Network File System (NFS) Direct Data Placement
draft-ietf-nfsv4-nfsdirect-08

IANA Last Call comments:

This document does not seem to request any actions from IANA. The IANA Considerations section appears to be directed at implementors and operators, and should probably be renamed "Port Usage Considerations."

IANA Last Call comments:

IANA is unable to determine what this document is requesting.

#1 The document appears to be trying to register NC_RDMA in some registry defined by RFC1833, but we haven't been able to locate this registry.

#2 Is the document asking for a port for RPC/RDMA ? If so, this request needs to be made explicit.

PROTO Write-up

(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 Direct Data Placement"
draft-ietf-nfsv4-nfsdirect-06.txt
---------------------------------------------------------------

Technical Summary

This document specifies a method of binding NFS on top of
the ONC RPC operation over RDMA transports (such as RDDP).

The RDMA transport for ONC RPC 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. This protocol describes the use
of direct data placement by means of server- initiated RDMA
operations into client-supplied buffers in a Chunk list for
implementations of NFS versions 2, 3, and 4 over an RDMA
transport.

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.