Re: [storm] MPA Peer Connect: Publication Requested

arkady kanevsky <arkady.kanevsky@gmail.com> Sat, 09 April 2011 13:54 UTC

Return-Path: <arkady.kanevsky@gmail.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54E83A6A9E for <storm@core3.amsl.com>; Sat, 9 Apr 2011 06:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EdGyR6L0+oE for <storm@core3.amsl.com>; Sat, 9 Apr 2011 06:54:35 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 5A79B3A6932 for <storm@ietf.org>; Sat, 9 Apr 2011 06:54:35 -0700 (PDT)
Received: by pzk30 with SMTP id 30so1915390pzk.31 for <storm@ietf.org>; Sat, 09 Apr 2011 06:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JdDcBLCJA+D0t52qLELqkZDaNLxG2N+kSxyrLzQ5Pgs=; b=KH2sN6veffazDqkky3d2TEJm/vmC1LQpoMsq6OYW/UbHqLadVZQvj5fgsHvfgKes4s /UqVCEUu2SPUMiLCtEcXW+rvdKetXh2MWDiQPHu+3FOmlwLpN2B0LWTqm/pks+6XxWpa PS83U8zZfFtumSElEeroXsN+Q13/T7LecL2UM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UbJ7/Hslh61juqr1YcZozoGQHMWWRMGmb7C78WZ+khPH7VJVW4G1RR8/UpYXz89As9 /qSlNlSRLZXHmvP+ORi9z/0gjvheDjkJoXTWxhP6TejvXeFZQaEpj//+DBD83rWDkq03 xFedW1IW8WLEKOeJXLbT9oukEr1lLKCE4jSHs=
MIME-Version: 1.0
Received: by 10.143.169.7 with SMTP id w7mr2807894wfo.186.1302357381306; Sat, 09 Apr 2011 06:56:21 -0700 (PDT)
Received: by 10.142.185.20 with HTTP; Sat, 9 Apr 2011 06:56:21 -0700 (PDT)
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E041664F53C@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E041664F53C@MX14A.corp.emc.com>
Date: Sat, 9 Apr 2011 09:56:21 -0400
Message-ID: <BANLkTin-GHjt3i9oSHSjAv_XvdR28tOnfQ@mail.gmail.com>
From: arkady kanevsky <arkady.kanevsky@gmail.com>
To: david.black@emc.com
Content-Type: multipart/alternative; boundary=000e0cd51a54155b4504a07cb50e
Cc: storm@ietf.org
Subject: Re: [storm] MPA Peer Connect: Publication Requested
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 13:54:38 -0000

Hurray.
Thanks David.
Arkady

On Fri, Apr 8, 2011 at 5:36 PM, <david.black@emc.com> 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 (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 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
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
>



-- 
Cheers,
Arkady Kanevsky