[nfsv4] NFS, RPC/RDMA Internet Drafts ready for IESG

[Spencer Shepler <[e-mail]>]

Lars,


With the completion of working group last call for these documents:

      draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt
      draft-ietf-nfsv4-nfsdirect-06.txt
      draft-ietf-nfsv4-rpcrdma-06.txt

The NFSv4 Working Group is requesting of the IESG that they be
published as RFCs.  The following, as per RFC4858, provides the detail
of shepherding the documents forward.

------------------------------------------------------------------

    (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?

       The document shepherd is Spencer Shepler.  Spencer has reviewed
       the documents and believes they are ready for publication.


    (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?

       The documents have been reviewed via two working group last
       calls:

       WG last call on Aug 17, 2006
       http://www1.ietf.org/mail-archive/web/nfsv4/current/msg03706.html

       WG last call on May 8th, 2007
       http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04322.html

       And the documents have received external review as well.

       There are no remaining concerns related to depth or breadth
       of the reviews that have occurred.


    (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 concerns exist.


    (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?

       No such concerns exist.


    (1.e)  How solid is the consensus of the interested community behind
       this document?

       There is broad consensus within the NFS and RPC communities
       in this work.

    (1.f)  Has anyone threatened an appeal or otherwise indicated  
extreme
       discontent?

       No.

    (1.g)  Has the Document Shepherd personally verified that the
       document satisfies all ID nits?

       Yes.

    (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?

       No.

       If such normative references exist, what is the strategy for  
their
       completion?

       Not applicable.

       Are there normative references that are downward
       references, as described in [RFC3967]?

       Yes.

       If so, list these downward
       references to support the Area Director in the Last Call  
procedure
       for them [RFC3967].

       RFC1094 "NFS: Network File System Protocol Specification"
       RFC1813 "NFS Version 3 Protocol Specification"

    (1.i)  Has the Document Shepherd verified that the document IANA
       consideration section exists and is consistent with the body of
       the document?

       Yes.

       If the document specifies protocol extensions, are reservations
       requested in appropriate IANA registries?  Are the IANA
       registries clearly identified?

       Yes. Yes.

       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?

       Not Applicable.

    (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?

       Yes.

    (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:


       Document Announcement Write-Up for:

       "NFS RDMA Problem Statement"
       draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt
       ---------------------------------------------------------------

       Technical Summary

         Motivation for the application of Remote Direct Memory Access
         to the NFS protocols is described.  NFS implementations
         historically incur significant overhead due to data copies on
         end-host systems, as well as other processing overhead. The
         potential benefits of RDMA to these implementations are
         explored, and the reasons why RDMA is especially well-suited to
         NFS and network file protocols in general are evaluated.

       Working Group Summary

         There is consensus in the WG to publish these documents.

       Document Quality

         As the Informative References demonstrate, this work has drawn
         on a variety of work in academia and industry and
         appropriately motivates the appropriate use of RDMA
         technologies for protocols such as NFS.




       Document Announcement Write-Up for:

       "NFS Direct Data Placement"
       draft-ietf-nfsv4-nfsdirect-06.txt

	-and-

       "RDMA Transport for ONC RPC"
       draft-ietf-nfsv4-rpcrdma-06.txt
       ---------------------------------------------------------------

       Technical Summary

         These documents specify a protocol for ONC RPC operation over
         RDMA transports (such as RDDP), and a binding of NFS atop this
         protocol.

         The RPC/RDMA protocol supports RDMA as a new transport for ONC
         RPC.  The RDMA transport binding conveys the benefits of
         efficient, bulk data transport over high speed networks, while
         providing for minimal change to RPC applications and with no
         required revision of the application RPC protocol (such as
         NFS), or the RPC protocol itself.

         An NFS binding atop the RDMA transport for ONC RPC then
         provides direct data placement for NFS data.  Direct data
         placement not only reduces the amount of data that needs to be
         copied in an NFS call, but allows much of the data movement
         over the network to be implemented in RDMA hardware. Bindings
         of NFS versions 2, 3, and 4 over an RDMA transport are
         defined.


       Working Group Summary

         There is consensus in the WG to publish these documents.

       Document Quality

         In support of this protocol definition, a variety of
         prototyping efforts have occurred in both Linux and
         OpenSolaris operating environments.  At this point, there
         exist interoperable NFS client and server implementations for
         both Linux and OpenSolaris.



_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4