[BXXPwg] Draft minutes of meeting in San Diego

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


Joe,
 
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.

Thanks,
Keith.

 
> > 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
>