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/