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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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プロトコルに能力ベースの拡張を定義します。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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.
：部分的なロック機能は、デバイスは、完全なコンフィギュレーションデータストアよりも限られた範囲でその構成のロックをサポートしていることを示しています。範囲は制限されたり、完全な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).
ロックによってカバーされているコンフィギュレーション・リソースを確保しなければならないシステムは、このような簡易ネットワーク管理プロトコル（SNMP）とコマンドラインインタフェース（CLI）のような他のNETCONFまたは非NETCONFの管理操作によって変更されていません。
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）いずれかの対応する<部分アンロック>操作が成功または（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.
<部分的なロック>操作は、各取得に成功したロックを識別するためにロックIDを返します。ロック-idには、任意のNETCONFまたは非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つ以外にも、可能な他の多くの利用シナリオがあります。
2.1.1.1. Multiple Managers Handling the Writable Running Datastore with Overlapping Sections
2.1.1.1。オーバーラップする部分で書き込み可能な実行データストアを扱う複数のマネージャ
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操作を調製した後、管理者は、単一の<部分的ロック>操作を使用して、彼の仕事のために重要な領域をロックします。管理者は次に、部分的ロックを解除する、構成を変更する<編集設定>操作の数を実行します。ロックは最短時間（例えば、秒ではなく数分）保持されなければなりません。マネージャーは何かをロックする前に、すべての人間の入力を収集する必要があります。各マネージャ・ロックデータ・モデルの一部のみとして、通常、複数のオペレータが同時に<編集-config>の操作を実行することができます。
2.1.1.2. Multiple Managers Handling the Writable Running Datastore, Distinct Management Areas
2.1.1.2。書き込み可能な実行中のデータストアを扱う複数のマネージャ、個別管理領域
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.
管理者は、<部分的ロック>操作で自分の領域をロック<編集-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項で説明したように、デバイスは、select要素に制限されたXPath式をサポートしなければなりません。場合、任意に、：XPathの機能もサポートされている（[NETCONF]で定義されるように、セクション8.9「XPathの能力は」）、デバイスはまた、選択要素の任意のXPath 1.0の式を使用してサポートしなければなりません。
urn:ietf:params:netconf:capability:partial-lock:1.0
URN：IETF：のparams：NETCONF：機能：部分的ロック：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.
<部分的ロック>操作は、クライアントが実行されているデータストアの一部をロックすることができます。ロックする部分は、<部分的なロック>動作の要素を「選択」で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セッションは、ノードのロックを保持している場合、他のセッションまたはシステムの非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式は一度だけ評価されます。ロック時。その後、ロックの範囲は、すなわち、返さノードセットではなく、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.
<部分的なロック>動作NETCONFサーバによってアトミックに処理されなければなりません。サーバーのいずれかのロックは、すべてのデータストアまたはnoneの部分を要求しました。 <部分的ロック>運転中に要求された部分の一つがロックできない場合は、サーバはすでにその操作中にロックされているすべての部品をロック解除する必要があります。
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).
ロックの範囲内のノードは、ロックを所有しているセッションによって削除された場合は、ロックの範囲から除外されるので、他のセッションまたは非NETCONF機構は、それを再現することができます。ロックの範囲内のすべてのノードが削除された場合、ロックがまだ存在することになります。 （ロックは、任意のノードをカバーしていないので）しかし、その範囲は空になります。
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:
<部分的ロック>操作があれば失敗しなければなりません：
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領域の任意の部分がロック（または部分的なロックによって保護された）<部分的なロック>または任意の他の非NETCONF管理方法を使用して、他の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サーバは、アクセス制御を実装し、ロックユーザーが十分なアクセス権を持っていません。アクセス権の正確な取り扱いは、この文書の範囲外であり、拒否または<部分的なロック>操作を可能にするアクセス制御システムがあることが想定されます。
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.
<部分的ロック>操作を簡単にするために設計され、その部分のロックが実行されたとき、あなたはあなたが尋ね取得されています。書き込み用にロックされているノードの集合。
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.
注：<部分的なロック>動作[NETCONF】基地NETCONFプロトコルで定義されたグローバル<ロック>の動作を変更しません。実行されているデータストアの一部はすでに<パーシャル・ロック>によってロックされている場合はグローバルロックが部分的にロックを所有している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.
選択：1つまたは複数のそれぞれが、XPath式を含む、要素の「選択」。 XPath式は、コンテキストノードがサーバの概念データモデルのルートであり、名前空間宣言のセットは、選択要素に範囲内のものであるコンテキストで評価されます。
The nodes returned from the select expressions are reported in the rpc-reply message.
SELECT式から返されたノードは、RPC応答メッセージで報告されています。
Each select expression MUST return a node set, and at least one of the node sets MUST be non-empty.
各選択式は、ノード・セットを返さなければならない、およびノードセットのうちの少なくとも一方は空でなければなりません。
If the device supports the :xpath capability, any valid XPath 1.0 expression can be used. If the device does not support the :xpath capability, the XPath expression MUST be limited to an Instance Identifier expression. An Instance Identifier is an absolute path expression in abbreviated syntax, where predicates are used only to specify values for nodes defined as keys to distinguish multiple instances.
デバイスがサポートしている場合：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のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" メッセージID = "135"> <部分的なロック> <のxmlnsを選択：RTE = "http://example.com/ns/route"> / RTE：ルーティング/ RTE：virtualRouter [RTE：routerName = 'ルータ1'] </選択> <のxmlnsを選択します。if = "http://example.com/ns/interface"> / IF：インターフェイス/ IF：インターフェイス[場合：ID = 'eth1の'] </選択> </部分的なロック> </ 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>
<NC：RPC返信のxmlns：NCは= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" message- ID = "135"> <ロック-ID> 127 </ロック-ID> <ロック・ノードのxmlns：RTE = "http://example.com/ns/route"> / RTE：ルーティング/ RTE：virtualRouter [RTE ：routerName = 'ルータ1'] </ロック・ノード> <ロックされたノードのxmlns：もし= "http://example.com/ns/interface"> / IF：インターフェイス/ IF：インターフェイス[場合：ID = 'のeth1 「] </ロック・ノード> </ NC：RPC返信>
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返信>で<データ> 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返信>を満足することができた場合、<RPC返信>要素内の<ロック-ID>要素（ロック識別子）を用いて送信されます。ロックされたノードのリストは、インスタンス識別子の形式で返されます。
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.
ロックがすでにロックされるべきサブツリー内の任意のノード上の別のセッションによって保持されている場合、<エラータグ>要素である「ロック拒否」及び<エラー情報>要素は、ロックの<session-id>を含みますオーナー。ロックが0（ゼロ）の非NETCONFセッション<セッションID>に保持されている場合は含まれるべきです。要求セッションがすでに実行されているデータストアの（グローバル）ロックを保持している場合、同じエラー応答が返されます。
If needed, the returned session-id may be used to <kill-session> the NETCONF session holding the lock.
必要に応じて、返されたセッションIDは、<殺すセッション> NETCONFセッションがロックを保持するために使用することができます。
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.
動作は、以前に同じセッション中に<部分的なロック>を使用してロックされた実行データストアの部分のロックを解除します。操作は、ロック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.
ロックIDを：ロックのアイデンティティは、ロックを解除します。このロック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>
<NC：RPCのxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" メッセージID = "136"> <部分アンロック> <ロック-ID> 127 </ロック-ID> </部分アンロック> </ 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-応答を>要求を満たすことができた場合は、<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.
<ロック-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.
その操作がロックの保護領域内のノードを変更しようとするとロックが付与されているセッション以外のNETCONFセッションで実行された場合に成功した部分的なロックは、後続の操作は失敗します。 「使用中の」<エラータグ>と<エラーアプリ内タグ>「ロック」を返します。 <編集-config>の、<コピー設定>、<削除-config>の、<コミット>、および<廃棄の変更>：実行中のデータストアを変更するすべての操作には、影響を受けています。部分的ロックいくつかのデータを修正することを防止する<編集-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.
データストアは、部分的ロックによってロックされたノードが含まれている場合、これは（グローバル）<ロック>操作が失敗します。ロック所有者の<誤差タグ>要素「ロック・拒否された」と<セッションID>を含む<エラー-info>要素が返されます。ロックが0（ゼロ）の非NETCONFセッション<セッション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.
候補データストアは、<部分的ロック>操作を使用してロックすることはできません。
If:
もし：
o a partial lock is requested for the running datastore, and
O部分的ロックが実行されているデータストアのために要求され、そして
o the NETCONF server implements the :confirmed-commit capability, and
NETCONFサーバが実装○：機能を確認し、コミット、および
o there was a recent confirmed <commit> operation where the confirming <commit> operation has not been received
O <コミット>動作確認を受けていない、最近確認した<コミット>操作がありました
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.
この場合、<エラータグ>「使用中」と<エラーアプリ内タグ>「卓越した-確認-コミット」を返します。
The startup datastore cannot be locked using the <partial-lock> operation.
スタートアップデータストアは、<部分的ロック>操作を使用してロックすることはできません。
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]のような関連しています。 <部分的なロック>と<部分アンロック>のRPCは、認証されたユーザに許可されなければなりません。 <部分的なロック>と<部分アンロック>のRPCは、許可されたユーザのために許容されるべきです。 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接続）のためにハングしているロックが明示的に<殺すセッションを>操作を使用してロックセッション所有を殺すことによって、別の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）能力壺」レジストリから1つの能力識別子URN、及び「IETF XMLレジストリ」のNETCONFのXML名前空間のための1つのURI [RFC3688]を登録します。機能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
URI：URN：IETF：のparams：XML：NS：NETCONF：部分的ロック：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.
このドキュメントへの重要なインプットを提供するためのアンディBierman、シャロン・チザム、フィル・シェーファー、デヴィッド・ハリントン、メフメットErsue、ウェスHardaker、ユルゲンSchoenwaelder、Washamファン、およびNETCONF WGの多くの他のメンバーに感謝します。
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[NETCONF]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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 - NETCONFのためのデータモデリング言語"、進歩、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スキーマは、<部分的ロック>と<部分アンロック>操作を定義します。
<CODE BEGINS>
<CODEが開始されます>
<?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">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns = "壷：IETF：のparams：XML ：NS：NETCONF：部分的なロック：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のtargetNamespace = "URN：IETF：paramsは：XML：NS：NETCONF：パーシャル・ロック：1.0" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<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
バラージュLengyel balazs.lengyel@ericsson.com
revision 2009-10-19 description Initial version, published as RFC 5717. </xs:documentation> </xs:annotation>
改正2009-10-19記述初期バージョンは、RFCとして公開5717. </ XS：ドキュメンテーション> </ XS：注釈>
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
<XS：インポート名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のschemaLocation = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：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：simpleTypeの名前= "ロック-ID型"> <XS：注釈> <XS：ドキュメント>セッションに付与された特定部分のロックを識別する番号。これは、システムによって割り当てられ、ロック解除操作で使用されるべきです。 </ XS：ドキュメント> </ XS：注釈> <XS：制限ベース= "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の名= "partialLockType"> <XS：注釈> <XS：ドキュメント>ランニングデータストアの一部をロックNETCONF操作。 </ XS：ドキュメント> </ XS：注釈> <XS：complexContentを> <XS：増設ベース= "NC：rpcOperationType"> <XS：配列> <XS：要素名=タイプを "選択" = "XS：文字列" maxOccurs = "無制限"> <XS：注釈> <XS：ドキュメント>ロックの範囲を指定するXPath式。 XPathの機能任意のXPath 1.0式が許可される場合にはサポートされていますない限り、インスタンス識別子の表現を使用しなければなりません。 </ XS：ドキュメント> </ XS：注釈> </ XS：要素> </ XS：配列> </ XS：拡張> </ 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：complexTypeの名= "partialUnLockType"> <XS：注釈> <XS：ドキュメント>以前に取得した部分ロックを解除するNETCONF操作。 </ XS：ドキュメント> </ XS：注釈> <XS：complexContentを> <XS：拡張ベース= "NC：rpcOperationType"> <XS：配列> <XS：要素名= "ロックID" タイプ= "ロックインID型 "> <XS：注釈> <XS：ドキュメント>がリリースされるロックを識別します。部分的なロック操作に応答して受信された値でなければなりません。 </ XS：ドキュメンテーション> </ XS：注釈> </ XS：要素> </ XS：シーケンス> </ XS：拡張>
</xs:complexContent> </xs:complexType>
</ XS：complexContentを> </ XS：complexTypeの>
<!-- <partial-lock> operation --> <xs:element name="partial-lock" type="partialLockType" substitutionGroup="nc:rpcOperation"/>
< - <部分的ロック>操作 - > <！XS：要素名= "部分ロック" タイプ= "partialLockType" のsubstitutionGroup = "NC：rpcOperation" />
<!-- <partial-unlock> operation --> <xs:element name="partial-unlock" type="partialUnLockType" substitutionGroup="nc:rpcOperation"/>
<！ - <パーシャルロック解除>操作 - > <XS：要素名= "部分アンロック" タイプ= "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>
<XS：complexTypeの名=「contentPartInPartialLockReplyType」> <XS：注釈> <XS：ドキュメント>成功した部分的なロック要求に対する応答の内容は、この複合型に従わなければなりません。 </ XS：ドキュメント> </ XS：注釈> <XS：配列> <XS：要素名= "ロックID" タイプ= "ロックID型"> <XS：注釈> <XS：ドキュメントは>識別ロックが解除されます。パーシャル・ロック操作に応答して受信された値でなければなりません。 </ XS：ドキュメント> </ XS：注釈> </ XS：要素> <XS：要素名= "ロック・ノード" TYPE = "XS：文字列" のmaxOccurs = "無制限"> <XS：注釈> <XS：ドキュメント>ランニングデータストア内のロックされたノードのリスト。 </ XS：ドキュメント> </ XS：注釈> </ XS：要素> </ XS：配列> </ XS：complexTypeの> </ XS：スキーマ>
<CODE ENDS>
<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モジュールは<部分的ロック>と<部分アンロック>操作を定義します。 YANG言語は[YANG]で定義されています。
<CODE BEGINS>
<CODEが開始されます>
module ietf-netconf-partial-lock {
モジュールIETF-NETCONF-部分ロック{
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ウェブ：http://www.ietf.org/html.charters/netconf-charter.html
Balazs Lengyel Ericsson balazs.lengyel@ericsson.com";
バラージュLengyelエリクソンbalazs.lengyel@ericsson.com「。
description "This YANG module defines the <partial-lock> and <partial-unlock> operations.";
説明は「このYANGモジュールは<部分的ロック>と<部分アンロック>操作を定義します。」;
revision 2009-10-19 { description "Initial version, published as RFC 5717."; }
改訂2009年10月19日{説明「初期バージョンは、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>
<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.
部分的なロックが効果的に将来の使用のためにそれらを確保しようと、存在しないノードをロックするために使用することはできません。ノードは、他のいくつかのセッションによって作成することができないことを保証するために、親ノードは、作成した新しいサブツリーの最上位ノードをロックし、その後、別の<部分的ロック>操作でロックする必要があります。この後、親ノードのロックを削除する必要があります。
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.
私たちは、<ユーザー>の下に<ユーザー>ジョーを作成し、それを編集を開始します。編集分の数がかかる場合があります。我々はすぐに我々が編集を終了する前に、その誰もがそれを触れないだろうジョーをロックします。
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>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/users "> <ユーザー/> </トップ> </フィルタ> </取得-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>
<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/users"> <ユーザー> <ユーザー> <名前>フレッド</名前> <電話> 8327 </電話> </ユーザー> </ユーザー> </ TOP> </データ> </ RPC返信>
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.
私たちは、新しいユーザージョーを追加して、すぐに部分的ロックを使用して、彼をロックします。これを行う方法は、最初の<ユーザー>ノードをロックすることにより、すべての<ユーザー>ノードをロックすることです。
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：ユーザーは/ usr：は/ usrユーザーの我々は選択式を使用して、すべての<ユーザー>のノードをロックするかどうことに注意してください。これは私たちがロックした後に作成される新しいユーザージョーをロックしないでしょう。だから我々は、むしろ<ユーザー>ノードをロックする必要があります。
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>
<NC：RPCのxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" メッセージID = "102"> <部分的なロック> <のxmlns選択：USR = "http://example.com/users"> / USR：トップ/ USR：ユーザー</選択> </部分的なロック> </ 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>
<NC：RPC返信のxmlns：NCは= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" message- ID = "102"> <ロック-ID> 1 </ロック-ID> <ロック・ノードのxmlns：USR = "http://example.com/users"> / USR：トップ/ USR：ユーザー</ locked-ノード> </ NC：RPC-返信>
Next we create user Joe. Joe is protected by the lock received above, as it is under the subtree rooted at the <users> node.
次は、ユーザージョーを作成します。ジョーは、ロックによって保護され、それは<ユーザー>ノードをルートとするサブツリーの下にあるように、上記受信されました。
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>
<RPCメッセージID = "103" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </標的> <設定> <トップxmlns：USR = "http://example.com/users"> <ユーザー> <ユーザー> <名前>ジョー</名前> </ユーザー> </ユーザー> </トップ> </ 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.
私たちは、<編集-config>のに対して正の応答（図示せず）を受け取ります。次はロックのみ<ユーザー> Joeが、そして<ユーザー>ノードのロックを解除することを、ロックを要求します。これは、他の管理者が追加の新規ユーザーを作成することができます。
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>
<NC：RPCのxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" メッセージID = "104"> <部分的なロック> <のxmlnsを選択：USR = "http://example.com/users"> / USR：トップ/ USR：ユーザ/ユーザ[USR：名= "ジョー"]」</選択> </パーシャル・ロック> </ 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ロックの範囲は、名前ジョーを持つ唯一の<ユーザー>ノードを含みます。ロックは、この特定の<ユーザー>ノードの下にあるすべてのデータを保護します。
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>
<NC：RPC返信のxmlns：NCは= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" message- ID = "104"> <ロック-ID> 2 </ロック-ID> <ロック・ノードのxmlns：USR = "http://example.com/users"> / USR：トップ/ USR：ユーザ/ユーザ[USR ：名= "ジョー"]」</ロック・ノード> </ NC：RPC返信>
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のロックの範囲は、<ユーザ>ノードジョーです。これは、この<ユーザー>ノードとその下の任意のデータ（例えば、電話番号）を保護します。この時点で、これらのノードは、第1および第2のロックの両方によって保護されています。次に、我々は他のマネージャーがそれらに取り組むことができるように、他の<ユーザー> sおよび<ユーザー>ノードのロックを解除します。我々はまだ第2のロックを維持するため、<ユーザー>ノードジョーと下のサブツリーは、まだ保護されています。
Step 8 - Release lock on <users>
ステップ8 - <ユーザー>にリリースロック
<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>
<NC：RPCのxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：部分的なロック：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" メッセージID = "105"> <部分アンロック> <ロック-ID> 1 </ロック-ID> </部分アンロック> </ NC：RPC>
Authors' Addresses
著者のアドレス
Balazs Lengyel Ericsson
バラージュLengyelエリクソン
EMail: balazs.lengyel@ericsson.com
メールアドレス：balazs.lengyel@ericsson.com
Martin Bjorklund Tail-f Systems
マーティンBjorklundテール-Fシステム
EMail: mbj@tail-f.com
メールアドレス：mbj@tail-f.com