draft-ietf-netconf-partial-lock-05.txt		draft-ietf-netconf-partial-lock-06.txt
	NETCONF B. Lengyel		NETCONF B. Lengyel
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track M. Bjorklund		Intended status: Standards Track M. Bjorklund
	Expires: June 11, 2009 Tail-f Systems		Expires: August 10, 2009 Tail-f Systems
	December 08, 2008		February 06, 2009
	Partial Lock RPC for NETCONF		Partial Lock RPC for NETCONF
	draft-ietf-netconf-partial-lock-05		draft-ietf-netconf-partial-lock-06
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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.
	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."
	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 June 11, 2009.		This Internet-Draft will expire on August 10, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	Abstract		Abstract
	The NETCONF protocol defines the lock and unlock RPCs, used to lock		The NETCONF protocol defines the lock and unlock RPCs, used to 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
	defines a capability-based extension to the NETCONF protocol for		defines a capability-based extension to the NETCONF protocol for
	locking portions of a configuration datastore.		locking portions of a configuration datastore.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 27		skipping to change at page 2, line 31
	2.5. Modifications to Existing Operations . . . . . . . . . . . 11		2.5. Modifications to Existing Operations . . . . . . . . . . . 11
	2.6. Interactions with Other Capabilities . . . . . . . . . . . 12		2.6. Interactions with Other Capabilities . . . . . . . . . . . 12
	2.6.1. Candidate Configuration Capability . . . . . . . . . . 12		2.6.1. Candidate Configuration Capability . . . . . . . . . . 12
	2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 12		2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 12
	2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 12		2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 12
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 12		3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	5. Appendix A - XML Schema for Partial Locking (normative) . . 14		5. Appendix A - XML Schema for Partial Locking (normative) . . 14
	6. Appendix B - YANG Module for Partial Locking		6. Appendix B - YANG Module for Partial Locking
	(non-normative) . . . . . . . . . . . . . . . . . . . . . . . 18		(non-normative) . . . . . . . . . . . . . . . . . . . . . . . 18
	7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 21		7. Appendix C - Usage Example - Reserving nodes for future
	7.1. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 21		editing (non-normative) . . . . . . . . . . . . . . . . . . . 21
	7.2. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. Appendix D - Change Log . . . . . . . . . . . . . . . . . . 26
	7.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.1. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.4. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.2. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.5. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 22		8.3. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		8.4. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		8.5. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.6. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 24		8.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.2. Informative References . . . . . . . . . . . . . . . . . . 24		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . . . . 26		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
			10.2. Informative References . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	The [NETCONF] protocol describes the lock and unlock operations that		The [NETCONF] protocol describes the lock and unlock operations that
	operate on entire configuration datastores. Often, multiple		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 a		configuration datastore is needed. This document defines a
	capability based extension to the NETCONF protocol to support partial		capability based extension to the NETCONF protocol to support partial
	locking of NETCONF datastores using a mechanism based on the existing		locking of NETCONF datastores using a mechanism based on the existing
	skipping to change at page 4, line 6		skipping to change at page 4, line 6
	locking of its configuration with a more limited scope than a		locking of its configuration with a more limited scope than a
	complete configuration datastore. The scope to be locked is		complete configuration datastore. The scope to be locked is
	specified by using restricted or full XPath expressions. Partial		specified by using restricted or full XPath expressions. Partial
	locking only affects configuration data.		locking only affects configuration data.
	The system MUST ensure that configuration resources covered by the		The system MUST ensure that configuration resources covered by the
	lock are not 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 begins when the partial lock is		The duration of the partial lock begins when the partial lock is
	granted and lasts until (1) either the corresponding partial-unlock		granted and lasts until (1) either the corresponding <partial-unlock>
	operation succeeds or (2) the NETCONF session terminates.		operation succeeds or (2) the NETCONF session 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
	(running, candidate, startup) locked using partial lock operations.		(running, candidate, startup) locked using partial lock operations.
	The <partial-lock> operation returns a lock-id to identify each		The <partial-lock> operation returns a lock-id to identify each
	successfully acquired lock.		successfully acquired lock.
	2.1.1. Usage Scenarios		2.1.1. Usage Scenarios
	skipping to change at page 10, line 11		skipping to change at page 10, line 11
	If a lock is already held by another session on any node within the		If a lock is already held by another session on any node within the
	subtrees to be locked, the <error-tag> element is 'lock-denied' and		subtrees to be locked, the <error-tag> element is 'lock-denied' and
	the <error-info> element includes the <session-id> of the lock owner.		the <error-info> element includes the <session-id> of the lock owner.
	If the lock is held by a non-NETCONF session, a <session-id> of 0		If the lock is held by a non-NETCONF session, a <session-id> of 0
	(zero) is included. If needed the returned session-id may be used to		(zero) is included. If needed the returned session-id may be used to
	<kill-session> the NETCONF session holding the lock. The same error		<kill-session> the NETCONF session holding the lock. The same error
	response is returned if the requesting session already holds the		response is returned if the requesting session already holds the
	(global) lock for the same datastore.		(global) lock for the same datastore.
			If any select expression is an invalid XPath expression, the <error-
			tag> is 'invalid-value'.
			If any select expression returns something other than a node set, the
			<error-tag> is 'invalid-value', and the <error-app-tag> is 'not-a-
			node-set'.
	If all the select expressions return an empty node set, the <error-		If all the select expressions return an empty node set, the <error-
	tag> is 'operation-failed', and the <error-app-tag> is 'no-matches'.		tag> is 'operation-failed', and the <error-app-tag> is 'no-matches'.
	If any select expression returns something other than a node set, the		If any of the target datastors does not exist, the <error-tag> is
	<error-tag> is 'invalid-value', the <error-app-tag> is 'not-a-node-		'invalid-value', the <error-app-tag> is 'invalid-lock-specification'
	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> is 'invalid-value', the		not an Instance Identifier, the <error-tag> is 'invalid-value', the
	<error-app-tag> is 'invalid-lock-specification'.		<error-app-tag> is 'invalid-lock-specification'.
	If access control denies the partial lock, the <error-tag> is		If access control denies the partial lock, the <error-tag> is
	'access-denied'.		'access-denied'.
	2.4.1.2. Reserving nodes for future editing		2.4.1.2. Deadlock Avoidance
	Partial lock cannot be used to lock non-existent nodes, which would
	effectively attempt to reserve them for future use. To guarantee
	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.1.3. Deadlock Avoidance
	As with most locking systems, it is possible that two management		As with most locking systems, it is possible that two management
	sessions trying to lock different parts of the configuration could		sessions trying to lock different parts of the configuration could
	become dead-locked. To avoid this situation, clients should lock		become dead-locked. To avoid this situation, clients should lock
	everything they need in one operation. If locking fails, the client		everything they need in one operation. If locking fails, the client
	should back-off, release any previously acquired locks, and retry the		should back-off, release any previously acquired locks, and retry the
	procedure after waiting some randomized time interval.		procedure after waiting some randomized time interval.
	2.4.2. <partial-unlock>		2.4.2. <partial-unlock>
	skipping to change at page 11, line 40		skipping to change at page 11, line 35
	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
	A successful partial lock will cause a subsequent operation to fail		A successful partial lock will cause a subsequent operation to fail
	if that attempts to modify nodes in the protected area of the lock		if that attempts to modify nodes in the protected area of the lock
	and is executed in a NETCONF session other than the session that has		and is executed in a NETCONF session other than the session that has
	been granted the lock. The <error-tag> 'in-use' and the <error-app-		been granted the lock. The <error-tag> 'in-use' and the <error-app-
	tag> 'locked' is returned. All operations that modify the datastore		tag> 'locked' is returned. All operations that modify the datastore
	are affected, including: <edit-config>, <copy-config>, <delete-		are affected, including: <edit-config>, <copy-config>, <delete-
	config>, <commit> and <discard-changes>. If a datastore contains		config>, <commit> and <discard-changes>. If partial lock prevents
	nodes locked by partial lock, this will cause the (global) <lock>		<edit-config> modifying some data, but the operation includes the
	operation to fail. The <error-tag> element 'lock-denied' and an		continue-on-error option, modification of other parts of the
	<error-info> element including the <session-id> of the lock owner		datastore, which are not protected by partial locking, might still
	will be returned. If the lock is held by a non-NETCONF session, a		succeed.
	<session-id> of 0 (zero) is returned.
			If a datastore contains nodes locked by partial lock, this will cause
			the (global) <lock> operation to fail. The <error-tag> element
			'lock-denied' and an <error-info> element including the <session-id>
			of the lock owner will be returned. If the lock is held by a non-
			NETCONF session, a <session-id> of 0 (zero) is returned.
	All of these operations are affected only if they are targeting the		All of these operations are affected only if they are targeting the
	same datastore.		same datastore.
	2.6. Interactions with Other Capabilities		2.6. Interactions with Other Capabilities
	2.6.1. Candidate Configuration Capability		2.6.1. Candidate Configuration Capability
	Partial locking of the candidate datastore can only be done if the		Partial locking of the candidate datastore can only be done if the
	:candidate capability is supported by the device. Partial locking of		:candidate capability is supported by the device. Partial locking of
	skipping to change at page 14, line 21		skipping to change at page 14, line 21
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
	targetNamespace="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"		targetNamespace="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	Schema defining the partial-lock and unlock operations.		Schema defining the partial-lock and unlock operations.
	organization "IETF NETCONF Working Group"		organization "IETF NETCONF Working Group"
	contact		contact
	"Balazs Lengyel		Netconf Working Group
	Ericsson Hungary, Inc.		Mailing list: netconf@ietf.org
			Web: http://www.ietf.org/html.charters/netconf-charter.html
			Balazs Lengyel
	balazs.lengyel@ericsson.com"		balazs.lengyel@ericsson.com"
			revision 2009-01-23
			description Initial version, published as RFC yyyy.
			-- RFC Ed.: replace yyyy with actual RFC number & remove this note.
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"		<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
	schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>		schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
	<xs:simpleType name="lock-id-type">		<xs:simpleType name="lock-id-type">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	A number identifying a specific		A number identifying a specific
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	The following YANG module defines the <partial-lock> and <partial-		The following YANG module defines the <partial-lock> and <partial-
	unlock> operations. The YANG language is defined in		unlock> operations. The YANG language is defined in
	[I-D.ietf-netmod-yang].		[I-D.ietf-netmod-yang].
	module ietf-netconf-partial-lock {		module ietf-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 Network Configuration (netconf) Working Group";
	contact		contact
	"Balazs Lengyel		"Netconf Working Group
			Mailing list: netconf@ietf.org
			Web: http://www.ietf.org/html.charters/netconf-charter.html
			Balazs Lengyel
	Ericsson		Ericsson
	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-12-08 {		revision 2009-01-23 {
	description "Initial version.";		description
			"Initial version, published as RFC yyyy.";
			// RFC Ed.: replace yyyy with actual RFC number & remove this note.
	}		}
	typedef lock-id-type {		typedef lock-id-type {
	description "A number identifying a specific
	partial-lock granted to a session.
	It is allocated by the system, and SHOULD
	be used in the partial-unlock operation.";
	type uint32;		type uint32;
			description
			"A number identifying a specific partial-lock granted to a session.
			It is allocated by the system, and SHOULD be used in the
			partial-unlock operation.";
	}		}
	rpc partial-lock {		rpc partial-lock {
	description		description
	"A NETCONF operation that locks part of one or more datastores.";		"A NETCONF operation that locks part of one or more datastores.";
	input {		input {
	list target {		list target {
	description "A list of one or more datastore names.
	Each list entry must contain a different datastore name.";
	min-elements 1;		min-elements 1;
	max-elements 3;		max-elements 3;
			description
			"A list of one or more datastore names.
			Each list entry must contain a different datastore name.";
	choice datastore {		choice datastore {
	leaf running { type empty; }		leaf running { type empty; }
	leaf candidate { type empty; }		leaf candidate { type empty; }
	leaf startup { type empty; }		leaf startup { type empty; }
	}		}
	}		}
	leaf-list select {		leaf-list select {
			type string;
			min-elements 1;
	description		description
	"XPath expression that specifies the scope of the lock.		"XPath expression that specifies the scope of the lock.
	An Instance Identifier expression MUST be used unless the		An Instance Identifier expression MUST be used unless the
	:xpath capability is supported, in which case any XPath 1.0		:xpath capability is supported, in which case any XPath 1.0
	expression is allowed.";		expression is allowed.";
	type string;
	min-elements 1;
	}		}
	}		}
	output {		output {
	leaf lock-id {		leaf lock-id {
			type lock-id-type;
	description		description
	"Identifies the lock, if granted. The lock-id SHOULD be		"Identifies the lock, if granted. The lock-id SHOULD be
	used in the partial-unlock rpc.";		used in the partial-unlock rpc.";
	type lock-id-type;
	}		}
	container running {		container running {
	leaf-list locked-node {		leaf-list locked-node {
	description "List of locked nodes
	in the running datastore";
	type instance-identifier;		type instance-identifier;
			min-elements 1;
			description
			"List of locked nodes in the running datastore";
	}		}
	}		}
	container candidate {		container candidate {
	leaf-list locked-node {		leaf-list locked-node {
	description "List of locked nodes
	in the candidate datastore";
	type instance-identifier;		type instance-identifier;
			min-elements 1;
			description
			"List of locked nodes in the candidate datastore";
	}		}
	}		}
	container startup {		container startup {
	leaf-list locked-node {		leaf-list locked-node {
	description "List of locked nodes
	in the startup datastore";
	type instance-identifier;		type instance-identifier;
			min-elements 1;
			description
			"List of locked nodes in the startup datastore";
	}		}
	}		}
	}		}
	}		}
	rpc partial-unlock {		rpc partial-unlock {
	description		description
	"A NETCONF operation that releases a previously acquired		"A NETCONF operation that releases a previously acquired
	partial-lock.";		partial-lock.";
	input {		input {
	leaf lock-id {		leaf lock-id {
			type lock-id-type;
	description		description
	"Identifies the lock to be released. MUST be the value		"Identifies the lock to be released. MUST be the value
	received in the response to the partial-lock operation.";		received in the response to the partial-lock operation.";
	type lock-id-type;
	}		}
	}		}
	}		}
	}		}
	7. Appendix C - Change Log		7. Appendix C - Usage Example - Reserving nodes for future editing
			(non-normative)
	7.1. 04-05		Partial lock cannot be used to lock non-existent nodes, which would
			effectively attempt to reserve them for future use. To guarantee
			that a node cannot be created by some other session, the parent node
			should be locked, the top level node of the new subtree created, and
			then locked with another <partial-lock> operation. After this, the
			lock on the parent node should be removed.
			In this chapter an example illustrating the above is given.
			We want to create <user> Joe under <users>, and start editing it.
			Editing might take a number of minutes. We want to immediately lock
			Joe so no one will touch it before we are finished with the editing.
			We also want to minimize locking other parts of the datastore as
			multiple managers might be adding users near simultaneously.
			First we check what users are already defined.
			Step 1 - Read existing users
			<rpc message-id="101"
			xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<get-config>
			<source>
			<running/>
			</source>
			<filter type="subtree">
			<top xmlns="http://example.com/users">
			<users/>
			</top>
			</filter>
			</get-config>
			</rpc>
			The NETCONF server sends the following reply.
			Step 2 - Receiving existing data
			<rpc-reply message-id="101"
			xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<data>
			<top xmlns="http://example.com/users">
			<users>
			<user>
			<name>fred</name>
			<phone>8327</phone>
			</user>
			</users>
			</top>
			</data>
			</rpc-reply>
			We want to add the new user "Joe" and immediately lock him using
			partial locking. The way to do this, is to first lock all <user>
			nodes by locking the <users> node.
			Step 3 - Lock users
			<nc:rpc
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			message-id="102">
			<partial-lock>
			<target>
			<running/>
			</target>
			<select xmlns:usr="http://example.com/users">
			/usr:top/usr:users
			</select>
			</partial-lock>
			</nc:rpc>
			The NETCONF server grants the partial lock. The scope of the lock
			includes only the <users> node. The lock protects the <users> node
			and all <user> nodes below it from modification (by other sessions).
			Step 4 - Receive lock
			<nc:rpc-reply
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			message-id="102">
			<lock-id>1</lock-id>
			<running>
			<locked-node xmlns:usr="http://example.com/users">
			/usr:top/usr:users
			</locked-node>
			</running>
			</nc:rpc-reply>
			Next we create user Joe. Joe is protected by the lock received above,
			as it is under the sub-tree rooted at the <users> node.
			Step 5 - Create user Joe
			<rpc message-id="103"
			xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<edit-config>
			<target>
			<running/>
			</target>
			<config>
			<top xmlns:usr="http://example.com/users">
			<users>
			<user>
			<name>Joe</name>
			</user>
			</users>
			</top>
			</config>
			</edit-config>
			</rpc>
			We receive a positive reply to the <edit-config> (not shown). Next
			we request a lock, that locks only <user> Joe, and release the lock
			on the <users> node. This will allow other managers to create
			additional new users.
			Step 6 - Lock user Joe
			<nc:rpc
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			message-id="104">
			<partial-lock>
			<target>
			<running/>
			</target>
			<select xmlns:usr="http://example.com/users">
			/usr:top/usr:users/user[usr:name="Joe"]"
			</select>
			</partial-lock>
			</nc:rpc>
			The NETCONF server grants the partial lock. The scope of this second
			lock includes only the <user> node with name Joe. The lock protects
			all data below this particular <user> node.
			Step 7 - Receive lock
			<nc:rpc-reply
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			message-id="104">
			<lock-id>2</lock-id>
			<running>
			<locked-node xmlns:usr="http://example.com/users">
			/usr:top/usr:users/user[usr:name="Joe"]"
			</locked-node>
			</running>
			</nc:rpc-reply>
			The scope of the second lock is the <user> node Joe. It protects this
			<user> node and any data below it (e.g. phone number). At this point
			of time these nodes are protected both by the first and second lock.
			Next we unlock the other <user>s and the <users> node, to allow other
			managers to work on them. We still keep the second lock, so the
			<user> node Joe and the sub-tree below is still protected.
			Step 8 - Release lock on <users>
			<nc:rpc xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
			xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
			message-id="105">
			<partial-unlock>
			<lock-id>1</lock-id>
			</partial-unlock>
			</nc:rpc>
			8. Appendix D - Change Log
			8.1. 05-06
			Added usage example
			Clarified error messages
			Clarified interaction with edit-config continue-on-error
			Improved YANG: indentation, canonical order, contact info
			Added usage example in appendix C
			Synchronized YANG and XSD
			8.2. 04-05
	Language and editorial updates		Language and editorial updates
	all app-tags are with dashes without spaces		all app-tags are with dashes without spaces
	Added usage scenarios		Added usage scenarios
	Changed encoding		Changed encoding
	Clarified definitions, separated scope of lock and protected area		Clarified definitions, separated scope of lock and protected area
	7.2. 03-04		8.3. 03-04
	Minor clarifications		Minor clarifications
	Added list of locked-nodes to the output of partial-lock.		Added list of locked-nodes to the output of partial-lock.
	Added <target> wrapper around datastore names.		Added <target> wrapper around datastore names.
	Allowed atomic/one operation locking of datastore parts in multiple		Allowed atomic/one operation locking of datastore parts in multiple
	datastores.		datastores.
	Improved English (hopefully)		Improved English (hopefully)
	Removed the <data> element from rpc-reply following the text of		Removed the <data> element from rpc-reply following the text of
	rfc4741.		rfc4741.
	7.3. 02-03		8.4. 02-03
	Minor clarifications		Minor clarifications
	Same descriptions in XSD and YANG.		Same descriptions in XSD and YANG.
	7.4. 01-02		8.5. 01-02
	Made XSD normative		Made XSD normative
	Clarified that no specific access control is assumed.		Clarified that no specific access control is assumed.
	Clarified that non-existing nodes are NOT covered by the lock, even		Clarified that non-existing nodes are NOT covered by the lock, even
	if they where existing and covered by the lock when it was originally		if they where existing and covered by the lock when it was originally
	granted.		granted.
	Some rewording		Some rewording
	skipping to change at page 22, line 4		skipping to change at page 27, line 17
	Made XSD normative		Made XSD normative
	Clarified that no specific access control is assumed.		Clarified that no specific access control is assumed.
	Clarified that non-existing nodes are NOT covered by the lock, even		Clarified that non-existing nodes are NOT covered by the lock, even
	if they where existing and covered by the lock when it was originally		if they where existing and covered by the lock when it was originally
	granted.		granted.
	Some rewording		Some rewording
	Added app-tags for two of the error cases.		Added app-tags for two of the error cases.
	Made YANG an informative reference		Made YANG an informative reference
	Enhanced security considerations.		Enhanced security considerations.
	7.5. 00-01		8.6. 00-01
	Added YANG module.		Added YANG module.
	7.6. -00		8.7. -00
	Created from draft-lengyel-ngo-partial-lock-01.txt		Created from draft-lengyel-ngo-partial-lock-01.txt
	8. Acknowledgements		9. Acknowledgements
	Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David		Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David
	Harrington, Mehmet Ersue, Wes Hardaker and many other members of the		Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder and
	NETCONF WG for providing important input to this document.		many other members of the NETCONF WG for providing important input to
			this document.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,		[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
	December 2006.		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.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-netmod-yang]		[I-D.ietf-netmod-yang]
	Bjorklund, M., "YANG - A data modeling language for		Bjorklund, M., "YANG - A data modeling language for
	NETCONF", draft-ietf-netmod-yang-02 (work in progress),		NETCONF", draft-ietf-netmod-yang-03 (work in progress),
	November 2008.		January 2009.
	Authors' Addresses		Authors' Addresses
	Balazs Lengyel		Balazs Lengyel
	Ericsson		Ericsson
	Email: balazs.lengyel@ericsson.com		Email: balazs.lengyel@ericsson.com
	Martin Bjorklund		Martin Bjorklund
	Tail-f Systems		Tail-f Systems
	Email: mbj@tail-f.com		Email: mbj@tail-f.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 49 change blocks.
	80 lines changed or deleted		295 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/