[要約] RFC 6241はNETCONF（Network Configuration Protocol）に関する標準化ドキュメントであり、ネットワークデバイスの設定と管理を効率化するためのプロトコルです。目的は、ネットワーク機器の自動化と柔軟性の向上を実現することです。
Internet Engineering Task Force (IETF) R. Enns, Ed.
Request for Comments: 6241 Juniper Networks
Obsoletes: 4741 M. Bjorklund, Ed.
Category: Standards Track Tail-f Systems
ISSN: 2070-1721 J. Schoenwaelder, Ed.
Jacobs University
A. Bierman, Ed.
Brocade
June 2011
Network Configuration Protocol (NETCONF)
ネットワーク構成プロトコル（NETCONF）
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 as remote procedure calls (RPCs). This document obsoletes RFC 4741.
このドキュメントで定義されているネットワーク構成プロトコル（NETCONF）は、ネットワークデバイスの構成をインストール、操作、および削除するためのメカニズムを提供します。プロトコルメッセージと同様に、構成データの拡張マークアップ言語（XML）ベースのデータエンコーディングを使用します。NETCONFプロトコル操作は、リモートプロシージャコール（RPC）として実現されています。この文書はRFC 4741を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 5741のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6241.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6241で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2011 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（http://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日以前に公開されたIETF文書または公開されたIETFの貢献からの資料を含めることができます。この材料のいくつかの著作権を制御する人は、そのような材料の修正を許可する権利を信頼する権利を与えられなかった人物IETF標準の外部プロセス。そのような材料の著作権を制御する人から適切なライセンスを取得せずに、この文書はIETF規格プロセスの外で修正されていない可能性があり、それをフォーマットすること以外はIETF標準プロセスの外ではデリバティブ作品が作成されない可能性があります。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Separation of Configuration and State Data . . . . . . . 10
2. Transport Protocol Requirements . . . . . . . . . . . . . . . 11
2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 11
2.2. Authentication, Integrity, and Confidentiality . . . . . 12
2.3. Mandatory Transport Protocol . . . . . . . . . . . . . . 12
3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 13
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Document Type Declarations . . . . . . . . . . . . . . . 13
4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 13
4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 16
4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 19
5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 19
5.1. Configuration Datastores . . . . . . . . . . . . . . . . 19
5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 20
6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 21
6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 21
6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 22
6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 23
6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 23
6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 24
6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 25
6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 26
6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 26
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 27
6.4.4. Select All <name> Elements within the <users>
Subtree . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 30
6.4.6. Specific Elements from a Specific <user> Entry . . . 31
6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 32
6.4.8. Elements with Attribute Naming . . . . . . . . . . . 33
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 35
7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 35
7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 37
7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 43
7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 44
7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 49
7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 50
8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 51
8.2. Writable-Running Capability . . . . . . . . . . . . . . . 53
8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 53
8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 53
8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 53
8.2.5. Modifications to Existing Operations . . . . . . . . 53
8.3. Candidate Configuration Capability . . . . . . . . . . . 53
8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 54
8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 54
8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 54
8.3.5. Modifications to Existing Operations . . . . . . . . 56
8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 57
8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 57
8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 58
8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 58
8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 59
8.4.5. Modifications to Existing Operations . . . . . . . . 60
8.5. Rollback-on-Error Capability . . . . . . . . . . . . . . 61
8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 61
8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 62
8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 62
8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 62
8.5.5. Modifications to Existing Operations . . . . . . . . 62
8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 63
8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 63
8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 63
8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 63
8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 63
8.6.5. Modifications to Existing Operations . . . . . . . . 64
8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 64
8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 64
8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 65
8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 65
8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 65
8.7.5. Modifications to Existing Operations . . . . . . . . 65
8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 66
8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 66
8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 66
8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 66
8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 66
8.8.5. Modifications to Existing Operations . . . . . . . . 66
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 67
8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 67
8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 68
8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 68
8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 68
8.9.5. Modifications to Existing Operations . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 71
10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 71
10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 72
10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 72
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 76
Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 80
Appendix C. YANG Module for NETCONF Protocol Operations . . . . 85
Appendix D. Capability Template . . . . . . . . . . . . . . . . 105
D.1. capability-name (template) . . . . . . . . . . . . . . . 105
D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 105
D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 105
D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 105
D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 105
D.1.5. Modifications to Existing Operations . . . . . . . . 105
D.1.6. Interactions with Other Capabilities . . . . . . . . 105
Appendix E. Configuring Multiple Devices with NETCONF . . . . . 106
E.1. Operations on Individual Devices . . . . . . . . . . . . 106
E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 106
E.1.2. Checkpointing the Running Configuration . . . . . . . 107
E.1.3. Loading and Validating the Incoming Configuration . . 108
E.1.4. Changing the Running Configuration . . . . . . . . . 108
E.1.5. Testing the New Configuration . . . . . . . . . . . . 109
E.1.6. Making the Change Permanent . . . . . . . . . . . . . 109
E.1.7. Releasing the Configuration Lock . . . . . . . . . . 110
E.2. Operations on Multiple Devices . . . . . . . . . . . . . 111
Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 112
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 [W3C.REC-xml-20001006] 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 [W3C.REC-XML-20001006]のRPCをエンコードし、安全な接続指向セッションを使用してサーバーに送信します。サーバーはXMLでエンコードされた応答で応答します。要求と応答の両方の内容は、XML DTDSまたはXMLスキーマ、またはその両方で完全に説明されており、両方の当事者はExchangeに課された構文制約を認識できるようになります。
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 [W3C.REC-xslt-19991116], 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 [W3C.REC-XSLT-19991116]などの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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
o candidate configuration datastore: A configuration datastore that can be manipulated without impacting the device's current configuration and that can be committed to the running configuration datastore. Not all devices support a candidate configuration datastore.
o 候補設定データストア：デバイスの現在の設定に影響を与えずに操作できる構成データストア、および実行中の構成データストアにコミットできます。すべてのデバイスが候補設定データストアをサポートしているわけではありません。
o capability: A functionality that supplements the base NETCONF specification.
o 機能：ベースのNetConf仕様を補足する機能。
o client: Invokes protocol operations on a server. In addition, a client can subscribe to receive notifications from a server.
o クライアント：サーバー上のプロトコル操作を呼び出します。さらに、クライアントはサーバーから通知を受け取るように購読することができます。
o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state.
o 構成データ：システムを初期デフォルト状態から現在の状態に変換するために必要な書き込み可能なデータのセット。
o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof.
o データストア：情報を保存してアクセスするための概念的な場所。データストアは、例えば、ファイル、データベース、フラッシュメモリ位置、またはそれらの組み合わせを使用することができる。
o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state.
o 構成データストア：初期デフォルト状態から所望の動作状態にデバイスを取得するために必要な構成データの完全なセットを保持しているデータストア。
o message: A protocol element sent over a session. Messages are well-formed XML documents.
o メッセージ：セッションを介して送信されたプロトコル要素。メッセージは整形式のXML文書です。
o notification: A server-initiated message indicating that a certain event has been recognized by the server.
o 通知：特定のイベントがサーバーによって認識されていることを示すサーバー開始メッセージ。
o protocol operation: A specific remote procedure call, as used within the NETCONF protocol.
o プロトコル操作：NetConfプロトコル内で使用される特定のリモートプロシージャコール。
o remote procedure call (RPC): Realized by exchanging <rpc> and <rpc-reply> messages.
o リモートプロシージャコール（RPC）：<RPC>と<RPC-REPLY>メッセージを交換することによって実現されます。
o running configuration datastore: A configuration datastore holding the complete configuration currently active on the device. The running configuration datastore always exists.
o 構成データストアの実行：現在デバイス上で現在アクティブな完全な構成を保持している構成データストア。実行中の構成データストアは常に存在します。
o server: Executes protocol operations invoked by a client. In addition, a server can send notifications to a client.
o サーバー：クライアントによって呼び出されたプロトコル操作を実行します。さらに、サーバーはクライアントに通知を送信できます。
o session: Client and server exchange messages using a secure, connection-oriented session.
o セッション：安全な接続指向のセッションを使用して、クライアントとサーバーの交換メッセージ。
o startup configuration datastore: The configuration datastore holding the configuration loaded by the device when it boots. Only present on devices that separate the startup configuration datastore from the running configuration datastore.
o スタートアップコンフィギュレーションデータストア：構成データストアが起動したときにデバイスによってロードされた設定を保持しています。スタートアップコンフィギュレーションデータストアを実行コンフィギュレーションデータストアから分離するデバイスのみが存在します。
o state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics.
o 状態データ：読み取り専用ステータス情報や収集された統計などの構成データではないシステム上の追加データ。
o user: The authenticated identity of the client. The authenticated identity of a client is commonly referred to as the NETCONF username.
o ユーザー：クライアントの認証されたID。クライアントの認証されたIDは、一般にNETCONFのユーザー名と呼ばれます。
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 as shown in Figure 1.
NETCONFは、図1に示すように、概念的に4層に分割できます。
Layer Example
+-------------+ +-----------------+ +----------------+
(4) | Content | | Configuration | | Notification |
| | | data | | data |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------+ |
(3) | Operations | | <edit-config> | |
| | | | |
+-------------+ +-----------------+ |
| | |
+-------------+ +-----------------+ +----------------+
(2) | Messages | | <rpc>, | | <notification> |
| | | <rpc-reply> | | |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------------------------------+
(1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
| Transport | | |
+-------------+ +-----------------------------------------+
Figure 1: NETCONF Protocol Layers
図1：NetConfプロトコルレイヤー
(1) The Secure Transport 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 Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, and [RFC5717] documents notifications.
（2）メッセージ層は、RPCと通知を符号化するための単純でトランスポートに依存しないフレーミングメカニズムを提供します。セクション4 RPCメッセージと[RFC5717]のドキュメント通知を文書化します。
(3) The Operations layer defines a set of base protocol operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base protocol operations.
（3）Operations Layerは、XMLエンコードされたパラメータを使用してRPCメソッドとして呼び出される一連の基本プロトコル操作を定義します。セクション7は、基本プロトコル操作のリストを詳しく説明します。
(4) The Content layer is outside the scope of this document. It is expected that separate efforts to standardize NETCONF data models will be undertaken.
（4）コンテンツレイヤーはこの文書の範囲外です。NetConfデータモデルを標準化するための別々の努力が行われます。
The YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations, covering the Operations and the Content layers of Figure 1.
YANGデータモデリング言語[RFC6020]は、NetConfデータモデルやプロトコル操作、操作を網羅し、図1のコンテンツ層を指定するための開発されました。
A NETCONF capability is a set of functionality that supplements the base NETCONF specification. The capability is identified by a uniform resource identifier (URI) [RFC3986].
NETCONF機能は、ベースのNetConf仕様を補足する一連の機能です。機能は、統一資源識別子（URI）[RFC3986]によって識別されます。
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 might 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に、クライアントがサーバーの機能を検出できるようにする能力Exchangeを定義します。セクション8には、このドキュメントで定義されている機能のセットも一覧表示されます。
Additional capabilities can be defined at any time in external documents, allowing the set of capabilities to expand over time. Standards bodies can define standardized capabilities, and implementations can define proprietary ones. A capability URI MUST sufficiently distinguish the naming authority to avoid naming collisions.
追加の機能は、外部文書内のいつでも定義でき、一連の機能を時間の経過とともに拡大することができます。規格ボディは標準化された機能を定義することができ、実装は独自のものを定義することができます。能力URIは、命名衝突を回避するために命名権限を十分に区別する必要があります。
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> operationは設定と状態データを取得します。
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プロトコルによって設定データとして扱われません。
For example, if a local database of user authentication data is stored on the device, it is an implementation-dependent matter whether it is included in configuration data.
たとえば、ユーザー認証データのローカルデータベースがデバイスに格納されている場合は、構成データに含まれているかどうかは実装に依存します。
NETCONF uses an RPC-based communication paradigm. A client sends a series of one or more RPC request messages, which cause the server to respond with a corresponding series of RPC reply messages.
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 connections are long-lived, persisting between protocol operations.
NetConfは接続指向で、ピア間の永続的な接続を必要とします。この接続は信頼性の高い、順序付けられたデータ配信を提供しなければなりません。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, confidentiality, and replay protection. 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 could be encrypted using Transport Layer Security (TLS) [RFC5246] or Secure Shell (SSH) [RFC4251], depending on the underlying protocol.
NetConf接続は、認証、データの整合性、機密性、および再生保護を提供する必要があります。NETCONFはこの機能のためのトランスポートプロトコルによって異なります。NETCONFピアは、適切なレベルのセキュリティと機密性がこの文書とは無関係に提供されると仮定しています。たとえば、基盤となるプロトコルに応じて、トランスポートレイヤセキュリティ（TLS）[RFC5246]またはSECUR SHEL（SSH）[RFC4251]を使用して接続を暗号化できます。
NETCONF connections MUST be authenticated. The transport protocol is responsible for authentication of the server to the client and authentication of the client to the server. A NETCONF peer assumes that the connection's authentication information has been validated by the underlying transport protocol using sufficiently trustworthy mechanisms and that the peer's identity has been sufficiently proven.
NetConf接続は認証されなければなりません。トランスポートプロトコルは、クライアントへのサーバーの認証とサーバーへのクライアントの認証を担当します。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 available on the device. For example, a NETCONF server on a device that supports RADIUS [RFC2865] might allow the use of RADIUS to authenticate NETCONF sessions.
NETCONFの1つの目標は、デバイスのネイティブインターフェイスの機能に密接に従うデバイスへのプログラムのインタフェースを提供することです。したがって、基盤となるプロトコルは、デバイス上で利用可能な既存の認証メカニズムを使用することが予想されます。たとえば、RADIUS [RFC2865]をサポートするデバイス上のNETCONFサーバーでは、RADIUSを使用してNETCONFセッションを認証できます。
The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from Section 2.2 of [W3C.REC-xml-20001006]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. The transport protocol MUST provide a username to be used by the other NETCONF layers.
認証プロセスには、許可がサーバーに認識されている認証されたクライアントIDが発生する必要があります。クライアントの認証されたIDは、一般にNETCONFのユーザー名と呼ばれます。ユーザー名は、[W3C.REC-XML-20001006]のセクション2.2からの「CHAR」制作に一致する文字列です。ユーザ名を導出するために使用されるアルゴリズムは、トランスポートプロトコル特有、およびトランスポートプロトコルによって使用される認証メカニズムに特有のものである。トランスポートプロトコルは、他のNetConfレイヤによって使用されるユーザー名を指定する必要があります。
The access permissions of a given client, identified by its NETCONF username, are part of the configuration of the NETCONF server. These permissions MUST be enforced during the remainder of the NETCONF session. The details of how access control is configured is outside the scope of this document.
NETCONFのユーザー名で識別される特定のクライアントのアクセス権限は、NETCONFサーバーの構成の一部です。これらの許可は、NetConfセッションの残りの部分で強制されなければなりません。アクセス制御の設定方法の詳細は、この文書の範囲外です。
A NETCONF implementation MUST support the SSH transport protocol mapping [RFC6242].
NETCONF実装はSSHトランスポートプロトコルマッピング[RFC6242]をサポートしている必要があります。
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に固有のツールの両方で操作できるテキスト形式で表現できます。
All NETCONF messages MUST be well-formed XML, encoded in UTF-8 [RFC3629]. If a peer receives an <rpc> message that is not well-formed XML or not encoded in UTF-8, it SHOULD reply with a "malformed-message" error. If a reply cannot be sent for any reason, the server MUST terminate the session.
すべてのNETCONFメッセージは、UTF-8 [RFC3629]でエンコードされた厳密なXMLでなければなりません。ピアが整然としていないXMLまたはUTF-8でエンコードされていない<RPC>メッセージを受信した場合、それは「malfformed-message」エラーで返信する必要があります。何らかの理由で返信を送信できない場合、サーバーはセッションを終了する必要があります。
A NETCONF message MAY begin with an XML declaration (see Section 2.8 of [W3C.REC-xml-20001006]).
NETCONFメッセージはXML宣言で始まることがあります（[W3C.REC-XML-20001006]のセクション2.8を参照）。
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 [RFC3986]. NETCONF capabilities are discussed in Section 8.
NetConf機能名はURIでなければなりません[RFC3986]。NETCONF機能については、セクション8で説明します。
Document type declarations (see Section 2.8 of [W3C.REC-xml-20001006]) MUST NOT appear in NETCONF content.
文書タイプ宣言（[W3C.REC-XML-20001006のセクション2.8を参照）が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 syntax and XML encoding of the Messages-layer RPCs are formally defined in the XML schema in Appendix B.
メッセージ層RPCの構文とXMLエンコーディングは、付録BのXMLスキーマで正式に定義されています。
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 a 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. The sender MUST ensure that the "message-id" value is normalized according to the XML attribute value normalization rules defined in [W3C.REC-xml-20001006] if the sender wants the string to be returned unmodified. For example:
<RPC>要素には、必須の属性 "message-id"があります。これは、一般的に単調に増加する整数を符号化するRPCの送信者によって選択された文字列です。RPCの受信側はこの文字列をデコードまたは解釈しませんが、その結果、結果として生じる任意の<rpc-reply>メッセージに "message-id"属性として使用するように保存します。送信者は、送信者が文字列を変更しないようにしたい場合は、[W3C.REC-XML-20001006]で定義されているXML属性値正規化規則に従って「Message-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. This includes any "xmlns" attributes.
追加の属性が<rpc>要素に存在する場合、NetConfピアは<rpc-reply>要素で変更されずに返されないようにしなければなりません。これには「XMLNS」属性が含まれます。
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-each-method>というメソッドを呼び出します。これには、<my-first-parameter>の値が "14"、<<white-parameter>、値 "fred"の値で<my-first-parameter>を呼び出します。：
<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":
次の例では、<zip-code> "27606-0100"で<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> message.
<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 server MUST also return any additional attributes included in the <rpc> element unmodified in the <rpc-reply> element.
NETCONFサーバーは、<rpc-reppl>要素で変更されていない<rpc>要素に含まれる追加の属性も返す必要があります。
The response data is encoded as one or more child elements to the <rpc-reply> element.
応答データは、1つ以上の子要素として<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>要素は、要求されたコンテンツと同様に "user-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>要求の処理中にエラーが発生した場合、<rpc-error>要素は<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.
<RPC>要求の処理中にサーバーが複数のエラーを検出した場合、<rpc-reply>には複数の<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 (layer: Secure Transport)
* 輸送（レイヤー：安全な輸送）
* rpc (layer: Messages)
* RPC（レイヤー：メッセージ）
* protocol (layer: Operations)
* プロトコル（レイヤー：操作）
* application (layer: Content)
* アプリケーション（レイヤー：コンテンツ）
error-tag: Contains a string identifying the error condition. See Appendix A for allowed values.
error-tag：エラー状態を識別する文字列が含まれています。許容値については付録Aを参照してください。
error-severity: Contains a string identifying the error severity, as determined by the device. One of:
error-severity：デバイスによって決定されるように、エラーの重大度を識別する文字列が含まれています。の一つ：
* error
* エラー
* warning
* 警告
Note that there are no <error-tag> values defined in this document that utilize the "warning" enumeration. This is reserved for future use.
このドキュメントで定義されている<error-tag>値は、「警告」列挙を利用することができないことに注意してください。これは将来の使用のために予約されています。
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. If a data-model-specific and an implementation-specific error-app-tag both exist, then the data-model-specific value MUST be used by the server.
error-app-tag：1つが存在する場合、データモデル固有または実装固有のエラー状態を識別する文字列が含まれています。適切なアプリケーションerror-tagを特定のエラー状態に関連付けることができない場合、この要素は存在しません。データモデル固有と実装固有の誤りapp-tagの両方が存在する場合、データモデル固有の値はサーバーによって使用されなければなりません。
error-path: Contains the absolute XPath [W3C.REC-xpath-19991116] 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 or datastore node can be associated with a particular error condition.
error-path：absolute xpath [w3c.rec-xpath-19991116]は、特定の<rpc-error>要素で報告されているエラーに関連付けられているノードへの要素パスを識別する式を含みます。適切なペイロード要素やデータストアノードが特定のエラー状態に関連付けられていない場合、この要素は存在しません。
The XPath expression is interpreted in the following context:
XPath式は、次のコンテキストで解釈されます。
* The set of namespace declarations are those in scope on the <rpc-error> element.
* 名前空間宣言のセットは<rpc-error>要素のスコープ内のものです。
* The set of variable bindings is empty.
* 変数バインディングのセットは空です。
* The function library is the core function library.
* 関数ライブラリはコア関数ライブラリです。
The context node depends on the node associated with the error being reported:
コンテキストノードは、報告されているエラーに関連付けられているノードに依存します。
* If a payload element can be associated with the error, the context node is the rpc request's document node (i.e., the <rpc> element).
* ペイロード要素をエラーに関連付けることができる場合、コンテキストノードはRPC要求のドキュメントノード（すなわち<rpc>要素）である。
* Otherwise, the context node is the root of all data models, i.e., the node that has the top-level nodes from all data models as children.
* そうでなければ、コンテキストノードは、すべてのデータモデル、すなわち、すべてのデータモデルからの最上位ノードを持つノードのルートである。
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 [W3C.REC-xml-20001006] and discussed in [RFC3470].
エラーメッセージ：エラー状態を説明する人間の表示に適した文字列が含まれています。特定のエラー状態に対して適切なメッセージが提供されていない場合、この要素は存在しません。この要素には、[W3C.REC-XML-20001006]で定義されている「XML：LANG」属性を含め、[RFC3470]で説明しています。
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.
error-info：プロトコルまたはデータモデル固有のエラー内容を含みます。このようなエラーコンテンツが特定のエラー状態に対して提供されていない場合、この要素は存在しません。付録Aのリストは、各エラーの必須エラー情報コンテンツを定義します。プロトコル義務的なコンテンツの後、データモデル定義は、特定のアプリケーション層エラー情報がエラー情報コンテナに含まれることを義務付けています。実装は、拡張固有のデバッグ情報を提供するための追加の要素を含み得る。
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.
例：<rpc>要素が "message-id"属性なしで受信された場合、エラーが返されます。この場合にのみ、<rpc-reply>要素内の "message-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-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
</error-path>
<error-message xml:lang="en">
MTU value 25000 is not within range 256..9192
</error-message>
</rpc-error>
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
</error-path>
<error-message xml:lang="en">
Invalid IP address for interface Ethernet1/0
</error-message>
</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, and no data was returned from the operation. For example:
<RPC>要求の処理中にエラーや警告が発生しなかった場合、<ok>要素は<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は、初期の操作セットと、ベースを拡張するために使用できる機能のいくつかを提供します。NetConfはセクション8.1で説明されているようにセッションが開始されると、Exchangeデバイス機能をピアにします。
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つ以上の構成データストアの存在を定義し、それらの構成操作を可能にします。構成データストアは、デバイスをその初期デフォルト状態から所望の動作状態に取得するために必要な構成データの完全なセットとして定義されています。構成データストアには、状態データまたはエグゼクティブコマンドは含まれていません。
The running configuration datastore holds 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.
実行中の構成データストアは、現在ネットワークデバイスで現在アクティブな完全な設定を保持します。このタイプの構成データストアは1つだけデバイスに存在し、常に存在します。NetConfプロトコル操作<running>要素を使用してこのデータストアを参照してください。
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.
基本モデルには<実行>構成データストアのみが存在します。追加の構成データストアは機能によって定義されます。そのような構成データストアは、機能を宣伝するデバイスでのみ利用可能です。
The capabilities in Sections 8.3 and 8.7 define the <candidate> and <startup> configuration datastores, respectively.
セクション8.3および8.7の機能は、それぞれ<候補>および<起動>構成データストアを定義します。
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 the 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 can 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 server does not need to utilize any data-model-specific semantics during processing, allowing for simple and centralized implementation strategies.
XMLサブツリーフィルタリングは、<get>または<get-config>演算の<rpc-reply>にインクルードするようにアプリケーションが特定の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.
概念的には、サブツリーフィルタは、フィルタ選択基準を表す0個以上の要素サブツリーで構成されています。サブツリー内の各封じ込めレベルでは、兄弟ノードのセットはサーバーによって論理的に処理され、そのサブツリーとルートへの要素のパスがフィルタ出力に含まれているかどうかを判断します。
Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria 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>.
サブツリーフィルタで指定された各ノードは、包括的なフィルタを表します。サーバー上の指定されたデータストア内の基礎となるデータモデル内の関連するノードのみがフィルタによって選択されます。フィルタ絶対パス名が<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 can 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 コンテンツマッチノード
A namespace is considered to match (for filter purposes) if the XML namespace associated with a particular node within the <filter> element is the same as in the underlying data model. Note that namespace selection cannot be used by itself. At least one element MUST be specified in the filter if any elements are to be included in the filter output.
<filter>要素内の特定のノードに関連付けられているXMLネームスペースが基礎となるデータモデルと同じである場合、名前空間は（フィルタ目的のために）と見なされます。名前空間の選択は単独で使用できません。フィルタ出力に含まれる要素が含まれる場合は、少なくとも1つの要素をフィルタに指定する必要があります。
An XML namespace wildcard mechanism is defined for subtree filtering. If an element within the <filter> element is not qualified by a namespace (e.g., xmlns=""), then the server MUST evaluate all the XML namespaces it supports, when processing that subtree filter node. This wildcard mechanism is not applicable to XML attributes.
サブツリーフィルタリングには、XMLネームスペースのワイルドカードメカニズムが定義されています。<filter>要素内の要素がネームスペース（例えばxmlns = ""）によって修飾されていない場合、サーバーはサブリーレートフィルタノードを処理するときにそれがサポートするすべてのXML名前空間を評価する必要があります。このワイルドカードメカニズムはXML属性には適用されません。
Note that prefix values for qualified namespaces are not relevant when comparing filter elements to elements in the underlying data model.
基礎となるデータモデル内のフィルタ要素を要素に比較するときに、修飾名前空間のプレフィックス値は関係ありません。
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 in the "http://example.com/schema/1.2/config" namespace and any child nodes (from the underlying data model) will be included in the filter output.
この例では、<top>要素は選択ノードであり、 "http://example.com/schema/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> and <interfaces> elements are containment nodes, the <interface> element is a selection node, 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"は属性一致式です。値 "eth0"を持つ "ifname"属性を持つ "http://example.com/schema/1.2 / config"ネームスペースの "Interface"ノードのみ "" "" interfaces "ノード内の" Topfaces "ノード内に発生します。フィルタ出力に含まれています。
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>要素は整備ノードであり、<users>要素は選択ノードです。Configuration DataStoreのルートである<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.
o コンテンツ一致ノードにネストされた要素を含める必要があります。
o Multiple content match nodes (i.e., sibling nodes) are logically combined in an "AND" expression.
o 複数のコンテンツ一致ノード（すなわち、兄弟ノード）は、「AND」式で論理的に組み合わされる。
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 whitespace-onlyコンテンツのフィルタリングはサポートされていません。
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 If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be 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 それ以外の場合（すなわち、フィルタ兄bingセットに選択または封じ込めノードはない）、基礎となるデータモデル（およびそのサブツリーの場合はそのサブツリー）でこのレベルで定義されたすべてのノードがフィルタ出力に返される。
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).
兄弟コンテンツ一致ノードテストのいずれかが「偽」である場合、その兄弟セットに対してそれ以上のフィルタ処理は行われず、コンテンツ一致ノードを含むフィルタによってどの兄弟サブツリーも選択されない。
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.
この例では、<users>および<user>ノードは両方の封じ込めノードであり、<name>はコンテンツ一致ノードです。<NAME>の兄弟ノードが指定されていない（したがって、封じ込めまたは選択ノードがない）ので、<NAME>のすべての兄弟ノードがフィルタ出力に返されます。要素階層と一致する「http://example.com/schema/1.2/config」ネームスペースの「user」ノードのみ、および<NAME>要素が「FRED」に等しい場合の「FRED」に含まれます。
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 will be selected (with all child nodes) in the filter output.
各サブツリーフィルタは、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> Operationでフィルタを除外するデータモデル全体を返します。
<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> element's "type" attribute used in these examples is discussed further in Section 7.1.
コンテンツの一致や選択ノードが存在しないため、空のフィルタは何も選択しません。これはエラーではありません。これらの例で使用されている<filter>要素の "type"属性については、セクション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つの選択ノード（<ユーザー>）が含まれているため、そのサブツリーがフィルタによって選択されます。この例は、続くほとんどのフィルタの例で完全に取り付けられた<users>データモデルを表します。実データモデルでは、<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>).
次のフィルタ要求は同じ結果を生み出しましたが、コンテナ<users>は1つの子要素（<ユーザー>）を定義しているためです。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
This filter contains two containment nodes (<users>, <user>) and one selection node (<name>). All instances of the <name> element in the same sibling set are selected in the filter output. The client might 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つの封じ込めノード（<users>、<ユーザー>）と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つの封じ込めノード（<users>、<ユーザー>）と1つのコンテンツ一致ノード（<NAME>）があります。フィルタ出力で<NAME>の値が「FRED」の値が選択されている<名>を含む兄弟セットのすべてのインスタンス。
<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 selection 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つの封じ込めノード（<users>、<ユーザー>）、1つのコンテンツ一致ノード（<名>）、および2つの選択ノード（<type>、<full-name>）があります。フィルタ出力で<NAME>の値が「FRED」の値が選択されているのと同じ兄弟セット内の<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、バーニー）が含まれています。
The "root" subtree filter contains two containment nodes (<users>, <user>), one content match node (<name>), and one selection node (<company-info>). The subtree selection criteria are met, and just the company-info subtree for "root" is selected in the filter output.
「ルート」サブツリーフィルタには、2つの封じ込めノード（<users>、<User>）、1つのコンテンツ一致ノード（<名>）、および1つの選択ノード（<company-info>）が2つあります。サブツリー選択基準が満たされ、「ルート」の会社情報サブツリーだけがフィルタ出力で選択されています。
The "fred" subtree filter contains three containment nodes (<users>, <user>, <company-info>), one content match node (<name>), and one selection node (<id>). The subtree selection criteria are met, and just the <id> element within the company-info subtree for "fred" is selected in the filter output.
「Fred」サブツリーフィルタには、3つの封じ込めノード（<users>、<user>、<company-info>）、1つのコンテンツ一致ノード（<name>）、および1つの選択ノード（<ID>）があります。サブツリー選択基準が満たされ、「FRED」の会社情報サブツリー内の<id>要素だけがフィルタ出力で選択されています。
The "barney" subtree filter contains three containment nodes (<users>, <user>, <company-info>), two content match nodes (<name>, <type>), and one selection node (<dept>). The subtree selection criteria are 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つの封じ込めノード（<users>、<user>、<company-info>）、2つのコンテンツ一致ノード（<name>、<type>）、および1つの選択ノード（<dept>）があります。ユーザー "Barney"が "スーパーユーザー"ではなく、サブツリーの選択基準は満たされておらず、 "Barney"（その親<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>
<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 selection 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 are qualified because the "ifName" attribute will not be considered part of the "schema/1.2" namespace if it is unqualified.
この例では、フィルタには、1つの封じ込めノード（<インターフェイス>）、1つの属性一致式（ "ifname"）、および1つの選択ノード（<インタフェース>）が含まれています。フィルタ出力では、 "eth0"に等しい<ifname "属性を持つ<interface>サブツリーのすべてのインスタンスが選択されています。「ifname」属性が、非修飾の場合、「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 edit-config.
o copy-config
o copy-config.
o delete-config
o delete-config
o lock
o ロック
o unlock
o 閉まれた
o close-session
o 閉鎖
o kill-session
o キルセッション
A protocol operation can 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 YANG module in Appendix C. The following sections describe the semantics of each protocol operation.
プロトコル操作の構文とXMLエンコードは、付録CのYANGモジュールで正式に定義されています。以下のセクションでは、各プロトコル操作の意味論について説明します。
Description: Retrieve all or part of a specified configuration datastore.
説明：指定された構成データストアの全部または一部を取得します。
Parameters:
パラメーター：
source: Name of the configuration datastore being queried, such as <running/>.
ソース：<実行/>など、クエリされているコンフィギュレーションデータストアの名前。
filter: This parameter identifies the portions of the device configuration datastore to retrieve. If this parameter is not present, the entire configuration is returned.
フィルタ：このパラメータは、RETRIEVEにデバイス構成データストアの部分を識別します。このパラメータが存在しない場合は、構成全体が返されます。
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.
<filter>要素は、オプションで "type"属性を含めることができます。この属性は、<filter>要素内で使用されるフィルタリング構文のタイプを示します。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）、<filter>要素の "select"属性に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:
例：<users>サブツリー全体を取得するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/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>
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 datastore. 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 datastore 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.
NETCONFピアが：URL機能（セクション8.8）をサポートしている場合は、<config>パラメーターの代わりに<url>要素が表示されます。
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>メッセージと同様に、ターゲット設定は必ずしも交換されません。代わりに、ターゲット構成は、ソースのデータと要求された操作に従って変更されます。
If the <edit-config> operation contains multiple sub-operations that apply to the same conceptual node in the underlying data model, then the result of the operation is undefined (i.e., outside the scope of the NETCONF protocol).
基礎となるデータモデル内の同じ概念ノードに適用される複数のサブ操作が含まれている場合、操作の結果は未定義（すなわち、NETCONFプロトコルの範囲外）である。
Attributes:
属性：
operation: Elements in the <config> subtree MAY contain an "operation" attribute, which belongs to the NETCONF namespace defined in Section 3.1. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the <config> subtree.
操作：<config>サブツリーの要素には、セクション3.1で定義されているNETCONFネームスペースに属する "Operation"属性が含まれている可能性があります。属性は、動作を実行するための構成内のポイントを識別し、<config>サブツリー全体で複数の要素に表示されることがあります。
If the "operation" attribute is not specified, the configuration is merged into the configuration datastore.
"operation"属性が指定されていない場合、設定はConfiguration DataStoreにマージされます。
The "operation" attribute has one of the following values:
「operation」属性には、次のいずれかの値があります。
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.
merge：この属性を含む要素によって識別される構成データは、<target>パラメータによって識別された構成データストア内の対応するレベルで構成とマージされます。これがデフォルトの動作です。
replace: The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the <target> parameter. If no such configuration data exists in the configuration datastore, it is created. Unlike a <copy-config> operation, which replaces the entire target configuration, only the configuration actually present in the <config> parameter is affected.
置換：この属性を含む要素によって識別される構成データは、<target>パラメータによって識別された構成データストア内の関連設定を置き換えます。構成データストアにそのような設定データが存在しない場合は作成されます。ターゲット構成全体を置き換える<copy-config>操作とは異なり、<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 in the configuration datastore. If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of "data-exists".
作成：この属性を含む要素によって識別される構成データが、構成データがConfiguration DataStoreにまだ存在していない場合に限り、構成に追加されます。構成データが存在する場合、<rpc-error>要素は<error-tag> "data-exists"と返されます。
delete: The configuration data identified by the element containing this attribute is deleted from the configuration if and only if the configuration data currently exists in the configuration datastore. If the configuration data does not exist, an <rpc-error> element is returned with an <error-tag> value of "data-missing".
削除：この属性を含む要素によって識別される構成データは、構成データがConfiguration DataStoreに現在存在する場合に限り、構成から削除されます。構成データが存在しない場合は、<rpc-error>要素が "data-missing"の<error-tag>値で返されます。
remove: The configuration data identified by the element containing this attribute is deleted from the configuration if the configuration data currently exists in the configuration datastore. If the configuration data does not exist, the "remove" operation is silently ignored by the server.
削除：この属性を含む要素によって識別された構成データは、構成データがConfiguration DataStoreに現在存在する場合は、構成から削除されます。構成データが存在しない場合は、サーバーによって「削除」操作が黙って無視されます。
Parameters:
パラメーター：
target: Name of the configuration datastore being edited, such as <running/> or <candidate/>.
ターゲット：<実行/>または<andateate />など、編集中の構成データストアの名前。
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".
デフォルト - 操作：この<編集設定>要求のデフォルト操作を選択します。<default-operation>パラメータのデフォルト値は "merge"です。
The <default-operation> parameter is optional, but if provided, it has one of the following values:
<default-operation>パラメータはオプションですが、指定されている場合は、次のいずれかの値があります。
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.
なし：ターゲットデータストアは、着信設定データが「operation」属性を使用しない限り、<config>パラメータの設定の影響を受けません。<config>パラメータの設定にターゲットデータストア内に対応するレベルがないデータが含まれている場合、<rpc-error>は<error-tag>データが欠けている値で返されます。"None"を使用すると、削除する要素の親階層を意図せずに作成することを避けるために「削除」のような操作が可能です。
test-option: The <test-option> element MAY be specified only if the device advertises the :validate:1.1 capability (Section 8.6).
test-option：<test-option>要素は、デバイスが：検証：1.1機能（セクション8.6）をアドバタイズしている場合にのみ指定できます。
The <test-option> element has one of the following values:
<test-option>要素には、次のいずれかの値があります。
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.
test-then-set：設定しようとする前に検証テストを実行してください。検証エラーが発生した場合は、<edit-config> operationを実行しないでください。これがデフォルトのテストオプションです。
set: Perform a set without a validation test first.
セット：最初に検証テストなしでセットを実行してください。
test-only: Perform only the validation test, without attempting to set.
テスト専用：設定しようとすることなく検証テストのみを実行してください。
error-option: The <error-option> element has one of the following values:
error-option：<error-option>要素には、次のいずれかの値があります。
stop-on-error: Abort the <edit-config> operation on first error. This is the default error-option.
STOP-on-error：最初のエラーの<edit-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>要素が生成されるようにエラー状態が発生した場合、サーバーは<edit-config>の操作の処理を停止し、開始時に指定された設定を完全な状態に復元します。この<編集設定>操作。このオプションは、セクション8.5で説明されている：ROLLBACK-ON-ERROR機能をサポートするようにサーバーが必要です。
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.
config：デバイスのデータモデルの1つによって定義されている構成データの階層。内容は適切な名前空間に配置され、デバイスが適切なデータモデルを検出できるように、その機能定義によって定義されているように、その内容はそのデータモデルの制約に従わなければなりません。機能はセクション8で説明されています。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element.
正の応答：デバイスが要求を満たすことができた場合、<ok>要素を含む<rpc-reply>が送信されます。
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 can be present, and an instance is distinguished by the <name> element within each <interface> element.
例：<edit-config>このセクションの例では、<interface>要素の複数のインスタンスが存在する可能性がある単純なデータモデルを使用し、インスタンスは各<interface>要素内の<name>要素によって区別されます。
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:
以前のインターフェイスをその名前に置き換えるrunning構成に "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):
OSPFエリアからのインターフェースの削除192.0.2.4（同じエリアで設定されている他のインタフェースは影響を受けません）。
<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. 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".
書き込み可能な実行機能をアドバタイズしても、<copy-config>演算の<target>パラメータとして<running /> configuration datastoreをサポートしないことを選択できます。デバイスは、リモート間コピー操作をサポートしないことを選択できます。ここで、<source>と<target>パラメータの両方が<url>要素を使用します。<source>と<target>パラメータが同じURLまたはConfiguration DataStoreを識別している場合は、 "invalid-value"を含むエラータグでエラーが返されなければなりません。
Parameters:
パラメーター：
target: Name of the configuration datastore to use as the destination of the <copy-config> operation.
ターゲット：<copy-config>演算の宛先として使用する設定データストアの名前。
source: Name of the configuration datastore to use as the source of the <copy-config> operation, or the <config> element containing the complete configuration to copy.
ソース：<copy-config> operationのソースとして使用する設定データストア、またはコピーする完全な設定を含む<config>要素。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<rpc-reply>が送信されます。
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:password@example.com/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.
説明：構成データストアを削除します。<実行>構成データストアは削除できません。
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.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<rpc-reply>が送信されます。
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 entire configuration datastore 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.
説明：<lock>操作により、クライアントはデバイスの構成データストアシステム全体をロックすることができます。そのようなロックは、他のNetConfクライアント、非NETCONFクライアント（例えば、SNMPおよびコマンドラインインターフェイス（CLI）スクリプト）との対話を恐れずにクライアントが変更を加えることを目的としており、クライアントが変更をすることを可能にします。
An attempt to lock the configuration datastore 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 can be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, simple inactivity timeout, or detection of abusive behavior on the part of the client. These criteria are dependent on the implementation and the underlying transport.
ロックの期間は、ロックが解除され、ロックが解除されるかNetConfセッションが閉じるまで、ロックが取得され、持続するときに定義されます。セッションクロージャは、クライアントによって明示的に実行され、またはその基礎となるトランスポートの失敗、単純な非活性タイムアウト、またはクライアントの部分上の虐待的な動作の検出などの基準に基づいてサーバーによって暗黙的に実行されます。これらの基準は実装と基礎となる輸送に依存しています。
The <lock> operation takes a mandatory parameter, <target>. The <target> parameter names the configuration datastore that will be locked. When a lock is active, using the <edit-config> operation on the locked configuration datastore 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> operation 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.
<LOCK> OPERATIONは必須のパラメータ<target>を取ります。<target>パラメーターは、ロックされる構成データストアを指定します。ロックされている構成データストアの<edit-config>操作を使用して、ロックされた構成を使用して<copy-config>演算のターゲットとしてロックされた設定を使用して、他のNetConfセッションによって許可されません。さらに、システムは、これらのロックされた構成リソースがSNMPやCLIなどの他のNENCONF管理操作によって変更されないことを確認します。<kill-session>の操作を使用して、別のNetConfセッションが所有するロックのリリースを強制できます。他のエンティティによって保持されているロックを破る方法を定義するのはこの文書の範囲を超えています。
A lock MUST NOT be granted if any 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.
* ターゲット構成は<候補者>で、すでに変更されており、これらの変更はコミットまたはロールバックされていません。
* The target configuration is <running>, and another NETCONF session has an ongoing confirmed commit (Section 8.4).
* ターゲット設定は<RUNNING>で、もう1つのNetConfセッションには継続的な確認済みのコミットがあります（セクション8.4）。
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.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<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>に含まれています。
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.
ロックがすでに保持されている場合、<error-tag>要素は「ロック拒否」になり、<error-info>要素にはロック所有者の<session-ID>が含まれます。ロックがNEN-NETCONFエンティティによって保持されている場合は、0（ゼロ）の<session-ID>が含まれます。ターゲットの部分部分でさえもロックを実行する他のエンティティは、そのターゲット上でNetConfロック（これはグローバル）が得られるのを防ぎます。
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> OPERATIONを使用して、<LOCK> OPERATIONを使用して、<ロック解除>操作を使用します。
An <unlock> operation will not succeed if either of the following conditions is true:
次の条件に該当する場合、<uncokk>操作は成功しません。
* The specified lock is not currently active.
* 指定されたロックは現在アクティブされていません。
* The session issuing the <unlock> operation is not the same session that obtained the lock.
* <uncoks>操作を発行するセッションは、ロックを取得したのと同じセッションではありません。
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.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<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:
例：
<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 not present, 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.
<filter>要素は、オプションで "type"属性を含めることができます。この属性は、<filter>要素内で使用されるフィルタリング構文のタイプを示します。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"を使用して、<filter>要素の "select"属性に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サーバーが<閉じるセッション>要求を受信すると、セッションを正常に閉じます。サーバーは、セッションに関連付けられているロックとリソースを解放し、関連付けられた接続を正常に閉じます。<閉じるセッション>要求の後に受信されたNetConf要求は無視されます。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<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:
例：
<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エンティティがオープンセッションの<kill-session>要求を受け取ると、現在プロセス中の操作を中止し、セッションに関連付けられているロックとリソースを解放し、関連する接続を閉じます。
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サーバが<kill-session>要求を受信した場合（セクション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: 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.
session-id：終了するNetConfセッションのセッション識別子。この値が現在のセッションIDと等しい場合は、「無効な値」エラーが返されます。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定的な応答：デバイスが要求を満たすことができた場合は、<ok>要素を含む<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:
例：
<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 D. Future capability definitions can be published as standards by standards bodies or published as proprietary extensions.
付録Dのテンプレートを使用して追加の機能を定義できます。
A NETCONF capability is identified with a URI. The base capabilities are defined using URNs following the method described in RFC 3553 [RFC3553]. Capabilities defined in this document have the following format:
NetConf機能はURIで識別されます。基本機能は、RFC 3553 [RFC3553]に記載されている方法に従ってURNを使用して定義されています。この文書で定義されている機能は次の形式です。
urn:ietf:params:netconf:capability:{name}:1.x
where {name} is the name of the capability. Capabilities are often referenced in discussions and email using the shorthand :{name}, or :{name}:{version} if the capability exists in multiple versions. 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}：{name}：{version}。たとえば、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.1". A peer MAY include capabilities for previous NETCONF versions, to indicate that it supports multiple protocol versions.
セッション確立中に各ピアによって送信されたメッセージで機能が広告されています。NETCONFセッションが開かれると、各ピア（クライアントとサーバーの両方）がそのピアの機能のリストを含む<hello>要素を送信する必要があります。各ピアは、少なくとも基本NetConf機能 "urn：ietf：params：netconf：base：1.1"を送る必要があります。ピアには、複数のプロトコルバージョンがサポートされていることを示すために、以前のNetConfバージョンに対する機能を含めることができます。
Both NETCONF peers MUST verify that the other peer has advertised a common protocol version. When comparing protocol version capability URIs, only the base part is used, in the event any parameters are encoded at the end of the URI string. If no protocol version capability in common is found, the NETCONF peer MUST NOT continue the session. If more than one protocol version URI in common is present, then the highest numbered (most recent) protocol version MUST be used by both peers.
どちらのNETCONFピアも、他のピアが一般的なプロトコルバージョンをアドバタイズしたことを確認する必要があります。プロトコルバージョン機能のURIを比較すると、任意のパラメータがURI文字列の末尾にエンコードされている場合には、基本部分のみが使用されます。共通のプロトコルバージョン機能が見つからない場合、NetConfピアはセッションを続行してはいけません。複数のプロトコルバージョンURIが共通のものが存在する場合は、両方のピアによって最大番号付き（最新の）プロトコルバージョンを使用する必要があります。
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 <hello> message with a <session-id> element MUST terminate the NETCONF session. Similarly, a client that does not receive a <session-id> element in the server's <hello> message MUST terminate the NETCONF session (without first sending a <close-session>).
<session-id>要素を持つ<hello>メッセージを受信したサーバーは、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機能、ベースのNetConf文書で定義されている1つのNetConf機能、および1つの実装固有の機能をアドバタイズします。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</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.
書き込み可能な実行機能は、デバイスが<実行>構成データストアへの直接書き込みをサポートすることを示します。つまり、このデバイスは<und-config>と<copy-config>の操作をサポートしています。ここで、<実行>構成がターゲットである。
None.
無し。
The :writable-running capability is identified by the following capability string:
：書き込み可能な実行機能は、次の機能文字列によって識別されます。
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>.
書き込み可能な実行機能は、<running>要素を<target>として受け入れるように<edit-config> operationを修正します。
The :writable-running capability modifies the <copy-config> operation to accept the <running> element as a <target>.
：書き込み可能な実行機能は、<running>要素を<target>として受け入れるように<copy-config> ofponationを変更します。
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 can 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.
候補構成機能、：候補は、デバイスがデバイスの現在の設定に影響を与えずに操作することができる構成データを保持するために使用される候補構成データストアをサポートすることを示します。候補設定は、構成データを作成および操作するための作業場所として機能するフル構成データセットです。このデータに対して追加、削除、および変更を行い、目的の設定データを構築することができます。<コミット>動作は、デバイスの実行構成を候補構成の値に設定させる任意の時点で実行されてもよい。
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:1.1 capability (Section 8.4) would make no sense as a "copy confirmed" operation.
<COMMIT> OPERATIONは、実行構成を候補構成の現在の内容に効果的に設定します。単純なコピーとしてモデル化することができる間、それは多くの理由で明確な操作として行われます。高レベルの概念を一流の操作として維持する際に、開発者はクライアントが要求しているものとサーバーが実行する必要があるものの両方をより明確に見ることができます。これは、意図をより明らかに、特別なケースがそれほど複雑ではなく、操作の間の相互作用をより簡単にします。たとえば、：confirmed-commit：1.1能力（8.4節）は、「コピー確認」操作と同じ意味を表します。
The candidate configuration can be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it MUST assume that other sessions are 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 the 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.
候補設定をデバイスの新しい現在の設定としてコミットするには、<commit>操作を使用します。
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 running or candidate configuration is currently locked by a different session, the <commit> operation MUST fail with an <error-tag> value of "in-use".
実行中または候補構成が現在別のセッションによってロックされている場合、<commit>の操作は<error-tag>の値の「使用中」の値で失敗する必要があります。
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.
デバイスが要求を満たすことができた場合は、<ok>要素を含む<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:
例：
<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 is not to be committed, the <discard-changes> operation can be used to revert the candidate configuration to the current running configuration.
候補設定がコミットされないとクライアントが決定した場合は、<discard-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>、または<validate>操作のソースまたはターゲットとして使用できます。<source>または<target>パラメータとして使用できます。<候補>要素は候補設定を示すために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<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>パラメータとして<andated>要素を使用して<LOCK> OPERATIONを使用して候補設定をロックすることができます。
<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:
同様に、候補設定は<abdentate>要素を<target>パラメータとして使用してロック解除されます。
<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.
クライアントが候補構成への優れた変更で失敗すると、回復は困難になる可能性があります。簡単な回復を容易にするために、<uncoks>の操作または暗黙のうちにセッション障害から暗黙的にも明示的にも、ロックが解除されたときには、優れた変更が破棄されます。
The :confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation and the <confirmed>, <confirm-timeout>, <persist>, and <persist-id> parameters for the <commit> operation. See Section 8.3 for further details on the <commit> operation.
：confirm-commit：1.1機能は、サーバーが<camner-commit>操作と<chencted>、<conffer-timeout>、<perset>、<confir-commit-timeout>、<perset>、および<commit>操作のパラメータをサポートすることを示します。。<COMMIT>操作の詳細については、セクション8.3を参照してください。
A confirmed <commit> operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a <commit> operation without the <confirmed> parameter. The timeout period can be adjusted with the <confirm-timeout> parameter. If a follow-up confirmed <commit> operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed <commit> operation MAY introduce additional changes to the configuration.
確認されたコミットがタイムアウト期間内に（デフォルト600秒= 10分）に発行されない場合は、確認済みの<コミット>操作を元に戻す必要があります。確認コミットは<確認済み>パラメータなしの<COMMIT>操作です。タイムアウト期間は<confirm-timeout>パラメータで調整できます。フォローアップが確認された<コミット>操作が期限切れになる前に発行された場合、タイマーは新しい値にリセットされます（デフォルトでは600秒）。確認コミットとフォローアップ確認<コミット>の両方の操作は、構成に追加の変更を導入する可能性があります。
If the <persist> element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the <persist> element is given in the confirmed <commit> operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a <persist-id> element with a value equal to the given value of the <persist> element.
確認済みコミット操作に<persist>要素が指定されていない場合は、確認されたコミットを発行したのと同じセッションで、フォローアップコミットと確認コミットを発行する必要があります。<persist>要素が確認された<commit>演算で指定されている場合、フォローアップコミットと確認コミットは任意のセッションで指定でき、指定された値に等しい値を持つ<persist-id>要素を含める必要があります。<persist>要素の値。
If the server also advertises the :startup capability, a <copy-config> from running to startup is also necessary to save the changes to startup.
サーバーが：起動機能をアドバタイズした場合は、スタートアップに変更を保存するには、起動機能を実行して起動から起動への<copy-config>も必要です。
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, unless the confirmed commit also included a <persist> element.
確認のタイムアウトが期限切れになる前に確認されたコミットを発行するセッションが何らかの理由で終了した場合、確認されたコミットも<persist>要素に含まれていない限り、サーバーは確認されたコミットが発行される前に構成をその状態に復元する必要があります。
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. To cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued, by using the <cancel-commit> operation.
確認コミットが発行されていない場合、デバイスは確認されたコミットの発行前にその構成を状態に戻します。確認のタイムアウトが期限切れになるのを待たずに確認されたコミットをキャンセルして変更を元に戻すには、<cancel-commit>操作を使用して、クライアントは確認されたコミットが発行される前に構成を明示的に復元できます。
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 datastores, configuration locking SHOULD also be used.
共有構成の場合、この機能は、構成ロック機能が使用されていない限り、他の構成変更（たとえば、他のNetConfセッションを介して）が誤って変更または削除されることがあります（つまり、<編集設定>の前にロックが取得されます。操作が開始されます）。したがって、この機能を共有構成データストアで使用するためには、構成ロックも使用する必要があることが強く示唆されています。
Version 1.0 of this capability was defined in [RFC4741]. Version 1.1 is defined in this document, and extends version 1.0 by adding a new operation, <cancel-commit>, and two new optional parameters, <persist> and <persist-id>. For backwards compatibility with old clients, servers conforming to this specification MAY advertise version 1.0 in addition to version 1.1.
この機能のバージョン1.0は[RFC4741]で定義されています。このドキュメントではバージョン1.1が定義されており、新しい操作、<cancel-commit>、および2つの新しいオプションのパラメータ、<persist>と<persist-id>を追加して、バージョン1.0を拡張します。古いクライアントとの後方互換性のために、この仕様に準拠したサーバーは、バージョン1.1に加えてバージョン1.0をアドバタイズすることができます。
The :confirmed-commit:1.1 capability is only relevant if the :candidate capability is also supported.
：confirmed-commit：1.1能力は、候補機能もサポートされている場合にのみ関連しています。
The :confirmed-commit:1.1 capability is identified by the following capability string:
：confirmed-commit：1.1機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:confirmed-commit:1.1
Description:
説明：
Cancels an ongoing confirmed commit. If the <persist-id> parameter is not given, the <cancel-commit> operation MUST be issued on the same session that issued the confirmed commit.
継続的な確認済みコミットを取り消します。<persist-id>パラメータが与えられていない場合は、確認されたコミットを発行したのと同じセッションで<cancel-commit>操作を発行する必要があります。
Parameters:
パラメーター：
persist-id:
保存ID：
Cancels a persistent confirmed commit. The value MUST be equal to the value given in the <persist> parameter to the <commit> operation. If the value does not match, the operation fails with an "invalid-value" error.
永続確認済みコミットを取り消します。値は<commit>操作の<persist>パラメータで指定された値に等しくなければなりません。値が一致しない場合、操作は「無効な値」エラーで失敗します。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスが要求を満たすことができた場合は、<ok>要素を含む<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:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-commit/>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The :confirmed-commit:1.1 capability allows 4 additional parameters to the <commit> operation.
：confirm-commit：1.1機能は4つの追加パラメータを<commit>操作に可能にします。
Parameters:
パラメーター：
confirmed:
確認済み：
Perform a confirmed <commit> operation.
確認済み<COMMIT>操作を実行します。
confirm-timeout:
確認タイムアウト：
Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds.
確認されたコミットのタイムアウト期間（秒）。指定されていない場合、[タイムアウトの確認]は600秒になります。
persist:
持続する：
Make the confirmed commit survive a session termination, and set a token on the ongoing confirmed commit.
確認されたコミットをセッション終了に存続し、継続的な確認済みコミットにトークンを設定します。
persist-id:
保存ID：
Used to issue a follow-up confirmed commit or a confirming commit from any session, with the token from the previous <commit> operation.
以前の<COMMIT>操作のトークンを使用して、あらゆるセッションからのフォローアップ確認されたコミットまたは確認コミットを発行するために使用されます。
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>
Example:
例：
<!-- start a persistent confirmed-commit -->
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<persist>IQ,d4668</persist>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<!-- confirm the persistent confirmed-commit,
possibly from another session -->
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<persist-id>IQ,d4668</persist-id>
</commit>
</rpc>
<rpc-reply message-id="102"
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.
この機能は、サーバーが<error-option>パラメーターの "<edit-config> operationへのロールバックオンエラー"値をサポートすることを示します。
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 datastores, configuration locking also be used.
共有構成の場合、この機能は、構成ロック機能が使用されていない限り、他の構成変更（たとえば、他のNetConfセッションを介して）が誤って変更または削除されることがあります（つまり、<編集設定>の前にロックが取得されます。操作が開始されます）。したがって、この機能を共有構成データストアで使用するために、構成ロックも使用することが強く示唆されています。
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.
：ロールバックオンエラー機能により、<編集コンフィグレーション>操作の<エラーオプション>パラメータへの<エラーオプション>パラメータを使用できます。
<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 complete 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.
この機能がアドバタイズされている場合、デバイスは<検証>プロトコル操作をサポートし、少なくとも構文エラーについてチェックします。さらに、この機能は<test-option>パラメータを<edit-config> operationにサポートし、それが提供されると、少なくとも構文エラーの場合はチェックします。
Version 1.0 of this capability was defined in [RFC4741]. Version 1.1 is defined in this document, and extends version 1.0 by adding a new value, "test-only", to the <test-option> parameter of the <edit-config> operation. For backwards compatibility with old clients, servers conforming to this specification MAY advertise version 1.0 in addition to version 1.1.
この機能のバージョン1.0は[RFC4741]で定義されています。バージョン1.1はこのドキュメントで定義されており、<編集コンフィグレーション>操作の<test-option>パラメータに新しい値、「テスト専用」を追加することでバージョン1.0を拡張します。古いクライアントとの後方互換性のために、この仕様に準拠したサーバーは、バージョン1.1に加えてバージョン1.0をアドバタイズすることができます。
None.
無し。
The :validate:1.1 capability is identified by the following capability string:
：検証値：1.1機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:validate:1.1
Description:
説明：
This protocol operation validates the contents of the specified configuration.
このプロトコル操作は、指定された構成の内容を検証します。
Parameters:
パラメーター：
source:
ソース：
Name of the configuration datastore to validate, such as <candidate>, or the <config> element containing the complete configuration to validate.
設定データストアの名前、<andateate>など、検証するための完全な構成を含む<config>要素の名前。
Positive Response:
肯定的な反応：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
デバイスが要求を満たすことができた場合は、<ok>要素を含む<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>に含まれています。
A <validate> operation can fail for a number of reasons, such as syntax errors, missing parameters, references to undefined configuration data, or any other violations of rules established by the underlying data model.
<検証>操作は、構文エラー、欠落パラメータ、未定義の構成データへの参照、または基礎となるデータモデルによって確立された他の規則の違反など、さまざまな理由で失敗する可能性があります。
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 :validate:1.1 capability modifies the <edit-config> operation to accept the <test-option> parameter.
検証値：1.1機能<test-option>パラメータを受け入れるための<edit-config>の操作を変更します。
The device supports separate running and startup configuration datastores. The startup configuration is loaded by the device when it boots. 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> is used 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.
このデバイスは、別々の実行と起動設定データストアをサポートしています。起動時に起動設定はデバイスによってロードされます。実行構成に影響を与える操作は、自動的に起動設定にコピーされません。<rning>から<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:
：起動機能は、いくつかのNetConf操作の引数に<startup />構成データストアを追加します。サーバーは以下の追加値をサポートする必要があります。
+--------------------+--------------------------+-------------------+
| Operation | Parameters | Notes |
+--------------------+--------------------------+-------------------+
| <get-config> | <source> | |
| | | |
| <copy-config> | <source> <target> | |
| | | |
| <lock> | <target> | |
| | | |
| <unlock> | <target> | |
| | | |
| <validate> | <source> | If :validate:1.1 |
| | | is advertised |
| | | |
| <delete-config> | <target> | Resets the device |
| | | to its factory |
| | | defaults |
+--------------------+--------------------------+-------------------+
To save the startup configuration, use the <copy-config> operation to copy the <running> configuration datastore to the <startup> configuration datastore.
起動設定を保存するには、<copy-config>の操作を使用して<実行>構成データストアを<startup> configuration datastoreにコピーします。
<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>
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には、「Scheme」引数が割り当てられている「Scheme」引数が割り当てられている必要があります。例えば：
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.
：URL機能は、<config>パラメータの代わりに<url>要素を受け入れるように<edit-config> operationを修正します。
The file that the url refers to contains the configuration data hierarchy to be modified, encoded in XML under the element <config> in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
URLと言及したファイルは、変更する構成データ階層を含みます。 "urn：ietf：params：xml：ns：netconf：base：1.0"の名前空間：netconf：base：1.0 "の名前空間。
The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters.
：URL機能は、<url>要素を<source>と<target>パラメータの値として受け入れるように<copy-config> ofponationを変更します。
The file that the url refers to contains the complete datastore, encoded in XML under the element <config> in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
URLとは、element <config>の要素<config>の下にエンコードされた完全なデータストアが含まれているファイルは、 "utf：params：xml：ns：netconf：base：1.0"の名前空間を含みます。
The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters.
URL機能は<url>要素を<target>パラメータの値として受け入れるように<delete-config> offeterを変更します。
The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.
：URL機能は、<url>要素を<source>パラメータの値として受け入れるように<validate> operationを変更します。
The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the <filter> element. XPath is described in [W3C.REC-xpath-19991116].
XPath機能は、NETCONFピアが<filter>要素内のXPath式の使用をサポートすることを示します。XPathは[w3c.rec-xpath-19991116]に説明されています。
The data model used in the XPath expression is the same as that used in XPath 1.0 [W3C.REC-xpath-19991116], with the same extension for root node children as used by XSLT 1.0 ([W3C.REC-xslt-19991116], Section 3.1). Specifically, it means that the root node MAY have any number of element nodes as its children.
XPath式で使用されているデータモデルは、XPATH 1.0 [w3c.rec-xpath-19991116]で使用されているものと同じです。（[w3c.rec-xslt-19991116]、セクション3.1）。具体的には、ルートノードはその子として任意の数の要素ノードを有することができることを意味する。
The XPath expression is evaluated in the following context:
XPath式は次のコンテキストで評価されます。
o The set of namespace declarations are those in scope on the <filter> element.
o 名前空間宣言のセットは<filter>要素のスコープ内のものです。
o The set of variable bindings is defined by the data model. If no such variable bindings are defined, the set is empty.
o 一連の変数バインディングはデータモデルによって定義されます。そのような変数バインディングが定義されていない場合、セットは空です。
o The function library is the core function library, plus any functions defined by the data model.
o 関数ライブラリは、コア関数ライブラリ、さらにデータモデルによって定義された関数です。
o The context node is the root node.
o コンテキストノードはルートノードです。
The XPath expression MUST return a node set. If it does not return a node set, the operation fails with an "invalid-value" error.
XPath式はノードセットを返す必要があります。ノードセットを返さない場合、操作は「無効な値」エラーで失敗します。
The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. Specific data instances are not duplicated in the response.
応答メッセージには、フィルタ式によって選択されたサブツリーが含まれています。そのようなサブツリーごとに、サブツリーを一意に識別するために必要な要素または属性を含む、データモデルルートノードからサブツリーへの経路が応答メッセージに含まれています。特定のデータインスタンスは、応答に重複していません。
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機能は、<filter>要素の "type"属性の値 "xpath"を受け入れるように<get>と<get-config>操作を変更します。「type」属性が "XPath"に設定されている場合、<filter>要素に "select"属性が存在している必要があります。"select"属性はXPath式として扱われ、返されたデータをフィルタリングするために使用されます。この場合、<filter>要素自体を空にする必要があります。
The XPath result for the select expression MUST be a node-set. Each node in the node-set MUST correspond to a node in the underlying data model. In order to properly identify each node, the following encoding rules are defined:
SELECT式のXPathの結果はノードセットでなければなりません。ノード・セット内の各ノードは、基礎となるデータ・モデル内のノードに対応している必要があります。各ノードを正しく識別するために、次のエンコード規則が定義されています。
o All ancestor nodes of the result node MUST be encoded first, so the <data> element returned in the reply contains only fully specified subtrees, according to the underlying data model.
o 結果ノードのすべての先祖ノードを最初にエンコードする必要があるため、基礎となるデータモデルによると、返信で返された<data>要素には、完全に指定されたサブツリーのみが含まれています。
o If any sibling or ancestor nodes of the result node are needed to identify a particular instance within a conceptual data structure, then these nodes MUST also be encoded in the response.
o 結果ノードの兄弟ノードまたは祖先ノードが概念的なデータ構造内の特定のインスタンスを識別するために必要な場合は、これらのノードも応答にエンコードされている必要があります。
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 xmlns:t="http://example.com/schema/1.2/config"
type="xpath"
select="/t:top/t:users/t:user[t:name='fred']"/>
</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>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
This section provides security considerations for the base NETCONF message layer and the base operations of the NETCONF protocol. Security considerations for the NETCONF transports are provided in the transport documents, and security considerations for the content manipulated by NETCONF can be found in the documents defining data models.
このセクションでは、Base NetConfメッセージレイヤのセキュリティ上の考慮事項とNetConfプロトコルの基本操作を説明します。NETCONFトランスポートのセキュリティ上の考慮事項はトランスポート文書にあり、NETCONFによって操作されたコンテンツのセキュリティ上の考慮事項は、データモデルの定義文書にあります。
This document does not specify an authorization scheme, as such a scheme will likely 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 might be incompatible. Second, it could be desirable to authorize based on mechanisms available in the Secure Transport layer (e.g., SSH, Blocks Extensible Exchange Protocol (BEEP), etc.).
NetConfサーバを介した個々のユーザの承認は、1：1を他のインタフェースにマッピングしない場合があります。まず、データモデルは互換性がないかもしれません。第二に、安全なトランスポート層（例えば、SSH、ブロック拡張可能なExchange Protocol（Beep）など）で利用可能なメカニズムに基づいて認証することが望ましいかもしれない。
In addition, operations on configurations could have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, if the running configuration is not locked, a partially complete access list could be committed from the candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device.
さらに、構成に対する操作の操作は、それらの操作がファイルまたは操作されているオブジェクトのグローバルロックによっても保護されていない場合、意図しない結果を持つ可能性があります。たとえば、実行コンフィギュレーションがロックされていない場合、部分的に完全なアクセスリストは候補設定の範囲外の候補設定から候補構成のロックの所有者にコミットされ、不安定なデバイスまたはアクセスできないデバイスにつながります。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection 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 provides 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 can 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 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が<候補>構成でインターフェース上のIPアドレスを構成した場合、ユーザAは<候補>構成をコミットすることを許可されてはならない。
Similarly, just because someone says "go write a configuration through the URL capability at a particular place", this does not mean that an element will 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 a function within the device's native user interface. These two mechanisms suffer from a race condition that could be ameliorated by removing the offending user from an Authentication, Authorization, and Accounting (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> OPERATIONは、NETCONFが管理者の少なくともいくつかの信頼を持つシステムによる使用を目的としていることを示します。この文書で指定されているように、プリンシパルがそうでなければアクセスできない可能性がある構成の部分をロックすることが可能です。結局のところ、構成全体がロックされます。この問題を軽減するために、2つのアプローチがあります。OpenDendingセッションのセッションIDを知っている場合は、NETCONF内からプログラムで別のNetConfセッションを強制終了させることができます。ロックを破るための他の可能な方法は、デバイスのネイティブユーザーインターフェイス内で機能を提供することです。これら2つのメカニズムは、認証、承認、および会計（AAA）サーバから問題のあるユーザーを削除することによって改善される可能性がある競合状態に苦しんでいます。ただし、そのような解決策は、SSHパブリック/秘密鍵ペアが使用されているものなど、すべての展開シナリオでは役に立ちません。
This document registers a URI for the NETCONF XML namespace in the IETF XML registry [RFC3688].
このドキュメントは、IETF XMLレジストリ[RFC3688]のNetConf XMLネームスペースのURIを登録します。
IANA has updated the following URI to reference this document.
この文書を参照するには、IANAが次のURIを更新しました。
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 [RFC3688].
このドキュメントでは、IETF XMLレジストリ[RFC3688]のNetConf XMLスキーマのURIを登録します。
IANA has updated the following URI to reference this document.
この文書を参照するには、IANAが次のURIを更新しました。
URI: urn:ietf:params:xml:schema:netconf Registrant Contact: The IESG.
URI：URN：IETF：PARAMS：XML：スキーマ：NetConf登録者連絡先：IESG。
XML: Appendix B of this document.
XML：この文書の付録B。
This document registers a YANG module in the YANG Module Names registry [RFC6020].
このドキュメントでは、YANGモジュール名レジストリ[RFC6020]にYANGモジュールが登録されます。
name: ietf-netconf
namespace: urn:ietf:params:xml:ns:netconf:base:1.0
prefix: nc
reference: RFC 6241
IANA has created and now maintains a registry "Network Configuration Protocol (NETCONF) Capability URNs" that allocates NETCONF capability identifiers. Additions to the registry require IETF Standards Action.
IANAは、NetConf機能識別子を割り当てるレジストリ「ネットワーク構成プロトコル（NetConf）機能URN」を維持しています。レジストリへの追加には、IETF標準アクションが必要です。
IANA has updated the allocations of the following capabilities to reference this document.
IANAはこの文書を参照するために次の機能の割り当てを更新しました。
Index
Capability Identifier
------------------------
:writable-running
urn:ietf:params:netconf:capability:writable-running:1.0
:candidate
urn:ietf:params:netconf:capability:candidate:1.0
:rollback-on-error
urn:ietf:params:netconf:capability:rollback-on-error: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
IANA has added the following capabilities to the registry:
IANAはレジストリに次の機能を追加しました：
Index
Capability Identifier
------------------------
:base:1.1
urn:ietf:params:netconf:base:1.1
:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
:validate:1.1
urn:ietf:params:netconf:capability:validate:1.1
In addition to the editors, this document was written by:
編集者に加えて、この文書は次のように書かれています。
Ken Crozier, Cisco Systems
Cisco Systems.Ken Crozier
Ted Goddard, IceSoft
Ted Goddard、ムスコフト
Eliot Lear, Cisco Systems
Cisco Systems.Eliot Lear
Phil Shafer, Juniper Networks
Phil Shafer、ジュニパーネットワークス
Steve Waldbusser
Steve Waldbusser
Margaret Wasserman, Painless Security, LLC
マーガレットWasserman、痛みのないセキュリティ、LLC
The authors would like to acknowledge the members of the NETCONF working group. In particular, we would like to thank Wes Hardaker for his persistence and patience in assisting us with security considerations. We would also like to thank Randy Presuhn, Sharon Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch, and Kent Watsen for all of their valuable advice.
著者らはNetConfワーキンググループのメンバーを承認したいと思います。特に、セキュリティ上の考慮事項を支援する際に、Wes Serakerに彼の持続性と忍耐力を感謝します。また、Randy Presuhn、Sharon Chisholm、Glenn Waters、David Perkins、Weijing Chen、Simon Leinen、Keith Allen、Dave Harrington、Ladislav Lhotka、Tom Petch、およびKent Watsenの貴重なアドバイスのためのKent Watsenにもあります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T.、およびG。klyne、「登録プロトコルパラメータのIETF URNサブネームスペース」、BCP 73、RFC 3553、2003年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009.
[RFC5717] Lengyel、B.およびM.Bjorklund、「NetConfの部分ロックリモートプロシージャー（RPC）」、RFC 5717、2009年12月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M.、 "Yang - ネットワーク構成プロトコル（NetConf）のデータモデリング言語"、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J.、 "Common Yang Data Types"、RFC 6021、2010年10月。
[RFC6242] Wasserman, M., "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", RFC 6242, June 2011.
[RFC6242] Wasserman、M.、「Secure Shell（SSH）のNetConf構成プロトコルの使用（SSH）」、RFC 6242、2011年6月。
[W3C.REC-xml-20001006] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-XML-20001006] Sperberg-McQueen、C.、Breay、T.、Paoli、J.、およびE. Maler、「Extensible Markup Language（XML）1.0（第2版）」、ワールドワイドWebコンソーシアムREC-XML-20001006、2000年10月、<http://www.w3.org/tr/2000/rec-xml-20001006>。
[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3C.REC-XPATH-19991116] Derose、S.およびJ.Clark、World Wide Web Consortium勧告Rec-XPath-19991116、19999年11月、<http：// www。w3.org/tr/1999/Rec-xpath-19991116>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.、およびW.Simpson、「ユーザーサービスのリモート認証ダイヤル（RADIUS）」、RFC 2865、2000年6月。
[RFC3470] 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.
[RFC3470] Hollenbeck、S.、Rose、M.、L.Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）を使用するためのガイドライン」、BCP 70、RFC 3470、2003年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T.およびC. Lonvick、「Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R.、「NetConf構成プロトコル」、RFC 4741、2006年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] 2008年8月、RFC 5246、RFC 5246、RFC5246。
[W3C.REC-xslt-19991116] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[W3C.REC-XSLT-19991116]クラーク、J.、「XSL変換（XSLT）バージョン1.0」、ワールドワイドWebコンソーシアム推奨REC-XSLT-19991116、1999年11月、<http://www.w3.org/tr/ 1999 / Rec-XSLT-19991116>。
This section is normative.
このセクションは規範的です。
For each error-tag, the valid error-type and error-severity values are listed, together with any mandatory error-info, if any.
エラータグごとに、有効なエラータイプとエラー重大度の値が一覧表示されます。
error-tag: in-use error-type: protocol, application error-severity: error error-info: none Description: The request requires a resource that already is in use.
error-tag：in-useエラータイプ：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：要求にはすでに使用中のリソースが必要です。
error-tag: invalid-value error-type: protocol, application error-severity: error error-info: none Description: The request specifies an unacceptable value for one or more parameters.
error-tag：無効値error-type：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：要求は1つ以上のパラメータに対して許容できない値を指定します。
error-tag: too-big error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle.
エラータグ：Big-Big Error型：トランスポート、RPC、プロトコル、アプリケーションエラー - 重大度：エラー：エラー情報：なし説明：要求または応答（生成される）は、実装に対処するには大きすぎます。
error-tag: missing-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the missing attribute <bad-element> : name of the element that is supposed to contain the missing attribute Description: An expected attribute is missing.
error-tag：欠損属性error型：RPC、Protocol、Application Error：Severity：Error Error-info：<bad-属性>：欠落属性<bad-element>：想定される要素の名前欠落している属性の説明を含みます。：期待される属性が見つかりません。
error-tag: bad-attribute error-type: rpc, protocol, application error-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.
error-tag：不適切な属性のエラータイプ：RPC、Protocol、Application Error - 重大度：error：enerry-info：<bad-attribute>：属性の名前w / bad value <bad-element>：その名前の名前値が悪い場合の属性が含まれています。属性値が正しくありません。例えば、誤ったタイプ、範囲外、パターンの不一致。
error-tag: unknown-attribute error-type: rpc, protocol, application error-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.
error-tag：不明 - 属性のエラータイプ：RPC、Protocol、Application Error - 重大度：error：eRror-info：<bad-attribute>：予期しない属性<bad-element>：予期しない要素の名前属性説明：予期しない属性が存在します。
error-tag: missing-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the missing element Description: An expected element is missing.
error-tag：欠損enerat error型：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：<bad-element>：欠けている要素の名前説明：期待されている要素が見つかりません。
error-tag: bad-element error-type: protocol, application error-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.
error-mag：不正な要素のエラータイプ：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：<bad-element>：要素の名前w / bad値説明：要素値が正しくありません。例えば、誤ったタイプ、範囲外、パターンの不一致。
error-tag: unknown-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the unexpected element Description: An unexpected element is present.
error-tag：unknown-elementエラータイプ：プロトコル、アプリケーションerror - 重大度：error error-info：<bad-element>：予期しない要素の名前説明：予期しない要素が存在します。
error-tag: unknown-namespace error-type: protocol, application error-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.
error-tag：unknown-namespace error型：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：<bad-element>：予期しないネームスペースを含む要素の名前<bad-namespace>：予期しないネームスペースの名前：予期しないネームスペースが存在します。
error-tag: access-denied error-type: protocol, application error-severity: error error-info: none Description: Access to the requested protocol operation or data model is denied because authorization failed.
error-tag：アクセス拒否エラータイプ：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：要求されたプロトコルへのアクセスまたはデータモデルへのアクセスは失敗したために拒否されます。
error-tag: lock-denied error-type: protocol error-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.
error-tag：ロック拒否エラータイプ：プロトコルエラー - 重大度：エラーエラー - 情報：<session-id>：要求されたロックを保持しているセッションのセッションID、またはNETCONF以外のエンティティがロック記述を保持するようにゼロロックが現在別のエンティティによって保持されているため、要求されたロックへのアクセスは拒否されます。
error-tag: resource-denied error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: Request could not be completed because of insufficient resources.
error-tag：リソース拒否エラータイプ：トランスポート、RPC、プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：リソースが不十分なため、要求は完了できませんでした。
error-tag: rollback-failed error-type: protocol, application error-severity: error error-info: none Description: Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason.
error-tag：Rollback-Failedエラータイプ：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：一部の設定変更をロールバックする要求（ロールバックオンエラーまたは<破棄>操作を介して）何らかの理由で完了しました。
error-tag: data-exists error-type: application error-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.
error-tag：data-existsエラータイプ：アプリケーションエラー - 重大度：エラーエラー - 情報：なし説明：関連データモデルのコンテンツがすでに存在するため、要求は完了できませんでした。たとえば、既に存在するデータに対して「作成」操作が試行されました。
error-tag: data-missing error-type: application error-severity: error error-info: none Description: Request could not be completed because the relevant data model content does not exist. For example, a "delete" operation was attempted on data that does not exist.
error-tag：データ不足エラータイプ：アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：関連データモデルのコンテンツが存在しないため、要求は完了できませんでした。たとえば、存在しないデータに対して「削除」操作が試行されました。
error-tag: operation-not-supported error-type: protocol, application error-severity: error error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation.
error-tag：operation-supportedエラータイプ：プロトコル、アプリケーションerror - 重大度：エラーエラー - 情報：なし説明：要求された操作はこの実装ではサポートされていないため、要求は完了できませんでした。
error-tag: operation-failed error-type: rpc, protocol, application error-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.
error-tag：操作失敗エラータイプ：RPC、Protocol、Application Error - 重大度：エラーエラー - 情報：なし説明：要求された操作は、他のエラー状態によってカバーされていない理由で要求された操作が失敗したため、要求は完了できませんでした。
error-tag: partial-operation error-type: application error-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.
error-tag：partial-operation error-type：アプリケーションerror - 重大度：エラーエラー - 情報：<ok-element>：そのノードとそのすべての子ノードの要求された操作が完了したデータモデル内の要素を識別します。。この要素は、<error-info>コンテナ内で0回以上表示される可能性があります。
<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>コンテナ内で0回以上表示される可能性があります。
<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.
<noop-element>：そのノードとそのすべての子ノードに対して要求された操作が試行されなかったデータモデル内の要素を識別します。この要素は、<error-info>コンテナ内で0回以上表示される可能性があります。
Description: This error-tag is obsolete, and SHOULD NOT be sent by servers conforming to this document.
説明：このエラータグは廃止されており、この文書に準拠したサーバーによって送信されるべきではありません。
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>).
要求された操作の一部が失敗したか、または何らかの理由で試行されませんでした。サーバーによって完全なクリーンアップが実行されていません（例えば、ロールバックはサポートされていません）。エラー情報コンテナは、要求された操作が成功したアプリケーションデータモデル内容のどの部分（<ok-element>）、失敗した（<bad-element>）、または試行されていないかを識別するために使用されます（<noop-element）>）。
error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set.
error-tag：malformed-messageエラータイプ：RPC error - 重大度：エラーエラー - 情報：なし説明：正しく解析されなかったため、メッセージを処理できませんでした。たとえば、メッセージは整形式のXMLではありません。無効な文字セットを使用します。
This error-tag is new in :base:1.1 and MUST NOT be sent to old clients.
このerror-tagは次のように：基本：1.1で、古いクライアントに送信してはいけません。
This section is normative.
このセクションは規範的です。
<CODE BEGINS> file "netconf.xsd"
<コード開始>ファイル "NETCONF.XSD"
<?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"
version="1.1">
<xs:annotation>
<xs:documentation>
This schema defines the syntax for the NETCONF Messages layer
messages 'hello', 'rpc', and 'rpc-reply'.
</xs:documentation>
</xs:annotation>
<!--
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:enumeration value="malformed-message"/>
</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:string"
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" processContents="lax"
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>
<!--
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:enumeration value="remove"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="operation" type="editOperationType"/>
<!--
<rpc-reply> element
-->
<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:sequence>
<xs:element ref="rpc-error"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="rpcResponse"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</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:element name="rpc-reply" type="rpcReplyType"/>
<!--
<rpc-error> element
-->
<xs:element name="rpc-error" type="rpcErrorType"/>
<!--
rpcOperationType: used as a base type for all
NETCONF operations
-->
<xs:complexType name="rpcOperationType"/>
<xs:element name="rpcOperation" type="rpcOperationType"
abstract="true"/>
<!--
rpcResponseType: used as a base type for all
NETCONF responses
-->
<xs:complexType name="rpcResponseType"/>
<xs:element name="rpcResponse" type="rpcResponseType"
abstract="true"/>
<!--
<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>
<CODE ENDS>
<コード終了>
This section is normative.
このセクションは規範的です。
The ietf-netconf YANG module imports typedefs from [RFC6021].
IETF-NETCONF YANGモジュールは[RFC6021]からTypedeFをインポートします。
<CODE BEGINS> file "ietf-netconf@2011-06-01.yang"
module ietf-netconf {
モジュールIETF-NETCONF {
// the namespace for NETCONF XML definitions is unchanged
// from RFC 4741, which this document replaces
namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
prefix nc;
接頭辞NC。
import ietf-inet-types {
prefix inet;
}
organization "IETF NETCONF (Network Configuration) Working Group";
組織「IETF NETCONF（ネットワーク構成）ワーキンググループ」。
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <netconf@ietf.org>
WG Chair: Bert Wijnen
<bertietf@bwijnen.net>
WG Chair: Mehmet Ersue
<mehmet.ersue@nsn.com>
Editor: Martin Bjorklund
<mbj@tail-f.com>
Editor: Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de>
Editor: Andy Bierman
<andy.bierman@brocade.com>";
description "NETCONF Protocol Data Types and Protocol Operations.
説明 "NetConfプロトコルデータ型とプロトコル操作。
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2011 IETFの信頼と文書著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 6241; see
the RFC itself for full legal notices.";
revision 2011-06-01 {
description
"Initial revision";
reference
"RFC 6241: Network Configuration Protocol";
}
extension get-filter-element-attributes { description "If this extension is present within an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the <get> and <get-config> protocol operations, then the following unqualified XML attribute is supported within the <filter> element, within a <get> or <get-config> protocol operation:
get-filter-element-attributes {description "拡張子が 'filter'という名前の 'anyxml'ステートメント内に存在する場合、<get>と<get-config>プロトコル操作のRPC入力セクション内で概念的に定義されている必要があります。その場合、次の不適切なXML属性は、<get>または<get-config>プロトコル操作内で、<filter>要素内でサポートされています。
type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'.
タイプ：許可された値文字列 'subtree'と 'xpath'を持つオプションの属性。欠落している場合、デフォルト値は 'subtree'です。
If the 'xpath' feature is supported, then the following unqualified XML attribute is also supported:
'XPath'機能がサポートされている場合は、次の非修飾XML属性もサポートされています。
select: optional attribute containing a
string representing an XPath expression.
The 'type' attribute must be equal to 'xpath'
if this attribute is present.";
}
// NETCONF capabilities defined as features feature writable-running {
//機能として定義されたNetConf機能が書き込み可能な機能実行{
description
"NETCONF :writable-running capability;
If the server advertises the :writable-running
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.2";
}
feature candidate {
description
"NETCONF :candidate capability;
If the server advertises the :candidate
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.3";
}
feature confirmed-commit {
if-feature candidate;
description
"NETCONF :confirmed-commit:1.1 capability;
If the server advertises the :confirmed-commit:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.4";
}
feature rollback-on-error {
description
"NETCONF :rollback-on-error capability;
If the server advertises the :rollback-on-error
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.5";
}
feature validate {
description
"NETCONF :validate:1.1 capability;
If the server advertises the :validate:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.6";
}
feature startup {
description
"NETCONF :startup capability;
If the server advertises the :startup
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.7";
}
feature url {
description
"NETCONF :url capability;
If the server advertises the :url
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.8";
}
feature xpath {
description
"NETCONF :xpath capability;
If the server advertises the :xpath
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.9";
}
// NETCONF Simple Types
// NetConfシンプルタイプ
typedef session-id-type {
type uint32 {
range "1..max";
}
description
"NETCONF Session Id";
}
typedef session-id-or-zero-type {
type uint32;
description
"NETCONF Session Id or Zero to indicate none";
}
typedef error-tag-type {
type enumeration {
enum in-use {
description
"The request requires a resource that
already is in use.";
}
enum invalid-value {
description
"The request specifies an unacceptable value for one
or more parameters.";
}
enum too-big {
description
"The request or response (that would be generated) is
too large for the implementation to handle.";
}
enum missing-attribute {
description
"An expected attribute is missing.";
}
enum bad-attribute {
description
"An attribute value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-attribute {
description
"An unexpected attribute is present.";
}
enum missing-element {
description
"An expected element is missing.";
}
enum bad-element {
description
"An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-element {
description
"An unexpected element is present.";
}
enum unknown-namespace {
description
"An unexpected namespace is present.";
}
enum access-denied {
description
"Access to the requested protocol operation or
data model is denied because authorization failed.";
}
enum lock-denied {
description
"Access to the requested lock is denied because the
lock is currently held by another entity.";
}
enum resource-denied {
description
"Request could not be completed because of
insufficient resources.";
}
enum rollback-failed {
description
"Request to roll back some configuration change (via
rollback-on-error or <discard-changes> operations)
was not completed for some reason.";
}
enum data-exists {
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.";
}
enum data-missing {
description
"Request could not be completed because the relevant
data model content does not exist. For example,
a 'delete' operation was attempted on
data that does not exist.";
}
enum operation-not-supported {
description
"Request could not be completed because the requested
operation is not supported by this implementation.";
}
enum operation-failed {
description
"Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.";
}
enum partial-operation {
description
"This error-tag is obsolete, and SHOULD NOT be sent
by servers conforming to this document.";
}
enum malformed-message {
description
"A message could not be handled because it failed to
be parsed correctly. For example, the message is not
well-formed XML or it uses an invalid character set.";
}
}
description "NETCONF Error Tag";
reference "RFC 6241, Appendix A";
}
typedef error-severity-type {
type enumeration {
enum error {
description "Error severity";
}
enum warning {
description "Warning severity";
}
}
description "NETCONF Error Severity";
reference "RFC 6241, Section 4.3";
}
typedef edit-operation-type {
type enumeration {
enum merge {
description
"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.";
}
enum replace {
description
"The configuration data identified by the element
containing this attribute replaces any related
configuration in the configuration datastore
identified by the target parameter. If no such
configuration data exists in the configuration
datastore, it is created. Unlike a
<copy-config> operation, which replaces the
entire target configuration, only the configuration
actually present in the config parameter is affected.";
}
enum create {
description
"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 in the configuration
datastore. If the configuration data exists, an
<rpc-error> element is returned with an
<error-tag> value of 'data-exists'.";
}
enum delete {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if and only if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, an <rpc-error> element is returned with
an <error-tag> value of 'data-missing'.";
}
enum remove {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, the 'remove' operation is silently ignored
by the server.";
}
}
default "merge";
description "NETCONF 'operation' attribute values";
reference "RFC 6241, Section 7.2";
}
// NETCONF Standard Protocol Operations
// NetConf標準プロトコル操作
rpc get-config {
description
"Retrieve all or part of a specified configuration.";
reference "RFC 6241, Section 7.1";
参照「RFC 6241、セクション7.1」;
input {
container source {
description
"Particular configuration to retrieve.";
"検索するための特定の設定。"
choice config-source {
mandatory true;
description
"The configuration to retrieve.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.
This is optional-to-implement on the server because
not all servers will support filtering for this
datastore.";
}
}
}
anyxml filter {
description
"Subtree or XPath filter to use.";
nc:get-filter-element-attributes;
}
}
output {
anyxml data {
description
"Copy of the source datastore subset that matched
the filter criteria (if any). An empty data container
indicates that the request did not produce any results.";
}
}
}
rpc edit-config { description
rpc edit-config {説明
"The <edit-config> operation loads all or part of a specified configuration to the specified target configuration.";
「<編集設定>オペレーションは、指定された設定の全部または一部を指定されたターゲット構成にロードします。」
reference "RFC 6241, Section 7.2";
参照「RFC 6241、セクション7.2」;
input {
container target {
description
"Particular configuration to edit.";
choice config-target {
mandatory true;
description
"The configuration target.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config source.";
}
}
}
leaf default-operation {
type enumeration {
enum merge {
description
"The default operation is merge.";
}
enum replace {
description
"The default operation is replace.";
}
enum none {
description
"There is no default operation.";
}
}
default "merge";
description
"The default operation to use.";
}
}
leaf test-option {
if-feature validate;
type enumeration {
enum test-then-set {
description
"The server will test and then set if no errors.";
}
enum set {
description
"The server will set without a test first.";
}
enum test-only {
description
"The server will only test and not set, even
if there are no errors.";
}
}
default "test-then-set";
description
"The test option to use.";
}
leaf error-option {
type enumeration {
enum stop-on-error {
description
"The server will stop on errors.";
}
enum continue-on-error {
description
"The server may continue on errors.";
}
enum rollback-on-error {
description
"The server will roll back on errors.
This value can only be used if the 'rollback-on-error'
feature is supported.";
}
}
default "stop-on-error";
description
"The error option to use.";
}
choice edit-content {
選択編集コンテンツ{
mandatory true;
description
"The content for the edit operation.";
anyxml config {
description
"Inline Config content.";
}
leaf url {
if-feature url;
type inet:uri;
description
"URL-based config content.";
}
}
}
}
rpc copy-config {
description
"Create or replace an entire configuration datastore with the
contents of another complete configuration datastore.";
reference "RFC 6241, Section 7.3";
参照「RFC 6241、セクション7.3」;
input {
container target {
description
"Particular configuration to copy to.";
choice config-target {
mandatory true;
description
"The configuration target of the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config target.
This is optional-to-implement on the server.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
container source {
description
"Particular configuration to copy from.";
choice config-source {
mandatory true;
description
"The configuration source for the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
rpc delete-config {
description
"Delete a configuration datastore.";
reference "RFC 6241, Section 7.4";
参照「RFC 6241、セクション7.4」;
input {
container target {
description
"Particular configuration to delete.";
choice config-target {
mandatory true;
description
"The configuration target to delete.";
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
}
}
rpc lock {
description
"The lock operation allows the client to lock the configuration
system of a device.";
reference "RFC 6241, Section 7.5";
「RFC 6241、セクション7.5」;
input {
container target {
description
"Particular configuration to lock.";
choice config-target {
mandatory true;
description
"The configuration target to lock.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
rpc unlock {
description
"The unlock operation is used to release a configuration lock,
previously obtained with the 'lock' operation.";
reference "RFC 6241, Section 7.6";
参照「RFC 6241、セクション7.6」;
input {
container target {
description
"Particular configuration to unlock.";
choice config-target {
mandatory true;
description "The configuration target to unlock.";
説明「ロックを解除する設定」;;
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
rpc get {
description
"Retrieve running configuration and device state information.";
reference "RFC 6241, Section 7.7";
参照「RFC 6241、セクション7.7」;
input {
anyxml filter {
description
"This parameter specifies the portion of the system
configuration and state data to retrieve.";
nc:get-filter-element-attributes;
}
}
output {
anyxml data {
description
"Copy of the running datastore subset and/or state
data that matched the filter criteria (if any).
An empty data container indicates that the request did not
produce any results.";
}
}
}
rpc close-session {
description
"Request graceful termination of a NETCONF session.";
reference "RFC 6241, Section 7.8";
}
rpc kill-session {
description
"Force the termination of a NETCONF session.";
reference "RFC 6241, Section 7.9";
参照「RFC 6241、セクション7.9」;
input {
leaf session-id {
type session-id-type;
mandatory true;
description
"Particular session to kill.";
}
}
}
rpc commit {
if-feature candidate;
description "Commit the candidate configuration as the device's new current configuration.";
説明 "候補設定をデバイスの新しい現在の設定としてコミットします。"
reference "RFC 6241, Section 8.3.4.1";
参照「RFC 6241、セクション8.3.4.1」;
input {
leaf confirmed {
if-feature confirmed-commit;
type empty;
description
"Requests a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf confirm-timeout {
if-feature confirmed-commit;
type uint32 {
range "1..max";
}
units "seconds";
default "600"; // 10 minutes
description
"The timeout interval for a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf persist {
if-feature confirmed-commit;
type string;
description
"This parameter is used to make a confirmed commit
persistent. A persistent confirmed commit is not aborted
if the NETCONF session terminates. The only way to abort
a persistent confirmed commit is to let the timer expire,
or to use the <cancel-commit> operation.
The value of this parameter is a token that must be given in the 'persist-id' parameter of <commit> or <cancel-commit> operations in order to confirm or cancel the persistent confirmed commit.
このパラメータの値は、永続確認済みコミットを確定またはキャンセルするために、<commit>または<cancel-commit>操作の 'persist-id'パラメータで指定する必要があるトークンです。
The token should be a random string.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf persist-id {
if-feature confirmed-commit;
type string;
description
"This parameter is given in order to commit a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
reference "RFC 6241, Section 8.3.4.1";
}
}
}
rpc discard-changes {
if-feature candidate;
description "Revert the candidate configuration to the current running configuration.";
説明「候補設定を現在の実行構成に戻します」。
reference "RFC 6241, Section 8.3.4.2";
}
rpc cancel-commit {
if-feature confirmed-commit;
description
"This operation is used to cancel an ongoing confirmed commit.
If the confirmed commit is persistent, the parameter
'persist-id' must be given, and it must match the value of the
'persist' parameter.";
reference "RFC 6241, Section 8.4.4.1";
input {
leaf persist-id {
type string;
description
"This parameter is given in order to cancel a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
}
}
}
rpc validate {
if-feature validate;
description "Validates the contents of the specified configuration.";
説明「指定された設定の内容を検証します」。
reference "RFC 6241, Section 8.6.4.1";
参照「RFC 6241、セクション8.6.4.1」;
input {
container source {
description
"Particular configuration to validate.";
choice config-source {
mandatory true;
description
"The configuration source to validate.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
}
}
<CODE ENDS>
<コード終了>
This non-normative section defines a template that can be used to define protocol capabilities. Data models written in YANG usually do not need to define protocol capabilities since the usage of YANG automatically leads to a capability announcing the data model and any optional portions of the data model, so called features in YANG terminology. The capabilities template is intended to be used in cases where the YANG mechanisms are not powerful enough (e.g., for handling parameterized features) or a different data modeling language is used.
この非規範的なセクションは、プロトコル機能を定義するために使用できるテンプレートを定義します。Yangで書かれたデータモデルは通常、ヤンの使用法が自動的にデータモデルとデータモデルの任意の部分を発表する機能をもたらすため、プロトコル機能を定義する必要はありません。能力テンプレートは、Yangメカニズムが十分に強力ではない場合（例えば、パラメータ化された機能を処理するために）使用される場合、または異なるデータモデリング言語が使用されることを意図しています。
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.
この機能が他の機能と対話しない場合、このセクションは省略することができます。
This section is non-normative.
このセクションは非規範です。
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 Checkpointing the running configuration.
o 実行設定をチェックします。
o Loading and validating the incoming 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 if the update fails. 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> OPEROPYを使用して取得できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
If the :candidate capability is supported, the candidate configuration should be locked.
：候補能力がサポートされている場合、候補設定をロックする必要があります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</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> operationを使って作成できます。
<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.
チェックポイントファイルを復元するには、<source>と<target>パラメータを元に戻します。
If the :candidate capability is supported, the configuration can be loaded onto the device without impacting the running system.
：候補機能がサポートされている場合は、実行中のシステムに影響を与えずに構成をデバイスにロードできます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
If the device supports the :validate:1.1 capability, it will by default validate the incoming configuration when it is loaded into the candidate. To avoid this validation, pass the <test-option> parameter with the value "set". Full validation can be requested with the <validate> operation.
このデバイスが：Validate：1.1機能をサポートしている場合は、デフォルトで候補にロードされたときに着信設定を検証します。この検証を回避するには、<test-option>パラメータを値 "set"に渡します。完全検証は<validate>操作で要求できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
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 :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.
デバイスが：候補機能をサポートしている場合は、<commit>操作を使用して実行コンフィギュレーションを候補設定に設定します。デバイスへの接続が失敗した場合、元の設定への自動復帰を許可するには、<確認済み>パラメータを使用します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
If the candidate is not supported by the device, the incoming configuration change is loaded directly into running.
候補がデバイスでサポートされていない場合は、着信コンフィギュレーションチェンジが実行中にロードされます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</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 is expected to 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.
<uncoks>操作を使用して設定ロックを解除します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
If the :candidate capability is supported, the candidate configuration should be unlocked.
：候補能力がサポートされている場合、候補設定はロック解除されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
When a configuration change requires updates across a number of devices, care needs to 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.
マルチデバイス操作には2つのクラスがあります。最初のクラスは、すべてのデバイスを元の状態に戻す必要なしに、操作を個々のデバイスで失敗させることができます。操作は後で再試行することも、またはその障害は単にユーザーに報告されます。このクラスの例としては、NTPサーバーを追加している可能性があります。このクラスの操作では、障害回避と回復は個々のデバイスに焦点を合わせます。これはデバイスの回復、失敗を報告し、おそらく別の試みをスケジューリングすることを意味します。
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.
トランザクションセマンティクスを与えるために、上記の単一デバイス操作で使用されているのと同じ手順が使用されますが、すべてのデバイス間で並行して実行されます。構成ロックはすべてのターゲットデバイスで取得され、すべてのデバイスが更新され、変更が永続的になるまで保持されます。構成の変更をアップロードして検証はすべてのデバイスで実行されます。各デバイスでチェックポイントを作成する必要があります。その後、実行設定を変更、テストし、永続的にします。これらの手順のいずれかが失敗した場合、それらが変更された任意のデバイス上で前の設定を復元できます。変更が完全に実装された、または完全に廃棄された後、各デバイスのロックを解除することができます。
This section lists major changes between this document and RFC 4741.
このセクションでは、このドキュメントとRFC 4741の間の主な変更点を示します。
o Added the "malformed-message" error-tag.
o "malformed-message"エラータグを追加しました。
o Added "remove" enumeration value to the "operation" attribute.
o 「operation」属性に「削除」列挙値を追加しました。
o Obsoleted the "partial-operation" error-tag enumeration value.
o 「部分操作」エラータグ列挙値を廃止しました。
o Added <persist> and <persist-id> parameters to the <commit> operation.
o <complet>操作に<persist>と<persist-id>パラメータを追加しました。
o Updated the base protocol URI and clarified the <hello> message exchange to select and identify the base protocol version in use for a particular session.
o ベースプロトコルURIを更新し、特定のセッションに使用されている基本プロトコルのバージョンを選択して識別するために<hello>メッセージ交換を明確にしました。
o Added a YANG module to model the operations and removed the operation layer from the XSD.
o 操作をモデル化し、XSDから操作層を削除するためのYangモジュールを追加しました。
o Clarified lock behavior for the candidate datastore.
o 候補データストアのロック動作が明確になりました。
o Clarified the error response server requirements for the "delete" enumeration value of the "operation" attribute.
o "operation"属性の "delete"列挙値のエラー応答サーバーの要件を明確にしました。
o Added a namespace wildcarding mechanism for subtree filtering.
o サブツリーフィルタリングのためのネームスペースワイルドカードメカニズムを追加しました。
o Added a "test-only" value for the <test-option> parameter to the <edit-config> operation.
o <test-option>パラメータの<edit-config> operationに "test-only"値を追加しました。
o Added a <cancel-commit> operation.
o <cancel-commit>操作を追加しました。
o Introduced a NETCONF username and a requirement for transport protocols to explain how a username is derived.
o ユーザー名がどのように導き出されるかを説明するために、NetConfのユーザー名と転送プロトコルの要件を導入しました。
Authors' Addresses
著者の住所
Rob Enns (editor) Juniper Networks
Rob Enns（編集）ジュニパーネットワークス
EMail: rob.enns@gmail.com
Martin Bjorklund (editor) Tail-f Systems
Martin Bjorklund（編集）Tail-Fシステム
EMail: mbj@tail-f.com
Juergen Schoenwaelder (editor) Jacobs University
Juergen Schoenwaelder（編集）Jacobs University
EMail: j.schoenwaelder@jacobs-university.de
Andy Bierman (editor) Brocade
Andy Bierman（編集）Brocade.
EMail: andy.bierman@brocade.com