Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
RFC 5573
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
02 | (System) | Notify list changed from martin.thomson@andrew.com, draft-thomson-beep-async@ietf.org to (None) |
2012-08-22 |
02 | (System) | post-migration administrative database adjustment to the No Objection position for Lisa Dusseault |
2009-06-11 |
02 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2009-06-11 |
02 | Cindy Morgan | [Note]: 'RFC 5573' added by Cindy Morgan |
2009-06-10 |
02 | (System) | RFC published |
2009-05-24 |
02 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Sam Weiler. |
2009-05-18 |
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-05-18 |
02 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-05-18 |
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-05-15 |
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-05-13 |
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-05-13 |
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-05-13 |
02 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2009-05-12 |
02 | (System) | IANA Action state changed to In Progress |
2009-05-12 |
02 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-05-12 |
02 | Amy Vezza | IESG has approved the document |
2009-05-12 |
02 | Amy Vezza | Closed "Approve" ballot |
2009-05-08 |
02 | (System) | Removed from agenda for telechat - 2009-05-07 |
2009-05-07 |
02 | Cindy Morgan | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan |
2009-05-07 |
02 | Alexey Melnikov | 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 … 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. |
2009-05-07 |
02 | Alexey Melnikov | Intended Status has been changed to Experimental from Proposed Standard |
2009-05-07 |
02 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault |
2009-05-07 |
02 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-05-07 |
02 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-05-07 |
02 | Dan Romascanu | [Ballot comment] |
2009-05-07 |
02 | Alexey Melnikov | [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 … [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. |
2009-05-07 |
02 | Alexey Melnikov | [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 … [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. |
2009-05-07 |
02 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-05-06 |
02 | Alexey Melnikov | [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> … [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. |
2009-05-06 |
02 | Alexey Melnikov | [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> … [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. |
2009-05-06 |
02 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-05-06 |
02 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2009-05-06 |
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-05-06 |
02 | Dan Romascanu | [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 … [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. |
2009-05-05 |
02 | Robert Sparks | [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 … [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? |
2009-05-05 |
02 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-05-05 |
02 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-05-05 |
02 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-05-05 |
02 | Lisa Dusseault | [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 … [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. |
2009-05-05 |
02 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
2009-05-05 |
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-05-04 |
02 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-05-04 |
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-05-04 |
02 | Adrian Farrel | [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 … [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. |
2009-05-04 |
02 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-04-27 |
02 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2009-04-27 |
02 | Alexey Melnikov | Ballot has been issued by Alexey Melnikov |
2009-04-27 |
02 | Alexey Melnikov | Created "Approve" ballot |
2009-04-27 |
02 | Alexey Melnikov | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Alexey Melnikov |
2009-04-24 |
02 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-04-17 |
02 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document … (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. |
2009-04-17 |
02 | Alexey Melnikov | Placed on agenda for telechat - 2009-05-07 by Alexey Melnikov |
2009-04-16 |
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Weiler |
2009-04-16 |
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Weiler |
2009-04-16 |
02 | Samuel Weiler | Assignment of request for Last Call review by SECDIR to Chris Newman was rejected |
2009-04-16 |
02 | Amanda Baber | 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] … 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. |
2009-04-07 |
02 | Alexey Melnikov | Removed from agenda for telechat - 2009-05-07 by Alexey Melnikov |
2009-04-07 |
02 | Alexey Melnikov | Placed on agenda for telechat - 2009-05-07 by Alexey Melnikov |
2009-04-03 |
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Chris Newman |
2009-04-03 |
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Chris Newman |
2009-03-27 |
02 | Cindy Morgan | Last call sent |
2009-03-27 |
02 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2009-03-26 |
02 | Alexey Melnikov | Area acronymn has been changed to app from gen |
2009-03-26 |
02 | Alexey Melnikov | Last Call was requested by Alexey Melnikov |
2009-03-26 |
02 | Alexey Melnikov | State Changes to Last Call Requested from Publication Requested by Alexey Melnikov |
2009-03-26 |
02 | Alexey Melnikov | [Note]: 'Chris Newman is the document shepherd. ' added by Alexey Melnikov |
2009-03-26 |
02 | (System) | Ballot writeup text was added |
2009-03-26 |
02 | (System) | Last call text was added |
2009-03-26 |
02 | (System) | Ballot approval text was added |
2009-03-23 |
02 | Alexey Melnikov | Responsible AD has been changed to Alexey Melnikov from Chris Newman |
2009-03-23 |
02 | Alexey Melnikov | Draft Added by Alexey Melnikov in state Publication Requested |
2009-03-23 |
02 | (System) | New version available: draft-thomson-beep-async-02.txt |
2008-11-25 |
01 | (System) | New version available: draft-thomson-beep-async-01.txt |
2008-05-27 |
00 | (System) | New version available: draft-thomson-beep-async-00.txt |