]>

United States of America cel-ietf@chucklever.net

Web and Internet Transport Network File System Version 4 NFS COMPOUND nfsstat4 fattr4 IANA Several numbered NFS version 4 protocol elements, among them operations, callback operations, status codes, file attributes, and the flags of the ACCESS and OPEN operations, are identified by values that no IANA registry records, so protocol extensions under development at the same time can assign the same value to different elements. This document requests an IANA registry for each of these element types, populates the registries from published RFCs, and requires future elements to obtain their values through them. It updates RFC 8178. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Network File System Version 4 Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction , , and together specify three minor versions of the Network File System (NFS) version 4 protocol. Each minor version has exactly two RPC procedures: NULL and COMPOUND. A COMPOUND request carries a sequence of operations, and every NFSv4 file access, locking, session, and pNFS action is expressed as one of those operations. The callback program that a server uses to contact a client likewise has two procedures, CB_NULL and CB_COMPOUND, and a CB_COMPOUND request carries a sequence of callback operations. Each operation returns a status code of type nfsstat4, and file system object metadata is carried in the fattr4 data type as a bitmask and list of individual attributes. Several operations, among them ACCESS and OPEN, carry flag words whose bits and values select the behavior requested or report the behavior provided. The above specifications (and others) assign a numeric value to each operation, callback operation, status code, attribute, and flag. The value is the element's constant in an XDR enumeration, its bit position in a bitmask, or its bit or value within a flag word, and it identifies the element on the wire. specifies a set of permitted mechanisms to extend the NFSv4 protocol, but no registry records which values have been assigned. Assignment of new values is currently handled ad hoc by the nfsv4 Working Group, and authors of concurrent extensions can select the same value for different elements. , for example, records that its values were checked by hand against the specifications the authors were aware of. It has been additionally observed that there is no single place that maps each element to the RFC (or RFCs) where that element is specified. The Working Group assignment mechanism is not how protocol-element-to-numeric-value mappings are commonly handled elsewhere. To address these concerns, this document requests the creation of an IANA registry for each element type, so that value assignment is managed via a well-known and authoritative mechanism. The element types covered are those to which at least one RFC published since has added a value. The document provides an initial set of entries for each registry based on values in published RFCs to date. Lastly, a new assignment mechanism is normatively specified for these elements, updating .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Allocation of Protocol Element Values

Background Each element covered by this document is identified by a non-negative integer. For an operation or callback operation, that integer is the value of the constant in the nfs_opnum4 or nfs_cb_opnum4 enumeration (for example, OP_GETATTR has the value 9), and it selects the arm of the union that carries the operation's arguments and results. For a status code, it is the value of the constant in the nfsstat4 enumeration (for example, NFS4ERR_NOENT has the value 2). For an attribute, it is both the bit position of the attribute within the bitmap4 that appears in a fattr4 and the value of the corresponding XDR constant (for example, FATTR4_SIZE has the value 4). For a flag, it is the value of the XDR constant that a sender combines into a flag word (for example, ACCESS4_READ has the value 0x00000001). permits the addition of previously unspecified operation codes and attributes, of new values to existing enums, and of previously unassigned bit values to a flag word, as XDR extensions, and requires that such an extension to an existing minor version be published as a Proposed Standard. also forbids the deletion or reuse of a value once assigned. However, does not say how the numeric value for a new element is chosen. In practice, an author of an Internet-Draft selects the next value after the highest one the author is aware of. When two drafts are in progress concurrently, both may select the same value, and the collision is discovered only when one of the documents is revised or when implementations of the two features are combined.

The Registries This document creates the registries listed in as the single authoritative sources of value assignments for the elements they cover. The rules below apply to every registry. From the publication of this document onward:

• As required by , a new element is specified in a document published as a Proposed Standard. The registration policy for each registry is therefore Standards Action with Expert Review (Sections and of ), which admits exactly that class of document and matches the policy of the other NFSv4 registries created by . The role of the Designated Expert is described in .
• The document that specifies a new element MUST include an IANA Considerations section requesting that the element be added to the appropriate registry, and MUST obtain the element's numeric value through that request. The XDR constant for the element is derived from the registered value; a document MUST NOT specify a constant that differs from the registered value.
• To eliminate collisions between concurrently developed extensions, values MAY be allocated before publication using the early allocation procedure of . A Working Group document that introduces a new element SHOULD request early allocation once the Working Group has adopted it, and MUST NOT use a value that has not been either registered or early-allocated.
• Values are assigned sequentially, starting from the lowest unassigned value that is not reserved and is within the range the registry makes available for assignment. A value that has been assigned is never assigned again, even if the corresponding element has since been withdrawn from every minor version, because prohibits reuse of a value.
• An element is never removed from a registry. A document that withdraws an element from one or more minor versions updates the entry's Versions column to the minor versions in which the element remains valid and adds itself to the entry's Reference column (). The value remains allocated.
• Per , an element introduced in one minor version is available in all later minor versions unless a later minor version explicitly removes support for it. A document that carries an element unchanged into a new minor version does not change the element's registry entry.

Designated Expert Guidance The Designated Expert's review is confined to the registration itself, not the merits of the element, which are for the IETF consensus process that produced the Proposed Standard.Editor's note: skeletal; to be expanded if the Working Group wants the expert to check more than registry hygiene. The guidance applies to every registry. The expert confirms that:

• The request names the registry that matches the element's type and, for an operation, its direction: the "NFSv4 Operations" registry for an operation sent in a COMPOUND, and the "NFSv4 Callback Operations" registry for one sent in a CB_COMPOUND.
• The requested value is the lowest unassigned value in that registry that is not reserved and is available for assignment, or was previously early-allocated to the same document.
• The name is unique within the registry and follows the naming convention given in the registry's description in .
• The element's XDR definition (the arguments and results of an operation, or the type of an attribute) appears in the requesting document or in a document it normatively references.
• The Versions column is consistent with the minor versions the requesting document says the element is valid in, and the Reference column cites the requesting document.

For a document that withdraws an existing element from one or more minor versions, the expert additionally confirms that the document states which minor versions the change applies to, that the requested Versions value matches that scope, and that the document does not reuse the element's value, renumber the element, or request that the entry be removed.

Updates to RFC 8178 This document updates as follows. describes the addition of previously unspecified operation codes and attributes, of new values to existing enums, and of previously unassigned bit values to a flag word, as XDR extensions. This document adds the requirement that, for each element type for which creates a registry, the numeric value of a new element be allocated from that registry as specified in , rather than being chosen by the author of the extension. continues to govern the publication requirements for an extension that introduces a new element. The registries do not relax those requirements; they only record the outcome of the process. Nothing in this document changes the rules in for XDR extensions to elements not covered by a registry in , nor the rules for creating new minor versions.

Security Considerations This document creates IANA registries and specifies how values in those registries are allocated. It introduces no new protocol behavior and therefore no new security considerations beyond those of the documents that define the individual elements.

IANA Considerations

NFSv4 Parameters Registry Group IANA is requested to create a registry group titled "Network File System Version 4 (NFSv4) Parameters" and to place in it the registries described in , , , , , , , and . Future documents may add registries for other NFSv4 numeric protocol elements to this group. This document does not request that the existing NFSv4 registries created by be moved into the group.

Registry Format Each registry created by this document has the following columns. A registry's description below may add a column.

Value:

The element's numeric value. Values are non-negative integers. A registry of flags records them in hexadecimal.

Name:

The element's name as used in the specifying document, or "Reserved" for a value that is not available for assignment. The registry's description gives the convention that derives the element's XDR constant from the Name. A document that registers a new element MUST follow that convention.

Versions:

The NFSv4 minor versions in which the element is valid, as a range. A range that ends in "+" (for example, "4.1+") is open: the element is valid in the first minor version named and in every later minor version. A range without "+" is closed: "4.0" means valid in NFSv4.0 only, and "4.1-4.2" means valid in NFSv4.1 and NFSv4.2 only. The word "none" means the element has been withdrawn from every minor version. The column is empty for a Reserved value.

Reference:

The RFC that specifies the minor version in which the element was introduced, or the RFC that added the element to an existing minor version, followed by each later RFC that changes the element's definition or its Versions. An RFC that restates the element unchanged in a new minor version is not cited.

The registration policy for each registry is Standards Action with Expert Review (Sections and of ). Guidance for the Designated Expert is in . Early allocation of values is permitted per . Values are assigned sequentially from the lowest unassigned value that is not reserved and is available for assignment; in a registry of flags, the lowest unassigned bit is assigned unless the registry's description says otherwise. Assigned values MUST NOT be reused, and entries MUST NOT be removed (see ).

NFSv4 Operations Registry IANA is requested to create a registry titled "NFSv4 Operations". The Value is the operation's constant in the nfs_opnum4 enumeration and the discriminant that selects the operation's arm of the nfs_argop4 and nfs_resop4 unions. The XDR constant is the Name prefixed with "OP_" (for example, OP_GETATTR for the operation named GETATTR). By convention, the XDR structures carrying the operation's arguments and results are the Name suffixed with "4args" and "4res"; the registry does not record these names. Values 0 through 2 are Reserved because the base specifications begin the nfs_opnum4 enumeration at 3.Editor's note: the base specifications give no reason for starting at 3. If the Working Group would rather leave 0 through 2 unassigned, the three Reserved entries can be dropped from both operation registries. All other unassigned values are available for assignment. Initial contents of the NFSv4 Operations registry

Value	Name	Versions	Reference
0	Reserved
1	Reserved
2	Reserved
3	ACCESS	4.0+
4	CLOSE	4.0+
5	COMMIT	4.0+
6	CREATE	4.0+
7	DELEGPURGE	4.0+
8	DELEGRETURN	4.0+
9	GETATTR	4.0+
10	GETFH	4.0+
11	LINK	4.0+
12	LOCK	4.0+
13	LOCKT	4.0+
14	LOCKU	4.0+
15	LOOKUP	4.0+
16	LOOKUPP	4.0+
17	NVERIFY	4.0+
18	OPEN	4.0+
19	OPENATTR	4.0+
20	OPEN_CONFIRM	4.0
21	OPEN_DOWNGRADE	4.0+
22	PUTFH	4.0+
23	PUTPUBFH	4.0+
24	PUTROOTFH	4.0+
25	READ	4.0+
26	READDIR	4.0+
27	READLINK	4.0+
28	REMOVE	4.0+
29	RENAME	4.0+
30	RENEW	4.0
31	RESTOREFH	4.0+
32	SAVEFH	4.0+
33	SECINFO	4.0+
34	SETATTR	4.0+
35	SETCLIENTID	4.0
36	SETCLIENTID_CONFIRM	4.0
37	VERIFY	4.0+
38	WRITE	4.0+
39	RELEASE_LOCKOWNER	4.0
40	BACKCHANNEL_CTL	4.1+
41	BIND_CONN_TO_SESSION	4.1+
42	EXCHANGE_ID	4.1+
43	CREATE_SESSION	4.1+
44	DESTROY_SESSION	4.1+
45	FREE_STATEID	4.1+
46	GET_DIR_DELEGATION	4.1+
47	GETDEVICEINFO	4.1+
48	GETDEVICELIST	4.1
49	LAYOUTCOMMIT	4.1+
50	LAYOUTGET	4.1+
51	LAYOUTRETURN	4.1+
52	SECINFO_NO_NAME	4.1+
53	SEQUENCE	4.1+
54	SET_SSV	4.1+
55	TEST_STATEID	4.1+
56	WANT_DELEGATION	4.1+
57	DESTROY_CLIENTID	4.1+
58	RECLAIM_COMPLETE	4.1+
59	ALLOCATE	4.2+
60	COPY	4.2+
61	COPY_NOTIFY	4.2+
62	DEALLOCATE	4.2+
63	IO_ADVISE	4.2+
64	LAYOUTERROR	4.2+
65	LAYOUTSTATS	4.2+
66	OFFLOAD_CANCEL	4.2+
67	OFFLOAD_STATUS	4.2+
68	READ_PLUS	4.2+
69	SEEK	4.2+
70	WRITE_SAME	4.2+
71	CLONE	4.2+
72	GETXATTR	4.2+
73	SETXATTR	4.2+
74	LISTXATTRS	4.2+
75	REMOVEXATTR	4.2+
10044	ILLEGAL	4.0+

Values 76 through 10043, and 10045 and above, are unassigned.

NFSv4 Callback Operations Registry IANA is requested to create a registry titled "NFSv4 Callback Operations". The Value is the callback operation's constant in the nfs_cb_opnum4 enumeration and the discriminant that selects the operation's arm of the nfs_cb_argop4 and nfs_cb_resop4 unions. Every Name begins with "CB_". The XDR constant is the Name prefixed with "OP_" (for example, OP_CB_GETATTR for the operation named CB_GETATTR). By convention, the XDR structures carrying the operation's arguments and results are the Name suffixed with "4args" and "4res"; the registry does not record these names. Values 0 through 2 are Reserved for the reason given in . All other unassigned values are available for assignment. Initial contents of the NFSv4 Callback Operations registry

Value	Name	Versions	Reference
0	Reserved
1	Reserved
2	Reserved
3	CB_GETATTR	4.0+
4	CB_RECALL	4.0+
5	CB_LAYOUTRECALL	4.1+
6	CB_NOTIFY	4.1+
7	CB_PUSH_DELEG	4.1+
8	CB_RECALL_ANY	4.1+
9	CB_RECALLABLE_OBJ_AVAIL	4.1+
10	CB_RECALL_SLOT	4.1+
11	CB_SEQUENCE	4.1+
12	CB_WANTS_CANCELLED	4.1+
13	CB_NOTIFY_LOCK	4.1+
14	CB_NOTIFY_DEVICEID	4.1+
15	CB_OFFLOAD	4.2+
10044	CB_ILLEGAL	4.0+

Values 16 through 10043, and 10045 and above, are unassigned.

NFSv4 Status Codes Registry IANA is requested to create a registry titled "NFSv4 Status Codes". The Value is the status code's constant in the nfsstat4 enumeration. The Name is the name of that constant. The name of a code that indicates failure is upper case and is prefixed with "NFS4ERR_" (for example, NFS4ERR_NOENT); the only code that does not indicate failure is NFS4_OK. Values below 10000 mirror the NFS version 3 status codes , which in turn match traditional errno values, and are not available for assignment. Value 10002 is Reserved because the NFSv3 status code with that value, NFS3ERR_NOT_SYNC, has no NFSv4 counterpart, and value 10073 is Reserved because left it unused. All other unassigned values of 10001 or above are available for assignment. The XDR constants for the base minor versions appear in the companion XDR descriptions , , and . Initial contents of the NFSv4 Status Codes registry

Value	Name	Versions	Reference
0	NFS4_OK	4.0+
1	NFS4ERR_PERM	4.0+
2	NFS4ERR_NOENT	4.0+
5	NFS4ERR_IO	4.0+
6	NFS4ERR_NXIO	4.0
13	NFS4ERR_ACCESS	4.0+
17	NFS4ERR_EXIST	4.0+
18	NFS4ERR_XDEV	4.0+
20	NFS4ERR_NOTDIR	4.0+
21	NFS4ERR_ISDIR	4.0+
22	NFS4ERR_INVAL	4.0+
27	NFS4ERR_FBIG	4.0+
28	NFS4ERR_NOSPC	4.0+
30	NFS4ERR_ROFS	4.0+
31	NFS4ERR_MLINK	4.0+
63	NFS4ERR_NAMETOOLONG	4.0+
66	NFS4ERR_NOTEMPTY	4.0+
69	NFS4ERR_DQUOT	4.0+
70	NFS4ERR_STALE	4.0+
10001	NFS4ERR_BADHANDLE	4.0+
10002	Reserved
10003	NFS4ERR_BAD_COOKIE	4.0+
10004	NFS4ERR_NOTSUPP	4.0+
10005	NFS4ERR_TOOSMALL	4.0+
10006	NFS4ERR_SERVERFAULT	4.0+
10007	NFS4ERR_BADTYPE	4.0+
10008	NFS4ERR_DELAY	4.0+
10009	NFS4ERR_SAME	4.0+
10010	NFS4ERR_DENIED	4.0+
10011	NFS4ERR_EXPIRED	4.0+
10012	NFS4ERR_LOCKED	4.0+
10013	NFS4ERR_GRACE	4.0+
10014	NFS4ERR_FHEXPIRED	4.0+
10015	NFS4ERR_SHARE_DENIED	4.0+
10016	NFS4ERR_WRONGSEC	4.0+
10017	NFS4ERR_CLID_INUSE	4.0+
10018	NFS4ERR_RESOURCE	4.0
10019	NFS4ERR_MOVED	4.0+
10020	NFS4ERR_NOFILEHANDLE	4.0+
10021	NFS4ERR_MINOR_VERS_MISMATCH	4.0+
10022	NFS4ERR_STALE_CLIENTID	4.0+
10023	NFS4ERR_STALE_STATEID	4.0
10024	NFS4ERR_OLD_STATEID	4.0+
10025	NFS4ERR_BAD_STATEID	4.0+
10026	NFS4ERR_BAD_SEQID	4.0
10027	NFS4ERR_NOT_SAME	4.0+
10028	NFS4ERR_LOCK_RANGE	4.0+
10029	NFS4ERR_SYMLINK	4.0+
10030	NFS4ERR_RESTOREFH	4.0
10031	NFS4ERR_LEASE_MOVED	4.0
10032	NFS4ERR_ATTRNOTSUPP	4.0+
10033	NFS4ERR_NO_GRACE	4.0+
10034	NFS4ERR_RECLAIM_BAD	4.0+
10035	NFS4ERR_RECLAIM_CONFLICT	4.0+
10036	NFS4ERR_BADXDR	4.0+
10037	NFS4ERR_LOCKS_HELD	4.0+
10038	NFS4ERR_OPENMODE	4.0+
10039	NFS4ERR_BADOWNER	4.0+
10040	NFS4ERR_BADCHAR	4.0+
10041	NFS4ERR_BADNAME	4.0+
10042	NFS4ERR_BAD_RANGE	4.0+
10043	NFS4ERR_LOCK_NOTSUPP	4.0+
10044	NFS4ERR_OP_ILLEGAL	4.0+
10045	NFS4ERR_DEADLOCK	4.0+
10046	NFS4ERR_FILE_OPEN	4.0+
10047	NFS4ERR_ADMIN_REVOKED	4.0+
10048	NFS4ERR_CB_PATH_DOWN	4.0+
10049	NFS4ERR_BADIOMODE	4.1+
10050	NFS4ERR_BADLAYOUT	4.1+
10051	NFS4ERR_BAD_SESSION_DIGEST	4.1+
10052	NFS4ERR_BADSESSION	4.1+
10053	NFS4ERR_BADSLOT	4.1+
10054	NFS4ERR_COMPLETE_ALREADY	4.1+
10055	NFS4ERR_CONN_NOT_BOUND_TO_SESSION	4.1+
10056	NFS4ERR_DELEG_ALREADY_WANTED	4.1+
10057	NFS4ERR_BACK_CHAN_BUSY	4.1+
10058	NFS4ERR_LAYOUTTRYLATER	4.1+
10059	NFS4ERR_LAYOUTUNAVAILABLE	4.1+
10060	NFS4ERR_NOMATCHING_LAYOUT	4.1+
10061	NFS4ERR_RECALLCONFLICT	4.1+
10062	NFS4ERR_UNKNOWN_LAYOUTTYPE	4.1+
10063	NFS4ERR_SEQ_MISORDERED	4.1+
10064	NFS4ERR_SEQUENCE_POS	4.1+
10065	NFS4ERR_REQ_TOO_BIG	4.1+
10066	NFS4ERR_REP_TOO_BIG	4.1+
10067	NFS4ERR_REP_TOO_BIG_TO_CACHE	4.1+
10068	NFS4ERR_RETRY_UNCACHED_REP	4.1+
10069	NFS4ERR_UNSAFE_COMPOUND	4.1+
10070	NFS4ERR_TOO_MANY_OPS	4.1+
10071	NFS4ERR_OP_NOT_IN_SESSION	4.1+
10072	NFS4ERR_HASH_ALG_UNSUPP	4.1+
10073	Reserved
10074	NFS4ERR_CLIENTID_BUSY	4.1+
10075	NFS4ERR_PNFS_IO_HOLE	4.1+
10076	NFS4ERR_SEQ_FALSE_RETRY	4.1+
10077	NFS4ERR_BAD_HIGH_SLOT	4.1+
10078	NFS4ERR_DEADSESSION	4.1+
10079	NFS4ERR_ENCR_ALG_UNSUPP	4.1+
10080	NFS4ERR_PNFS_NO_LAYOUT	4.1+
10081	NFS4ERR_NOT_ONLY_OP	4.1+
10082	NFS4ERR_WRONG_CRED	4.1+
10083	NFS4ERR_WRONG_TYPE	4.1+
10084	NFS4ERR_DIRDELEG_UNAVAIL	4.1+
10085	NFS4ERR_REJECT_DELEG	4.1+
10086	NFS4ERR_RETURNCONFLICT	4.1+
10087	NFS4ERR_DELEG_REVOKED	4.1+
10088	NFS4ERR_PARTNER_NOTSUPP	4.2+
10089	NFS4ERR_PARTNER_NO_AUTH	4.2+
10090	NFS4ERR_UNION_NOTSUPP	4.2+
10091	NFS4ERR_OFFLOAD_DENIED	4.2+
10092	NFS4ERR_WRONG_LFS	4.2+
10093	NFS4ERR_BADLABEL	4.2+
10094	NFS4ERR_OFFLOAD_NO_REQS	4.2+
10095	NFS4ERR_NOXATTR	4.2+
10096	NFS4ERR_XATTR2BIG	4.2+

Values 10097 and above are unassigned.

NFSv4 fattr4 Attributes Registry IANA is requested to create a registry titled "NFSv4 fattr4 Attributes". The Value is both the attribute's bit position in the attribute bitmap and the value of its XDR constant. The XDR constant is the Name in upper case prefixed with "FATTR4" (for example, FATTR4_SIZE for the attribute named size), and the XDR typedef that specifies the attribute's value format is the Name prefixed with "fattr4" (for example, fattr4_size). This registry has one additional column:

XDR Type:

The XDR () data type of the attribute's value, as it appears in the typedef for the attribute in the specifying document. For the base minor versions, the typedefs appear in the companion XDR descriptions , , and .

No value is Reserved, and all unassigned values are available for assignment. Initial contents of the NFSv4 fattr4 Attributes registry

Value	Name	XDR Type	Versions	Reference
0	supported_attrs	bitmap4	4.0+
1	type	nfs_ftype4	4.0+
2	fh_expire_type	uint32_t	4.0+
3	change	changeid4	4.0+
4	size	uint64_t	4.0+
5	link_support	bool	4.0+
6	symlink_support	bool	4.0+
7	named_attr	bool	4.0+
8	fsid	fsid4	4.0+
9	unique_handles	bool	4.0+
10	lease_time	nfs_lease4	4.0+
11	rdattr_error	nfsstat4	4.0+
12	acl	nfsace4<>	4.0+
13	aclsupport	uint32_t	4.0+
14	archive	bool	4.0+
15	cansettime	bool	4.0+
16	case_insensitive	bool	4.0+
17	case_preserving	bool	4.0+
18	chown_restricted	bool	4.0+
19	filehandle	nfs_fh4	4.0+
20	fileid	uint64_t	4.0+
21	files_avail	uint64_t	4.0+
22	files_free	uint64_t	4.0+
23	files_total	uint64_t	4.0+
24	fs_locations	fs_locations4	4.0+
25	hidden	bool	4.0+
26	homogeneous	bool	4.0+
27	maxfilesize	uint64_t	4.0+
28	maxlink	uint32_t	4.0+
29	maxname	uint32_t	4.0+
30	maxread	uint64_t	4.0+
31	maxwrite	uint64_t	4.0+
32	mimetype	ascii_REQUIRED4	4.0+
33	mode	mode4	4.0+
34	no_trunc	bool	4.0+
35	numlinks	uint32_t	4.0+
36	owner	utf8str_mixed	4.0+
37	owner_group	utf8str_mixed	4.0+
38	quota_avail_hard	uint64_t	4.0+
39	quota_avail_soft	uint64_t	4.0+
40	quota_used	uint64_t	4.0+
41	rawdev	specdata4	4.0+
42	space_avail	uint64_t	4.0+
43	space_free	uint64_t	4.0+
44	space_total	uint64_t	4.0+
45	space_used	uint64_t	4.0+
46	system	bool	4.0+
47	time_access	nfstime4	4.0+
48	time_access_set	settime4	4.0+
49	time_backup	nfstime4	4.0+
50	time_create	nfstime4	4.0+
51	time_delta	nfstime4	4.0+
52	time_metadata	nfstime4	4.0+
53	time_modify	nfstime4	4.0+
54	time_modify_set	settime4	4.0+
55	mounted_on_fileid	uint64_t	4.0+
56	dir_notif_delay	nfstime4	4.1+
57	dirent_notif_delay	nfstime4	4.1+
58	dacl	nfsacl41	4.1+
59	sacl	nfsacl41	4.1+
60	change_policy	change_policy4	4.1+
61	fs_status	fs4_status	4.1+
62	fs_layout_types	layouttype4<>	4.1+
63	layout_hint	layouthint4	4.1+
64	layout_types	layouttype4<>	4.1+
65	layout_blksize	uint32_t	4.1+
66	layout_alignment	uint32_t	4.1+
67	fs_locations_info	fs_locations_info4	4.1+
68	mdsthreshold	mdsthreshold4	4.1+
69	retention_get	retention_get4	4.1+
70	retention_set	retention_set4	4.1+
71	retentevt_get	retention_get4	4.1+
72	retentevt_set	retention_set4	4.1+
73	retention_hold	uint64_t	4.1+
74	mode_set_masked	mode_masked4	4.1+
75	suppattr_exclcreat	bitmap4	4.1+
76	fs_charset_cap	fs_charset_cap4	4.1+
77	clone_blksize	uint32_t	4.2+
78	space_freed	uint64_t	4.2+
79	change_attr_type	change_attr_type4	4.2+
80	sec_label	sec_label4	4.2+
81	mode_umask	mode_umask4	4.2+
82	xattr_support	bool	4.2+
83	offline	bool	4.2+
84	time_deleg_access	nfstime4	4.2+
85	time_deleg_modify	nfstime4	4.2+
86	open_arguments	open_arguments4	4.2+

Values 87 and above are unassigned.

NFSv4 ACCESS Flags Registry IANA is requested to create a registry titled "NFSv4 ACCESS Flags". The Value is a bit in the access field of ACCESS4args and in the supported and access fields of ACCESS4resok. The XDR constant is the Name prefixed with "ACCESS4_" (for example, ACCESS4_READ for the flag named READ). Initial contents of the NFSv4 ACCESS Flags registry

Value	Name	Versions	Reference
0x00000001	READ	4.0+
0x00000002	LOOKUP	4.0+
0x00000004	MODIFY	4.0+
0x00000008	EXTEND	4.0+
0x00000010	DELETE	4.0+
0x00000020	EXECUTE	4.0+
0x00000040	XAREAD	4.2+
0x00000080	XAWRITE	4.2+
0x00000100	XALIST	4.2+

Bits 0x00000200 and above are unassigned.

NFSv4 OPEN Share Access Flags Registry IANA is requested to create a registry titled "NFSv4 OPEN Share Access Flags". The Value is a bit or a masked value in the share_access field of OPEN4args and OPEN_DOWNGRADE4args and in the wda_want field of WANT_DELEGATION4args. The XDR constant is the Name prefixed with "OPEN4SHARE_ACCESS" (for example, OPEN4_SHARE_ACCESS_READ for the flag named READ). The values covered by WANT_DELEG_MASK form an enumerated subfield rather than independent bits. A new value in that subfield is assigned sequentially in units of 0x00000100 from the lowest unassigned value; a new flag outside it is assigned the lowest unassigned bit. Initial contents of the NFSv4 OPEN Share Access Flags registry

Value	Name	Versions	Reference
0x00000001	READ	4.0+
0x00000002	WRITE	4.0+
0x00000003	BOTH	4.0+
0x00000000	WANT_NO_PREFERENCE	4.1+
0x00000100	WANT_READ_DELEG	4.1+
0x00000200	WANT_WRITE_DELEG	4.1+
0x00000300	WANT_ANY_DELEG	4.1+
0x00000400	WANT_NO_DELEG	4.1+
0x00000500	WANT_CANCEL	4.1+
0x0000FF00	WANT_DELEG_MASK	4.1+
0x00010000	WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL	4.1+
0x00020000	WANT_PUSH_DELEG_WHEN_UNCONTENDED	4.1+
0x00100000	WANT_DELEG_TIMESTAMPS	4.2+
0x00200000	WANT_OPEN_XOR_DELEGATION	4.2+

Values 0x00000600 through 0x0000FE00 of the WANT_DELEG_MASK subfield, bits 0x00000004 through 0x00000080, bits 0x00040000 through 0x00080000, and bits 0x00400000 and above are unassigned.

NFSv4 OPEN Result Flags Registry IANA is requested to create a registry titled "NFSv4 OPEN Result Flags". The Value is a bit in the rflags field of OPEN4resok. The XDR constant is the Name prefixed with "OPEN4RESULT" (for example, OPEN4_RESULT_CONFIRM for the flag named CONFIRM). Bit 0x00000001 is not assigned by any minor version specification. This document marks it Reserved so that it is never assigned.Editor's note: as with operation values 0 through 2, the Working Group may prefer to leave this bit unassigned. Initial contents of the NFSv4 OPEN Result Flags registry

Value	Name	Versions	Reference
0x00000001	Reserved
0x00000002	CONFIRM	4.0
0x00000004	LOCKTYPE_POSIX	4.0+
0x00000008	PRESERVE_UNLINKED	4.1+
0x00000010	NO_OPEN_STATEID	4.2+
0x00000020	MAY_NOTIFY_LOCK	4.1+

Bits 0x00000040 and above are unassigned.

NFSv4 OPEN Delegation Types Registry IANA is requested to create a registry titled "NFSv4 OPEN Delegation Types". The Value is the delegation type's constant in the open_delegation_type4 enumeration and the discriminant of the open_delegation4 union in OPEN4resok. The XDR constant is the Name prefixed with "OPEN_DELEGATE_" (for example, OPEN_DELEGATE_READ for the delegation type named READ). Initial contents of the NFSv4 OPEN Delegation Types registry

Value	Name	Versions	Reference
0	NONE	4.0+
1	READ	4.0+
2	WRITE	4.0+
3	NONE_EXT	4.1+
4	READ_ATTRS_DELEG	4.2+
5	WRITE_ATTRS_DELEG	4.2+

Values 6 and above are unassigned.

References Normative References This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK] This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of 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 has 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 External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices. This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions. In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that. This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects. In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530. This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This delegation provides the client the right to authoritatively cache metadata on the file locally. This document presents several extensions for both opening the file and delegating it to the client. This document extends NFSv4.2 (see RFC 7863). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK] This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK] The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its 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 has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol. This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.

Open Issues This section is to be removed before publishing as an RFC. Each item below is tracked as an issue in this document's issue tracker, where the detail and the discussion live.

• Whether values 0 through 2 in the operation registries, and 10002 and 10073 in the status code registry, should be marked Reserved, as this revision does, or simply left unassigned.
• Whether the OPEN share_deny flags, which no document since has extended, should nevertheless be registered alongside the share_access flags.
• Whether the Reference column for an element introduced in NFSv4.0 should also cite , which restates every NFSv4.0 element. This revision cites only the introducing specification and the documents that change the element.
• Several section headings in carry the wrong numeric value: (NFS4ERR_BAD_STATEID, 10025, shown as 10026), (NFS4ERR_UNSAFE_COMPOUND, 10069, shown as 10068), and (NFS4ERR_NXIO, 6, shown as 5). The registry uses the values from the XDR in . Errata should be filed if none exist.
• NFS4ERR_RESOURCE is absent from every NFSv4.1 error list in , including , which enumerates the NFSv4.0 errors that NFSv4.1 obsoletes. The only statement that NFSv4.1 withdraws it is a comment in the XDR description. A comment in an XDR description is not normative, and requires explicit removal, so the registry's Versions value of "4.0" for this code rests on the XDR comment alone. An erratum against may be warranted.

Acknowledgments Thanks to Éric Vyncke for suggesting this approach. The editor is grateful to Bill Baker, Greg Marsden, and Martin Thomson for their input and support. Special thanks to Area Director Gorry Fairhurst, NFSv4 Working Group Chair Brian Pawlowski, and NFSv4 Working Group Secretary Thomas Haynes for their guidance and oversight.