[BXXPwg] Draft minutes of meeting in San Diego

Keith McCloghrie kzm@cisco.com
Fri, 22 Dec 2000 11:17:23 -0800 (PST)

Any comments on these minutes ?


BEEP WG, Thursday 14 December 2000, 1530-1730

   1. Agenda bashing
   2. WG status - Keith McCloghrie 
   3. Review of BEEP - Marshall Rose 
   4. Multi-peer application protocols - Dan Li 
   5. Discussion and Q&A

After a slight reordering of the agenda, Keith presented the WG status.
The WG's two Internet-Drafts (draft-ietf-beep-framework-nn.txt and
draft-ietf-beep-tcpmapping-nn.txt) have completed WG Last Call and IETF
Last Call, and are now awaiting the IESG's formal decision before they
become Proposed Standards.  The other two I-D's of relevance to the WG
are draft-mrose-beep-design-01.txt which Marshall and Carl will publish
as an Informational RFC, and draft-mrose-beep-sctpmapping-00.txt for
which Marshall is waiting on an action by the SCTP folks.  Thus, none
of the four I-D's needed any discussion at this meeting.  So, the focus
of this meeting was for the benefit of implementors (as opposed to
making progress on the charter of the WG).

Next, Marshall presented his review of BEEP.  He covered much the same
material as in the previous WG meeting, but it was updated based on the
changes adopted by the WG since last Summer.  Several issues came up
during the presentation:

1. The notion of mapping a BEEP session onto multiple TCP connections
   is still under consideration by Joe Touch, even though no I-D has
   been generated as yet.

2. For one-to-one exchanges, there is a positive reply (the "RPY"
   message) and a negative reply (the "ERR" message).  However, for the
   one-to-many exchanges, the replies consist of zero or more "ANS"
   messages followed by a "NUL" message.  That is, a negative reply can
   not be generated after one or more "ANS" messages have been sent.
   Further discussion of this issue was deferred to the end of the

3. It was suggested that the "best current practices" for implementing
   the transport mappings should be documented.  It was agreed that this
   can be done (based on implementation experience) in a future revision
   of the transport mappings document(s), e.g., advice of how to implement
   BEEP's flow control.

Dan Li then presented some requirements for a multi-peer application
(see draft-danli-wrec-wcip-00.txt).  The basic requirement would appear
to be the need for a "logical bi-directional channel" consisting of
multicast downstream and unicast upstream.

Discussion then returned to the issue of whether the "ERR" message
should be allowed (as an alternative to a "NUL" message) in one-to-many
exchanges.  The chair observed that this was not a new issue; the
Working Group had discussed it at least once before on the mailing
list and decided in favour of the approach in the current documents.
Another view was that with the current approach, the "ERR" message is
used to convey errors detected by the BEEP layer, including syntax
errors for messages; in contrast, application-specific errors are
conveyed using "RSP" or "ANS" messages.  After some discussion, the
(non-unanimous) consensus was to stay with the current approach, and
ask the editor to see whether some clarifying text could be added to
the framework document as an editorial change.