draft-ietf-nfsv4-rfc3530bis-18.txt		draft-ietf-nfsv4-rfc3530bis-19.txt
	NFSv4 T. Haynes, Ed.		NFSv4 T. Haynes, Ed.
	Internet-Draft NetApp		Internet-Draft NetApp
	Intended status: Standards Track D. Noveck, Ed.		Intended status: Standards Track D. Noveck, Ed.
	Expires: November 9, 2012 EMC		Expires: March 7, 2013 EMC
	May 08, 2012		September 03, 2012
	Network File System (NFS) Version 4 Protocol		Network File System (NFS) Version 4 Protocol
	draft-ietf-nfsv4-rfc3530bis-18.txt		draft-ietf-nfsv4-rfc3530bis-19.txt
	Abstract		Abstract
	The Network File System (NFS) version 4 is a distributed filesystem		The Network File System (NFS) version 4 is a distributed filesystem
	protocol which owes heritage to NFS protocol version 2, RFC 1094, and		protocol which owes heritage to NFS protocol version 2, RFC 1094, and
	version 3, RFC 1813. Unlike earlier versions, the NFS version 4		version 3, RFC 1813. Unlike earlier versions, the NFS version 4
	protocol supports traditional file access while integrating support		protocol supports traditional file access while integrating support
	for file locking and the mount protocol. In addition, support for		for file locking and the mount protocol. In addition, support for
	strong security (and its negotiation), compound operations, client		strong security (and its negotiation), compound operations, client
	caching, and internationalization have been added. Of course,		caching, and internationalization have been added. Of course,
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 9, 2012.		This Internet-Draft will expire on March 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 5, line 32		skipping to change at page 5, line 32
	9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121		9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121
	9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121		9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121
	9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122		9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122
	9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123		9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123
	9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124		9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124
	9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124		9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124
	9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124		9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124
	9.6.3. Network Partitions and Recovery . . . . . . . . . . 126		9.6.3. Network Partitions and Recovery . . . . . . . . . . 126
	9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134		9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134
	9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 134		9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 134
	9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 136		9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 135
	9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136		9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136
	9.10.1. Close and Retention of State Information . . . . . . 137		9.10.1. Close and Retention of State Information . . . . . . 137
	9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138		9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138
	9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138		9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138
	9.13. Clocks, Propagation Delay, and Calculating Lease		9.13. Clocks, Propagation Delay, and Calculating Lease
	Expiration . . . . . . . . . . . . . . . . . . . . . . . 139		Expiration . . . . . . . . . . . . . . . . . . . . . . . 139
	9.14. Migration, Replication and State . . . . . . . . . . . . 139		9.14. Migration, Replication and State . . . . . . . . . . . . 139
	9.14.1. Migration and State . . . . . . . . . . . . . . . . 140		9.14.1. Migration and State . . . . . . . . . . . . . . . . 140
	9.14.2. Replication and State . . . . . . . . . . . . . . . 141		9.14.2. Replication and State . . . . . . . . . . . . . . . 141
	9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141		9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141
	skipping to change at page 19, line 39		skipping to change at page 19, line 39
	| | String expected to be UTF-8 but no |		| | String expected to be UTF-8 but no |
	| | validation |		| | validation |
	| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |		| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |
	| | String SHOULD be sent UTF-8 and SHOULD be |		| | String SHOULD be sent UTF-8 and SHOULD be |
	| | validated |		| | validated |
	| utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; |		| utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; |
	| | String MUST be sent UTF-8 and MUST be |		| | String MUST be sent UTF-8 and MUST be |
	| | validated |		| | validated |
	| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |		| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
	| | String MUST be sent as ASCII and thus is |		| | String MUST be sent as ASCII and thus is |
	| | automatically UTF.8 |		| | automatically UTF-8 |
	| comptag4 | typedef utf8_expected comptag4; |		| comptag4 | typedef utf8_expected comptag4; |
	| | Tag should be UTF.8 but is not checked |		| | Tag should be UTF-8 but is not checked |
	| component4 | typedef utf8val_RECOMMENDED4 component4; |		| component4 | typedef utf8val_RECOMMENDED4 component4; |
	| | Represents path name components. |		| | Represents path name components. |
	| linktext4 | typedef utf8val_RECOMMENDED4 linktext4; |		| linktext4 | typedef utf8val_RECOMMENDED4 linktext4; |
	| | Symbolic link contents. |		| | Symbolic link contents. |
	| pathname4 | typedef component4 pathname4<>; |		| pathname4 | typedef component4 pathname4<>; |
	| | Represents path name for fs_locations. |		| | Represents path name for fs_locations. |
	| nfs_lockid4 | typedef uint64_t nfs_lockid4; |		| nfs_lockid4 | typedef uint64_t nfs_lockid4; |
	| verifier4 | typedef opaque |		| verifier4 | typedef opaque |
	| | verifier4[NFS4_VERIFIER_SIZE]; |		| | verifier4[NFS4_VERIFIER_SIZE]; |
	| | Verifier used for various operations |		| | Verifier used for various operations |
	skipping to change at page 53, line 40		skipping to change at page 53, line 40
	(ACEs) that are associated with the file system object. Although the		(ACEs) that are associated with the file system object. Although the
	client can read and write the acl attribute, the server is		client can read and write the acl attribute, the server is
	responsible for using the ACL to perform access control. The client		responsible for using the ACL to perform access control. The client
	can use the OPEN or ACCESS operations to check access without		can use the OPEN or ACCESS operations to check access without
	modifying or reading data or metadata.		modifying or reading data or metadata.
	The NFS ACE structure is defined as follows:		The NFS ACE structure is defined as follows:
	typedef uint32_t acetype4;		typedef uint32_t acetype4;
	typedef uint32_t aceflag4;		typedef uint32_t aceflag4;
	typedef uint32_t acemask4;		typedef uint32_t acemask4;
	struct nfsace4 {		struct nfsace4 {
	acetype4 type;		acetype4 type;
	aceflag4 flag;		aceflag4 flag;
	acemask4 access_mask;		acemask4 access_mask;
	utf8val_REQUIRED4 who;		utf8val_REQUIRED4 who;
	};		};
	To determine if a request succeeds, the server processes each nfsace4		To determine if a request succeeds, the server processes each nfsace4
	skipping to change at page 123, line 16		skipping to change at page 123, line 16
	them doing so. Also, clients must be prepared for the possibility		them doing so. Also, clients must be prepared for the possibility
	that this final locking request will be accepted.		that this final locking request will be accepted.
	9.5. Lease Renewal		9.5. Lease Renewal
	The purpose of a lease is to allow a server to remove stale locks		The purpose of a lease is to allow a server to remove stale locks
	that are held by a client that has crashed or is otherwise		that are held by a client that has crashed or is otherwise
	unreachable. It is not a mechanism for cache consistency and lease		unreachable. It is not a mechanism for cache consistency and lease
	renewals may not be denied if the lease interval has not expired.		renewals may not be denied if the lease interval has not expired.
	The following events cause implicit renewal of all of the leases for		The client can implicitly provide a a positive indication that it is
	a given client (i.e., all those sharing a given client ID). Each of		still active and that the associated state held at the server, for
	these is a positive indication that the client is still active and		the client, is still valid. Any operation made with a valid clientid
	that the associated state held at the server, for the client, is		(DELEGPURGE, RENEW, OPEN, LOCK) or a valid stateid (CLOSE,
	still valid.		DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, READ,
			SETATTR, or WRITE) informs the server to renew all of the leases for
	o An OPEN with a valid client ID.		that client (i.e., all those sharing a given client ID). In the
			latter case, the stateid must not be one of the special stateids
	o Any operation made with a valid clientid (DELEGPURGE, RENEW, OPEN,		consisting of all bits 0 or all bits 1.
	LOCK) or a valid stateid (CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN,
	OPEN_CONFIRM, OPEN_DOWNGRADE, READ, SETATTR, or WRITE). In the
	latter case, the stateid must not be one of the special stateids
	consisting of all bits 0 or all bits 1.
	Note that if the client had restarted or rebooted, the client		Note that if the client had restarted or rebooted, the client would
	would not be making these requests without issuing the		not be making these requests without issuing the SETCLIENTID/
	SETCLIENTID/SETCLIENTID_CONFIRM sequence. The use of the		SETCLIENTID_CONFIRM sequence. The use of the SETCLIENTID/
	SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that changes the		SETCLIENTID_CONFIRM sequence (one that changes the client verifier)
	client verifier) notifies the server to drop the locking state		notifies the server to drop the locking state associated with the
	associated with the client. SETCLIENTID/SETCLIENTID_CONFIRM never		client. SETCLIENTID/SETCLIENTID_CONFIRM never renews a lease.
	renews a lease.
	If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID		If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID
	error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be		error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be
	valid hence preventing spurious renewals.		valid hence preventing spurious renewals.
	This approach allows for low overhead lease renewal which scales		This approach allows for low overhead lease renewal which scales
	well. In the typical case no extra RPC calls are required for lease		well. In the typical case no extra RPC calls are required for lease
	renewal and in the worst case one RPC is required every lease period		renewal and in the worst case one RPC is required every lease period
	(i.e., a RENEW operation). The number of locks held by the client is		(i.e., a RENEW operation). The number of locks held by the client is
	not a factor since all state for the client is involved with the		not a factor since all state for the client is involved with the
	lease renewal action.		lease renewal action.
	Since all operations that create a new lease also renew existing		Since all operations that create a new lease also renew existing
	leases, the server must maintain a common lease expiration time for		leases, the server must maintain a common lease expiration time for
End of changes. 10 change blocks.
	31 lines changed or deleted		26 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/