draft-ietf-nfsv4-minorversion1-PAv6.txt		draft-ietf-nfsv4-minorversion1-PAv7.txt
	NFSv4 S. Shepler		NFSv4 S. Shepler
	Internet-Draft M. Eisler		Internet-Draft M. Eisler
	Intended status: Standards Track D. Noveck		Intended status: Standards Track D. Noveck
	Expires: May 1, 2010 Editors		Expires: May 2, 2010 Editors
	October 28, 2009		October 29, 2009
	NFS Version 4 Minor Version 1		NFS Version 4 Minor Version 1
	draft-ietf-nfsv4-minorversion1-PAv6.txt		draft-ietf-nfsv4-minorversion1-PAv7.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 1, 2010.		This Internet-Draft will expire on May 2, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 26, line 50		skipping to change at page 26, line 50
	uniquely defines the client so that subsequent instances of the same		uniquely defines the client so that subsequent instances of the same
	client bear the same co_ownerid with a different verifier.		client bear the same co_ownerid with a different verifier.
	There are several considerations for how the client generates the		There are several considerations for how the client generates the
	co_ownerid string:		co_ownerid string:
	o The string should be unique so that multiple clients do not		o The string should be unique so that multiple clients do not
	present the same string. The consequences of two clients		present the same string. The consequences of two clients
	presenting the same string range from one client getting an error		presenting the same string range from one client getting an error
	to one client having its leased state abruptly and unexpectedly		to one client having its leased state abruptly and unexpectedly
	canceled.		cancelled.
	o The string should be selected so that subsequent incarnations		o The string should be selected so that subsequent incarnations
	(e.g. restarts) of the same client cause the client to present the		(e.g. restarts) of the same client cause the client to present the
	same string. The implementor is cautioned from an approach that		same string. The implementor is cautioned from an approach that
	requires the string to be recorded in a local file because this		requires the string to be recorded in a local file because this
	precludes the use of the implementation in an environment where		precludes the use of the implementation in an environment where
	there is no local disk and all file access is from an NFSv4.1		there is no local disk and all file access is from an NFSv4.1
	server.		server.
	o The string should be the same for each server network address that		o The string should be the same for each server network address that
	skipping to change at page 162, line 40		skipping to change at page 162, line 40
	sent with a READ or WRITE operation. It also may set a non-zero		sent with a READ or WRITE operation. It also may set a non-zero
	value in which case the server checks if that seqid is the correct		value in which case the server checks if that seqid is the correct
	one. In that case the server is required to return		one. In that case the server is required to return
	NFS4ERR_OLD_STATEID if the seqid is lower than the most current value		NFS4ERR_OLD_STATEID if the seqid is lower than the most current value
	and NFS4ERR_BAD_STATEID if the seqid is greater than the most current		and NFS4ERR_BAD_STATEID if the seqid is greater than the most current
	value. This would be the common choice in the case of stateids sent		value. This would be the common choice in the case of stateids sent
	with a CLOSE or OPEN_DOWNGRADE. Because OPENs may be sent in		with a CLOSE or OPEN_DOWNGRADE. Because OPENs may be sent in
	parallel for the same owner, a client might close a file without		parallel for the same owner, a client might close a file without
	knowing that an OPEN upgrade had been done by the server, changing		knowing that an OPEN upgrade had been done by the server, changing
	the lock in question. If CLOSE were sent with a zero seqid, the OPEN		the lock in question. If CLOSE were sent with a zero seqid, the OPEN
	upgrade would be canceled before the client even received an		upgrade would be cancelled before the client even received an
	indication that an upgrade had happened.		indication that an upgrade had happened.
	When a stateid is sent by the server to client as part of a callback		When a stateid is sent by the server to client as part of a callback
	operation, it is not subject to checking for a current seqid and		operation, it is not subject to checking for a current seqid and
	returning NFS4ERR_OLD_STATEID. This is because the client is not in		returning NFS4ERR_OLD_STATEID. This is because the client is not in
	a position to know the most up-to-date seqid and thus cannot verify		a position to know the most up-to-date seqid and thus cannot verify
	it. Unless specially noted, the seqid value for a stateid sent by		it. Unless specially noted, the seqid value for a stateid sent by
	the server to the client as part of a callback is required to be zero		the server to the client as part of a callback is required to be zero
	with NFS4ERR_BAD_STATEID returned if it is not.		with NFS4ERR_BAD_STATEID returned if it is not.
	skipping to change at page 445, line 28		skipping to change at page 445, line 28
	};		};
	enum why_no_delegation4 { /* new to v4.1 */		enum why_no_delegation4 { /* new to v4.1 */
	WND4_NOT_WANTED = 0,		WND4_NOT_WANTED = 0,
	WND4_CONTENTION = 1,		WND4_CONTENTION = 1,
	WND4_RESOURCE = 2,		WND4_RESOURCE = 2,
	WND4_NOT_SUPP_FTYPE = 3,		WND4_NOT_SUPP_FTYPE = 3,
	WND4_WRITE_DELEG_NOT_SUPP_FTYPE = 4,		WND4_WRITE_DELEG_NOT_SUPP_FTYPE = 4,
	WND4_NOT_SUPP_UPGRADE = 5,		WND4_NOT_SUPP_UPGRADE = 5,
	WND4_NOT_SUPP_DOWNGRADE = 6,		WND4_NOT_SUPP_DOWNGRADE = 6,
	WND4_CANCELED = 7,		WND4_CANCELLED = 7,
	WND4_IS_DIR = 8		WND4_IS_DIR = 8
	};		};
	union open_none_delegation4 /* new to v4.1 */		union open_none_delegation4 /* new to v4.1 */
	switch (why_no_delegation4 ond_why) {		switch (why_no_delegation4 ond_why) {
	case WND4_CONTENTION:		case WND4_CONTENTION:
	bool ond_server_will_push_deleg;		bool ond_server_will_push_deleg;
	case WND4_RESOURCE:		case WND4_RESOURCE:
	bool ond_server_will_signal_avail;		bool ond_server_will_signal_avail;
	default:		default:
	skipping to change at page 453, line 40		skipping to change at page 453, line 40
	WND4_WRITE_DELEG_NOT_SUPP_FTYPE The server does not support write		WND4_WRITE_DELEG_NOT_SUPP_FTYPE The server does not support write
	delegations on this file type.		delegations on this file type.
	WND4_NOT_SUPP_UPGRADE The server does not support atomic upgrade of		WND4_NOT_SUPP_UPGRADE The server does not support atomic upgrade of
	a read delegation to a write delegation.		a read delegation to a write delegation.
	WND4_NOT_SUPP_DOWNGRADE The server does not support atomic downgrade		WND4_NOT_SUPP_DOWNGRADE The server does not support atomic downgrade
	of a write delegation to a read delegation.		of a write delegation to a read delegation.
	WND4_CANCELED The client specified OPEN4_SHARE_ACCESS_WANT_CANCEL		WND4_CANCELLED The client specified OPEN4_SHARE_ACCESS_WANT_CANCEL
	and now any "want" for this file object is cancelled.		and now any "want" for this file object is cancelled.
	WND4_IS_DIR The specified file object is a directory, and the		WND4_IS_DIR The specified file object is a directory, and the
	operation is OPEN or WANT_DELEGATION which do not support		operation is OPEN or WANT_DELEGATION which do not support
	delegations on directories.		delegations on directories.
	OPEN4_SHARE_ACCESS_WANT_READ_DELEG,		OPEN4_SHARE_ACCESS_WANT_READ_DELEG,
	OPEN_SHARE_ACCESS_WANT_WRITE_DELEG, or		OPEN_SHARE_ACCESS_WANT_WRITE_DELEG, or
	OPEN_SHARE_ACCESS_WANT_ANY_DELEG mean, respectively, the client wants		OPEN_SHARE_ACCESS_WANT_ANY_DELEG mean, respectively, the client wants
	a read, write, or any delegation regardless which of		a read, write, or any delegation regardless which of
	skipping to change at page 589, line 38		skipping to change at page 589, line 38
	client could mistakenly free too many.		client could mistakenly free too many.
	If resource demands prompt it, the server may send another		If resource demands prompt it, the server may send another
	CB_RECALL_ANY with a lower count, even it has not yet received an		CB_RECALL_ANY with a lower count, even it has not yet received an
	acknowledgement from the client for a previous CB_RECALL_ANY with the		acknowledgement from the client for a previous CB_RECALL_ANY with the
	same type mask. Although the possibility exists that these will be		same type mask. Although the possibility exists that these will be
	received by the client in a order different from the order in which		received by the client in a order different from the order in which
	they were sent, any such permutation of the callback stream is		they were sent, any such permutation of the callback stream is
	harmless. It is the job of the client to bring down the size of the		harmless. It is the job of the client to bring down the size of the
	recallable object set in line with each CB_RECALL_ANY received and		recallable object set in line with each CB_RECALL_ANY received and
	until that obligation is met it cannot be canceled or modified by any		until that obligation is met it cannot be cancelled or modified by
	subsequent CB_RECALL_ANY for the same type mask. Thus if the server		any subsequent CB_RECALL_ANY for the same type mask. Thus if the
	sends two CB_RECALL_ANY's, the effect will be the same as if the		server sends two CB_RECALL_ANY's, the effect will be the same as if
	lower count was sent, whatever the order of recall receipt. Note		the lower count was sent, whatever the order of recall receipt. Note
	that this means that a server may not cancel the effect of a		that this means that a server may not cancel the effect of a
	CB_RECALL_ANY by sending another recall with a higher count. When a		CB_RECALL_ANY by sending another recall with a higher count. When a
	CB_RECALL_ANY is received and the count is already within the limit		CB_RECALL_ANY is received and the count is already within the limit
	set or is above a limit that the client is working to get down to,		set or is above a limit that the client is working to get down to,
	that callback has no effect.		that callback has no effect.
	Servers are generally free not to give out recallable objects when		Servers are generally free not to give out recallable objects when
	insufficient resources are available. Note that the effect of such a		insufficient resources are available. Note that the effect of such a
	policy is implicitly to give precedence to existing objects relative		policy is implicitly to give precedence to existing objects relative
	to requested ones, with the result that resources might not be		to requested ones, with the result that resources might not be
	skipping to change at page 595, line 15		skipping to change at page 595, line 15
	20.10.2. RESULT		20.10.2. RESULT
	struct CB_WANTS_CANCELLED4res {		struct CB_WANTS_CANCELLED4res {
	nfsstat4 cwcr_status;		nfsstat4 cwcr_status;
	};		};
	20.10.3. DESCRIPTION		20.10.3. DESCRIPTION
	The CB_WANTS_CANCELLED operation is used to notify the client that		The CB_WANTS_CANCELLED operation is used to notify the client that
	the some or all wants it registered for recallable delegations and		the some or all wants it registered for recallable delegations and
	layouts have been canceled.		layouts have been cancelled.
	If cwca_contended_wants_cancelled is TRUE, this indicates the server		If cwca_contended_wants_cancelled is TRUE, this indicates the server
	will not be pushing to the client any delegations that become		will not be pushing to the client any delegations that become
	available after contention passes.		available after contention passes.
	If cwca_resourced_wants_cancelled is TRUE, this indicates the server		If cwca_resourced_wants_cancelled is TRUE, this indicates the server
	will not notify the client when there are resources on the server to		will not notify the client when there are resources on the server to
	grant delegations or layouts.		grant delegations or layouts.
	After receiving a CB_WANTS_CANCELLED operation, the client is free to		After receiving a CB_WANTS_CANCELLED operation, the client is free to
End of changes. 9 change blocks.
	13 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/