Skip to main content

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