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