rfc7530v3.txt   rfc7530.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
ISSN: 2070-1721 March 2015 ISSN: 2070-1721 March 2015
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
Abstract Abstract
The Network File System (NFS) version 4 protocol is a distributed The Network File System (NFS) version 4 protocol is a distributed
file system protocol that builds on the heritage of NFS protocol file system protocol that builds on the heritage of NFS protocol
version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier
versions, the NFS version 4 protocol supports traditional file access versions, the NFS version 4 protocol supports traditional file access
while integrating support for file locking and the mount protocol. while integrating support for file locking and the MOUNT protocol.
In addition, support for strong security (and its negotiation), In addition, support for strong security (and its negotiation),
COMPOUND operations, client caching, and internationalization has COMPOUND operations, client caching, and internationalization has
been added. Of course, attention has been applied to making NFS been added. Of course, attention has been applied to making NFS
version 4 operate well in an Internet environment. version 4 operate well in an Internet environment.
This document, together with the companion External Data This document, together with the companion External Data
Representation (XDR) description document, RFC 7531, obsoletes RFC Representation (XDR) description document, RFC 7531, obsoletes RFC
3530 as the definition of the NFS version 4 protocol. 3530 as the definition of the NFS version 4 protocol.
Status of This Memo Status of This Memo
skipping to change at page 2, line 32 skipping to change at page 2, line 32
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.2. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . . 7 1.2. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . . 7
1.3. Definitions in the Companion Document RFC 7531 Are 1.3. Definitions in the Companion Document RFC 7531 Are
Authoritative . . . . . . . . . . . . . . . . . . . . . . 8 Authoritative . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Overview of NFSv4 Features . . . . . . . . . . . . . . . 8 1.4. Overview of NFSv4 Features . . . . . . . . . . . . . . . 8
1.4.1. RPC and Security . . . . . . . . . . . . . . . . . . 9 1.4.1. RPC and Security . . . . . . . . . . . . . . . . . . 9
1.4.2. Procedure and Operation Structure . . . . . . . . . . 9 1.4.2. Procedure and Operation Structure . . . . . . . . . . 9
1.4.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10 1.4.3. File System Model . . . . . . . . . . . . . . . . . . 10
1.4.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12 1.4.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12
1.4.5. File Locking . . . . . . . . . . . . . . . . . . . . 12 1.4.5. File Locking . . . . . . . . . . . . . . . . . . . . 12
1.4.6. Client Caching and Delegation . . . . . . . . . . . . 12 1.4.6. Client Caching and Delegation . . . . . . . . . . . . 12
1.5. General Definitions . . . . . . . . . . . . . . . . . . . 13 1.5. General Definitions . . . . . . . . . . . . . . . . . . . 13
1.6. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15 1.6. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15
1.7. Changes between RFC 3010 and RFC 3530 . . . . . . . . . . 16 1.7. Changes between RFC 3010 and RFC 3530 . . . . . . . . . . 16
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 17 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 17
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 17 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 17
2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 20 2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 20
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 41 skipping to change at page 3, line 41
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . . 68
6.3.2. Computing a mode Attribute from an ACL . . . . . . . 69 6.3.2. Computing a mode Attribute from an ACL . . . . . . . 69
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . . 72 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . . 72
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72
7. NFS Server Namespace . . . . . . . . . . . . . . . . . . . . 74 7. NFS Server Namespace . . . . . . . . . . . . . . . . . . . . 74
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 74 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 74
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74
7.3. Server Pseudo-Filesystem . . . . . . . . . . . . . . . . 75 7.3. Server Pseudo-File System . . . . . . . . . . . . . . . . 75
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 76 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 76
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 76 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 76
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76
7.8. Security Policy and Namespace Presentation . . . . . . . 77 7.8. Security Policy and Namespace Presentation . . . . . . . 77
8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 78 8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 78
8.1. Location Attributes . . . . . . . . . . . . . . . . . . . 78 8.1. Location Attributes . . . . . . . . . . . . . . . . . . . 78
8.2. File System Presence or Absence . . . . . . . . . . . . . 78 8.2. File System Presence or Absence . . . . . . . . . . . . . 78
8.3. Getting Attributes for an Absent File System . . . . . . 79 8.3. Getting Attributes for an Absent File System . . . . . . 79
8.3.1. GETATTR within an Absent File System . . . . . . . . 79 8.3.1. GETATTR within an Absent File System . . . . . . . . 79
skipping to change at page 6, line 41 skipping to change at page 6, line 41
16.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 232 16.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 232
16.17. Operation 19: OPENATTR - Open Named Attribute Directory 242 16.17. Operation 19: OPENATTR - Open Named Attribute Directory 242
16.18. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 243 16.18. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 243
16.19. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 245 16.19. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 245
16.20. Operation 22: PUTFH - Set Current Filehandle . . . . . . 246 16.20. Operation 22: PUTFH - Set Current Filehandle . . . . . . 246
16.21. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 247 16.21. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 247
16.22. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 248 16.22. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 248
16.23. Operation 25: READ - Read from File . . . . . . . . . . 249 16.23. Operation 25: READ - Read from File . . . . . . . . . . 249
16.24. Operation 26: READDIR - Read Directory . . . . . . . . . 251 16.24. Operation 26: READDIR - Read Directory . . . . . . . . . 251
16.25. Operation 27: READLINK - Read Symbolic Link . . . . . . 255 16.25. Operation 27: READLINK - Read Symbolic Link . . . . . . 255
16.26. Operation 28: REMOVE - Remove Filesystem Object . . . . 256 16.26. Operation 28: REMOVE - Remove File System Object . . . . 256
16.27. Operation 29: RENAME - Rename Directory Entry . . . . . 258 16.27. Operation 29: RENAME - Rename Directory Entry . . . . . 258
16.28. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 260 16.28. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 260
16.29. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 262 16.29. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 262
16.30. Operation 32: SAVEFH - Save Current Filehandle . . . . . 262 16.30. Operation 32: SAVEFH - Save Current Filehandle . . . . . 262
16.31. Operation 33: SECINFO - Obtain Available Security . . . 263 16.31. Operation 33: SECINFO - Obtain Available Security . . . 263
16.32. Operation 34: SETATTR - Set Attributes . . . . . . . . . 267 16.32. Operation 34: SETATTR - Set Attributes . . . . . . . . . 267
16.33. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 269 16.33. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 269
16.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 273 16.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 273
16.35. Operation 37: VERIFY - Verify Same Attributes . . . . . 276 16.35. Operation 37: VERIFY - Verify Same Attributes . . . . . 276
16.36. Operation 38: WRITE - Write to File . . . . . . . . . . 277 16.36. Operation 38: WRITE - Write to File . . . . . . . . . . 277
skipping to change at page 10, line 8 skipping to change at page 10, line 8
The NFSv4 protocol continues to have the client refer to a file or The NFSv4 protocol continues to have the client refer to a file or
directory at the server by a "filehandle". The COMPOUND procedure directory at the server by a "filehandle". The COMPOUND procedure
has a method of passing a filehandle from one operation to another has a method of passing a filehandle from one operation to another
within the sequence of operations. There is a concept of a current within the sequence of operations. There is a concept of a current
filehandle and a saved filehandle. Most operations use the current filehandle and a saved filehandle. Most operations use the current
filehandle as the file system object to operate upon. The saved filehandle as the file system object to operate upon. The saved
filehandle is used as temporary filehandle storage within a COMPOUND filehandle is used as temporary filehandle storage within a COMPOUND
procedure as well as an additional operand for certain operations. procedure as well as an additional operand for certain operations.
1.4.3. Filesystem Model 1.4.3. File System Model
The general file system model used for the NFSv4 protocol is the same The general file system model used for the NFSv4 protocol is the same
as previous versions. The server file system is hierarchical, with as previous versions. The server file system is hierarchical, with
the regular files contained within being treated as opaque byte the regular files contained within being treated as opaque byte
streams. In a slight departure, file and directory names are encoded streams. In a slight departure, file and directory names are encoded
with UTF-8 to deal with the basics of internationalization. with UTF-8 to deal with the basics of internationalization.
The NFSv4 protocol does not require a separate protocol to provide The NFSv4 protocol does not require a separate protocol to provide
for the initial mapping between pathname and filehandle. Instead of for the initial mapping between pathname and filehandle. Instead of
using the older MOUNT protocol for this mapping, the server provides using the older MOUNT protocol for this mapping, the server provides
skipping to change at page 14, line 5 skipping to change at page 14, line 5
With reference to byte-range locking, the client is also the With reference to byte-range locking, the client is also the
entity that maintains a set of locks on behalf of one or more entity that maintains a set of locks on behalf of one or more
applications. This client is responsible for crash or failure applications. This client is responsible for crash or failure
recovery for those locks it manages. recovery for those locks it manages.
Note that multiple clients may share the same transport and Note that multiple clients may share the same transport and
connection, and multiple clients may exist on the same network connection, and multiple clients may exist on the same network
node. node.
Client ID: The Client ID is a 64-bit quantity used as a unique, Client ID: The client ID is a 64-bit quantity used as a unique,
shorthand reference to a client-supplied verifier and ID. The shorthand reference to a client-supplied verifier and ID. The
server is responsible for supplying the Client ID. server is responsible for supplying the client ID.
File System: The file system is the collection of objects on a File System: The file system is the collection of objects on a
server that share the same fsid attribute (see Section 5.8.1.9). server that share the same fsid attribute (see Section 5.8.1.9).
Lease: A lease is an interval of time defined by the server for Lease: A lease is an interval of time defined by the server for
which the client is irrevocably granted a lock. At the end of a which the client is irrevocably granted a lock. At the end of a
lease period the lock may be revoked if the lease has not been lease period the lock may be revoked if the lease has not been
extended. The lock must be revoked if a conflicting lock has been extended. The lock must be revoked if a conflicting lock has been
granted after the lease interval. granted after the lease interval.
All leases granted by a server have the same fixed duration. Note All leases granted by a server have the same fixed duration. Note
that the fixed interval duration was chosen to alleviate the that the fixed interval duration was chosen to alleviate the
expense a server would have in maintaining state about variable- expense a server would have in maintaining state about variable-
length leases across server failures. length leases across server failures.
Lock: The term "lock" is used to refer to record (byte-range) locks Lock: The term "lock" is used to refer to record (byte-range) locks
as well as share reservations unless specifically stated as well as share reservations unless specifically stated
otherwise. otherwise.
Lock-Owner: Each byte-range lock is associated with a specific lock- Lock-Owner: Each byte-range lock is associated with a specific lock-
owner and an open-owner. The lock-owner consists of a Client ID owner and an open-owner. The lock-owner consists of a client ID
and an opaque owner string. The client presents this to the and an opaque owner string. The client presents this to the
server to establish the ownership of the byte-range lock as server to establish the ownership of the byte-range lock as
needed. needed.
Open-Owner: Each open file is associated with a specific open-owner, Open-Owner: Each open file is associated with a specific open-owner,
which consists of a Client ID and an opaque owner string. The which consists of a client ID and an opaque owner string. The
client presents this to the server to establish the ownership of client presents this to the server to establish the ownership of
the open as needed. the open as needed.
READ Bypass Stateid: The READ Bypass Stateid is a special locking READ Bypass Stateid: The READ Bypass Stateid is a special locking
object and is defined in Section 9.1.4.3. object and is defined in Section 9.1.4.3.
Server: The "server" is the entity responsible for coordinating Server: The "server" is the entity responsible for coordinating
client access to a set of file systems. client access to a set of file systems.
Stable Storage: NFSv4 servers must be able to recover without data Stable Storage: NFSv4 servers must be able to recover without data
skipping to change at page 49, line 47 skipping to change at page 49, line 47
The time of last modification to the object. The time of last modification to the object.
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 used as values of the "who" field within nfs4ace and groups used as values of the who field within nfs4ace structures
structures used in the acl attribute) are represented in the form of used in the acl attribute) are represented in the form of UTF-8
UTF-8 strings. This format avoids the use of a representation that strings. This format avoids the use of a representation that is tied
is tied to a particular underlying implementation at the client or to a particular underlying implementation at the client or server.
server. Note that Section 6.1 of [RFC2624] provides additional Note that Section 6.1 of [RFC2624] provides additional rationale. It
rationale. It is expected that the client and server will have their is expected that the client and server will have their own local
own local representation of owners and groups that is used for local representation of owners and groups that is used for local storage or
storage or presentation to the application via APIs that expect such presentation to the application via APIs that expect such a
a representation. Therefore, the protocol requires that when these representation. Therefore, the protocol requires that when these
attributes are transferred between the client and server, the local attributes are transferred between the client and server, the local
representation is translated to a string of the form representation is translated to a string of the form
"identifier@dns_domain". This allows clients and servers that do not "identifier@dns_domain". This allows clients and servers that do not
use the same local representation to effectively interoperate since use the same local representation to effectively interoperate since
they both use a common syntax that can be interpreted by both. they both use a common syntax that can 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 67, line 7 skipping to change at page 67, line 7
ACE4_IDENTIFIER_GROUP ACE4_IDENTIFIER_GROUP
Indicates that the "who" refers to a GROUP as defined under UNIX Indicates that the "who" refers to a GROUP as defined under UNIX
or a GROUP ACCOUNT as defined under Windows. Clients and servers or a GROUP ACCOUNT as defined under Windows. Clients and servers
MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who
value equal to one of the special identifiers outlined in value equal to one of the special identifiers outlined in
Section 6.2.1.5. Section 6.2.1.5.
6.2.1.5. ACE Who 6.2.1.5. ACE Who
The "who" field of an ACE is an identifier that specifies the The who field of an ACE is an identifier that specifies the principal
principal or principals to whom the ACE applies. It may refer to a or principals to whom the ACE applies. It may refer to a user or a
user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying group, with the flag bit ACE4_IDENTIFIER_GROUP specifying which.
which.
There are several special identifiers that need to be understood There are several special identifiers that need to be understood
universally, rather than in the context of a particular DNS domain. universally, rather than in the context of a particular DNS domain.
Some of these identifiers cannot be understood when an NFS client Some of these identifiers cannot be understood when an NFS client
accesses the server but have meaning when a local process accesses accesses the server but have meaning when a local process accesses
the file. The ability to display and modify these permissions is the file. The ability to display and modify these permissions is
permitted over NFS, even if none of the access methods on the server permitted over NFS, even if none of the access methods on the server
understand the identifiers. understand the identifiers.
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
skipping to change at page 75, line 23 skipping to change at page 75, line 23
An automounter on the client can obtain a snapshot of the server's An automounter on the client can obtain a snapshot of the server's
namespace using the EXPORTS procedure of the MOUNT protocol. If it namespace using the EXPORTS procedure of the MOUNT protocol. If it
understands the server's pathname syntax, it can create an image of understands the server's pathname syntax, it can create an image of
the server's namespace on the client. The parts of the namespace the server's namespace on the client. The parts of the namespace
that are not exported by the server are filled in with a "pseudo-file that are not exported by the server are filled in with a "pseudo-file
system" that allows the user to browse from one mounted file system system" that allows the user to browse from one mounted file system
to another. There is a drawback to this representation of the to another. There is a drawback to this representation of the
server's namespace on the client: it is static. If the server server's namespace on the client: it is static. If the server
administrator adds a new export, the client will be unaware of it. administrator adds a new export, the client will be unaware of it.
7.3. Server Pseudo-Filesystem 7.3. Server Pseudo-File System
NFSv4 servers avoid this namespace inconsistency by presenting all NFSv4 servers avoid this namespace inconsistency by presenting all
the exports within the framework of a single-server namespace. An the exports within the framework of a single-server namespace. An
NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly
from one export to another. Portions of the server namespace that from one export to another. Portions of the server namespace that
are not exported are bridged via a "pseudo-file system" that provides are not exported are bridged via a "pseudo-file system" that provides
a view of exported directories only. A pseudo-file system has a a view of exported directories only. A pseudo-file system has a
unique fsid and behaves like a normal, read-only file system. unique fsid and behaves like a normal, read-only file system.
Based on the construction of the server's namespace, it is possible Based on the construction of the server's namespace, it is possible
skipping to change at page 75, line 47 skipping to change at page 75, line 47
/a/b real file system /a/b real file system
/a/b/c pseudo-file system /a/b/c pseudo-file system
/a/b/c/d real file system /a/b/c/d real file system
Each of the pseudo-file systems are considered separate entities and Each of the pseudo-file systems are considered separate entities and
therefore will have a unique fsid. therefore will have a unique fsid.
7.4. Multiple Roots 7.4. Multiple Roots
The DOS and Windows operating environments are sometimes described as The DOS and Windows operating environments are sometimes described as
having "multiple roots". Filesystems are commonly represented as having "multiple roots". File systems are commonly represented as
disk letters. MacOS represents file systems as top-level names. disk letters. MacOS represents file systems as top-level names.
NFSv4 servers for these platforms can construct a pseudo-file system NFSv4 servers for these platforms can construct a pseudo-file system
above these root names so that disk letters or volume names are above these root names so that disk letters or volume names are
simply directory names in the pseudo-root. simply directory names in the pseudo-root.
7.5. Filehandle Volatility 7.5. Filehandle Volatility
The nature of the server's pseudo-file system is that it is a logical The nature of the server's pseudo-file system is that it is a logical
representation of file system(s) available from the server. representation of file system(s) available from the server.
Therefore, the pseudo-file system is most likely constructed Therefore, the pseudo-file system is most likely constructed
skipping to change at page 92, line 41 skipping to change at page 92, line 41
address, or a zero-length string. A zero-length string SHOULD be address, or a zero-length string. A zero-length string SHOULD be
used to indicate the current address being used for the RPC. It is used to indicate the current address being used for the RPC. It is
not a requirement that all servers that share the same rootpath be not a requirement that all servers that share the same rootpath be
listed in one fs_location4 instance. The array of server names is listed in one fs_location4 instance. The array of server names is
provided for convenience. Servers that share the same rootpath may provided for convenience. Servers that share the same rootpath may
also be listed in separate fs_location4 entries in the fs_locations also be listed in separate fs_location4 entries in the fs_locations
attribute. attribute.
The fs_locations4 data type and fs_locations attribute contain an The fs_locations4 data type and fs_locations attribute contain an
array of such locations. Since the namespace of each server may be array of such locations. Since the namespace of each server may be
constructed differently, the "fs_root" field is provided. The path constructed differently, the fs_root field is provided. The path
represented by the fs_root represents the location of the file system represented by the fs_root represents the location of the file system
in the current server's namespace, i.e., that of the server from in the current server's namespace, i.e., that of the server from
which the fs_locations attribute was obtained. The fs_root path is which the fs_locations attribute was obtained. The fs_root path is
meant to aid the client by clearly referencing the root of the file meant to aid the client by clearly referencing the root of the file
system whose locations are being reported, no matter what object system whose locations are being reported, no matter what object
within the current file system the current filehandle designates. within the current file system the current filehandle designates.
The fs_root is simply the pathname the client used to reach the The fs_root is simply the pathname the client used to reach the
object on the current server (i.e., the object to which the object on the current server (i.e., the object to which the
fs_locations attribute applies). fs_locations attribute applies).
skipping to change at page 101, line 31 skipping to change at page 101, line 31
same type (for example, byte-range locks, opens, or delegations), for same type (for example, byte-range locks, opens, or delegations), for
a specific file or directory, and sharing the same ownership a specific file or directory, and sharing the same ownership
characteristics. The seqid designates a specific instance of such a characteristics. The seqid designates a specific instance of such a
set of locks, and is incremented to indicate changes in such a set of set of locks, and is incremented to indicate changes in such a set of
locks, by either the addition or deletion of locks from the set, a locks, by either the addition or deletion of locks from the set, a
change in the byte-range they apply to, or an upgrade or downgrade in change in the byte-range they apply to, or an upgrade or downgrade in
the type of one or more locks. the type of one or more locks.
When such a set of locks is first created, the server returns a When such a set of locks is first created, the server returns a
stateid with a seqid value of one. On subsequent operations that stateid with a seqid value of one. On subsequent operations that
modify the set of locks, the server is required to advance the modify the set of locks, the server is required to advance the seqid
"seqid" field by one whenever it returns a stateid for the same field by one whenever it returns a stateid for the same state-
state-owner/file/type combination and the operation is one that might owner/file/type combination and the operation is one that might make
make some change in the set of locks actually designated. In this some change in the set of locks actually designated. In this case,
case, the server will return a stateid with an "other" field the same the server will return a stateid with an "other" field the same as
as previously used for that state-owner/file/type combination, with previously used for that state-owner/file/type combination, with an
an incremented "seqid" field. incremented seqid field.
Seqids will be compared, by both the client and the server. The Seqids will be compared, by both the client and the server. The
client uses such comparisons to determine the order of operations, client uses such comparisons to determine the order of operations,
while the server uses them to determine whether the while the server uses them to determine whether the
NFS4ERR_OLD_STATEID error is to be returned. In all cases, the NFS4ERR_OLD_STATEID error is to be returned. In all cases, the
possibility of seqid wraparound needs to be taken into account, as possibility of seqid wraparound needs to be taken into account, as
discussed in Section 9.1.3. discussed in Section 9.1.3.
9.1.4.3. Special Stateids 9.1.4.3. Special Stateids
Stateid values whose "other" field is either all zeros or all ones Stateid values whose "other" field is either all zeros or all ones
are reserved. They MUST NOT be assigned by the server but have are reserved. They MUST NOT be assigned by the server but have
special meanings defined by the protocol. The particular meaning special meanings defined by the protocol. The particular meaning
depends on whether the "other" field is all zeros or all ones and the depends on whether the "other" field is all zeros or all ones and the
specific value of the "seqid" field. specific value of the seqid field.
The following combinations of "other" and "seqid" are defined in The following combinations of "other" and seqid are defined in NFSv4:
NFSv4:
Anonymous Stateid: When "other" and "seqid" are both zero, the Anonymous Stateid: When "other" and seqid are both zero, the stateid
stateid is treated as a special anonymous stateid, which can be is treated as a special anonymous stateid, which can be used in
used in READ, WRITE, and SETATTR requests to indicate the absence READ, WRITE, and SETATTR requests to indicate the absence of any
of any open state associated with the request. When an anonymous open state associated with the request. When an anonymous stateid
stateid value is used, and an existing open denies the form of value is used, and an existing open denies the form of access
access requested, then access will be denied to the request. requested, then access will be denied to the request.
READ Bypass Stateid: When "other" and "seqid" are both all ones, the READ Bypass Stateid: When "other" and seqid are both all ones, the
stateid is a special READ bypass stateid. When this value is used stateid is a special READ bypass stateid. When this value is used
in WRITE or SETATTR, it is treated like the anonymous value. When in WRITE or SETATTR, it is treated like the anonymous value. When
used in READ, the server MAY grant access, even if access would used in READ, the server MAY grant access, even if access would
normally be denied to READ requests. normally be denied to READ requests.
If a stateid value is used that has all zeros or all ones in the If a stateid value is used that has all zeros or all ones in the
"other" field but does not match one of the cases above, the server "other" field but does not match one of the cases above, the server
MUST return the error NFS4ERR_BAD_STATEID. MUST return the error NFS4ERR_BAD_STATEID.
Special stateids, unlike other stateids, are not associated with Special stateids, unlike other stateids, are not associated with
skipping to change at page 103, line 5 skipping to change at page 103, line 5
locks become invalid, without the client requesting they be returned. locks become invalid, without the client requesting they be returned.
These include lease expiration and a number of forms of lock These include lease expiration and a number of forms of lock
revocation within the lease period. It is important to note that in revocation within the lease period. It is important to note that in
these situations, the stateid remains valid and the client can use it these situations, the stateid remains valid and the client can use it
to determine the disposition of the associated lost locks. to determine the disposition of the associated lost locks.
An "other" value must never be reused for a different purpose (i.e., An "other" value must never be reused for a different purpose (i.e.,
different filehandle, owner, or type of locks) within the context of different filehandle, owner, or type of locks) within the context of
a single client ID. A server may retain the "other" value for the a single client ID. A server may retain the "other" value for the
same purpose beyond the point where it may otherwise be freed, but if same purpose beyond the point where it may otherwise be freed, but if
it does so, it must maintain "seqid" continuity with previous values. it does so, it must maintain seqid continuity with previous values.
One mechanism that may be used to satisfy the requirement that the One mechanism that may be used to satisfy the requirement that the
server recognize invalid and out-of-date stateids is for the server server recognize invalid and out-of-date stateids is for the server
to divide the "other" field of the stateid into two fields: to divide the "other" field of the stateid into two fields:
o An index into a table of locking-state structures. o An index into a table of locking-state structures.
o A generation number that is incremented on each allocation of a o A generation number that is incremented on each allocation of a
table entry for a particular use. table entry for a particular use.
skipping to change at page 103, line 28 skipping to change at page 103, line 28
o The client ID with which the stateid is associated. o The client ID with which the stateid is associated.
o The current generation number for the (at most one) valid stateid o The current generation number for the (at most one) valid stateid
sharing this index value. sharing this index value.
o The filehandle of the file on which the locks are taken. o The filehandle of the file on which the locks are taken.
o An indication of the type of stateid (open, byte-range lock, file o An indication of the type of stateid (open, byte-range lock, file
delegation). delegation).
o The last "seqid" value returned corresponding to the current o The last seqid value returned corresponding to the current "other"
"other" value. value.
o An indication of the current status of the locks associated with o An indication of the current status of the locks associated with
this stateid -- in particular, whether these have been revoked this stateid -- in particular, whether these have been revoked
and, if so, for what reason. and, if so, for what reason.
With this information, an incoming stateid can be validated and the With this information, an incoming stateid can be validated and the
appropriate error returned when necessary. Special and non-special appropriate error returned when necessary. Special and non-special
stateids are handled separately. (See Section 9.1.4.3 for a stateids are handled separately. (See Section 9.1.4.3 for a
discussion of special stateids.) discussion of special stateids.)
When a stateid is being tested, and the "other" field is all zeros or When a stateid is being tested, and the "other" field is all zeros or
all ones, a check that the "other" and "seqid" fields match a defined all ones, a check that the "other" and seqid fields match a defined
combination for a special stateid is done and the results determined combination for a special stateid is done and the results determined
as follows: as follows:
o If the "other" and "seqid" fields do not match a defined o If the "other" and seqid fields do not match a defined combination
combination associated with a special stateid, the error associated with a special stateid, the error NFS4ERR_BAD_STATEID
NFS4ERR_BAD_STATEID is returned. is returned.
o If the combination is valid in general but is not appropriate to o If the combination is valid in general but is not appropriate to
the context in which the stateid is used (e.g., an all-zero the context in which the stateid is used (e.g., an all-zero
stateid is used when an open stateid is required in a LOCK stateid is used when an open stateid is required in a LOCK
operation), the error NFS4ERR_BAD_STATEID is also returned. operation), the error NFS4ERR_BAD_STATEID is also returned.
o Otherwise, the check is completed and the special stateid is o Otherwise, the check is completed and the special stateid is
accepted as valid. accepted as valid.
When a stateid is being tested, and the "other" field is neither all When a stateid is being tested, and the "other" field is neither all
skipping to change at page 104, line 40 skipping to change at page 104, line 40
o If the stateid type is not valid for the context in which the o If the stateid type is not valid for the context in which the
stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid
may be valid in general but invalid for a particular operation, may be valid in general but invalid for a particular operation,
as, for example, when a stateid that doesn't represent byte-range as, for example, when a stateid that doesn't represent byte-range
locks is passed to the non-from_open case of LOCK or to LOCKU, or locks is passed to the non-from_open case of LOCK or to LOCKU, or
when a stateid that does not represent an open is passed to CLOSE when a stateid that does not represent an open is passed to CLOSE
or OPEN_DOWNGRADE. In such cases, the server MUST return or OPEN_DOWNGRADE. In such cases, the server MUST return
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
o If the "seqid" field is not zero and it is later than the current o If the seqid field is not zero and it is later than the current
sequence value corresponding to the current "other" field, return sequence value corresponding to the current "other" field, return
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
o If the "seqid" field is earlier than the current sequence value o If the seqid field is earlier than the current sequence value
corresponding to the current "other" field, return corresponding to the current "other" field, return
NFS4ERR_OLD_STATEID. NFS4ERR_OLD_STATEID.
o Otherwise, the stateid is valid, and the table entry should o Otherwise, the stateid is valid, and the table entry should
contain any additional information about the type of stateid and contain any additional information about the type of stateid and
information associated with that particular type of stateid, such information associated with that particular type of stateid, such
as the associated set of locks (e.g., open-owner and lock-owner as the associated set of locks (e.g., open-owner and lock-owner
information), as well as information on the specific locks information), as well as information on the specific locks
themselves, such as open modes and byte ranges. themselves, such as open modes and byte ranges.
skipping to change at page 130, line 9 skipping to change at page 130, line 9
When multiple open files on the client are merged into a single open When multiple open files on the client are merged into a single open
file object on the server, the close of one of the open files (on the file object on the server, the close of one of the open files (on the
client) may necessitate change of the access and deny status of the client) may necessitate change of the access and deny status of the
open file on the server. This is because the union of the access and open file on the server. This is because the union of the access and
deny bits for the remaining opens may be smaller (i.e., a proper deny bits for the remaining opens may be smaller (i.e., a proper
subset) than previously. The OPEN_DOWNGRADE operation is used to subset) than previously. The OPEN_DOWNGRADE operation is used to
make the necessary change, and the client should use it to update the make the necessary change, and the client should use it to update the
server so that share reservation requests by other clients are server so that share reservation requests by other clients are
handled properly. The stateid returned has the same "other" field as handled properly. The stateid returned has the same "other" field as
that passed to the server. The "seqid" value in the returned stateid that passed to the server. The seqid value in the returned stateid
MUST be incremented (Section 9.1.4), even in situations in which MUST be incremented (Section 9.1.4), even in situations in which
there has been no change to the access and deny bits for the file. there has been no change to the access and deny bits for the file.
9.12. Short and Long Leases 9.12. Short and Long Leases
When determining the time period for the server lease, the usual When determining the time period for the server lease, the usual
lease trade-offs apply. Short leases are good for fast server lease trade-offs apply. Short leases are good for fast server
recovery at a cost of increased RENEW or READ (with zero length) recovery at a cost of increased RENEW or READ (with zero length)
requests. Longer leases are certainly kinder and gentler to servers requests. Longer leases are certainly kinder and gentler to servers
trying to handle very large numbers of clients. The number of RENEW trying to handle very large numbers of clients. The number of RENEW
skipping to change at page 131, line 24 skipping to change at page 131, line 24
alternative server (e.g., in response to server unresponsiveness) in alternative server (e.g., in response to server unresponsiveness) in
the context of file system replication, the appropriate handling of the context of file system replication, the appropriate handling of
state shared between the client and server (i.e., locks, leases, state shared between the client and server (i.e., locks, leases,
stateids, and client IDs) is as described below. The handling stateids, and client IDs) is as described below. The handling
differs between migration and replication. For a related discussion differs between migration and replication. For a related discussion
of file server state and recovery of same, see the subsections of of file server state and recovery of same, see the subsections of
Section 9.6. Section 9.6.
In cases in which one server is expected to accept opaque values from In cases in which one server is expected to accept opaque values from
the client that originated from another server, the servers SHOULD the client that originated from another server, the servers SHOULD
encode the "opaque" values in big-endian byte order. If this is encode the opaque values in big-endian byte order. If this is done,
done, the new server will be able to parse values like stateids, the new server will be able to parse values like stateids, directory
directory cookies, filehandles, etc. even if their native byte order cookies, filehandles, etc. even if their native byte order is
is different from that of other servers cooperating in the different from that of other servers cooperating in the replication
replication and migration of the file system. and migration of the file system.
9.14.1. Migration and State 9.14.1. Migration and State
In the case of migration, the servers involved in the migration of a In the case of migration, the servers involved in the migration of a
file system SHOULD transfer all server state from the original server file system SHOULD transfer all server state from the original server
to the new server. This must be done in a way that is transparent to to the new server. This must be done in a way that is transparent to
the client. This state transfer will ease the client's transition the client. This state transfer will ease the client's transition
when a file system migration occurs. If the servers are successful when a file system migration occurs. If the servers are successful
in transferring all state, the client will continue to use stateids in transferring all state, the client will continue to use stateids
assigned by the original server. Therefore, the new server must assigned by the original server. Therefore, the new server must
skipping to change at page 179, line 25 skipping to change at page 179, line 25
The resource (quota) hard limit has been exceeded. The user's The resource (quota) hard limit has been exceeded. The user's
resource limit on the server has been exceeded. resource limit on the server has been exceeded.
13.1.4.3. NFS4ERR_EXIST (Error Code 17) 13.1.4.3. NFS4ERR_EXIST (Error Code 17)
A file system object of the specified target name (when creating, A file system object of the specified target name (when creating,
renaming, or linking) already exists. renaming, or linking) already exists.
13.1.4.4. NFS4ERR_FBIG (Error Code 27) 13.1.4.4. NFS4ERR_FBIG (Error Code 27)
The filesystem object is too large. The operation would have caused The file system object is too large. The operation would have caused
a file system object to grow beyond the server's limit. a file system object to grow beyond the server's limit.
13.1.4.5. NFS4ERR_FILE_OPEN (Error Code 10046) 13.1.4.5. NFS4ERR_FILE_OPEN (Error Code 10046)
The operation is not allowed because a file system object involved in The operation is not allowed because a file system object involved in
the operation is currently open. Servers may, but are not required the operation is currently open. Servers may, but are not required
to, disallow linking to, removing, or renaming open file system to, disallow linking to, removing, or renaming open file system
objects. objects.
13.1.4.6. NFS4ERR_IO (Error Code 5) 13.1.4.6. NFS4ERR_IO (Error Code 5)
skipping to change at page 204, line 12 skipping to change at page 204, line 12
of any operation within it. If there is an XDR decoding error in of any operation within it. If there is an XDR decoding error in
this case, an RPC XDR decode error would be returned. The second this case, an RPC XDR decode error would be returned. The second
method would be to make an initial pass to decode the basic COMPOUND method would be to make an initial pass to decode the basic COMPOUND
request and then to XDR decode each of the individual operations, as request and then to XDR decode each of the individual operations, as
the server is ready to execute it. In this case, the server may the server is ready to execute it. In this case, the server may
encounter an XDR decode error during such an operation decode, after encounter an XDR decode error during such an operation decode, after
previous operations within the COMPOUND have been executed. In this previous operations within the COMPOUND have been executed. In this
case, the server would return the error NFS4ERR_BADXDR to signify the case, the server would return the error NFS4ERR_BADXDR to signify the
decode error. decode error.
The COMPOUND arguments contain a "minorversion" field. The initial The COMPOUND arguments contain a minorversion field. The initial and
and default value for this field is 0 (zero). This field will be default value for this field is 0 (zero). This field will be used by
used by future minor versions such that the client can communicate to future minor versions such that the client can communicate to the
the server what minor version is being requested. If the server server what minor version is being requested. If the server receives
receives a COMPOUND procedure with a minorversion field value that it a COMPOUND procedure with a minorversion field value that it does not
does not support, the server MUST return an error of support, the server MUST return an error of
NFS4ERR_MINOR_VERS_MISMATCH and a zero-length resultdata array. NFS4ERR_MINOR_VERS_MISMATCH and a zero-length resultdata array.
Contained within the COMPOUND results is a "status" field. If the Contained within the COMPOUND results is a status field. If the
results array length is non-zero, this status must be equivalent to results array length is non-zero, this status must be equivalent to
the status of the last operation that was executed within the the status of the last operation that was executed within the
COMPOUND procedure. Therefore, if an operation incurred an error, COMPOUND procedure. Therefore, if an operation incurred an error,
then the "status" value will be the same error value as is being then the status value will be the same error value as is being
returned for the operation that failed. returned for the operation that failed.
Note that operations 0 (zero), 1 (one), and 2 (two) are not defined Note that operations 0 (zero), 1 (one), and 2 (two) are not defined
for the COMPOUND procedure. It is possible that the server receives for the COMPOUND procedure. It is possible that the server receives
a request that contains an operation that is less than the first a request that contains an operation that is less than the first
legal operation (OP_ACCESS) or greater than the last legal operation legal operation (OP_ACCESS) or greater than the last legal operation
(OP_RELEASE_LOCKOWNER). In this case, the server's response will (OP_RELEASE_LOCKOWNER). In this case, the server's response will
encode the opcode OP_ILLEGAL rather than the illegal opcode of the encode the opcode OP_ILLEGAL rather than the illegal opcode of the
request. The status field in the ILLEGAL return results will be set request. The status field in the ILLEGAL return results will be set
to NFS4ERR_OP_ILLEGAL. The COMPOUND procedure's return results will to NFS4ERR_OP_ILLEGAL. The COMPOUND procedure's return results will
skipping to change at page 237, line 46 skipping to change at page 237, line 46
case that there is an existing share reservation that conflicts with case that there is an existing share reservation that conflicts with
the OPEN request, the server returns the error NFS4ERR_SHARE_DENIED. the OPEN request, the server returns the error NFS4ERR_SHARE_DENIED.
For a complete SHARE request, the client must provide values for the For a complete SHARE request, the client must provide values for the
owner and seqid fields for the OPEN argument. For additional owner and seqid fields for the OPEN argument. For additional
discussion of share semantics, see Section 9.9. discussion of share semantics, see Section 9.9.
In the case that the client is recovering state from a server In the case that the client is recovering state from a server
failure, the claim field of the OPEN argument is used to signify that failure, the claim field of the OPEN argument is used to signify that
the request is meant to reclaim state previously held. the request is meant to reclaim state previously held.
The "claim" field of the OPEN argument is used to specify the file to The claim field of the OPEN argument is used to specify the file to
be opened and the state information that the client claims to be opened and the state information that the client claims to
possess. There are four basic claim types that cover the various possess. There are four basic claim types that cover the various
situations for an OPEN. They are as follows: situations for an OPEN. They are as follows:
CLAIM_NULL: For the client, this is a new OPEN request, and there is CLAIM_NULL: For the client, this is a new OPEN request, and there is
no previous state associated with the file for the client. no previous state associated with the file for the client.
CLAIM_PREVIOUS: The client is claiming basic OPEN state for a file CLAIM_PREVIOUS: The client is claiming basic OPEN state for a file
that was held previous to a server reboot. This is generally used that was held previous to a server reboot. This is generally used
when a server is returning persistent filehandles; the client may when a server is returning persistent filehandles; the client may
skipping to change at page 239, line 28 skipping to change at page 239, line 28
and name checks. See Section 12.7 for further discussion. and name checks. See Section 12.7 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
reservations for the new OPEN proceeds normally, with no exception reservations for the new OPEN proceeds normally, with no exception
for the existing OPEN held by the same owner. In this case, the for the existing OPEN held by the same owner. In this case, the
stateid returned has an "other" field that matches that of the stateid returned has an "other" field that matches that of the
previous open, while the "seqid" field is incremented to reflect the previous open, while the seqid field is incremented to reflect the
changed status due to the new open (Section 9.1.4). changed status due to the new open (Section 9.1.4).
If the underlying file system at the server is only accessible in a If the underlying file system at the server is only accessible in a
read-only mode and the OPEN request has specified read-only mode and the OPEN request has specified
OPEN4_SHARE_ACCESS_WRITE or OPEN4_SHARE_ACCESS_BOTH, the server will OPEN4_SHARE_ACCESS_WRITE or OPEN4_SHARE_ACCESS_BOTH, the server will
return NFS4ERR_ROFS to indicate a read-only file system. return NFS4ERR_ROFS to indicate a read-only file system.
As with the CREATE operation, the server MUST derive the owner, owner As with the CREATE operation, the server MUST derive the owner, owner
ACE, group, or group ACE if any of the four attributes are required ACE, group, or group ACE if any of the four attributes are required
and supported by the server's file system. For an OPEN with the and supported by the server's file system. For an OPEN with the
skipping to change at page 256, line 48 skipping to change at page 256, line 48
that is not meaningful to the server operating system in a symbolic that is not meaningful to the server operating system in a symbolic
link. A READLINK operation returns the data to the client for link. A READLINK operation returns the data to the client for
interpretation. If different implementations want to share access to interpretation. If different implementations want to share access to
symbolic links, then they must agree on the interpretation of the symbolic links, then they must agree on the interpretation of the
data in the symbolic link. data in the symbolic link.
The READLINK operation is only allowed on objects of type NF4LNK. The READLINK operation is only allowed on objects of type NF4LNK.
The server should return the error NFS4ERR_INVAL if the object is not The server should return the error NFS4ERR_INVAL if the object is not
of type NF4LNK. of type NF4LNK.
16.26. Operation 28: REMOVE - Remove Filesystem Object 16.26. Operation 28: REMOVE - Remove File System Object
16.26.1. SYNOPSIS 16.26.1. SYNOPSIS
(cfh), filename -> change_info (cfh), filename -> change_info
16.26.2. ARGUMENT 16.26.2. ARGUMENT
struct REMOVE4args { struct REMOVE4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
component4 target; component4 target;
}; };
skipping to change at page 285, line 40 skipping to change at page 285, line 40
operations use the CB_COMPOUND procedure as a wrapper. operations use the CB_COMPOUND procedure as a wrapper.
In the processing of the CB_COMPOUND procedure, the client may find In the processing of the CB_COMPOUND procedure, the client may find
that it does not have the available resources to execute any or all that it does not have the available resources to execute any or all
of the operations within the CB_COMPOUND sequence. In this case, the of the operations within the CB_COMPOUND sequence. In this case, the
error NFS4ERR_RESOURCE will be returned for the particular operation error NFS4ERR_RESOURCE will be returned for the particular operation
within the CB_COMPOUND procedure where the resource exhaustion within the CB_COMPOUND procedure where the resource exhaustion
occurred. This assumes that all previous operations within the occurred. This assumes that all previous operations within the
CB_COMPOUND sequence have been evaluated successfully. CB_COMPOUND sequence have been evaluated successfully.
Contained within the CB_COMPOUND results is a "status" field. This Contained within the CB_COMPOUND results is a status field. This
status must be equivalent to the status of the last operation that status must be equivalent to the status of the last operation that
was executed within the CB_COMPOUND procedure. Therefore, if an was executed within the CB_COMPOUND procedure. Therefore, if an
operation incurred an error, then the "status" value will be the same operation incurred an error, then the status value will be the same
error value as is being returned for the operation that failed. error value as is being returned for the operation that failed.
For the definition of the "tag" field, see Section 15.2. For the definition of the tag field, see Section 15.2.
The value of callback_ident is supplied by the client during The value of callback_ident is supplied by the client during
SETCLIENTID. The server must use the client-supplied callback_ident SETCLIENTID. The server must use the client-supplied callback_ident
during the CB_COMPOUND to allow the client to properly identify the during the CB_COMPOUND to allow the client to properly identify the
server. server.
Illegal operation codes are handled in the same way as they are Illegal operation codes are handled in the same way as they are
handled for the COMPOUND procedure. handled for the COMPOUND procedure.
17.2.5. IMPLEMENTATION 17.2.5. IMPLEMENTATION
 End of changes. 37 change blocks. 
72 lines changed or deleted 70 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/