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