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 |