RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)ベースの勉強資料です。

1. RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)ベースの勉強資料です。
下線、ハイライトは個人的に重要そうなところ。斜体、#はメモ。
原文のMUST/REQUIRED/SHALL/SHOULD/MAY/OPTIONAL等の​RFC2119​用語は原文のまま残しています。
MUST、REQUIRED、SHALL：絶対的な要求事項
MUST NOT：絶対的な禁止事項
SHOULD、RECOMMENDED：慎重に重要性を判断するべき要求事項
SHOULD NOT、NOT RECOMMENDED：慎重に重要性を判断するべき禁止事項
MAY、OPTIONAL：オプション。
間違っていたらコメントをお願いします。
元ネタ（RFC5717）
https://tools.ietf.org/html/rfc5717
Errata
https://www.rfc-editor.org/errata_search.php?rfc=5717
Partial Lock Remote Procedure Call (RPC) for NETCONF
Abstract
The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure
Calls (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.
NETCONFはconfig datastore全体をlockするためのRPC lockとunlockを定義する。状況によっては、config
datastoreの一部のみをロックする方法が必要である。​本ドキュメントではconfig datastoreの一部をロックするための
NETCONFのcapabilityを定義する。
Table of Contents
Abstract 1
Table of Contents 1
1. Introduction 3
1.1. Definition of Terms 3
2. Partial Locking Capability 3
2.1. Overview 3
2.1.1. Usage Scenarios 4
2.1.1.1. Multiple Managers Handling the Writable Running Datastore with
Overlapping Sections 4
2.1.1.2. Multiple Managers Handling the Writable Running Datastore, Distinct
Management Areas 5
2.2. Dependencies 5
2.3. Capability Identifier 5
2.4. New Operations 6
2.4.1. <partial-lock> 6
2.4.1.1. Parameters, Results, Examples 8
2.4.1.2. Deadlock Avoidance 10
2.4.2. <partial-unlock> 11
1

2. 2.5. Modifications to Existing Operations 11
2.6. Interactions with Other Capabilities 12
2.6.1. Candidate Configuration Capability 12
2.6.2. Confirmed Commit Capability 12
2.6.3. Distinct Startup Capability 13
3. Security Considerations 13
4. IANA Considerations 14
Appendix A. XML Schema for Partial Locking (Normative) 14
Appendix B. YANG Module for Partial Locking (Non-Normative) 16
Appendix C. Usage Example - Reserving Nodes for Future Editing (Non-Normative) 17
2

3. 1. Introduction
The [NETCONF] protocol describes the lock and unlock operations 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 a capability-based extension to the
NETCONF protocol to support partial locking of the NETCONF running datastore using a mechanism
based on the existing XPath filtering mechanisms.
NETCONFにはconfig datastore全体へのlock/unlock operationがある。​複数のセッションが管理対象のデバイスの
configをパラレルに変更できる必要がある。そのとき、config datastoreの一部のみをロックする必要がある。本ドキュメ
ントでは、既存のXPathフィルターのメカニズムをベースに、NETCONF running datastoreの部分的なロックをサポートす
るNETCONFのcapabilityを定義する。
1.1. Definition of Terms
Instance Identifier An XPath expression identifying a specific node in the conceptual
XML datastore. It contains an absolute path expression in
abbreviated syntax, where predicates are used only to specify values
for nodes defined as keys to distinguish multiple instances.
Datastore（XML）内の特定のnodeを識別するXPath。インスタンスを識別するためのkey
としてのみpredicateが使用される、"Abbreviated Syntax"の絶対パス式である。
2.5 Abbreviated Syntax
https://www.w3.org/TR/1999/REC-xpath-19991116/#path-abbrev
Scope of the lock Initially, the set of nodes returned by the XPath expressions in a
successful partial-lock operation. The set might be modified if
some of the nodes are deleted by the session owning the lock.
成功したpartial-lock operationのXPathで返されたnode。ロックしたセッションに
よってnodeの一部が削除され変更される場合がある。
Protected area The set of nodes that are protected from modification by the lock.
This set consists of nodes in the scope of the lock and nodes in
subtrees under them.
ロックによって変更から保護されているnode。このnodeは、ロックの範囲内のnodeと、そ
のサブツリーのnodeで構成される。
2. Partial Locking Capability
2.1. Overview
The :partial-lock capability indicates that the device supports the 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 only
affects configuration data and only the running
datastore. The candidate or the start-up datastore are not affected.
:partial-lock capabilityは、一部のconfigのロックをサポートすることを示す。ロックされる範囲はXPathで指定され
る。Partialロックはconfig dataとrunning datastoreにのみ影響する。​Candidate datastore、start-up
datastoreは影響を受けない。
3

4. The system MUST ensure that configuration resources covered by the lock are not modified by
other NETCONF or non-NETCONF management operations such as Simple Network Management Protocol
(SNMP) and the Command Line Interface (CLI).
システムはロックの対象となるconfigが他のNETCONF、non-NETCONF（SNMP、CLI等）によって変更されないようにすること
(MUST)。
The duration of the partial lock begins when the partial lock is granted and lasts until (1)
either the corresponding <partial-unlock> operation succeeds or (2) the NETCONF session
terminates.
Partialロックの期間はpartial-lockが許可されたときに始まり、(1)対応する<partial-unlock>が成功するか、
(2)NETCONFセッションが終了するまで続く。
#NETCONFセッション終了でもunlockするので忘れないように。
A NETCONF session MAY have multiple parts of the running datastore locked using partial lock
operations.
NETCONFセッションはpartial-lockを使用してrunning datastoreの複数の部分をロックしてもよい(MAY)。
The <partial-lock> operation returns a lock-id to identify each successfully acquired lock.
The lock-id is unique at any given time for a NETCONF server for all partial-locks granted to
any NETCONF or non-NETCONF sessions.
<partial-lock>はロックを識別するためにlock-idを返す。​lock-idはNETCONFサーバーのNETCONF、non-NETCONFに許
可された全てのpartialロックに対して一意である。
2.1.1. Usage Scenarios
In the following, we describe a few scenarios for partial locking. Besides the two described
here, there are many other usage scenarios possible.
以下では、partialロックのシナリオについて説明する。以下の2つ以外にも他にも多くのシナリオが考えられる。
2.1.1.1. Multiple Managers Handling the Writable Running Datastore with
Overlapping Sections
Multiple managers are handling the same NETCONF agent simultaneously. The agent is handled via
the writable running datastore. Each manager has his or her own task, which might involve the
modification of overlapping sections of the datastore.
複数のマネージャーが同じNETCONFエージェントへ処理を同時に要求する。エージェントはwritable running datastoreに
対して処理をする。各マネージャーには各自のタスクがありdatastoreへのオーバーラップした変更をする場合がある。
#要は複数クライアントから同一のサーバーのconfigを変更するケース。
After collecting and analyzing input and preparing the NETCONF operations off-line, the
manager locks the areas that are important for his task using one single <partial-lock>
operation. The manager executes a number of <edit-config> operations to modify the
configuration, then releases the partial-lock. The lock should be held for the shortest
possible time (e.g., seconds rather than minutes). The manager should collect all human input
before locking anything. As each manager locks only a part of the data model, usually
multiple operators can execute the <edit-config> operations simultaneously.
マネージャーはインプットの解析、NETCONF operationをオフラインで準備した後、<partial-lock>を使用してタスクに必
要なエリアをロックする。マネージャーは<edit-config>し、partial-lockを解放する。ロックはできるだけ短い時間（例：
秒単位）だけ保持することが推奨される。マネージャーはロックする前にインプットを解析、NETCONF operationの準備をして
4

5. いることが推奨される。各マネージャーはデータモデルの一部のみをロックするため、複数のオペレーターが<edit-config>を
同時に実行できる。
#オペレーターは操作する人、マネージャーはクライアント、エージェントはサーバーのイメージ。
2.1.1.2. Multiple Managers Handling the Writable Running Datastore, Distinct
Management Areas
Multiple managers are handling the same NETCONF agent simultaneously. The agent is handled via
the writable running datastore. The agent's data model contains a number of well-defined
separate areas that can be configured without impacting other areas. An example can be a
server with multiple applications running on it, or a number of network elements with a common
NETCONF agent for management.
複数のマネージャーが同じNETCONFエージェントへ処理を同時に要求する。エージェントはwritable running datastoreに
対して処理をする。エージェントのデータモデルには、他の領域に影響なく変更できる領域が含まれている。例えば、複数のアプ
リケーションが実行されているサーバーや、複数のネットワークエレメントを管理するNETCONFエージェントがある。
Each manager has his or her own task, which does not involve the modification of overlapping
sections of the datastore.
各マネージャーにはdatastoreのオーバーラップした変更をしないタスクがある。
The manager locks his area with a <partial-lock> operation, uses a number of <edit-config>
commands to modify it, and later releases the lock. As each manager has his functional area
assigned to him, and he locks only that area, multiple managers can edit the configuration
simultaneously. Locks can be held for extended periods (e.g., minutes, hours), as this will
not hinder other managers.
マネージャーは<partial-lock>で自分が変更するエリアをロックし、<edit-config>を使用して変更し、ロックを解放す
る。各マネージャーには自分のfunctionalエリアが割り当てられており、そのエリアのみをロックしているため、複数のマネー
ジャーが同時にconfigを編集できる。ロックは他のマネージャーの操作を阻害しないため、長時間（例：分、時間）保持でき
る。
This scenario assumes that the global lock operation from [NETCONF] is not used.
本シナリオはglobal lockが使用されないことを前提としている。
#global lock使用される場合は長時間ロックはNG。
2.2. Dependencies
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 (as defined in
[NETCONF], Section 8.9. "XPath Capability"), the device MUST also support using any XPath 1.0
expression in the select element.
Section 2.4.1にある通り、デバイスはselect elementでrestricted XPathをサポートすること(MUST)。オプション
で、:xpath capabilityがサポートされている場合、デバイスはselect elementでXPath 1.0をサポートすること(MUST)
。
2.3. Capability Identifier
urn:ietf:params:netconf:capability:partial-lock:1.0
5

6. 2.4. New Operations
2.4.1. <partial-lock>
The <partial-lock> operation allows the client to lock a portion of the running datastore.
The portion to lock is specified with XPath expressions in the "select" elements in the
<partial-lock> operation. Each XPath expression MUST return a node set.
<partial-lock>により、クライアントはruuning datastoreの一部をロックできる。ロックする部分は"select"
elementのXPathで指定される。XPathはnode setを返すこと(MUST)。
When a NETCONF session holds a lock on a node, no other session or non-NETCONF mechanism of
the system can change that node or any node in the hierarchy of nodes beneath it.
NETCONF sessionがnodeのロックを保持している場合、他のセッションまたはnon-NETCONFはそのnode、node以下のnode
を変更できない。
Locking a node protects the node itself and the complete subtree under the node from
modification by others. The set of locked nodes is called the scope of the lock, while all
the locked nodes and the nodes in the subtrees under them make up the protected area.
Nodeをロックすると、nodeとそのnode以下のサブツリーが他からの変更から保護される。ロックされたnode setは"scope
of the lock"と呼ばれ、全てのロックされたnodeとそのサブツリーのnodeが保護される。
The XPath expressions are evaluated only once: at lock time. Thereafter, the scope of the lock
is maintained as a set of nodes, i.e., the returned nodeset, and not by the XPath expression.
If the configuration data is later altered in a way that would make the original XPath
expressions evaluate to a different set of nodes, this does not affect the scope of the
partial lock.
XPathはロック時に1度だけ評価される。その後、scope of the lockはXPathではなくnode setとしてメンテされる。元の
XPathが異なるnode setとして評価されるようにconfigが後で変更された場合、これはpartial-lockのスコープに影響しな
い。
Let's say the agent's data model includes a list of interface nodes. If the XPath expression
in the partial-lock operation covers all interface nodes at locking, the scope of the lock
will be maintained as the list of interface nodes at the time when the lock was granted. If
someone later creates a new interface, this new interface will not be included in the
locked-nodes list created previously so the new interface will not be locked.
エージェントのデータモデルにインターフェースノードのリストが含まれているとする。partial-lockのXPathがロック時の全
てのインターフェースノードを含む場合、ロックのスコープはその時点のインターフェースノードのリストとしてメンテされる。
後で新しいインターフェースが作成される場合、その新しいインターフェースはロックノードリストに含まれないため、新しいイ
ンターフェースはロックされない。
A <partial-lock> operation MUST be handled atomically by the NETCONF server. The server
either locks all requested parts of the datastore or none. If during the <partial-lock>
operation one of the requested parts cannot be locked, the server MUST unlock all parts that
have already been locked during that operation.
<partial-lock>はNETCONFサーバーによってアトミックに処理されること(MUST)。サーバーはdatastoreに対して要求され
たロックをするかしないかのどちらかである。<partial-lock>中に要求された一部でもロックできない場合、サーバーはその
要求の処理中にロックした全てのロックを解放すること(MUST)。
6

7. If a node in the scope of the lock is deleted by the session owning the lock, it is removed
from the scope of the lock, so any other session or non-NETCONF mechanism can recreate it. If
all nodes in the scope of the lock are deleted, the lock will still be present. However, its
scope will become empty (since the lock will not cover any nodes).
Scope of the lockのノードがロックを所有しているセッションによって削除された場合、そのノードはscope of the
lockから削除されるため、他のセッション、non-NETCONFでノードを再作成できる。Scope of the lockの全てのノードが
削除された場合でもロックは存在し続ける。ただし、ノードが無いためスコープは空である。
A NETCONF server that supports partial locking MUST be able to grant multiple simultaneous
partial locks to a single NETCONF session. If the protected area of the individual locks
overlap, nodes in the common area MUST be protected until all of the overlapping locks are
released.
Partial-lockをサポートするNETCONFサーバーは、単一のNETCONFセッションに同時に複数のpartial-lockを許容できるこ
と(MUST)。各ロックの保護エリアがオーバーラップしている場合、全てのオーバーラップしたロックが解放されるまでオーバー
ラップしたnodeを保護すること(MUST)。
#自セッション内でのpartial-lockのオーバーラップはOK。
A <partial-lock> operation MUST fail if:
<partial-lock>は以下の場合に失敗すること(MUST):
● Any NETCONF session (including the current session) owns the global lock on the running
datastore.
NETCONFセッション(現在のセッションを含む)がrunning datastoreのグローバルlockを所有している場合。
● Any part of the area to be protected is already locked (or protected by partial
locking) by another management session, including other NETCONF sessions using
<partial-lock> or any other non-NETCONF management method.
他のNETCONFセッション、non-NETCONFにより既にロックされている場合。
● The requesting user is not successfully authenticated.
要求したユーザーが認証されていない場合。
● The NETCONF server implements access control and the locking user does not have
sufficient access rights. 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.
NETCONFサーバーはアクセス制御を実装しており、ロックするユーザーにアクセス権がない場合。アクセス権の処理は
本ドキュメントのスコープ外だが、<partial-lock>を拒否/許可できるアクセス制御があってよい(MAY)。
#RFC8341 NACMで可能。
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 that are locked for writing.
<partial-lock>はシンプルにデザインされており、ロックが実行されるとロックされたnodeが得られる。
As a consequence, users must observe the following:
結果として、ユーザーは以下に注意する必要がある。
● Locking does not affect read operations.
ロックはreadには影響しない。
7

8. ● If part of the running 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 or nodes
outside the protected part of the datastore), these nodes SHOULD be included in the
protected area of the lock.
Running datastoreの一部がロックされている場合、datastoreのロックされていない部分には影響しない。これ
に問題がある場合、例えば変更がロックで保護された部分外のnodeに依存する場合、それらのnodeもロックの保護領域
に含まれることが推奨される(SHOULD)。
● Configuration data can be edited both inside and outside the protected area of a lock.
It is the responsibility of the NETCONF client application to lock all relevant parts
of the datastore that are crucial for a specific management action.
Configuration dataはロックの保護領域の内側、外側の両方で編集できる。​特定のアクションで変更が必要な全て
の関連部分をロックするのはNETCONFクライアントの責任である。
Note: The <partial-lock> operation does not modify the global <lock> operation defined in the
base NETCONF protocol [NETCONF]. If part of the running datastore is already locked by
<partial-lock>, then a global lock for the running datastore MUST fail even if the global lock
is requested by the NETCONF session that owns the partial lock.
Note: <partial-lock>はNETCONFプロトコルで定義されたglobal <lock>を変更しない。​Running datastoreの一部が
<partial-lock>でロックされている場合、ロックしているNETCONFセッションでrunning datastoreのglobal <lock>
が要求されてもglobal <lock>は失敗すること(MUST)。
2.4.1.1. Parameters, Results, Examples
Parameters:
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.
XPathを含む、1つ以上の'select' element。XPathはコンテキストノードが
サーバーのroot。
The nodes returned from the select expressions are reported
in the rpc-reply message.
selectで返されたnodeはrpc-replyで送信される。
Each select expression MUST return a node set, and at least
one of the node sets MUST be non-empty.
各selectはnode setを返し(MUST)、1つ以上のnode setが空でないこと
(MUST)。
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.
デバイスが:xpath capabilityをサポートしている場合、XPath 1.0を使用で
8

9. きる。:xpath capabilityをサポートしていない場合、XPathはInstance
Identifier expressionに制限される(MUST)。Instance Identifier
expressionは、abbreviated syntaxの絶対パスであり、predicates はイ
ンスタンスを識別するためのkeyとしてのみ使用される。
Positive Response: If the device was able to satisfy the request, an <rpc-reply>
is sent with a <lock-id> element (lock identifier) in the
<rpc-reply> element. A list of locked nodes is also returned
in Instance Identifier format.
デバイスが要求を満たす場合、<lock-id>とロックされたnodeのリスト
(Instance Identifier format)を含む<rpc-reply>が送信される。
Negative Response: If any select expression is an invalid XPath expression, the
<error-tag> is 'invalid-value'.
Selectが無効なXPathの場合、<error-tag>は'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'.
Selectがnode set以外を返す場合、<error-tag>は'invalid-value'、
<error-app-tag>は'not-a-node-set'である。
If all the select expressions return an empty node set, the
<error-tag> is 'operation-failed', and the <error-app-tag> is
'no-matches'.
全てのselectがemptyの場合、 <error-tag>は'operation-failed'、
<error-app-tag>は'no-matches'である。
If the :xpath capability is not supported and the XPath
expression is not an Instance Identifier, the <error-tag> is
'invalid-value', the <error-app-tag> is
'invalid-lock-specification'.
:xpath capabilityが未サポートかつXPathがInstance Identifierでない
場合、<error-tag>は'invalid-value'、 <error-app-tag>は
'invalid-lock-specification'である。
If access control denies the partial lock, the <error-tag> is
'access-denied'. Access control SHOULD be checked before
checking for conflicting locks to avoid giving out
information about other sessions to an unauthorized client.
アクセス制御がpartial-lockを拒否する場合、<error-tag>は
'access-denied'である。競合するロックをチェックする前に、アクセス制御を
チェックすることで、アクセス許可されていないクライアントに他のセッションに関
する情報を提供しないことが推奨される(SHOULD)。
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 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 (zero) SHOULD be
included. The same error response is returned if the
requesting session already holds the (global) lock for the
running datastore.
ロックされるサブツリー内のnodeを別のセッションが既にロックしている場合、
<error-tag>'lock-denied'、<error-info>はロックしている
<session-id>が含まれる。ロックがnon-NETCONFセッションで保持されている
場合、<session-id>には0を含めることが推奨される(SHOULD)。 ​ロックを要求
9

10. するセッションがrunning datastoreのglobal lockを既に保持している場
合、同じエラー応答が返される。
If needed, the returned session-id may be used to
<kill-session> the NETCONF session holding the lock.
必要に応じて、返されたsession-idを使用してロックを保持しているNETCONF
セッションを<kill-session>してもよい。
Example: Lock virtual router 1 and interface eth1
<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="135">
<partial-lock>
<select xmlns:rte="http://example.com/ns/route">
/rte:routing/rte:virtualRouter[rte:routerName='router1']
</select>
<select xmlns:if="http://example.com/ns/interface">
/if:interfaces/if:interface[if:id='eth1']
</select>
</partial-lock>
</nc:rpc>
<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="135">
<lock-id>127</lock-id>
<locked-node xmlns:rte="http://example.com/ns/route">
/rte:routing/rte:virtualRouter[rte:routerName='router1']
</locked-node>
<locked-node xmlns:if="http://example.com/ns/interface">
/if:interfaces/if:interface[if:id='eth1']
</locked-node>
</nc:rpc-reply>
Note: The XML Schema in [NETCONF] has a known bug that requires the <data> XML element in a
<rpc-reply>. This means that the above examples will not validate using the XML Schema found
in [NETCONF].
Note: NETCONFのXMLスキーマには<rpc-reply>の<data>を必要とする既知のバグがある。これは上記の例がNETCONFにあ
るXMLスキーマを使用してvalidateしないことを意味する。
2.4.1.2. Deadlock Avoidance
As with most locking systems, it is possible that two management sessions trying to lock
different parts of the configuration could become deadlocked. To avoid this situation,
clients SHOULD lock everything they need in one operation. If locking fails, the client MUST
back-off, release any previously acquired locks, and SHOULD retry the procedure after waiting
some randomized time interval.
その他のロックシステムと同様に、configの異なる部分をロックしようとする2つのセッションがデッドロックになる可能性があ
る。この状態を回避するためにクライアントは、必要なものを全て1回でロックすることが推奨される(SHOULD)。ロックが失敗
した場合、クライアントはバックオフし、以前に取得したロックを解放し、ランダムの時間間隔を待ってから再試行すること
(MUST)。
10

11. 2.4.2. <partial-unlock>
The operation unlocks the parts of the running datastore that were previously locked using
<partial-lock> during the same session. The operation unlocks the parts that are covered by
the lock identified by the lock-id parameter. In case of multiple potentially overlapping
locks, only the lock identified by the lock-id is removed.
同じセッション中​に<partial-lock>を使用してロックしたruuning datastoreのロックを解放する。lock-idパラメーター
で指定されるロックを解放する。複数のロックがありオーバーラップしている場合、lock-idのロックのみが解放される。
Parameters:
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
during the current session, and MUST NOT have been sent in a
previous unlock request.
アンロックするロックのid。lock-idは現在のセッション中にマネージャーによる
ロック要求への応答として受信し(MUST)、それ以前のunlock要求ではlock-idを
送信しないこと(MUST)。
Positive Response: If the device was able to satisfy the request, an <rpc-reply>
is sent that contains an <ok> element. A positive response
MUST be sent even if all of the locked parts of the datastore
have already been deleted.
デバイスが要求を満たす場合、<ok>を含む<rpc-reply>が送信される。
Datastoreのロックされた部分が全て削除されている場合でも、positive
responseを送信すること(MUST)。
Negative Response: If the <lock-id> parameter does not identify a lock that is
owned by the session, an 'invalid-value' error is returned.
<lock-id>パラメーターがセッションが所有するロックでない場合、
'invalid-value'が返される。
Example: Unlock a previously created lock
<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="136">
<partial-unlock>
<lock-id>127</lock-id>
</partial-unlock>
</nc:rpc>
2.5. Modifications to Existing Operations
A successful partial lock will cause a subsequent operation to fail if that operation attempts
to modify nodes in the protected area of the lock 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-tag> 'locked' is returned. All operations that modify the running datastore are
affected, including: <edit-config>, <copy-config>, <delete-config>, <commit>, and
<discard-changes>. If partial lock prevents <edit-config> from modifying some data, but the
operation includes the continue-on-error option, modification of other parts of the datastore,
which are not protected by partial locking, might still succeed.
11

12. Partial lockが成功後、ロックしたセッション以外のセッションでの保護エリアのnodeの変更は失敗する。<error-tag>
'in-use'と<error-app-tag> 'locked'が返される。<edit-config>, <copy-config>, <delete-config>,
<commit>, and <discard-changes>といったrunning datastoreを変更する全てのoperationが影響を受ける。
Partial lockにより<edit-config>で一部のデータ変更に失敗したが、continue-on-error optionが含まれている場
合、ロックされていない他の部分への変更は成功してもよい。
If the 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.
Datastoreにpartial-lockされたnodeが含まれている場合、<lock>は失敗する。 <error-tag> 'lock-denied'、
<error-info> にロックしている<session-id>が返される。Non-NETCONFの場合<session-id>は0。
All of these operations are affected only if they are targeting the running datastore.
これらのoperationは全てrunning datastoreをtargetにしている場合にのみ影響を受ける。
2.6. Interactions with Other Capabilities
2.6.1. Candidate Configuration Capability
The candidate datastore cannot be locked using the <partial-lock> operation.
Candidate datastoreは<partial-lock>でロックできない。
2.6.2. Confirmed Commit Capability
If:
● a partial lock is requested for the running datastore, and
running datastoreにpartial-lockが要求されており、
● the NETCONF server implements the :confirmed-commit capability, and
NETCONFサーバーは:confirmed-commit capabilityを実装しており、
#RFC6241。Candidate datastoreの変更をrunning datastoreに反映したり、キャンセルしたりする
capability。
● there was a recent confirmed <commit> operation where the confirming <commit> operation
has not been received
confirming <commit>が受信されていないconfirmed <commit>があった場合
#confirmed <commit> :commitが継続する。
#confirming <commit>:commit完了。
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.
Confirmationが受信されない場合、running datastoreをcommit前の状態にロールバックする必要があり(MUST)、ロック
を拒否する必要がある(MUST)。​そのため、NETCONFサーバーはconfigを変更する必要がある。
In this case, the <error-tag> 'in-use' and the <error-app-tag> 'outstanding-confirmed-commit'
is returned.
この場合、以下が返される。
12

13. <error-tag> 'in-use'
<error-app-tag> 'outstanding-confirmed-commit'
2.6.3. Distinct Startup Capability
The startup datastore cannot be locked using the <partial-lock> operation.
Startup datastoreは<partial-lock>でロックできない。
3. Security Considerations
The same considerations are relevant as for the base NETCONF protocol [NETCONF].
<partial-lock> and <partial-unlock> RPCs MUST only be allowed for an authenticated user.
<partial-lock> and <partial-unlock> RPCs SHOULD only be allowed for an authorized user.
However, as NETCONF access control is not standardized and not a mandatory part of a NETCONF
implementation, it is strongly recommended, but OPTIONAL (although nearly all implementations
include some kind of access control).
<partial-lock>、<partial-unlock>は認証されたユーザーにのみ許容されること(MUST)。<partial-lock>、
<partial-unlock>は許可されたユーザーにのみ許容されることが推奨される(SHOULD)。ただし、NETCONFアクセス制御は標
準化されておらず、NETCONFの必須機能ではないため、強く推奨されるがOPTIONALである。
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:
ロックにより他のユーザーがシステムをconfigできない場合がある。想定しない状況を防ぐために以下のメカニズムがある。
● A user, that is not successfully authenticated, MUST NOT be granted a partial lock.
認証されていないユーザーにはpartial-lockを許可しないこと(MUST NOT)。
● Only an authorized user SHOULD be able to request a partial lock.
認証されたユーザーのみがpartial-lockを要求できること(SHOULD)。
● The partial lock is automatically released when a session is terminated regardless of
how the session ends.
セッションの終了方法に関わらず、セッションが終了したときにpartial-lockは自動的に解放される。
● The <kill-session> operation makes it possible to terminate other users' sessions.
<kill-session>により他のユーザーのセッションを終了できる。
● The NETCONF server MAY log partial lock requests in an audit trail.
NETCONFサーバーはpartial-lockをauditする機能をもってよい(MAY)。
A lock that is hung for some reason (e.g., a broken TCP connection that the server has not yet
recognized) can be released using another NETCONF session by explicitly killing the session
owning that lock using the <kill-session> operation.
何らかの理由（例：TCPパケット破損等）でハングしたロックは<kill-session>でセッションを終了することで解放できる。
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.
13

14. Partial-lockに認証のメカニズムはないため、セキュリティやアクセス制御のためには使用しないこと(SHOULD NOT)。
Partial-lockは複数のマネージャーがnodeをconfigしているようなときに使用することが推奨される(SHOULD)。​ユーザー
が正確なscope of lockを確認できることが重要である。これが、ロック時にscopeが決定され、それ以降に変更されない理由
である。
4. IANA Considerations
This document registers one capability identifier URN from the "Network Configuration Protocol
(NETCONF) Capability URNs" registry, and one URI for the NETCONF XML namespace in the "IETF
XML registry" [RFC3688]. Note that the capability URN is compliant to [NETCONF], Section
10.3.
以下を追加する。
NETCONF Capability URNs :partial-lock
urn:ietf:params:netconf:capability:partial-lock:1.0
NETCONF XML namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0
Appendix A. XML Schema for Partial Locking (Normative)
The following XML Schema defines the <partial-lock> and <partial-unlock> operations:
以下のXMLスキーマは<partial-lock>、<partial-unlock>を定義する。
<CODE BEGINS>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
Schema defining the partial-lock and unlock operations.
organization "IETF NETCONF Working Group"
contact
Netconf Working Group
Mailing list: netconf@ietf.org
Web: http://www.ietf.org/html.charters/netconf-charter.html
Balazs Lengyel
balazs.lengyel@ericsson.com
revision 2009-10-19
description Initial version, published as RFC 5717.
</xs:documentation>
</xs:annotation>
<xs:import namespace="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:annotation>
<xs:documentation>
14

15. A number identifying a specific
partial-lock granted to a session.
It is allocated by the system, and SHOULD
be used in the unlock operation.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:complexType name="partialLockType">
<xs:annotation>
<xs:documentation>
A NETCONF operation that locks parts of
the running datastore.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="nc:rpcOperationType">
<xs:sequence>
<xs:element name="select" type="xs:string"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
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.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="partialUnLockType">
<xs:annotation>
<xs:documentation>
A NETCONF operation that releases a previously acquired
partial-lock.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="nc:rpcOperationType">
<xs:sequence>
<xs:element name="lock-id" type="lock-id-type">
<xs:annotation>
<xs:documentation>
Identifies the lock to be released. MUST
be the value received in the response to
the partial-lock operation.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- <partial-lock> operation -->
<xs:element name="partial-lock" type="partialLockType"
substitutionGroup="nc:rpcOperation"/>
<!-- <partial-unlock> operation -->
15

16. <xs:element name="partial-unlock" type="partialUnLockType"
substitutionGroup="nc:rpcOperation"/>
<!-- reply to <partial-lock> -->
<xs:complexType name="contentPartInPartialLockReplyType">
<xs:annotation>
<xs:documentation>
The content of the reply to a successful
partial-lock request MUST conform to this complex type.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="lock-id" type="lock-id-type">
<xs:annotation>
<xs:documentation>
Identifies the lock, if granted. This lock-id must
be used in the partial-unlock operation.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="locked-node" type="xs:string"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
List of locked nodes in the running datastore.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<CODE ENDS>
Appendix B. YANG Module for Partial Locking (Non-Normative)
The following YANG module defines the <partial-lock> and <partial-unlock> operations. The
YANG language is defined in [YANG].
以下のYANGモジュールは<partial-lock>、<partial-unlock>を定義する。
<CODE BEGINS>
module ietf-netconf-partial-lock {
namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0;
prefix pl;
organization "IETF Network Configuration (netconf) Working Group";
contact
"Netconf Working Group
Mailing list: netconf@ietf.org
Web: http://www.ietf.org/html.charters/netconf-charter.html
Balazs Lengyel
Ericsson
balazs.lengyel@ericsson.com";
description
"This YANG module defines the <partial-lock> and
<partial-unlock> operations.";
16

17. revision 2009-10-19 {
description
"Initial version, published as RFC 5717.";
}
typedef lock-id-type {
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 {
description
"A NETCONF operation that locks parts of the running datastore.";
input {
leaf-list select {
type string;
min-elements 1;
description
"XPath expression that specifies the scope of the lock.
An Instance Identifier expression MUST be used unless the
:xpath capability is supported, in which case any XPath 1.0
expression is allowed.";
}
}
output {
leaf lock-id {
type lock-id-type;
description
"Identifies the lock, if granted. The lock-id SHOULD be
used in the partial-unlock rpc.";
}
leaf-list locked-node {
type instance-identifier;
min-elements 1;
description
"List of locked nodes in the running datastore";
}
}
}
rpc partial-unlock {
description
"A NETCONF operation that releases a previously acquired
partial-lock.";
input {
leaf lock-id {
type lock-id-type;
description
"Identifies the lock to be released. MUST be the value
received in the response to a partial-lock operation.";
}
}
}
}
<CODE ENDS>
Appendix C. Usage Example - Reserving Nodes for Future Editing
(Non-Normative)
17

18. 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.
Partial-lockを使用して存在しないnodeをあらかじめロックすることはできない。​他のセッションでnodeを作成できないよう
にするためには、親nodeをロックし、サブツリーの最上位nodeを作成してから新たに<partial-lock>する必要がある。その
後、親nodeのロックを削除する。
In this section, an example illustrating the above is given.
このsectionでは上記の例を示す。
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.
<users>配下に<user> Joeを作成し、editする。Editには数分かかる場合がある。即座にJoeをロックしてeditが完了する
までに誰も変更できないようにする。
We also want to minimize locking other parts of the running datastore as multiple managers
might be adding users near simultaneously.
複数のマネージャーが同時にユーザーを追加する可能性があるため、running datastoreの他の部分へのロックは最小限にす
る。
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.
NETCONFサーバーは以下の応答を送信する。
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">
18

19. <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.
Joeを追加し、即座にpartial-lockでロックする。このためにまず<users>nodeをロックし、全ての<user>nodeをロックす
る。
Note that if we would lock all the <user> nodes using the select expression
'/usr:top/usr:users/usr:user'; this would not lock the new user Joe, which we will create
after locking. So we rather have to lock the <users> node.
'/usr:top/usr:users/usr:user';を使用して全ての<user>nodeをロックしてもロック後に作成されるJoeはロックされ
ない。そのため、<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>
<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).
NETCONFサーバーはpartial lockを許可する。Scope of the lockには<users>nodeのみが含まれる。ロックは、
<users>nodeと配下の全ての<user>nodeを他のセッションによる変更から保護する。
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>
<locked-node xmlns:usr="http://example.com/users">
/usr:top/usr:users
</locked-node>
</nc:rpc-reply>
Next we create user Joe. Joe is protected by the lock received above, as it is under the
subtree rooted at the <users> node.
19

20. 次にuser Joeを作成する。Joeは<users>nodeをrootとするサブツリーにあるため、上記のロックで保護される。
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.
<edit-config>に対してOK応答を受信する。次に<user> Joeのみのロックを要求し、<users>nodeのロックを解放する。こ
れにより他のマネージャーが新しいユーザーを作成できる。
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>
<select xmlns:usr="http://example.com/users">
/usr:top/usr:users/usr: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.
NETCONFサーバーはpartial-lockを許可する。二番目のScope of the lockはJoeという名前の<user>nodeのみが含まれ
る。ロックはJoeの<user>node配下の全ての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>
<locked-node xmlns:usr="http://example.com/users">
/usr:top/usr:users/usr:user[usr:name="Joe"]
</locked-node>
</nc:rpc-reply>
20

21. 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
subtree below is still protected.
二番目のロックのscope of the lockは<user> node Joeである。この<user>nodeとその配下のdata（例:phone
number）を保護する。この時点では、これらのnodeは最初と二番目のロックの両方で保護される。次に他の<user>と<users>
のロックを解放し、他のマネージャーが編集できるようにする。二番目のロックは引き続き保持されるため、<user>node Joe
とそのサブツリーは保護される。
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>
21