IANA Registries for the Remote Direct Data Placement (RDDP) Protocols
RFC 6580
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
02 | (System) | Changed document authors from "" to "Mike Ko, David Black" |
|
2015-10-14
|
02 | (System) | Notify list changed from storm-chairs@ietf.org, draft-ietf-storm-rddp-registries@ietf.org to (None) |
|
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
|
2012-04-07
|
02 | (System) | RFC published |
|
2012-03-29
|
02 | Martin Stiemerling | Responsible AD changed to Martin Stiemerling from David Harrington |
|
2012-02-23
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2012-02-23
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2012-02-23
|
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2012-02-22
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2012-02-13
|
02 | (System) | IANA Action state changed to In Progress |
|
2012-02-10
|
02 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2012-02-09
|
02 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2012-02-09
|
02 | Cindy Morgan | IESG has approved the document |
|
2012-02-09
|
02 | Cindy Morgan | Closed "Approve" ballot |
|
2012-02-09
|
02 | Cindy Morgan | Ballot writeup text changed |
|
2012-02-09
|
02 | David Harrington | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2012-02-09
|
02 | David Harrington | Approval announcement text changed |
|
2012-02-09
|
02 | David Harrington | Approval announcement text regenerated |
|
2012-02-09
|
02 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss |
|
2012-02-03
|
02 | David Harrington | Approval announcement text changed |
|
2012-02-03
|
02 | David Harrington | Approval announcement text regenerated |
|
2012-01-17
|
02 | (System) | New version available: draft-ietf-storm-rddp-registries-02.txt |
|
2012-01-11
|
02 | Elwyn Davies | Request for Last Call review by GENART Completed. Reviewer: Elwyn Davies. |
|
2012-01-05
|
02 | Cindy Morgan | Removed from agenda for telechat |
|
2012-01-05
|
02 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
|
2012-01-05
|
02 | Amy Vezza | Ballot writeup text changed |
|
2012-01-05
|
02 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-05
|
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-04
|
02 | Jari Arkko | [Ballot comment] I agree with Pete that the RFC 2119 language is in general unnecessary. In some of the registries, providing an experimental value for … [Ballot comment] I agree with Pete that the RFC 2119 language is in general unnecessary. In some of the registries, providing an experimental value for testing and development purposes would be useful, IMHO. Look at RFC 5872 Sections 2.1 and 3 for an example and RFC 3692 for general guidance. For instance, I would reserve one RDMAP operation code value (0xF) as an experimental value. And 0xFFFF for SCTP Function Codes for DDP Session Control. But whether you want to make such a reservation depends of course entirely on your understanding of the needs of the RDDP community and how the protocols might evolve. |
|
2012-01-04
|
02 | Jari Arkko | [Ballot discuss] The draft has several places where it says: Assignment policy: If the requested value is not already assigned, it may be … [Ballot discuss] The draft has several places where it says: Assignment policy: If the requested value is not already assigned, it may be assigned to the requester. This was a bit confusing because the allocation policy (e.g., Standards Action) came much later in the Section, and I was wondering if the above meant "FCFS". I would replace all of these with one statement at the beginning of Section 3: Allocation requests for the below registries may come with a suggested numerical value that should be assigned. Such suggestions are useful when early implementations have already chosen particular code points before the final RFC comes out. If the allocation request in general is accepted, such suggestions may be honored if the suggested value is still free to be assigned. Or some words to the same effect. |
|
2012-01-04
|
02 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded |
|
2012-01-04
|
02 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-03
|
02 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-03
|
02 | Pete Resnick | [Ballot comment] I think the 2119 language is unnecessary and ought to be removed. Some of it belongs with the protocol that defines the field. … [Ballot comment] I think the 2119 language is unnecessary and ought to be removed. Some of it belongs with the protocol that defines the field. Some of it is giving instructions to IANA about their processing, which seems an inappropriate use of 2119. |
|
2012-01-03
|
02 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-03
|
02 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-02
|
02 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded |
|
2012-01-02
|
02 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded |
|
2012-01-01
|
02 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-12-31
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-12-30
|
02 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-12-29
|
02 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-12-21
|
02 | David Harrington | Placed on agenda for telechat - 2012-01-05 |
|
2011-12-21
|
02 | David Harrington | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-12-21
|
02 | David Harrington | [Ballot Position Update] New position, Yes, has been recorded for David Harrington |
|
2011-12-21
|
02 | David Harrington | Ballot has been issued |
|
2011-12-21
|
02 | David Harrington | Created "Approve" ballot |
|
2011-12-21
|
01 | (System) | New version available: draft-ietf-storm-rddp-registries-01.txt |
|
2011-12-21
|
02 | Amanda Baber | IANA understands that, upon approval of this document, there are six IANA actions that need to be completed. First, a new master registry for RDDP … IANA understands that, upon approval of this document, there are six IANA actions that need to be completed. First, a new master registry for RDDP parameters will be created. Second, in the master RDDP registry created above, a new registry called "RDMAP Errors" will be created. The registration rules for the new registry will be Standards Action. The registry will be populated with the following initial values: Layer Error-Type Error-Code Error-Type Name Error-Code Name Reference ----- ---------- ---------- ------------------------- ---- 0x0 0x0 Local Catastrophic Error [RFC5040] 0x0 0x1 0x00 Remote Protection Error Invalid Steering Tag [RFC5040] 0x0 0x1 0x01 Remote Protection Error Base or bounds violation [RFC5040] 0x0 0x1 0x02 Remote Protection Error Access rights violation [RFC5040] 0x0 0x1 0x03 Remote Protection Error Steering Tag not associated with RDMAP Stream [RFC5040] 0x0 0x1 0x04 Remote Protection Error Tagged Offset wrap [RFC5040] 0x0 0x1 0x09 Remote Protection Error Steering Tag cannot be invalidated [RFC5040] 0x0 0x1 0xff Remote Protection Error Unspecified Error [RFC5040] 0x0 0x2 0x05 Remote Operation Error Invalid RDMAP version [RFC5040] 0x0 0x2 0x06 Remote Operation Error Unexpected OpCode [RFC5040] 0x0 0x2 0x07 Remote Operation Error Catastrophic error,localized to RDMAP Stream [RFC5040] 0x0 0x2 0x08 Remote Operation Error Catastrophic error, global [RFC5040] 0x0 0x2 0x09 Remote Operation Error Steering Tag cannot be Invalidated [RFC5040] 0x0 0x2 0xff Remote Operation Error Unspecified Error [RFC5040] Third, in the master RDDP registry created above, a new registry called "DDP Errors" will be created. The registration rules for the new registry will be Standards Action. The registry will be populated with the following initial values: Layer Error-Type Error-Code Error-Type-Name Error-Code-Name Reference ===== ========== ========== ======================== ====== 0x1 0x0 0x00 Local Catastrophic [RFC5041] 0x1 0x1 0x00 Tagged Buffer Error Invalid Steering Tag [RFC5041] 0x1 0x1 0x01 Tagged Buffer Error Base or bounds violation [RFC5041] 0x1 0x1 0x02 Tagged Buffer Error Steering Tag not associated with DDP Stream [RFC5041] 0x1 0x1 0x03 Tagged Buffer Error Tagged Offset wrap [RFC5041] 0x1 0x1 0x04 Tagged Buffer Error Invalid DDP version [RFC5041] 0x1 0x2 0x01 Untagged Buffer Error Invalid Queue Number [RFC5041] 0x1 0x2 0x02 Untagged Buffer Error Invalid Message Sequence Number - no buffer available [RFC5041] 0x1 0x2 0x03 Untagged Buffer Error Invalid Message Sequence Number - Message Sequence Number range is not valid [RFC5041] 0x1 0x2 0x04 Untagged Buffer Error Invalid Message Offset [RFC5041] 0x1 0x2 0x05 Untagged Buffer Error DDP Message too long for available buffer [RFC5041] 0x1 0x2 0x06 Untagged Buffer Error Invalid DDP version [RFC5041] 0x1 0x3 Reserved for use by Lower Layer Protocol [RFC5041] Fourth, in the master RDDP registry created above, a new registry called "MPA Errors" will be created. The registration rules for the new registry will be Standards Action. The registry will be populated with the following initial values: Layer Error-Type Error-Code Error-Type-Name Error-Code-Name Reference ===== ========== ========== ========== ======= ============= 0x2 0x0 0x01 MPA Error TCP connection closed, terminated, or lost [RFC5044] 0x2 0x0 0x02 MPA Error MPA CRC Error [RFC5044] 0x2 0x0 0x03 MPA Error MPA Marker and ULPDU Length field mismatch [RFC5044] 0x2 0x0 0x04 MPA Error Invalid MPA Request Frame or MPA Response Frame [RFC5044] Fifth, in the master RDDP registry created above, a new registry called "RDMAP Message Operation Codes" will be created. The registration rules for the new registry will be Standards Action. The registry will be populated with the following initial values: RDMAP Message Operation Code Message Type Reference ============= =========================== ========= 0x0 RDMA Write [RFC5040] 0x1 RDMA Read Request [RFC5040] 0x2 RDMA Read Response RFC5040] 0x3 Send [RFC5040] 0x4 Send with Invalidate [RFC5040] 0x5 Send with Solicited Event [RFC5040] 0x6 Send with Solicited Event and Invalidate [RFC5040] 0x7 Terminate [RFC5040] Sixth, in the master RDDP registry created above, a new registry called "SCTP Function Codes for DDP Session Control" will be created. The registration rules for the new registry will be Standards Action. The registry will be populated with the following initial values: SCTP Function Code SCTP Function Name Reference ================== ===================================== ========== 0x0001 DDP Stream Session Initiate [RFC5043] 0x0002 DDP Stream Session Accept [RFC5043] 0x0003 DDP Stream Session Reject [RFC5043] 0x0004 DDP Stream Session Terminate [RFC5043] IANA understands that these six actions are the only actions needed to be completed upon approval of this document. |
|
2011-12-19
|
02 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-12-15
|
02 | Cindy Morgan | CORRECTED PROTO WRITE-UP: IANA Registries for the RDDP … CORRECTED PROTO WRITE-UP: IANA Registries for the RDDP (Remote Direct Data Placement) Protocols draft-ietf-storm-rddp-registries-00.txt Requested Publication Status: Proposed Standard PROTO shepherd: David L. Black (STORM WG Co-Chair) ------------------------------------------------------------------------ (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? David L. Black (david.black@emc.com) is the Document Shepherd and a co-author of the draft. The Document Shepherd has reviewed this version of the document and believes that it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had sufficient review from key WG members. The document has been prepared quickly, but has essentially no new technical content, as the document creates and populates IANA registries based on values specified in existing RFCs. (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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG is largely silent, but the Document Shepherd believes that the need for this document is clearly understood by the WG as a whole, and no objections have been raised. (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 the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? N/A. (1.h) Has the document split its references into normative and informative? Yes. 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]. There are no issues with the normative references. (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 suggest a reasonable name for the new registry? See [RFC5226]. 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? Almost the entire document is IANA Considerations text that creates new registries. The new contents and allocation procedure are defined, and the registrieshave reasonable names. The Expert Review process is not used. (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? N/A, (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The original RFCs that specified the RDDP protocol suite did not create IANA registries for RDDP error codes, operation codes and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. Working Group Summary Nothing exceptional to note. Document Quality There are multiple implementations of the RDDP protocols to which these new registries apply. |
|
2011-12-12
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
|
2011-12-12
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
|
2011-12-08
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
|
2011-12-08
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
|
2011-12-05
|
02 | Amy Vezza | Last call sent |
|
2011-12-05
|
02 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <storm@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-storm-rddp-registries-00.txt> (IANA Registries for the RDDP (Remote Direct Data Placement) Protocols) to Proposed Standard The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'IANA Registries for the RDDP (Remote Direct Data Placement) Protocols' <draft-ietf-storm-rddp-registries-00.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The original RFCs that specified the RDDP protocol suite did not create IANA registries for RDDP error codes, operation codes and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-rddp-registries/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-rddp-registries/ No IPR declarations have been submitted directly on this I-D. |
|
2011-12-05
|
02 | David Harrington | Last Call was requested |
|
2011-12-05
|
02 | David Harrington | State changed to Last Call Requested from Publication Requested. |
|
2011-12-05
|
02 | (System) | Ballot writeup text was added |
|
2011-12-05
|
02 | (System) | Last call text was added |
|
2011-12-05
|
02 | (System) | Ballot approval text was added |
|
2011-11-14
|
02 | Cindy Morgan | Submitted to IESG |
|
2011-11-14
|
02 | Cindy Morgan | IETF state changed to Submitted to IESG for Publication from In WG Last Call |
|
2011-11-14
|
02 | Cindy Morgan | PROTO writeup: Enhanced RDMA Connection Establishment draft-ietf-storm-mpa-peer-connect-04.txt Requested Publication … PROTO writeup: Enhanced RDMA Connection Establishment draft-ietf-storm-mpa-peer-connect-04.txt Requested Publication Status: Proposed Standard PROTO shepherd: David L. Black (STORM WG Co-Chair) ------------------------------------------------------------------------ (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? David L. Black (david.black@emc.com) is the Document Shepherd. The Document Shepherd has reviewed this version of the document and believes that it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had sufficient review from key WG members. The Document Shepherd is satisifed that this document has been sufficiently reviewed by members of the community that uses this protocol. (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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus of the WG members who are familiar with this technology is solid. The storm (STORage Maintenance) WG conducts maintenance on multiple storage protocols, and different WG members have differing levels of interest and expertise across the protocols that the WG maintains. (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 the Internet-Drafts Checklist 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? Yes, the document satisfies ID nits. No other formal review criteria apply. (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]. The references have been split, and there are no downward references or normative references to work-in-progress documents. (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 suggest a reasonable name for the new registry? See [RFC5226]. 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? The IANA Considerations section exists and states that no IANA actions are required by this document. There are some values defined in this document that may be appropriate to be move into IANA registries if future extensions should occur, but creation of IANA registries is not necessary at this juncture (this document suffices as a reference). (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? N/A. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document extends iWARP (rddp) RDMA connection establishment with two functions that apply to the adaptation layer between RDMA functionality and the transport protocol. The first extension broadens MPA (adaptation to TCP) to enable connection establishment without initial data to send in support of applications structured as a collection of peers. The second extension improves connection setup for both MPA/TCP and the SCTP adaptation by adding support for standardized exchange of resource availability (queue depth) information. Working Group Summary This document makes small additions to existing protocols. There has been clear WG recognition that this functionality is needed to match the usage of these protocols by an important class of applications, and no significant WG dissent from the design in this document. Document Quality There are multiple existing implementations of the iWARP (rddp) RDMA protocols that have plans to add the functionality specified in this document. Hemal Shah reviewed the near-final version of this draft and found some important corrections that needed to be made. |
|
2011-11-14
|
02 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-11-14
|
02 | Cindy Morgan | [Note]: 'David Black (david.black@emc.com) is the document shepherd.' added |
|
2011-10-22
|
02 | David Black | Immediate WG Last Call on -00 version because the MPA peer connect draft (@ IESG) is waiting for this draft to create the RDDP registries. |
|
2011-10-22
|
02 | David Black | IETF state changed to In WG Last Call from WG Document |
|
2011-10-19
|
00 | (System) | New version available: draft-ietf-storm-rddp-registries-00.txt |