rfc8881v7.txt		rfc8881.txt
	Internet Engineering Task Force (IETF) D. Noveck, Ed.		Internet Engineering Task Force (IETF) D. Noveck, Ed.
	Request for Comments: 8881 NetApp		Request for Comments: 8881 NetApp
	Obsoletes: 5661 C. Lever		Obsoletes: 5661 C. Lever
	Category: Standards Track ORACLE		Category: Standards Track ORACLE
	ISSN: 2070-1721 July 2020		ISSN: 2070-1721 August 2020
	Network File System (NFS) Version 4 Minor Version 1 Protocol		Network File System (NFS) Version 4 Minor Version 1 Protocol
	Abstract		Abstract
	This document describes the Network File System (NFS) version 4 minor		This document describes the Network File System (NFS) version 4 minor
	version 1, including features retained from the base protocol (NFS		version 1, including features retained from the base protocol (NFS
	version 4 minor version 0, which is specified in RFC 7530) and		version 4 minor version 0, which is specified in RFC 7530) and
	protocol extensions made subsequently. The later minor version has		protocol extensions made subsequently. The later minor version has
	no dependencies on NFS version 4 minor version 0, and is considered a		no dependencies on NFS version 4 minor version 0, and is considered a
	skipping to change at line 390 ¶		skipping to change at line 390 ¶
	one in state Rejected, that will need to be addressed in a later		one in state Rejected, that will need to be addressed in a later
	document. This will involve making changes to consensus decisions		document. This will involve making changes to consensus decisions
	reflected in RFC 5661, in situations in which the working group		reflected in RFC 5661, in situations in which the working group
	has decided that the treatment in RFC 5661 is incorrect and needs		has decided that the treatment in RFC 5661 is incorrect and needs
	to be revised to reflect the working group's new consensus and to		to be revised to reflect the working group's new consensus and to
	ensure compatibility with existing implementations that do not		ensure compatibility with existing implementations that do not
	follow the handling described in RFC 5661.		follow the handling described in RFC 5661.
	Note that it is expected that all such errata reports will remain		Note that it is expected that all such errata reports will remain
	relevant to implementors and the authors of an eventual		relevant to implementors and the authors of an eventual
	rfc5661bis, despite the fact that this document, when approved,		rfc5661bis, despite the fact that this document obsoletes RFC 5661
	will obsolete RFC 5661 [66].		[66].
	* There is a need for a new approach to the description of		* There is a need for a new approach to the description of
	internationalization since the current internationalization		internationalization since the current internationalization
	section (Section 14) has never been implemented and does not meet		section (Section 14) has never been implemented and does not meet
	the needs of the NFSv4 protocol. Possible solutions are to create		the needs of the NFSv4 protocol. Possible solutions are to create
	a new internationalization section modeled on that in [68] or to		a new internationalization section modeled on that in [68] or to
	create a new document describing internationalization for all		create a new document describing internationalization for all
	NFSv4 minor versions and reference that document in the RFCs		NFSv4 minor versions and reference that document in the RFCs
	defining both NFSv4.0 and NFSv4.1.		defining both NFSv4.0 and NFSv4.1.
	skipping to change at line 4956 ¶		skipping to change at line 4956 ¶
	Named attributes are accessed by the new OPENATTR operation, which		Named attributes are accessed by the new OPENATTR operation, which
	accesses a hidden directory of attributes associated with a file		accesses a hidden directory of attributes associated with a file
	system object. OPENATTR takes a filehandle for the object and		system object. OPENATTR takes a filehandle for the object and
	returns the filehandle for the attribute hierarchy. The filehandle		returns the filehandle for the attribute hierarchy. The filehandle
	for the named attributes is a directory object accessible by LOOKUP		for the named attributes is a directory object accessible by LOOKUP
	or READDIR and contains files whose names represent the named		or READDIR and contains files whose names represent the named
	attributes and whose data bytes are the value of the attribute. For		attributes and whose data bytes are the value of the attribute. For
	example:		example:
	+==========+===========+=================================+		+----------+-----------+---------------------------------+
	+==========+===========+=================================+
	| LOOKUP | "foo" | ; look up file |		| LOOKUP | "foo" | ; look up file |
	+----------+-----------+---------------------------------+		+----------+-----------+---------------------------------+
	| GETATTR | attrbits | |		| GETATTR | attrbits | |
	+----------+-----------+---------------------------------+		+----------+-----------+---------------------------------+
	| OPENATTR | | ; access foo's named attributes |		| OPENATTR | | ; access foo's named attributes |
	+----------+-----------+---------------------------------+		+----------+-----------+---------------------------------+
	| LOOKUP | "x11icon" | ; look up specific attribute |		| LOOKUP | "x11icon" | ; look up specific attribute |
	+----------+-----------+---------------------------------+		+----------+-----------+---------------------------------+
	| READ | 0,4096 | ; read stream of bytes |		| READ | 0,4096 | ; read stream of bytes |
	+----------+-----------+---------------------------------+		+----------+-----------+---------------------------------+
	skipping to change at line 10237 ¶		skipping to change at line 10236 ¶
	no previous CLOSE operation has been sent to the server, a CLOSE		no previous CLOSE operation has been sent to the server, a CLOSE
	operation must be sent to the server.		operation must be sent to the server.
	* If a file has other open references at the client, then OPEN		* If a file has other open references at the client, then OPEN
	operations must be sent to the server. The appropriate stateids		operations must be sent to the server. The appropriate stateids
	will be provided by the server for subsequent use by the client		will be provided by the server for subsequent use by the client
	since the delegation stateid will no longer be valid. These OPEN		since the delegation stateid will no longer be valid. These OPEN
	requests are done with the claim type of CLAIM_DELEGATE_CUR. This		requests are done with the claim type of CLAIM_DELEGATE_CUR. This
	will allow the presentation of the delegation stateid so that the		will allow the presentation of the delegation stateid so that the
	client can establish the appropriate rights to perform the OPEN.		client can establish the appropriate rights to perform the OPEN.
	(see Section 18.16, which describes the OPEN operation, for		(See Section 18.16, which describes the OPEN operation, for
	details.)		details.)
	* If there are granted byte-range locks, the corresponding LOCK		* If there are granted byte-range locks, the corresponding LOCK
	operations need to be performed. This applies to the		operations need to be performed. This applies to the
	OPEN_DELEGATE_WRITE delegation case only.		OPEN_DELEGATE_WRITE delegation case only.
	* For an OPEN_DELEGATE_WRITE delegation, if at the time of recall		* For an OPEN_DELEGATE_WRITE delegation, if at the time of recall
	the file is not open for OPEN4_SHARE_ACCESS_WRITE/		the file is not open for OPEN4_SHARE_ACCESS_WRITE/
	OPEN4_SHARE_ACCESS_BOTH, all modified data for the file must be		OPEN4_SHARE_ACCESS_BOTH, all modified data for the file must be
	flushed to the server. If the delegation had not existed, the		flushed to the server. If the delegation had not existed, the
	skipping to change at line 27257 ¶		skipping to change at line 27256 ¶
	expansive recovery of file system objects if the metadata server does		expansive recovery of file system objects if the metadata server does
	not get a positive indication from all clients holding a		not get a positive indication from all clients holding a
	LAYOUTIOMODE4_RW layout that they have successfully completed all		LAYOUTIOMODE4_RW layout that they have successfully completed all
	their writes. Sending a LAYOUTCOMMIT (if required) and then		their writes. Sending a LAYOUTCOMMIT (if required) and then
	following with LAYOUTRETURN can provide such an indication and allow		following with LAYOUTRETURN can provide such an indication and allow
	for graceful and efficient recovery.		for graceful and efficient recovery.
	If loca_reclaim is TRUE, the metadata server is free to either		If loca_reclaim is TRUE, the metadata server is free to either
	examine or ignore the value in the field loca_stateid. The metadata		examine or ignore the value in the field loca_stateid. The metadata
	server implementation might or might not encode in its layout stateid		server implementation might or might not encode in its layout stateid
	information that allows the metadate server to perform a consistency		information that allows the metadata server to perform a consistency
	check on the LAYOUTCOMMIT request.		check on the LAYOUTCOMMIT request.
	18.43. Operation 50: LAYOUTGET - Get Layout Information		18.43. Operation 50: LAYOUTGET - Get Layout Information
	18.43.1. ARGUMENT		18.43.1. ARGUMENT
	struct LAYOUTGET4args {		struct LAYOUTGET4args {
	/* CURRENT_FH: file */		/* CURRENT_FH: file */
	bool loga_signal_layout_avail;		bool loga_signal_layout_avail;
	layouttype4 loga_layout_type;		layouttype4 loga_layout_type;
	skipping to change at line 30269 ¶		skipping to change at line 30268 ¶
	principals, is of considerable importance.		principals, is of considerable importance.
	22. IANA Considerations		22. IANA Considerations
	This section uses terms that are defined in [63].		This section uses terms that are defined in [63].
	22.1. IANA Actions		22.1. IANA Actions
	This update does not require any modification of, or additions to,		This update does not require any modification of, or additions to,
	registry entries or registry rules associated with NFSv4.1. However,		registry entries or registry rules associated with NFSv4.1. However,
	since this document obsoletes RFC 8881, IANA has updated all registry		since this document obsoletes RFC 5661, IANA has updated all registry
	entries and registry rules references that point to RFC 5661 to point		entries and registry rules references that point to RFC 5661 to point
	to this document instead.		to this document instead.
	Previous actions by IANA related to NFSv4.1 are listed in the		Previous actions by IANA related to NFSv4.1 are listed in the
	remaining subsections of Section 22.		remaining subsections of Section 22.
	22.2. Named Attribute Definitions		22.2. Named Attribute Definitions
	IANA created a registry called the "NFSv4 Named Attribute Definitions		IANA created a registry called the "NFSv4 Named Attribute Definitions
	Registry".		Registry".
	skipping to change at line 31493 ¶		skipping to change at line 31492 ¶
	The slot sequence can be used as needed, and cases in which it		The slot sequence can be used as needed, and cases in which it
	would be of no use are appropriately noted.		would be of no use are appropriately noted.
	* It had been assumed that the only functions of EXCHANGE_ID were to		* It had been assumed that the only functions of EXCHANGE_ID were to
	inform the server of the client, to create the client ID, and to		inform the server of the client, to create the client ID, and to
	communicate it to the client. When multiple simultaneous		communicate it to the client. When multiple simultaneous
	connections are involved, as often happens when trunking, that		connections are involved, as often happens when trunking, that
	treatment was inadequate in that it ignored the role of		treatment was inadequate in that it ignored the role of
	EXCHANGE_ID in associating the client ID with the connection on		EXCHANGE_ID in associating the client ID with the connection on
	which it was done, so that it could be used by a subsequent		which it was done, so that it could be used by a subsequent
	CREATE_SESSSION whose parameters do not include an explicit client		CREATE_SESSION whose parameters do not include an explicit client
	ID.		ID.
	The new treatment explicitly discusses the role of EXCHANGE_ID in		The new treatment explicitly discusses the role of EXCHANGE_ID in
	associating the client ID with the connection so it can be used by		associating the client ID with the connection so it can be used by
	CREATE_SESSION and in associating a connection with an existing		CREATE_SESSION and in associating a connection with an existing
	session.		session.
	The new treatment can be found in Section 18.35 above. It supersedes		The new treatment can be found in Section 18.35 above. It supersedes
	the treatment in Section 18.35 of RFC 5661 [66].		the treatment in Section 18.35 of RFC 5661 [66].
End of changes. 7 change blocks.
	9 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/