--- 1/draft-ietf-netconf-partial-lock-03.txt 2008-10-31 18:12:06.000000000 +0100 +++ 2/draft-ietf-netconf-partial-lock-04.txt 2008-10-31 18:12:06.000000000 +0100 @@ -1,19 +1,19 @@ NETCONF B. Lengyel -Internet-Draft Ericsson Hungary +Internet-Draft Ericsson Intended status: Standards Track M. Bjorklund -Expires: February 7, 2009 Tail-f Systems - August 06, 2008 +Expires: May 2, 2009 Tail-f Systems + October 29, 2008 Partial Lock RPC for NETCONF - draft-ietf-netconf-partial-lock-03 + draft-ietf-netconf-partial-lock-04 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,66 +24,67 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 7, 2009. + This Internet-Draft will expire on May 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract - The NETCONF protocol defines the lock and unlock RPCs that lock + The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 4 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1. . . . . . . . . . . . . . . . . . . . . 4 2.4.2. . . . . . . . . . . . . . . . . . . . 8 2.5. Modifications to Existing Operations . . . . . . . . . . . 9 2.6. Interactions with Other Capabilities . . . . . . . . . . . 9 - 2.6.1. Writable-Running Capability . . . . . . . . . . . . . 9 - 2.6.2. Candidate Configuration Capability . . . . . . . . . . 9 - 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 9 - 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 5. Appendix A - XML Schema for Partial Locking (normative) . . 11 + 2.6.1. Candidate Configuration Capability . . . . . . . . . . 9 + 2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 9 + 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 10 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5. Appendix A - XML Schema for Partial Locking (normative) . . 12 6. Appendix B - YANG Module for Partial Locking - (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 15 - 7.1. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.3. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.4. -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 + (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 19 + 7.1. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.2. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.3. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.4. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . . . 24 1. Introduction The NETCONF protocol [NETCONF] describes the lock and unlock RPCs that operate on entire configuration datastores. Often, multiple management sessions need to be able to modify the configuration of a managed device in parallel. In these cases, locking only parts of a configuration datastore is needed. This document defines an extension to the NETCONF protocol to allow this. @@ -97,320 +98,367 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 2. Partial Locking Capability 2.1. Overview The :partial-lock capability indicates that the device supports the - locking of its configuration with a scope smaller then a complete - configuration datastore. The scope to be locked is specified by - using restricted or full XPath expressions. Partial locking covers - configuration data, but not state data. + locking of its configuration with a more limited scope than a + complete configuration datastore. The scope to be locked is + specified by using restricted or full XPath expressions. Partial + locking covers configuration data, but not state data. The system MUST ensure that configuration resources covered by the lock are not modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI. - The duration of the partial lock is defined as beginning when the - partial lock is granted. The partial lock lasts until either the - corresponding operation succeeds or the NETCONF - session terminates. + The duration of the partial lock begins when the partial lock is + granted and lasts until (1) either the corresponding + operation succeeds or (2) the NETCONF session terminates. A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock. 2.2. Dependencies - The device MUST support the restricted XPath expressions in the - select element, as described in Section 2.4.1. If optionally the - :xpath capability is also supported, the device MUST also support the - usage of any XPath 1.0 expression in the select element. + The device MUST support restricted XPath expressions in the select + element, as described in Section 2.4.1. Optionally, if the :xpath + capability is also supported, the device MUST also support using any + XPath 1.0 expression in the select element. 2.3. Capability Identifier urn:ietf:params:netconf:capability:partial-lock:1.0 2.4. New Operations 2.4.1. - The operation allows the client to lock a portion of a - data store. The portion to lock is specified by using XPath - expressions in the select elements of the operation. - Each XPath expression MUST return a node set. Locking a node - protects the complete subtree under it from modification by others. + The operation allows the client to lock a portion of + one or more datastores. The portion to lock is specified with XPath + expressions in the select elements and the list of datastores in the + target element in the operation. Each XPath + expression MUST return a node set. Locking a node also protects the + complete subtree under the node from modification by others. - 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 - the configuration data is later altered in a way that would make the - original select XPath expressions evaluate to a different set of + In some situations it is desirable that the same set of nodes are + locked in more than one datastore. As an example: if an interface is + configured in the candidate datastore, it is dangerous if it is + configured by someone else in a possibly conflicting manner in the + running datastore. For this reason allows the locking + of the same sections of the management data in one or multiple + datastores. + + 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 the configuration data is later altered in a way that would make + the original select XPath expressions evaluate to a different set of nodes, this does not affect the scope 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 node + Conceptually, the scope of the lock is defined by the returned node set and not by the XPath expression. A operation MUST be handled atomically by the NETCONF - server. The server either locks all requested parts of the data - 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. + server. The server either locks all requested parts of the + datastore(s) or none. That is, if during the + operation one of the requested parts cannot be locked, the server + MUST unlock all parts that were previously locked during that + operation. 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. 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. 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. + can recreate it, as it is no longer covered by the lock. If all top + level nodes are deleted, the lock will still be present. However, + its scope will become nil (i.e., the lock will not cover any nodes). + + A NETCONF server MUST be able to grant multiple simultaneous partial + locks to a single NETCONF session. If the scope of the individual + locks overlaps, nodes in the common area MUST be locked until all of + the locks are released. A partial lock operation MUST fail if: o Any NETCONF session (including the current session) owns the - global lock on the datastore. + global lock on any target datastore. o Any part of the scope to be locked is already locked by another management session/protocol, including other NETCONF sessions using the or any other non-NETCONF management method. - o The NETCONF server implements access control and the locking user - does not have sufficient privileges, to all parts of the datastore + o The NETCONF server implements access control, and the locking user + does not have sufficient rights to all parts of a datastore section to be locked. The exact handling of access rights is outside the scope of this document, but it is assumed that there is an access control system that MAY deny or allow the partial lock operation. - Note: If partial lock is requested for the running datastore, and the - NETCONF server implements the :confirmed-commit capability, and there - was a recent confirmed operation, where the confirming - operation has not been received. In this case the lock MUST - be denied, because if the confirmation does not arrive, the running - datastore MUST be rolled back to its state before the commit, thus - the NETCONF server might need to modify the configuration. - - 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. + As with most locking systems, it is possible that two management + sessions trying to lock different parts of the configuration could + become dead-locked. To avoid this situation, clients SHOULD lock + everything they need in one operation. If that operation fails, the + client SHOULD back down, release any previously acquired locks, and + retry the procedure after waiting some time interval. The length of + the interval SHOULD be random to avoid repeated dead-locks when both + (or all) clients back down and then retry the partial lock operation. - 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 - locked for writing. There are some other issues that are - intentionally not addressed for the sake of simplicity: + The operation is designed for simplicity, so when a + partial 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 + intentionally not addressed: o Locking does not affect read operations. - 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 - operator's changes depend on data values in the unlocked part of - the datastore, the operator should include these values in the - scope of the lock. + o If part of a datastore is locked, this has no effect on any + unlocked parts of the datastore. If this is a problem (e.g., + changes depend on data values in the unlocked part of the + datastore), these values SHOULD be included in the scope of the + lock. - o An operator is allowed to edit the configuration both inside and - 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 - management action. + o Configuration data can be edited both inside and outside the scope + of a lock. It is the responsibility of the NETCONF client + application to lock all relevant parts of a datastore that are + crucial for a specific management action. Note: The operation does not modify the global operation defined in the base NETCONF Protocol [NETCONF]. If part of a datastore is already locked by , then a global lock - for that datastore fails even if the global lock is attempted by the - same NETCONF session which owns the partial-lock. + for that datastore MUST fail even if the global lock is requested by + the NETCONF session that owns the partial lock. 2.4.1.1. Parameters, Result, Examples Parameters: - target: Name of the configuration datastore of which a part shall be - locked. One operation can affect only one of the - datastores. URLs are not accepted. + target: Name of one or more configuration datastores of which a part + shall be locked. If multiple datastores are specified the same + select parameter(s) are used for all of them. For each datastore + locking of the same set of nodes will be requested. - 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 the context node is the root of the server's conceptual data model, and the set of namespace declarations are those in scope on the select element. - The select expressions MUST each return a node set, and at least - one of the node sets must be non-empty. + Each select expression is evaluated for each targeted datastore. - If the device supports the :xpath capability as well any valid - XPath 1.0 expression can be used, if not, the XPath expression - MUST be limited to an Instance Identifier expression. An - Instance Identifier is an absolute path expression in abbreviated - syntax, where predicates are used only to specify values for - nodes defined as keys to distinguish multiple instances. + The nodes that matched the select expression and are locked are + reported in the rpc-reply message. Note that if some of the + requested nodes exist only in one of the datastores, the lock is + granted on different nodes in different datastores. + + Each select expression MUST return a node set, and at least one + of the node sets for one of the specified datastores MUST be non- + empty. + + If the device supports the :xpath capability, any valid XPath 1.0 + expression can be used. If the device does not support the + :xpath capability, the XPath expression MUST be limited to an + Instance Identifier expression. An Instance Identifier is an + absolute path expression in abbreviated syntax, where predicates + are used only to specify values for nodes defined as keys to + distinguish multiple instances. Example: Lock virtual router 1 and interface eth1 - xmlns:if="http://example.com/ns/interface"> - nc:message-id="135"> + xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" + message-id="135"> - - + /rte:routing/rte:virtualRouter[rte:routerName='router1'] + + - - xmlns:if="http://example.com/ns/interface"> - nc:message-id="135"> - + message-id="135"> 127 - + + + /rte:routing/rte:virtualRouter[rte:routerName='router1'] + + + /if:interfaces/if:interface[if:id='eth1'] + + Positive Response: If the device was able to satisfy the request, an is sent - with a element (lock identifier) in the element. + with a element (lock identifier) in the + element. A list of locked nodes per datastore is also returned in + Instance Identifier format. Negative Response: - If a lock is already held on any node within the subtrees to be - locked, the element is 'lock-denied' and the - element includes the of the lock owner. If the lock is - held by a non-NETCONF entity, a of 0 (zero) is included. + If a lock is already held by another session on any node within the + subtrees to be locked, the element is 'lock-denied' and + the element includes the of the lock owner. + If the lock is held by a non-NETCONF session, a of 0 + (zero) is included. If needed the returned session-id may be used to + the NETCONF session holding the lock. The same error + response is returned if the requesting session already holds the + (global) lock for the same datastore. - If the select expressions return an empty node set, the - is 'operation-failed', and the is 'no-matches'. + If all the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'. - If any select expression returns anything but a node set, the is 'invalid-value', the is 'XPath does not - return a node set'. + If any select expression returns something other than a node set, the + is 'invalid-value', the is 'XPath does + not return a node set'. If the :xpath capability is not supported and the XPath expression is not an Instance Identifier, the is 'invalid-value', the is ':xpath capability not supported'. If access control denies the partial lock, the is 'access-denied'. 2.4.1.2. 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 operation. After this the lock on the parent - node should be removed. + 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 operation. After this, the + lock on the parent node SHOULD be removed. 2.4.2. - The operation unlocks a part of a datastore that was previously - locked using during the same session. + The operation unlocks the parts of the datastores that were + previously locked using during the same session. 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 operation. - Example: Unlock + Example: Unlock a previously created lock - + 127 Positive Response: If the device was able to satisfy the request, an is sent that contains an 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 parts of the datastore(s) have already been + deleted. Negative Response: If the parameter does not identify a lock which is owned by the session, an 'invalid-value' error is returned. 2.5. Modifications to Existing Operations - A granted partial-lock will cause another operation to fail, if it - tries to modify the locked area and is executed in a NETCONF session - other then the one that owns the lock. Affected operations include: - , , , and . A granted partial-lock will also cause the (global) - operation to fail. All of these operations are affected only if they - are for the same datastore. + A successful partial lock will cause a subsequent operation to fail + if it attempts to modify the locked area and is executed in a NETCONF + session other than the session that owns the lock. All operations + that modify the datastore are affected, including: , + , , and . A + successful partial lock will also cause the (global) operation + to fail. All of these operations are affected only if they are + targeting the same datastore. 2.6. Interactions with Other Capabilities -2.6.1. Writable-Running Capability +2.6.1. Candidate Configuration Capability - Partial locking of the running datastore can only be done if the - :writable-running capability is supported by the device. + Partial locking of the candidate datastore can only be done if the + :candidate capability is supported by the device. Partial locking of + the candidate datastore does not depend on whether the datastore was + modified or not. -2.6.2. Candidate Configuration Capability +2.6.2. Confirmed Commit Capability - Partial locking of the candidate datastore can only be done if the - :candidate capability is supported by the device. The partial - locking of the candidate datastore does not depend on whether the - datastore was modified or not. + If: + + o a partial lock is requested for the running datastore, and + + o the NETCONF server implements the :confirmed-commit capability, + and + + o there was a recent confirmed operation where the + confirming operation has not been received + + then the lock MUST be denied, because if the confirmation does not + arrive, the running datastore MUST be rolled back to its state before + the commit. The NETCONF server might therefore need to modify the + configuration. + In this case the 'in-use' and the 'Lock + denied, Outstanding confirmed commit' is returned. 2.6.3. Distinct Startup Capability Partial locking of the startup datastore can only be done if the :startup capability is supported by the device. 3. Security Considerations - The same considerations as for the base NETCONF Protocol [NETCONF] - are valid. It is assumed that the and and RPCs are only allowed for an authenticated user after passing some access control mechanism. - A lock either a partial-lock or a global lock might prevent other + 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. + Only an authenticated and authorized user can request a partial + lock. - The partial-lock is automatically released when a session is - terminated irrespective of the manner the session ends. + The partial lock is automatically released when a session is + terminated regardless of how the session ends. - The operation allows terminating other users - sessions. + The operation makes it possible to terminate other + users's sessions. - The NETCONF server may log partial-lock requests in an audit + 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. + A lock that is hung for some reason (e.g., a broken TCP connection + that the server has not yet recognised) can be released using another + NETCONF session by explicitly killing the session owning that lock + using the operation. + + 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 for providing consistency when multiple + managers are trying to configure the node. It is vital that users + easily understand the exact scope of a lock. This is why the scope + is determined when granting a lock and is not modified thereafter. 4. IANA Considerations This document registers two URIs for the NETCONF XML namespace in the IETF XML registry [RFC3688]. Note that the capability URN is compliant to [NETCONF] section 10.3. +---------------+---------------------------------------------------+ | Index | Capability Identifier | +---------------+---------------------------------------------------+ @@ -441,32 +489,51 @@ Schema defining the partial-lock and unlock operations. organization "IETF NETCONF Working Group" contact "Balazs Lengyel Ericsson Hungary, Inc. balazs.lengyel@ericsson.com" + schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/> - A NETCONF operation that locks part of a datastore. + A NETCONF operation that locks part of one or more datastores. - + + + + A list of one or more datastore names for NETCONF. + + + + + + + + + + + + + + + + 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. @@ -482,183 +549,283 @@ A NETCONF operation that releases a previously acquired partial-lock. - Identifies the lock to be released. Must be the value - received in the response to the partial-lock operation. + Identifies the lock, SHOULD be used in the subsequent + partial-lock operation. - + + + + + In a reply to a successful partial-lock request the content + of the element MUST conform to this complex type. + + + + + + + Identifies the lock to be released. Must be the value + received in the response to the partial-lock operation. + + + + + + + List of locked nodes in the running datastore. + + + + + + + + + + + + + List of locked nodes in the candidate datastore. + + + + + + + + + + + + + List of locked nodes in the startup datastore. + + + + + + + + + + + 6. Appendix B - YANG Module for Partial Locking (non-normative) The following YANG module defines the and operations. The YANG language is defined in [I-D.ietf-netmod-yang]. module netconf-partial-lock { namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0; prefix pl; organization "IETF NETCONF Working Group"; contact "Balazs Lengyel - Ericsson Hungary, Inc. + Ericsson balazs.lengyel@ericsson.com"; description "This YANG module defines the and operations."; - revision 2008-06-06 { + revision 2008-10-31 { description "Initial version."; } - grouping configName { + grouping configNames { + container target { description - "A choice to list the datastore names for NETCONF. - This could be moved to a netconf.yang module."; - choice configNameType { + "A list of one or more datastore names."; leaf running { type empty; } leaf candidate { type empty; } leaf startup { type empty; } + must "running or candidate or startup" { + error-message "At least one datastore must be specified."; + } } } rpc partial-lock { - description "A NETCONF operation that locks part of a datastore."; + description + "A NETCONF operation that locks part of one or more datastores."; input { - uses configName; + uses configNames; 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 + 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; min-elements 1; } } output { leaf lock-id { description - "Identifies the lock, if granted. The lock-id must be + "Identifies the lock, if granted. The lock-id MUST be used in the partial-unlock rpc."; type uint32; } + container running { + leaf-list locked-node { + description "List of locked nodes + in the running datastore"; + type instance-identifier; + } + } + container candidate { + leaf-list locked-node { + description "List of locked nodes + in the candidate datastore"; + type instance-identifier; + } + } + container startup { + leaf-list locked-node { + description "List of locked nodes + in the startup datastore"; + type instance-identifier; + } + } } } rpc partial-unlock { description "A NETCONF operation that releases a previously acquired partial-lock."; input { leaf lock-id { 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."; type uint32; } } } } 7. Appendix C - Change Log -7.1. 02-03 +7.1. 03-04 + + Minor clarifications + + Added list of locked-nodes to the output of partial-lock. + + Added wrapper around datastore names. + + Allowed atomic/one operation locking of datastore parts in multiple + datastores. + + Improved English (hopefully) + + Removed the element from rpc-reply following the text of + rfc4741. + +7.2. 02-03 Minor clarifications Same descriptions in XSD and YANG. -7.2. 01-02 +7.3. 01-02 Made XSD normative Clarified that no specific access control is assumed. 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 granted. Some rewording Added app-tags for two of the error cases. Made YANG an informative reference Enhanced security considerations. -7.3. 00-01 +7.4. 00-01 Added YANG module. -7.4. -00 +7.5. -00 Created from draft-lengyel-ngo-partial-lock-01.txt 8. Acknowledgements Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David - Harrington, Mehmet Ersue and many other members of the NETCONF WG for - providing important input to this document. + Harrington, Mehmet Ersue, Wes Hardaker and many other members of the + NETCONF WG for providing important input to this document. 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [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. + NETCONF", draft-ietf-netmod-yang-01 (work in progress), + August 2008. Authors' Addresses Balazs Lengyel - Ericsson Hungary + Ericsson Email: balazs.lengyel@ericsson.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Full Copyright Statement