[要約] RFC 4741はNETCONF Configuration Protocolの仕様を定義しており、ネットワークデバイスの設定と管理を効率化するためのプロトコルです。目的は、ネットワーク機器の設定を自動化し、ネットワーク管理者の作業を簡素化することです。
Network Working Group R. Enns, Ed.
Request for Comments: 4741 Juniper Networks
Category: Standards Track December 2006
NETCONF Configuration Protocol
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) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer.
このドキュメントで定義されているネットワーク構成プロトコル（NetConf）は、ネットワークデバイスの構成をインストール、操作、削除するメカニズムを提供します。拡張可能なマークアップ言語（XML）ベースのデータを使用して、構成データとプロトコルメッセージにエンコードします。NetConfプロトコル操作は、単純なリモートプロシージャコール（RPC）レイヤーの上に実現されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Protocol Overview ..........................................6
1.2. Capabilities ...............................................7
1.3. Separation of Configuration and State Data .................7
2. Transport Protocol Requirements .................................8
2.1. Connection-Oriented Operation ..............................9
2.2. Authentication, Integrity, and Confidentiality .............9
2.3. Authentication .............................................9
2.4. Mandatory Transport Protocol ..............................10
3. XML Considerations .............................................10
3.1. Namespace .................................................10
3.2. No Document Type Declarations .............................10
4. RPC Model ......................................................10
4.1. <rpc> Element .............................................10
4.2. <rpc-reply> Element .......................................12
4.3. <rpc-error> Element .......................................12
4.4. <ok> Element ..............................................16
4.5. Pipelining ................................................16
5. Configuration Model ............................................16
5.1. Configuration Datastores ..................................16
5.2. Data Modeling .............................................17
6. Subtree Filtering ..............................................17
6.1. Overview ..................................................17
6.2. Subtree Filter Components .................................18
6.2.1. Namespace Selection ................................18
6.2.2. Attribute Match Expressions ........................19
6.2.3. Containment Nodes ..................................19
6.2.4. Selection Nodes ....................................20
6.2.5. Content Match Nodes ................................20
6.3. Subtree Filter Processing .................................22
6.4. Subtree Filtering Examples ................................22
6.4.1. No Filter ..........................................22
6.4.2. Empty Filter .......................................23
6.4.3. Select the Entire <users> Subtree ..................23
6.4.4. Select All <name> Elements within the
<users> Subtree ....................................25
6.4.5. One Specific <user> Entry ..........................26
6.4.6. Specific Elements from a Specific <user> Entry .....27
6.4.7. Multiple Subtrees ..................................28
6.4.8. Elements with Attribute Naming .....................29
7. Protocol Operations ............................................31
7.1. <get-config> ..............................................31
7.2. <edit-config> .............................................34
7.3. <copy-config> .............................................39
7.4. <delete-config> ...........................................41
7.5. <lock> ....................................................42
7.6. <unlock> ..................................................44
7.7. <get> .....................................................45
7.8. <close-session> ...........................................47
7.9. <kill-session> ............................................48
8. Capabilities ...................................................49
8.1. Capabilities Exchange .....................................49
8.2. Writable-Running Capability ...............................50
8.2.1. Description ........................................50
8.2.2. Dependencies .......................................50
8.2.3. Capability Identifier ..............................50
8.2.4. New Operations .....................................51
8.2.5. Modifications to Existing Operations ...............51
8.3. Candidate Configuration Capability ........................51
8.3.1. Description ........................................51
8.3.2. Dependencies .......................................52
8.3.3. Capability Identifier ..............................52
8.3.4. New Operations .....................................52
8.3.5. Modifications to Existing Operations ...............53
8.4. Confirmed Commit Capability ...............................55
8.4.1. Description ........................................55
8.4.2. Dependencies .......................................55
8.4.3. Capability Identifier ..............................56
8.4.4. New Operations .....................................56
8.4.5. Modifications to Existing Operations ...............56
8.5. Rollback on Error Capability ..............................57
8.5.1. Description ........................................57
8.5.2. Dependencies .......................................57
8.5.3. Capability Identifier ..............................57
8.5.4. New Operations .....................................57
8.5.5. Modifications to Existing Operations ...............57
8.6. Validate Capability .......................................58
8.6.1. Description ........................................58
8.6.2. Dependencies .......................................58
8.6.3. Capability Identifier ..............................58
8.6.4. New Operations .....................................58
8.7. Distinct Startup Capability ...............................60
8.7.1. Description ........................................60
8.7.2. Dependencies .......................................60
8.7.3. Capability Identifier ..............................60
8.7.4. New Operations .....................................60
8.7.5. Modifications to Existing Operations ...............60
8.8. URL Capability ............................................61
8.8.1. Description ........................................61
8.8.2. Dependencies .......................................61
8.8.3. Capability Identifier ..............................62
8.8.4. New Operations .....................................62
8.8.5. Modifications to Existing Operations ...............62
8.9. XPath Capability ..........................................63
8.9.1. Description ........................................63
8.9.2. Dependencies .......................................63
8.9.3. Capability Identifier ..............................63
8.9.4. New Operations .....................................63
8.9.5. Modifications to Existing Operations ...............63
9. Security Considerations ........................................64
10. IANA Considerations ...........................................66
10.1. NETCONF XML Namespace ....................................66
10.2. NETCONF XML Schema .......................................66
10.3. NETCONF Capability URNs ..................................66
11. Authors and Acknowledgements ..................................68
12. References ....................................................68
12.1. Normative References .....................................68
12.2. Informative References ...................................69
Appendix A. NETCONF Error List ....................................70
Appendix B. XML Schema for NETCONF RPC and Protocol Operations ....74
Appendix C. Capability Template ...................................86
C.1. capability-name (template) ................................86
C.1.1. Overview ...........................................86
C.1.2. Dependencies .......................................86
C.1.3. Capability Identifier ..............................86
C.1.4. New Operations .....................................86
C.1.5. Modifications to Existing Operations ...............86
C.1.6. Interactions with Other Capabilities ...............86
Appendix D. Configuring Multiple Devices with NETCONF ............87
D.1. Operations on Individual Devices ..........................87
D.1.1. Acquiring the Configuration Lock ...................87
D.1.2. Loading the Update .................................88
D.1.3. Validating the Incoming Configuration ..............89
D.1.4. Checkpointing the Running Configuration ............89
D.1.5. Changing the Running Configuration .................90
D.1.6. Testing the New Configuration ......................91
D.1.7. Making the Change Permanent ........................91
D.1.8. Releasing the Configuration Lock ...................92
D.2. Operations on Multiple Devices ............................92
Appendix E. Deferred Features .....................................93
The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets.
NetConfプロトコルは、ネットワークデバイスを管理し、構成データ情報を取得し、新しい構成データをアップロードおよび操作できる簡単なメカニズムを定義します。このプロトコルにより、デバイスは完全な正式なアプリケーションプログラミングインターフェイス（API）を公開できます。アプリケーションは、この簡単なAPIを使用して、完全かつ部分的な構成データセットを送信および受信できます。
The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML [1] and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange.
NetConfプロトコルは、リモートプロシージャコール（RPC）パラダイムを使用します。クライアントはXML [1]のRPCをエンコードし、安全で接続指向のセッションを使用してサーバーに送信します。サーバーは、XMLでエンコードされた返信で応答します。リクエストと応答の両方の内容は、XML DTDまたはXMLスキーマまたはその両方で完全に説明されているため、両当事者は交換に課される構文制約を認識できます。
A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native functionality of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface.
NetConfの重要な側面は、管理プロトコルの機能がデバイスのネイティブ機能を綿密にミラーリングできることです。これにより、実装コストが削減され、新機能へのタイムリーなアクセスが可能になります。さらに、アプリケーションは、デバイスのネイティブユーザーインターフェイスの構文コンテンツとセマンティックコンテンツの両方にアクセスできます。
NETCONF allows a client to discover the set of protocol extensions supported by a server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. Standard and non-standard capabilities can be defined with semantic and syntactic rigor. Capabilities are discussed in Section 8.
NetConfを使用すると、クライアントはサーバーがサポートするプロトコル拡張セットを発見できます。これらの「機能」により、クライアントは動作を調整して、デバイスによって公開される機能を活用できます。機能定義は、非中心的な方法で簡単に拡張できます。標準および非標準の機能は、セマンティックおよび構文の厳密さで定義できます。機能については、セクション8で説明します。
The NETCONF protocol is a building block in a system of automated configuration. XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XML-based transformation technologies, such as XSLT [8], to provide a system for automated generation of full and partial configurations. The system can query one or more databases for data about networking topologies, links, policies, customers, and services. This data can be transformed using one or more XSLT scripts from a task-oriented, vendor-independent data schema into a form that is specific to the vendor, product, operating system, and software release. The resulting data can be passed to the device using the NETCONF protocol.
NetConfプロトコルは、自動構成のシステムの構成要素です。XMLは、インターチェンジのLingua Francaであり、階層コンテンツの柔軟なが完全に指定されたエンコーディングメカニズムを提供します。NetConfは、XSLT [8]などのXMLベースの変換テクノロジーと協調して、完全および部分構成の自動生成のシステムを提供することができます。システムは、ネットワーキングトポロジ、リンク、ポリシー、顧客、およびサービスに関するデータの1つ以上のデータベースを照会できます。このデータは、タスク指向のベンダーに依存しないデータスキーマから、ベンダー、製品、オペレーティングシステム、およびソフトウェアリリースに固有のフォームに1つ以上のXSLTスクリプトを使用して変換できます。結果のデータは、NetConfプロトコルを使用してデバイスに渡すことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [3]に記載されているように解釈される。
NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server. The client can be a script or application typically running as part of a network manager. The server is typically a network device. The terms "device" and "server" are used interchangeably in this document, as are "client" and "application".
NetConfは、単純なRPCベースのメカニズムを使用して、クライアントとサーバー間の通信を促進します。クライアントは、通常、ネットワークマネージャーの一部として実行されているスクリプトまたはアプリケーションにすることができます。サーバーは通常、ネットワークデバイスです。「デバイス」と「サーバー」という用語は、「クライアント」と「アプリケーション」と同様に、このドキュメントで同じ意味で使用されます。
A NETCONF session is the logical connection between a network administrator or network configuration application and a network device. A device MUST support at least one NETCONF session and SHOULD support multiple sessions. Global configuration attributes can be changed during any authorized session, and the effects are visible in all sessions. Session-specific attributes affect only the session in which they are changed.
NetConfセッションは、ネットワーク管理者またはネットワーク構成アプリケーションとネットワークデバイスとの間の論理的な接続です。デバイスは、少なくとも1つのNetConfセッションをサポートする必要があり、複数のセッションをサポートする必要があります。承認されたセッション中にグローバル構成属性を変更でき、すべてのセッションで効果が表示されます。セッション固有の属性は、変更されたセッションのみに影響します。
NETCONF can be conceptually partitioned into four layers:
NetConfは、概念的に4つのレイヤーに分割できます。
Layer Example
+-------------+ +-----------------------------+
(4) | Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(3) | Operations | | <get-config>, <edit-config> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(2) | RPC | | <rpc>, <rpc-reply> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(1) | Transport | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+
1. The transport protocol layer provides a communication path between the client and server. NETCONF can be layered over any transport protocol that provides a set of basic requirements. Section 2 discusses these requirements.
1. トランスポートプロトコル層は、クライアントとサーバーの間の通信パスを提供します。NetConfは、一連の基本的な要件を提供する任意の輸送プロトコルの上に階層化できます。セクション2では、これらの要件について説明します。
2. The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. Section 4 documents this protocol.
2. RPCレイヤーは、RPCをエンコードするためのシンプルで輸送に依存しないフレーミングメカニズムを提供します。セクション4はこのプロトコルを文書化しています。
3. The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base operations.
3. 操作層は、XMLエンコードパラメーターを使用してRPCメソッドとして呼び出される一連のベース操作を定義します。セクション7では、基本操作のリストを詳しく説明しています。
4. The content layer is outside the scope of this document. Given the current proprietary nature of the configuration data being manipulated, the specification of this content depends on the NETCONF implementation. It is expected that a separate effort to specify a standard data definition language and standard content will be undertaken.
4. コンテンツレイヤーは、このドキュメントの範囲外です。操作されている構成データの現在の独自の性質を考えると、このコンテンツの仕様はNetConfの実装に依存します。標準のデータ定義言語と標準コンテンツを指定するための個別の努力が実施されることが期待されています。
A NETCONF capability is a set of functionality that supplements the base NETCONF specification. The capability is identified by a uniform resource identifier (URI). These URIs should follow the guidelines as described in Section 8.
NetConf機能は、ベースのNetConf仕様を補完する一連の機能です。機能は、均一なリソース識別子（URI）によって識別されます。これらのURIは、セクション8で説明されているガイドラインに従う必要があります。
Capabilities augment the base operations of the device, describing both additional operations and the content allowed inside operations. The client can discover the server's capabilities and use any additional operations, parameters, and content defined by those capabilities.
The capability definition may name one or more dependent capabilities. To support a capability, the server MUST support any capabilities upon which it depends.
機能定義には、1つ以上の従属機能に名前を付けることができます。機能をサポートするには、サーバーが依存する機能をサポートする必要があります。
Section 8 defines the capabilities exchange that allows the client to discover the server's capabilities. Section 8 also lists the set of capabilities defined in this document.
セクション8では、クライアントがサーバーの機能を発見できるようにする機能交換を定義しています。セクション8には、このドキュメントで定義されている一連の機能も示します。
Additional capabilities can be defined at any time in external documents, allowing the set of capabilities to expand over time. Standards bodies may define standardized capabilities, and implementations may define proprietary ones. A capability URI MUST sufficiently distinguish the naming authority to avoid naming collisions.
The information that can be retrieved from a running system is separated into two classes, configuration data and state data. Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. When a device is performing configuration operations, a number of problems would arise if state data were included:
実行中のシステムから取得できる情報は、構成データと状態データの2つのクラスに分けられます。構成データは、システムを最初のデフォルト状態から現在の状態に変換するために必要な書き込み可能なデータのセットです。状態データは、読み取り専用のステータス情報や収集された統計などの構成データではないシステム上の追加データです。デバイスが構成操作を実行している場合、状態データが含まれている場合、多くの問題が発生します。
o Comparisons of configuration data sets would be dominated by irrelevant entries such as different statistics.
o 構成データセットの比較は、異なる統計などの無関係なエントリによって支配されます。
o Incoming data could contain nonsensical requests, such as attempts to write read-only data.
o 着信データには、読み取り専用データを作成する試みなど、無意味なリクエストが含まれる場合があります。
o The data sets would be large.
o データセットは大きくなります。
o Archived data could contain values for read-only data items, complicating the processing required to restore archived data.
o アーカイブデータには、読み取り専用データ項目の値が含まれている場合があり、アーカイブデータを復元するために必要な処理を複雑にします。
To account for these issues, the NETCONF protocol recognizes the difference between configuration data and state data and provides operations for each. The <get-config> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data.
これらの問題を説明するために、NetConfプロトコルは構成データと状態データの違いを認識し、それぞれに操作を提供します。<get-config>操作は構成データのみを取得し、<get>操作は構成と状態データを取得します。
Note that the NETCONF protocol is focused on the information required to get the device into its desired running state. The inclusion of other important, persistent data is implementation specific. For example, user files and databases are not treated as configuration data by the NETCONF protocol.
NetConfプロトコルは、デバイスを目的の実行状態にするために必要な情報に焦点を当てていることに注意してください。他の重要で永続的なデータを含めることは、実装固有です。たとえば、ユーザーファイルとデータベースは、NetConfプロトコルによって構成データとして扱われません。
If a local database of user authentication data is stored on the device, whether it is included in configuration data is an implementation-dependent matter.
ユーザー認証データのローカルデータベースがデバイスに保存されている場合、構成データに含まれているかどうかは、実装依存の問題です。
NETCONF uses an RPC-based communication paradigm. A client sends a series of one or more RPC request operations, which cause the server to respond with a corresponding series of RPC replies.
NetConfはRPCベースの通信パラダイムを使用します。クライアントは、一連の1つ以上のRPC要求操作を送信します。これにより、サーバーは対応する一連のRPC応答で応答します。
The NETCONF protocol can be layered on any transport protocol that provides the required set of functionality. It is not bound to any particular transport protocol, but allows a mapping to define how it can be implemented over any specific protocol.
NetConfプロトコルは、必要な機能セットを提供する任意のトランスポートプロトコルに重ねることができます。特定のトランスポートプロトコルに拘束されていませんが、マッピングが特定のプロトコルを介してどのように実装できるかを定義できるようにします。
The transport protocol MUST provide a mechanism to indicate the session type (client or server) to the NETCONF protocol layer.
トランスポートプロトコルは、セッションタイプ（クライアントまたはサーバー）をNetConfプロトコルレイヤーに示すメカニズムを提供する必要があります。
This section details the characteristics that NETCONF requires from the underlying transport protocol.
このセクションでは、NetConfが基礎となる輸送プロトコルから必要とする特性について詳しく説明しています。
NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide reliable, sequenced data delivery.
NetConfは接続指向であり、ピア間の永続的な接続が必要です。この接続は、信頼できるシーケンスされたデータ配信を提供する必要があります。
NETCONF connections are long-lived, persisting between protocol operations. This allows the client to make changes to the state of the connection that will persist for the lifetime of the connection. For example, authentication information specified for a connection remains in effect until the connection is closed.
NetConf接続は長寿命であり、プロトコル操作の間に持続します。これにより、クライアントは、接続の生涯にわたって持続する接続の状態に変更を加えることができます。たとえば、接続に指定された認証情報は、接続が閉じるまで有効です。
In addition, resources requested from the server for a particular connection MUST be automatically released when the connection closes, making failure recovery simpler and more robust. For example, when a lock is acquired by a client, the lock persists until either it is explicitly released or the server determines that the connection has been terminated. If a connection is terminated while the client holds a lock, the server can perform any appropriate recovery. The lock operation is further discussed in Section 7.5.
さらに、特定の接続に対してサーバーから要求されたリソースは、接続が閉じるときに自動的にリリースされ、障害回復をより単純化し、より堅牢にする必要があります。たとえば、クライアントによってロックが取得されると、ロックは明示的にリリースされるか、サーバーが接続が終了したと判断するまで持続します。クライアントがロックを保持しているときに接続が終了すると、サーバーは適切な回復を実行できます。ロック操作については、セクション7.5でさらに説明します。
NETCONF connections must provide authentication, data integrity, and confidentiality. NETCONF depends on the transport protocol for this capability. A NETCONF peer assumes that appropriate levels of security and confidentiality are provided independently of this document. For example, connections may be encrypted in TLS [9] or SSH [10], depending on the underlying protocol.
NetConf接続は、認証、データの整合性、および機密性を提供する必要があります。NetConfは、この機能の輸送プロトコルに依存します。NetConfのピアは、適切なレベルのセキュリティと機密性がこのドキュメントとは無関係に提供されると想定しています。たとえば、基礎となるプロトコルに応じて、接続はTLS [9]またはSSH [10]で暗号化される場合があります。
NETCONF connections must be authenticated. The transport protocol is responsible for authentication. The peer assumes that the connection's authentication information has been validated by the underlying protocol using sufficiently trustworthy mechanisms and that the peer's identity has been sufficiently proven.
NetConf接続は認証する必要があります。トランスポートプロトコルは認証を担当します。ピアは、接続の認証情報が十分に信頼できるメカニズムを使用して基礎となるプロトコルによって検証され、ピアの身元が十分に証明されていると想定しています。
One goal of NETCONF is to provide a programmatic interface to the device that closely follows the functionality of the device's native interface. Therefore, it is expected that the underlying protocol uses existing authentication mechanisms defined by the device. For example, a device that supports RADIUS [11] should allow the use of RADIUS to authenticate NETCONF sessions.
NetConfの目標の1つは、デバイスのネイティブインターフェイスの機能に密接に従うプログラムインターフェイスをデバイスに提供することです。したがって、基礎となるプロトコルは、デバイスによって定義された既存の認証メカニズムを使用することが予想されます。たとえば、RADIUS [11]をサポートするデバイスは、RADIUSを使用してNetConfセッションを認証できるようにする必要があります。
The authentication process should result in an identity whose permissions are known to the device. These permissions MUST be enforced during the remainder of the NETCONF session.
認証プロセスは、デバイスに対して許可が知られているアイデンティティになるはずです。これらのアクセス許可は、NetConfセッションの残りの期間中に実施する必要があります。
A NETCONF implementation MUST support the SSH transport protocol mapping [4].
NetConfの実装は、SSH輸送プロトコルマッピングをサポートする必要があります[4]。
XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.
XMLは、NetConfのエンコード形式として機能し、XMLに固有の従来のテキストツールとツールの両方で読み、保存、操作できるテキスト形式で複雑な階層データを表現できます。
This section discusses a small number of XML-related considerations pertaining to NETCONF.
このセクションでは、NetConfに関連する少数のXML関連の考慮事項について説明します。
All NETCONF protocol elements are defined in the following namespace:
すべてのNetConfプロトコル要素は、次の名前空間で定義されています。
urn:ietf:params:xml:ns:netconf:base:1.0
NETCONF capability names MUST be URIs [5]. NETCONF capabilities are discussed in Section 8.
NetConf機能名はurisでなければなりません[5]。NetConf機能については、セクション8で説明します。
Document type declarations MUST NOT appear in NETCONF content.
ドキュメントタイプの宣言は、NetConfコンテンツに表示されてはなりません。
The NETCONF protocol uses an RPC-based communication model. NETCONF peers use <rpc> and <rpc-reply> elements to provide transport protocol-independent framing of NETCONF requests and responses.
NetConfプロトコルは、RPCベースの通信モデルを使用します。NetConfピアは<RPC>および<RPC-Reply>要素を使用して、NetConfリクエストと応答の輸送プロトコルに依存しないフレーミングを提供します。
The <rpc> element is used to enclose a NETCONF request sent from the client to the server.
<RPC>要素は、クライアントからサーバーに送信されたNetConf要求を囲むために使用されます。
The <rpc> element has a mandatory attribute "message-id", which is an arbitrary string chosen by the sender of the RPC that will commonly encode a monotonically increasing integer. The receiver of the RPC does not decode or interpret this string but simply saves it to be used as a "message-id" attribute in any resulting <rpc-reply> message. For example:
<RPC>要素には、RPCの送信者が選択した任意の文字列である必須属性「Message-ID」があり、一般に単調に増加する整数をエンコードします。RPCの受信機は、この文字列をデコードまたは解釈するのではなく、結果の<RPC-Reply>メッセージの「メッセージID」属性として使用するように保存するだけです。例えば：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>
<!-- method parameters here... -->
</some-method>
</rpc>
If additional attributes are present in an <rpc> element, a NETCONF peer MUST return them unmodified in the <rpc-reply> element.
追加の属性が<RPC>要素に存在する場合、NetConfピアは<RPC-Reply>要素で修正されていないものを返す必要があります。
The name and parameters of an RPC are encoded as the contents of the <rpc> element. The name of the RPC is an element directly inside the <rpc> element, and any parameters are encoded inside this element.
RPCの名前とパラメーターは、<RPC>要素の内容としてエンコードされます。RPCの名前は、<RPC>要素内部の直接の要素であり、パラメーターはこの要素内にエンコードされています。
The following example invokes a method called <my-own-method>, which has two parameters, <my-first-parameter>, with a value of "14", and <another-parameter>, with a value of "fred":
次の例では、<my-own-method>と呼ばれるメソッドを呼び出します。これには、「14」の値を持つ2つのパラメーター、<my-first-parameter>、および<Another-Parameter>、「Fred」の値があります。：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<my-own-method xmlns="http://example.net/me/my-own/1.0">
<my-first-parameter>14</my-first-parameter>
<another-parameter>fred</another-parameter>
</my-own-method>
</rpc>
The following example invokes a <rock-the-house> method with a <zip-code> parameter of "27606-0100":
次の例では、「27606-0100」の<zip-code>パラメーターを使用して<rock-the-house>メソッドを呼び出します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
The following example invokes the NETCONF <get> method with no parameters:
次の例では、パラメーターのないNetConf <get>メソッドを呼び出します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
The <rpc-reply> message is sent in response to an <rpc> operation.
<rpc-reply>メッセージは、<rpc>操作に応じて送信されます。
The <rpc-reply> element has a mandatory attribute "message-id", which is equal to the "message-id" attribute of the <rpc> for which this is a response.
<RPC-Reply>要素には、必須の属性「Message-ID」があります。これは、これが応答である<RPC>の「Message-ID」属性に等しくなります。
A NETCONF peer MUST also return any additional attributes included in the <rpc> element unmodified in the <rpc-reply> element.
NetConfのピアは、<RPC>要素に<RPC-Reply>要素に変更されていない追加の属性も返品する必要があります。
The response name and response data are encoded as the contents of the <rpc-reply> element. The name of the reply is an element directly inside the <rpc-reply> element, and any data is encoded inside this element.
応答名と応答データは、<rpc-reply>要素の内容としてエンコードされます。返信の名前は、<RPC-Reply>要素の直接の要素であり、データはこの要素内にエンコードされています。
For example:
例えば：
The following <rpc> element invokes the NETCONF <get> method and includes an additional attribute called "user-id". Note that the "user-id" attribute is not in the NETCONF namespace. The returned <rpc-reply> element returns the "user-id" attribute, as well as the requested content.
次の<RPC>要素は、NetConf <Get>メソッドを呼び出し、「user-id」と呼ばれる追加の属性を含みます。「user-id」属性はNetConfの名前空間にないことに注意してください。返された<RPC-Reply>要素は、「ユーザーID」属性と要求されたコンテンツを返します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<data>
<!-- contents here... -->
</data>
</rpc-reply>
The <rpc-error> element is sent in <rpc-reply> messages if an error occurs during the processing of an <rpc> request.
<rpc-error>要素は、<rpc>要求の処理中にエラーが発生した場合、<rpc-reply>メッセージで送信されます。
If a server encounters multiple errors during the processing of an <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error> elements. However, a server is not required to detect or report more than one <rpc-error> element, if a request contains multiple errors. A server is not required to check for particular error conditions in a specific sequence. A server MUST return an <rpc-error> element if any error conditions occur during processing and SHOULD return an <rpc-error> element if any warning conditions occur during processing.
サーバーがAN <RPC>リクエストの処理中に複数のエラーに遭遇した場合、<RPC-Reply>には複数の<RPC-Error>要素が含まれる場合があります。ただし、要求に複数のエラーが含まれている場合、サーバーは複数の<RPC-Error>要素を検出または報告する必要はありません。サーバーは、特定のシーケンスで特定のエラー条件を確認する必要はありません。サーバーは、処理中にエラー条件が発生した場合は<RPC-ERROR>要素を返す必要があり、処理中に警告条件が発生した場合は<RPC-Error>要素を返します。
A server MUST NOT return application-level- or data-model-specific error information in an <rpc-error> element for which the client does not have sufficient access rights.
サーバーは、クライアントが十分なアクセス権を持っていない<rpc-error>要素にアプリケーションレベルまたはデータモデル固有のエラー情報を返してはなりません。
The <rpc-error> element includes the following information:
<rpc-error>要素には、次の情報が含まれています。
error-type: Defines the conceptual layer that the error occurred. Enumeration. One of:
エラータイプ：エラーが発生したという概念レイヤーを定義します。列挙。の一つ：
* transport
* 輸送
* rpc
* RPC
* protocol
* プロトコル
* application
* 応用
error-tag: Contains a string identifying the error condition. See Appendix A for allowed values.
エラータグ：エラー条件を識別する文字列が含まれています。許可された値については、付録Aを参照してください。
error-severity: Contains a string identifying the error severity, as determined by the device. One of:
エラー - 過剰：デバイスによって決定されるエラーの重大度を識別する文字列が含まれています。の一つ：
* error
* エラー
* warning
* 警告
error-app-tag: Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition.
エラーアプリタグ：存在する場合、データモデル固有または実装固有のエラー条件を識別する文字列が含まれています。適切なアプリケーションエラータグが特定のエラー条件に関連付けられない場合、この要素は存在しません。
error-path: Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace.
エラーパス：特定のRPCエラー要素で報告されているエラーに関連付けられているノードへの要素パスを識別する絶対XPath [2]式が含まれています。適切なペイロード要素が特定のエラー条件に関連付けられない場合、または「エラーインフォー」コンテナで「エラーとインフォ」コンテナで返された「バッドエレメント」QSTRINGがエラーに関連付けられたノードを識別するのに十分である場合、この要素は存在しません。XPath式が解釈されると、名前空間宣言のセットは、デフォルトの名前空間を含むRPC-Error要素の範囲にあります。
error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute as defined in [1] and discussed in [12].
エラーメサージ：エラー条件を説明する人間のディスプレイに適した文字列が含まれています。特定のエラー条件に適切なメッセージが提供されていない場合、この要素は存在しません。この要素には、[1]で定義され、[12]で説明されているXML：Lang属性を含める必要があります。
error-info: Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in Appendix A defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information.
エラーINFO：プロトコルまたはデータモデル固有のエラーコンテンツが含まれています。特定のエラー条件に対してそのようなエラーコンテンツが提供されていない場合、この要素は存在しません。付録Aのリストは、各エラーの必須のエラーINFOコンテンツを定義しています。プロトコルが義務付けているコンテンツの後、データモデル定義は、特定のアプリケーション層エラー情報をエラーとFOコンテナに含めることを義務付ける場合があります。実装には、拡張および/または実装固有のデバッグ情報を提供するための追加要素が含まれる場合があります。
Appendix A enumerates the standard NETCONF errors.
付録Aでは、標準のNetConfエラーを列挙しています。
Example:
例：
An error is returned if an <rpc> element is received without a message-id attribute. Note that only in this case is it acceptable for the NETCONF peer to omit the message-id attribute in the <rpc-reply> element.
メッセージ-ID属性なしで<RPC>要素が受信されると、エラーが返されます。この場合にのみ、NetConfピアが<RPC-Reply>要素でメッセージ-ID属性を省略することは許容されることに注意してください。
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>rpc</error-type>
<error-tag>missing-attribute</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
The following <rpc-reply> illustrates the case of returning multiple <rpc-error> elements.
以下の<RPC-Reply>は、複数の<RPC-Error>要素を返す場合を示しています。
Note that the data models used in the examples in this section use the <name> element to distinguish between multiple instances of the <interface> element.
このセクションの例で使用されているデータモデルは、<name>要素を使用して、<interface>要素の複数のインスタンスを区別することに注意してください。
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">
MTU value 25000 is not within range 256..9192
</error-message>
<error-info>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>25000</mtu>
</interface>
</top>
</error-info>
</rpc-error>
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">
Invalid IP address for interface Ethernet1/0
</error-message>
<error-info>
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet1/0</name>
<address>
<name>1.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</error-info>
</rpc-error>
</rpc-reply>
The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request. For example:
<ok>要素は、<rpc>リクエストの処理中にエラーや警告が発生しなかった場合、<rpc-reply>メッセージで送信されます。例えば：
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
NETCONF <rpc> requests MUST be processed serially by the managed device. Additional <rpc> requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.
NetConf <RPC>リクエストは、管理されたデバイスによって連続的に処理する必要があります。追加の<rpc>リクエストは、以前のものが完了する前に送信される場合があります。管理されたデバイスは、リクエストを受信した順序でのみ応答を送信する必要があります。
NETCONF provides an initial set of operations and a number of capabilities that can be used to extend the base. NETCONF peers exchange device capabilities when the session is initiated as described in Section 8.1.
NetConfは、初期の操作セットと、ベースの拡張に使用できる多くの機能を提供します。セクション8.1で説明されているように、セッションが開始された場合、NetConfピア交換デバイス機能。
NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them. A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands.
NetConfは、1つ以上の構成データストアの存在を定義し、それらの構成操作を許可します。構成データストアは、最初のデフォルト状態からデバイスを目的の動作状態にするために必要な構成データの完全なセットとして定義されます。構成データストアには、状態データやエグゼクティブコマンドは含まれません。
Only the <running> configuration datastore is present in the base model. Additional configuration datastores may be defined by capabilities. Such configuration datastores are available only on devices that advertise the capabilities.
<runing>構成データストアのみがベースモデルに存在します。追加の構成データストアは、機能によって定義される場合があります。このような構成データストアは、機能を宣伝するデバイスでのみ使用できます。
o Running: The complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. NETCONF protocol operations refer to this datastore using the <running> element.
o 実行：ネットワークデバイスで現在アクティブな完全な構成。このタイプの1つの構成データストアのみがデバイスに存在し、常に存在します。NetConfプロトコル操作<runing>要素を使用して、このデータストアを参照してください。
The capabilities in Sections 8.3 and 8.7 define the <candidate> and <startup> configuration datastores, respectively.
セクション8.3および8.7の機能は、それぞれ<condative>および<startup>構成データストアを定義します。
Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model.
データモデリングとコンテンツの問題は、NetConfプロトコルの範囲外です。デバイスのデータモデルはアプリケーションによく知られており、両方の当事者がレイアウト、封じ込め、キーイング、検索、交換、および課されるその他の制約などの問題を認識していると仮定されています。データモデルによって。
NETCONF carries configuration data inside the <config> element that is specific to device's data model. The protocol treats the contents of that element as opaque data. The device uses capabilities to announce the set of data models that the device implements. The capability definition details the operation and constraints imposed by data model.
NetConfは、デバイスのデータモデルに固有の<config>要素内に構成データを搭載しています。プロトコルは、その要素の内容を不透明なデータとして扱います。デバイスは機能を使用して、デバイスが実装する一連のデータモデルを発表します。機能定義には、データモデルによって課される操作と制約の詳細があります。
Devices and managers may support multiple data models, including both standard and proprietary data models.
デバイスとマネージャーは、標準データモデルと独自のデータモデルの両方を含む複数のデータモデルをサポートできます。
XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the <rpc-reply> for a <get> or <get-config> operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The agent does not need to utilize any data-model-specific semantics during processing, allowing for simple and centralized implementation strategies.
XMLサブツリーフィルタリングは、アプリケーションが特定のXMLサブツリーを選択できるようにするメカニズムです。インクルージョンのための小さなフィルターのセット、シンプルなコンテンツの正確な試合、選択が提供されます。エージェントは、処理中にデータモデル固有のセマンティクスを利用する必要はなく、シンプルで集中化された実装戦略を可能にします。
Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output.
概念的には、サブツリーフィルターは、フィルター選択基準を表すゼロ以上の要素サブツリーで構成されています。サブツリー内の各封じ込めレベルで、兄弟ノードのセットはサーバーによって論理的に処理され、ルートへの要素のサブツリーとパスがフィルター出力に含まれるかどうかを判断します。
All elements present in a particular subtree within a filter must match associated nodes present in the server's conceptual data model. XML namespaces may be specified (via 'xmlns' declarations) within the filter data model. If they are, the declared namespace must first exactly match a namespace supported by the server. Note that prefix values for qualified namespaces are not relevant when comparing filter elements to elements in the underlying data model. Only data associated with a specified namespace will be included in the filter output.
フィルター内の特定のサブツリーに存在するすべての要素は、サーバーの概念データモデルに存在する関連ノードと一致する必要があります。XML名前空間は、フィルターデータモデル内で（「XMLNS」宣言を介して）指定できます。もしそうなら、宣言された名前空間は、最初にサーバーでサポートされている名前空間と正確に一致する必要があります。適格な名前空間のプレフィックス値は、基礎となるデータモデルの要素とフィルター要素を比較する場合、関連しないことに注意してください。指定された名前空間に関連付けられたデータのみがフィルター出力に含まれます。
Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified configuration datastore on the server are selected by the filter. A node must exactly match the namespace and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below <filter>.
サブツリーフィルターで指定された各ノードは、包括的なフィルターを表します。サーバー上の指定された構成データストア内の基礎となるデータモデルの関連ノードのみがフィルターによって選択されます。ノードは、フィルターの絶対パス名が下のレイヤーから開始するように調整されていることを除いて、フィルターデータに与えられた要素の名前空間と階層と正確に一致する必要があります。
Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data.
応答メッセージには、フィルターによって選択されたサブツリーのみが含まれます。特定の選択されたサブツリー内で、リクエストに存在する選択基準も応答に含まれています。葉のノードとしてフィルターで表されるいくつかの要素は、フィルター出力に拡張されます（つまり、サブツリーが含まれています）。リクエストに同じデータを選択する複数のフィルターサブツリー式が含まれている場合、特定のデータインスタンスは応答で複製されません。
A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter:
サブツリーフィルターは、XML要素とそのXML属性で構成されています。サブツリーフィルターに存在する可能性のあるコンポーネントには5つのタイプがあります。
o Namespace Selection
o 名前空間選択
o Attribute Match Expressions
o 属性一致式
o Containment Nodes
o 封じ込めノード
o Selection Nodes
o 選択ノード
o Content Match Nodes
o コンテンツはノードを一致させます
If namespaces are used, then the filter output will only include elements from the specified namespace. A namespace is considered to match (for filter purposes) if the content of the 'xmlns' attributes are the same in the filter and the underlying data model. Note that namespace selection cannot be used by itself. At least one element must be specified in the filter any elements to be included in the filter output.
名前空間を使用する場合、フィルター出力には指定された名前空間の要素のみが含まれます。「xmlns」属性のコンテンツがフィルターと基礎となるデータモデルで同じである場合、名前空間は（フィルターのために）一致すると見なされます。名前空間の選択はそれ自体では使用できないことに注意してください。フィルター出力に含まれる要素をフィルターで指定する必要があります。
Example:
例：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>
In this example, the <top> element is a selection node, and only this node and any child nodes (from the underlying data model) in the 'http://example.com/schema/1.2/config' namespace will be included in the filter output.
この例では、<top>要素は選択ノードであり、「http://example.com/schema/1.2/config 'ネームスペースの「http://example.com/1.2/config」のこのノードと子ノードのみが含まれます。フィルター出力。
An attribute that appears in a subtree filter is part of an "attribute match expression". Any number of (unqualified or qualified) XML attributes may be present in any type of filter node. In addition to the selection criteria normally applicable to that node, the selected data must have matching values for every attribute specified in the node. If an element is not defined to include a specified attribute, then it is not selected in the filter output.
サブツリーフィルターに表示される属性は、「属性マッチ式」の一部です。任意の数の（資格のないまたは資格のない）XML属性は、どのタイプのフィルターノードにも存在する場合があります。通常、そのノードに適用される選択基準に加えて、選択したデータには、ノードで指定されたすべての属性の一致値が必要です。要素が指定された属性を含めるように定義されていない場合、フィルター出力で選択されません。
Example:
例：
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/config">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
In this example, the <top>, <interfaces>, and <interface> elements are containment nodes, and 'ifName' is an attribute match expression. Only 'interface' nodes in the 'http://example.com/schema/1.2/config' namespace that have an 'ifName' attribute with the value 'eth0' and occur within 'interfaces' nodes within 'top' nodes will be included in the filter output.
この例では、<top>、<interfaces>、および<interface>要素は封じ込めノードであり、「ifname」は属性マッチ式です。'http://example.com/schema/1.2/config' value 'eth0'を持つ 'ifname'属性を持つ名前空間の「http://example.com/schema/1.2/config」ノードのみが、「トップ」ノード内の「インターフェイス」ノード内で発生する名前空間になります。フィルター出力に含まれています。
Nodes that contain child elements within a subtree filter are called "containment nodes". Each child element can be any type of node, including another containment node. For each containment node specified in a subtree filter, all data model instances that exactly match the specified namespaces, element hierarchy, and any attribute match expressions are included in the filter output.
サブツリーフィルター内に子要素を含むノードは、「封じ込めノード」と呼ばれます。各子要素は、別の封じ込めノードを含むあらゆるタイプのノードにすることができます。サブツリーフィルターで指定された各封じ込めノードについて、指定された名前空間、要素階層、および属性一致式を正確に一致させるすべてのデータモデルインスタンスがフィルター出力に含まれます。
Example:
例：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
In this example, the <top> element is a containment node.
この例では、<top>要素は封じ込めノードです。
An empty leaf node within a filter is called a "selection node", and it represents an "explicit selection" filter on the underlying data model. Presence of any selection nodes within a set of sibling nodes will cause the filter to select the specified subtree(s) and suppress automatic selection of the entire set of sibling nodes in the underlying data model. For filtering purposes, an empty leaf node can be declared either with an empty tag (e.g., <foo/>) or with explicit start and end tags (e.g., <foo> </foo>). Any whitespace characters are ignored in this form.
フィルター内の空のリーフノードは「選択ノード」と呼ばれ、基礎となるデータモデルの「明示的な選択」フィルターを表します。兄弟ノードのセット内に選択ノードが存在すると、フィルターは指定されたサブツリーを選択し、基礎となるデータモデルの兄弟ノードのセット全体の自動選択を抑制します。フィルタリングのために、空の葉のノードは、空のタグ（<foo/>など）または明示的な開始および終了タグ（例：<foo> </foo>）で宣言できます。この形式では、白面の文字は無視されます。
Example:
例：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
In this example, the <top> element is a containment node, and the <users> element is a selection node. Only 'users' nodes in the 'http://example.com/schema/1.2/config' namespace that occur within a 'top' element that is the root of the configuration datastore will be included in the filter output.
この例では、<top>要素は封じ込めノードであり、<ユーザー>要素は選択ノードです。'http://example.com/schema/1.2/config'名前空間の「users」ノードのみが、データストアの構成のルートである「上」要素内で発生する名前空間がフィルター出力に含まれます。
A leaf node that contains simple content is called a "content match node". It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content. The following constraints apply to content match nodes:
シンプルなコンテンツを含むリーフノードは、「コンテンツマッチノード」と呼ばれます。フィルター出力のためにその兄弟ノードの一部またはすべてを選択するために使用され、葉のノード要素コンテンツの正確な一致フィルターを表します。次の制約は、ノードに一致するコンテンツに適用されます。
o A content match node must not contain nested elements (i.e., must resolve to a simpleType in the XML Schema Definition (XSD)).
o コンテンツマッチノードには、ネストされた要素が含まれてはなりません（つまり、XMLスキーマ定義（XSD）の単純なタイプに解決する必要があります）。
o Multiple content match nodes (i.e., sibling nodes) are logically combined in an "AND" expression.
o 複数のコンテンツマッチノード（つまり、兄弟ノード）は、論理的に "および"式で結合されます。
o Filtering of mixed content is not supported.
o 混合コンテンツのフィルタリングはサポートされていません。
o Filtering of list content is not supported.
o リストコンテンツのフィルタリングはサポートされていません。
o Filtering of whitespace-only content is not supported.
o 空白のみのコンテンツのフィルタリングはサポートされていません。
o A content match node must contain non-whitespace characters. An empty element (e.g., <foo></foo>) will be interpreted as a selection node (e.g., <foo/>).
o コンテンツマッチノードには、非白文字文字を含める必要があります。空の要素（例：<foo> </foo>）は、選択ノード（例：<foo/>）として解釈されます。
o Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified.
o 主要および後続のホワイトスペースの文字は無視されますが、テキスト文字のブロック内の空白文字は無視または変更されません。
If all specified sibling content match nodes in a subtree filter expression are 'true', then the filter output nodes are selected in the following manner:
サブツリーフィルター式のすべての指定された兄弟コンテンツ一致ノードが「true」である場合、フィルター出力ノードは次の方法で選択されます。
o Each content match node in the sibling set is included in the filter output.
o 兄弟セットの各コンテンツマッチノードは、フィルター出力に含まれています。
o If any containment nodes are present in the sibling set, then they are processed further and included if any nested filter criteria are also met.
o 封じ込めノードが兄弟セットに存在する場合、それらはさらに処理され、ネストされたフィルター基準も満たされている場合は含まれます。
o If any selection nodes are present in the sibling set, then all of them are included in the filter output.
o 兄弟セットに選択ノードが存在する場合、それらはすべてフィルター出力に含まれています。
o Otherwise (i.e., there are no selection or containment nodes in the filter sibling set), all the nodes defined at this level in the underlying data model (and their subtrees, if any) are returned in the filter output.
o それ以外の場合は（つまり、フィルター兄弟セットに選択または封じ込めノードがありません）、このレベルで基礎となるデータモデル（およびそのサブツリー（もしあれば））で定義されているすべてのノードは、フィルター出力で返されます。
If any of the sibling content match node tests are 'false', then no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match node(s).
兄弟コンテンツマッチノードテストのいずれかが「false」である場合、その兄弟セットではそれ以上のフィルター処理は実行されず、コンテンツマッチノードを含む兄弟サブツリーはフィルターによって選択されません。
Example:
例：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
In this example, the <users> and <user> nodes are both containment nodes, and <name> is a content match node. Since no sibling nodes of <name> are specified (and therefore no containment or selection nodes), all of the sibling nodes of <name> are returned in the filter output. Only 'user' nodes in the 'http://example.com/schema/1.2/config' namespace that match the element hierarchy and for which the <name> element is equal to 'fred' will be included in the filter output.
この例では、<ユーザー>および<ユーザー>ノードはどちらも封じ込めノードであり、<name>はコンテンツマッチノードです。<name>の兄弟ノードは指定されていないため（したがって、封じ込めまたは選択ノードはありません）、<name>の兄弟ノードはすべてフィルター出力で返されます。'http://example.com/schema/1.2/config'要素階層に一致し、<name>要素が「Fred」に等しい<name>要素がフィルター出力に含まれる「user」ノードのみ。
The filter output (the set of selected nodes) is initially empty.
フィルター出力（選択したノードのセット）は最初に空です。
Each subtree filter can contain one or more data model fragments, which represent portions of the data model that should be selected (with all child nodes) in the filter output.
各Subtreeフィルターには、1つ以上のデータモデルフラグメントを含めることができます。これは、フィルター出力で（すべての子ノードを使用して）選択する必要があるデータモデルの一部を表します。
Each subtree data fragment is compared by the server to the internal data models supported by the server. If the entire subtree data-fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data.
各サブツリーデータフラグメントは、サーバーによってサーバーでサポートされている内部データモデルと比較されます。サブツリーデータフラグメントフィルター全体（ルートからフィルターで指定された最も内側の要素まで）がサポートされているデータモデルの対応する部分と正確に一致する場合、そのノードとそのすべての子供が結果データに含まれます。
The server processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root elements in the filter are considered in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent.
サーバーは、ルートから葉のノードまで、同じ親ノード（兄弟セット）を使用してすべてのノードを処理します。フィルター内のルート要素は、同じ兄弟セットで考慮されます（同じ名前のスペースにあると仮定します）、共通の親はいません。
For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed.
各兄弟セットについて、サーバーは、フィルター出力にどのノードが含まれている（または潜在的に含まれている）か、フィルター出力からどの兄弟サブツリーが除外（プルーン化されている）かを決定します。サーバーは、最初に兄弟セットにどのタイプのノードが存在するかを決定し、そのタイプのルールに従ってノードを処理します。兄弟セットのノードが選択されている場合、選択した各ノードの兄弟セットにプロセスが再帰的に適用されます。アルゴリズムは、フィルターで指定されたすべてのサブツリーのすべての兄弟セットが処理されるまで継続します。
Leaving out the filter on the get operation returns the entire data model.
GET操作のフィルターを除外すると、データモデル全体が返されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<!-- ... entire set of data returned ... -->
</data>
</rpc-reply>
An empty filter will select nothing because no content match or selection nodes are present. This is not an error. The filter type attribute used in these examples is discussed further in Section 7.1.
空のフィルターは、コンテンツマッチや選択ノードが存在しないため、何も選択しません。これはエラーではありません。これらの例で使用されるフィルター型属性については、セクション7.1でさらに説明します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
</data>
</rpc-reply>
The filter in this example contains one selection node (<users>), so just that subtree is selected by the filter. This example represents the fully-populated <users> data model in most of the filter examples that follow. In a real data model, the <company-info> would not likely be returned with the list of users for a particular host or network.
この例のフィルターには、1つの選択ノード（<ユーザー>）が含まれているため、そのサブツリーがフィルターで選択されているだけです。この例は、以下のほとんどのフィルターの例で完全に入力された<ユーザー>データモデルを表しています。実際のデータモデルでは、<Company-INFO>は、特定のホストまたはネットワークのユーザーのリストとともに返されることはありません。
NOTE: The filtering and configuration examples used in this document appear in the namespace "http://example.com/schema/1.2/config". The root element of this namespace is <top>. The <top> element and its descendents represent an example configuration data model only.
注：このドキュメントで使用されているフィルタリングと構成の例は、名前空間「http://example.com/schema/1.2/config」に表示されます。この名前空間のルート要素は<top>です。<top>要素とその子孫は、構成データモデルの例のみを表します。
<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/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
<user>
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
<company-info>
<dept>2</dept>
<id>3</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
The following filter request would have produced the same result, but only because the container <users> defines one child element (<user>).
次のフィルター要求は同じ結果を生成しましたが、それはコンテナ<ユーザー>が1つの子要素（<user>）を定義するためです。
<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/schema/1.2/config">
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
This filter contains two containment nodes (<users>, <user>) and one selector node (<name>). All instances of the <name> element in the same sibling set are selected in the filter output. The manager may need to know that <name> is used as an instance identifier in this particular data structure, but the server does not need to know that meta-data in order to process the request.
このフィルターには、2つの封じ込めノード（<ユーザー>、<ユーザー>）と1つのセレクターノード（<name>）が含まれています。同じ兄弟セットの<name>要素のすべてのインスタンスは、フィルター出力で選択されています。マネージャーは、<name>がこの特定のデータ構造のインスタンス識別子として使用されていることを知る必要があるかもしれませんが、リクエストを処理するためにサーバーはそのメタデータを知る必要はありません。
<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/schema/1.2/config">
<users>
<user>
<name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
</user>
<user>
<name>fred</name>
</user>
<user>
<name>barney</name>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains two containment nodes (<users>, <user>) and one content match node (<name>). All instances of the sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output.
このフィルターには、2つの封じ込めノード（<ユーザー>、<ユーザー>）と1つのコンテンツマッチノード（<name>）が含まれています。<name>の値が「Fred」に等しい<name>を含む兄弟セットのすべてのインスタンスがフィルター出力で選択されています。
<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/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains two containment nodes (<users>, <user>), one content match node (<name>), and two selector nodes (<type>, <full-name>). All instances of the <type> and <full-name> elements in the same sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output. The <company-info> element is not included because the sibling set contains selection nodes.
このフィルターには、2つの封じ込めノード（<ユーザー>、<ユーザー>）、1つのコンテンツマッチノード（<name>）、および2つのセレクターノード（<type>、<full-name>）が含まれています。<name>の値が「Fred」に等しい<name>を含む同じ兄弟セットの<type>および<full-name>要素のすべてのインスタンスがフィルター出力で選択されています。兄弟セットには選択ノードが含まれているため、<Company-info>要素は含まれていません。
<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/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type/>
<full-name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains three subtrees (name=root, fred, barney).
このフィルターには、3つのサブツリー（name = root、Fred、Barney）が含まれています。
The "root" subtree filter contains two containment nodes (<users>, <user>), one content match node (<name>), and one selector node (<company-info>). The subtree selection criteria is met, and just the company-info subtree for "root" is selected in the filter output.
「root」サブツリーフィルターには、2つのcontanmentノード（<ユーザー>、<ユーザー>）、1つのコンテンツマッチノード（<name>）、および1つのセレクターノード（<Company-info>）が含まれています。サブツリーの選択基準が満たされ、「ルート」の会社INFOサブツリーのみがフィルター出力で選択されます。
The "fred" subtree filter contains three containment nodes (<users>, <user>, <company-info>), one content match node (<name>), and one selector node (<id>). The subtree selection criteria is met, and just the <id> element within the company-info subtree for "fred" is selected in the filter output.
「FRED」サブツリーフィルターには、3つの封じ込めノード（<ユーザー>、<ユーザー>、<Company-INFO>）、1つのコンテンツマッチノード（<name>）、および1つのセレクターノード（<id>）が含まれています。サブツリーの選択基準が満たされ、「FRED」の会社INFOサブツリー内の<id>要素のみがフィルター出力で選択されます。
The "barney" subtree filter contains three containment nodes (<users>, <user>, <company-info>), two content match nodes (<name>, <type>), and one selector node (<dept>). The subtree selection criteria is not met because user "barney" is not a "superuser", and the entire subtree for "barney" (including its parent <user> entry) is excluded from the filter output.
「Barney」サブツリーフィルターには、3つの封じ込めノード（<ユーザー>、<ユーザー>、<Company-info>）、2つのコンテンツマッチノード（<name>、<type>）、および1つのセレクターノード（<dept>）が含まれています。ユーザー「Barney」は「スーパーユーザー」ではないため、サブツリーの選択基準は満たされません。「Barney」のサブツリー全体（親<ユーザー>エントリを含む）がフィルター出力から除外されます。
<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/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<type>superuser</type>
<company-info>
<dept/>
</company-info>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
In this example, the filter contains one containment node (<interfaces>), one attribute match expression (ifName), and one selector node (<interface>). All instances of the <interface> subtree that have an ifName attribute equal to "eth0" are selected in the filter output. The filter data elements and attributes must be qualified because the ifName attribute will not be considered part of the 'schema/1.2' namespace if it is unqualified.
この例では、フィルターには、1つの封じ込めノード（<interfaces>）、1つの属性マッチ式（IFName）、および1つのセレクターノード（<interface>）が含まれています。「eth0」に等しいIFName属性を持つ<interface>サブツリーのすべてのインスタンスは、フィルター出力で選択されます。IFName属性は、資格がない場合は「スキーマ/1.2」名前空間の一部とは見なされないため、フィルターデータ要素と属性を適格にする必要があります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0">
<t:ifInOctets>45621</t:ifInOctets>
<t:ifOutOctets>774344</t:ifOutOctets>
</t:interface>
</t:interfaces>
</t:top>
</data>
</rpc-reply>
If ifName were a child node instead of an attribute, then the following request would produce similar results.
IFNameが属性の代わりに子ノードであった場合、次の要求は同様の結果をもたらします。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
The NETCONF protocol provides a small set of low-level operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration datastores. Additional operations are provided, based on the capabilities advertised by the device.
NetConfプロトコルは、デバイス構成を管理し、デバイスの状態情報を取得するための小さなレベル操作の小さなセットを提供します。ベースプロトコルは、構成データストアを取得、構成、コピー、削除する操作を提供します。デバイスによって宣伝されている機能に基づいて、追加の操作が提供されます。
The base protocol includes the following protocol operations:
基本プロトコルには、次のプロトコル操作が含まれます。
o get
o 得る
o get-config
o get-config
o edit-config
o 編集config
o copy-config
o copyconfig
o delete-config
o
o lock
o ロック
o unlock
o
o close-session
o セッション
o kill-session
o キルセッション
A protocol operation may fail for various reasons, including "operation not supported". An initiator should not assume that any operation will always succeed. The return values in any RPC reply should be checked for error responses.
プロトコル操作は、「操作がサポートされていない」など、さまざまな理由で失敗する場合があります。イニシエーターは、操作が常に成功すると想定してはなりません。RPC返信の返品値には、エラー応答がないか確認する必要があります。
The syntax and XML encoding of the protocol operations are formally defined in the XML schema in Appendix B. The following sections describe the semantics of each protocol operation.
プロトコル操作の構文とXMLエンコードは、付録BのXMLスキーマで正式に定義されています。次のセクションでは、各プロトコル操作のセマンティクスについて説明します。
Description:
説明：
Retrieve all or part of a specified configuration.
指定された構成のすべてまたは一部を取得します。
Parameters:
パラメーター：
source:
ソース：
Name of the configuration datastore being queried, such as <running/>.
<running/>など、Queridedの構成データストアの名前。
filter:
フィルター：
The filter element identifies the portions of the device configuration to retrieve. If this element is unspecified, the entire configuration is returned.
フィルター要素は、取得するデバイス構成の部分を識別します。この要素が不特定の場合、構成全体が返されます。
The filter element may optionally contain a "type" attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value "subtree" explicitly identifies this type of filtering.
フィルター要素には、オプションで「タイプ」属性が含まれる場合があります。この属性は、フィルター要素内で使用されるフィルタリング構文のタイプを示します。NetConfのデフォルトのフィルタリングメカニズムは、サブツリーフィルタリングと呼ばれ、セクション6で説明されています。値「サブツリー」は、このタイプのフィルタリングを明示的に識別します。
If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression.
NetConfピアがXPath機能（セクション8.9）をサポートする場合、値「XPath」を使用して、フィルター要素の選択属性にXPath式が含まれていることを示すことができます。
Positive Response:
肯定的な反応：
If the device can satisfy the request, the server sends an <rpc-reply> element containing a <data> element with the results of the query.
デバイスがリクエストを満たすことができる場合、サーバーはクエリの結果と<data>要素を含む<rpc-reply>要素を送信します。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example: To retrieve the entire <users> subtree:
例：<ユーザー>サブツリー全体を取得するには：
<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/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</data>
</rpc-reply>
If the configuration is available in multiple formats, such as XML and text, an XML namespace can be used to specify which format is desired. In the following example, the client uses a specific element (<config-text>) in a specific namespace to indicate to the server the desire to receive the configuration in an alternative format. The server may support any number of distinct formats or views into the configuration data, with the client using the <filter> parameter to select between them.
構成がXMLやテキストなどの複数の形式で使用できる場合、XMLネームスペースを使用して、どの形式が必要かを指定できます。次の例では、クライアントは特定の名前空間で特定の要素（<config-text>）を使用して、サーバーに代替形式で構成を受信したいという要望を示します。サーバーは、構成データへの任意の数の異なる形式またはビューをサポートする場合があり、クライアントは<filter>パラメーターを使用してそれらを選択することができます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<!-- request a text version of the configuration -->
<config-text xmlns="http://example.com/text/1.2/config"/>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<config-text xmlns="http://example.com/text/1.2/config">
<!-- configuration text... -->
</config-text>
</data>
</rpc-reply>
Section 6 contains additional examples of subtree filtering.
セクション6には、サブツリーフィルタリングの追加例が含まれています。
Description:
説明：
The <edit-config> operation loads all or part of a specified configuration to the specified target configuration. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration does not exist, it will be created. If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear instead of the <config> parameter and should identify a local configuration file.
The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the <copy-config> message. Instead, the target configuration is changed in accordance with the source's data and requested operations.
デバイスは、ソースとターゲットの構成を分析し、要求された変更を実行します。<copy-config>メッセージのように、ターゲット構成は必ずしも置き換えられません。代わりに、ターゲット構成は、ソースのデータと要求された操作に従って変更されます。
Attributes:
属性：
operation:
手術：
Elements in the <config> subtree may contain an "operation" attribute. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the <config> subtree.
If the operation attribute is not specified, the configuration is merged into the configuration datastore.
操作属性が指定されていない場合、構成は構成データストアにマージされます。
The operation attribute has one of the following values:
操作属性には、次の値のいずれかがあります。
merge: The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the target parameter. This is the default behavior.
マージ：この属性を含む要素によって識別される構成データは、ターゲットパラメーターによって識別される構成データストアの対応するレベルで構成とマージされます。これがデフォルトの動作です。
replace: The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the target parameter. Unlike a <copy-config> operation, which replaces the entire target configuration, only the configuration actually present in the config parameter is affected.
交換：この属性を含む要素によって識別される構成データは、ターゲットパラメーターによって識別された構成データストアの関連する構成を置き換えます。ターゲット構成全体を置き換える<copy-config>操作とは異なり、構成パラメーターに実際に存在する構成のみが影響を受けます。
create: The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist on the device. If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of data-exists.
作成：この属性を含む要素によって識別される構成データは、設定データがデバイスにまだ存在していない場合にのみ、構成に追加されます。構成データが存在する場合、<rpc-error>要素は、<error-tag> value of data-existsで返されます。
delete: The configuration data identified by the element containing this attribute is deleted in the configuration datastore identified by the target parameter.
削除：この属性を含む要素によって識別される構成データは、ターゲットパラメーターによって識別された構成データストアで削除されます。
Parameters:
パラメーター：
target:
目標：
Name of the configuration datastore being edited, such as <running/> or <candidate/>.
<runing/>や<condation/>など、編集中の構成データストアの名前。
default-operation:
デフォルト操作：
Selects the default operation (as described in the "operation" attribute) for this <edit-config> request. The default value for the default-operation parameter is "merge".
この<edit-config>リクエストに対して、デフォルト操作（「操作」属性で説明されているように）を選択します。デフォルト操作パラメーターのデフォルト値は「マージ」です。
The default-operation parameter is optional, but if provided, it must have one of the following values:
デフォルトオペレーションパラメーターはオプションですが、提供されている場合は、次の値のいずれかを持っている必要があります。
merge: The configuration data in the <config> parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior.
マージ：<config>パラメーターの構成データは、ターゲットデータストアの対応するレベルで構成とマージされます。これがデフォルトの動作です。
replace: The configuration data in the <config> parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data.
交換：<config>パラメーターの構成データは、ターゲットデータストアの構成を完全に置き換えます。これは、以前に保存された構成データをロードするのに役立ちます。
none: The target datastore is unaffected by the configuration in the <config> parameter, unless and until the incoming configuration data uses the "operation" attribute to request a different operation. If the configuration in the <config> parameter contains data for which there is not a corresponding level in the target datastore, an <rpc-error> is returned with an <error-tag> value of data-missing. Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted.
なし：ターゲットデータストアは、着信構成データが「操作」属性を使用して異なる操作を要求しない限り、<config>パラメーターの構成の影響を受けません。<config>パラメーターの構成に、ターゲットデータストアに対応するレベルがないデータが含まれている場合、<rpc-error>はデータミッシングの<error-tag>値で返されます。「none」を使用すると、「削除」などの操作により、削除される要素の親階層が意図せずに作成されないようになります。
test-option:
テストオプション：
The test-option element may be specified only if the device advertises the :validate capability (Section 8.6).
テストオプション要素は、デバイスが以下を宣伝する場合にのみ指定できます。
The test-option element has one of the following values:
test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the <edit-config> operation. This is the default test-option.
テスト - セット：設定を試みる前に検証テストを実行します。検証エラーが発生した場合、<edit-config>操作を実行しないでください。これはデフォルトのテストオプションです。
set: Perform a set without a validation test first.
セット：最初に検証テストなしでセットを実行します。
error-option:
エラーオプション：
The error-option element has one of the following values:
エラーオプション要素には、次の値のいずれかがあります。
stop-on-error: Abort the edit-config operation on first error. This is the default error-option.
Stop-on-Error：最初のエラーで編集config操作を中止します。これはデフォルトのエラーオプションです。
continue-on-error: Continue to process configuration data on error; error is recorded, and negative response is generated if any errors occur.
継続的なエラー：エラーに関する構成データを処理し続けます。エラーが記録され、エラーが発生した場合は負の応答が生成されます。
rollback-on-error: If an error condition occurs such that an error severity <rpc-error> element is generated, the server will stop processing the edit-config operation and restore the specified configuration to its complete state at the start of this edit-config operation. This option requires the server to support the :rollback-on-error capability described in Section 8.5.
ロールバックオンエラー：エラーの重大度<RPC-Error>要素が生成されるようにエラー条件が発生した場合、サーバーは編集操作の処理を停止し、この編集の開始時に指定された構成を完全な状態に復元します-CONFIG操作。このオプションでは、セクション8.5で説明されている次のようなロールバックオンエラー機能をサポートする必要があります。
config:
構成：
A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. Capabilities are discussed in Section 8.
デバイスのデータモデルの1つで定義されている構成データの階層。コンテンツは、適切なデータモデルを検出できるようにするために適切な名前空間に配置する必要があり、そのコンテンツは、その機能定義で定義されているように、そのデータモデルの制約に従う必要があります。機能については、セクション8で説明します。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。
Negative Response:
否定的な反応：
An <rpc-error> response is sent if the request cannot be completed for any reason.
何らかの理由でリクエストを完了できない場合、<RPC-Error>応答が送信されます。
Example:
例：
The <edit-config> examples in this section utilize a simple data model, in which multiple instances of the 'interface' element may be present, and an instance is distinguished by the 'name' element within each 'interface' element.
このセクションの<edit-config>の例は、「インターフェイス」要素の複数のインスタンスが存在する可能性があり、インスタンスが各「インターフェイス」要素内の「名前」要素によって区別される単純なデータモデルを使用します。
Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration:
実行中の構成の「Ethernet0/0」という名前のインターフェイスでMTUを1500に設定します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Add an interface named "Ethernet0/0" to the running configuration, replacing any previous interface with that name:
「Ethernet0/0」という名前のインターフェイスを実行中の構成に追加し、以前のインターフェイスをその名前に置き換えます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete the configuration for an interface named "Ethernet0/0" from the running configuration:
実行中の構成から「Ethernet0/0」という名前のインターフェイスの構成を削除します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete interface 192.0.2.4 from an OSPF area (other interfaces configured in the same area are unaffected):
インターフェイス192.0.2.4を削除します。OSPFエリアから（同じ領域で構成された他のインターフェイスは影響を受けません）：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<protocols>
<ospf>
<area>
<name>0.0.0.0</name>
<interfaces>
<interface xc:operation="delete">
<name>192.0.2.4</name>
</interface>
</interfaces>
</area>
</ospf>
</protocols>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description:
説明：
Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed.
構成データストア全体を別の完全な構成データストアの内容に作成または交換します。ターゲットデータストアが存在する場合、上書きされます。それ以外の場合は、許可されている場合は新しいものが作成されます。
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <source> or <target> parameter.
NetConfピアが以下をサポートする場合、URL機能（セクション8.8）、<URL>要素は<source>または<target>パラメーターとして表示できます。
Even if it advertises the :writable-running capability, a device may choose not to support the <running/> configuration datastore as the <target> parameter of a <copy-config> operation. A device may choose not to support remote-to-remote copy operations, where both the <source> and <target> parameters use the <url> element.
次の宣伝している場合でも、writableランニング機能を宣伝している場合でも、デバイスは<copy-config>操作の<target>パラメーターとして<runsin/> configuration dataStoreをサポートしないことを選択できます。デバイスは、<source>と<target>の両方のパラメーターが<url>要素を使用するリモートからリモートのコピー操作をサポートしないことを選択できます。
If the source and target parameters identify the same URL or configuration datastore, an error MUST be returned with an error-tag containing invalid-value.
ソースパラメーターとターゲットパラメーターが同じURLまたは構成データストアを識別する場合、無効な価値を含むエラータグでエラーを返す必要があります。
Parameters:
パラメーター：
target:
目標：
Name of the configuration datastore to use as the destination of the copy operation.
コピー操作の宛先として使用する構成データストアの名前。
source:
ソース：
Name of the configuration datastore to use as the source of the copy operation or the <config> element containing the configuration subtree to copy.
コピー操作のソースとして使用する構成データストアの名前またはコピーする構成サブツリーを含む<config>要素。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が送信されます<ok>要素が含まれます。
Negative Response:
否定的な反応：
An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.
<rpc-error>要素は、何らかの理由でリクエストを完了できない場合、<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user@example.com:passphrase/cfg/new.txt</url>
</source>
</copy-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description:
説明：
Delete a configuration datastore. The <running> configuration datastore cannot be deleted.
構成データストアを削除します。<runing>構成データストアを削除することはできません。
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <target> parameter.
NetConfピアが以下をサポートする場合、URL機能（セクション8.8）、<URL>要素は<target>パラメーターとして表示できます。
Parameters:
target:
目標：
Name of the configuration datastore to delete.
削除する構成データストアの名前。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が送信されます<ok>要素が含まれます。
Negative Response:
否定的な反応：
An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.
<rpc-error>要素は、何らかの理由でリクエストを完了できない場合、<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description:
説明：
The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users.
ロック操作により、クライアントはデバイスの構成システムをロックできます。このようなロックは、他のNetConfクライアント、非ネットコンクライアント（SNMPおよびコマンドラインインターフェイス（CLI）スクリプトなど）、および人間ユーザーとのやり取りを恐れずにクライアントが変更を加えることを目的としています。
An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target.
既存のセッションまたは他のエンティティがロックターゲットの任意の部分にロックを保持している場合、構成をロックしようとする試みが失敗する必要があります。
When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error.
ロックが取得されると、サーバーは、このセッションで要求されたリソース以外のロックされたリソースの変更を防ぐ必要があります。SNMPとCLIは、リソースを変更するようにリクエストして、適切なエラーで失敗する必要があります。
The duration of the lock is defined as beginning when the lock is acquired and lasting until either the lock is released or the NETCONF session closes. The session closure may be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, or simple inactivity timeout. This criteria is dependent on the implementation and the underlying transport.
ロックの持続時間は、ロックが取得され、ロックが解放されるか、NetConfセッションが閉じるまで続くときに開始時に定義されます。セッションの閉鎖は、クライアントによって明示的に実行される場合、または基礎となる輸送の障害や単純な非アクティブタイムアウトなどの基準に基づいてサーバーによって暗黙的に実行される場合があります。この基準は、実装と基礎となる輸送に依存します。
The lock operation takes a mandatory parameter, target. The target parameter names the configuration that will be locked. When a lock is active, using the <edit-config> operation on the locked configuration and using the locked configuration as a target of the <copy-config> operation will be disallowed by any other NETCONF session. Additionally, the system will ensure that these locked configuration resources will not be modified by other non-NETCONF management operations such as SNMP and CLI. The <kill-session> message (at the RPC layer) can be used to force the release of a lock owned by another NETCONF session. It is beyond the scope of this document to define how to break locks held by other entities.
ロック操作には、必須のパラメーター、ターゲットが必要です。ターゲットパラメーターは、ロックされる構成に名前を付けます。ロックがアクティブな場合、ロックされた構成で<edit-config>操作を使用し、<copy-config>操作のターゲットとしてロックされた構成を使用すると、他のNetConfセッションで許可されます。さらに、システムは、これらのロックされた構成リソースが、SNMPやCLIなどの他の非ネットコン管理操作によって変更されないようにします。<キルセッション>メッセージ（RPCレイヤー）を使用して、別のNetConfセッションが所有するロックのリリースを強制することができます。このドキュメントの範囲を超えて、他のエンティティが保持しているロックを壊す方法を定義します。
A lock MUST not be granted if either of the following conditions is true:
次の条件のいずれかが真である場合、ロックを許可してはなりません。
* A lock is already held by any NETCONF session or another entity.
* ロックは、NetConfセッションまたは別のエンティティによってすでに保持されています。
* The target configuration is <candidate>, it has already been modified, and these changes have not been committed or rolled back.
* ターゲット構成は<caddate>であり、すでに変更されており、これらの変更はコミットされておらず、ロールバックされていません。
The server MUST respond with either an <ok> element or an <rpc-error>.
サーバーは、<ok>要素または<rpc-error>で応答する必要があります。
A lock will be released by the system if the session holding the lock is terminated for any reason.
ロックを保持しているセッションが何らかの理由で終了した場合、システムによってロックがリリースされます。
Parameters:
パラメーター：
target:
目標：
Name of the configuration datastore to lock.
ロックする構成データストアの名前。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
If the lock is already held, the <error-tag> element will be 'lock-denied' and the <error-info> element will include the <session-id> of the lock owner. If the lock is held by a non-NETCONF entity, a <session-id> of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target.
Example:
例：
The following example shows a successful acquisition of a lock.
次の例は、ロックの獲得が成功したことを示しています。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <!-- lock succeeded -->
</rpc-reply>
Example:
例：
The following example shows a failed attempt to acquire a lock when the lock is already in use.
次の例は、ロックが既に使用されているときにロックを取得しようとする試みが失敗したことを示しています。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <!-- lock failed -->
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>
<!-- lock is held by NETCONF session 454 -->
</error-info>
</rpc-error>
</rpc-reply>
Description:
The unlock operation is used to release a configuration lock, previously obtained with the <lock> operation.
ロック解除操作は、<lock>操作で以前に取得された構成ロックのリリースに使用されます。
An unlock operation will not succeed if any of the following conditions are true:
次の条件のいずれかが真実であれば、ロック解除操作は成功しません。
* the specified lock is not currently active
* 指定されたロックは現在アクティブではありません
* the session issuing the <unlock> operation is not the same session that obtained the lock
* <Lock>操作を発行するセッションは、ロックを取得したのと同じセッションではありません
The server MUST respond with either an <ok> element or an <rpc-error>.
サーバーは、<ok>要素または<rpc-error>で応答する必要があります。
Parameters:
パラメーター：
target:
目標：
Name of the configuration datastore to unlock.
ロックを解除する構成データストアの名前。
A NETCONF client is not permitted to unlock a configuration datastore that it did not lock.
NetConfクライアントは、ロックしていない構成データストアのロックを解除することは許可されていません。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description:
説明：
Retrieve running configuration and device state information.
実行中の構成とデバイスの状態情報を取得します。
Parameters:
パラメーター：
filter:
This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned.
このパラメーターは、システム構成の部分と取得する状態データの部分を指定します。このパラメーターが空の場合、すべてのデバイス構成と状態情報が返されます。
The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value 'subtree' explicitly identifies this type of filtering.
フィルター要素には、オプションで「タイプ」属性が含まれている場合があります。この属性は、フィルター要素内で使用されるフィルタリング構文のタイプを示します。NetConfのデフォルトのフィルタリングメカニズムは、サブツリーフィルタリングと呼ばれ、セクション6で説明されています。値「サブツリー」は、このタイプのフィルタリングを明示的に識別します。
If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute of the filter element contains an XPath expression.
NetConfピアがXPath機能（セクション8.9）をサポートする場合、値「XPath」を使用して、フィルター要素の選択属性にXPath式が含まれていることを示すことができます。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent. The <data> section contains the appropriate subset.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が送信されます。<data>セクションには、適切なサブセットが含まれています。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
<ifInOctets>45621</ifInOctets>
<ifOutOctets>774344</ifOutOctets>
</interface>
</interfaces>
</top>
</data>
</rpc-reply>
Description:
説明：
Request graceful termination of a NETCONF session.
NetConfセッションの優雅な終了を要求します。
When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a <close-session> request will be ignored.
NetConfサーバーが<Close-Session>リクエストを受信すると、セッションを優雅に閉じます。サーバーは、セッションに関連付けられたロックとリソースをリリースし、関連する接続を優雅に閉じます。<Close-Session>リクエスト後に受信したNetConfリクエストは無視されます。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が送信されます<ok>要素が含まれます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description:
説明：
Force the termination of a NETCONF session.
NetConfセッションの終了を強制します。
When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections.
NetConfエンティティがオープンセッションの<キルセッション>リクエストを受信すると、現在プロセス中の操作を中止し、セッションに関連するロックとリソースを解放し、関連する接続を閉じます。
If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it must restore the configuration to its state before the confirmed commit was issued.
NetConfサーバーが確認されたコミットの処理中に<キルセッション>要求を受信した場合（セクション8.4）、確認されたコミットが発行される前に構成を状態に復元する必要があります。
Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock.
それ以外の場合、<kill-session>操作は、ロックを保持しているエンティティが作成した構成やその他のデバイス状態の変更をロールバックしません。
Parameters:
パラメーター：
session-id:
セッションID：
Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an 'invalid-value' error is returned.
終了するNetConfセッションのセッション識別子。この値が現在のセッションIDに等しい場合、「無効」エラーが返されます。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が送信されます<ok>要素が含まれます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
This section defines a set of capabilities that a client or a server MAY implement. Each peer advertises its capabilities by sending them during an initial capabilities exchange. Each peer needs to understand only those capabilities that it might use and MUST ignore any capability received from the other peer that it does not require or does not understand.
このセクションでは、クライアントまたはサーバーが実装できる一連の機能を定義します。各ピアは、最初の機能交換中にそれらを送信することにより、その機能を宣伝します。各ピアは、使用する可能性のある機能のみを理解する必要があり、他のピアから受け取った機能を必要としない、または理解していない機能を無視する必要があります。
Additional capabilities can be defined using the template in Appendix C. Future capability definitions may be published as standards by standards bodies or published as proprietary extensions.
付録Cのテンプレートを使用して、追加の機能を定義できます。将来の機能定義は、標準団体による標準として公開されるか、独自の拡張として公開されます。
A NETCONF capability is identified with a URI. The base capabilities are defined using URNs following the method described in RFC 3553 [6]. Capabilities defined in this document have the following format:
NetConf機能はURIで識別されます。ベース機能は、RFC 3553 [6]で説明されている方法に従ってURNを使用して定義されます。このドキュメントで定義されている機能には、次の形式があります。
urn:ietf:params:netconf:capability:{name}:1.0
where {name} is the name of the capability. Capabilities are often referenced in discussions and email using the shorthand :{name}. For example, the foo capability would have the formal name "urn:ietf:params:netconf:capability:foo:1.0" and be called ":foo". The shorthand form MUST NOT be used inside the protocol.
ここで、{name}は機能の名前です。速記を使用して、ディスカッションや電子メールで言及されることがよくあります。{name}。たとえば、FOO機能には、正式な名前「urn：ietf：params：netconf：capability：foo：1.0」と呼ばれる：foo "が含まれます。速記のフォームは、プロトコル内で使用しないでください。
Capabilities are advertised in messages sent by each peer during session establishment. When the NETCONF session is opened, each peer (both client and server) MUST send a <hello> element containing a list of that peer's capabilities. Each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.0".
機能は、セッションの確立中に各ピアが送信したメッセージに宣伝されます。NetConfセッションが開かれたとき、各ピア（クライアントとサーバーの両方）は、そのピアの機能のリストを含む<hello>要素を送信する必要があります。各ピアは、少なくともベースネットコン機能「urn：ietf：params：netconf：base：1.0」を送信する必要があります。
A server sending the <hello> element MUST include a <session-id> element containing the session ID for this NETCONF session. A client sending the <hello> element MUST NOT include a <session-id> element.
<hello>要素を送信するサーバーには、このNetConfセッションのセッションIDを含む<session-id>要素を含める必要があります。<hello>要素を送信するクライアントには、<session-id>要素を含めてはなりません。
A server receiving a <session-id> element MUST NOT continue the NETCONF session. Similarly, a client that does not receive a <session-id> element in the server's <hello> message MUST NOT continue the NETCONF session. In both cases, the underlying transport should be closed.
<session-id>要素を受信するサーバーは、NetConfセッションを続行してはなりません。同様に、サーバーの<hello>メッセージで<session-id>要素を受け取らないクライアントは、NetConfセッションを続行してはなりません。どちらの場合も、基礎となる輸送を閉じる必要があります。
In the following example, a server advertises the base NETCONF capability, one NETCONF capability defined in the base NETCONF document, and one implementation-specific capability.
次の例では、サーバーはベースネットコン機能、ベースNetConfドキュメントで定義されている1つのNetConf機能、および1つの実装固有の機能を宣伝します。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
http://example.net/router/2.3/myfeature
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
Each peer sends its <hello> element simultaneously as soon as the connection is open. A peer MUST NOT wait to receive the capability set from the other side before sending its own set.
各ピアは、接続が開かれたらすぐに<hello>要素を同時に送信します。ピアは、独自のセットを送信する前に、反対側からセットを受信するのを待ってはなりません。
The :writable-running capability indicates that the device supports direct writes to the <running> configuration datastore. In other words, the device supports edit-config and copy-config operations where the <running> configuration is the target.
：書き込み可能な実行機能は、デバイスが<runing>構成データストアに直接書き込みをサポートすることを示しています。つまり、デバイスは、<runing>構成がターゲットである編集とコピーコンフィグ操作をサポートします。
None.
なし。
The :writable-running capability is identified by the following capability string:
：Writable Running機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:writable-running:1.0
None.
なし。
The :writable-running capability modifies the <edit-config> operation to accept the <running> element as a <target>.
The：Writable Running機能は、<edit-config>操作を変更して、<target>として<runing>要素を受け入れます。
The :writable-running capability modifies the <copy-config> operation to accept the <running> element as a <target>.
The：Writable Running機能は、<copy-config>操作を変更して、<runing>要素を<ターゲット>として受け入れます。
The candidate configuration capability, :candidate, indicates that the device supports a candidate configuration datastore, which is used to hold configuration data that can be manipulated without impacting the device's current configuration. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes may be made to this data to construct the desired configuration data. A <commit> operation may be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration.
候補構成機能：候補は、デバイスがデバイスの現在の構成に影響を与えることなく操作できる構成データを保持するために使用される候補構成データストアをサポートすることを示します。候補構成は、構成データを作成および操作するための作業場所として機能する完全な構成データセットです。このデータに追加、削除、および変更を加えて、目的の構成データを構築できます。<commit>操作は、デバイスの実行構成を候補構成の値に設定するためにいつでも実行できます。
The <commit> operation effectively sets the running configuration to the current contents of the candidate configuration. While it could be modeled as a simple copy, it is done as a distinct operation for a number of reasons. In keeping high-level concepts as first class operations, we allow developers to see more clearly both what the client is requesting and what the server must perform. This keeps the intentions more obvious, the special cases less complex, and the interactions between operations more straightforward. For example, the :confirmed-commit capability (Section 8.4) would make no sense as a "copy confirmed" operation.
<commit>操作は、実行中の構成を候補構成の現在の内容に効果的に設定します。単純なコピーとしてモデル化できますが、いくつかの理由で明確な操作として行われます。高レベルの概念をファーストクラスの操作として維持する際に、開発者がクライアントが要求しているものとサーバーが実行する必要があるものの両方をより明確に確認できるようにします。これにより、意図がより明白になり、特別なケースが複雑ではなく、操作間の相互作用がより簡単になります。たとえば、次のように、確認されたコミット機能（セクション8.4）は、「コピーが確認された」操作として意味がありません。
The candidate configuration may be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it must assume that other sessions may be able to modify the candidate configuration at the same time. It is therefore prudent for a client to lock the candidate configuration before modifying it.
候補設定は、複数のセッション間で共有される場合があります。クライアントが候補設定が共有されていないという特定の情報を持っている場合を除き、他のセッションが候補設定を同時に変更できると仮定する必要があります。したがって、クライアントが候補構成を変更する前にロックすることは賢明です。
The client can discard any uncommitted changes to the candidate configuration by executing the <discard-changes> operation. This operation reverts the contents of the candidate configuration to the contents of the running configuration.
クライアントは、<discard-changes>操作を実行することにより、候補の構成にコミットされていない変更を廃棄できます。この操作は、候補構成の内容を実行中の構成の内容に戻します。
None.
なし。
The :candidate capability is identified by the following capability string:
：候補機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:candidate:1.0
Description:
説明：
When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration.
候補構成のコンテンツが完了すると、構成データをコミットし、データセットをデバイスの残りの部分に公開し、デバイスに新しい構成に記載されている動作に準拠するよう要求できます。
To commit the candidate configuration as the device's new current configuration, use the <commit> operation.
候補設定をデバイスの新しい現在の構成としてコミットするには、<comped>操作を使用します。
The <commit> operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration.
<commit>操作は、候補構成に含まれる構成データを実装するようにデバイスに指示します。デバイスが候補構成データストアのすべての変更をコミットできない場合、実行中の構成は変更されていないままでなければなりません。デバイスがコミットに成功した場合、候補構成のコンテンツで実行された構成を更新する必要があります。
If the system does not have the :candidate capability, the <commit> operation is not available.
システムに以下の能力がない場合、<commit>操作は使用できません。
Positive Response:
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
If the client decides that the candidate configuration should not be committed, the <discard-changes> operation can be used to revert the candidate configuration to the current running configuration.
クライアントが候補構成をコミットしないでくださいと判断した場合、<Docdard-Changes>操作を使用して、候補設定を現在の実行構成に戻すことができます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration.
この操作は、実行中の構成のコンテンツで候補構成をリセットすることにより、コミットされていない変更を破棄します。
The candidate configuration can be used as a source or target of any <get-config>, <edit-config>, <copy-config>, or <validate> operation as a <source> or <target> parameter. The <candidate> element is used to indicate the candidate configuration:
候補構成は、<get-config>、<edit-config>、<copy-config>、または<balidate>操作の任意のソースまたはターゲットとして使用できます。<Chindate>要素は、候補の構成を示すために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config> <!-- any NETCONF operation -->
<source>
<candidate/>
</source>
</get-config>
</rpc>
The candidate configuration can be locked using the <lock> operation with the <candidate> element as the <target> parameter:
候補の構成は、<Target>パラメーターとして<Chindate>要素を使用して<Lock>操作を使用してロックできます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
Similarly, the candidate configuration is unlocked using the <candidate> element as the <target> parameter:
同様に、候補の構成は、<Target>パラメーターとして<Chindate>要素を使用してロック解除されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the <unlock> operation or implicitly from session failure.
クライアントが候補の構成に顕著な変更で失敗した場合、回復は困難になる可能性があります。容易な回復を容易にするために、<アンロック>操作で明示的に、またはセッションの障害から暗黙的にであろうと、ロックがリリースされると、未解決の変更が破棄されます。
The :confirmed-commit capability indicates that the server will support the <confirmed> and <confirm-timeout> parameters for the <commit> protocol operation. See Section 8.3 for further details on the <commit> operation.
The：確認されたコミット機能は、サーバーが<cumpirmed>および<confirn-timeOut>パラメーターを<comped>プロトコル操作のパラメーターをサポートすることを示します。<commit>操作の詳細については、セクション8.3を参照してください。
A confirmed commit operation MUST be reverted if a follow-up commit (called the "confirming commit") is not issued within 600 seconds (10 minutes). The timeout period can be adjusted with the <confirm-timeout> element. The confirming commit can itself include a <confirmed> parameter.
フォローアップコミット（「確認コミット」と呼ばれる）が600秒（10分）以内に発行されない場合、確認されたコミット操作を戻す必要があります。タイムアウト期間は、<Confirm-TimeOut>要素で調整できます。確認するコミット自体には、<confirmed>パラメーターを含めることができます。
If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued.
確認済みのコミットを発行するセッションが、確認されたタイムアウトの有効期限が切れる前に何らかの理由で終了した場合、サーバーは、確認されたコミットが発行される前に構成をその状態に復元する必要があります。
If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued.
確認のタイムアウトが期限切れになる前に何らかの理由でデバイスが再起動した場合、確認されたコミットが発行される前に、サーバーはその状態に構成を復元する必要があります。
If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. Note that any commit operation, including a commit which introduces additional changes to the configuration, will serve as a confirming commit. Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the manager can explicitly restore the configuration to its state before the confirmed commit was issued.
確認のコミットが発行されない場合、デバイスは、確認されたコミットの発行の前に、その構成を状態に戻します。構成に追加の変更を導入するコミットを含むコミット操作は、確認するコミットとして機能することに注意してください。したがって、確認されたタイムアウトが期限切れになるのを待たずに確認されたコミットをキャンセルし、変更を戻すために、マネージャーは、確認されたコミットが発行される前に、構成をその状態に明示的に復元できます。
For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the edit-config operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration databases, configuration locking should also be used.
共有構成の場合、この機能は、構成ロック機能が使用されない限り、他の構成の変更（たとえば、他のNetConfセッションを介して）を不注意に変更または削除する可能性があります（つまり、編集Configの操作が前にロックが取得される場合があります。開始）。したがって、共有構成データベースでこの機能を使用するには、構成ロックも使用する必要があることが強く提案されています。
The :confirmed-commit capability is only relevant if the :candidate capability is also supported.
The :confirmed-commit capability is identified by the following capability string:
：確認されたコミット機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:confirmed-commit:1.0
None.
なし。
The :confirmed-commit capability allows 2 additional parameters to the <commit> operation.
The：確認されたコミット機能により、<commit>操作に2つの追加パラメーターが可能になります。
Parameters:
パラメーター：
confirmed:
確認済み：
Perform a confirmed commit operation.
確認されたコミット操作を実行します。
confirm-timeout:
CONSICH-TIMEOUT：
Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds.
確認されたコミットのタイムアウト期間、数秒で。不特定の場合、確認タイムアウトのデフォルトは600秒になります。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
This capability indicates that the server will support the 'rollback-on-error' value in the <error-option> parameter to the <edit-config> operation.
この機能は、サーバーが<edit-config>操作に<error-option>パラメーターの「ロールバックオンエラー」値をサポートすることを示しています。
For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the edit-config operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration databases, configuration locking also be used.
共有構成の場合、この機能は、構成ロック機能が使用されない限り、他の構成の変更（たとえば、他のNetConfセッションを介して）を不注意に変更または削除する可能性があります（つまり、編集Configの操作が前にロックが取得される場合があります。開始）。したがって、共有構成データベースでこの機能を使用するためには、構成ロックも使用することが強く提案されています。
None
なし
The :rollback-on-error capability is identified by the following capability string:
：ロールバックオンエラー機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:rollback-on-error:1.0
None.
なし。
The :rollback-on-error capability allows the 'rollback-on-error' value to the <error-option> parameter on the <edit-config> operation.
：ロールバックオンエラー機能により、<edit-config>操作の<error-option>パラメーターに「ロールバックオンエラー」値が可能になります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Validation consists of checking a candidate configuration for syntactical and semantic errors before applying the configuration to the device.
検証は、設定をデバイスに適用する前に、構文とセマンティックエラーの候補構成をチェックすることで構成されます。
If this capability is advertised, the device supports the <validate> protocol operation and checks at least for syntax errors. In addition, this capability supports the test-option parameter to the <edit-config> operation and, when it is provided, checks at least for syntax errors.
この機能が宣伝されている場合、デバイスは<balidate>プロトコル操作をサポートし、少なくとも構文エラーをチェックします。さらに、この機能は、<edit-config>操作のテストオプションパラメーターをサポートし、提供された場合、少なくとも構文エラーをチェックします。
None.
なし。
The :validate capability is identified by the following capability string:
THE：検証機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:validate:1.0
Description:
説明：
This protocol operation validates the contents of the specified configuration.
このプロトコル操作は、指定された構成の内容を検証します。
Parameters:
パラメーター：
source:
ソース：
Name of the configuration datastore being validated, such as <candidate> or the <config> element containing the configuration subtree to validate.
検証されている構成データストアの名前が検証されています。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスがリクエストを満たすことができた場合、<rpc-reply>が<ok>要素を含む送信されます。
Negative Response:
否定的な反応：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
要求が何らかの理由で完了できない場合、<rpc-error>要素は<rpc-reply>に含まれています。
A validate operation can fail for any of the following reasons:
検証操作は、次のいずれかの理由で失敗する可能性があります。
+ Syntax errors
+ 構文エラー
+ Missing parameters
+ 欠落パラメーター
+ References to undefined configuration data
+ 未定義の構成データへの参照
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The device supports separate running and startup configuration datastores. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit <copy-config> operation from the <running> to the <startup> must be invoked to update the startup configuration to the current contents of the running configuration. NETCONF protocol operations refer to the startup datastore using the <startup> element.
このデバイスは、個別の実行および起動構成データストアをサポートします。実行中の構成に影響を与える操作は、スタートアップ構成に自動的にコピーされません。<runing>から<Startup>への明示的な<Copy-Config>操作を呼び出して、スタートアップ構成を実行中の構成の現在の内容に更新する必要があります。NetConfプロトコル操作<Startup>要素を使用したスタートアップデータストアを参照してください。
None.
なし。
The :startup capability is identified by the following capability string:
：スタートアップ機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:startup:1.0
None.
The :startup capability adds the <startup/> configuration datastore to arguments of several NETCONF operations. The server MUST support the following additional values:
+--------------------+--------------------------+-------------------+
| Operation | Parameters | Notes |
+--------------------+--------------------------+-------------------+
| <get-config> | <source> | |
| | | |
| <copy-config> | <source> <target> | |
| | | |
| <lock> | <target> | |
| | | |
| <unlock> | <target> | |
| | | |
| <validate> | <source> | If :validate is |
| | | advertised |
+--------------------+--------------------------+-------------------+
To save the startup configuration, use the copy-config operation to copy the <running> configuration datastore to the <startup> configuration datastore.
スタートアップ構成を保存するには、copy-config操作を使用して、<running>構成データストアを<Startup> Configuration DataStoreにコピーします。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<source>
<running/>
</source>
<target>
<startup/>
</target>
</copy-config>
</rpc>
The NETCONF peer has the ability to accept the <url> element in <source> and <target> parameters. The capability is further identified by URL arguments indicating the URL schemes supported.
NetConfピアには、<source>および<target>パラメーターで<URL>要素を受け入れる機能があります。機能は、サポートされているURLスキームを示すURL引数によってさらに識別されます。
None.
なし。
The :url capability is identified by the following capability string:
：URL機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
The :url capability URI MUST contain a "scheme" argument assigned a comma-separated list of scheme names indicating which schemes the NETCONF peer supports. For example:
：URL機能URIには、NetConfピアがサポートするスキームを示すスキーム名のコンマ分離リストを割り当てられた「スキーム」引数を含める必要があります。例えば：
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
None.
なし。
The :url capability modifies the <edit-config> operation to accept the <url> element as an alternative to the <config> parameter. If the <url> element is specified, then it should identify a local configuration file.
：URL機能は、<edit-config>操作を変更して、<url>要素を<config>パラメーターの代替として受け入れます。<url>要素が指定されている場合、ローカル構成ファイルを識別する必要があります。
The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters.
：URL機能は、<source>パラメーターの値として<URL>要素を受け入れるように<copy-config>操作を変更します。
The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters. If this parameter contains a URL, then it should identify a local configuration file.
：URL機能は<delete-config>操作を変更して、<url>要素を<ターゲット>パラメーターの値として受け入れます。このパラメーターにURLが含まれている場合、ローカル構成ファイルを識別する必要があります。
The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.
The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the <filter> element. XPath is described in [2].
XPath機能は、NetConfピアが<filter>要素でXPath式の使用をサポートしていることを示しています。Xpathは[2]で説明されています。
The XPath expression must return a node-set.
XPath式はノードセットを返す必要があります。
The XPath expression is evaluated in a context where the context node is the root node, and the set of namespace declarations are those in scope on the filter element, including the default namespace.
XPath式は、コンテキストノードがルートノードであるコンテキストで評価され、名前空間宣言のセットは、デフォルトの名前空間を含むフィルター要素の範囲内のものです。
None.
なし。
The :xpath capability is identified by the following capability string:
：XPath機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:xpath:1.0
None.
なし。
The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", a select attribute MUST be present on the filter element. The select attribute will be treated as an XPath expression and used to filter the returned data. The filter element itself MUST be empty in this case.
XPath機能は、<get>および<get-config>操作を変更して、フィルター要素の型属性の値「xpath」を受け入れます。型属性が「xpath」に設定されている場合、フィルター要素に選択属性が存在する必要があります。Select属性はXPath式として扱われ、返されたデータのフィルタリングに使用されます。この場合、フィルター要素自体が空でなければなりません。
For example:
例えば：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<!-- get the user named fred -->
<filter type="xpath" select="top/users/user[name='fred']"/>
</get-config>
</rpc>
This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. Implementors SHOULD provide a comprehensive authorization scheme with NETCONF.
このドキュメントでは、そのようなスキームはメタデータモデルまたはデータモデルに関連付ける必要があるため、承認スキームを指定しません。実装者は、NetConfで包括的な認可スキームを提供する必要があります。
Authorization of individual users via the NETCONF server may or may not map 1:1 to other interfaces. First, the data models may be incompatible. Second, it may be desirable to authorize based on mechanisms available in the transport protocol layer (TELNET, SSH, etc).
NetConfサーバーを介した個々のユーザーの承認は、1：1を他のインターフェイスにマッピングする場合とさせない場合があります。まず、データモデルは互換性がない場合があります。第二に、輸送プロトコル層（Telnet、SSHなど）で利用可能なメカニズムに基づいて承認することが望ましい場合があります。
In addition, operations on configurations may have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, a partially complete access list could be committed from a candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device if the lock on the candidate configuration does not also apply to the <copy-config> operation when applied to it.
さらに、これらの操作が操作されているファイルまたはオブジェクトのグローバルロックによっても守られていない場合、構成に関する操作は意図しない結果をもたらす可能性があります。たとえば、候補構成のロックが<コピーにも適用されない場合、候補構成のロックの所有者に知られていない候補構成から部分的に完全なアクセスリストを候補構成からコミットすることができます。-config>操作に適用した場合。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol should be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces.
構成情報は、まさにその性質に敏感です。明確で整合性チェックなしでの送信は、古典的な盗聴攻撃に開かれています。構成情報には、多くの場合、パスワード、ユーザー名、サービスの説明、トポロジ情報が含まれていますが、これらはすべて敏感です。このため、このプロトコルは、他の管理インターフェイスで経験すると予想されるあらゆる種類の攻撃に十分な注意を払って慎重に実装する必要があります。
The protocol, therefore, must minimally support options for both confidentiality and authentication. It is anticipated that the underlying protocol (SSH, BEEP, etc) will provide for both confidentiality and authentication, as is required. It is further expected that the identity of each end of a NETCONF session will be available to the other in order to determine authorization for any given request. One could also easily envision additional information, such as transport and encryption methods, being made available for purposes of authorization. NETCONF itself provide no means to re-authenticate, much less authenticate. All such actions occur at lower layers.
したがって、プロトコルは、機密性と認証の両方のオプションを最小限にサポートする必要があります。基礎となるプロトコル（SSH、ビープなど）は、必要に応じて機密性と認証の両方を提供すると予想されます。さらに、NetConfセッションの各端の身元が、特定のリクエストの承認を決定するために他のセッションが利用できることが予想されます。また、輸送方法や暗号化方法などの追加情報を簡単に想像することも、許可を目的として利用できるようにすることもできます。NetConf自体は、再認証を再認証する手段を提供しません。そのようなアクションはすべて、下層で発生します。
Different environments may well allow different rights prior to and then after authentication. Thus, an authorization model is not specified in this document. When an operation is not properly authorized, a simple "access denied" is sufficient. Note that authorization information may be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection.
環境が異なる場合は、認証の前後に異なる権利を許可する場合があります。したがって、このドキュメントでは承認モデルは指定されていません。操作が適切に承認されていない場合、単純な「アクセス拒否」で十分です。承認情報は構成情報の形で交換される場合があります。これは、接続のセキュリティを確保するためのより多くの理由です。
That having been said, it is important to recognize that some operations are clearly more sensitive by nature than others. For instance, <copy-config> to the startup or running configurations is clearly not a normal provisioning operation, whereas <edit-config> is. Such global operations MUST disallow the changing of information that an individual does not have authorization to perform. For example, if a user A is not allowed to configure an IP address on an interface but user B has configured an IP address on an interface in the <candidate> configuration, user A must not be allowed to commit the <candidate> configuration.
そうは言っても、一部の操作は他の操作よりも明らかに本質的に敏感であることを認識することが重要です。たとえば、スタートアップまたは実行の構成への<Copy-Config>は、明らかに通常のプロビジョニング操作ではありませんが、<edit-config>はそうです。このようなグローバルな運用は、個人が実行する許可を持っていない情報の変更を禁止する必要があります。たとえば、ユーザーAがインターフェイスでIPアドレスを構成することを許可されていないが、ユーザーBが<Chindate>構成のインターフェイス上のIPアドレスを構成している場合、ユーザーAは<Chindaties>構成をコミットすることは許可されていません。
Similarly, just because someone says "go write a configuration through the URL capability at a particular place", this does not mean that an element should do it without proper authorization.
同様に、誰かが「特定の場所でURL機能を介して構成を書く」と言ったからといって、これは、適切な承認なしに要素がそれを行うべきであるという意味ではありません。
The <lock> operation will demonstrate that NETCONF is intended for use by systems that have at least some trust of the administrator. As specified in this document, it is possible to lock portions of a configuration that a principal might not otherwise have access to. After all, the entire configuration is locked. To mitigate this problem, there are two approaches. It is possible to kill another NETCONF session programmatically from within NETCONF if one knows the session identifier of the offending session. The other possible way to break a lock is to provide an function within the device's native user interface. These two mechanisms suffer from a race condition that may be ameliorated by removing the offending user from an AAA server. However, such a solution is not useful in all deployment scenarios, such as those where SSH public/private key pairs are used.
<lock>操作は、NetConfが少なくとも管理者の信頼を持っているシステムが使用することを目的としていることを実証します。このドキュメントで指定されているように、プリンシパルが他の方法ではアクセスできない可能性のある構成の部分をロックすることができます。結局のところ、構成全体がロックされています。この問題を軽減するには、2つのアプローチがあります。違反セッションのセッション識別子を知っている場合、NetConf内から別のNetConfセッションをプログラムで殺すことができます。ロックを破る他の可能な方法は、デバイスのネイティブユーザーインターフェイス内で機能を提供することです。これらの2つのメカニズムは、AAAサーバーから問題のあるユーザーを削除することで改善される可能性のある人種状態に悩まされています。ただし、このようなソリューションは、SSHパブリック/プライベートキーペアが使用されているものなど、すべての展開シナリオでは役に立ちません。
This document registers a URI for the NETCONF XML namespace in the IETF XML registry [7].
このドキュメントは、IETF XMLレジストリ[7]のNetConf XMLネームスペースのURIを登録します。
Following the format in RFC 3688, IANA has made the following registration.
RFC 3688の形式に続いて、IANAは次の登録を行いました。
URI: urn:ietf:params:xml:ns:netconf:base:1.0
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N/A、要求されたURIはXMLネームスペースです。
This document registers a URI for the NETCONF XML schema in the IETF XML registry [7].
このドキュメントは、IETF XMLレジストリ[7]のNetConf XMLスキーマのURIを登録します。
Following the format in RFC 3688, IANA has made the following registration.
RFC 3688の形式に続いて、IANAは次の登録を行いました。
URI: urn:ietf:params:xml:schema:netconf
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: Appendix B of this document.
XML：このドキュメントの付録B。
This document creates a registry that allocates NETCONF capability identifiers. Additions to the registry require IETF Standards Action.
このドキュメントは、NetConf機能識別子を割り当てるレジストリを作成します。レジストリへの追加には、IETF標準アクションが必要です。
The initial content of the registry contains the capability URNs defined in Section 8.
レジストリの初期コンテンツには、セクション8で定義されている機能が含まれています。
Following the guidelines in RFC 3553 [6], IANA assigned a NETCONF sub-namespace as follows:
RFC 3553 [6]のガイドラインに従って、IANAは次のようにNetConfサブネームスペースを割り当てました。
Registry name: netconf
レジストリ名：NetConf
Specification: Section 8 of this document.
仕様：このドキュメントのセクション8。
Repository: The following table.
リポジトリ：次の表。
+--------------------+----------------------------------------------+
| Index | Capability Identifier |
+--------------------+----------------------------------------------+
| :writable-running | urn:ietf:params:netconf:capability:writable- |
| | running:1.0 |
| | |
| :candidate | urn:ietf:params:netconf:capability:candidate |
| | :1.0 |
| | |
| :confirmed-commit | urn:ietf:params:netconf:capability:confirmed |
| | -commit:1.0 |
| | |
| :rollback-on-error | urn:ietf:params:netconf:capability:rollback- |
| | on-error:1.0 |
| | |
| :validate | urn:ietf:params:netconf:capability:validate: |
| | 1.0 |
| | |
| :startup | urn:ietf:params:netconf:capability:startup:1 |
| | .0 |
| | |
| :url | urn:ietf:params:netconf:capability:url:1.0 |
| | |
| :xpath | urn:ietf:params:netconf:capability:xpath:1.0 |
+--------------------+----------------------------------------------+
Index value: The capability name.
インデックス値：機能名。
This document was written by:
このドキュメントは次のように書かれています。
Andy Bierman
アンディ・ビアマン
Ken Crozier, Cisco Systems
ケンクロジエ、シスコシステム
Rob Enns, Juniper Networks
Juniper Networks、Rob Enns
Ted Goddard, IceSoft
テッド・ゴダード、アイセフト
Eliot Lear, Cisco Systems
エリオット・リア、シスコ・システム
Phil Shafer, Juniper Networks
フィルシェーファー、ジュニパーネットワーク
Steve Waldbusser
スティーブ・ウォルドバッサー
Margaret Wasserman, ThingMagic
マーガレット・ワッサーマン、物事
The authors would like to acknowledge the members of the NETCONF working group. In particular, we would like to thank Wes Hardaker for his persistance and patience in assisting us with security considerations. We would also like to thank Randy Presuhn, Sharon Chisholm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, and Dave Harrington for all of their valuable advice.
著者は、NetConfワーキンググループのメンバーを認めたいと考えています。特に、セキュリティの考慮事項で私たちを支援する彼の粘り強さと忍耐について、ウェス・ハーデイカーに感謝したいと思います。また、Randy Presuhn、Sharon Chisholm、Juergen Schoenwalder、Glenn Waters、David Perkins、Weijing Chen、Simon Leinen、Keith Allen、Dave Harringtonのすべての貴重なアドバイスに感謝します。
[1] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium, http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[1] Sperberg-Mcqueen、C.、Paoli、J.、Maler、E。、およびT. Bray、「拡張可能なマークアップ言語（XML）1.0（第2版）」、World Wide Webコンソーシアム、http：//www.w3.org/TR/2000/REC-XML-20001006、2000年10月。
[2] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation, http://www.w3.org/TR/1999/REC-xpath-19991116, November 1999.
[2] Clark、J。and S. Derose、「XML Path Language（XPath）バージョン1.0」、World Wide Web Consortiumの推奨、http：//www.w3.org/tr/1999/rec-xpath-19991116、1999年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[4] Wasserman、M。およびT. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[6] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[6] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「登録プロトコルパラメーターのIETF URNサブネームスペース」、BCP 73、RFC 3553、2003年6月。
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[7] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[8] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation, http://www.w3.org/TR/1999/REC-xslt-19991116, November 1999.
[8] クラーク、J。、「XSL変換（XSLT）バージョン1.0」、World Wide Webコンソーシアムの推奨、http：//www.w3.org/tr/1999/rec-xslt-19991116、1999年11月。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[10] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[10] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[11] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[12] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[12] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
Tag: in-use Error-type: protocol, application Severity: error Error-info: none Description: The request requires a resource that already in use.
タグ：使用中のエラータイプ：プロトコル、アプリケーションの重大度：エラーエラーINFO：なし説明：リクエストには既に使用されているリソースが必要です。
Tag: invalid-value Error-type: protocol, application Severity: error Error-info: none Description: The request specifies an unacceptable value for one or more parameters.
Tag: too-big Error-type: transport, rpc, protocol, application Severity: error Error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle.
タグ：あまりにもビッグエラータイプ：トランスポート、RPC、プロトコル、アプリケーションの重大度：エラーエラーINFO：なし説明：リクエストまたは応答（生成される）は、実装が処理するには大きすぎます。
Tag: missing-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the missing attribute <bad-element> : name of the element that should contain the missing attribute Description: An expected attribute is missing.
タグ：アトリブの欠落エラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーエラー-INFO：<bad-aTtribute>：欠落属性の名前<バッドエレメント>：欠落属性を含む要素の名前説明：予想される属性がありません。
Tag: bad-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the attribute w/ bad value <bad-element> : name of the element that contains the attribute with the bad value Description: An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch.
Tag: unknown-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the unexpected attribute <bad-element> : name of the element that contains the unexpected attribute Description: An unexpected attribute is present.
タグ：不明 - アトリブエラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーERROR-INFO：<bad-aTtribute>：予期しない属性の名前<Bad-Element>：予期しない属性を含む要素の名前：予期しない属性が存在します。
Tag: missing-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the missing element Description: An expected element is missing.
タグ：不足エレメントエラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーERROR-INFO：<Bad-Element>：欠落要素の名前説明：予想される要素がありません。
Tag: bad-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch.
タグ：バッドエレメントエラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーエラー-INFO：<バッドエレメント>：値のある要素の名前説明：要素値は正しくありません。たとえば、間違ったタイプ、範囲外、パターンの不一致。
Tag: unknown-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the unexpected element Description: An unexpected element is present.
タグ：未知のエレメントエラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーERROR-INFO：<Bad-Element>：予期しない要素の名前説明：予期しない要素が存在します。
Tag: unknown-namespace Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the element that contains the unexpected namespace <bad-namespace> : name of the unexpected namespace Description: An unexpected namespace is present.
タグ：不明な名目エラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーエラー-INFO：<バッドエレメント>：予期しない名前空間を含む要素の名前<bad-namespace>：予期しない名前空間の名前説明：予期しない名前空間が存在します。
Tag: access-denied Error-type: rpc, protocol, application Severity: error Error-info: none Description: Access to the requested RPC, protocol operation, or data model is denied because authorization failed.
タグ：Access-Denied Error-Type：RPC、プロトコル、アプリケーションの重大度：エラーエラーINFO：なし説明：要求されたRPC、プロトコル操作、またはデータモデルへのアクセスは、承認が失敗したため拒否されます。
Tag: lock-denied Error-type: protocol Severity: error Error-info: <session-id> : session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock Description: Access to the requested lock is denied because the lock is currently held by another entity.
タグ：ロック除去エラータイプ：プロトコルの重大度：エラーエラーINFO：<Session-ID>：セッションIDのセッションIDは、要求されたロックを保持します。ロックは現在別のエンティティによって保持されているため、ロックは拒否されます。
Tag: resource-denied Error-type: transport, rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because of insufficient resources.
タグ：リソース除去エラータイプ：トランスポート、RPC、プロトコル、アプリケーションの重大度：エラーエラーINFO：なし説明：リソースが不十分なため、リクエストは完了できませんでした。
Tag: rollback-failed Error-type: protocol, application Severity: error Error-info: none Description: Request to rollback some configuration change (via rollback-on-error or discard-changes operations) was not completed for some reason.
タグ：ロールバック化されたエラータイプ：プロトコル、アプリケーションの重大度：エラーエラー-INFO：なし説明：ロールバックのリクエストいくつかの構成変更（ロールバックオンエラーまたはdiscard-changes操作を介して）は何らかの理由で完了しませんでした。
Tag: data-exists Error-type: application Severity: error Error-info: none Description: Request could not be completed because the relevant data model content already exists. For example, a 'create' operation was attempted on data that already exists.
Tag: data-missing Error-type: application Severity: error Error-info: none Description: Request could not be completed because the relevant data model content does not exist. For example, a 'replace' or 'delete' operation was attempted on data that does not exist.
タグ：データミッシングエラータイプ：アプリケーションの重大度：エラーエラーINFO：なし説明：関連するデータモデルコンテンツが存在しないため、要求は完了できませんでした。たとえば、存在しないデータに対して「交換」または「削除」操作が試みられました。
Tag: operation-not-supported Error-type: rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation.
タグ：Operation-Not-Supported Error-Type：RPC、プロトコル、アプリケーションの重大度：エラーERROR-INFO：なし説明：要求された操作がこの実装によってサポートされていないため、要求が完了できませんでした。
Tag: operation-failed Error-type: rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because the requested operation failed for some reason not covered by any other error condition.
タグ：操作型エラータイプ：RPC、プロトコル、アプリケーションの重大度：エラーエラーINFO：なし説明：要求された操作が他のエラー条件でカバーされていないためにリクエストされた操作が失敗したために要求が完了できませんでした。
Tag: partial-operation Error-type: application Severity: error Error-info: <ok-element> : identifies an element in the data model for which the requested operation has been completed for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.
タグ：部分操作エラータイプ：アプリケーションの重大度：エラーエラーINFO：<OK-ELEMENT>：そのノードとそのすべての子ノードに対して要求された操作が完了したデータモデルの要素を識別します。この要素は、<Error-Info>コンテナでゼロ以上に表示される場合があります。
<err-element> : identifies an element in the data model for which the requested operation has failed for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.
<err-element>：要求された操作がそのノードとそのすべての子ノードで失敗したデータモデルの要素を識別します。この要素は、<Error-Info>コンテナでゼロ以上に表示される場合があります。
<noop-element> : identifies an element in the data model for which the requested operation was not attempted for that node and all its child nodes. This element can appear zero or more times in the <error-info> container. Description: Some part of the requested operation failed or was not attempted for some reason. Full cleanup has not been performed (e.g., rollback not supported) by the server. The error-info container is used to identify which portions of the application data model content for which the requested operation has succeeded (<ok-element>), failed (<bad-element>), or not been attempted (<noop-element>).
<NOOP-ELEMENT>：要求された操作がそのノードとそのすべての子ノードに対して試みられなかったデータモデルの要素を識別します。この要素は、<Error-Info>コンテナでゼロ以上に表示される場合があります。説明：要求された操作の一部が失敗したか、何らかの理由で試みられなかった。完全なクリーンアップは、サーバーによって実行されていません（ロールバックはサポートされていません）。エラー-INFOコンテナは、要求された操作が成功した（<OK-ELEMENT>）、失敗（<bad-element>）、または試行（<noop-element）のアプリケーションデータモデルコンテンツのどの部分を識別するために使用されます>）。
BEGIN
始める
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<!--
import standard XML definitions
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xs:annotation>
<xs:documentation>
This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element.
</xs:documentation>
</xs:annotation>
</xs:import>
<!--
message-id attribute
-->
<xs:simpleType name="messageIdType">
<xs:restriction base="xs:string">
<xs:maxLength value="4095"/>
</xs:restriction>
</xs:simpleType>
<!--
Types used for session-id
-->
<xs:simpleType name="SessionId">
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SessionIdOrZero">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<!--
<rpc> element
-->
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType"
use="required"/>
<!--
Arbitrary attributes can be supplied with <rpc> element.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
<!--
data types and elements used to construct rpc-errors
-->
<xs:simpleType name="ErrorType">
<xs:restriction base="xs:string">
<xs:enumeration value="transport"/>
<xs:enumeration value="rpc"/>
<xs:enumeration value="protocol"/>
<xs:enumeration value="application"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorTag">
<xs:restriction base="xs:string">
<xs:enumeration value="in-use"/>
<xs:enumeration value="invalid-value"/>
<xs:enumeration value="too-big"/>
<xs:enumeration value="missing-attribute"/>
<xs:enumeration value="bad-attribute"/>
<xs:enumeration value="unknown-attribute"/>
<xs:enumeration value="missing-element"/>
<xs:enumeration value="bad-element"/>
<xs:enumeration value="unknown-element"/>
<xs:enumeration value="unknown-namespace"/>
<xs:enumeration value="access-denied"/>
<xs:enumeration value="lock-denied"/>
<xs:enumeration value="resource-denied"/>
<xs:enumeration value="rollback-failed"/>
<xs:enumeration value="data-exists"/>
<xs:enumeration value="data-missing"/>
<xs:enumeration value="operation-not-supported"/>
<xs:enumeration value="operation-failed"/>
<xs:enumeration value="partial-operation"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorSeverity">
<xs:restriction base="xs:string">
<xs:enumeration value="error"/>
<xs:enumeration value="warning"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="errorInfoType">
<xs:sequence>
<xs:choice>
<xs:element name="session-id" type="SessionIdOrZero"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:sequence>
<xs:element name="bad-attribute" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="ok-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="err-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="noop-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-namespace" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
<!-- elements from any other namespace are also allowed
to follow the NETCONF elements -->
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rpcErrorType">
<xs:sequence>
<xs:element name="error-type" type="ErrorType"/>
<xs:element name="error-tag" type="ErrorTag"/>
<xs:element name="error-severity" type="ErrorSeverity"/>
<xs:element name="error-app-tag" type="xs:string"
minOccurs="0"/>
<xs:element name="error-path" type="xs:string" minOccurs="0"/>
<xs:element name="error-message" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="error-info" type="errorInfoType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--
<rpc-reply> element
-->
<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:group ref="rpcResponse"/>
</xs:choice>
<xs:attribute name="message-id" type="messageIdType"
use="optional"/>
<!--
Any attributes supplied with <rpc> element must be returned
on <rpc-reply>.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:group name="rpcResponse">
<xs:sequence>
<xs:element name="rpc-error" type="rpcErrorType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="data" type="dataInlineType" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="rpc-reply" type="rpcReplyType"/>
<!--
Type for <test-option> parameter to <edit-config>
-->
<xs:simpleType name="testOptionType">
<xs:restriction base="xs:string">
<xs:enumeration value="test-then-set"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
<!--
Type for <error-option> parameter to <edit-config>
-->
<xs:simpleType name="errorOptionType">
<xs:restriction base="xs:string">
<xs:annotation>
<xs:documentation>
Use of the rollback-on-error value requires
the :rollback-on-error capability.
</xs:documentation>
</xs:annotation>
<xs:enumeration value="stop-on-error"/>
<xs:enumeration value="continue-on-error"/>
<xs:enumeration value="rollback-on-error"/>
</xs:restriction>
</xs:simpleType>
<!--
rpcOperationType: used as a base type for all
NETCONF operations
-->
<xs:complexType name="rpcOperationType"/>
<xs:element name="rpcOperation"
type="rpcOperationType" abstract="true"/>
<!--
Type for <config> element
-->
<xs:complexType name="configInlineType">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<!--
Type for <data> element
-->
<xs:complexType name="dataInlineType">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<!--
Type for <filter> element
-->
<xs:simpleType name="FilterType">
<xs:restriction base="xs:string">
<xs:annotation>
<xs:documentation>
Use of the xpath value requires the :xpath capability.
</xs:documentation>
</xs:annotation>
<xs:enumeration value="subtree"/>
<xs:enumeration value="xpath"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="filterInlineType">
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="type"
type="FilterType" default="subtree"/>
<!-- if type="xpath", the xpath expression
appears in the select element -->
<xs:attribute name="select"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--
configuration datastore names
-->
<xs:annotation>
<xs:documentation>
The startup datastore can be used only if the :startup
capability is advertised. The candidate datastore can
be used only if the :candidate datastore is advertised.
</xs:documentation>
</xs:annotation>
<xs:complexType name="configNameType"/>
<xs:element name="config-name"
type="configNameType" abstract="true"/>
<xs:element name="startup" type="configNameType"
substitutionGroup="config-name"/>
<xs:element name="candidate" type="configNameType"
substitutionGroup="config-name"/>
<xs:element name="running" type="configNameType"
substitutionGroup="config-name"/>
<!--
operation attribute used in <edit-config>
-->
<xs:simpleType name="editOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="merge"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="create"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="operation"
type="editOperationType" default="merge"/>
<!--
<default-operation> element
-->
<xs:simpleType name="defaultOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="merge"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
<!--
<url> element
-->
<xs:complexType name="configURIType">
<xs:annotation>
<xs:documentation>
Use of the url element requires the :url capability.
</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:anyURI"/>
</xs:simpleContent>
</xs:complexType>
<!--
Type for <source> element (except <get-config>)
-->
<xs:complexType name="rpcOperationSourceType">
<xs:choice>
<xs:element name="config" type="configInlineType"/>
<xs:element ref="config-name"/>
<xs:element name="url" type="configURIType"/>
</xs:choice>
</xs:complexType>
<!--
Type for <source> element in <get-config>
-->
<xs:complexType name="getConfigSourceType">
<xs:choice>
<xs:element ref="config-name"/>
<xs:element name="url" type="configURIType"/>
</xs:choice>
</xs:complexType>
<!--
Type for <target> element
-->
<xs:complexType name="rpcOperationTargetType">
<xs:choice>
<xs:element ref="config-name"/>
<xs:element name="url" type="configURIType"/>
</xs:choice>
</xs:complexType>
<!--
<get-config> operation
-->
<xs:complexType name="getConfigType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="source"
type="getConfigSourceType"/>
<xs:element name="filter"
type="filterInlineType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="get-config" type="getConfigType"
substitutionGroup="rpcOperation"/>
<!--
<edit-config> operation
-->
<xs:complexType name="editConfigType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:annotation>
<xs:documentation>
Use of the test-option element requires the
:validate capability. Use of the url element
requires the :url capability.
</xs:documentation>
</xs:annotation>
<xs:element name="target"
type="rpcOperationTargetType"/>
<xs:element name="default-operation"
type="defaultOperationType"
minOccurs="0"/>
<xs:element name="test-option"
type="testOptionType"
minOccurs="0"/>
<xs:element name="error-option"
type="errorOptionType"
minOccurs="0"/>
<xs:choice>
<xs:element name="config"
type="configInlineType"/>
<xs:element name="url"
type="configURIType"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="edit-config" type="editConfigType"
substitutionGroup="rpcOperation"/>
<!--
<copy-config> operation
-->
<xs:complexType name="copyConfigType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="target" type="rpcOperationTargetType"/>
<xs:element name="source" type="rpcOperationSourceType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="copy-config" type="copyConfigType"
substitutionGroup="rpcOperation"/>
<!--
<delete-config> operation
-->
<xs:complexType name="deleteConfigType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="target" type="rpcOperationTargetType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="delete-config" type="deleteConfigType"
substitutionGroup="rpcOperation"/>
<!--
<get> operation
-->
<xs:complexType name="getType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="filter"
type="filterInlineType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="get" type="getType"
substitutionGroup="rpcOperation"/>
<!--
<lock> operation
-->
<xs:complexType name="lockType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="target"
type="rpcOperationTargetType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="lock" type="lockType"
substitutionGroup="rpcOperation"/>
<!--
<unlock> operation
-->
<xs:complexType name="unlockType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="target" type="rpcOperationTargetType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="unlock" type="unlockType"
substitutionGroup="rpcOperation"/>
<!--
<validate> operation
-->
<xs:complexType name="validateType">
<xs:annotation>
<xs:documentation>
The validate operation requires the :validate capability.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="source" type="rpcOperationSourceType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="validate" type="validateType"
substitutionGroup="rpcOperation"/>
<!--
<commit> operation
-->
<xs:simpleType name="confirmTimeoutType">
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="commitType">
<xs:annotation>
<xs:documentation>
The commit operation requires the :candidate capability.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:annotation>
<xs:documentation>
Use of the confirmed and confirm-timeout elements
requires the :confirmed-commit capability.
</xs:documentation>
</xs:annotation>
<xs:element name="confirmed" minOccurs="0"/>
<xs:element name="confirm-timeout"
type="confirmTimeoutType"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="commit" type="commitType"
substitutionGroup="rpcOperation"/>
<!--
<discard-changes> operation
-->
<xs:complexType name="discardChangesType">
<xs:annotation>
<xs:documentation>
The discard-changes operation requires the
:candidate capability.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="rpcOperationType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="discard-changes"
type="discardChangesType"
substitutionGroup="rpcOperation"/>
<!--
<close-session> operation
-->
<xs:complexType name="closeSessionType">
<xs:complexContent>
<xs:extension base="rpcOperationType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="close-session" type="closeSessionType"
substitutionGroup="rpcOperation"/>
<!--
<kill-session> operation
-->
<xs:complexType name="killSessionType">
<xs:complexContent>
<xs:extension base="rpcOperationType">
<xs:sequence>
<xs:element name="session-id"
type="SessionId" minOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="kill-session" type="killSessionType"
substitutionGroup="rpcOperation"/>
<!--
<hello> element
-->
<xs:element name="hello">
<xs:complexType>
<xs:sequence>
<xs:element name="capabilities">
<xs:complexType>
<xs:sequence>
<xs:element name="capability" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="session-id"
type="SessionId" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
END
終わり
The {name} capability is identified by the following capability string:
{name}機能は、次の機能文字列によって識別されます。
{capability uri}
{機能uri}
If existing operations are not modified by this capability, this section may be omitted.
既存の操作がこの機能によって変更されていない場合、このセクションは省略できます。
If this capability does not interact with other capabilities, this section may be omitted.
Consider the work involved in performing a configuration update against a single individual device. In making a change to the configuration, the application needs to build trust that its change has been made correctly and that it has not impacted the operation of the device. The application (and the application user) should feel confident that their change has not damaged the network.
単一の個々のデバイスに対して構成更新の実行に伴う作業を検討してください。構成を変更する際、アプリケーションは、その変更が正しく行われ、デバイスの動作に影響を与えていないという信頼を構築する必要があります。アプリケーション（およびアプリケーションユーザー）は、変更がネットワークに損害を与えていないことを確信する必要があります。
Protecting each individual device consists of a number of steps:
個々のデバイスを保護することは、いくつかのステップで構成されています。
o Acquiring the configuration lock.
o 構成ロックの取得。
o Loading the update.
o 更新の読み込み。
o Validating the incoming configuration.
o 着信構成の検証。
o Checkpointing the running configuration.
o 実行中の構成のチェックポイント。
o Changing the running configuration.
o 実行中の構成を変更します。
o Testing the new configuration.
o 新しい構成のテスト。
o Making the change permanent (if desired).
o 変更を永続的にする（必要に応じて）。
o Releasing the configuration lock.
o 構成ロックのリリース。
Let's look at the details of each step.
各ステップの詳細を見てみましょう。
A lock should be acquired to prevent simultaneous updates from multiple sources. If multiple sources are affecting the device, the application is hampered in both testing of its change to the configuration and in recovery should the update fail. Acquiring a short-lived lock is a simple defense to prevent other parties from introducing unrelated changes.
複数のソースからの同時更新を防ぐために、ロックを取得する必要があります。複数のソースがデバイスに影響を与えている場合、アプリケーションは構成への変更のテストと、更新が失敗した場合の回復の両方で妨げられます。短命のロックを取得することは、他の関係者が無関係な変更を導入するのを防ぐための簡単な防御です。
The lock can be acquired using the <lock> operation.
<lock>操作を使用してロックを取得できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
The configuration can be loaded onto the device without impacting the running system. If the :url capability is supported and lists "file" as a supported scheme, incoming changes can be placed in a local file.
実行システムに影響を与えることなく、構成をデバイスにロードできます。：URL機能がサポートされ、「ファイル」がサポートされているスキームとしてリストされている場合、着信変更をローカルファイルに配置できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<url>file://incoming.conf</url>
</target>
<source>
<config>
<!-- place incoming configuration here -->
</config>
</source>
</copy-config>
</rpc>
If the :candidate capability is supported, the candidate configuration can be used.
：候補の機能がサポートされている場合、候補設定を使用できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<!-- place incoming configuration here -->
</config>
</edit-config>
</rpc>
If the update fails, the user file can be deleted using the <delete-config> operation, or the candidate configuration can be reverted using the <discard-changes> operation.
更新が失敗した場合、<delete-config>操作を使用してユーザーファイルを削除するか、<disdard-changes>操作を使用して候補設定を戻すことができます。
Before the incoming configuration is applied, validating it is often useful. Validation allows the application to gain confidence that the change will succeed and simplifies recovery if it does not.
着信構成が適用される前に、それを検証することはしばしば役立ちます。検証により、アプリケーションは、変更が成功するという自信を得ることができ、そうでない場合は回復を簡素化できます。
If the device supports the :url capability and lists "file" as a supported scheme, use the <validate> operation with the <source> parameter set to the proper user file:
デバイスが以下をサポートしている場合、「ファイル」をサポートされたスキームとしてリストする場合、適切なユーザーファイルに設定された<source>パラメーターを使用して<balidate>操作を使用します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<url>file://incoming.conf</url>
</source>
</validate>
</rpc>
If the device supports the :candidate capability, some validation will be performed as part of loading the incoming configuration into the candidate. For full validation, either pass the <validate> parameter during the <edit-config> step given above, or use the <validate> operation with the <source> parameter set to <candidate>.
デバイスが次のようにサポートする場合、候補の機能を候補にロードする一環として、ある検証が実行されます。完全に検証するには、上記の<edit-config>ステップ中に<balidate>パラメーターを渡すか、<source>パラメーターを<soction>に設定して<balidate>操作を使用します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
The running configuration can be saved into a local file as a checkpoint before loading the new configuration. If the update fails, the configuration can be restored by reloading the checkpoint file.
実行中の構成は、新しい構成をロードする前に、チェックポイントとしてローカルファイルに保存できます。更新が失敗した場合、チェックポイントファイルをリロードすることにより、構成を復元できます。
The checkpoint file can be created using the <copy-config> operation.
チェックポイントファイルは、<copy-config>操作を使用して作成できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<url>file://checkpoint.conf</url>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
To restore the checkpoint file, reverse the source and target parameters.
チェックポイントファイルを復元するには、ソースパラメーターとターゲットパラメーターを逆にします。
When the incoming configuration has been safely loaded onto the device and validated, it is ready to impact the running system.
着信構成が安全にデバイスにロードされ、検証されている場合、実行システムに影響を与える準備ができています。
If the device supports the :url capability and lists "file" as a supported scheme, use the <edit-config> operation to merge the incoming configuration into the running configuration.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<url>file://incoming.conf</url>
</config>
</edit-config>
</rpc>
If the device supports the :candidate capability, use the <commit> operation to set the running configuration to the candidate configuration. Use the <confirmed> parameter to allow automatic reversion to the original configuration if connectivity to the device fails.
デバイスが次のようにサポートする場合、候補機能を使用して、<comped>操作を使用して、実行中の構成を候補構成に設定します。<confirmed>パラメーターを使用して、デバイスへの接続が失敗した場合は、元の構成への自動リバージョンを可能にします。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
Now that the incoming configuration has been integrated into the running configuration, the application needs to gain trust that the change has affected the device in the way intended without affecting it negatively.
着信構成が実行中の構成に統合されたため、アプリケーションは、変更がデバイスに悪影響を与えることなく、デバイスに影響を与えると信頼する必要があります。
To gain this confidence, the application can run tests of the operational state of the device. The nature of the test is dependent on the nature of the change and is outside the scope of this document. Such tests may include reachability from the system running the application (using ping), changes in reachability to the rest of the network (by comparing the device's routing table), or inspection of the particular change (looking for operational evidence of the BGP peer that was just added).
この信頼性を得るために、アプリケーションはデバイスの動作状態のテストを実行できます。テストの性質は、変更の性質に依存しており、このドキュメントの範囲外です。このようなテストには、アプリケーションを実行しているシステム（PINGを使用）を実行しているシステムからの到達可能性、ネットワークの残りの部分への到達可能性の変化（デバイスのルーティングテーブルを比較すること）、または特定の変更の検査（BGPピアの運用証拠を探していることが含まれます。追加されました）。
When the configuration change is in place and the application has sufficient faith in the proper function of this change, the application should make the change permanent.
構成の変更が整っており、アプリケーションがこの変更の適切な機能に十分な信頼を持っている場合、アプリケーションは変更を永続的にする必要があります。
If the device supports the :startup capability, the current configuration can be saved to the startup configuration by using the startup configuration as the target of the <copy-config> operation.
デバイスが以下をサポートする場合、スタートアップ構成を<Copy-Config>操作のターゲットとして使用して、現在の構成を起動構成に保存できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
If the device supports the :candidate capability and a confirmed commit was requested, the confirming commit must be sent before the timeout expires.
デバイスが以下をサポートしている場合、候補の能力と確認されたコミットが要求された場合、タイムアウトの有効期限が切れる前に、確認するコミットを送信する必要があります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
When the configuration update is complete, the lock must be released, allowing other applications access to the configuration.
構成の更新が完了したら、ロックをリリースする必要があり、構成に他のアプリケーションにアクセスできるようにします。
Use the <unlock> operation to release the configuration lock.
<Lock>操作を使用して、構成ロックをリリースします。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
When a configuration change requires updates across a number of devices, care should be taken to provide the required transaction semantics. The NETCONF protocol contains sufficient primitives upon which transaction-oriented operations can be built. Providing complete transactional semantics across multiple devices is prohibitively expensive, but the size and number of windows for failure scenarios can be reduced.
構成の変更に多くのデバイスで更新が必要な場合、必要なトランザクションセマンティクスを提供するように注意する必要があります。NetConfプロトコルには、トランザクション指向の操作を構築できる十分なプリミティブが含まれています。複数のデバイスで完全なトランザクションセマンティクスを提供することは非常に高価ですが、故障シナリオ用のウィンドウのサイズと数を減らすことができます。
There are two classes of multi-device operations. The first class allows the operation to fail on individual devices without requiring all devices to revert to their original state. The operation can be retried at a later time, or its failure simply reported to the user. An example of this class might be adding an NTP server. For this class of operations, failure avoidance and recovery are focused on the individual device. This means recovery of the device, reporting the failure, and perhaps scheduling another attempt.
The second class is more interesting, requiring that the operation should complete on all devices or be fully reversed. The network should either be transformed into a new state or be reset to its original state. For example, a change to a VPN may require updates to a number of devices. Another example of this might be adding a class-of-service definition. Leaving the network in a state where only a portion of the devices have been updated with the new definition will lead to future failures when the definition is referenced.
2番目のクラスはより興味深いもので、すべてのデバイスで操作を完了するか、完全に逆転する必要があります。ネットワークは、新しい状態に変換されるか、元の状態にリセットする必要があります。たとえば、VPNへの変更には、多くのデバイスの更新が必要になる場合があります。この別の例は、サービスのクラス定義を追加することです。ネットワークは、新しい定義でデバイスの一部のみが更新されている状態で、定義が参照されると将来の障害につながります。
To give transactional semantics, the same steps used in single device operations listed above are used, but are performed in parallel across all devices. Configuration locks should be acquired on all target devices and kept until all devices are updated and the changes made permanent. Configuration changes should be uploaded and validation performed across all devices. Checkpoints should be made on each device. Then the running configuration can be changed, tested, and made permanent. If any of these steps fail, the previous configurations can be restored on any devices upon which they were changed. After the changes have been completely implemented or completely discarded, the locks on each device can be released.
The following features have been deferred until a future revision of this document.
o Granular locking of configuration objects.
o 構成オブジェクトの粒状ロック。
o Named configuration files/datastores.
o 名前付き構成ファイル/データストア。
o Support for multiple NETCONF channels.
o 複数のネットコンチャネルのサポート。
o Asynchronous notifications.
o 非同期通知。
o Explicit protocol support for rollback of configuration changes to prior versions.
o 以前のバージョンへの構成変更のロールバックに対する明示的なプロトコルサポート。
Editor's Address
編集者のアドレス
Rob Enns Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 US
Rob Enns Juniper Networks 1194 North Mathilda Ave Sunnyvale、CA 94089 US
EMail: rpe@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。