Lisa raised a concern about number of reviewers supporting the proposal.

Based on discussion with Chris Newman and Lisa, I decided to take the easy way out and to downgrade the document to Experimental. The author didn't object to this option.

Another alternative would have been to solicit more reviews and proceed with publication as a Proposed Standard, assuming reviews are positive.

[Ballot comment]
In response to Lisa's concerns:

[22:04:40] <Chris Newman> Lisa is also incorrect that there's no benefit for the receiver.
[22:04:51] <alexeymelnikov> What is the benefit?
[22:08:55] <Chris Newman> So with channels, the receiver will typically want to implement one thread per channel to keep things simple. For this extension, the receiver will implement a work queue and dynamically create or reuse idle threads as needed. The receiver can control how many worker threads it wants to create for the work queue, so it can dynamically adjust to load. That's much more difficult with a channel-based architecture. Channels also have a lot more receiver-side state.

Later on Chris said:

[22:23:57] <Chris Newman> BEEP channels are stateful asynchrony, Async requests are stateless asynchrony. Both are beneficial for different use cases for both parties.

Also, a similar feature is present in both base XMPP, IMAP and LDAP. It is used heavily in XMPP and LDAP. I was thinking to take advantage of it in Isode's IMAP server, for example for out of order processing of full body searches over multiple email messages.

Note to myself:
Add an RFC Editor note about use cases.

[Ballot comment]
Here is a comment from Chris:

[22:04:40] <Chris Newman> Lisa is also incorrect that there's no benefit for the receiver.
[22:04:51] <alexeymelnikov> What is the benefit?
[22:08:55] <Chris Newman> So with channels, the receiver will typically want to implement one thread per channel to keep things simple. For this extension, the receiver will implement a work queue and dynamically create or reuse idle threads as needed. The receiver can control how many worker threads it wants to create for the work queue, so it can dynamically adjust to load. That's much more difficult with a channel-based architecture. Channels also have a lot more receiver-side state.

Later on Chris said:

[22:23:57] <Chris Newman> BEEP channels are stateful asynchrony, Async requests are stateless asynchrony. Both are beneficial for different use cases for both parties.

Also, a similar feature is present in both base XMPP, IMAP and LDAP. It is used heavily in XMPP and LDAP. I was thinking to take advantage of it in Isode's IMAP server, for example for out of order processing of full body searches over multiple email messages.

Note to myself:
Add an RFC Editor note about use cases.

[Ballot comment]
Due to power cut I have no access to my mail at the moment.

Here is a comment from Chris:

[22:04:40] <Chris Newman> Lisa is also incorrect that there's no benefit for the receiver.
[22:04:51] <alexeymelnikov> What is the benefit?
[22:08:55] <Chris Newman> So with channels, the receiver will typically want to implement one thread per channel to keep things simple. For this extension, the receiver will implement a work queue and dynamically create or reuse idle threads as needed. The receiver can control how many worker threads it wants to create for the work queue, so it can dynamically adjust to load. That's much more difficult with a channel-based architecture. Channels also have a lot more receiver-side state.

Later on Chris said:

[22:23:57] <Chris Newman> BEEP channels are stateful asynchrony, Async requests are stateless asynchrony. Both are beneficial for different use cases for both parties.

Also, a similar feature is present in both base IMAP and LDAP. It is used heavily in LDAP. I was thinking to take advantage of it in Isode's IMAP server, for example for full body searches over multiple email messages.

[Ballot comment]
Due to power cut I have no access to my mail at the moment.

Here is a comment from Chris:

[22:04:40] <Chris Newman> Lisa is also incorrect that there's no benefit for the receiver.
[22:04:51] <alexeymelnikov> What is the benefit?
[22:08:55] <Chris Newman> So with channels, the receiver will typically want to implement one thread per channel to keep things simple. For this extension, the receiver will implement a work queue and dynamically create or reuse idle threads as needed. The receiver can control how many worker threads it wants to create for the work queue, so it can dynamically adjust to load. That's much more difficult with a channel-based architecture. Channels also have a lot more receiver-side state.

[Ballot comment]
The OPS-DIR review performed by Mehmet Ersue revealed some problems related to scalability and configurability of the extension feature to BEEP described in this document.

> Although the document introduces additional state information which
> needs to be stored and managed it does not discuss scalability
> sufficiently. The document also does not introduce a configurable
> parameter for the 'maximum count of allowed parallel asynchronous
> channels'.
> Also the document misses to disscuss what happens when a response does
> not follow a request, i.e. is missing the exception handling
> thereafter.
>

I believe that the operational and implementability value of the document would be improved if these aspects would be considered by the authors and the respective details added to the document.

[Ballot comment]
The archives for BXXP have moved away from the link the charter and tools page point to. I was able to find them (I think) by digging around at beepcore.org <http://www.beepcore.org/old-archives/beepwg/pipermail/beepwg/>. Is there a better store somewhere?

[Ballot discuss]
BEEP already has a feature for asynchrony: it's multiple channels.  The model proposed in this document would lead to either slightly simpler code for the initiating client or slightly better performance (depending on whether the client maintains a pool of channels), but there are no gains for the responding client.  Overall, the cost of defining a new standard and seeing it implemented, tested and deployed are, IMO, not worth it. 

That said, once discussed, I won't continue to hold this architectural and tradeoff objection as a DISCUSS.

[Ballot comment]
If you are making edits...

s/an BEEP/a BEEP/ twice
s/an means/a means/

Section 1
s/only requests may be processed/except that requests may be processed/

Section 3.1
It might be nice to state explicitly the converse of...
  If both peers include
  this feature in the greeting message, either peer is able to create
  an asynchronous channel.
That is:
  If either peer does not include
  this feature in the greeting message, neither peer is able to create
  an asynchronous channel.

  (1.a)  Who is the Document Shepherd for this document?  Has the
    Document Shepherd personally reviewed this version of the document
    and, in particular, does he or she believe this version is ready
    for forwarding to the IESG for publication?

  Chris Newman <chris.newman@sun.com>.  Yes.

  (1.b)  Has the document had adequate review both from key members of
    the interested community and others?  Does the Document Shepherd
    have any concerns about the depth or breadth of the reviews that
    have been performed?

  This has been reviewed on the BEEP WG mailing list:

<http://groups.google.com/group/beepwg/browse_thread/thread/db0255c634c7eb0c#>
  No concerns about review.

  (1.c)  Does the Document Shepherd have concerns that the document
    needs more review from a particular or broader perspective, e.g.,
    security, operational complexity, someone familiar with AAA,
    internationalization or XML?

  No.

  (1.d)  Does the Document Shepherd have any specific concerns or
    issues with this document that the Responsible Area Director
    and/or the IESG should be aware of?  For example, perhaps he or
    she is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it.  In any event, if
    the interested community has discussed those issues and has
    indicated that it still wishes to advance the document, detail
    those concerns here.

  There was some controversy as this problem can be solved both at the BEEP
  layer and as part of the application layered on top of BEEP.  The shepherd
  feels both solutions are appropriate and have their place.

  (1.e)  How solid is the consensus of the interested community behind
    this document?  Does it represent the strong concurrence of a few
    individuals, with others being silent, or does the interested
    community as a whole understand and agree with it?

  There was explicit support from a few individuals on the list including
  the primary editor of the base protocol.  The feature this adds is a well
  understood feature present in other IETF application protocols (such as
  LDAP).  There were no objections to the technical details of thi to the feature
  although there was some discussion that the feature could be implemented at
  a different layer and thus may not be necessary at the BEEP layer.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director.  (It
    should be in a separate email because this questionnaire is
    entered into the ID Tracker.)

  No.

  (1.g)  Has the Document Shepherd personally verified that the
    document satisfies all ID nits?  (See
    http://www.ietf.org/ID-Checklist.html and
    http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
    enough; this check needs to be thorough.  Has the document met all
    formal review criteria it needs to, such as the MIB Doctor, media
    type and URI type reviews?

  Passes ID Nits v2.11.07.

  (1.h)  Has the document split its references into normative and
    informative?  Are there normative references to documents that are
    not ready for advancement or are otherwise in an unclear state?
    If such normative references exist, what is the strategy for their
    completion?  Are there normative references that are downward
    references, as described in [RFC3967]?  If so, list these downward
    references to support the Area Director in the Last Call procedure
    for them [RFC3967].

  Yes.  No references to drafts or normative downrefs.

  (1.i)  Has the Document Shepherd verified that the document IANA
    consideration section exists and is consistent with the body of
    the document?  If the document specifies protocol extensions, are
    reservations requested in appropriate IANA registries?  Are the
    IANA registries clearly identified?  If the document creates a new
    registry, does it define the proposed initial contents of the
    registry and an allocation procedure for future registrations?
    Does it suggested a reasonable name for the new registry?  See
    [I-D.narten-iana-considerations-rfc2434bis].  If the document
    describes an Expert Review process has Shepherd conferred with the
    Responsible Area Director so that the IESG can appoint the needed
    Expert during the IESG Evaluation?

  Yes.

  (1.j)  Has the Document Shepherd verified that sections of the
    document that are written in a formal language, such as XML code,
    BNF rules, MIB definitions, etc., validate correctly in an
    automated checker?

  No formal language outside examples.  I'm not aware of a BEEP validator so
  validation was not performed of examples.

  (1.k)  The IESG approval announcement includes a Document
    Announcement Write-Up.  Please provide such a Document
    Announcement Writeup?  Recent examples can be found in the
    "Action" announcements for approved documents.  The approval
    announcement contains the following sections:

    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.

IANA comments:

Upon approval of this document, IANA will register the following
in the "BEEP Features" registry at
http://www.iana.org/assignments/beep-parameters/beep-parameters.xhtml

Feature Reference
------- ---------
async [RFC-thomson-beep-async-02]

We understand the above to be the only IANA action for this
document.