BEEP WG, Thursday 14 December, 1530-1730 Agenda 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. Joe confirmed that this work was pending finalization of the framework. 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 meeting. 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. However, there was some confusion (at the meeting) on what the current documents indicate. At least one group argued that "ERR" messages convey BEEP-layer errors only, and that application-specific errors are conveyed by "RSP" or "ANS" messages. Joe Touch believed the current documents indicated otherwise; that the ERR messages include application errors. After some discussion, the (non-unanimous) consensus was to go/stay with the former approach, and ask the editor to see whether some clarifying text could be added to the framework document as an editorial change.