Re: [storm] MPA Peer Connect: Publication Requested

[arkady kanevsky <[e-mail]>]

Hurray.
Thanks David.
Arkady

On Fri, Apr 8, 2011 at 5:36 PM, <[e-mail]> wrote:

>
> I have just requested publication of the MPA Peer Connect draft as a
> Proposed Standard RFC.  The next process steps will be Area Director review
> (by our AD, Dave Harrington) followed by IETF Last Call.  The PROTO writeup
> that is part of the publication request follows.
>
> Enjoy,
> --David
>
> 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 ([e-mail]) 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 satisfied 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.
>
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>



-- 
Cheers,
Arkady Kanevsky