draft-ietf-nfsv4-rfc3530bis-21.txt | draft-ietf-nfsv4-rfc3530bis-22.txt | |||
---|---|---|---|---|
NFSv4 T. Haynes, Ed. | NFSv4 T. Haynes, Ed. | |||
Internet-Draft NetApp | Internet-Draft NetApp | |||
Intended status: Standards Track D. Noveck, Ed. | Intended status: Standards Track D. Noveck, Ed. | |||
Expires: May 14, 2013 EMC | Expires: August 2, 2013 EMC | |||
November 10, 2012 | January 29, 2013 | |||
Network File System (NFS) Version 4 Protocol | Network File System (NFS) Version 4 Protocol - Obsoletes (if approved) | |||
draft-ietf-nfsv4-rfc3530bis-21.txt | draft-ietf-nfsv4-rfc3530bis-22.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, | |||
attention has been applied to making NFS version 4 operate well in an | attention has been applied to making NFS version 4 operate well in an | |||
Internet environment. | Internet environment. | |||
This document, together with the companion XDR description document, | This document, together with the companion XDR description document, | |||
RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 | RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version | |||
protocol. | 4 protocol. | |||
Requirements Language | Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [1]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 May 14, 2013. | This Internet-Draft will expire on August 2, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 3, line 9 | skipping to change at page 3, line 9 | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 9 | 1.1. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 9 | |||
1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 9 | 1.2. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 10 | |||
1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 11 | 1.3. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 11 | |||
1.4. Inconsistencies of this Document with the companion | 1.4. Inconsistencies of this Document with the companion | |||
document NFS Version 4 Protocol . . . . . . . . . . . . 11 | document NFS Version 4 Protocol . . . . . . . . . . . . 11 | |||
1.5. Overview of NFSv4 Features . . . . . . . . . . . . . . . 12 | 1.5. Overview of NFSv4 Features . . . . . . . . . . . . . . . 12 | |||
1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12 | 1.5.1. RPC and Security . . . . . . . . . . . . . . . . . . 12 | |||
1.5.2. Procedure and Operation Structure . . . . . . . . . 12 | 1.5.2. Procedure and Operation Structure . . . . . . . . . 12 | |||
1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13 | 1.5.3. Filesystem Model . . . . . . . . . . . . . . . . . . 13 | |||
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15 | 1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 15 | |||
1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15 | 1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 15 | |||
1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 | 1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 | |||
skipping to change at page 7, line 48 | skipping to change at page 7, line 48 | |||
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 272 | 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 272 | |||
15.25. Operation 25: READ - Read from File . . . . . . . . . . 273 | 15.25. Operation 25: READ - Read from File . . . . . . . . . . 273 | |||
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 275 | 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 275 | |||
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 279 | 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 279 | |||
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 280 | 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 280 | |||
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 282 | 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 282 | |||
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 284 | 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 284 | |||
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 285 | 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 285 | |||
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 286 | 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 286 | |||
15.33. Operation 33: SECINFO - Obtain Available Security . . . 287 | 15.33. Operation 33: SECINFO - Obtain Available Security . . . 287 | |||
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 290 | 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 291 | |||
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 293 | 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 293 | |||
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 297 | 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 297 | |||
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 300 | 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 300 | |||
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 302 | 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 302 | |||
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner | 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner | |||
State . . . . . . . . . . . . . . . . . . . . . . . . . 306 | State . . . . . . . . . . . . . . . . . . . . . . . . . 306 | |||
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 307 | 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 307 | |||
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 308 | 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 308 | |||
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 308 | 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 308 | |||
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 308 | 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 308 | |||
skipping to change at page 8, line 23 | skipping to change at page 8, line 23 | |||
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback | 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback | |||
Operation . . . . . . . . . . . . . . . . . . . . . 312 | Operation . . . . . . . . . . . . . . . . . . . . . 312 | |||
17. Security Considerations . . . . . . . . . . . . . . . . . . . 313 | 17. Security Considerations . . . . . . . . . . . . . . . . . . . 313 | |||
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 315 | 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 315 | |||
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 315 | 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 315 | |||
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 316 | 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 316 | |||
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 316 | 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 316 | |||
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 316 | 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 316 | |||
19.1. Normative References . . . . . . . . . . . . . . . . . . 316 | 19.1. Normative References . . . . . . . . . . . . . . . . . . 316 | |||
19.2. Informative References . . . . . . . . . . . . . . . . . 317 | 19.2. Informative References . . . . . . . . . . . . . . . . . 317 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 319 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 320 | |||
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 320 | Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 320 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 320 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321 | |||
1. Introduction | 1. Introduction | |||
1.1. Changes since RFC 3530 | 1.1. Changes since RFC 3530 | |||
This document, together with the companion XDR description document | This document, together with the companion XDR description document | |||
[2], obsoletes RFC 3530 [11] as the authoritative document describing | [I-D.ietf-nfsv4-rfc3530bis-dot-x], obsoletes RFC 3530 [RFC3530] as | |||
NFSv4. It does not introduce any over-the-wire protocol changes, in | the authoritative document describing NFSv4. It does not introduce | |||
the sense that previously valid requests requests remain valid. | any over-the-wire protocol changes, in the sense that previously | |||
However, some requests previously defined as invalid, although not | valid requests requests remain valid. However, some requests | |||
generally rejected, are now explicitly allowed, in that | previously defined as invalid, although not generally rejected, are | |||
internationalization handling has been generalized and liberalized. | now explicitly allowed, in that internationalization handling has | |||
The main changes from RFC 3530 are: | been generalized and liberalized. The main changes from RFC 3530 | |||
are: | ||||
o The XDR definition has been moved to a companion document [2] | o The XDR definition has been moved to a companion document | |||
[I-D.ietf-nfsv4-rfc3530bis-dot-x] | ||||
o Updates for the latest IETF intellectual property statements | o Updates for the latest IETF intellectual property statements | |||
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 [3]. | o Updating handling of domain names to reflect IDNA | |||
[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. | |||
o A third edge case was added for Courtesy locks and network | o A third edge case was added for Courtesy locks and network | |||
partitions. | partitions. | |||
o The definition of stateid was strengthened. | o The definition of stateid was strengthened. | |||
1.2. Changes since RFC 3010 | 1.2. Changes since RFC 3010 | |||
This definition of the NFSv4 protocol replaces or obsoletes the | This definition of the NFSv4 protocol replaces or obsoletes the | |||
definition present in [12]. While portions of the two documents have | definition present in [RFC3010]. While portions of the two documents | |||
remained the same, there have been substantive changes in others. | have remained the same, there have been substantive changes in | |||
others. The changes made between [RFC3010] and this document | ||||
The changes made between [12] and this document represent | represent implementation experience and further review of the | |||
implementation experience and further review of the protocol. While | protocol. While some modifications were made for ease of | |||
some modifications were made for ease of implementation or | implementation or clarification, most updates represent errors or | |||
clarification, most updates represent errors or situations where the | situations where the [RFC3010] definition were untenable. | |||
[12] definition were untenable. | ||||
The following list is not all inclusive of all changes but presents | The following list is not all inclusive of all changes but presents | |||
some of the most notable changes or additions made: | some of the most notable changes or additions made: | |||
o The state model has added an open_owner4 identifier. This was | o The state model has added an open_owner4 identifier. This was | |||
done to accommodate Posix based clients and the model they use for | done to accommodate Posix based clients and the model they use for | |||
file locking. For Posix clients, an open_owner4 would correspond | file locking. For Posix clients, an open_owner4 would correspond | |||
to a file descriptor potentially shared amongst a set of processes | to a file descriptor potentially shared amongst a set of processes | |||
and the lock_owner4 identifier would correspond to a process that | and the lock_owner4 identifier would correspond to a process that | |||
is locking a file. | is locking a file. | |||
skipping to change at page 11, line 11 | skipping to change at page 11, line 17 | |||
o Remove use of the pathname4 data type from LOOKUP and OPEN in | o Remove use of the pathname4 data type from LOOKUP and OPEN in | |||
favor of having the client construct a sequence of LOOKUP | favor of having the client construct a sequence of LOOKUP | |||
operations to achieve the same effect. | operations to achieve the same effect. | |||
o Clarification of the internationalization issues and adoption of | o Clarification of the internationalization issues and adoption of | |||
the new stringprep profile framework. | the new stringprep profile framework. | |||
1.3. NFS Version 4 Goals | 1.3. NFS Version 4 Goals | |||
The NFSv4 protocol is a further revision of the NFS protocol defined | The NFSv4 protocol is a further revision of the NFS protocol defined | |||
already by versions 2 [13] and 3 [14]. It retains the essential | already by versions 2 [RFC1094] and 3 [RFC1813]. It retains the | |||
characteristics of previous versions: design for easy recovery, | essential characteristics of previous versions: design for easy | |||
independent of transport protocols, operating systems and | recovery, independent of transport protocols, operating systems and | |||
filesystems, simplicity, and good performance. The NFSv4 revision | filesystems, simplicity, and good performance. The NFSv4 revision | |||
has the following goals: | has the following goals: | |||
o Improved access and good performance on the Internet. | o Improved access and good performance on the Internet. | |||
The protocol is designed to transit firewalls easily, perform well | The protocol is designed to transit firewalls easily, perform well | |||
where latency is high and bandwidth is low, and scale to very | where latency is high and bandwidth is low, and scale to very | |||
large numbers of clients per server. | large numbers of clients per server. | |||
o Strong security with negotiation built into the protocol. | o Strong security with negotiation built into the protocol. | |||
skipping to change at page 11, line 45 | skipping to change at page 11, line 51 | |||
or operating system over another. | or operating system over another. | |||
o Designed for protocol extensions. | o Designed for protocol extensions. | |||
The protocol is designed to accept standard extensions that do not | The protocol is designed to accept standard extensions that do not | |||
compromise backward compatibility. | compromise backward compatibility. | |||
1.4. Inconsistencies of this Document with the companion document NFS | 1.4. Inconsistencies of this Document with the companion document NFS | |||
Version 4 Protocol | Version 4 Protocol | |||
[2], NFS Version 4 Protocol, contains the definitions in XDR | [I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains | |||
description language of the constructs used by the protocol. Inside | the definitions in XDR description language of the constructs used by | |||
this document, several of the constructs are reproduced for purposes | the protocol. Inside this document, several of the constructs are | |||
of explanation. The reader is warned of the possibility of errors in | reproduced for purposes of explanation. The reader is warned of the | |||
the reproduced constructs outside of [2]. For any part of the | possibility of errors in the reproduced constructs outside of | |||
document that is inconsistent with [2], [2] is to be considered | [I-D.ietf-nfsv4-rfc3530bis-dot-x]. For any part of the document that | |||
authoritative. | is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x], | |||
[I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative. | ||||
1.5. Overview of NFSv4 Features | 1.5. Overview of NFSv4 Features | |||
To provide a reasonable context for the reader, the major features of | To provide a reasonable context for the reader, the major features of | |||
NFSv4 protocol will be reviewed in brief. This will be done to | NFSv4 protocol will be reviewed in brief. This will be done to | |||
provide an appropriate context for both the reader who is familiar | provide an appropriate context for both the reader who is familiar | |||
with the previous versions of the NFS protocol and the reader that is | with the previous versions of the NFS protocol and the reader that is | |||
new to the NFS protocols. For the reader new to the NFS protocols, | new to the NFS protocols. For the reader new to the NFS protocols, | |||
some fundamental knowledge is still expected. The reader should be | some fundamental knowledge is still expected. The reader should be | |||
familiar with the XDR and RPC protocols as described in [4] and [15]. | familiar with the XDR and RPC protocols as described in [RFC5531] and | |||
A basic knowledge of filesystems and distributed filesystems is | [RFC4506]. A basic knowledge of filesystems and distributed | |||
expected as well. | filesystems is expected as well. | |||
1.5.1. RPC and Security | 1.5.1. RPC and Security | |||
As with previous versions of NFS, the External Data Representation | As with previous versions of NFS, the External Data Representation | |||
(XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 | (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 | |||
protocol are those defined in [4] and [15]. To meet end to end | protocol are those defined in [RFC5531] and [RFC4506]. To meet end | |||
security requirements, the RPCSEC_GSS framework [5] will be used to | to end security requirements, the RPCSEC_GSS framework [RFC2203] will | |||
extend the basic RPC security. With the use of RPCSEC_GSS, various | be used to extend the basic RPC security. With the use of | |||
mechanisms can be provided to offer authentication, integrity, and | RPCSEC_GSS, various mechanisms can be provided to offer | |||
privacy to the NFS version 4 protocol. Kerberos V5 will be used as | authentication, integrity, and privacy to the NFS version 4 protocol. | |||
described in [16] to provide one security framework. With the use of | Kerberos V5 will be used as described in [RFC4121] to provide one | |||
RPCSEC_GSS, other mechanisms may also be specified and used for NFS | security framework. With the use of RPCSEC_GSS, other mechanisms may | |||
version 4 security. | also be specified and used for NFS version 4 security. | |||
To enable in-band security negotiation, the NFSv4 protocol has added | To enable in-band security negotiation, the NFSv4 protocol has added | |||
a new operation which provides the client a method of querying the | a new operation which provides the client a method of querying the | |||
server about its policies regarding which security mechanisms must be | server about its policies regarding which security mechanisms must be | |||
used for access to the server's filesystem resources. With this, the | used for access to the server's filesystem resources. With this, the | |||
client can securely match the security mechanism that meets the | client can securely match the security mechanism that meets the | |||
policies specified at both the client and server. | policies specified at both the client and server. | |||
1.5.2. Procedure and Operation Structure | 1.5.2. Procedure and Operation Structure | |||
skipping to change at page 14, line 12 | skipping to change at page 14, line 17 | |||
filehandle being provided by the server and can be prepared to deal | filehandle being provided by the server and can be prepared to deal | |||
with the semantics of each. | with the semantics of each. | |||
1.5.3.2. Attribute Types | 1.5.3.2. Attribute Types | |||
The NFSv4 protocol has a rich and extensible file object attribute | The NFSv4 protocol has a rich and extensible file object attribute | |||
structure, which is divided into REQUIRED, RECOMMENDED, and named | structure, which is divided into REQUIRED, RECOMMENDED, and named | |||
attributes (see Section 5). | attributes (see Section 5). | |||
Several (but not all) of the REQUIRED attributes are derived from the | Several (but not all) of the REQUIRED attributes are derived from the | |||
attributes of NFSv3 (see definition of the fattr3 data type in [14]). | attributes of NFSv3 (see definition of the fattr3 data type in | |||
An example of a REQUIRED attribute is the file object's type | [RFC1813]). An example of a REQUIRED attribute is the file object's | |||
(Section 5.8.1.2) so that regular files can be distinguished from | type (Section 5.8.1.2) so that regular files can be distinguished | |||
directories (also known as folders in some operating environments) | from directories (also known as folders in some operating | |||
and other types of objects. REQUIRED attributes are discussed in | environments) and other types of objects. REQUIRED attributes are | |||
Section 5.1. | discussed in Section 5.1. | |||
An example of the RECOMMENDED attributes is an acl. This attribute | An example of the RECOMMENDED attributes is an acl. This attribute | |||
defines an Access Control List (ACL) on a file object ((Section 6). | defines an Access Control List (ACL) on a file object ((Section 6). | |||
An ACL provides file access control beyond the model used in NFSv3. | An ACL provides file access control beyond the model used in NFSv3. | |||
The ACL definition allows for specification of specific sets of | The ACL definition allows for specification of specific sets of | |||
permissions for individual users and groups. In addition, ACL | permissions for individual users and groups. In addition, ACL | |||
inheritance allows propagation of access permissions and restriction | inheritance allows propagation of access permissions and restriction | |||
down a directory tree as file system objects are created. | down a directory tree as file system objects are created. | |||
RECOMMENDED attributes are discussed in Section 5.2. | RECOMMENDED attributes are discussed in Section 5.2. | |||
skipping to change at page 18, line 20 | skipping to change at page 18, line 23 | |||
server for a specific open-owner or lock-owner/open-owner pair for | server for a specific open-owner or lock-owner/open-owner pair for | |||
a specific file and type of lock. | a specific file and type of lock. | |||
Verifier: A 64-bit quantity generated by the client that the server | Verifier: A 64-bit quantity generated by the client that the server | |||
can use to determine if the client has restarted and lost all | can use to determine if the client has restarted and lost all | |||
previous lock state. | previous lock state. | |||
2. Protocol Data Types | 2. Protocol Data Types | |||
The syntax and semantics to describe the data types of the NFS | The syntax and semantics to describe the data types of the NFS | |||
version 4 protocol are defined in the XDR [15] and RPC [4] documents. | version 4 protocol are defined in the XDR [RFC4506] and RPC [RFC5531] | |||
The next sections build upon the XDR data types to define types and | documents. The next sections build upon the XDR data types to define | |||
structures specific to this protocol. | types and structures specific to this protocol. | |||
2.1. Basic Data Types | 2.1. Basic Data Types | |||
These are the base NFSv4 data types. | These are the base NFSv4 data types. | |||
+----------------------+--------------------------------------------+ | +----------------------+--------------------------------------------+ | |||
| Data Type | Definition | | | Data Type | Definition | | |||
+----------------------+--------------------------------------------+ | +----------------------+--------------------------------------------+ | |||
| int32_t | typedef int int32_t; | | | int32_t | typedef int int32_t; | | |||
| uint32_t | typedef unsigned int uint32_t; | | | uint32_t | typedef unsigned int uint32_t; | | |||
skipping to change at page 19, line 18 | skipping to change at page 19, line 21 | |||
| | Various defined file types. | | | | Various defined file types. | | |||
| nfsstat4 | enum nfsstat4; | | | nfsstat4 | enum nfsstat4; | | |||
| | Return value for operations. | | | | Return value for operations. | | |||
| offset4 | typedef uint64_t offset4; | | | offset4 | typedef uint64_t offset4; | | |||
| | Various offset designations (READ, WRITE, | | | | Various offset designations (READ, WRITE, | | |||
| | LOCK, COMMIT). | | | | LOCK, COMMIT). | | |||
| qop4 | typedef uint32_t qop4; | | | qop4 | typedef uint32_t qop4; | | |||
| | Quality of protection designation in | | | | Quality of protection designation in | | |||
| | SECINFO. | | | | SECINFO. | | |||
| sec_oid4 | typedef opaque sec_oid4<>; | | | sec_oid4 | typedef opaque sec_oid4<>; | | |||
| | Security Object Identifier. The sec_oid4 | | | | Security Object Identifier. The sec_oid4 | | |||
| | data type is not really opaque. Instead | | | | data type is not really opaque. Instead it | | |||
| | it contains an ASN.1 OBJECT IDENTIFIER as | | | | contains an ASN.1 OBJECT IDENTIFIER as | | |||
| | used by GSS-API in the mech_type argument | | | | used by GSS-API in the mech_type argument | | |||
| | to GSS_Init_sec_context. See [6] for | | | | to GSS_Init_sec_context. See [RFC2743] for | | |||
| | details. | | | | details. | | |||
| seqid4 | typedef uint32_t seqid4; | | | seqid4 | typedef uint32_t seqid4; | | |||
| | Sequence identifier used for file locking. | | | | Sequence identifier used for file locking. | | |||
| utf8string | typedef opaque utf8string<>; | | | utf8string | typedef opaque utf8string<>; | | |||
| | UTF-8 encoding for strings. | | | | UTF-8 encoding for strings. | | |||
| utf8_expected | typedef utf8string utf8_expected; | | | utf8_expected | typedef utf8string utf8_expected; | | |||
| | String expected to be UTF-8 but no | | | | String expected to be UTF-8 but no | | |||
| | validation | | | | validation | | |||
| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | |||
| | String SHOULD be sent UTF-8 and SHOULD be | | | | String SHOULD be sent UTF-8 and SHOULD be | | |||
skipping to change at page 23, line 4 | skipping to change at page 23, line 4 | |||
struct clientaddr4 { | struct clientaddr4 { | |||
/* see struct rpcb in RFC 1833 */ | /* see struct rpcb in RFC 1833 */ | |||
string r_netid<>; /* network id */ | string r_netid<>; /* network id */ | |||
string r_addr<>; /* universal address */ | string r_addr<>; /* universal address */ | |||
}; | }; | |||
The clientaddr4 structure is used as part of the SETCLIENTID | The clientaddr4 structure is used as part of the SETCLIENTID | |||
operation to either specify the address of the client that is using a | operation to either specify the address of the client that is using a | |||
client ID or as part of the callback registration. The r_netid and | client ID or as part of the callback registration. The r_netid and | |||
r_addr fields respectively contain a netid and uaddr. The netid and | r_addr fields respectively contain a netid and uaddr. The netid and | |||
uaddr concepts are defined in [7]. The netid and uaddr formats for | uaddr concepts are defined in [RFC5665]. The netid and uaddr formats | |||
TCP over IPv4 and TCP over IPv6 are defined in [7], specifically | for TCP over IPv4 and TCP over IPv6 are defined in [RFC5665], | |||
Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4. | specifically Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4. | |||
2.2.11. cb_client4 | 2.2.11. cb_client4 | |||
struct cb_client4 { | struct cb_client4 { | |||
unsigned int cb_program; | unsigned int cb_program; | |||
clientaddr4 cb_location; | clientaddr4 cb_location; | |||
}; | }; | |||
This structure is used by the client to inform the server of its call | This structure is used by the client to inform the server of its call | |||
back address; includes the program number and client address. | back address; includes the program number and client address. | |||
skipping to change at page 24, line 39 | skipping to change at page 24, line 39 | |||
between the client and server. For the client, this data structure | between the client and server. For the client, this data structure | |||
is read-only. The server is required to increment the seqid field | is read-only. The server is required to increment the seqid field | |||
monotonically at each transition of the stateid. This is important | monotonically at each transition of the stateid. This is important | |||
since the client will inspect the seqid in OPEN stateids to determine | since the client will inspect the seqid in OPEN stateids to determine | |||
the order of OPEN processing done by the server. | the order of OPEN processing done by the server. | |||
3. RPC and Security Flavor | 3. RPC and Security Flavor | |||
The NFSv4 protocol is a Remote Procedure Call (RPC) application that | The NFSv4 protocol is a Remote Procedure Call (RPC) application that | |||
uses RPC version 2 and the corresponding eXternal Data Representation | uses RPC version 2 and the corresponding eXternal Data Representation | |||
(XDR) as defined in [4] and [15]. The RPCSEC_GSS security flavor as | (XDR) as defined in [RFC5531] and [RFC4506]. The RPCSEC_GSS security | |||
defined in [5] MUST be implemented as the mechanism to deliver | flavor as defined in [RFC2203] MUST be implemented as the mechanism | |||
stronger security for the NFSv4 protocol. However, deployment of | to deliver stronger security for the NFSv4 protocol. However, | |||
RPCSEC_GSS is optional. | deployment of RPCSEC_GSS is optional. | |||
3.1. Ports and Transports | 3.1. Ports and Transports | |||
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The | Historically, NFSv2 and NFSv3 servers have resided on port 2049. The | |||
registered port 2049 [17] for the NFS protocol SHOULD be the default | registered port 2049 [RFC3232] for the NFS protocol SHOULD be the | |||
configuration. Using the registered port for NFS services means the | default configuration. Using the registered port for NFS services | |||
NFS client will not need to use the RPC binding protocols as | means the NFS client will not need to use the RPC binding protocols | |||
described in [18]; this will allow NFS to transit firewalls. | as described in [RFC1833]; this will allow NFS to transit firewalls. | |||
Where an NFSv4 implementation supports operation over the IP network | Where an NFSv4 implementation supports operation over the IP network | |||
protocol, the supported transports between NFS and IP MUST be among | protocol, the supported transports between NFS and IP MUST be among | |||
the IETF-approved congestion control transport protocols, which | the IETF-approved congestion control transport protocols, which | |||
include TCP and SCTP. To enhance the possibilities for | include TCP and SCTP. To enhance the possibilities for | |||
interoperability, an NFSv4 implementation MUST support operation over | interoperability, an NFSv4 implementation MUST support operation over | |||
the TCP transport protocol, at least until such time as a standards | the TCP transport protocol, at least until such time as a standards | |||
track RFC revises this requirement to use a different IETF-approved | track RFC revises this requirement to use a different IETF-approved | |||
congestion control transport protocol. | congestion control transport protocol. | |||
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 [19], NORM [20]). | mechanism (e.g., DCCP [RFC4340], NORM [RFC3940]). | |||
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 | |||
over TCP server implementations have assumed such a model and thus | over TCP server implementations have assumed such a model and thus | |||
scale the implementation of TCP connection management in proportion | scale the implementation of TCP connection management in proportion | |||
to the number of expected client machines. It is intended that NFSv4 | to the number of expected client machines. It is intended that NFSv4 | |||
will not modify this connection management model. NFSv4 clients that | will not modify this connection management model. NFSv4 clients that | |||
violate this assumption can expect scaling issues on the server and | violate this assumption can expect scaling issues on the server and | |||
hence reduced service. | hence reduced service. | |||
Note that for various timers, the client and server should avoid | Note that for various timers, the client and server should avoid | |||
inadvertent synchronization of those timers. For further discussion | inadvertent synchronization of those timers. For further discussion | |||
of the general issue refer to [21]. | of the general issue refer to [Floyd]. | |||
3.1.1. Client Retransmission Behavior | 3.1.1. Client Retransmission Behavior | |||
When processing a request received over a reliable transport such as | When processing a request received over a reliable transport such as | |||
TCP, the NFSv4 server MUST NOT silently drop the request, except if | TCP, the NFSv4 server MUST NOT silently drop the request, except if | |||
the transport connection has been broken. Given such a contract | the transport connection has been broken. Given such a contract | |||
between NFSv4 clients and servers, clients MUST NOT retry a request | between NFSv4 clients and servers, clients MUST NOT retry a request | |||
unless one or both of the following are true: | unless one or both of the following are true: | |||
o The transport connection has been broken | o The transport connection has been broken | |||
skipping to change at page 26, line 32 | skipping to change at page 26, line 32 | |||
or it can break the transport connection and reconnect before re- | or it can break the transport connection and reconnect before re- | |||
sending the original request. | sending the original request. | |||
For callbacks from the server to the client, the same rules apply, | For callbacks from the server to the client, the same rules apply, | |||
but the server doing the callback becomes the client, and the client | but the server doing the callback becomes the client, and the client | |||
receiving the callback becomes the server. | receiving the callback becomes the server. | |||
3.2. Security Flavors | 3.2. Security Flavors | |||
Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, | Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, | |||
AUTH_DH, and AUTH_KRB4 as security flavors. With [5] an additional | AUTH_DH, and AUTH_KRB4 as security flavors. With [RFC2203] an | |||
security flavor of RPCSEC_GSS has been introduced which uses the | additional security flavor of RPCSEC_GSS has been introduced which | |||
functionality of GSS-API [6]. This allows for the use of various | uses the functionality of GSS-API [RFC2743]. This allows for the use | |||
security mechanisms by the RPC layer without the additional | of various security mechanisms by the RPC layer without the | |||
implementation overhead of adding RPC security flavors. For NFSv4, | additional implementation overhead of adding RPC security flavors. | |||
the RPCSEC_GSS security flavor MUST be used to enable the mandatory | For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the | |||
security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and | mandatory security mechanism. Other flavors, such as, AUTH_NONE, | |||
AUTH_DH MAY be implemented as well. | AUTH_SYS, and AUTH_DH MAY be implemented as well. | |||
3.2.1. Security mechanisms for NFSv4 | 3.2.1. Security mechanisms for NFSv4 | |||
The use of RPCSEC_GSS requires selection of: mechanism, quality of | The use of RPCSEC_GSS requires selection of: mechanism, quality of | |||
protection, and service (authentication, integrity, privacy). The | protection, and service (authentication, integrity, privacy). The | |||
remainder of this document will refer to these three parameters of | remainder of this document will refer to these three parameters of | |||
the RPCSEC_GSS security as the security triple. | the RPCSEC_GSS security as the security triple. | |||
3.2.1.1. Kerberos V5 as a security triple | 3.2.1.1. Kerberos V5 as a security triple | |||
The Kerberos V5 GSS-API mechanism as described in [16] MUST be | The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be | |||
implemented and provide the following security triples. | implemented and provide the following security triples. | |||
column descriptions: | column descriptions: | |||
1 == number of pseudo flavor | 1 == number of pseudo flavor | |||
2 == name of pseudo flavor | 2 == name of pseudo flavor | |||
3 == mechanism's OID | 3 == mechanism's OID | |||
4 == mechanism's algorithm(s) | 4 == mechanism's algorithm(s) | |||
5 == RPCSEC_GSS service | 5 == RPCSEC_GSS service | |||
skipping to change at page 27, line 29 | skipping to change at page 27, line 29 | |||
and 56 bit DES | and 56 bit DES | |||
for privacy. | for privacy. | |||
Note that the pseudo flavor is presented here as a mapping aid to the | Note that the pseudo flavor is presented here as a mapping aid to the | |||
implementor. Because this NFS protocol includes a method to | implementor. Because this NFS protocol includes a method to | |||
negotiate security and it understands the GSS-API mechanism, the | negotiate security and it understands the GSS-API mechanism, the | |||
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 | pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 | |||
since the security negotiation is done via the MOUNT protocol. | since the security negotiation is done via the MOUNT protocol. | |||
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please | For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please | |||
see [22]. | see [RFC2623]. | |||
3.3. Security Negotiation | 3.3. Security Negotiation | |||
With the NFSv4 server potentially offering multiple security | With the NFSv4 server potentially offering multiple security | |||
mechanisms, the client needs a method to determine or negotiate which | mechanisms, the client needs a method to determine or negotiate which | |||
mechanism is to be used for its communication with the server. The | mechanism is to be used for its communication with the server. The | |||
NFS server may have multiple points within its filesystem name space | NFS server may have multiple points within its filesystem name space | |||
that are available for use by NFS clients. In turn the NFS server | that are available for use by NFS clients. In turn the NFS server | |||
may be configured such that each of these entry points may have | may be configured such that each of these entry points may have | |||
different or multiple security mechanisms in use. | different or multiple security mechanisms in use. | |||
skipping to change at page 29, line 34 | skipping to change at page 29, line 34 | |||
The filehandle in the NFS protocol is a per server unique identifier | The filehandle in the NFS protocol is a per server unique identifier | |||
for a filesystem object. The contents of the filehandle are opaque | for a filesystem object. The contents of the filehandle are opaque | |||
to the client. Therefore, the server is responsible for translating | to the client. Therefore, the server is responsible for translating | |||
the filehandle to an internal representation of the filesystem | the filehandle to an internal representation of the filesystem | |||
object. | object. | |||
4.1. Obtaining the First Filehandle | 4.1. Obtaining the First Filehandle | |||
The operations of the NFS protocol are defined in terms of one or | The operations of the NFS protocol are defined in terms of one or | |||
more filehandles. Therefore, the client needs a filehandle to | more filehandles. Therefore, the client needs a filehandle to | |||
initiate communication with the server. With the NFSv2 protocol [13] | initiate communication with the server. With the NFSv2 protocol | |||
and the NFSv3 protocol [14], there exists an ancillary protocol to | [RFC1094] and the NFSv3 protocol [RFC1813], there exists an ancillary | |||
obtain this first filehandle. The MOUNT protocol, RPC program number | protocol to obtain this first filehandle. The MOUNT protocol, RPC | |||
100005, provides the mechanism of translating a string based | program number 100005, provides the mechanism of translating a string | |||
filesystem path name to a filehandle which can then be used by the | based filesystem path name to a filehandle which can then be used by | |||
NFS protocols. | the NFS protocols. | |||
The MOUNT protocol has deficiencies in the area of security and use | The MOUNT protocol has deficiencies in the area of security and use | |||
via firewalls. This is one reason that the use of the public | via firewalls. This is one reason that the use of the public | |||
filehandle was introduced in [23] and [24]. With the use of the | filehandle was introduced in [RFC2054] and [RFC2055]. With the use | |||
public filehandle in combination with the LOOKUP operation in the | of the public filehandle in combination with the LOOKUP operation in | |||
NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT | the NFSv2 and NFSv3 protocols, it has been demonstrated that the | |||
protocol is unnecessary for viable interaction between NFS client and | MOUNT protocol is unnecessary for viable interaction between NFS | |||
server. | client and server. | |||
Therefore, the NFSv4 protocol will not use an ancillary protocol for | Therefore, the NFSv4 protocol will not use an ancillary protocol for | |||
translation from string based path names to a filehandle. Two | translation from string based path names to a filehandle. Two | |||
special filehandles will be used as starting points for the NFS | special filehandles will be used as starting points for the NFS | |||
client. | client. | |||
4.1.1. Root Filehandle | 4.1.1. Root Filehandle | |||
The first of the special filehandles is the ROOT filehandle. The | The first of the special filehandles is the ROOT filehandle. The | |||
ROOT filehandle is the "conceptual" root of the filesystem name space | ROOT filehandle is the "conceptual" root of the filesystem name space | |||
skipping to change at page 39, line 14 | skipping to change at page 39, line 14 | |||
MUST return NFS4ERR_INVAL. | MUST return NFS4ERR_INVAL. | |||
5.6. REQUIRED Attributes - List and Definition References | 5.6. REQUIRED Attributes - List and Definition References | |||
The list of REQUIRED attributes appears in Table 2. The meaning of | The list of REQUIRED attributes appears in Table 2. The meaning of | |||
the columns of the table are: | the columns of the table are: | |||
o Name: The name of attribute | o Name: The name of attribute | |||
o Id: The number assigned to the attribute. In the event of | o Id: The number assigned to the attribute. In the event of | |||
conflicts between the assigned number and [2], the latter is | conflicts between the assigned number and | |||
likely authoritative, but should be resolved with Errata to this | [I-D.ietf-nfsv4-rfc3530bis-dot-x], the latter is likely | |||
document and/or [2]. See [25] for the Errata process. | authoritative, but should be resolved with Errata to this document | |||
and/or [I-D.ietf-nfsv4-rfc3530bis-dot-x]. See [ISEG_errata] for | ||||
the Errata process. | ||||
o Data Type: The XDR data type of the attribute. | o Data Type: The XDR data type of the attribute. | |||
o Acc: Access allowed to the attribute. R means read-only (GETATTR | o Acc: Access allowed to the attribute. R means read-only (GETATTR | |||
may retrieve, SETATTR may not set). W means write-only (SETATTR | may retrieve, SETATTR may not set). W means write-only (SETATTR | |||
may set, GETATTR may not retrieve). R W means read/write (GETATTR | may set, GETATTR may not retrieve). R W means read/write (GETATTR | |||
may retrieve, SETATTR may set). | may retrieve, SETATTR may set). | |||
o Defined in: The section of this specification that describes the | o Defined in: The section of this specification that describes the | |||
attribute. | attribute. | |||
skipping to change at page 44, line 28 | skipping to change at page 44, line 28 | |||
5.8.2.9. Attribute 23: files_total | 5.8.2.9. Attribute 23: files_total | |||
Total file slots on the file system containing this object. | Total file slots on the file system containing this object. | |||
5.8.2.10. Attribute 24: fs_locations | 5.8.2.10. Attribute 24: fs_locations | |||
Locations where this file system may be found. If the server returns | Locations where this file system may be found. If the server returns | |||
NFS4ERR_MOVED as an error, this attribute MUST be supported. | NFS4ERR_MOVED as an error, this attribute MUST be supported. | |||
The server can specify a root path by setting an array of zero path | The server specifies the root path for a given server by returning a | |||
components. Other than this special case, the server MUST not | path consisting of zero path components. | |||
present empty path components to the client. | ||||
5.8.2.11. Attribute 25: hidden | 5.8.2.11. Attribute 25: hidden | |||
TRUE, if the file is considered hidden with respect to the Windows | TRUE, if the file is considered hidden with respect to the Windows | |||
API. | API. | |||
5.8.2.12. Attribute 26: homogeneous | 5.8.2.12. Attribute 26: homogeneous | |||
TRUE, if this object's file system is homogeneous, i.e., all objects | TRUE, if this object's file system is homogeneous, i.e., all objects | |||
in the file system (all objects on the server with the same fsid) | in the file system (all objects on the server with the same fsid) | |||
skipping to change at page 48, line 32 | skipping to change at page 48, line 32 | |||
5.8.2.33. Attribute 47: time_access | 5.8.2.33. Attribute 47: time_access | |||
The time_access attribute represents the time of last access to the | The time_access attribute represents the time of last access to the | |||
object by a READ operation sent to the server. The notion of what is | object by a READ operation sent to the server. The notion of what is | |||
an "access" depends on the server's operating environment and/or the | an "access" depends on the server's operating environment and/or the | |||
server's file system semantics. For example, for servers obeying | server's file system semantics. For example, for servers obeying | |||
Portable Operating System Interface (POSIX) semantics, time_access | Portable Operating System Interface (POSIX) semantics, time_access | |||
would be updated only by the READ and READDIR operations and not any | would be updated only by the READ and READDIR operations and not any | |||
of the operations that modify the content of the object [16], [17], | of the operations that modify the content of the object [16], [17], | |||
[26], [27], [28]. Of course, setting the corresponding | [read_api], [readdir_api], [write_api]. Of course, setting the | |||
time_access_set attribute is another way to modify the time_access | corresponding time_access_set attribute is another way to modify the | |||
attribute. | time_access attribute. | |||
Whenever the file object resides on a writable file system, the | Whenever the file object resides on a writable file system, the | |||
server should make its best efforts to record time_access into stable | server should make its best efforts to record time_access into stable | |||
storage. However, to mitigate the performance effects of doing so, | storage. However, to mitigate the performance effects of doing so, | |||
and most especially whenever the server is satisfying the read of the | and most especially whenever the server is satisfying the read of the | |||
object's content from its cache, the server MAY cache access time | object's content from its cache, the server MAY cache access time | |||
updates and lazily write them to stable storage. It is also | updates and lazily write them to stable storage. It is also | |||
acceptable to give administrators of the server the option to disable | acceptable to give administrators of the server the option to disable | |||
time_access updates. | time_access updates. | |||
skipping to change at page 49, line 33 | skipping to change at page 49, line 33 | |||
5.8.2.40. Attribute 54: time_modify_set | 5.8.2.40. Attribute 54: time_modify_set | |||
Sets the time of last modification to the object. SETATTR use only. | Sets the time of last modification to the object. SETATTR use only. | |||
5.9. Interpreting owner and owner_group | 5.9. Interpreting owner and owner_group | |||
The RECOMMENDED attributes "owner" and "owner_group" (and also users | The RECOMMENDED attributes "owner" and "owner_group" (and also users | |||
and groups within the "acl" attribute) are represented in terms of a | and groups within the "acl" attribute) are represented in terms of a | |||
UTF-8 string. To avoid a representation that is tied to a particular | UTF-8 string. To avoid a representation that is tied to a particular | |||
underlying implementation at the client or server, the use of the | underlying implementation at the client or server, the use of the | |||
UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [29] | UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 | |||
provides additional rationale. It is expected that the client and | [RFC2624] provides additional rationale. It is expected that the | |||
server will have their own local representation of owner and | client and server will have their own local representation of owner | |||
owner_group that is used for local storage or presentation to the end | and owner_group that is used for local storage or presentation to the | |||
user. Therefore, it is expected that when these attributes are | end user. Therefore, it is expected that when these attributes are | |||
transferred between the client and server, the local representation | transferred between the client and server, the local representation | |||
is translated to a syntax of the form "user@dns_domain". This will | is translated to a syntax of the form "user@dns_domain". This will | |||
allow for a client and server that do not use the same local | allow for a client and server that do not use the same local | |||
representation the ability to translate to a common syntax that can | representation the ability to translate to a common syntax that can | |||
be interpreted by both. | be interpreted by both. | |||
Similarly, security principals may be represented in different ways | Similarly, security principals may be represented in different ways | |||
by different security mechanisms. Servers normally translate these | by different security mechanisms. Servers normally translate these | |||
representations into a common format, generally that used by local | representations into a common format, generally that used by local | |||
storage, to serve as a means of identifying the users corresponding | storage, to serve as a means of identifying the users corresponding | |||
skipping to change at page 52, line 15 | skipping to change at page 52, line 15 | |||
dns_domain". | dns_domain". | |||
The owner string "nobody" may be used to designate an anonymous user, | The owner string "nobody" may be used to designate an anonymous user, | |||
which will be associated with a file created by a security principal | which will be associated with a file created by a security principal | |||
that cannot be mapped through normal means to the owner attribute. | that cannot be mapped through normal means to the owner attribute. | |||
5.10. Character Case Attributes | 5.10. Character Case Attributes | |||
With respect to the case_insensitive and case_preserving attributes, | With respect to the case_insensitive and case_preserving attributes, | |||
each UCS-4 character (which UTF-8 encodes) has a "long descriptive | each UCS-4 character (which UTF-8 encodes) has a "long descriptive | |||
name" RFC1345 [30] which may or may not include the word "CAPITAL" or | name" RFC1345 [RFC1345] which may or may not include the word | |||
"SMALL". The presence of SMALL or CAPITAL allows an NFS server to | "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows an NFS | |||
implement unambiguous and efficient table driven mappings for case | server to implement unambiguous and efficient table driven mappings | |||
insensitive comparisons, and non-case-preserving storage, although | for case insensitive comparisons, and non-case-preserving storage, | |||
there are variations that occur additional characters with a name | although there are variations that occur additional characters with a | |||
including "SMALL" or "CAPITAL" are added in a subsequent version of | name including "SMALL" or "CAPITAL" are added in a subsequent version | |||
Unicode. | of Unicode. | |||
For general character handling and internationalization issues, see | For general character handling and internationalization issues, see | |||
Section 12. For details regarding case mapping, see the section | Section 12. For details regarding case mapping, see the section | |||
Case-based Mapping Used for Component4 Strings. | Case-based Mapping Used for Component4 Strings. | |||
6. Access Control Attributes | 6. Access Control Attributes | |||
Access Control Lists (ACLs) are file attributes that specify fine | Access Control Lists (ACLs) are file attributes that specify fine | |||
grained access control. This chapter covers the "acl", "aclsupport", | grained access control. This chapter covers the "acl", "aclsupport", | |||
"mode", file attributes, and their interactions. Note that file | "mode", file attributes, and their interactions. Note that file | |||
skipping to change at page 82, line 12 | skipping to change at page 82, line 12 | |||
Another issue concerns refresh of referral locations. When referrals | Another issue concerns refresh of referral locations. When referrals | |||
are used extensively, they may change as server configurations | are used extensively, they may change as server configurations | |||
change. It is expected that clients will cache information related | change. It is expected that clients will cache information related | |||
to traversing referrals so that future client-side requests are | to traversing referrals so that future client-side requests are | |||
resolved locally without server communication. This is usually | resolved locally without server communication. This is usually | |||
rooted in client-side name look up caching. Clients should | rooted in client-side name look up caching. Clients should | |||
periodically purge this data for referral points in order to detect | periodically purge this data for referral points in order to detect | |||
changes in location information. | changes in location information. | |||
A problem exists if a client allows an open owner to have state on | A potential problem exists if a client were to allow an open owner to | |||
multiple filesystems on a server. If one of those filesystems is | have state on multiple filesystems on server, in that it is unclear | |||
migrated, what happens to the sequence numbers? A client can avoid | how the sequence numbers associated with open owners are to be dealt | |||
such a situation with the stipulation that any client which supports | with, in the event of transparent state migration. A client can | |||
migration MUST ensure that any open owner is confined to a single | avoid such a situation, if it ensures that any use of an open owner | |||
filesystem. If the server finds itself migrating open owners that | is confined to a single filesystem. | |||
span multiple filesystems, then it MUST not migrate the state for the | ||||
conflicting open owners on the non-migrated filesystems; instead it | A server MAY decline to migrate state associated with open owners | |||
MUST return NFS4ERR_STALE_STATEID if the client tries to use those | that span multiple filesystems. In cases in which the server chooses | |||
stateids. | not to migrate such state, the server MUST return NFS4ERR_BAD_STATEID | |||
when the client uses those stateids on the new server. | ||||
The server MUST return NFS4ERR_STALE_STATEID when the client uses | ||||
those stateids on the old server, regardless of whether migration has | ||||
occurred or not. | ||||
7.7. Effecting File System Transitions | 7.7. Effecting File System Transitions | |||
Transitions between file system instances, whether due to switching | Transitions between file system instances, whether due to switching | |||
between replicas upon server unavailability or to server-initiated | between replicas upon server unavailability or to server-initiated | |||
migration events, are best dealt with together. This is so even | migration events, are best dealt with together. This is so even | |||
though, for the server, pragmatic considerations will normally force | though, for the server, pragmatic considerations will normally force | |||
different implementation strategies for planned and unplanned | different implementation strategies for planned and unplanned | |||
transitions. Even though the prototypical use cases of replication | transitions. Even though the prototypical use cases of replication | |||
and migration contain distinctive sets of features, when all | and migration contain distinctive sets of features, when all | |||
skipping to change at page 82, line 50 | skipping to change at page 83, line 7 | |||
limit the changes seen by the client, to those that are less | limit the changes seen by the client, to those that are less | |||
aggressive, use more standard methods of replicating data, and impose | aggressive, use more standard methods of replicating data, and impose | |||
a greater burden on the client to adapt to the transition. | a greater burden on the client to adapt to the transition. | |||
The NFSv4 protocol does not impose choices on clients and servers | The NFSv4 protocol does not impose choices on clients and servers | |||
with regard to that spectrum of transition methods. In fact, there | with regard to that spectrum of transition methods. In fact, there | |||
are many valid choices, depending on client and application | are many valid choices, depending on client and application | |||
requirements and their interaction with server implementation | requirements and their interaction with server implementation | |||
choices. The NFSv4.0 protocol does not provide the servers a means | choices. The NFSv4.0 protocol does not provide the servers a means | |||
of communicating the transition methods. In the NFSv4.1 protocol | of communicating the transition methods. In the NFSv4.1 protocol | |||
[31], an additional attribute "fs_locations_info" is presented, which | [RFC5661], an additional attribute "fs_locations_info" is presented, | |||
will define the specific choices that can be made, how these choices | which will define the specific choices that can be made, how these | |||
are communicated to the client, and how the client is to deal with | choices are communicated to the client, and how the client is to deal | |||
any discontinuities. | with any discontinuities. | |||
In the sections below, references will be made to various possible | In the sections below, references will be made to various possible | |||
server implementation choices as a way of illustrating the transition | server implementation choices as a way of illustrating the transition | |||
scenarios that clients may deal with. The intent here is not to | scenarios that clients may deal with. The intent here is not to | |||
define or limit server implementations but rather to illustrate the | define or limit server implementations but rather to illustrate the | |||
range of issues that clients may face. Again, as the NFSv4.0 | range of issues that clients may face. Again, as the NFSv4.0 | |||
protocol does not have an explicit means of communicating these | protocol does not have an explicit means of communicating these | |||
issues to the client, the intent is to document the problems that can | issues to the client, the intent is to document the problems that can | |||
be faced in a multi-server name space and allow the client to use the | be faced in a multi-server name space and allow the client to use the | |||
inferred transitions available via fs_locations and other attributes | inferred transitions available via fs_locations and other attributes | |||
skipping to change at page 103, line 27 | skipping to change at page 103, line 27 | |||
For the case of the use of multiple, disjoint security mechanisms in | For the case of the use of multiple, disjoint security mechanisms in | |||
the server's resources, the security for a particular object in the | the server's resources, the security for a particular object in the | |||
server's namespace should be the union of all security mechanisms of | server's namespace should be the union of all security mechanisms of | |||
all direct descendants. | all direct descendants. | |||
9. File Locking and Share Reservations | 9. File Locking and Share Reservations | |||
Integrating locking into the NFS protocol necessarily causes it to be | Integrating locking into the NFS protocol necessarily causes it to be | |||
stateful. With the inclusion of share reservations the protocol | stateful. With the inclusion of share reservations the protocol | |||
becomes substantially more dependent on state than the traditional | becomes substantially more dependent on state than the traditional | |||
combination of NFS and NLM (Network Lock Manager) [32]. There are | combination of NFS and NLM (Network Lock Manager) [xnfs]. There are | |||
three components to making this state manageable: | three components to making this state manageable: | |||
o clear division between client and server | o clear division between client and server | |||
o ability to reliably detect inconsistency in state between client | o ability to reliably detect inconsistency in state between client | |||
and server | and server | |||
o simple and robust recovery mechanisms | o simple and robust recovery mechanisms | |||
In this model, the server owns the state information. The client | In this model, the server owns the state information. The client | |||
skipping to change at page 117, line 49 | skipping to change at page 117, line 49 | |||
received before the last request (L) was sent. If a duplicate of | received before the last request (L) was sent. If a duplicate of | |||
last request (r == L) is received, the stored response is returned. | last request (r == L) is received, the stored response is returned. | |||
If a request beyond the next sequence (r == L + 2) is received, it is | If a request beyond the next sequence (r == L + 2) is received, it is | |||
rejected with the return of error NFS4ERR_BAD_SEQID. Sequence | rejected with the return of error NFS4ERR_BAD_SEQID. Sequence | |||
history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM | history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM | |||
sequence changes the client verifier. | sequence changes the client verifier. | |||
Since the sequence number is represented with an unsigned 32-bit | Since the sequence number is represented with an unsigned 32-bit | |||
integer, the arithmetic involved with the sequence number is mod | integer, the arithmetic involved with the sequence number is mod | |||
2^32. For an example of modulo arithmetic involving sequence numbers | 2^32. For an example of modulo arithmetic involving sequence numbers | |||
see [33]. | see [RFC0793]. | |||
It is critical the server maintain the last response sent to the | It is critical the server maintain the last response sent to the | |||
client to provide a more reliable cache of duplicate non-idempotent | client to provide a more reliable cache of duplicate non-idempotent | |||
requests than that of the traditional cache described in [34]. The | requests than that of the traditional cache described in [Chet]. The | |||
traditional duplicate request cache uses a least recently used | traditional duplicate request cache uses a least recently used | |||
algorithm for removing unneeded requests. However, the last lock | algorithm for removing unneeded requests. However, the last lock | |||
request and response on a given state-owner must be cached as long as | request and response on a given state-owner must be cached as long as | |||
the lock state exists on the server. | the lock state exists on the server. | |||
The client MUST monotonically increment the sequence number for the | The client MUST monotonically increment the sequence number for the | |||
CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE | CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE | |||
operations. This is true even in the event that the previous | operations. This is true even in the event that the previous | |||
operation that used the sequence number received an error. The only | operation that used the sequence number received an error. The only | |||
exception to this rule is if the previous operation received one of | exception to this rule is if the previous operation received one of | |||
skipping to change at page 126, line 17 | skipping to change at page 126, line 17 | |||
requests to be processed during the grace period, it MUST determine | requests to be processed during the grace period, it MUST determine | |||
that no lock subsequently reclaimed will be rejected and that no lock | that no lock subsequently reclaimed will be rejected and that no lock | |||
subsequently reclaimed would have prevented any I/O operation | subsequently reclaimed would have prevented any I/O operation | |||
processed during the grace period. | processed during the grace period. | |||
Clients should be prepared for the return of NFS4ERR_GRACE errors for | Clients should be prepared for the return of NFS4ERR_GRACE errors for | |||
non-reclaim lock and I/O requests. In this case the client should | non-reclaim lock and I/O requests. In this case the client should | |||
employ a retry mechanism for the request. A delay (on the order of | employ a retry mechanism for the request. A delay (on the order of | |||
several seconds) between retries should be used to avoid overwhelming | several seconds) between retries should be used to avoid overwhelming | |||
the server. Further discussion of the general issue is included in | the server. Further discussion of the general issue is included in | |||
[21]. The client must account for the server that is able to perform | [Floyd]. The client must account for the server that is able to | |||
I/O and non-reclaim locking requests within the grace period as well | perform I/O and non-reclaim locking requests within the grace period | |||
as those that cannot do so. | as well as those that cannot do so. | |||
A reclaim-type locking request outside the server's grace period can | A reclaim-type locking request outside the server's grace period can | |||
only succeed if the server can guarantee that no conflicting lock or | only succeed if the server can guarantee that no conflicting lock or | |||
I/O request has been granted since reboot or restart. | I/O request has been granted since reboot or restart. | |||
A server may, upon restart, establish a new value for the lease | A server may, upon restart, establish a new value for the lease | |||
period. Therefore, clients should, once a new client ID is | period. Therefore, clients should, once a new client ID is | |||
established, refetch the lease_time attribute and use it as the basis | established, refetch the lease_time attribute and use it as the basis | |||
for lease renewal for the lease associated with that server. | for lease renewal for the lease associated with that server. | |||
However, the server must establish, for this restart event, a grace | However, the server must establish, for this restart event, a grace | |||
skipping to change at page 146, line 45 | skipping to change at page 146, line 45 | |||
leases will not be renewed, the server MAY extend the period for | leases will not be renewed, the server MAY extend the period for | |||
delegation recovery beyond the typical lease expiration period. For | delegation recovery beyond the typical lease expiration period. For | |||
open delegations, such delegations that are not released are | open delegations, such delegations that are not released are | |||
reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (See | reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (See | |||
Section 10.5 and Section 15.18 for discussion of open delegation and | Section 10.5 and Section 15.18 for discussion of open delegation and | |||
the details of OPEN respectively). | the details of OPEN respectively). | |||
A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it | A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it | |||
does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM and | does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM and | |||
instead MUST make them available for client reclaim using | instead MUST make them available for client reclaim using | |||
CLAIM_DELEGATE_PREV. The server MAY NOT remove the delegations until | CLAIM_DELEGATE_PREV. The server MUST NOT remove the delegations | |||
either the client does a DELEGPURGE, or one lease period has elapsed | until either the client does a DELEGPURGE, or one lease period has | |||
from the time the later of the SETCLIENTID_CONFIRM or the last | elapsed from the time the later of the SETCLIENTID_CONFIRM or the | |||
successful CLAIM_DELEGATE_PREV reclaim. | last successful CLAIM_DELEGATE_PREV reclaim. | |||
Note that the requirement stated above is not meant to imply that | Note that the requirement stated above is not meant to imply that | |||
when the client is no longer obliged, as required above, to retain | when the client is no longer obliged, as required above, to retain | |||
delegation information, that it should necessarily dispose of it. | delegation information, that it should necessarily dispose of it. | |||
Some specific cases are: | Some specific cases are: | |||
o When the period is terminated by the occurrence of DELEGPURGE, | o When the period is terminated by the occurrence of DELEGPURGE, | |||
deletion of unreclaimed delegations is appropriate and desirable. | deletion of unreclaimed delegations is appropriate and desirable. | |||
skipping to change at page 175, line 48 | skipping to change at page 175, line 48 | |||
protocol, and how they address issues related to | protocol, and how they address issues related to | |||
internationalization, including issues related to UTF-8, | internationalization, including issues related to UTF-8, | |||
normalization, string preparation, case folding, and handling of | normalization, string preparation, case folding, and handling of | |||
internationalization issues related to domains. | internationalization issues related to domains. | |||
The NFSv4 protocol needs to deal with internationalization, or I18N, | The NFSv4 protocol needs to deal with internationalization, or I18N, | |||
with respect to file names and other strings as used within the | with respect to file names and other strings as used within the | |||
protocol. The choice of string representation must allow for | protocol. The choice of string representation must allow for | |||
reasonable name/string access to clients, applications, and users | reasonable name/string access to clients, applications, and users | |||
which use various languages. The UTF-8 encoding of the UCS as | which use various languages. The UTF-8 encoding of the UCS as | |||
defined by [8] allows for this type of access and follows the policy | defined by [ISO.10646-1.1993] allows for this type of access and | |||
described in "IETF Policy on Character Sets and Languages", [9]. | follows the policy described in "IETF Policy on Character Sets and | |||
Languages", [RFC2277]. | ||||
In implementing such policies, it is important to understand and | In implementing such policies, it is important to understand and | |||
respect the nature of NFSv4 as a means by which client | respect the nature of NFSv4 as a means by which client | |||
implementations may invoke operations on remote file systems. Server | implementations may invoke operations on remote file systems. Server | |||
implementations act as a conduit to a range of file system | implementations act as a conduit to a range of file system | |||
implementations that the NFSv4 server typically invokes through a | implementations that the NFSv4 server typically invokes through a | |||
virtual-file-system interface. | virtual-file-system interface. | |||
Keeping this context in mind, one needs to understand that the file | Keeping this context in mind, one needs to understand that the file | |||
systems with which clients will be interacting will generally not be | systems with which clients will be interacting will generally not be | |||
skipping to change at page 176, line 45 | skipping to change at page 176, line 47 | |||
12.1. Use of UTF-8 | 12.1. Use of UTF-8 | |||
As mentioned above, UTF-8 is used as a convenient way to encode | As mentioned above, UTF-8 is used as a convenient way to encode | |||
Unicode which allows clients that have no internationalization | Unicode which allows clients that have no internationalization | |||
requirements to avoid these issues since the mapping of ASCII names | requirements to avoid these issues since the mapping of ASCII names | |||
to UTF-8 is the identity. | to UTF-8 is the identity. | |||
12.1.1. Relation to Stringprep | 12.1.1. Relation to Stringprep | |||
RFC 3454 [10], otherwise known as "stringprep", documents a framework | RFC 3454 [RFC3454], otherwise known as "stringprep", documents a | |||
for using Unicode/UTF-8 in networking protocols, intended "to | framework for using Unicode/UTF-8 in networking protocols, intended | |||
increase the likelihood that string input and string comparison work | "to increase the likelihood that string input and string comparison | |||
in ways that make sense for typical users throughout the world." A | work in ways that make sense for typical users throughout the world." | |||
protocol conforming to this framework must define a profile of | A protocol conforming to this framework must define a profile of | |||
stringprep "in order to fully specify the processing options." | stringprep "in order to fully specify the processing options." | |||
NFSv4, while it does make normative references to stringprep and uses | NFSv4, while it does make normative references to stringprep and uses | |||
elements of that framework, it does not, for reasons that are | elements of that framework, it does not, for reasons that are | |||
explained below, conform to that framework, for all of the strings | explained below, conform to that framework, for all of the strings | |||
that are used within it. | that are used within it. | |||
In addition to some specific issues which have caused stringprep to | In addition to some specific issues which have caused stringprep to | |||
add confusion in handling certain characters for certain languages, | add confusion in handling certain characters for certain languages, | |||
there are a number of general reasons why stringprep profiles are not | there are a number of general reasons why stringprep profiles are not | |||
suitable for describing NFSv4. | suitable for describing NFSv4. | |||
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 [3] | in [I-D.draft-ietf-idna] | |||
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 | |||
similar appearance. There have been attempts to define uniform | similar appearance. There have been attempts to define uniform | |||
processing in an attempt to avoid such confusion (see stringprep | processing in an attempt to avoid such confusion (see stringprep | |||
[10]) but the results have often added confusion. | [RFC3454]) but the results have often added confusion. | |||
Some examples of possible confusions and proposed processing intended | Some examples of possible confusions and proposed processing intended | |||
to reduce/avoid confusions: | to reduce/avoid confusions: | |||
o Deletion of characters believed to be invisible and appropriately | o Deletion of characters believed to be invisible and appropriately | |||
ignored, justifying their deletion, including, WORD JOINER | ignored, justifying their deletion, including, WORD JOINER | |||
(U+2060), and the ZERO WIDTH SPACE (U+200B). | (U+2060), and the ZERO WIDTH SPACE (U+200B). | |||
o Deletion of characters supposed to not bear semantics and only | o Deletion of characters supposed to not bear semantics and only | |||
affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C) | affect glyph choice, including the ZERO WIDTH NON-JOINER (U+200C) | |||
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 [3]. | responsibility of IDNA as described in [I-D.draft-ietf-idna]. | |||
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 183, line 27 | skipping to change at page 183, line 27 | |||
Table 6 | Table 6 | |||
The last table describes the components of the compound types | The last table describes the components of the compound types | |||
described above. | described above. | |||
+----------+--------+------+----------------------------------------+ | +----------+--------+------+----------------------------------------+ | |||
| Type | Class | Def | Explanation | | | Type | Class | Def | Explanation | | |||
+----------+--------+------+----------------------------------------+ | +----------+--------+------+----------------------------------------+ | |||
| svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or | | | svraddr4 | ASCII | NIP | Server as IP address, whether IPv4 or | | |||
| | | | IPv6. | | | | | | IPv6. | | |||
| svrname4 | UVMUST | INET | Server name as returned by server. | | | svrname4 | UVMUST | INET | Server name as returned by server. Not | | |||
| | | | Not sent by client, except in | | | | | | sent by client, except in | | |||
| | | | VERIFY/NVERIFY. | | | | | | VERIFY/NVERIFY. | | |||
| prinsfx4 | UVMUST | INET | Suffix part of principal, in the form | | | prinsfx4 | UVMUST | INET | Suffix part of principal, in the form | | |||
| | | | of a domain name. | | | | | | of a domain name. | | |||
| prinpfx4 | UVMUST | NFS | Must match one of a list of valid | | | prinpfx4 | UVMUST | NFS | Must match one of a list of valid | | |||
| | | | users or groups for that particular | | | | | | users or groups for that particular | | |||
| | | | domain. | | | | | | domain. | | |||
+----------+--------+------+----------------------------------------+ | +----------+--------+------+----------------------------------------+ | |||
Table 7 | Table 7 | |||
skipping to change at page 209, line 16 | skipping to change at page 209, line 16 | |||
A locking request was attempted which would require the upgrade or | A locking request was attempted which would require the upgrade or | |||
downgrade of a lock range already held by the owner when the server | downgrade of a lock range already held by the owner when the server | |||
does not support atomic upgrade or downgrade of locks. | does not support atomic upgrade or downgrade of locks. | |||
13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) | 13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) | |||
A lock request is operating on a range that overlaps in part a | A lock request is operating on a range that overlaps in part a | |||
currently held lock for the current lock owner and does not precisely | currently held lock for the current lock owner and does not precisely | |||
match a single such lock where the server does not support this type | match a single such lock where the server does not support this type | |||
of request, and thus does not implement POSIX locking semantics [35]. | of request, and thus does not implement POSIX locking semantics | |||
See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a | [fcntl]. See Section 15.12.5, Section 15.13.5, and Section 15.14.5 | |||
discussion of how this applies to LOCK, LOCKT, and LOCKU | for a discussion of how this applies to LOCK, LOCKT, and LOCKU | |||
respectively. | respectively. | |||
13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) | 13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) | |||
The client attempted a READ, WRITE, LOCK or other operation not | The client attempted a READ, WRITE, LOCK or other operation not | |||
sanctioned by the stateid passed (e.g., writing to a file opened only | sanctioned by the stateid passed (e.g., writing to a file opened only | |||
for read). | for read). | |||
13.1.9. Reclaim Errors | 13.1.9. Reclaim Errors | |||
skipping to change at page 234, line 47 | skipping to change at page 234, line 47 | |||
verifier at each server event or instantiation that may lead to a | verifier at each server event or instantiation that may lead to a | |||
loss of uncommitted data. Most commonly this occurs when the server | loss of uncommitted data. Most commonly this occurs when the server | |||
is rebooted; however, other events at the server may result in | is rebooted; however, other events at the server may result in | |||
uncommitted data loss as well. | uncommitted data loss as well. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
15.5.5. IMPLEMENTATION | 15.5.5. IMPLEMENTATION | |||
The COMMIT operation is similar in operation and semantics to the | The COMMIT operation is similar in operation and semantics to the | |||
POSIX fsync() [36] system call that synchronizes a file's state with | POSIX fsync() [fsync] system call that synchronizes a file's state | |||
the disk (file data and metadata is flushed to disk or stable | with the disk (file data and metadata is flushed to disk or stable | |||
storage). COMMIT performs the same operation for a client, flushing | storage). COMMIT performs the same operation for a client, flushing | |||
any unsynchronized data and metadata on the server to the server's | any unsynchronized data and metadata on the server to the server's | |||
disk or stable storage for the specified file. Like fsync(), it may | disk or stable storage for the specified file. Like fsync(), it may | |||
be that there is some modified data or no modified data to | be that there is some modified data or no modified data to | |||
synchronize. The data may have been synchronized by the server's | synchronize. The data may have been synchronized by the server's | |||
normal periodic buffer synchronization activity. COMMIT should | normal periodic buffer synchronization activity. COMMIT should | |||
return NFS4_OK, unless there has been an unexpected error. | return NFS4_OK, unless there has been an unexpected error. | |||
COMMIT differs from fsync() in that it is possible for the client to | COMMIT differs from fsync() in that it is possible for the client to | |||
flush a range of the file (most likely triggered by a buffer- | flush a range of the file (most likely triggered by a buffer- | |||
skipping to change at page 238, line 19 | skipping to change at page 238, line 19 | |||
from the principal indicated in the RPC credentials of the call, but | from the principal indicated in the RPC credentials of the call, but | |||
the server's operating environment or filesystem semantics may | the server's operating environment or filesystem semantics may | |||
dictate other methods of derivation. Similarly, if createattrs | dictate other methods of derivation. Similarly, if createattrs | |||
includes neither the group attribute nor a group ACE, and if the | includes neither the group attribute nor a group ACE, and if the | |||
server's filesystem both supports and requires the notion of a group | server's filesystem both supports and requires the notion of a group | |||
attribute (or group ACE), the server MUST derive the group attribute | attribute (or group ACE), the server MUST derive the group attribute | |||
(or the corresponding owner ACE) for the file. This could be from | (or the corresponding owner ACE) for the file. This could be from | |||
the RPC call's credentials, such as the group principal if the | the RPC call's credentials, such as the group principal if the | |||
credentials include it (such as with AUTH_SYS), from the group | credentials include it (such as with AUTH_SYS), from the group | |||
identifier associated with the principal in the credentials (e.g., | identifier associated with the principal in the credentials (e.g., | |||
POSIX systems have a user database [37] that has the group identifier | POSIX systems have a user database [getpwnam] that has the group | |||
for every user identifier), inherited from directory the object is | identifier for every user identifier), inherited from directory the | |||
created in, or whatever else the server's operating environment or | object is created in, or whatever else the server's operating | |||
filesystem semantics dictate. This applies to the OPEN operation | environment or filesystem semantics dictate. This applies to the | |||
too. | OPEN operation too. | |||
Conversely, it is possible the client will specify in createattrs an | Conversely, it is possible the client will specify in createattrs an | |||
owner attribute or group attribute or ACL that the principal | owner attribute or group attribute or ACL that the principal | |||
indicated the RPC call's credentials does not have permissions to | indicated the RPC call's credentials does not have permissions to | |||
create files for. The error to be returned in this instance is | create files for. The error to be returned in this instance is | |||
NFS4ERR_PERM. This applies to the OPEN operation too. | NFS4ERR_PERM. This applies to the OPEN operation too. | |||
15.6.5. IMPLEMENTATION | 15.6.5. IMPLEMENTATION | |||
If the client desires to set attribute values after the create, a | If the client desires to set attribute values after the create, a | |||
skipping to change at page 252, line 27 | skipping to change at page 252, line 27 | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
15.14.5. IMPLEMENTATION | 15.14.5. IMPLEMENTATION | |||
If the area to be unlocked does not correspond exactly to a lock | If the area to be unlocked does not correspond exactly to a lock | |||
actually held by the lock-owner the server may return the error | actually held by the lock-owner the server may return the error | |||
NFS4ERR_LOCK_RANGE. This includes the case in which the area is not | NFS4ERR_LOCK_RANGE. This includes the case in which the area is not | |||
locked, where the area is a sub-range of the area locked, where it | locked, where the area is a sub-range of the area locked, where it | |||
overlaps the area locked without matching exactly or the area | overlaps the area locked without matching exactly or the area | |||
specified includes multiple locks held by the lock-owner. In all of | specified includes multiple locks held by the lock-owner. In all of | |||
these cases, allowed by POSIX locking [35] semantics, a client | these cases, allowed by POSIX locking [fcntl] semantics, a client | |||
receiving this error, should if it desires support for such | receiving this error, should if it desires support for such | |||
operations, simulate the operation using LOCKU on ranges | operations, simulate the operation using LOCKU on ranges | |||
corresponding to locks it actually holds, possibly followed by LOCK | corresponding to locks it actually holds, possibly followed by LOCK | |||
requests for the sub-ranges not being unlocked. | requests for the sub-ranges not being unlocked. | |||
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose | When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose | |||
(see Section 15.12.5)) to handle LOCK requests locally. In such a | (see Section 15.12.5)) to handle LOCK requests locally. In such a | |||
case, LOCKU requests will similarly be handled locally. | case, LOCKU requests will similarly be handled locally. | |||
15.15. Operation 15: LOOKUP - Lookup Filename | 15.15. Operation 15: LOOKUP - Lookup Filename | |||
skipping to change at page 263, line 18 | skipping to change at page 263, line 18 | |||
reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. | reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. | |||
In this case, delegation will always be granted, although the server | In this case, delegation will always be granted, although the server | |||
may specify an immediate recall in the delegation structure. | may specify an immediate recall in the delegation structure. | |||
The rflags returned by a successful OPEN allow the server to return | The rflags returned by a successful OPEN allow the server to return | |||
information governing how the open file is to be handled. | information governing how the open file is to be handled. | |||
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an | OPEN4_RESULT_CONFIRM indicates that the client MUST execute an | |||
OPEN_CONFIRM operation before using the open file. | OPEN_CONFIRM operation before using the open file. | |||
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking | OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking | |||
behavior supports the complete set of Posix locking techniques [35]. | behavior supports the complete set of Posix locking techniques | |||
From this the client can choose to manage file locking state in a way | [fcntl]. From this the client can choose to manage file locking | |||
to handle a mis-match of file locking management. | state in a way to handle a mis-match of file locking management. | |||
If the component is of zero length, NFS4ERR_INVAL will be returned. | If the component is of zero length, NFS4ERR_INVAL will be returned. | |||
The component is also subject to the normal UTF-8, character support, | The component is also subject to the normal UTF-8, character support, | |||
and name checks. See Section 12.3 for further discussion. | and name checks. See Section 12.3 for further discussion. | |||
When an OPEN is done and the specified open-owner already has the | When an OPEN is done and the specified open-owner already has the | |||
resulting filehandle open, the result is to "OR" together the new | resulting filehandle open, the result is to "OR" together the new | |||
share and deny status together with the existing status. In this | share and deny status together with the existing status. In this | |||
case, only a single CLOSE need be done, even though multiple OPENs | case, only a single CLOSE need be done, even though multiple OPENs | |||
were completed. When such an OPEN is done, checking of share | were completed. When such an OPEN is done, checking of share | |||
skipping to change at page 264, line 12 | skipping to change at page 264, line 12 | |||
does not have authorization to create files for, then the server may | does not have authorization to create files for, then the server may | |||
return NFS4ERR_PERM. | return NFS4ERR_PERM. | |||
In the case of a OPEN which specifies a size of zero (e.g., | In the case of a OPEN which specifies a size of zero (e.g., | |||
truncation) and the file has named attributes, the named attributes | truncation) and the file has named attributes, the named attributes | |||
are left as is. They are not removed. | are left as is. They are not removed. | |||
15.18.6. IMPLEMENTATION | 15.18.6. IMPLEMENTATION | |||
The OPEN operation contains support for EXCLUSIVE4 create. The | The OPEN operation contains support for EXCLUSIVE4 create. The | |||
mechanism is similar to the support in NFSv3 [14]. As in NFSv3, this | mechanism is similar to the support in NFSv3 [RFC1813]. As in NFSv3, | |||
mechanism provides reliable exclusive creation. Exclusive create is | this mechanism provides reliable exclusive creation. Exclusive | |||
invoked when the how parameter is EXCLUSIVE4. In this case, the | create is invoked when the how parameter is EXCLUSIVE4. In this | |||
client provides a verifier that can reasonably be expected to be | case, the client provides a verifier that can reasonably be expected | |||
unique. A combination of a client identifier, perhaps the client | to be unique. A combination of a client identifier, perhaps the | |||
network address, and a unique number generated by the client, perhaps | client network address, and a unique number generated by the client, | |||
the RPC transaction identifier, may be appropriate. | perhaps the RPC transaction identifier, may be appropriate. | |||
If the object does not exist, the server creates the object and | If the object does not exist, the server creates the object and | |||
stores the verifier in stable storage. For filesystems that do not | stores the verifier in stable storage. For filesystems that do not | |||
provide a mechanism for the storage of arbitrary file attributes, the | provide a mechanism for the storage of arbitrary file attributes, the | |||
server may use one or more elements of the object meta-data to store | server may use one or more elements of the object meta-data to store | |||
the verifier. The verifier must be stored in stable storage to | the verifier. The verifier must be stored in stable storage to | |||
prevent erroneous failure on retransmission of the request. It is | prevent erroneous failure on retransmission of the request. It is | |||
assumed that an exclusive create is being performed because exclusive | assumed that an exclusive create is being performed because exclusive | |||
semantics are critical to the application. Because of the expected | semantics are critical to the application. Because of the expected | |||
usage, exclusive CREATE does not rely solely on the normally volatile | usage, exclusive CREATE does not rely solely on the normally volatile | |||
skipping to change at page 266, line 10 | skipping to change at page 266, line 10 | |||
and for special files of other types; NFS4ERR_INVAL would be | and for special files of other types; NFS4ERR_INVAL would be | |||
inappropriate, since the arguments provided by the client were | inappropriate, since the arguments provided by the client were | |||
correct, and the client cannot necessarily know at the time it sent | correct, and the client cannot necessarily know at the time it sent | |||
the OPEN that the component would resolve to a non-regular file. | the OPEN that the component would resolve to a non-regular file. | |||
If the current filehandle is not a directory, the error | If the current filehandle is not a directory, the error | |||
NFS4ERR_NOTDIR will be returned. | NFS4ERR_NOTDIR will be returned. | |||
If a COMPOUND contains an OPEN which establishes a | If a COMPOUND contains an OPEN which establishes a | |||
OPEN_DELEGATE_WRITE delegation, then a subsequent GETATTR inside that | OPEN_DELEGATE_WRITE delegation, then a subsequent GETATTR inside that | |||
COMPOUND SHOULD not result in a CB_GETATTR to the client. The server | COMPOUND SHOULD NOT result in a CB_GETATTR to the client. The server | |||
SHOULD understand the GETATTR to be for the same client ID and avoid | SHOULD understand the GETATTR to be for the same client ID and avoid | |||
querying the client, which will not be able to respond. This | querying the client, which will not be able to respond. This | |||
sequence of OPEN, GETATTR SHOULD be understood as an atomic retrieval | sequence of OPEN, GETATTR SHOULD be understood as an atomic retrieval | |||
of the initial size and change attribute. Further, the client SHOULD | of the initial size and change attribute. Further, the client SHOULD | |||
NOT construct a COMPOUND which mixes operations for different client | NOT construct a COMPOUND which mixes operations for different client | |||
IDs. | IDs. | |||
15.19. Operation 19: OPENATTR - Open Named Attribute Directory | 15.19. Operation 19: OPENATTR - Open Named Attribute Directory | |||
15.19.1. SYNOPSIS | 15.19.1. SYNOPSIS | |||
skipping to change at page 271, line 45 | skipping to change at page 271, line 45 | |||
nfsstat4 status; | nfsstat4 status; | |||
}; | }; | |||
15.23.4. DESCRIPTION | 15.23.4. DESCRIPTION | |||
Replaces the current filehandle with the filehandle that represents | Replaces the current filehandle with the filehandle that represents | |||
the public filehandle of the server's name space. This filehandle | the public filehandle of the server's name space. This filehandle | |||
may be different from the "root" filehandle which may be associated | may be different from the "root" filehandle which may be associated | |||
with some other directory on the server. | with some other directory on the server. | |||
The public filehandle represents the concepts embodied in [23], [24], | The public filehandle represents the concepts embodied in [RFC2054], | |||
[38]. The intent for NFSv4 is that the public filehandle | [RFC2055], [RFC2224]. The intent for NFSv4 is that the public | |||
(represented by the PUTPUBFH operation) be used as a method of | filehandle (represented by the PUTPUBFH operation) be used as a | |||
providing WebNFS server compatibility with NFSv2 and NFSv3. | method of providing WebNFS server compatibility with NFSv2 and NFSv3. | |||
The public filehandle and the root filehandle (represented by the | The public filehandle and the root filehandle (represented by the | |||
PUTROOTFH operation) should be equivalent. If the public and root | PUTROOTFH operation) should be equivalent. If the public and root | |||
filehandles are not equivalent, then the public filehandle MUST be a | filehandles are not equivalent, then the public filehandle MUST be a | |||
descendant of the root filehandle. | descendant of the root filehandle. | |||
15.23.5. IMPLEMENTATION | 15.23.5. IMPLEMENTATION | |||
Used as the first operator in an NFS request to set the context for | Used as the first operator in an NFS request to set the context for | |||
following operations. | following operations. | |||
With the NFSv2 and 3 public filehandle, the client is able to specify | With the NFSv2 and 3 public filehandle, the client is able to specify | |||
whether the path name provided in the LOOKUP should be evaluated as | whether the path name provided in the LOOKUP should be evaluated as | |||
either an absolute path relative to the server's root or relative to | either an absolute path relative to the server's root or relative to | |||
the public filehandle. [38] contains further discussion of the | the public filehandle. [RFC2224] contains further discussion of the | |||
functionality. With NFSv4, that type of specification is not | functionality. With NFSv4, that type of specification is not | |||
directly available in the LOOKUP operation. The reason for this is | directly available in the LOOKUP operation. The reason for this is | |||
because the component separators needed to specify absolute vs. | because the component separators needed to specify absolute vs. | |||
relative are not allowed in NFSv4. Therefore, the client is | relative are not allowed in NFSv4. Therefore, the client is | |||
responsible for constructing its request such that the use of either | responsible for constructing its request such that the use of either | |||
PUTROOTFH or PUTPUBFH are used to signify absolute or relative | PUTROOTFH or PUTPUBFH are used to signify absolute or relative | |||
evaluation of an NFS URL respectively. | evaluation of an NFS URL respectively. | |||
Note that there are warnings mentioned in [38] with respect to the | Note that there are warnings mentioned in [RFC2224] with respect to | |||
use of absolute evaluation and the restrictions the server may place | the use of absolute evaluation and the restrictions the server may | |||
on that evaluation with respect to how much of its namespace has been | place on that evaluation with respect to how much of its namespace | |||
made available. These same warnings apply to NFSv4. It is likely, | has been made available. These same warnings apply to NFSv4. It is | |||
therefore that because of server implementation details, an NFSv3 | likely, therefore that because of server implementation details, an | |||
absolute public filehandle lookup may behave differently than an | NFSv3 absolute public filehandle lookup may behave differently than | |||
NFSv4 absolute resolution. | an NFSv4 absolute resolution. | |||
There is a form of security negotiation as described in [39] that | There is a form of security negotiation as described in [RFC2755] | |||
uses the public filehandle a method of employing SNEGO. This method | that uses the public filehandle a method of employing SNEGO. This | |||
is not available with NFSv4 as filehandles are not overloaded with | method is not available with NFSv4 as filehandles are not overloaded | |||
special meaning and therefore do not provide the same framework as | with special meaning and therefore do not provide the same framework | |||
NFSv2 and NFSv3. Clients should therefore use the security | as NFSv2 and NFSv3. Clients should therefore use the security | |||
negotiation mechanisms described in this RFC. | negotiation mechanisms described in this RFC. | |||
15.24. Operation 24: PUTROOTFH - Set Root Filehandle | 15.24. Operation 24: PUTROOTFH - Set Root Filehandle | |||
15.24.1. SYNOPSIS | 15.24.1. SYNOPSIS | |||
- -> (cfh) | - -> (cfh) | |||
15.24.2. ARGUMENT | 15.24.2. ARGUMENT | |||
skipping to change at page 281, line 42 | skipping to change at page 281, line 42 | |||
target is also subject to the normal UTF-8, character support, and | target is also subject to the normal UTF-8, character support, and | |||
name checks. See Section 12.3 for further discussion. | name checks. See Section 12.3 for further discussion. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
15.28.5. IMPLEMENTATION | 15.28.5. IMPLEMENTATION | |||
NFSv3 required a different operator RMDIR for directory removal and | NFSv3 required a different operator RMDIR for directory removal and | |||
REMOVE for non-directory removal. This allowed clients to skip | REMOVE for non-directory removal. This allowed clients to skip | |||
checking the file type when being passed a non-directory delete | checking the file type when being passed a non-directory delete | |||
system call (e.g., unlink() [40] in POSIX) to remove a directory, as | system call (e.g., unlink() [unlink] in POSIX) to remove a directory, | |||
well as the converse (e.g., a rmdir() on a non-directory) because | as well as the converse (e.g., a rmdir() on a non-directory) because | |||
they knew the server would check the file type. NFSv4 REMOVE can be | they knew the server would check the file type. NFSv4 REMOVE can be | |||
used to delete any directory entry independent of its file type. The | used to delete any directory entry independent of its file type. The | |||
implementor of an NFSv4 client's entry points from the unlink() and | implementor of an NFSv4 client's entry points from the unlink() and | |||
rmdir() system calls should first check the file type against the | rmdir() system calls should first check the file type against the | |||
types the system call is allowed to remove before issuing a REMOVE. | types the system call is allowed to remove before issuing a REMOVE. | |||
Alternatively, the implementor can produce a COMPOUND call that | Alternatively, the implementor can produce a COMPOUND call that | |||
includes a LOOKUP/VERIFY sequence to verify the file type before a | includes a LOOKUP/VERIFY sequence to verify the file type before a | |||
REMOVE operation in the same COMPOUND call. | REMOVE operation in the same COMPOUND call. | |||
The concept of last reference is server specific. However, if the | The concept of last reference is server specific. However, if the | |||
skipping to change at page 289, line 7 | skipping to change at page 289, line 7 | |||
not have the appropriate access to LOOKUP the name then SECINFO must | not have the appropriate access to LOOKUP the name then SECINFO must | |||
behave the same way and return NFS4ERR_ACCESS. | behave the same way and return NFS4ERR_ACCESS. | |||
The result will contain an array which represents the security | The result will contain an array which represents the security | |||
mechanisms available, with an order corresponding to server's | mechanisms available, with an order corresponding to server's | |||
preferences, the most preferred being first in the array. The client | preferences, the most preferred being first in the array. The client | |||
is free to pick whatever security mechanism it both desires and | is free to pick whatever security mechanism it both desires and | |||
supports, or to pick in the server's preference order the first one | supports, or to pick in the server's preference order the first one | |||
it supports. The array entries are represented by the secinfo4 | it supports. The array entries are represented by the secinfo4 | |||
structure. The field 'flavor' will contain a value of AUTH_NONE, | structure. The field 'flavor' will contain a value of AUTH_NONE, | |||
AUTH_SYS (as defined in [4]), or RPCSEC_GSS (as defined in [5]). | AUTH_SYS (as defined in [RFC5531]), or RPCSEC_GSS (as defined in | |||
[RFC2203]). | ||||
For the flavors AUTH_NONE and AUTH_SYS, no additional security | For the flavors AUTH_NONE and AUTH_SYS, no additional security | |||
information is returned. For a return value of RPCSEC_GSS, a | information is returned. For a return value of RPCSEC_GSS, a | |||
security triple is returned that contains the mechanism object id (as | security triple is returned that contains the mechanism object id (as | |||
defined in [6]), the quality of protection (as defined in [6]) and | defined in [RFC2743]), the quality of protection (as defined in | |||
the service type (as defined in [5]). It is possible for SECINFO to | [RFC2743]) and the service type (as defined in [RFC2203]). It is | |||
return multiple entries with flavor equal to RPCSEC_GSS with | possible for SECINFO to return multiple entries with flavor equal to | |||
different security triple values. | RPCSEC_GSS with different security triple values. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
If the name has a length of 0 (zero), or if name does not obey the | If the name has a length of 0 (zero), or if name does not obey the | |||
UTF-8 definition, the error NFS4ERR_INVAL will be returned. | UTF-8 definition, the error NFS4ERR_INVAL will be returned. | |||
15.33.5. IMPLEMENTATION | 15.33.5. IMPLEMENTATION | |||
The SECINFO operation is expected to be used by the NFS client when | The SECINFO operation is expected to be used by the NFS client when | |||
the error value of NFS4ERR_WRONGSEC is returned from another NFS | the error value of NFS4ERR_WRONGSEC is returned from another NFS | |||
skipping to change at page 314, line 11 | skipping to change at page 314, line 11 | |||
on an NFS server. Consideration should also be given to the | on an NFS server. Consideration should also be given to the | |||
integrity and privacy of NFS requests and responses. The issues of | integrity and privacy of NFS requests and responses. The issues of | |||
end to end mutual authentication, integrity, and privacy are | end to end mutual authentication, integrity, and privacy are | |||
discussed as part of Section 3. | discussed as part of Section 3. | |||
When an NFSv4 mandated security model is used and a security | When an NFSv4 mandated security model is used and a security | |||
principal or an NFSv4 name in user@dns_domain form needs to be | principal or an NFSv4 name in user@dns_domain form needs to be | |||
translated to or from a local representation as described in | translated to or from a local representation as described in | |||
Section 5.9, the translation SHOULD be done in a secure manner that | Section 5.9, the translation SHOULD be done in a secure manner that | |||
preserves the integrity of the translation. For communication with a | preserves the integrity of the translation. For communication with a | |||
name service such as LDAP ([41]), this means employing a security | name service such as LDAP ([RFC4511]), this means employing a | |||
service that uses authentication and data integrity. Kerberos and | security service that uses authentication and data integrity. | |||
TLS ([42]) are examples of such a security service. | Kerberos and TLS ([RFC5246]) are examples of such a security service. | |||
Note that being REQUIRED to implement does not mean REQUIRED to use; | Note that being REQUIRED to implement does not mean REQUIRED to use; | |||
AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS | AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS | |||
is merely an OPTIONAL security flavor in NFSv4, and so | is merely an OPTIONAL security flavor in NFSv4, and so | |||
interoperability via AUTH_SYS is not assured. | interoperability via AUTH_SYS is not assured. | |||
For reasons of reduced administration overhead, better performance | For reasons of reduced administration overhead, better performance | |||
and/or reduction of CPU utilization, users of NFSv4 implementations | and/or reduction of CPU utilization, users of NFSv4 implementations | |||
may choose to not use security mechanisms that enable integrity | may choose to not use security mechanisms that enable integrity | |||
protection on each remote procedure call and response. The use of | protection on each remote procedure call and response. The use of | |||
skipping to change at page 315, line 10 | skipping to change at page 315, line 10 | |||
server controlled by the attacker. | server controlled by the attacker. | |||
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are | Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are | |||
responsible for the release of client state, it is imperative that | responsible for the release of client state, it is imperative that | |||
the principal used for these operations is checked against and match | the principal used for these operations is checked against and match | |||
the previous use of these operations. See Section 9.1.1 for further | the previous use of these operations. See Section 9.1.1 for further | |||
discussion. | discussion. | |||
18. IANA Considerations | 18. IANA Considerations | |||
This section uses terms that are defined in [43]. | This section uses terms that are defined in [RFC5226]. | |||
18.1. Named Attribute Definitions | 18.1. Named Attribute Definitions | |||
IANA will create a registry called the "NFSv4 Named Attribute | IANA will create a registry called the "NFSv4 Named Attribute | |||
Definitions Registry". | Definitions Registry". | |||
The NFSv4 protocol supports the association of a file with zero or | The NFSv4 protocol supports the association of a file with zero or | |||
more named attributes. The name space identifiers for these | more named attributes. The name space identifiers for these | |||
attributes are defined as string names. The protocol does not define | attributes are defined as string names. The protocol does not define | |||
the specific assignment of the name space for these file attributes. | the specific assignment of the name space for these file attributes. | |||
skipping to change at page 315, line 33 | skipping to change at page 315, line 33 | |||
attributes as needed, they are encouraged to register the attributes | attributes as needed, they are encouraged to register the attributes | |||
with IANA. | with IANA. | |||
Such registered named attributes are presumed to apply to all minor | Such registered named attributes are presumed to apply to all minor | |||
versions of NFSv4, including those defined subsequently to the | versions of NFSv4, including those defined subsequently to the | |||
registration. Where the named attribute is intended to be limited | registration. Where the named attribute is intended to be limited | |||
with regard to the minor versions for which they are not be used, the | with regard to the minor versions for which they are not be used, the | |||
assignment in registry will clearly state the applicable limits. | assignment in registry will clearly state the applicable limits. | |||
All assignments to the registry are made on a First Come First Served | All assignments to the registry are made on a First Come First Served | |||
basis, per section 4.1 of [43]. The policy for each assignment is | basis, per section 4.1 of [RFC5226]. The policy for each assignment | |||
Specification Required, per section 4.1 of [43]. | is Specification Required, per section 4.1 of [RFC5226]. | |||
Under the NFSv4 specification, the name of a named attribute can in | Under the NFSv4 specification, the name of a named attribute can in | |||
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 | theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 | |||
clients and servers will be unable to a handle string that long. | clients and servers will be unable to a handle string that long. | |||
IANA should reject any assignment request with a named attribute that | IANA should reject any assignment request with a named attribute that | |||
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up | exceeds 128 UTF-8 characters. To give IESG the flexibility to set up | |||
bases of assignment of Experimental Use and Standards Action, the | bases of assignment of Experimental Use and Standards Action, the | |||
prefixes of "EXPE" and "STDS" are Reserved. The zero length named | prefixes of "EXPE" and "STDS" are Reserved. The zero length named | |||
attribute name is Reserved. | attribute name is Reserved. | |||
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 | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [I-D.draft-ietf-idna] | |||
Levels", March 1997. | Klensin, J., "Internationalized Domain Names in | |||
Applications (IDNA): Protocol", | ||||
draft-ietf-idnabis-protocol-18 (work in progress), | ||||
January 2010. | ||||
[2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", | [I-D.ietf-nfsv4-rfc3530bis-dot-x] | |||
draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), | Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR | |||
Feb 2011. | Description", draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work | |||
in progress), Feb 2011. | ||||
[3] Klensin, J., "Internationalized Domain Names in Applications | [ISO.10646-1.1993] | |||
(IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in | International Organization for Standardization, | |||
progress), January 2010. | "Information Technology - Universal Multiple-octet coded | |||
Character Set (UCS) - Part 1: Architecture and Basic | ||||
Multilingual Plane", ISO Standard 10646-1, May 1993. | ||||
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Version 2", RFC 5531, May 2009. | Requirement Levels", March 1997. | |||
[5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol | [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol | |||
Specification", RFC 2203, September 1997. | Specification", RFC 2203, September 1997. | |||
[6] Linn, J., "Generic Security Service Application Program | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
Interface Version 2, Update 1", RFC 2743, January 2000. | Languages", BCP 18, RFC 2277, January 1998. | |||
[7] Eisler, M., Ed., "IANA Considerations for Remote Procedure Call | [RFC2743] Linn, J., "Generic Security Service Application Program | |||
(RPC) Network Identifiers and Universal Address Formats", | Interface Version 2, Update 1", RFC 2743, January 2000. | |||
RFC 5665, January 2010. | ||||
[8] International Organization for Standardization, "Information | [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of | |||
Technology - Universal Multiple-octet coded Character Set (UCS) | Internationalized Strings ("stringprep")", RFC 3454, | |||
- Part 1: Architecture and Basic Multilingual Plane", | December 2002. | |||
ISO Standard 10646-1, May 1993. | ||||
[9] Alvestrand, H., "IETF Policy on Character Sets and Languages", | [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol | |||
BCP 18, RFC 2277, January 1998. | Specification Version 2", RFC 5531, May 2009. | |||
[10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized | [RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure | |||
Strings ("stringprep")", RFC 3454, December 2002. | Call (RPC) Network Identifiers and Universal Address | |||
Formats", RFC 5665, January 2010. | ||||
19.2. Informative References | 19.2. Informative References | |||
[11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, | [Chet] Juszczak, C., "Improving the Performance and Correctness | |||
C., Eisler, M., and D. Noveck, "Network File System (NFS) | of an NFS Server", USENIX Conference Proceedings , | |||
version 4 Protocol", RFC 3530, April 2003. | June 1990. | |||
[12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, | [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of | |||
C., Eisler, M., and D. Noveck, "Network File System (NFS) | Periodic Routing Messages", IEEE/ACM Transactions on | |||
version 4 Protocol", RFC 3010, December 2000. | Networking 2(2), pp. 122-136, April 1994. | |||
[13] Nowicki, B., "NFS: Network File System Protocol specification", | [ISEG_errata] | |||
RFC 1094, March 1989. | IESG, "IESG Processing of RFC Errata for the IETF Stream", | |||
July 2008. | ||||
[14] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
Protocol Specification", RFC 1813, June 1995. | RFC 793, September 1981. | |||
[15] Eisler, M., "XDR: External Data Representation Standard", | [RFC1094] Nowicki, B., "NFS: Network File System Protocol | |||
RFC 4506, May 2006. | specification", RFC 1094, March 1989. | |||
[16] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version | [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", | |||
5 Generic Security Service Application Program Interface (GSS- | RFC 1345, June 1992. | |||
API) Mechanism: Version 2", RFC 4121, July 2005. | ||||
[17] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- | [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS | |||
line Database", RFC 3232, January 2002. | Version 3 Protocol Specification", RFC 1813, June 1995. | |||
[18] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", | [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", | |||
RFC 1833, August 1995. | RFC 1833, August 1995. | |||
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion | [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, | |||
Control Protocol (DCCP)", RFC 4340, March 2006. | October 1996. | |||
[20] Adamson, B., Bormann, C., Handley, M., and J. Macker, | [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, | |||
"Negative-acknowledgment (NACK)-Oriented Reliable Multicast | October 1996. | |||
(NORM) Protocol", RFC 3940, November 2004. | ||||
[21] Floyd, S. and V. Jacobson, "The Synchronization of Periodic | [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. | |||
Routing Messages", IEEE/ACM Transactions on Networking 2(2), | ||||
pp. 122-136, April 1994. | ||||
[22] Eisler, M., "NFS Version 2 and Version 3 Security Issues and | [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues | |||
the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", | and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", | |||
RFC 2623, June 1999. | RFC 2623, June 1999. | |||
[23] Callaghan, B., "WebNFS Client Specification", RFC 2054, | [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", | |||
October 1996. | RFC 2624, June 1999. | |||
[24] Callaghan, B., "WebNFS Server Specification", RFC 2055, | [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security | |||
October 1996. | Negotiation for WebNFS", RFC 2755, January 2000. | |||
[25] IESG, "IESG Processing of RFC Errata for the IETF Stream", | [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., | |||
July 2008. | Beame, C., Eisler, M., and D. Noveck, "Network File System | |||
(NFS) version 4 Protocol", RFC 3010, December 2000. | ||||
[26] The Open Group, "Section 'read()' of System Interfaces of The | [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by | |||
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 | an On-line Database", RFC 3232, January 2002. | |||
Edition", 2004. | ||||
[27] The Open Group, "Section 'readdir()' of System Interfaces of | [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., | |||
The Open Group Base Specifications Issue 6, IEEE Std 1003.1, | Beame, C., Eisler, M., and D. Noveck, "Network File System | |||
2004 Edition", 2004. | (NFS) version 4 Protocol", RFC 3530, April 2003. | |||
[28] The Open Group, "Section 'write()' of System Interfaces of The | [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, | |||
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 | "Negative-acknowledgment (NACK)-Oriented Reliable | |||
Edition", 2004. | Multicast (NORM) Protocol", RFC 3940, November 2004. | |||
[29] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, | [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos | |||
June 1999. | Version 5 Generic Security Service Application Program | |||
Interface (GSS-API) Mechanism: Version 2", RFC 4121, | ||||
July 2005. | ||||
[30] Simonsen, K., "Character Mnemonics and Character Sets", | [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | |||
RFC 1345, June 1992. | Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | |||
[31] Shepler, S., Eisler, M., and D. Noveck, "Network File System | [RFC4506] Eisler, M., "XDR: External Data Representation Standard", | |||
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, | RFC 4506, May 2006. | |||
January 2010. | ||||
[32] The Open Group, "Protocols for Interworking: XNFS, Version 3W, | [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol | |||
ISBN 1-85912-184-5", February 1998. | (LDAP): The Protocol", RFC 4511, June 2006. | |||
[33] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
September 1981. | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | ||||
[34] Juszczak, C., "Improving the Performance and Correctness of an | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
NFS Server", USENIX Conference Proceedings , June 1990. | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
[35] The Open Group, "Section 'fcntl()' of System Interfaces of The | [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File | |||
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 | System (NFS) Version 4 Minor Version 1 Protocol", | |||
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", | RFC 5661, January 2010. | |||
2004. | ||||
[36] The Open Group, "Section 'fsync()' of System Interfaces of The | [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of | |||
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 | The Open Group Base Specifications Issue 6 IEEE Std | |||
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", | 1003.1, 2004 Edition, HTML Version (www.opengroup.org), | |||
2004. | ISBN 1931624232", 2004. | |||
[37] The Open Group, "Section 'getpwnam()' of System Interfaces of | [fsync] The Open Group, "Section 'fsync()' of System Interfaces of | |||
The Open Group Base Specifications Issue 6 IEEE Std 1003.1, | The Open Group Base Specifications Issue 6 IEEE Std | |||
2004 Edition, HTML Version (www.opengroup.org), ISBN | 1003.1, 2004 Edition, HTML Version (www.opengroup.org), | |||
1931624232", 2004. | ISBN 1931624232", 2004. | |||
[38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. | [getpwnam] | |||
The Open Group, "Section 'getpwnam()' 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. | ||||
[39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation | [read_api] | |||
for WebNFS", RFC 2755, January 2000. | The Open Group, "Section 'read()' of System Interfaces of | |||
The Open Group Base Specifications Issue 6, IEEE Std | ||||
1003.1, 2004 Edition", 2004. | ||||
[40] The Open Group, "Section 'unlink()' of System Interfaces of The | [readdir_api] | |||
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 | The Open Group, "Section 'readdir()' of System Interfaces | |||
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", | of The Open Group Base Specifications Issue 6, IEEE Std | |||
2004. | 1003.1, 2004 Edition", 2004. | |||
[41] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): | [unlink] The Open Group, "Section 'unlink()' of System Interfaces | |||
The Protocol", RFC 4511, June 2006. | of The Open Group Base Specifications Issue 6 IEEE Std | |||
1003.1, 2004 Edition, HTML Version (www.opengroup.org), | ||||
ISBN 1931624232", 2004. | ||||
[42] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) | [write_api] | |||
Protocol Version 1.2", RFC 5246, August 2008. | The Open Group, "Section 'write()' of System Interfaces of | |||
The Open Group Base Specifications Issue 6, IEEE Std | ||||
1003.1, 2004 Edition", 2004. | ||||
[43] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [xnfs] The Open Group, "Protocols for Interworking: XNFS, Version | |||
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. | 3W, ISBN 1-85912-184-5", February 1998. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
A bis is certainly built on the shoulders of the first attempt. | A bis is certainly built on the shoulders of the first attempt. | |||
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, | Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, | |||
Carl Beame, Mike Eisler, and David Noveck are responsible for a great | Carl Beame, Mike Eisler, and David Noveck are responsible for a great | |||
deal of the effort in this work. | deal of the effort in this work. | |||
Rob Thurlow clarified how a client should contact a new server if a | Rob Thurlow clarified how a client should contact a new server if a | |||
migration has occurred. | migration has occurred. | |||
skipping to change at page 320, line 29 | skipping to change at page 320, line 40 | |||
James Lentini graciously read the rewrite of Section 7 and his | James Lentini graciously read the rewrite of Section 7 and his | |||
comments were vital in improving the quality of that effort. | comments were vital in improving the quality of that effort. | |||
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond | Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond | |||
Myklebust were faithful attendants of the biweekly triage meeting and | Myklebust were faithful attendants of the biweekly triage meeting and | |||
accepted many an action item. | accepted many an action item. | |||
Bruce Fields was a good sounding board for both the Third Edge | Bruce Fields was a good sounding board for both the Third Edge | |||
Condition and Courtesy Locks in general. He was also the leading | Condition and Courtesy Locks in general. He was also the leading | |||
advocate of stamping out backport issues from [31]. | advocate of stamping out backport issues from [RFC5661]. | |||
Marcel Telka was a champion of straightening out the difference | Marcel Telka was a champion of straightening out the difference | |||
between a lock-owner and an open-owner. He has also been diligent in | between a lock-owner and an open-owner. He has also been diligent in | |||
reviewing the final document. | reviewing the final document. | |||
Appendix B. RFC Editor Notes | Appendix B. RFC Editor Notes | |||
[RFC Editor: please remove this section prior to publishing this | [RFC Editor: please remove this section prior to publishing this | |||
document as an RFC] | document as an RFC] | |||
End of changes. 111 change blocks. | ||||
316 lines changed or deleted | 340 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/ |