|
draft-ietf-netconf-partial-lock-08.txt |
|
draft-ietf-netconf-partial-lock-09.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: December 5, 2009
Tail-f Systems |
|
Expires: December 13, 2009
Tail-f Systems |
|
|
June 03, 2009 |
|
June 11, 2009 |
|
|
|
|
|
|
|
Partial Lock RPC for NETCONF |
|
Partial Lock RPC for NETCONF |
|
|
|
draft-ietf-netconf-partial-lock-08 |
|
draft-ietf-netconf-partial-lock-09 |
|
|
|
|
|
|
|
Status of this Memo |
|
Status of this Memo |
|
|
|
|
|
|
|
This Internet-Draft is submitted to IETF in full
conformance with the |
|
This Internet-Draft is submitted to IETF in full
conformance with the |
|
|
|
provisions of BCP 78 and BCP 79. |
|
provisions of BCP 78 and BCP 79. This document may contain material |
|
|
|
|
from IETF Documents or IETF
Contributions published or made publicly |
|
|
|
|
available before November 10, 2008.
The person(s) controlling the |
|
|
|
|
copyright in some of this material
may not have granted the IETF |
|
|
|
|
Trust the right to allow
modifications of such material outside the |
|
|
|
|
IETF Standards Process. Without
obtaining an adequate license from |
|
|
|
|
the person(s) controlling the
copyright in such materials, this |
|
|
|
|
document may not be modified outside
the IETF Standards Process, and |
|
|
|
|
derivative works of it may not be
created outside the IETF Standards |
|
|
|
|
Process, except to format it for
publication as an RFC or to |
|
|
|
|
translate it into languages other
than English. |
|
|
|
|
|
|
|
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 December 5, 2009. |
|
This Internet-Draft will expire on December 13, 2009. |
|
|
|
|
|
|
|
Copyright Notice |
|
Copyright Notice |
|
|
|
|
|
|
|
Copyright (c) 2009 IETF Trust and the persons identified
as the |
|
Copyright (c) 2009 IETF Trust and the persons identified
as the |
|
|
document authors. All rights reserved. |
|
document authors. All rights reserved. |
|
|
|
|
|
|
|
This document is subject to BCP 78 and the IETF Trust's
Legal |
|
This document is subject to BCP 78 and the IETF Trust's
Legal |
|
|
Provisions Relating to IETF Documents in effect on the
date of |
|
Provisions Relating to IETF Documents in effect on the
date of |
|
|
publication of this document (http://trustee.ietf.org/license-info). |
|
publication of this document (http://trustee.ietf.org/license-info). |
|
|
Please review these documents carefully, as they describe
your rights |
|
Please review these documents carefully, as they
describe your rights |
|
|
|
|
|
|
|
skipping to change at page 2,
line 10 |
|
skipping to change at page 3,
line 7 |
|
|
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 |
|
|
|
|
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . .
. . . . . 3 |
|
1. Introduction . . . . . . . . . . . . . . . . . . . .
. . . . . 4 |
|
|
1.1. Definition of Terms . . . . . . . . . . . . . . .
. . . . 3 |
|
1.1. Definition of Terms . . . . . . . . . . . . . . .
. . . . 4 |
|
|
2. Partial Locking Capability . . . . . . . . . . . . .
. . . . . 3 |
|
2. Partial Locking Capability . . . . . . . . . . . . .
. . . . . 4 |
|
|
2.1. Overview . . . . . . . . . . . . . . . . . . . . .
. . . . 3 |
|
2.1. Overview . . . . . . . . . . . . . . . . . . . . .
. . . . 4 |
|
|
2.1.1. Usage Scenarios . . . . . . . . . . . . . . . .
. . . 4 |
|
2.1.1. Usage Scenarios . . . . . . . . . . . . . . . .
. . . 5 |
|
|
2.2. Dependencies . . . . . . . . . . . . . . . . . . .
. . . . 6 |
|
2.2. Dependencies . . . . . . . . . . . . . . . . . . .
. . . . 7 |
|
|
2.3. Capability Identifier . . . . . . . . . . . . . .
. . . . 6 |
|
2.3. Capability Identifier . . . . . . . . . . . . . .
. . . . 7 |
|
|
2.4. New Operations . . . . . . . . . . . . . . . . . .
. . . . 6 |
|
2.4. New Operations . . . . . . . . . . . . . . . . . .
. . . . 7 |
|
|
2.4.1. <partial-lock> . . . . . . . . . . . . . .
. . . . . . 6 |
|
2.4.1. <partial-lock> . . . . . . . . . . . . . .
. . . . . . 7 |
|
|
2.4.2. <partial-unlock> . . . . . . . . . . . . .
. . . . . . 11 |
|
2.4.2. <partial-unlock> . . . . . . . . . . . . .
. . . . . . 12 |
|
|
2.5. Modifications to Existing Operations . . . . . . .
. . . . 11 |
|
2.5. Modifications to Existing Operations . . . . . . .
. . . . 13 |
|
|
2.6. Interactions with Other Capabilities . . . . . . .
. . . . 12 |
|
2.6. Interactions with Other Capabilities . . . . . . .
. . . . 14 |
|
|
2.6.1. Candidate Configuration Capability . . . . . . .
. . . 12 |
|
2.6.1. Candidate Configuration Capability . . . . . . .
. . . 14 |
|
|
2.6.2. Confirmed Commit Capability . . . . . . . . . .
. . . 12 |
|
2.6.2. Confirmed Commit Capability . . . . . . . . . .
. . . 14 |
|
|
2.6.3. Distinct Startup Capability . . . . . . . . . .
. . . 12 |
|
2.6.3. Distinct Startup Capability . . . . . . . . . .
. . . 14 |
|
|
3. Security Considerations . . . . . . . . . . . . . .
. . . . . 12 |
|
3. Security Considerations . . . . . . . . . . . . . .
. . . . . 14 |
|
|
4. IANA Considerations . . . . . . . . . . . . . . . .
. . . . . 13 |
|
4. IANA Considerations . . . . . . . . . . . . . . . .
. . . . . 15 |
|
|
5. Appendix A - XML Schema for Partial Locking
(normative) . . 15 |
|
5. Appendix A - XML Schema for Partial Locking
(normative) . . 16 |
|
|
6. Appendix B - YANG Module for Partial Locking |
|
6. Appendix B - YANG Module for Partial Locking |
|
|
|
(non-normative) . . . . . . . . . . . . . . . . . . . .
. . . 19 |
|
(non-normative) . . . . . . . . . . . . . . . . . . . .
. . . 20 |
|
|
7. Appendix C - Usage Example - Reserving nodes for
future |
|
7. Appendix C - Usage Example - Reserving nodes for
future |
|
|
|
editing (non-normative) . . . . . . . . . . . . . . . .
. . . 22 |
|
editing (non-normative) . . . . . . . . . . . . . . . .
. . . 23 |
|
|
8. Appendix D - Change Log . . . . . . . . . . . . . .
. . . . 27 |
|
8. Appendix D - Change Log . . . . . . . . . . . . . .
. . . . 28 |
|
|
8.1. 07-08 . . . . . . . . .
. . . . . . . . . . . . . . . . . 27 |
|
8.1. 08-09 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.2. 06-07 . . . . . . . . .
. . . . . . . . . . . . . . . . . 27 |
|
8.2. 07-08 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.3. 05-06 . . . . . . . . .
. . . . . . . . . . . . . . . . . 27 |
|
8.3. 06-07 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.4. 04-05 . . . . . . . . .
. . . . . . . . . . . . . . . . . 27 |
|
8.4. 05-06 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.5. 03-04 . . . . . . . . .
. . . . . . . . . . . . . . . . . 27 |
|
8.5. 04-05 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.6. 02-03 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
8.6. 03-04 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
|
8.7. 01-02 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
8.7. 02-03 . . . . . . . . .
. . . . . . . . . . . . . . . . . 29 |
|
|
8.8. 00-01 . . . . . . . . .
. . . . . . . . . . . . . . . . . 28 |
|
8.8. 01-02 . . . . . . . . .
. . . . . . . . . . . . . . . . . 29 |
|
|
8.9. -00 . . . . . . . . . . . . . . . . . . . . . . .
. . . . 28 |
|
8.9. 00-01 . . . . . . . . . . . . .
. . . . . . . . . . . . . 29 |
|
|
9. Acknowledgements . . . . . . . . . . . . . . . . . .
. . . . . 29 |
|
8.10. -00 . . . . . . . . . .
. . . . . . . . . . . . . . . . . 29 |
|
|
10. References . . . . . . . . . . . . . . . . . . . .
. . . . . . 30 |
|
9. Acknowledgements . . . . . . . . . . . . . . . . . .
. . . . . 30 |
|
|
10.1. Normative References . . . . . . . . . . . . . .
. . . . . 30 |
|
10. References . . . . . . . . . . . . . . . . . . . .
. . . . . . 31 |
|
|
10.2. Informative References . . . . . . . . . . . . .
. . . . . 30 |
|
10.1. Normative References . . . . . . . . . . . . . .
. . . . . 31 |
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . .
. . . . . . 31 |
|
10.2. Informative References . . . . . . . . . . . . .
. . . . . 31 |
|
|
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . .
. . . . . . 32 |
|
|
|
|
|
|
|
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 3,
line 36 |
|
skipping to change at page 4,
line 36 |
|
|
node in the conceptual XML datastore. It contains an
absolute |
|
node in the conceptual XML datastore. It contains an
absolute |
|
|
path _expression_ in abbreviated syntax, where predicates
are used |
|
path _expression_ in abbreviated syntax, where predicates
are used |
|
|
only to specify values for nodes defined as keys to
distinguish |
|
only to specify values for nodes defined as keys to
distinguish |
|
|
multiple instances. |
|
multiple instances. |
|
|
|
|
|
|
|
o Scope of the lock: initially the set of nodes returned
by the |
|
o Scope of the lock: initially the set of nodes returned
by the |
|
|
XPath expressions in a successful partial-lock operation.
The set |
|
XPath expressions in a successful partial-lock
operation. The set |
|
|
might be modified if some of the nodes are deleted. |
|
might be modified if some of the nodes are deleted. |
|
|
|
|
|
|
|
o Protected area: the set of nodes that are protected
from |
|
o Protected area: the set of nodes that are protected
from |
|
|
|
modification by the lock. This consist of nodes in the scope of |
|
modification by the lock. This set
consists of nodes in the scope |
|
|
the lock and nodes in subtrees under them. |
|
of the lock and nodes in subtrees under them. |
|
|
|
|
|
|
|
2. Partial Locking Capability |
|
2. Partial Locking Capability |
|
|
|
|
|
|
|
2.1. Overview |
|
2.1. Overview |
|
|
|
|
|
|
|
The :partial-lock capability indicates that the device
supports the |
|
The :partial-lock capability indicates that the device
supports the |
|
|
locking of its configuration with a 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. |
|
|
|
|
|
|
|
skipping to change at page 4,
line 27 |
|
skipping to change at page 5,
line 27 |
|
|
2.1.1. Usage Scenarios |
|
2.1.1. Usage Scenarios |
|
|
|
|
|
|
|
In the following we describe a few scenarios for partial
locking. |
|
In the following we describe a few scenarios for partial
locking. |
|
|
Partial locking is primarily useful towards the
running |
|
Partial locking is primarily useful towards the
running |
|
|
configuration. However it can be used to lock a candidate
datastore |
|
configuration. However it can be used to lock a
candidate datastore |
|
|
as well. While scenarios using the running datastore are
seen as the |
|
as well. While scenarios using the running datastore are
seen as the |
|
|
most important, as an example a scenario involving the
candidate |
|
most important, as an example a scenario involving the
candidate |
|
|
datastore is also presented. Besides the three described
here, there |
|
datastore is also presented. Besides the three described
here, there |
|
|
are many other usage scenarios possible. |
|
are many other usage scenarios possible. |
|
|
|
|
|
|
|
|
2.1.1.1. Multiple managers handling the writable
running datastore |
|
2.1.1.1. Multiple managers handling the writable
running datastore with |
|
|
|
|
overlapping sections |
|
|
|
|
|
|
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
|
The agent is handled via the writable running datastore.
Each |
|
The agent is handled via the writable running datastore.
Each |
|
|
manager has his or her own task, which might involve the
modification |
|
manager has his or her own task, which might involve the
modification |
|
|
of overlapping sections of the datastore. |
|
of overlapping sections of the datastore. |
|
|
|
|
|
|
|
After collecting and analyzing input and preparing the
NETCONF |
|
After collecting and analyzing input and preparing the
NETCONF |
|
|
operations off-line, the manager locks the areas that are
important |
|
operations off-line, the manager locks the areas that
are important |
|
|
for his task using one single <partial-lock>
operation. The manager |
|
for his task using one single <partial-lock>
operation. The manager |
|
|
executes a number of <edit-config> operations to
modify the |
|
executes a number of <edit-config> operations to
modify the |
|
|
configuration, then releases the partial-lock. The lock
should be |
|
configuration, then releases the partial-lock. The lock
should be |
|
|
|
held for only a short time
(seconds rather then minutes). The |
|
held for the shortest
possible time (e.g. seconds rather
then |
|
|
manager should collect all human input before locking
anything. As |
|
minutes). The manager should collect all human input
before locking |
|
|
each manager locks only a part of the data model,
usually multiple |
|
anything. As each manager locks only a part of the data
model, |
|
|
operators can execute the <edit-config>
operations simultaneously. |
|
usually multiple operators can execute the
<edit-config> operations |
|
|
|
|
simultaneously. |
|
|
|
|
|
|
|
2.1.1.2. Multiple managers handling the writable running
datastore, |
|
2.1.1.2. Multiple managers handling the writable running
datastore, |
|
|
distinct management areas |
|
distinct management areas |
|
|
|
|
|
|
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
|
The agent is handled via the writable running datastore.
The agent's |
|
The agent is handled via the writable running datastore.
The agent's |
|
|
data model contains a number of well defined separate
areas that can |
|
data model contains a number of well defined separate
areas that can |
|
|
be configured without impacting other areas. An example
can be a |
|
be configured without impacting other areas. An example
can be a |
|
|
server with multiple applications running on it, or a
number of a |
|
server with multiple applications running on it, or a
number of a |
|
|
network elements with a common NETCONF agent for
management. |
|
network elements with a common NETCONF agent for
management. |
|
|
|
|
|
|
|
Each manager has his or her own task, which does not
involve the |
|
Each manager has his or her own task, which does not
involve the |
|
|
modification of overlapping sections of the datastore. |
|
modification of overlapping sections of the
datastore. |
|
|
|
|
|
|
|
The manager locks his area with a <partial-lock>
operation, uses a |
|
The manager locks his area with a <partial-lock>
operation, uses a |
|
|
number of <edit-config> commands to modify it,
later releases the |
|
number of <edit-config> commands to modify it,
later releases the |
|
|
lock. As each manager has his functional area assigned to
him, and |
|
lock. As each manager has his functional area assigned
to him, and |
|
|
he locks only that area, multiple managers can edit the
configuration |
|
he locks only that area, multiple managers can edit the
configuration |
|
|
|
simultaneously. Locks can be held for extended periods
(minutes, |
|
simultaneously. Locks can be held for extended periods
(e.g. |
|
|
hours), as this will not hinder other managers. |
|
minutes, hours), as this will
not hinder other managers. |
|
|
|
|
|
|
|
This scenario assumes, that the global lock operation
from [NETCONF] |
|
This scenario assumes, that the global lock operation
from [NETCONF] |
|
|
is not used. |
|
is not used. |
|
|
|
|
|
|
|
2.1.1.3. Multiple managers handling the candidate
datastore in a semi- |
|
2.1.1.3. Multiple managers handling the candidate
datastore in a semi- |
|
|
coordinated work mode |
|
coordinated work mode |
|
|
|
|
|
|
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
Multiple managers are handling the same NETCONF agent
simultaneously. |
|
|
The agent is handled via the candidate datastore. Each
manager has |
|
The agent is handled via the candidate datastore. Each
manager has |
|
|
his or her own task which might involve the modification
of |
|
his or her own task which might involve the modification
of |
|
|
overlapping sections of the datastore. |
|
overlapping sections of the datastore. |
|
|
|
|
|
|
|
After collecting and analyzing input and preparing the
NETCONF |
|
After collecting and analyzing input and preparing the
NETCONF |
|
|
operations off-line, the manager locks the areas that are
important |
|
operations off-line, the manager locks the areas that
are important |
|
|
for his task using one single <partial-lock>
operation in both the |
|
for his task using one single <partial-lock>
operation in both the |
|
|
candidate and the running datastore. He executes a number
of <edit- |
|
candidate and the running datastore. He executes a
number of <edit- |
|
|
config> operations to modify the configuration, then
releases the |
|
config> operations to modify the configuration, then
releases the |
|
|
|
partial-lock. The lock should be held for only a short time (seconds |
|
partial-lock. The lock should only be held for the shortest
possible |
|
|
rather then minutes). |
|
time (e.g. seconds rather
then minutes). |
|
|
|
|
|
|
|
Operators coordinate with each other. When all of them
finish their |
|
Operators coordinate with each other. When all of them
finish their |
|
|
tasks one of them orders commit. If any of the operators
are still |
|
tasks one of them orders commit. If any of the operators
are still |
|
|
working, and holds a lock, the commit will fail, and will
need to be |
|
working, and holds a lock, the commit will fail, and
will need to be |
|
|
repeated after all managers finish. |
|
repeated after all managers finish. |
|
|
|
|
|
|
|
Warning: When multiple managers use the candidate
configuration in |
|
Warning: When multiple managers use the candidate
configuration in |
|
|
parallel, there is a risk that the interaction of access
control |
|
parallel, there is a risk that the interaction of access
control |
|
|
(which is still implementation specific at the time of
this writing) |
|
(which is still implementation specific at the time of
this writing) |
|
|
and the commit operation might result in a dead-lock, as
illustrated |
|
and the commit operation might result in a dead-lock, as
illustrated |
|
|
|
|
|
|
|
skipping to change at page 8,
line 15 |
|
skipping to change at page 9,
line 17 |
|
|
The <partial-lock> operation is designed for
simplicity, so when a |
|
The <partial-lock> operation is designed for
simplicity, so when a |
|
|
partial lock is executed you get what you asked for: a
set of nodes |
|
partial lock is executed you get what you asked for: a
set of nodes |
|
|
that are locked for writing. As a consequence users must
observe the |
|
that are locked for writing. As a consequence users must
observe the |
|
|
following: |
|
following: |
|
|
|
|
|
|
|
o Locking does not affect read operations. |
|
o Locking does not affect read operations. |
|
|
|
|
|
|
|
o If part of a datastore is locked, this has no effect on
any |
|
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., |
|
unlocked parts of the datastore. If this is a problem
(e.g., |
|
|
changes depend on data values or nodes outside the
protected part |
|
changes depend on data values or nodes outside the
protected part |
|
|
|
of the datastore), these nodes should be included in the protected |
|
of the datastore), these nodes SHOULD be included in the protected |
|
|
area of the lock. |
|
area of the lock. |
|
|
|
|
|
|
|
o Configuration data can be edited both inside and
outside the |
|
o Configuration data can be edited both inside and
outside the |
|
|
protected area of a lock. It is the responsibility of the
NETCONF |
|
protected area of a lock. It is the responsibility of
the NETCONF |
|
|
client application to lock all relevant parts of a
datastore that |
|
client application to lock all relevant parts of a
datastore that |
|
|
are crucial for a specific management action. |
|
are crucial for a specific management action. |
|
|
|
|
|
|
|
Note: The <partial-lock> operation does not modify
the global <lock> |
|
Note: The <partial-lock> operation does not modify
the global <lock> |
|
|
operation defined in the base NETCONF Protocol [NETCONF].
If part of |
|
operation defined in the base NETCONF Protocol
[NETCONF]. If part of |
|
|
a datastore is already locked by <partial-lock>,
then a global lock |
|
a datastore is already locked by <partial-lock>,
then a global lock |
|
|
|
|
|
|
|
skipping to change at page 10,
line 46 |
|
skipping to change at page 12,
line 35 |
|
|
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. Deadlock Avoidance |
|
2.4.1.2. 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 |
|
MUST back-off, release any
previously acquired locks, and SHOULD |
|
|
procedure after waiting some randomized time
interval. |
|
retry the procedure after waiting some randomized time
interval. |
|
|
|
|
|
|
|
2.4.2. <partial-unlock> |
|
2.4.2. <partial-unlock> |
|
|
|
|
|
|
|
The operation unlocks the parts of the datastores that
were |
|
The operation unlocks the parts of the datastores that
were |
|
|
previously locked using <partial-lock> during the
same session. |
|
previously locked using <partial-lock> during the
same session. |
|
|
|
|
|
|
|
Parameters: |
|
Parameters: |
|
|
|
|
|
|
|
lock-id: Identity of the lock to be unlocked. This
lock-id MUST |
|
lock-id: Identity of the lock to be unlocked. This
lock-id MUST |
|
|
have been received as a response to a lock request by the
manager |
|
have been received as a response to a lock request by
the manager |
|
|
|
|
|
|
|
skipping to change at page 13,
line 29 |
|
skipping to change at page 15,
line 19 |
|
|
users's sessions. |
|
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. |
|
trail. |
|
|
|
|
|
|
|
A lock that is hung for some reason (e.g., a broken TCP
connection |
|
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 |
|
that the server has not yet recognised) can be released
using another |
|
|
NETCONF session by explicitly killing the session owning
that lock |
|
NETCONF session by explicitly killing the session owning
that lock |
|
|
using the <kill-session> operation. |
|
using the <kill-session> operation. |
|
|
|
|
|
|
|
|
Partial locking is NOT an
authorization mechanism; it SHOULD NOT be |
|
Partial locking is not an
authorization mechanism; it SHOULD NOT be |
|
|
used to provide security or access control. Partial
locking SHOULD |
|
used to provide security or access control. Partial
locking SHOULD |
|
|
only be used as a mechanism for providing consistency
when multiple |
|
only be used as a mechanism for providing consistency
when multiple |
|
|
managers are trying to configure the node. It is vital
that users |
|
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 |
|
easily understand the exact scope of a lock. This is why
the scope |
|
|
is determined when granting a lock and is not modified
thereafter. |
|
is determined when granting a lock and is not modified
thereafter. |
|
|
|
|
|
|
|
4. IANA Considerations |
|
4. IANA Considerations |
|
|
|
|
|
|
|
This document registers two URIs for the NETCONF XML
namespace in the |
|
This document registers two URIs for the NETCONF XML
namespace in the |
|
|
IETF XML registry [RFC3688]. Note that the capability URN
is |
|
IETF XML registry [RFC3688]. Note that the capability
URN is |
|
|
|
|
|
|
|
skipping to change at page 27,
line 7 |
|
skipping to change at page 28,
line 7 |
|
|
<nc:rpc
xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" |
|
<nc:rpc
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" |
|
|
message-id="105"> |
|
message-id="105"> |
|
|
<partial-unlock> |
|
<partial-unlock> |
|
|
<lock-id>1</lock-id> |
|
<lock-id>1</lock-id> |
|
|
</partial-unlock> |
|
</partial-unlock> |
|
|
</nc:rpc> |
|
</nc:rpc> |
|
|
|
|
|
|
|
8. Appendix D - Change Log |
|
8. Appendix D - Change Log |
|
|
|
|
|
|
|
|
8.1. 07-08 |
|
8.1. 08-09 |
|
|
|
|
|
|
|
Clarifications |
|
Clarifications |
|
|
|
|
|
|
|
|
8.2. 06-07 |
|
8.2. 07-08 |
|
|
|
|
|
|
|
|
|
Clarifications |
|
|
|
|
|
|
|
|
|
8.3. 06-07 |
|
|
|
|
|
|
|
Changed XSD and YANG to allow additional proprietary
datastores to be |
|
Changed XSD and YANG to allow additional proprietary
datastores to be |
|
|
locked. |
|
locked. |
|
|
|
|
|
|
|
|
8.3. 05-06 |
|
8.4. 05-06 |
|
|
|
|
|
|
|
Added usage example |
|
Added usage example |
|
|
|
|
|
|
|
Clarified error messages |
|
Clarified error messages |
|
|
|
|
|
|
|
Clarified interaction with edit-config
continue-on-error |
|
Clarified interaction with edit-config
continue-on-error |
|
|
|
|
|
|
|
Improved YANG: indentation, canonical order, contact
info |
|
Improved YANG: indentation, canonical order, contact
info |
|
|
|
|
|
|
|
Added usage example in appendix C |
|
Added usage example in appendix C |
|
|
|
|
|
|
|
Synchronized YANG and XSD |
|
Synchronized YANG and XSD |
|
|
|
|
|
|
|
|
8.4. 04-05 |
|
8.5. 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 |
|
|
|
|
|
|
|
|
8.5. 03-04 |
|
8.6. 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. |
|
|
|
|
|
|
|
|
8.6. 02-03 |
|
8.7. 02-03 |
|
|
|
|
|
|
|
Minor clarifications |
|
Minor clarifications |
|
|
|
|
|
|
|
Same descriptions in XSD and YANG. |
|
Same descriptions in XSD and YANG. |
|
|
|
|
|
|
|
|
8.7. 01-02 |
|
8.8. 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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
8.8. 00-01 |
|
8.9. 00-01 |
|
|
|
|
|
|
|
Added YANG module. |
|
Added YANG module. |
|
|
|
|
|
|
|
|
8.9. -00 |
|
8.10. -00 |
|
|
|
|
|
|
|
Created from draft-lengyel-ngo-partial-lock-01.txt |
|
Created from draft-lengyel-ngo-partial-lock-01.txt |
|
|
|
|
|
|
|
9. 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, Juergen
Schoenwaelder, Washam |
|
Harrington, Mehmet Ersue, Wes Hardaker, Juergen
Schoenwaelder, Washam |
|
|
Fan and many other members of the NETCONF WG for
providing important |
|
Fan and many other members of the NETCONF WG for
providing important |
|
|
input to this document. |
|
input to this document. |
|
|
|
|
|
|
|
|
|
|
|
| End of changes. 25 change
blocks. |
|
65 lines changed or deleted |
|
82 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/
|
