draft-ietf-netconf-partial-lock-01.txt		draft-ietf-netconf-partial-lock-02.txt
	NETCONF B. Lengyel		NETCONF B. Lengyel
	Internet-Draft Ericsson Hungary		Internet-Draft Ericsson Hungary
	Intended status: Standards Track M. Bjorklund		Intended status: Standards Track M. Bjorklund
	Expires: August 28, 2008 Tail-f Systems		Expires: December 15, 2008 Tail-f Systems
	February 25, 2008		June 13, 2008
	Partial Lock RPC for NETCONF		Partial Lock RPC for NETCONF
	draft-ietf-netconf-partial-lock-01		draft-ietf-netconf-partial-lock-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 August 28, 2008.		This Internet-Draft will expire on December 15, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The NETCONF protocol defines the lock and unlock RPCs that lock		The NETCONF protocol defines the lock and unlock RPCs that lock
	entire configuration datastores. In some situations, a way to lock		entire configuration datastores. In some situations, a way to lock
	only parts of a configuration datastore is required. This document		only parts of a configuration datastore is required. This document
	skipping to change at page 2, line 15		skipping to change at page 2, line 15
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3		1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
	2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3		2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 4		2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 4
	2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4		2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4
	2.4.1. <partial-lock> . . . . . . . . . . . . . . . . . . . . 4		2.4.1. <partial-lock> . . . . . . . . . . . . . . . . . . . . 4
	2.4.2. <partial-unlock> . . . . . . . . . . . . . . . . . . . 7		2.4.2. <partial-unlock> . . . . . . . . . . . . . . . . . . . 8
	2.5. Modifications to Existing Operations . . . . . . . . . . . 8		2.5. Modifications to Existing Operations . . . . . . . . . . . 9
	2.6. Interactions with Other Capabilities . . . . . . . . . . . 8		2.6. Interactions with Other Capabilities . . . . . . . . . . . 9
	2.6.1. Writable-Running Capability . . . . . . . . . . . . . 8		2.6.1. Writable-Running Capability . . . . . . . . . . . . . 9
	2.6.2. Candidate Configuration Capability . . . . . . . . . . 8		2.6.2. Candidate Configuration Capability . . . . . . . . . . 9
	2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 8		2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 9
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Appendix A - Change Log . . . . . . . . . . . . . . . . . . 10		5. Appendix A - XML Schema for Partial Locking (normative) . . 11
	5.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Appendix B - YANG Module for Partial Locking		6. Appendix B - YANG Module for Partial Locking
	(non-normative) . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Appendix C - XML Schema for Partial Locking
	(non-normative) . . . . . . . . . . . . . . . . . . . . . . . 13		(non-normative) . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 15
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 16		7.1. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		7.2. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		7.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
			9.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The NETCONF protocol [RFC4741] describes the lock and unlock RPCs		The NETCONF protocol [NETCONF] describes the lock and unlock RPCs
	that operate on entire configuration datastores. Often, multiple		that operate on entire configuration datastores. Often, multiple
	management sessions need to be able to modify the configuration of a		management sessions need to be able to modify the configuration of a
	managed device in parallel. In these cases, locking only parts of a		managed device in parallel. In these cases, locking only parts of a
	configuration datastore is needed. This document defines an		configuration datastore is needed. This document defines an
	extension to the NETCONF protocol to allow this.		extension to the NETCONF protocol to allow this.
	The mechanism for partial locking is based on the existing XPath		The mechanism for partial locking is based on the existing XPath
	filtering mechanisms.		filtering mechanisms.
	Partial locking is defined as a capability to NETCONF.		Partial locking is defined as a capability to NETCONF.
	skipping to change at page 3, line 36		skipping to change at page 3, line 36
	2. Partial Locking Capability		2. Partial Locking Capability
	2.1. Overview		2.1. Overview
	The :partial-lock capability indicates that the device supports the		The :partial-lock capability indicates that the device supports the
	locking of its configuration with a scope smaller then a complete		locking of its configuration with a scope smaller then a complete
	configuration datastore. The scope to be locked is specified by		configuration datastore. The scope to be locked is specified by
	using restricted or full XPath expressions. Partial locking covers		using restricted or full XPath expressions. Partial locking covers
	configuration data, but not state data.		configuration data, but not state data.
	The system ensures that configuration resources covered by the lock		The system MUST ensure that configuration resources covered by the
	are not be modified by other NETCONF or non-NETCONF management		lock are not modified by other NETCONF or non-NETCONF management
	operations such as SNMP and the CLI.		operations such as SNMP and the CLI.
	The duration of the partial lock is defined as beginning when the		The duration of the partial lock is defined as beginning when the
	partial lock is granted and lasting until either the corresponding		partial lock is granted and lasting until either the corresponding
	<partial-unlock> operation succeeds or the NETCONF session		<partial-unlock> operation succeeds or the NETCONF session
	terminates.		terminates.
	A NETCONF session MAY have multiple parts of one or more datastores		A NETCONF session MAY have multiple parts of one or more datastores
	locked using partial lock operations. The <partial-lock> operation		(running, candidate,startup) locked using partial lock operations.
	returns a lock-id to identify each successfully acquired lock.		The <partial-lock> operation returns a lock-id to identify each
			successfully acquired lock.
	2.2. Dependencies		2.2. Dependencies
	Partial locking uses only restricted XPath expressions to describe		The device MUST support the restricted XPath expressions in the
	the lock's scope, as described in Section 2.4.1 for the select		select element, as described in Section 2.4.1 If optionally the
	element. However if optionally the :xpath capability is also		:xpath capability is also supported, the device MUST also support the
	supported, partial locking can utilize any Xpath 1.0 expression.		usage of any XPath 1.0 expression in the select element.
	2.3. Capability Identifier		2.3. Capability Identifier
	urn:ietf:params:netconf:capability:partial-lock:1.0		urn:ietf:params:netconf:capability:partial-lock:1.0
	2.4. New Operations		2.4. New Operations
	2.4.1. <partial-lock>		2.4.1. <partial-lock>
	The <partial-lock> operation allows the client to lock a portion of a		The <partial-lock> operation allows the client to lock a portion of a
	skipping to change at page 4, line 32		skipping to change at page 4, line 32
	expressions in the select elements of the <partial-lock> operation.		expressions in the select elements of the <partial-lock> operation.
	Each XPath expression MUST return a node set.		Each XPath expression MUST return a node set.
	The select XPath expressions are evaluated only once at lock time,		The select XPath expressions are evaluated only once at lock time,
	thereafter the scope of the lock is maintained as a set of nodes. If		thereafter the scope of the lock is maintained as a set of nodes. If
	the configuration data is later altered in a way that would make the		the configuration data is later altered in a way that would make the
	original select XPath expressions evaluate to a different set of		original select XPath expressions evaluate to a different set of
	nodes, this does not affect the scope of the partial lock.		nodes, this does not affect the scope of the partial lock.
	XPath is only used for the creation of the partial lock.		XPath is only used for the creation of the partial lock.
	Conceptually the scope of the lock is defined by the returned nodeset		Conceptually the scope of the lock is defined by the returned node
	and not by the XPath expression.		set and not by the XPath expression.
	A <partial-lock> operation MUST be handled atomically by the NETCONF		A <partial-lock> operation MUST be handled atomically by the NETCONF
	server. The server either locks all requested parts of the data		server. The server either locks all requested parts of the data
	store or none.		store or none; I.e. if during the operation one of the requested
			parts cannot be locked the server MUST unlock all parts that have
			been already locked during that operation.
	If a node is locked by a session, only that same session is able to		If a node is locked by a session, only that same session is able to
	modify that node or any node in the subtree underneath it.		modify that node or any node in the subtree underneath it.
	If a top level node of a locked subtree is deleted, any other session		If a top level node of a locked subtree is deleted, any other session
	can recreate it, as it is not covered by the lock anymore.		can recreate it, as it is not covered by the lock anymore. If all
			top level nodes are deleted, the lock will still be present, however
			it's scope will become nil i.e. it will not cover any nodes.
	A partial lock MUST fail if:		A partial lock MUST fail if:
	o Any NETCONF session (including the current session) owns the		o Any NETCONF session (including the current session) owns the
	global lock on the datastore.		global lock on the datastore.
	o Any part of the scope to be locked is already locked by another		o Any part of the scope to be locked is already locked by another
	management session/protocol, including other NETCONF sessions		management session/protocol, including other NETCONF sessions
	using the <partial-lock> or any other non-NETCONF management		using the <partial-lock> or any other non-NETCONF management
	method.		method.
	o The NETCONF server implements access control and the locking user		o The NETCONF server implements access control and the locking user
	does not have at least some basic access rights, e.g., read		does not have sufficient privileges, to all parts of the datastore
	rights, to all of the datastore section to be locked. The exact		section to be locked. The exact handling of access rights is
	handling of access rights is outside the scope of this document,		outside the scope of this document, but it is assumed that there
	but it is assumed that there is an access control system that MAY		is an access control system that MAY deny or allow the partial
	deny or allow the partial lock operation.		lock operation.
	As with most locking systems, there is a possibility that two users		Note: If partial lock is requested for the running datastore, and the
	trying to lock different parts of the configuration become dead-		NETCONF server implements the :confirmed-commit capability, and there
	locked. To avoid this situation, clients SHOULD lock everything they		was a recent confirmed <commit> operation, where the confirming
	need in one operation. If that operation still fails, the client		<commit> operation has not been received. In this case the lock MUST
	SHOULD back down, release any already acquired locks, and retry the		be denied, because if the confirmation does not arrive, the running
	procedure after some time interval. The length of the interval		datastore MUST be rolled back to its state before the commit, thus
	should preferably be random to avoid repeated dead-locks when both		the NETCONF server might need to modify the configuration.
	(or all) clients back down and then repeat locking.
			As with most locking systems, there is a possibility that two
			management sessions trying to lock different parts of the
			configuration become dead-locked. To avoid this situation, clients
			SHOULD lock everything they need in one operation. If that operation
			still fails, the client SHOULD back down, release any already
			acquired locks, and retry the procedure after some time interval.
			The length of the interval should preferably be random to avoid
			repeated dead-locks when both (or all) clients back down and then
			repeat locking.
	It is the intention to keep partial-locking simple, so when a partial		It is the intention to keep partial-locking simple, so when a partial
	lock is executed you get what you asked for: a set of nodes that are		lock is executed you get what you asked for: a set of nodes that are
	locked for writing. There are some other issues that are		locked for writing. There are some other issues that are
	intentionally not addressed for the sake of simplicity.		intentionally not addressed for the sake of simplicity:
	o Locking does not effect read operations.		o Locking does not affect read operations.
	o If a part of a datastore is locked, this has no effect on any		o If a part of a datastore is locked, this has no effect on any
	unlocked parts of the datastore. If this is a problem e.g. the		unlocked parts of the datastore. If this is a problem e.g. the
	operator's changes depend on data values in the unlocked part of		operator's changes depend on data values in the unlocked part of
	the datastore, the operator should include these values in the		the datastore, the operator should include these values in the
	scope of the lock.		scope of the lock.
	o An operator is allowed to edit the configuration both inside and		o An operator is allowed to edit the configuration both inside and
	outside the scope of a lock. It is the operator's responsibility		outside the scope of a lock. It is the operator's responsibility
	to lock all parts of the datastore that are crucial for a specific		to lock all parts of the datastore that are crucial for a specific
	management action.		management action.
	Note: The <partial-lock> operation does not modify the global <lock>		Note: The <partial-lock> operation does not modify the global <lock>
	operation defined in the base NETCONF Protocol [RFC4741]. If part of		operation defined in the base NETCONF Protocol [NETCONF]. If part of
	a datastore is already locked by <partial-lock>, then a global lock		a datastore is already locked by <partial-lock>, then a global lock
	for that datastore fails even if the global lock is attempted by the		for that datastore fails even if the global lock is attempted by the
	same NETCONF session which owns the partial-lock.		same NETCONF session which owns the partial-lock.
	Parameters:		Parameters:
	target: Name of the configuration datastore of which a part shall be		target: Name of the configuration datastore of which a part shall be
	locked. URLs are not accepted.		locked. One <partial-lock> operation can affect only one of the
			datastores. URLs are not accepted.
	select: One or more 'select' elements each containing an XPath		select: One or more 'select' elements each containing an XPath
	expression. The XPath expression is evaluated in a context where		expression. The XPath expression is evaluated in a context where
	the context node is the root of the server's conceptual data		the context node is the root of the server's conceptual data
	model, and the set of namespace declarations are those in scope		model, and the set of namespace declarations are those in scope
	on the select element.		on the select element.
	The select expressions MUST return a node set.		The select expressions MUST each return a node set, and at least
			one of the node sets must be non-empty.
	If the device supports the :xpath capability as well any valid		If the device supports the :xpath capability as well any valid
	XPath 1.0 expression can be used, if not, the XPath expression		XPath 1.0 expression can be used, if not, the XPath expression
	MUST be limited to an Instance Identifier expression [Editor's		MUST be limited to an Instance Identifier expression. An
	Note: add text or reference]. An Instance Identifier is an		Instance Identifier is an absolute path expression in abbreviated
	absolute path expression in abbreviated syntax, where predicates		syntax, where predicates are used only to specify values for
	are used only to specify values for nodes defined as keys to		nodes defined as keys to distinguish multiple instances.
	distinguish multiple instances.]
	Example: Lock virtual router 1 and interface eth1		Example: Lock virtual router 1 and interface eth1
	<nc:rpc		<nc:rpc
	xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
	xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	xmlns:rte="http://example.com/ns/route">		xmlns:rte="http://example.com/ns/route">
	xmlns:if="http://example.com/ns/interface">		xmlns:if="http://example.com/ns/interface">
	nc:message-id="135">		nc:message-id="135">
	<partial-lock>		<partial-lock>
	<nc:running/>		<nc:running/>
	<select>/routing/virtualRouter['routerName=router1']</select>		<select>/routing/virtualRouter['routerName=router1']</select>
	<select>/interfaces/['interfaceId=eth1']</select>		<select>/interfaces/interface[Id='eth1']</select>
	</partial-lock>		</partial-lock>
	</nc:rpc>		</nc:rpc>
	<nc:rpc-reply		<nc:rpc-reply
	xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
	xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	xmlns:rte="http://example.com/ns/route">		xmlns:rte="http://example.com/ns/route">
	xmlns:if="http://example.com/ns/interface">		xmlns:if="http://example.com/ns/interface">
	nc:message-id="135">		nc:message-id="135">
	<nc:data>		<nc:data>
	skipping to change at page 7, line 11		skipping to change at page 7, line 39
	</nc:rpc-reply>		</nc:rpc-reply>
	Positive Response:		Positive Response:
	If the device was able to satisfy the request, an <rpc-reply> is sent		If the device was able to satisfy the request, an <rpc-reply> is sent
	with a <lock-id> element (lock identifier) in the <data> element.		with a <lock-id> element (lock identifier) in the <data> element.
	Negative Response:		Negative Response:
	If a lock is already held on any node within the subtrees to be		If a lock is already held on any node within the subtrees to be
	locked, the <error-tag> element shall be 'lock-denied' and the		locked, the <error-tag> element is 'lock-denied' and the <error-info>
	<error-info> element shall include the <session-id> of the lock		element includes the <session-id> of the lock owner. If the lock is
	owner. If the lock is held by a non-NETCONF entity, a <session-id>		held by a non-NETCONF entity, a <session-id> of 0 (zero) is included.
	of 0 (zero) is included.
	If the select expressions return an empty node set, the <error-tag>		If the select expressions return an empty node set, the <error-tag>
	shall be 'operation-failed', and the <error-app-tag> shall be 'no-		is 'operation-failed', and the <error-app-tag> is 'no-matches'.
	matches'.
	If any select expression returns anything but a node set, the <error-		If any select expression returns anything but a node set, the <error-
	tag> shall be 'invalid-value'.		tag> is 'invalid-value', the <error-app-tag> is 'XPath does not
			return a node set'.
	If the :xpath capability is not supported and the XPath expression is		If the :xpath capability is not supported and the XPath expression is
	not an Instance Identifier, the <error-tag> shall be 'invalid-value'.		not an Instance Identifier, the <error-tag> is 'invalid-value', the
			<error-app-tag> is ':xpath capability not supported'.
	If access control denies the partial lock, the <error-tag> shall be		If access control denies the partial lock, the <error-tag> is
	'access-denied'.		'access-denied'.
			2.4.1.1. Reserving model sections for future work
			Partial lock can not be used to lock non-existing nodes, effectively
			reserving them for future use. To make sure that a node cannot be
			created by some other session, the parent node should be locked, the
			top level node of the new section created, and then locked with
			another <partial-lock> operation. After this the lock on the parent
			node should be removed.
	2.4.2. <partial-unlock>		2.4.2. <partial-unlock>
	The operation unlocks a part of a datastore that was previously		The operation unlocks a part of a datastore that was previously
	locked using <partial-lock> during the same session.		locked using <partial-lock> during the same session.
	Parameters:		Parameters:
	lock-id: Lock identifier to unlock; taken from a reply to a previous		lock-id: Lock identifier to unlock; taken from a reply to a previous
	<partial-lock> operation.		<partial-lock> operation.
	skipping to change at page 8, line 16		skipping to change at page 9, line 7
	that contains an <ok> element. A positive response MUST be sent even		that contains an <ok> element. A positive response MUST be sent even
	if all of the locked part of the datastore has already been deleted.		if all of the locked part of the datastore has already been deleted.
	Negative Response:		Negative Response:
	If the <lock-id> parameter does not identify a lock which is owned by		If the <lock-id> parameter does not identify a lock which is owned by
	the session, an 'invalid-value' error is returned.		the session, an 'invalid-value' error is returned.
	2.5. Modifications to Existing Operations		2.5. Modifications to Existing Operations
	None.		A granted partial-lock will cause operations that want to modify the
			locked area to fail, if executed in a NETCONF session other then the
			one that owns the lock. Affected operations include: <edit-config>,
			<copy-config>, <delete-config>, <commit> and <discard-changes>. A
			granted partial-lock will also cause the (global) <lock> operation to
			fail. All of these operations are affected only if they are for the
			same datastore.
	2.6. Interactions with Other Capabilities		2.6. Interactions with Other Capabilities
	2.6.1. Writable-Running Capability		2.6.1. Writable-Running Capability
	Partial locking of the running datastore can only be done if the		Partial locking of the running datastore can only be done if the
	:writable-running capability is supported by the device.		:writable-running capability is supported by the device.
	2.6.2. Candidate Configuration Capability		2.6.2. Candidate Configuration Capability
	skipping to change at page 8, line 39		skipping to change at page 9, line 36
	locking of the candidate datastore does not depend on whether the		locking of the candidate datastore does not depend on whether the
	datastore was modified or not.		datastore was modified or not.
	2.6.3. Distinct Startup Capability		2.6.3. Distinct Startup Capability
	Partial locking of the startup datastore can only be done if the		Partial locking of the startup datastore can only be done if the
	:startup capability is supported by the device.		:startup capability is supported by the device.
	3. Security Considerations		3. Security Considerations
	The same considerations as for the base NETCONF Protocol [RFC4741]		The same considerations as for the base NETCONF Protocol [NETCONF]
	are valid. It is assumed that the <partial-lock> and <partial-		are valid. It is assumed that the <partial-lock> and <partial-
	unlock> RPCs are only allowed for an authenticated user after passing		unlock> RPCs are only allowed for an authenticated user after passing
	some access control mechanism.		some access control mechanism.
			A lock either a partial-lock or a global lock might prevent other
			users from configuring the system. The following mechanisms are in
			place to prevent the misuse of this possibility:
			Only an authenticated user after passing access control can
			request a partial-lock.
			The partial-lock is automatically released when a session is
			terminated irrespective of the manner the session ends.
			The <kill-session> operation allows terminating other users
			sessions.
			The NETCONF server may log partial-lock requests in an audit
			trail.
			Partial locking is NOT an authorization mechanism, it should not be
			used to provide security or access control. Partial locking should
			only be used as a mechanism to provide consistency in case of
			multiple managers trying to configure the node. It is vital that the
			operator can easily understand the exact scope of a lock, for this
			reason the scope is determined when granting a lock and is not
			modified dynamically later.
	4. IANA Considerations		4. IANA Considerations
	This document registers a URN for the the following NETCONF		This document registers two URIs for the NETCONF XML namespace in the
	capability in the netconf registry (RFC4741], sect 10.3):		IETF XML registry [RFC3688]. Note that the capability URN is
			compliant to [NETCONF] section 10.3.
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	| Index | Capability Identifier |		| Index | Capability Identifier |
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	| :partial-lock | urn:ietf:params:netconf:capability:partial-lock:1 |		| :partial-lock | urn:ietf:params:netconf:capability:partial-lock:1 |
	| | .0 |		| | .0 |
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	5. Appendix A - Change Log		URI: urn:ietf:params:xml:ns:netconf:partial-lock:1.0
	5.1. Open Issues		Registrant Contact: The IESG.
	Shall we allow the locking of non-existent nodes? The operator		XML: N/A, the requested URI is an XML namespace.
	might want to reserve an object or rather its key/name even if he
	will create the object later.
	Should we include more detailed information in error results to		5. Appendix A - XML Schema for Partial Locking (normative)
	help debug lock conflicts, e.g. the userId of the conflicting
	session, the XPath expression of the conflicting session, the
	instanceId of the first object where the lock conflict was found?
	Should we allow users to lock parts of multiple datastores (e.g.		The following XML Schema defines the <partial-lock> and <partial-
	/top/routing both in the candidate and the running datastore) in		unlock> operations:
	one operation? This would decrease the probability of a dead-
	lock, but currently the (global) <lock> operation doesn't support
	this.
	5.2. -00		<?xml version="1.0" encoding="UTF-8"?>
			<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			targetNamespace="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			elementFormDefault="qualified" attributeFormDefault="unqualified">
	Created from draft-lengyel-ngo-partial-lock-01.txt		<xs:annotation>
			<xs:documentation>
			Schema defining the partial-lock and unlock operations.
			organization "IETF NETCONF Working Group"
			contact
			"Balazs Lengyel
			Ericsson Hungary, Inc.
			balazs.lengyel@ericsson.com"
			</xs:documentation>
			</xs:annotation>
	5.3. 00-01		<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
			schemaLocation="netconf.xsd"/>
	Added YANG module.		<xs:complexType name="partialLockType">
			<xs:complexContent>
			<xs:extension base="nc:rpcOperationType">
			<xs:sequence>
			<xs:element ref="nc:config-name"/>
			<xs:element name="select" type="xs:string"
			maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:extension>
			</xs:complexContent>
			</xs:complexType>
			<xs:complexType name="partialUnLockType">
			<xs:complexContent>
			<xs:extension base="nc:rpcOperationType">
			<xs:sequence>
			<xs:element name="lock-id" type="xs:unsignedInt"/>
			</xs:sequence>
			</xs:extension>
			</xs:complexContent>
			</xs:complexType>
			<!-- <partial-lock> operation -->
			<xs:element name="partial-lock" type="partialLockType"
			substitutionGroup="nc:rpcOperation"/>
			<!-- <partial-unlock> operation -->
			<xs:element name="partial-unlock" type="partialUnLockType"
			substitutionGroup="nc:rpcOperation"/>
			<!-- reply to <partial-lock> -->
			<xs:element name="lock-id" type="xs:unsignedInt"/>
			</xs:schema>
	6. Appendix B - YANG Module for Partial Locking (non-normative)		6. Appendix B - YANG Module for Partial Locking (non-normative)
	The following Yang modul defines the <partial-lock> and <partial-		The following YANG module defines the <partial-lock> and <partial-
	unlock> operations.		unlock> operations. The YANG language is defined in
	This and the following Appendix are non-normative as the method to		[I-D.ietf-netmod-yang].
	define NETCONF operations is not yet agreed. Either the YANG or the
	XSD or some other model will later probably become normative.
	module netconf-partial-lock {		module netconf-partial-lock {
	namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0;		namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0;
	prefix pl;		prefix pl;
	organization "IETF NETCONF Working Group";		organization "IETF NETCONF Working Group";
	contact		contact
	"Balazs Lengyel		"Balazs Lengyel
	Ericsson Hungary, Inc.		Ericsson Hungary, Inc.
	balazs.lengyel@ericsson.com";		balazs.lengyel@ericsson.com";
	description		description
	"This YANG module defines the <partial-lock> and		"This YANG module defines the <partial-lock> and
	<partial-unlock> operations.";		<partial-unlock> operations.";
	revision 2008-01-07 {		revision 2008-06-06 {
	description "Inital version.";		description "Initial version.";
	}		}
	grouping configName {		grouping configName {
	description		description
	"A choice to list the datastore names for NETCONF.		"A choice to list the datastore names for NETCONF.
	This could be moved to a netconf.yang module.";		This could be moved to a netconf.yang module.";
	choice configNameType {		choice configNameType {
	leaf running { type empty; }		leaf running { type empty; }
	leaf candidate { type empty; }		leaf candidate { type empty; }
	leaf startup { type empty; }		leaf startup { type empty; }
	}		}
	}		}
	rpc partial-lock {		rpc partial-lock {
			description "A NETCONF operation that locks part of a datastore.";
	input {		input {
	uses configName;		uses configName;
	leaf-list select {		leaf-list select {
			description
			"XPath expression that specifies the scope of the lock.
			An Instance Identifier expression must be used unless the
			:xpath capability is supported in which case any XPath 1.0
			expression is allowed.";
	type string;		type string;
	min-elements 1;		min-elements 1;
	}		}
	}		}
	output {		output {
	leaf lockId { type uint32; }		leaf lockId {
			description
			"Identifies the lock, if granted. The lockId must be
			used in the partial-unlock rpc.";
			type uint32;
			}
	}		}
	}		}
	rpc partial-unlock {		rpc partial-unlock {
	input {		input {
	leaf lockId { type uint32; }		leaf lockId {
			description
			"Identifies the lock to be released. Must be the value
			received in the response to the partial-lock operation.";
			type uint32;
			}
	}		}
	}		}
	}		}
	7. Appendix C - XML Schema for Partial Locking (non-normative)		7. Appendix C - Change Log
	The following XML Schema defines the <partial-lock> and <partial-		7.1. 01-02
	unlock> operations:
	<?xml version="1.0" encoding="UTF-8"?>		Made XSD normative
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
	targetNamespace="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:annotation>		Clarified that no specific access control is assumed.
	<xs:documentation>
	Schema defining the partial-lock and unlock operations.
	</xs:documentation>
	</xs:annotation>
	<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"		Clarified that non-existing nodes are NOT covered by the lock, even
	schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>		if they where existing and covered by the lock when it was originally
			granted.
	<xs:complexType name="partialLockType">		Some rewording
	<xs:complexContent>
	<xs:extension base="nc:rpcOperationType">
	<xs:sequence>
	<xs:element ref="nc:config-name"/>
	<xs:element name="select" type="xs:string"
	maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="partialUnLockType">		Added app-tags for two of the error cases.
	<xs:complexContent>
	<xs:extension base="nc:rpcOperationType">
	<xs:sequence>
	<xs:element name="lock-id" type="xs:unsignedInt"/>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<!-- <partial-lock> operation -->		Made YANG an informative reference
	<xs:element name="partial-lock" type="partialLockType"
	substitutionGroup="nc:rpcOperation"/>
	<!-- <partial-unlock> operation -->		Enhanced security considerations.
	<xs:element name="partial-unlock" type="partialUnLockType"
	substitutionGroup="nc:rpcOperation"/>
	<!-- reply to <partial-lock> -->		7.2. 00-01
	<xs:element name="lock-id" type="xs:unsignedInt"/>
	</xs:schema>		Added YANG module.
			7.3. -00
			Created from draft-lengyel-ngo-partial-lock-01.txt
	8. Acknowledgements		8. Acknowledgements
	Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer and many other		Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David
	members of the NETCONF WG for providing important input to this		Harrington, Mehmet Ersue and many other members of the NETCONF WG for
	document.		providing important input to this document.
	9. Normative References		9. References
			9.1. Normative References
			[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
			December 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4741] "NETCONF Configuration Protocol", RFC 4741, December 2006.		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
			January 2004.
			9.2. Informative References
			[I-D.ietf-netmod-yang]
			Bjorklund, M., "YANG - A data modeling language for
			NETCONF", draft-ietf-netmod-yang-00 (work in progress),
			May 2008.
	Authors' Addresses		Authors' Addresses
	Balazs Lengyel		Balazs Lengyel
	Ericsson Hungary		Ericsson Hungary
	Email: balazs.lengyel@ericsson.com		Email: balazs.lengyel@ericsson.com
	Martin Bjorklund		Martin Bjorklund
	Tail-f Systems		Tail-f Systems
End of changes. 61 change blocks.
	149 lines changed or deleted		243 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/