[BXXPwg] Items of WG consensus
Wed, 16 Aug 2000 22:50:14 -0700 (PDT)
Nobody has proposed any changes to the draft minutes (below), and so
I'm going to send them in as the official minutes. Further, based on
the mailing list discussions, I believe that with the exception of the
"piggybacking" issue, the WG was adopted all the items of consensus of
the meeting listed in the minutes.
For the "piggybacking" issue, I can only recall one person arguing
against it. I suggest that if anybody else wants to argue against it,
now would be a good time to say so. If nobody does, then I think we
have "rough consensus" on that issue also.
> From: Keith McCloghrie <email@example.com>
> Message-Id: <200008060803.BAA04270@ups.cisco.com>
> To: firstname.lastname@example.org
> Date: Sun, 6 Aug 2000 01:03:06 -0700 (PDT)
> Here's a draft of the minutes of last week's meeting.
> BEEP Working Group
> Minutes of meeting at Pittsburgh IETF (August 2000)
> - review of agenda
> - review of BEEP: design, framework, and TCP-mapping - Marshall Rose
> - prepared presentations
> - Issues List - Marshall Rose
> - Mapping LDAP onto BEEP - Kurt Zeilenga
> - suggestions/comments from the floor
> - disposition of Internet-Drafts
> - wrap-up
> First session (Thursday 4th August)
> As an introduction, Keith McCloghrie reviewed the charter and
> milestones for the WG. Marshall Rose then presented a review of BEEP,
> the rationale for its design choices, the framework for the protocol,
> and its mapping on top of TCP. In addition to clarifying questions,
> several suggestions were made during the presentation:
> - it was suggested that some transport mappings will be able to get
> indications of network congestion (e.g., via "Congestion Manager"), and
> therefore that it would be useful for the interface between the
> framework and a transport mapping to allow the transport mapping to
> pass up an indication of network congestion.
> - for security, it was asked whether it's possible to start TLS first,
> and then run BEEP over top of it, rather than not being able to start
> TLS until after some BEEP messages have already been exchanged.
> Marshall clarified that it's not currently possible, but he would think
> about whether it could be made possible. Marshall also clarified that
> it's not possible to do encryption on a per-channel basis, i.e., that
> negotiation of encryption applies to all channels.
> Marshall then presented a list of issues that had been raised on the
> mailing-list prior to the meeting. He listed the issues in five
> categories: Framing, Profiles, Channel Management, Reporting and TCP
> A) Framing Issues
> 1. Serial/Sequence numbers - BEEP's inclusion of serial and sequence
> numbers in its message header format could be viewed as redundant
> information. However, they ensure that the communicating applications
> will detect situations in which they become unsynchronized. That is,
> sequence and serial numbers provide robustness in the form of catching
> application-programming errors. In addition, Marshall cited his
> practical experience of catching such errors during interoperability
> testing of BXXP implementations. It was pointed out that the degree of
> redundancy is dependent on the transport mapping, and that different
> header formats for different transport mappings is undesirable for many
> reasons, e.g., because it complicates encoding and parsing. Therefore,
> the consensus of the meeting was to keep the serial and sequence numbers
> 2. Invalid RSPs - the framework does not specify what happens when a
> channel gets an invalid RSP. It was agreed that an invalid RSP on
> channel zero should cause the whole session to be aborted. However, it
> is unnecessary to abort the whole session for an invalid RSP on a
> non-zero channel; rather, it is only neccesary to abort the individual
> channel. Therefore, the consensus of the meeting was to generate a
> diagnostic message, and to shut down a non-zero channel on which an
> invalid RSP was received.
> 3. MIME headers only in first frame of a message - the framework does
> not explicitly explain this requirement. It was observed that the
> scope of these MIME headers is limited, and so, it's unlikely that they
> could be large (e.g., larger than the size of a frame). Nevertheless,
> they enjoy a "free ride" from a flow-control perspective, because they
> are part the header, not part of the payload, and therefore not subject
> to flow-control. Therefore, the consensus of the meeting was that the
> framework document does need to add explanatory text about this issue.
> 4. REQs and RSPs - the framework requires that each REQ have one and
> only one RSP. Discussion of this issue led to several examples of
> applications which have a different requirement:
> - a logging application, which does not need an application-level
> acknowledgement for each log message it sends; this was described
> as the "1-to-0" requirement (one REQ with no RSP).
> - a status reporting application, where a request for status invokes
> multiple periodic responses, e.g., a RSP providing status every 10
> seconds; this was described as the "1-to-N" requirement (one REQ
> with many RSPs).
> Several mechanisms were suggested to address these requirements. It was
> proposed that a solution should avoid the sending of useless/redundant
> Second session (Friday 5th August)
> Kurt Zeilenga gave a presentation of issues he had found in
> investigating how to map LDAP on top of BEEP. He stated the primary
> issue as being the number of situations where LDAP interactions are not
> one REQ to one RSP. In particular, he gave "persistent search" as an
> example of a 1-to-N requirement, and "unsolicited responses" as an
> example of a 1-to-0 requirement.
> Marshall then continued to present the Issues List.
> 4. REQs and RSPs (continued) - The consensus of the meeting was to
> accept the "1-to-0" and "1-to-N" requirements, and to request
> volunteers to work offline on a solution, and then send to the
> mailing-list. Joe Touch volunteered to prepare a proposal.
> B) Profile Issues
> 1. Default Content Type - should a profile be allowed to specify a
> default Content Type. By having a default, an application would not
> have to send a Content Type every time it opened a channel, which could
> save, say, 40 bytes. On the other hand, always having the Content Type
> explicitly specified would simplify the task of a "debugger" being used
> to capture all exchanges on the BEEP session by capturing packets "on
> the wire". Thus, this issue is a trade-off between "reducing the
> number of bits on the wire" versus "ease of debugging". A show of
> hands determined that there was no consensus in the meeting on which
> choice was better. Thus, this issue was deferred for discussion on the
> mailing list.
> 2. Default Character Set - should an XML-based profile be allowed to
> specify a default character set. One suggestion was to discourage the
> use of anything other than UTF-8. However, it was pointed out that the
> argument in favour of UTF-16 is that Asian characters can be
> represented in only 2 bytes in UTF-16 instead of 3 bytes in UTF-8
> (although other considerations cause the overall length of encodings
> to even out overall). The consensus of the meeting was for all
> XML-based profiles to have a default of UTF-8, i.e., not to allow each
> profile to have its own default. However, if an XML-based profile
> needs to specify an alternative character set, it should use a
> Content-Type header to do so.
> C) Channel Management Issues
> 1. Closing Channels - should the framework allow channels to be
> closed. Such a mechanism will be useful for the transport mappings to
> know traffic has ceased on a channel (so that buffers can be released),
> and the closing of a channel will allow its re-use. Having a Close
> Channel will also provide the means to send diagnostic information and
> to shut-down a non-zero channel (see the "Invalid RSPs" issue above).
> This led to discussion of allowing more than 255 channels. When
> running over TCP, channels will be able to be re-used faster than TCP
> ports can be re-used (because of TCP's TIME-WAIT state). Therefore,
> the size of the channel number space should be larger than the number
> of TCP ports. Thus, it was suggested that a channel number be up to 31
> bits wide. However, it was also suggested that the minimum number of
> concurrently open channels supported by an implementation need only be
> 257. The consensus of the meeting was to introduce a Close Channel
> mechanism able to include diagnostic information, to allow 31 bits of
> channels number with a minimum of 257 concurrently open channels.
> 2. Piggybacks - an XML-based profile is allowed to include an encapsulated
> message as part of channel creation. This piggybacking capability saves
> a round trip time, and that was thought to be a good thing for some
> transport mappings, e.g., T/TCP or UDP. However, implementations should
> not send an "unreasonable" amount of data in the <start>. The consensus
> of the meeting was to retain piggybacks, and to add text to the
> specification reminding profile designers that initialization elements
> should be reasonable in size.
> D) Reporting Issues
> 1. Error code - should channel-0 as well as the SASL and TLS channels
> use three digit error codes. It was agreed that the hierarchical model
> of the three digit codes was good, and that having textual messages for
> humans in addition to the machine-readable 3-digit error codes was
> good. The consensus of the meeting was for no change.
> E) TCP Mapping Issues
> 1. Silly Window Syndrome - should the TCP mapping document include text
> similar to RFC 1122 to explain SWS. The consensus of the meeting was
> to cite RFC 1122 and to explain the context of how it applies to BEEP,
> i.e., the same except for retranmissions.
> 2. Shrinking the Window - should the TCP mapping document include words
> similar to RFC 1122 on allowing the window's right-hand edge to move
> only to the right. The consensus of the meeting was to cite RFC 1122
> and to explain the context of how it applies to BEEP, i.e., the same
> but there's no "congestion window".
> Suggestions from the Floor
> It was suggested that having the channel number in RSP messages would
> simplify an implementation. The alternative perspective was that the
> channel number of a received RSP is easy to obtain through looking up
> the RSP's serial number. The ability of a debugger capturing "on the
> wire" packets was again cited as being simpler if it did not have to
> see as many packets, nor keep as much state. Thus, the consensus of
> the meeting was to include the channel number in the RSP message.
> This led to the suggestion that the serial number no longer needs
> to be unique per session, only unique per channel. It was observed
> that this would make it simpler for multi-threaded implementations.
> Therefore, the consensus was that message serial numbers only need to
> be unique within a channel.
> Disposition of Internet Drafts
> It was observed that the design document, draft-mrose-bxxp-design-00.txt,
> is written as Marshall and Carl's rationale for the design of BXXP,
> which is the starting point of the Working Group's effort. Thus, it is
> not appropriate for it to become a standards-track document, nor for it
> to be a WG document. Instead, it was agreed that the authors be
> thanked for their input and allowed to publish it in whatever way they
> wish, e.g., the WG would be quite happy for it to be published as an
> Informational RFC.
> The framework and TCP-mapping documents, draft-mrose-bxxp-framework-01.txt
> and draft-mrose-bxxp-tcpmapping-01.txt, were adopted as WG documents, and
> Marshall will update them based on the consensus of the WG. The consensus
> of the WG will be as recorded in the minutes and as modified by discussion,
> if any, of the minutes on the mailing-list.
> Marshall explained that the initial attempt at a SCTP-mapping document,
> draft-mrose-beep-sctpmapping-00.txt, needs further work. As such it
> will be adopted as a WG document, but could have significant revisions
> at a later date.
> The WG welcomed Joe Touch's offer to start work on a transport mapping
> document for BEEP over "multiple TCP connections". Work on a transport
> mapping document for BEEP over UDP was deferred. Joe Touch also stated
> his intention to make a proposal for being able to turn off encryption on
> a per-channel basis.
> BXXPwg mailing list