Document Action: 'Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)' to Experimental RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Asynchronous Channels for the Blocks Extensible Exchange Protocol 
   (BEEP) '
   <draft-thomson-beep-async-02.txt> as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-thomson-beep-async-02.txt

Technical Summary

   The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
   framework for the development of application protocols.  This
   document describes a BEEP feature that enables asynchrony for
   individual channels.

Working Group Summary

   This is an individual submission.

Document Quality

   This was reviewed on the mailing list for the concluded BEEP WG.
   There was moderate controversy about whether this extension was
   needed as it is possible to work-around the lack of this feature
   in BEEP at the next layer up.  No other technical objections were
   raised and there was explicit support from several parties.
   At least one open source BEEP library implementation has agreed
   to implement this extension.

Personnel

   Chris Newman is the document shepherd.  This has been reviewed for
   the IESG by Alexey Melnikov.  Marshall Rose and other participants
   of the BEEP WG mailing list reviewed this proposal.

RFC Editor Note

Add at the end of Section 1 (Introduction) the following new paragraph:

  This document is published as an Experimental RFC in order to find
  out whether the extension is going to be deployed for use in
  a variety of use cases and applications. 

In section 3.1, 1st paragraph:

OLD:
   The "feature" attribute in the BEEP greeting contains a whitespace
   separate list of features supported by each peer.  If both lists
           ^
   contain the same feature that feature may be used by either peer.
NEW:
   The "feature" attribute in the BEEP greeting contains a whitespace
   separated list of features supported by each peer.  If both lists
           ^
   contain the same feature that feature may be used by either peer.


Section 3.1, 2nd paragraph, 2nd sentence:
OLD:
  If both peers include
  this feature in the greeting message, either peer is able to create
  an asynchronous channel.
NEW:
  If either peer does not include
  this feature in the greeting message, neither peer is able to create
  an asynchronous channel.


Add a new Section 3.4 with the title "Error handling"

  BEEP does not provide any mechanism for managing a peer that does not
  respond to a request.  Synchronous channels cannot be used or even
  closed if a peer does not provide a response to a request.  The only
  remedy available is closing the underlying transport.  While an
  asynchronous channel cannot be closed, it can still be used for
  further requests.  However, any outstanding request still consumes
  state resources.  Client peers may dispose of such state after a
  configured interval, but must be prepared to discard unrecognized
  responses if they do so.


In Section 5, replace the 2nd paragraph with the following 2 paragraphs:

OLD:
   Peers that serve requests on asynchronous channels are not subject to
   any specific problems from state accumulation.  Peers in the serving
   role are able to use flow control [RFC3081] to limit the consumption
   of local resources.
NEW:
  A client peer maintains state for each request that it sends.
  A client peer should enforce a configurable limit on the number
  of requests that it will allow to be outstanding at any time.
  This limit could be enforced at channel, connection, or application
  scope.  Once this limit is reached, the client peer might prevent
  or block further requests from been generated.

  Peers that serve requests on asynchronous channels also accumulate
  state when a request is accepted for processing.  Peers in the
  serving role may similarly limit to the number of requests that
  are processed concurrently. Once this limit is reached the receiving
  peer can either stop reading new requests, or might start rejecting
  such requests by generating error responses.  Alternatively, the flow
  control [RFC3081] can be used; SEQ frames can be suppressed, allowing
  the flow control window to close and preventing the receipt of further
  requests.

"an BEEP" --> "a BEEP" (2 cases: 1 in the Abstract and 1 in the
Introduction)
"an means" --> "a means" (in Section 3)

In Section 1, 4th paragraph:
"only requests may be processed" --> "except that requests may be
processed"