[BXXPwg] Draft minutes of meeting in San Diego

Keith McCloghrie kzm@cisco.com
Thu, 28 Dec 2000 15:11:37 -0800 (PST)

Thanks for your technical comments.  However, I was really looking
for agreement on recording what happened at the meeting.  If you
believe that my draft minutes do not reflect what happened, could
you suggest alternative wording.


> > Any comments on these minutes ?
> > 
> > Keith.
> > --------------
> > 
> > BEEP WG, Thursday 14 December 2000, 1530-1730
> > 
> ...
> > 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.
> What is not yet clear is whether such a document is really
> needed, or whether that mapping is essentially trivial.
> Mapping BEEP sessions onto a single TCP connection provides
> strict priorities within the group only; it isn't clear
> how such priorities would interact with other concurrent
> BEEP associations on the same path (or same endpoints),
> e.g., for different applications, or for different
> security mechanisms within a single application. At that
> point, the different BEEPs are in effect already
> multiple TCP connections (with all their inter-stream
> independence). 
> > 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.
> It is the lack of #3 which, in part, further impedes #1. 
> > 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.
> This is inconsistent with the current ID. BEEP currently 
> indicates that many BEEP-level errors simply result in the
> termination of the connection, rather than the response of
> ERR. ERRs use 3-digit codes determined by the application.
> Both of these indicate that ERRs are exactly for the
> application, and not for BEEP-level errors.
> Joe