[要約] RFC 5717は、NETCONFにおける部分的なロックリモートプロシージャコール（RPC）に関する仕様です。その目的は、NETCONFセッション内でのデータの一部のみをロックするためのメカニズムを提供することです。
Network Working Group B. Lengyel
Request for Comments: 5717 Ericsson
Category: Standards Track M. Bjorklund
Tail-f Systems
December 2009
Partial Lock Remote Procedure Call (RPC) for NETCONF
NetConfの部分ロックリモートプロシージャコール（RPC）
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）は、構成データストア全体のロックに使用されるロックおよびロック解除リモートプロシージャコール（RPC）を定義します。状況によっては、構成データストアの一部のみをロックする方法が必要です。このドキュメントでは、構成データストアの一部をロックするためのNetConfプロトコルの機能ベースの拡張機能を定義します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
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.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 5
2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. <partial-lock> . . . . . . . . . . . . . . . . . . . . 5
2.4.2. <partial-unlock> . . . . . . . . . . . . . . . . . . . 10
2.5. Modifications to Existing Operations . . . . . . . . . . . 10
2.6. Interactions with Other Capabilities . . . . . . . . . . . 11
2.6.1. Candidate Configuration Capability . . . . . . . . . . 11
2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 11
2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. XML Schema for Partial Locking (Normative) . . . . . 14
Appendix B. YANG Module for Partial Locking (Non-Normative) . . . 17
Appendix C. Usage Example - Reserving Nodes for Future
Editing (Non-Normative) . . . . . . . . . . . . . . . 19
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]プロトコルは、構成データストア全体で動作するロックおよびロック解除操作について説明します。多くの場合、複数の管理セッションでは、管理されたデバイスの構成を並行して変更できる必要があります。これらの場合、構成データストアの一部のみをロックする必要があります。このドキュメントでは、既存のXPathフィルタリングメカニズムに基づいたメカニズムを使用して、NetConfを実行しているNetConfを実行しているNetConfの部分ロックをサポートするために、NetConfプロトコルの機能ベースの拡張機能を定義します。
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「この文書では、BCP 14、[RFC2119]に記載されているように解釈されます。
Additionally, the following terms are defined:
さらに、次の用語が定義されています。
o 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.
o インスタンス識別子：概念的なXMLデータストアの特定のノードを識別するXPath式。略語された構文に絶対パス式が含まれています。ここでは、述語は複数のインスタンスを区別するためのキーとして定義されたノードの値を指定するためにのみ使用されます。
o 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.
o ロックの範囲：最初は、Xpath式によって返されるノードのセットは、部分ロック操作を成功させました。ロックを所有するセッションによってノードの一部が削除されている場合、セットは変更される場合があります。
o 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.
o 保護エリア：ロックによる変更から保護されているノードのセット。このセットは、ロックの範囲内のノードとその下のサブツリーのノードで構成されています。
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.
The：Partial-Lock機能は、デバイスが完全な構成データストアよりも制限されたスコープで構成のロックをサポートすることを示しています。ロックされるスコープは、制限付きまたは完全なXPath式を使用して指定されます。部分ロックは、構成データのみに影響し、実行中のデータストアのみに影響します。候補者または起動データストアは影響を受けません。
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).
システムは、ロックで覆われた構成リソースが、Simple Network Management Protocol（SNMP）やコマンドラインインターフェイス（CLI）などの他のネットコンまたは非ネットコンフ管理操作によって変更されないようにする必要があります。
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.
部分ロックの持続時間は、部分ロックが許可され、（1）対応する<partial-unlock>操作が成功するか、（2）NetConfセッションが終了するまで続くときに始まります。
A NETCONF session MAY have multiple parts of the running datastore locked using partial lock operations.
NetConfセッションには、部分的なロック操作を使用して、実行中のデータストアの複数の部分がロックされている場合があります。
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>操作は、ロックIDを返して、正常に取得した各ロックを識別します。Lock-IDは、NetConfまたは非ネットコンセッションに付与されたすべての部分ロックについて、NetConfサーバーの場合はいつでもユニークです。
In the following, we describe a few scenarios for partial locking. Besides the two described here, there are many other usage scenarios possible.
以下では、部分ロックのいくつかのシナリオについて説明します。ここで説明する2つに加えて、他にも多くの使用シナリオがあります。
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エージェントを同時に処理しています。エージェントは、書き込み可能な実行可能なデータストアを介して処理されます。各マネージャーには独自のタスクがあり、データストアの重複セクションの変更が含まれる場合があります。
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操作をオフラインで準備した後、マネージャーは、1つの<Partial-Lock>操作を使用してタスクにとって重要な領域をロックします。マネージャーは、複数の<edit-config>操作を実行して構成を変更し、部分ロックをリリースします。ロックは、可能な限り最短時間（例：数分ではなく秒）に保持する必要があります。マネージャーは、何かをロックする前に、すべての人間の入力を収集する必要があります。各マネージャーはデータモデルの一部のみをロックするため、通常、複数の演算子が<edit-config>操作を同時に実行できます。
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エージェントを同時に処理しています。エージェントは、書き込み可能な実行可能なデータストアを介して処理されます。エージェントのデータモデルには、他の領域に影響を与えることなく構成できる明確に定義された多数の別々の領域が含まれています。例は、複数のアプリケーションを実行しているサーバー、または管理のための共通のNetConfエージェントを持つ多くのネットワーク要素です。
Each manager has his or her own task, which does not involve the modification of overlapping sections of the 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>コマンドを使用して変更し、後でロックをリリースします。各マネージャーは彼の機能領域を彼に割り当て、彼がその領域のみをロックしているため、複数のマネージャーは構成を同時に編集できます。ロックは、他のマネージャーを妨害しないため、長時間（時間、時間など）保持できます。
This scenario assumes that the global lock operation from [NETCONF] is not used.
このシナリオでは、[NetConf]からのグローバルロック操作は使用されていないことを前提としています。
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.
セクション2.4.1で説明されているように、デバイスは選択要素の制限付きXPath式をサポートする必要があります。オプションで、XPath機能がサポートされている場合（[NetConf]、セクション8.9で定義されているように。「XPath機能」）、デバイスは選択要素のxpath 1.0式を使用してサポートする必要があります。
urn:ietf:params:netconf:capability:partial-lock:1.0
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>操作により、クライアントは実行中のデータストアの一部をロックできます。ロックする部分は、<partial-lock>操作の「選択」要素のxpath式で指定されています。各XPath式は、ノードセットを返す必要があります。
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セッションがノードにロックを保持している場合、システムの他のセッションや非ネットコンフメカニズムは、その下のノードの階層内のノードまたはノードを変更することはできません。
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.
ノードをロックすると、ノード自体とノードの下の完全なサブツリーが、他の人による変更から保護されます。ロックされたノードのセットはロックの範囲と呼ばれ、その下のサブツリーのすべてのロックされたノードとノードは保護領域を構成します。
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回だけ評価されます。その後、ロックの範囲は、XPath式ではなく、ノードのセット、つまり返されたノードセットとして維持されます。構成データが、元のXPath式が別のノードのセットに評価されるように後で変更された場合、これは部分ロックの範囲に影響しません。
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.
エージェントのデータモデルにインターフェイスノードのリストが含まれているとしましょう。部分ロック操作の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サーバーによって原子的に処理する必要があります。サーバーは、データストアのすべての要求された部分をロックするか、なしでロックします。<partial-lock>操作中に、要求された部品の1つをロックできない場合、サーバーはその操作中に既にロックされているすべての部品のロックを解除する必要があります。
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).
ロックの範囲内のノードがロックを所有するセッションによって削除された場合、ロックの範囲から削除されるため、他のセッションまたは非ネットコンメカニズムが再現できます。ロックの範囲内のすべてのノードが削除されている場合、ロックはまだ存在します。ただし、そのスコープは空になります（ロックはノードをカバーしないため）。
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.
部分ロックをサポートするNetConfサーバーは、単一のNetConfセッションに複数の同時の部分ロックを付与できる必要があります。個々のロックの保護領域が重複する場合、すべてのオーバーラップロックが放出されるまで、共通エリアのノードを保護する必要があります。
A <partial-lock> operation MUST fail if:
<partial-lock>操作は、次の場合に失敗する必要があります。
o Any NETCONF session (including the current session) owns the global lock on the running datastore.
o NetConfセッション（現在のセッションを含む）は、実行中のデータストアのグローバルロックを所有しています。
o 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.
o 保護されるエリアのどの部分も、<partial-lock>または他の非ネットコン管理方法を使用した他のNetConfセッションを含む、別の管理セッションによって既にロックされています（または部分的なロックによって保護されています）。
o The requesting user is not successfully authenticated.
o リクエストユーザーは正常に認証されていません。
o 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.
o NetConfサーバーはアクセス制御を実装し、ロックユーザーには十分なアクセス権がありません。アクセス権の正確な処理はこのドキュメントの範囲外ですが、<partial-lock>操作を拒否または許可する可能性のあるアクセス制御システムがあると想定されています。
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>操作はシンプルに設計されているため、部分的なロックが実行されると、要求されたものが表示されます。書き込み用にロックされたノードのセットです。
As a consequence, users must observe the following:
結果として、ユーザーは次のことを観察する必要があります。
o Locking does not affect read operations.
o ロックは読み取り操作に影響しません。
o 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.
o 実行中のデータストアの一部がロックされている場合、これはデータストアのロック解除された部分に影響を与えません。これが問題である場合（たとえば、変更はデータストアの保護された部分の外側のデータ値またはノードに依存します）、これらのノードはロックの保護エリアに含める必要があります。
o 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.
o 構成データは、ロックの保護エリアの内側と外側の両方で編集できます。特定の管理アクションに不可欠なデータストアのすべての関連部分をロックすることは、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.
注：<Partial-Lock>操作は、ベースNetConfプロトコル[NetConf]で定義されているグローバル<Lock>操作を変更しません。実行中のデータストアの一部がすでに<partial-lock>によってロックされている場合、パートロックを所有するNetConfセッションによってグローバルロックが要求されていても、実行中のデータストアのグローバルロックが失敗する必要があります。
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つ以上の「選択」要素。XPath式は、コンテキストノードがサーバーの概念データモデルのルートであるコンテキストで評価され、名前空間宣言のセットは選択要素の範囲です。
The nodes returned from the select expressions are reported in the rpc-reply message.
選択式から返されたノードは、RPC-Replyメッセージで報告されています。
Each select expression MUST return a node set, and at least one of the node sets MUST be non-empty.
各選択式はノードセットを返す必要があり、少なくとも1つのノードセットは空ではない必要があります。
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機能をサポートする場合、有効なXPath 1.0式を使用できます。デバイスがXPath機能をサポートしていない場合、XPath式はインスタンス識別子式に制限する必要があります。インスタンス識別子は、短縮構文の絶対パス式であり、述語は複数のインスタンスを区別するためのキーとして定義されたノードの値を指定するためにのみ使用されます。
Example: Lock virtual router 1 and interface eth1
例：仮想ルーター1とインターフェイス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].
注：[NetConf]のXMLスキーマには、<RPC-Reply>の<Data> XML要素が必要な既知のバグがあります。これは、上記の例では、[netconf]で見つかったXMLスキーマを使用して検証されないことを意味します。
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.
デバイスがリクエストを満たすことができた場合、<RPC-ID>要素（ロック識別子）で<rpc-id>要素（lock-reply>要素で<rpc-reply>が送信されます。ロックされたノードのリストは、インスタンス識別子形式でも返されます。
Negative Response:
否定的な反応：
If any select expression is an invalid XPath expression, the <error-tag> is 'invalid-value'.
選択式が無効なXPath式である場合、<エラータグ>は「無効」です。
If any select expression returns something other than a node set, the <error-tag> is 'invalid-value', and the <error-app-tag> is 'not-a-node-set'.
選択式がノードセット以外のものを返す場合、<エラータグ>は「無効な値」であり、<エラーアプリタグ>は「ノードセット」です。
If all the select expressions return an empty node set, the <error-tag> is 'operation-failed', and the <error-app-tag> is '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機能がサポートされておらず、XPATH式がインスタンス識別子ではない場合、<エラータグ>は「無効」であり、<エラーアプリタグ>は「無効なロック仕様」です。
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.
アクセス制御が部分ロックを拒否した場合、<エラータグ>は「アクセス除去」です。不正なクライアントに他のセッションに関する情報を提供しないように、競合するロックを確認する前にアクセス制御を確認する必要があります。
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.
ロックをロックするサブツリー内のノードの別のセッションによってロックが既に保持されている場合、<エラータグ>要素は「ロック除去」であり、<Error-info>要素にはロックの<session-id>が含まれますオーナー。ロックが非ネットコンセッションによって保持されている場合、0（ゼロ）の<session-id>を含める必要があります。要求セッションが実行中のデータストアの（グローバル）ロックをすでに保持している場合、同じエラー応答が返されます。
If needed, the returned session-id may be used to <kill-session> the NETCONF session holding the lock.
必要に応じて、Returned Session-IDを使用して、ロックを保持しているNetConfセッションを<Kill-Session>に使用できます。
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.
ほとんどのロックシステムと同様に、構成の異なる部分をロックしようとする2つの管理セッションがデッドロックになる可能性があります。この状況を回避するために、クライアントは必要なすべてを1つの操作でロックする必要があります。ロックが失敗した場合、クライアントはバックオフし、以前に取得したロックをリリースする必要があり、ランダム化された時間間隔を待った後、手順を再試行する必要があります。
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.
この操作は、同じセッション中に<portial-lock>を使用して以前にロックされていた実行中のデータストアの部分のロックを解除します。操作は、ロックIDパラメーターによって識別されたロックでカバーされている部品のロックを解除します。複数の潜在的に重複するロックの場合、ロック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.
Lock-ID：ロック解除されるロックのアイデンティティ。このLock-IDは、現在のセッション中にマネージャーによるロックリクエストへの応答として受信されている必要があり、以前のロック解除リクエストで送信されてはなりません。
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>
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.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。データストアのすべてのロックされた部分がすでに削除されていても、肯定的な応答を送信する必要があります。
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>パラメーターがセッションによって所有されているロックを識別しない場合、「無効」エラーが返されます。
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.
部分的なロックを成功させると、その操作がロックの保護エリアでノードを変更しようとし、ロックが付与されたセッション以外のネットコンセッションで実行される場合、後続の操作が失敗します。<error-tag> 'in-use'と<error-app-tag> 'locked'が返されます。実行中のデータストアを変更するすべての操作は、<edit-config>、<copy-config>、<delete-config>、<commit>、<discard-changes>などの影響を受けます。Partial Lockが<edit-config>がいくつかのデータの変更を防ぎますが、操作には継続的なエラーオプションが含まれ、部分ロックによって保護されていないデータストアの他の部分の変更がまだ成功する可能性があります。
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.
データストアに部分ロックでロックされたノードが含まれている場合、これにより（グローバル）<Lock>操作が失敗します。<エラータグ>要素「ロック - デニード」とロック所有者の<Session-ID>を含む<Error-info>要素が返されます。ロックが非ネットコンセッションによって保持されている場合、0（ゼロ）の<session-id>が返されます。
All of these operations are affected only if they are targeting the running datastore.
これらの操作はすべて、実行中のデータストアをターゲットにしている場合にのみ影響を受けます。
The candidate datastore cannot be locked using the <partial-lock> operation.
候補のデータストアは、<partial-lock>操作を使用してロックできません。
If:
もしも：
o a partial lock is requested for the running datastore, and
o 実行中のデータストアには部分的なロックが要求され、
o the NETCONF server implements the :confirmed-commit capability, and
o NetConfサーバーは以下を実装しています。
o there was a recent confirmed <commit> operation where the confirming <commit> operation has not been received
o 確認<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.
確認が届かない場合、実行中のデータストアをコミット前に状態に戻す必要があるため、ロックを拒否する必要があります。したがって、NetConfサーバーは構成を変更する必要がある場合があります。
In this case, the <error-tag> 'in-use' and the <error-app-tag> 'outstanding-confirmed-commit' is returned.
この場合、<error-tag> 'in-use'と<error-app-tag> 'outstanding-confirmed-commit'が返されます。
The startup datastore cannot be locked using the <partial-lock> operation.
スタートアップデータストアは、<partial-lock>操作を使用してロックできません。
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).
同じ考慮事項は、ベースNetConfプロトコル[NetConf]に関連しています。<partial-lock>および<partial-unlock> rpcsは、認証されたユーザーにのみ許可する必要があります。<partial-lock>および<partial-unlock> rpcsは、承認されたユーザーにのみ許可される必要があります。ただし、NetConfアクセス制御は標準化されておらず、NetConfの実装の必須部分ではないため、強くお勧めしますが、オプションです（ただし、ほとんどすべての実装には何らかのアクセス制御が含まれます）。
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:
ロック（部分ロックまたはグローバルロックのいずれか）は、他のユーザーがシステムの構成を防ぐことができます。この可能性の誤用を防ぐために、次のメカニズムが整っています。
A user, that is not successfully authenticated, MUST NOT be granted a partial lock.
正常に認証されていないユーザーは、部分的なロックを許可されてはなりません。
Only an authorized user SHOULD be able to request a partial lock.
許可されたユーザーのみが部分的なロックを要求できるはずです。
The partial lock is automatically released when a session is terminated regardless of how the session ends.
セッションの終了に関係なく、セッションが終了すると、部分ロックが自動的にリリースされます。
The <kill-session> operation makes it possible to terminate other users' sessions.
<キルセッション>操作により、他のユーザーのセッションを終了することができます。
The NETCONF server MAY log partial lock requests in an audit trail.
NetConfサーバーは、監査証跡に部分的なロックリクエストを記録する場合があります。
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>操作を使用してそのロックを所有するセッションを明示的に殺すことにより、別のNetConfセッションを使用してリリースできます。
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.
部分ロックは認証メカニズムではありません。セキュリティやアクセス制御を提供するために使用しないでください。部分ロックは、複数のマネージャーがノードを構成しようとしている場合にのみ、一貫性を提供するメカニズムとして使用する必要があります。ユーザーがロックの正確な範囲を簡単に理解することが重要です。これが、ロックを付与するときにスコープが決定され、その後変更されない理由です。
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）機能URNS」レジストリから1つの機能識別子URNを登録し、「IETF XMLレジストリ」[RFC3688]のNetConf XMLネームスペースの1つのURIを登録します。機能URNは[NetConf]、セクション10.3に準拠していることに注意してください。
Index Capability Identifier
------------- ---------------------------------------------------
:partial-lock urn:ietf:params:netconf:capability:partial-lock:1.0
URI: urn:ietf:params:xml:ns:netconf:partial-lock:1.0
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N/A、要求されたURIはXMLネームスペースです。
Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer, David Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder, Washam Fan, and many other members of the NETCONF WG for providing important input to this document.
アンディ・ビアマン、シャロン・チショルム、フィル・シェーファー、デビッド・ハリントン、メフメット・エルエ、ウェス・ハーデイカー、ジュエルゲン・シェーンワエルダー、ワシャムファン、およびネットコンWGの他の多くのメンバーに感謝します。
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[NetConf] Enns、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[YANG] Bjorklund, M., "YANG - A data modeling language for NETCONF", Work in Progress, December 2009.
[Yang] Bjorklund、M。、「Yang-ネットコンのデータモデリング言語」、2009年12月、進行中の作業。
Appendix A. XML Schema for Partial Locking (Normative)
付録A. 部分ロックのためのXMLスキーマ（規範）
The following XML Schema defines the <partial-lock> and <partial-unlock> operations:
次のXMLスキーマは、<Partial-Lock>および<Partial-Unlock>操作を定義しています。
<CODE BEGINS>
<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
NetConfワーキンググループメーリングリストに連絡してください：netconf@ietf.org Web：http：//www.ietf.org/html.charters/netconf-charter.html
Balazs Lengyel balazs.lengyel@ericsson.com
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>
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 -->
<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 to be released. Must be the value
received in the response to a partial-lock 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)
付録B. 部分ロック用のYangモジュール（非規範的）
The following YANG module defines the <partial-lock> and <partial-unlock> operations. The YANG language is defined in [YANG].
次のYangモジュールは、<partial-lock>および<partial-unlock>操作を定義します。ヤン語は[Yang]で定義されています。
<CODE BEGINS>
<code begins>
module ietf-netconf-partial-lock {
モジュールietf-netconf-partial-lock {
namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0;
prefix pl;
organization "IETF Network Configuration (netconf) Working Group";
組織「IETFネットワーク構成（NetConf）ワーキンググループ」;
contact "Netconf Working Group Mailing list: netconf@ietf.org Web: http://www.ietf.org/html.charters/netconf-charter.html
お問い合わせ「NetConfワーキンググループメーリングリスト：netconf@ietf.org Web：http：//www.ietf.org/html.charters/netconf-charter.html
Balazs Lengyel Ericsson balazs.lengyel@ericsson.com";
Balazs lengyel ericsson balazs.lengyel@ericsson.com ";
description
"This YANG module defines the <partial-lock> and
<partial-unlock> operations.";
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)
付録C. 使用例 - 将来の編集用のリザーブノード（非規範的）
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>操作でロックされます。この後、親ノードのロックを削除する必要があります。
In this section, an example illustrating the above is given.
このセクションでは、上記を示す例を示します。
We want to create <user> Joe under <users>, and start editing it. Editing might take a number of minutes. We want to immediately lock Joe so no one will touch it before we are finished with the editing.
<user> joeの下で<user> joeを作成し、編集を開始します。編集には数分かかる場合があります。編集を終える前に誰もそれに触れないように、すぐにジョーをロックしたいと思います。
We also want to minimize locking other parts of the running datastore as multiple managers might be adding users near simultaneously.
また、複数のマネージャーがユーザーを同時に追加する可能性があるため、実行中のデータストアの他の部分をロックすることを最小限に抑えたいと考えています。
First, we check what users are already defined.
まず、ユーザーが既に定義されているものを確認します。
Step 1 - Read existing users
ステップ1-既存のユーザーを読み取ります
<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
ステップ2-既存のデータの受信
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/users">
<users>
<user>
<name>fred</name>
<phone>8327</phone>
</user>
</users>
</top>
</data>
</rpc-reply>
We want to add the new user Joe and immediately lock him using partial locking. The way to do this, is to first lock all <user> nodes by locking the <users> node.
新しいユーザーJoeを追加し、部分的なロックを使用してすぐに彼をロックしたいと思います。これを行う方法は、<ユーザー>ノードをロックして、最初にすべての<ユーザー>ノードをロックすることです。
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'を使用してすべての<ユーザー>ノードをロックする場合に注意してください。これは、新しいユーザーJoeをロックしません。これは、ロック後に作成するものです。したがって、<ユーザー>ノードをロックする必要があります。
Step 3 - Lock users
ステップ3-ユーザーをロックします
<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サーバーは、部分ロックを付与します。ロックの範囲には、<ユーザー>ノードのみが含まれます。ロックは、<ユーザー>ノードとその下のすべての<ユーザー>ノードを変更（他のセッションによる）から保護します。
Step 4 - Receive lock
ステップ4-ロックを受信します
<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.
次に、ユーザーJoeを作成します。ジョーは、<ユーザー>ノードにルート化されたサブツリーの下にあるため、上記のロックによって保護されています。
Step 5 - Create user Joe
ステップ5-ユーザージョーを作成します
<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>への肯定的な返信を受け取ります（図示せず）。次に、ロックを要求します。これは、<user> Joeのみをロックし、<users>ノードのロックをリリースします。これにより、他のマネージャーが追加の新しいユーザーを作成することができます。
Step 6 - Lock user Joe
ステップ6-ユーザージョーをロックします
<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/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サーバーは、部分ロックを付与します。この2番目のロックの範囲には、名前が付いた<user>ノードのみが含まれます。ロックは、この特定の<ユーザー>ノードの下のすべてのデータを保護します。
Step 7 - Receive lock
ステップ7-ロックを受信します
<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/user[usr:name="Joe"]"
</locked-node>
</nc:rpc-reply>
The scope of the second lock is the <user> node Joe. It protects this <user> node and any data below it (e.g., phone number). At this point of time, these nodes are protected both by the first and second lock. Next, we unlock the other <user>s and the <users> node, to allow other managers to work on them. We still keep the second lock, so the <user> node Joe and the subtree below is still protected.
2番目のロックのスコープは、<ユーザー>ノードジョーです。この<ユーザー>ノードとその下のデータ（電話番号など）を保護します。この時点で、これらのノードは、最初のロックと2番目のロックの両方によって保護されています。次に、他のマネージャーが作業できるようにするために、他の<ユーザー>と<ユーザー>ノードのロックを解除します。2番目のロックを保持するため、<ユーザー>ノードジョーと下のサブツリーはまだ保護されています。
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>
Authors' Addresses
著者のアドレス
Balazs Lengyel Ericsson
Balazs Lengyel Ericsson
EMail: balazs.lengyel@ericsson.com
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-Fシステム
EMail: mbj@tail-f.com