Skip to main content

Remote Direct Memory Access Transport for Remote Procedure Call
RFC 5666

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rpcrdma@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Lisa Dusseault
2010-01-19
09 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-01-19
09 Cindy Morgan [Note]: 'RFC 5666' added by Cindy Morgan
2010-01-14
09 (System) RFC published
2009-04-27
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-04-27
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-04-27
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-04-16
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-04-16
09 (System) IANA Action state changed to In Progress from On Hold
2009-01-22
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-01-22
09 (System) IANA Action state changed to On Hold from In Progress
2009-01-22
09 (System) IANA Action state changed to In Progress
2009-01-22
09 Amy Vezza IESG state changed to Approved-announcement sent
2009-01-22
09 Amy Vezza IESG has approved the document
2009-01-22
09 Amy Vezza Closed "Approve" ballot
2009-01-22
09 Lars Eggert State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert
2009-01-19
09 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault
2008-12-04
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-12-04
09 (System) New version available: draft-ietf-nfsv4-rpcrdma-09.txt
2008-06-26
09 Lisa Dusseault
[Ballot comment]
This comment is a revision of what was originally a DISCUSS which I held while trying to understand the authentication model for this …
[Ballot comment]
This comment is a revision of what was originally a DISCUSS which I held while trying to understand the authentication model for this document.

I never quite managed to understand the authentication model of combining RDMA, RPC and NFS as described in this document.  I thought that use of this suite would be in practice be limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers --  I can see this being useful in contexts where you basically want superuser access to a file system.  However, the authors inform me that this can be used securely over the Internet. 

What I don't understand is how implementations know what authentication to prompt for, how the user knows what domain's authentication information is being asked for, how to tie authentication at different layers together, and how to tie authenticated identities at this layer to NFS ACE principals. These may well all be implementation problems, and I'm clearing my DISCUSS because I can't be sure that they aren't.

I had been thinking of an applicability statement, but now that I've learned that this ought to be securely usable on the Internet, I no longer think an applicability statement would be helpful.
2008-06-26
09 Lisa Dusseault
[Ballot comment]
I never quite managed to understand the authentication model of combining RDMA, RPC and NFS as described in this document.  I thought that …
[Ballot comment]
I never quite managed to understand the authentication model of combining RDMA, RPC and NFS as described in this document.  I thought that use of this suite would be in practice be limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers --  I can see this being useful in contexts where you basically want superuser access to a file system.  However, the authors inform me that this can be used securely over the Internet. 

What I don't understand is how implementations know what authentication to prompt for, and how to tie authentication at different layers together, and how to tie authentication at this layer to NFS ACE principals. However, I agree with the implied response that this is an implementation problem.

I had been thinking of an applicability statement, but now that I've learned that this ought to be securely usable on the Internet, I no longer think an applicability statement would be helpful.
2008-06-26
09 Lisa Dusseault
[Ballot discuss]
IANA has questions.  RPC numbers are assigned differently than specified.  The IANA Considerations needs work. I agreed to hold "the IANA discuss" on …
[Ballot discuss]
IANA has questions.  RPC numbers are assigned differently than specified.  The IANA Considerations needs work. I agreed to hold "the IANA discuss" on the call.
2008-06-26
09 Chris Newman [Ballot comment]
I support Lisa's discuss comment.
2008-06-26
09 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-04-25
09 (System) Removed from agenda for telechat - 2008-04-24
2008-04-24
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-04-24
09 Lisa Dusseault
[Ballot discuss]
I am getting an early DISCUSS in to see if some answers can clear this up quickly.  I hope to revise this DISCUSS …
[Ballot discuss]
I am getting an early DISCUSS in to see if some answers can clear this up quickly.  I hope to revise this DISCUSS even before the call as I understand it better. 

Is the applicability of RDMA, RPC and NFS as described in this document limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers?  I can see this being useful in contexts where you basically want superuser access to a file system.

If the applicability is not limited, how is this appropriate for Internet or end-user usage, especially considering the limited authentication mechanisms and lack of information on mapping to NFS ACEs?

---

ETA: IANA has questions.  RPC numbers are assigned differently than specified.  The IANA Considerations needs work. I agreed to hold "the IANA discuss" on the call.
2008-04-24
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-04-24
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-04-24
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-04-24
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-04-23
09 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-04-23
09 Lisa Dusseault
[Ballot discuss]
I am getting an early DISCUSS in to see if some answers can clear this up quickly.  I hope to revise this DISCUSS …
[Ballot discuss]
I am getting an early DISCUSS in to see if some answers can clear this up quickly.  I hope to revise this DISCUSS even before the call as I understand it better. 

Is the applicability of RDMA, RPC and NFS as described in this document limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers?  I can see this being useful in contexts where you basically want superuser access to a file system.

If the applicability is not limited, how is this appropriate for Internet or end-user usage, especially considering the limited authentication mechanisms and lack of information on mapping to NFS ACEs?
2008-04-23
09 Lisa Dusseault [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault
2008-04-23
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-04-23
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-04-23
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-04-16
09 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Lars Eggert
2008-04-16
09 Lars Eggert Placed on agenda for telechat - 2008-04-24 by Lars Eggert
2008-04-16
09 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2008-04-16
09 Lars Eggert Ballot has been issued by Lars Eggert
2008-04-16
09 Lars Eggert Created "Approve" ballot
2008-04-16
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-04-16
08 (System) New version available: draft-ietf-nfsv4-rpcrdma-08.txt
2008-04-03
09 Lars Eggert State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lars Eggert
2008-04-03
09 Lars Eggert Revision needed to address last-call comments.
2008-03-26
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-03-25
09 Amanda Baber
IANA Last Call comments:

IANA has questions.

This document appears to be requesting a registration in the
protocol name (r_nc_proto) registry at
http://www.iana.org/assignments/rpcbind-transport-parameters
This registry …
IANA Last Call comments:

IANA has questions.

This document appears to be requesting a registration in the
protocol name (r_nc_proto) registry at
http://www.iana.org/assignments/rpcbind-transport-parameters
This registry was apparently created by RFC 1833, which does
not specify registration procedures. We need the IESG to
determine what those registration procedures are.

This document also appears to be requesting a SUN RPC number.
Per http://www.iana.org/assignments/sun-rpc-numbers (which
contains instructions but no registry), these numbers are
assigned by Sun, not by IANA. What, if anything, should IANA
do? The IANA Considerations state that "ideally," IANA will
create this registry, but does not actually instruct IANA to
do so, and does not appear to address the fact that these
assignments are currently made by Sun.

A document from 2005, draft-ietf-nfsv4-rpc-iana-03.txt,
appears to have been intended to transfer the number
assignments to IANA, but it was never approved.
2008-03-05
09 Amy Vezza Last call sent
2008-03-05
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-03-05
09 Lars Eggert State Changes to Last Call Requested from Waiting for AD Go-Ahead::AD Followup by Lars Eggert
2008-03-05
09 Lars Eggert Last Call was requested by Lars Eggert
2008-03-05
09 Lars Eggert Repeat IETF last call, now that draft-ietf-nfsv4-nfs-rdma-problem-statement has been approved.
2008-02-24
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-02-24
07 (System) New version available: draft-ietf-nfsv4-rpcrdma-07.txt
2007-12-17
09 Lars Eggert State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lars Eggert
2007-11-20
09 Lars Eggert Waiting for the approval of draft-ietf-nfsv4-nfs-rdma-problem-statement.
2007-10-17
09 Amanda Baber
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Protocol name (r_nc_proto)" registry
located at
http://www.iana.org/assignments/rpcbind-transport-parameters: …
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Protocol name (r_nc_proto)" registry
located at
http://www.iana.org/assignments/rpcbind-transport-parameters:

value Name              Value        Reference
--------------------  ---------      ---------
NC_RDMA              "rdma"        [RFC-nfsv4-rpcrdma-06]

We understand the above to be the only IANA Actions for this
document.
2007-10-12
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-10-11
09 Lars Eggert Removed from agenda until the IETF LC and IESG approval of the requirements document (draft-ietf-nfsv4-nfs-rdma-problem-statement) has occurred.
2007-10-11
09 Lars Eggert Removed from agenda for telechat - 2007-10-18 by Lars Eggert
2007-10-09
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom.
2007-09-29
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2007-09-29
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2007-09-28
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-09-28
09 Lars Eggert Putting this tentatively on the agenda for Oct 18.
2007-09-28
09 Lars Eggert Placed on agenda for telechat - 2007-10-18 by Lars Eggert
2007-09-28
09 Lars Eggert AD review performed during WGLC.
2007-09-28
09 Lars Eggert State Changes to Last Call Requested from AD Evaluation by Lars Eggert
2007-09-28
09 Lars Eggert Last Call was requested by Lars Eggert
2007-09-28
09 (System) Ballot writeup text was added
2007-09-28
09 (System) Last call text was added
2007-09-28
09 (System) Ballot approval text was added
2007-09-28
09 Lars Eggert [Note]: 'Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)' added by Lars Eggert
2007-09-28
09 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2007-09-28
09 Lars Eggert State Change Notice email list have been change to nfsv4-chairs@tools.ietf.org, draft-ietf-nfsv4-rpcrdma@tools.ietf.org from nfsv4-chairs@tools.ietf.org
2007-09-27
09 Dinara Suleymanova
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, …
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:

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

Technical Summary

This documents specifies a protocol for ONC RPC operation over
RDMA transports (such as RDDP).

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.

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.
2007-09-27
09 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2007-09-27
09 Dinara Suleymanova Intended Status has been changed to Proposed Standard from None
2007-06-30
06 (System) New version available: draft-ietf-nfsv4-rpcrdma-06.txt
2007-05-09
09 (System) State Changes to AD is watching from Dead by system
2007-05-08
05 (System) New version available: draft-ietf-nfsv4-rpcrdma-05.txt
2007-04-26
09 (System) State Changes to Dead from AD is watching by system
2007-04-26
09 (System) Document has expired
2006-10-23
04 (System) New version available: draft-ietf-nfsv4-rpcrdma-04.txt
2006-08-22
09 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-06-23
03 (System) New version available: draft-ietf-nfsv4-rpcrdma-03.txt
2005-10-27
02 (System) New version available: draft-ietf-nfsv4-rpcrdma-02.txt
2005-02-21
01 (System) New version available: draft-ietf-nfsv4-rpcrdma-01.txt
2004-07-02
00 (System) New version available: draft-ietf-nfsv4-rpcrdma-00.txt