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/