--- 1/draft-ietf-nfsv4-rfc3530bis-22.txt 2013-02-02 02:31:16.107916243 +0100 +++ 2/draft-ietf-nfsv4-rfc3530bis-23.txt 2013-02-02 02:31:16.579911868 +0100 @@ -1,19 +1,19 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp -Intended status: Standards Track D. Noveck, Ed. -Expires: August 2, 2013 EMC - January 29, 2013 +Obsoletes: 3530 (if approved) D. Noveck, Ed. +Intended status: Standards Track EMC +Expires: August 5, 2013 February 01, 2013 - Network File System (NFS) Version 4 Protocol - Obsoletes (if approved) - draft-ietf-nfsv4-rfc3530bis-22.txt + Network File System (NFS) Version 4 Protocol + draft-ietf-nfsv4-rfc3530bis-23.txt Abstract The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 2, 2013. + This Internet-Draft will expire on August 5, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -359,22 +359,21 @@ o There is a restructured and more complete explanation of multi- server namespace features. In particular, this explanation explicitly describes handling of inter-server referrals, even where neither migration nor replication is involved. o More liberal handling of internationalization for file names and user and group names, with the elimination of restrictions imposed by stringprep, with the recognition that rules for the forms of these name are the province of the receiving entity. - o Updating handling of domain names to reflect IDNA - [I-D.draft-ietf-idna]. + o Updating handling of domain names to reflect IDNA [RFC5891]. o Restructuring of string types to more appropriately reflect the reality of required string processing. o The previously required LIPKEY and SPKM-3 security mechanisms have been removed. o Some clarification on a client re-establishing callback information to the new server if state has been migrated. @@ -1103,21 +1102,21 @@ If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short lived connections and will improve performance for the WAN environment by eliminating the need for SYN handshakes. To date, all NFSv4 implementations are TCP based, i.e., there are none for SCTP nor UDP. UDP by itself is not sufficient as a transport for NFSv4, neither is UDP in combination with some other - mechanism (e.g., DCCP [RFC4340], NORM [RFC3940]). + mechanism (e.g., DCCP [RFC4340], NORM [RFC5740]). As noted in Section 17, the authentication model for NFSv4 has moved from machine-based to principal-based. However, this modification of the authentication model does not imply a technical requirement to move the TCP connection management model from whole machine-based to one based on a per user model. In particular, NFS over TCP client implementations have traditionally multiplexed traffic for multiple users over a common TCP connection between an NFS client and server. This has been true, regardless whether the NFS client is using AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS @@ -8407,21 +8406,21 @@ equivalence classes defined by the chosen equivalence relation. In the NFSv4 protocol, handling of issues related to internationalization with regard to normalization follows one of two basic patterns: o For strings whose function is related to other internet standards, such as server and domain naming, the normalization form defined by the appropriate internet standards is used. For server and domain naming, this involves normalization form NFKC as specified - in [I-D.draft-ietf-idna] + in [RFC5891] o For other strings, particular those passed by the server to file system implementations, normalization requirements are the province of the file system and the job of this specification is not to specify a particular form but to make sure that interoperability is maximized, even when clients and server-based file systems have different preferences. A related but distinct issue concerns string confusability. This can occur when two strings (including single-character strings) having a @@ -8453,21 +8452,21 @@ (U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK SMALL LETTER RHO (U+1D56, for good measure). NFSv4, as it does with normalization, takes a two-part approach to this issue: o For strings whose function is related to other internet standards, such as server and domain naming, any string processing to address the confusability issue is defined by the appropriate internet standards is used. For server and domain naming, this is the - responsibility of IDNA as described in [I-D.draft-ietf-idna]. + responsibility of IDNA as described in [RFC5891]. o For other strings, particularly those passed by the server to file system implementations, any such preparation requirements including the choice of how, or whether to address the confusability issue, are the responsibility of the file system to define, and for this specification to try to add its own set would add unacceptably to complexity, and make many files accessible locally and by other remote file access protocols, inaccessible by NFSv4. This specification defines how the protocol maximizes interoperability in the face of different file system @@ -14677,30 +14676,24 @@ 18.1.2. Updating Registrations The registrant is always permitted to update the point of contact field. To make any other change will require Expert Review or IESG Approval. 19. References 19.1. Normative References - [I-D.draft-ietf-idna] - Klensin, J., "Internationalized Domain Names in - Applications (IDNA): Protocol", - draft-ietf-idnabis-protocol-18 (work in progress), - January 2010. - [I-D.ietf-nfsv4-rfc3530bis-dot-x] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR - Description", draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work - in progress), Feb 2011. + Description", draft-ietf-nfsv4-rfc3530bis-dot-x-14 (work + in progress), Jan 2013. [ISO.10646-1.1993] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. @@ -14717,20 +14710,23 @@ Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009. [RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", RFC 5665, January 2010. + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, August 2010. + 19.2. Informative References [Chet] Juszczak, C., "Improving the Performance and Correctness of an NFS Server", USENIX Conference Proceedings , June 1990. [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking 2(2), pp. 122-136, April 1994. @@ -14775,24 +14771,20 @@ Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3010, December 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. - [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, - "Negative-acknowledgment (NACK)-Oriented Reliable - Multicast (NORM) Protocol", RFC 3940, November 2004. - [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4506] Eisler, M., "XDR: External Data Representation Standard", RFC 4506, May 2006. @@ -14804,20 +14796,25 @@ IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010. + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "Negative-acknowledgment (NACK)-Oriented Reliable + Multicast (NORM) Transport Protocol", RFC 5740, + November 2009. + [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. [fsync] The Open Group, "Section 'fsync()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004.