NETCONF - ネットワーク構成プロトコル
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
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）は、ネットワークデバイスの構成をインストール、操作、および削除するメカニズムを提供します。 これは、構成データとプロトコルメッセージにExtensible Markup Language（XML）ベースのデータエンコーディングを使用します。 NETCONFプロトコル操作は、リモートプロシージャコール（RPC）として実現されます。 このドキュメントはRFC 4741を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、Internet Engineering Task Force（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で入手できます。
Enns, et al. Standards Track [Page 1] RFC 6241 NETCONF Protocol June 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。 全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Enns, et al. Standards Track [Page 2]
RFC 6241 NETCONF Protocol June 2011
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
Enns, et al. Standards Track [Page 3]
RFC 6241 NETCONF Protocol June 2011
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
Enns, et al. Standards Track [Page 4]
RFC 6241 NETCONF Protocol June 2011
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
1.はじめに. . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.用語. . . . . . . . . . . . . . . . . . . . . . . 7
1.2.プロトコル概要. . . . . . . . . . . . . . . . . . . . 8
1.3.能力. . . . . . . . . . . . . . . . . . . . . 10
1.4.構成と状態データの分離. . . . . . . 10
2.トランスポートプロトコルの要件. . . . . . . . . . . . . . . 11
2.1.接続指向の操作. . . . . . . . . . . . . . 11
2.2.認証、整合性、機密性. . . . . 12
2.3.必須トランスポートプロトコル. . . . . . . . . . . . . . 12
3. XMLに関する考慮事項. . . . . . . . . . . . . . . . . . . . . 13
3.1.名前空間. . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.ドキュメントタイプ宣言. . . . . . . . . . . . . . . 13
4. RPCモデル. . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. <rpc>要素. . . . . . . . . . . . . . . . . . . . . . 13
4.2. <rpc-reply>要素. . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error>要素. . . . . . . . . . . . . . . . . . . 16
4.4. <ok>要素. . . . . . . . . . . . . . . . . . . . . . 19
4.5.パイプライン処理. . . . . . . . . . . . . . . . . . . . . . . 19
5.構成モデル. . . . . . . . . . . . . . . . . . . . . 19
5.1.設定データストア. . . . . . . . . . . . . . . . 19
5.2.データモデリング. . . . . . . . . . . . . . . . . . . . . . 20
6.サブツリーフィルタリング. . . . . . . . . . . . . . . . . . . . . . 20
6.1.概要. . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.サブツリーフィルターコンポーネント. . . . . . . . . . . . . . . . 21
6.2.1.名前空間の選択. . . . . . . . . . . . . . . . . 21
6.2.2.属性一致式. . . . . . . . . . . . . 22
6.2.3.封じ込めノード. . . . . . . . . . . . . . . . . . 23
6.2.4.選択ノード. . . . . . . . . . . . . . . . . . . 23
6.2.5.コンテンツ一致ノード. . . . . . . . . . . . . . . . . 24
6.3.サブツリーフィルター処理. . . . . . . . . . . . . . . . 25
6.4.サブツリーフィルタリング例. . . . . . . . . . . . . . . 26日
6.4.1.フィルターなし. . . . . . . . . . . . . . . . . . . . . . 26日
6.4.2.空のフィルター. . . . . . . . . . . . . . . . . . . . 26日
6.4.3. <users>サブツリー全体を選択します. . . . . . . . . . 27日
6.4.4. <users>内のすべての<name>要素を選択します
サブツリー. . . . . . . . . . . . . . . . . . . . . . . 29日
6.4.5. 1つの特定の<user>エントリ. . . . . . . . . . . . . . 30
6.4.6.特定の<user>エントリの特定の要素. . . 31
6.4.7.複数のサブツリー. . . . . . . . . . . . . . . . . . 32
6.4.8.属性の名前付けを持つ要素. . . . . . . . . . . 33
7.プロトコル操作. . . . . . . . . . . . . . . . . . . . . 35
7.1. <get-config>. . . . . . . . . . . . . . . . . . . . . . 35
7.2. <edit-config>. . . . . . . . . . . . . . . . . . . . . . 37
7.3. <copy-config>. . . . . . . . . . . . . . . . . . . . . . 43
7.4. <delete-config>. . . . . . . . . . . . . . . . . . . . . 44
7.5. <ロック>. . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6 <ロック解除>. . . . . . . . . . . . . . . . . . . . . . . . 47
7.7. <get>. . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. <close-session>. . . . . . . . . . . . . . . . . . . . . 49
7.9. <kill-session>. . . . . . . . . . . . . . . . . . . . . 50
8.機能. . . . . . . . . . . . . . . . . . . . . . . . 51
8.1.能力交換. . . . . . . . . . . . . . . . . . 51
8.2.書き込み可能な実行機能. . . . . . . . . . . . . . . 53
8.2.1.説明. . . . . . . . . . . . . . . . . . . . . 53
8.2.2.依存関係. . . . . . . . . . . . . . . . . . . . 53
8.2.3.能力識別子. . . . . . . . . . . . . . . . 53
8.2.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 53
8.2.5.既存のオペレーションの変更. . . . . . . . 53
8.3.候補構成機能. . . . . . . . . . . 53
8.3.1.説明. . . . . . . . . . . . . . . . . . . . . 53
8.3.2.依存関係. . . . . . . . . . . . . . . . . . . . 54
8.3.3.能力識別子. . . . . . . . . . . . . . . . 54
8.3.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 54
8.3.5.既存のオペレーションの変更. . . . . . . . 56
8.4.確認済みのコミット機能. . . . . . . . . . . . . . . 57
8.4.1.説明. . . . . . . . . . . . . . . . . . . . . 57
8.4.2.依存関係. . . . . . . . . . . . . . . . . . . . 58
8.4.3.能力識別子. . . . . . . . . . . . . . . . 58
8.4.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 59
8.4.5.既存のオペレーションの変更. . . . . . . . 60
8.5.エラー時のロールバック機能. . . . . . . . . . . . . . 61
8.5.1.説明. . . . . . . . . . . . . . . . . . . . . 61
8.5.2.依存関係. . . . . . . . . . . . . . . . . . . . 62
8.5.3.能力識別子. . . . . . . . . . . . . . . . 62
8.5.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 62
8.5.5.既存のオペレーションの変更. . . . . . . . 62
8.6機能を検証します. . . . . . . . . . . . . . . . . . . 63
8.6.1.説明. . . . . . . . . . . . . . . . . . . . . 63
8.6.2.依存関係. . . . . . . . . . . . . . . . . . . . 63
8.6.3.能力識別子. . . . . . . . . . . . . . . . 63
8.6.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 63
8.6.5.既存のオペレーションの変更. . . . . . . . 64
8.7.明確なスタートアップ機能. . . . . . . . . . . . . . . 64
8.7.1.説明. . . . . . . . . . . . . . . . . . . . . 64
8.7.2.依存関係. . . . . . . . . . . . . . . . . . . . 65
8.7.3.能力識別子. . . . . . . . . . . . . . . . 65
8.7.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 65
8.7.5.既存のオペレーションの変更. . . . . . . . 65
8.8. URL機能. . . . . . . . . . . . . . . . . . . . . 66
8.8.1.説明. . . . . . . . . . . . . . . . . . . . . 66
8.8.2.依存関係. . . . . . . . . . . . . . . . . . . . 66
8.8.3.能力識別子. . . . . . . . . . . . . . . . 66
8.8.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 66
8.8.5.既存のオペレーションの変更. . . . . . . . 66
8.9. XPath機能. . . . . . . . . . . . . . . . . . . . 67
8.9.1.説明. . . . . . . . . . . . . . . . . . . . . 67
8.9.2.依存関係. . . . . . . . . . . . . . . . . . . . 68
8.9.3.能力識別子. . . . . . . . . . . . . . . . 68
8.9.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 68
8.9.5.既存のオペレーションの変更. . . . . . . . 68
9.セキュリティに関する考慮事項. . . . . . . . . . . . . . . . . . . 69
10. IANAの考慮事項. . . . . . . . . . . . . . . . . . . . . 71
10.1 NETCONF XML名前空間. . . . . . . . . . . . . . . . . . 71
10.2 NETCONF XMLスキーマ. . . . . . . . . . . . . . . . . . . 71
10.3. NETCONF YANGモジュール. . . . . . . . . . . . . . . . . . . 72
10.4. NETCONF機能のURN. . . . . . . . . . . . . . . . . 72
11.寄稿者. . . . . . . . . . . . . . . . . . . . . . . . 73
12.謝辞. . . . . . . . . . . . . . . . . . . . . . 73
13.参考文献. . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1.規範的な参照. . . . . . . . . . . . . . . . . . 74
13.2.有益な参照. . . . . . . . . . . . . . . . . 75
付録A. NETCONFエラーリスト. . . . . . . . . . . . . . . . . 76
付録B. NETCONFメッセージ層のXMLスキーマ. . . . . . . 80
付録C. NETCONFプロトコル操作用のYANGモジュール. . . . 85
付録D.機能テンプレート. . . . . . . . . . . . . . . . 105
D.1.機能名（テンプレート）. . . . . . . . . . . . . . . 105
D.1.1.概要. . . . . . . . . . . . . . . . . . . . . . 105
D.1.2.依存関係. . . . . . . . . . . . . . . . . . . . 105
D.1.3.能力識別子. . . . . . . . . . . . . . . . 105
D.1.4.新しいオペレーション. . . . . . . . . . . . . . . . . . . 105
D.1.5.既存のオペレーションの変更. . . . . . . . 105
D.1.6.他の機能との相互作用. . . . . . . . 105
付録E. NETCONFを使用した複数のデバイスの構成. . . . . 106
E.1.個々のデバイスでの操作. . . . . . . . . . . . 106
E.1.1.構成ロックの取得. . . . . . . . . . 106
E.1.2.実行構成のチェックポイント. . . . . . . 107
E.1.3.着信構成のロードと検証. . 108
E.1.4.実行構成の変更. . . . . . . . 108
E.1.5.新しい構成のテスト. . . . . . . . . . . . 109
E.1.6.変更を永続的にします. . . . . . . . . . . . . 109
E.1.7.設定ロックの解除. . . . . . . . . . 110
E.2.複数のデバイスでの操作. . . . . . . . . . . . . 111
付録F. RFC 4741からの変更. . . . . . . . . . . . . . . 112
Enns, et al. Standards Track [Page 5] RFC 6241 NETCONF Protocol June 2011 1. Introduction
1.はじめに
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）パラダイムを使用します。 クライアントはRPCをXML [W3C.REC-xml-20001006]にエンコードし、安全な接続指向のセッションを使用してサーバーに送信します。 サーバーは、XMLでエンコードされた応答で応答します。 要求と応答の両方の内容は、XML DTDまたはXMLスキーマ、あるいはその両方で完全に記述されているため、両当事者は、交換に課せられた構文制約を認識できます。
A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native functionality of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface.
NETCONFの重要な側面は、管理プロトコルの機能がデバイスのネイティブ機能を厳密に反映できるようにすることです。 これにより、実装コストが削減され、新機能へのタイムリーなアクセスが可能になります。 さらに、アプリケーションはデバイスのネイティブユーザーインターフェイスの構文と意味の両方のコンテンツにアクセスできます。
NETCONF allows a client to discover the set of protocol extensions supported by a server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. Standard and non-standard capabilities can be defined with semantic and syntactic rigor. Capabilities are discussed in Section 8.
NETCONFにより、クライアントはサーバーでサポートされているプロトコル拡張機能のセットを検出できます。 これらの「機能」により、クライアントはその動作を調整して、デバイスによって公開されている機能を利用できます。 機能定義は、非集中的な方法で簡単に拡張できます。 標準および非標準の機能は、意味論的および構文上の厳密さで定義できます。 機能については、セクション8で説明します。
The NETCONF protocol is a building block in a system of automated configuration. XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XML-based transformation technologies, such as XSLT [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はインターチェンジの共通語であり、柔軟であるが完全に指定された階層化コンテンツのエンコーディングメカニズムを提供します。 NETCONFは、XSLT [W3C.REC-xslt-19991116]などのXMLベースの変換テクノロジーと組み合わせて使用して、完全な構成と部分的な構成を自動生成するシステムを提供できます。 システムは、ネットワークトポロジ、リンク、ポリシー、顧客、およびサービスに関するデータを1つ以上のデータベースに照会できます。 このデータは、1つ以上のXSLTスクリプトを使用して、タスク指向でベンダーに依存しないデータスキーマから、ベンダー、製品、オペレーティングシステム、およびソフトウェアリリースに固有の形式に変換できます。 結果のデータは、NETCONFプロトコルを使用してデバイスに渡すことができます。
Enns, et al. Standards Track [Page 6] RFC 6241 NETCONF Protocol June 2011 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]で説明されているように解釈されます。
1.1. Terminology
1.1。 用語
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 capability: A functionality that supplements the base NETCONF
specification.
機能：基本NETCONF仕様を補足する機能。
o client: Invokes protocol operations on a server. In addition, a
client can subscribe to receive notifications from a server.
client：サーバーでプロトコル操作を呼び出します。 さらに、クライアントはサーバーから通知を受け取るためにサブスクライブできます。
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 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 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 message: A protocol element sent over a session. Messages are
well-formed XML documents.
メッセージ：セッションを介して送信されるプロトコル要素。 メッセージは整形式のXMLドキュメントです。
o notification: A server-initiated message indicating that a certain
event has been recognized by the server.
notification：特定のイベントがサーバーによって認識されたことを示すサーバー起動メッセージ。
o protocol operation: A specific remote procedure call, as used
within the NETCONF protocol.
プロトコル操作：NETCONFプロトコル内で使用される特定のリモートプロシージャコール。
o remote procedure call (RPC): Realized by exchanging <rpc> and
<rpc-reply> messages.
リモートプロシージャコール（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 server: Executes protocol operations invoked by a client. In
addition, a server can send notifications to a client.
server：クライアントによって呼び出されたプロトコル操作を実行します。 さらに、サーバーはクライアントに通知を送信できます。
Enns, et al. Standards Track [Page 7]
RFC 6241 NETCONF Protocol June 2011
o session: Client and server exchange messages using a secure,
connection-oriented session.
セッション：クライアントとサーバーは、安全な接続指向のセッションを使用してメッセージを交換します。
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 state data: The additional data on a system that is not
configuration data such as read-only status information and
collected statistics.
状態データ：読み取り専用のステータス情報や収集された統計など、構成データではないシステム上の追加データ。
o user: The authenticated identity of the client. The authenticated
identity of a client is commonly referred to as the NETCONF
username.
user：クライアントの認証済みID。 クライアントの認証済みIDは、一般にNETCONFユーザー名と呼ばれます。
1.2. Protocol Overview
1.2。 プロトコルの概要
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セッションをサポートする必要があり、複数のセッションをサポートする必要があります（SHOULD）。 グローバル構成属性は、許可されたセッション中に変更でき、その影響はすべてのセッションで確認できます。 セッション固有の属性は、変更されたセッションにのみ影響します。
NETCONF can be conceptually partitioned into four layers as shown in Figure 1.
図1に示すように、NETCONFは概念的に4つの層に分割できます。
Enns, et al. Standards Track [Page 8]
RFC 6241 NETCONF Protocol June 2011
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) 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.
Secure Transportレイヤーは、クライアントとサーバー間の通信パスを提供します。 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.
メッセージ層は、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.
Operationsレイヤーは、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.
コンテンツ層はこのドキュメントの範囲外です。 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のオペレーションレイヤーとコンテンツレイヤーをカバーしています。
Enns, et al. Standards Track [Page 9] RFC 6241 NETCONF Protocol June 2011 1.3. Capabilities
1.3。 能力
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仕様を補足する一連の機能です。 機能はUniform Resource Identifier（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では、クライアントがサーバーの機能を検出できるようにする機能交換を定義します。 セクション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は、ネーミングの衝突を回避するためにネーミングオーソリティを十分に区別する必要があります。
1.4. Separation of Configuration and State Data
1.4。 構成と状態データの分離
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 Incoming data could contain nonsensical requests, such as attempts
to write read-only data.
受信データには、読み取り専用データを書き込もうとするなど、無意味な要求が含まれる場合があります。
o The data sets would be large.
データセットは大きくなります。
o Archived data could contain values for read-only data items,
complicating the processing required to restore archived data.
アーカイブデータには、読み取り専用データアイテムの値が含まれる可能性があり、アーカイブデータの復元に必要な処理が複雑になります。
Enns, et al. Standards Track [Page 10] RFC 6241 NETCONF Protocol June 2011 To account for these issues, the NETCONF protocol recognizes the difference between configuration data and state data and provides operations for each. The <get-config> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data.
これらの問題を説明するために、NETCONFプロトコルは構成データと状態データの違いを認識し、それぞれに操作を提供します。 <get-config>操作は構成データのみを取得し、<get>操作は構成および状態データを取得します。
Note that the NETCONF protocol is focused on the information required to get the device into its desired running state. The inclusion of other important, persistent data is implementation specific. For example, user files and databases are not treated as configuration data by the NETCONF protocol.
NETCONFプロトコルは、デバイスを望ましい実行状態にするために必要な情報に焦点を合わせていることに注意してください。 他の重要で永続的なデータを含めることは実装固有です。 たとえば、ユーザーファイルとデータベースは、NETCONFプロトコルでは構成データとして扱われません。
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.
たとえば、ユーザー認証データのローカルデータベースがデバイスに保存されている場合、それが構成データに含まれているかどうかは実装に依存します。
2. Transport Protocol Requirements
2.トランスポートプロトコルの要件
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に必要な特性について詳しく説明します。
2.1. Connection-Oriented Operation
2.1。 接続指向の操作
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.
さらに、特定の接続のためにサーバーから要求されたリソースは、接続が閉じたときに自動的に解放される必要があり、障害回復がよりシンプルで堅牢になります。 たとえば、クライアントがロックを取得した場合、そのロックは明示的に解放されるか、サーバーが接続が終了したと判断するまで保持されます。 クライアントがロックを保持している間に接続が終了した場合、サーバーは適切な回復を実行できます。 <lock>操作については、セクション7.5で詳しく説明します。
Enns, et al. Standards Track [Page 11] RFC 6241 NETCONF Protocol June 2011 2.2. Authentication, Integrity, and Confidentiality
2.2。 認証、完全性、機密性
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]またはセキュアシェル（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ピアは、十分に信頼できるメカニズムを使用して、基礎となるトランスポートプロトコルによって接続の認証情報が検証され、ピアのIDが十分に証明されていることを前提としています。
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は、一般に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セッション中に適用する必要があります。 アクセス制御の構成方法の詳細は、このドキュメントの範囲外です。
2.3. Mandatory Transport Protocol
2.3。 必須の転送プロトコル
A NETCONF implementation MUST support the SSH transport protocol mapping [RFC6242].
NETCONF実装は、SSHトランスポートプロトコルマッピング[RFC6242]をサポートする必要があります。
Enns, et al. Standards Track [Page 12] RFC 6241 NETCONF Protocol June 2011 3. XML Considerations
3. XMLに関する考慮事項
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>メッセージを受信した場合、「malformed-message」エラーで応答する必要があります（SHOULD）。 何らかの理由で応答を送信できない場合、サーバーはセッションを終了する必要があります。
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関連の考慮事項について説明します。
3.1. Namespace
3.1。 名前空間
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で説明します。
3.2. Document Type Declarations
3.2。 文書型宣言
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コンテンツに表示してはならない（MUST NOT）。
4. RPC Model
4. RPCモデル
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スキーマで正式に定義されています。
4.1. <rpc> Element
4.1。 <rpc>要素
The <rpc> element is used to enclose a NETCONF request sent from the client to the server.
<rpc>要素は、クライアントからサーバーに送信されるNETCONF要求を囲むために使用されます。
Enns, et al. Standards Track [Page 13] RFC 6241 NETCONF Protocol June 2011 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>メッセージの「メッセージ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-own-method>というメソッドを呼び出します。このメソッドには、2つのパラメーター<my-first-parameter>の値が "14"で、<another-parameter>の値が "fred"です。 ：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<my-own-method xmlns="http://example.net/me/my-own/1.0">
<my-first-parameter>14</my-first-parameter>
<another-parameter>fred</another-parameter>
</my-own-method>
</rpc>
The following example invokes a <rock-the-house> method with a
<zip-code> parameter of "27606-0100":
次の例では、「27606-0100」の<zip-code>パラメータを使用して<rock-the-house>メソッドを呼び出します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
Enns, et al. Standards Track [Page 14]
RFC 6241 NETCONF Protocol June 2011
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>
4.2. <rpc-reply> Element
4.2。 <rpc-reply>要素
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-reply>要素で変更されていない<rpc>要素に含まれる追加の属性も返す必要があります。
The response data is encoded as one or more child elements to the <rpc-reply> element.
応答データは、<rpc-reply>要素の1つ以上の子要素としてエンコードされます。
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>
Enns, et al. Standards Track [Page 15]
RFC 6241 NETCONF Protocol June 2011
4.3. <rpc-error> Element
4.3。 <rpc-error>要素
The <rpc-error> element is sent in <rpc-reply> messages if an error occurs during the processing of an <rpc> request.
<rpc-error>要素は、<rpc>要求の処理中にエラーが発生した場合に<rpc-reply>メッセージで送信されます。
If a server encounters multiple errors during the processing of an <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error> elements. However, a server is not required to detect or report more than one <rpc-error> element, if a request contains multiple errors. A server is not required to check for particular error conditions in a specific sequence. A server MUST return an <rpc-error> element if any error conditions occur during processing.
サーバーが<rpc>リクエストの処理中に複数のエラーを検出した場合、<rpc-reply>には複数の<rpc-error>要素が含まれる場合があります。 ただし、リクエストに複数のエラーが含まれている場合、サーバーは複数の<rpc-error>要素を検出または報告する必要はありません。 サーバーは、特定のシーケンスで特定のエラー状態をチェックする必要はありません。 処理中にエラー条件が発生した場合、サーバーは<rpc-error>要素を返さなければなりません（MUST）。
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>要素でアプリケーションレベルまたはデータモデル固有のエラー情報を返してはなりません（MUST NOT）。
The <rpc-error> element includes the following information:
<rpc-error>要素には、次の情報が含まれています。
error-type: Defines the conceptual layer that the error occurred.
error-type：エラーが発生した概念レイヤーを定義します。
Enumeration. One of:
* transport (layer: Secure Transport)
* rpc (layer: Messages)
* 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
Enns, et al. Standards Track [Page 16]
RFC 6241 NETCONF Protocol June 2011
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：データモデル固有または実装固有のエラー条件が存在する場合は、それを識別する文字列が含まれます。 この要素は、適切なアプリケーションエラータグを特定のエラー条件に関連付けることができない場合は存在しません。 データモデル固有と実装固有のエラーアプリタグの両方が存在する場合、サーバーはデータモデル固有の値を使用する必要があります。
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：特定の<rpc-error>要素で報告されているエラーに関連付けられているノードへの要素パスを識別する絶対XPath [W3C.REC-xpath-19991116]式が含まれています。 この要素は、適切なペイロード要素またはデータストアノードを特定のエラー条件に関連付けることができない場合は存在しません。
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].
error-message：エラー状態を説明する人間の表示に適した文字列が含まれています。 特定のエラー条件に対して適切なメッセージが提供されない場合、この要素は存在しません。 この要素には、[W3C.REC-xml-20001006]で定義され、[RFC3470]で説明されている「xml：lang」属性を含める必要があります（SHOULD）。
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エラーを列挙しています。
Enns, et al. Standards Track [Page 17]
RFC 6241 NETCONF Protocol June 2011
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.
例：「message-id」属性なしで<rpc>要素を受信すると、エラーが返されます。 この場合にのみ、NETCONFピアが<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>
Enns, et al. Standards Track [Page 18]
RFC 6241 NETCONF Protocol June 2011
<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>
4.4. <ok> Element
4.4。 <ok>要素
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>
4.5. Pipelining
4.5。 パイプライン
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>リクエストは、前のリクエストが完了する前に送信される場合があります。 管理対象デバイスは、要求が受信された順序でのみ応答を送信する必要があります。
5. Configuration Model
5.構成モデル
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で説明されているように、セッションが開始されたときにデバイス機能を交換します。
5.1. Configuration Datastores
5.1。 構成データストア
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つ以上の構成データストアの存在を定義し、それらに対する構成操作を許可します。 構成データストアは、デバイスを初期のデフォルト状態から目的の動作状態にするために必要な構成データの完全なセットとして定義されます。 構成データストアには、状態データや実行コマンドは含まれていません。
Enns, et al. Standards Track [Page 19] RFC 6241 NETCONF Protocol June 2011 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.
基本モデルには<running>構成データストアのみが存在します。 追加の構成データストアは、機能によって定義される場合があります。 このような構成データストアは、機能をアドバタイズするデバイスでのみ使用できます。
The capabilities in Sections 8.3 and 8.7 define the <candidate> and <startup> configuration datastores, respectively.
セクション8.3および8.7の機能は、それぞれ<candidate>および<startup>構成データストアを定義します。
5.2. Data Modeling
5.2。 データモデリング
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.
デバイスとマネージャは、標準データモデルと専用データモデルの両方を含む複数のデータモデルをサポートできます。
6. Subtree Filtering
6.サブツリーフィルタリング
6.1. Overview
6.1。 概観
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サブツリーフィルタリングは、アプリケーションが特定のXMLサブツリーを選択して、<get>または<get-config>操作の<rpc-reply>に含めることを可能にするメカニズムです。 包含、単純なコンテンツの完全一致、および選択のための少数のフィルターセットが提供されます。これにより、いくつかの有用な、しかし非常に限定された選択メカニズムが可能になります。 サーバーは、処理中にデータモデル固有のセマンティクスを利用する必要がないため、シンプルで一元化された実装戦略が可能になります。
Enns, et al. Standards Track [Page 20] RFC 6241 NETCONF Protocol June 2011 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.
応答メッセージには、フィルターによって選択されたサブツリーのみが含まれます。 特定の選択されたサブツリー内の要求に存在していた選択基準も、応答に含まれます。 フィルターでリーフノードとして表現されている一部の要素は、フィルター出力で展開されます（つまり、サブツリーが含まれます）。 同じデータを選択する複数のフィルターサブツリー式がリクエストに含まれている場合、特定のデータインスタンスはレスポンスで複製されません。
6.2. Subtree Filter Components
6.2。 サブツリーフィルターコンポーネント
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 Attribute Match Expressions
属性一致式
o Containment Nodes
封じ込めノード
o Selection Nodes
選択ノード
o Content Match Nodes
コンテンツ一致ノード
6.2.1. Namespace Selection
6.2.1。 名前空間の選択
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つのエレメントを指定する必要があります。
Enns, et al. Standards Track [Page 21] RFC 6241 NETCONF Protocol June 2011 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」名前空間のこのノードと、（基礎となるデータモデルの）子ノードのみが含まれます フィルター出力。
6.2.2. Attribute Match Expressions
6.2.2。 属性一致式
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"は属性一致式です。 「http://example.com/schema/1.2/config」名前空間の「インターフェース」ノードで、「ifName」属性の値が「eth0」で、「トップ」ノードの「インターフェース」ノード内にあるもののみが フィルター出力に含まれています。
Enns, et al. Standards Track [Page 22] RFC 6241 NETCONF Protocol June 2011 6.2.3. Containment Nodes
6.2.3。 封じ込めノード
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>要素は包含ノードです。
6.2.4. Selection Nodes
6.2.4。 選択ノード
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>要素は選択ノードです。 「http://example.com/schema/1.2/config」名前空間の「users」ノードのみが、構成データストアのルートである<top>要素内で発生し、フィルター出力に含まれます。
Enns, et al. Standards Track [Page 23] RFC 6241 NETCONF Protocol June 2011 6.2.5. Content Match Nodes
6.2.5。 コンテンツ一致ノード
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 Multiple content match nodes (i.e., sibling nodes) are logically
combined in an "AND" expression.
複数のコンテンツ一致ノード（つまり、兄弟ノード）は、「AND」式で論理的に結合されます。
o Filtering of mixed content is not supported.
混合コンテンツのフィルタリングはサポートされていません。
o Filtering of list content is not supported.
リストコンテンツのフィルタリングはサポートされていません。
o Filtering of whitespace-only content is not supported.
空白のみのコンテンツのフィルタリングはサポートされていません。
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/>).
コンテンツ一致ノードには、空白以外の文字を含める必要があります。 空の要素（<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.
先頭と末尾の空白文字は無視されますが、テキスト文字のブロック内の空白文字は無視または変更されません。
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 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 If any selection nodes are present in the sibling set, then all of
them are included in the filter output.
兄弟セットに選択ノードが存在する場合、それらすべてがフィルター出力に含まれます。
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.
選択ノードの兄弟ノードが概念的なデータ構造のインスタンス識別子コンポーネント（リストキーリーフなど）である場合、それらもフィルター出力に含めることができます（MAY）。
Enns, et al. Standards Track [Page 24]
RFC 6241 NETCONF Protocol June 2011
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.
それ以外の場合（つまり、フィルター兄弟セットに選択ノードまたは包含ノードがない場合）、基礎となるデータモデル（およびサブツリー（ある場合））のこのレベルで定義されたすべてのノードがフィルター出力に返されます。
If any of the sibling content match node tests are "false", then no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match node(s).
兄弟コンテンツ一致ノードテストのいずれかが「false」の場合、その兄弟セットに対してそれ以上のフィルター処理は実行されず、コンテンツ一致ノードを含む兄弟サブツリーはフィルターによって選択されません。
Example:
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
In this example, the <users> and <user> nodes are both containment
nodes, and <name> is a content match node. Since no sibling nodes of
<name> are specified (and therefore no containment or selection
nodes), all of the sibling nodes of <name> are returned in the filter
output. Only "user" nodes in the
"http://example.com/schema/1.2/config" namespace that match the
element hierarchy and for which the <name> element is equal to "fred"
will be included in the filter output.
この例では、<users>ノードと<user>ノードはどちらも包含ノードであり、<name>はコンテンツ一致ノードです。 <name>の兄弟ノードが指定されていない（したがって包含ノードも選択ノードもない）ため、<name>のすべての兄弟ノードがフィルター出力に返されます。 「http://example.com/schema/1.2/config」名前空間の「user」ノードだけがエレメント階層に一致し、<name>エレメントが「fred」に等しい場合のみ、フィルター出力に含まれます。
6.3. Subtree Filter Processing
6.3。 サブツリーフィルター処理
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 Enns, et al. Standards Track [Page 25] RFC 6241 NETCONF Protocol June 2011 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.
サーバーは、兄弟セットごとに、フィルター出力に含まれる（または含まれる可能性のある）ノード、およびフィルター出力から除外（プルーニング）された兄弟サブツリーを判別します。 サーバーは、最初に兄弟セットに存在するノードのタイプを判別し、それらのタイプのルールに従ってノードを処理します。 兄弟セットのノードが選択されている場合、プロセスは選択された各ノードの兄弟セットに再帰的に適用されます。 アルゴリズムは、フィルターで指定されたすべてのサブツリーのすべての兄弟セットが処理されるまで続きます。
6.4. Subtree Filtering Examples
6.4。 サブツリーフィルタリングの例
6.4.1. No Filter
6.4.1。 フィルターなし
Leaving out the filter on the <get> operation returns the entire data model.
<get>操作でフィルターを除外すると、データモデル全体が返されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<!-- ... entire set of data returned ... -->
</data>
</rpc-reply>
6.4.2. Empty Filter
6.4.2。 空のフィルター
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>
Enns, et al. Standards Track [Page 26]
RFC 6241 NETCONF Protocol June 2011
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
</data>
</rpc-reply>
6.4.3. Select the Entire <users> Subtree
6.4.3。 <users>サブツリー全体を選択します
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>）が含まれているため、フィルターによってそのサブツリーのみが選択されます。 この例は、以下のほとんどのフィルターの例で完全に入力された<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>
Enns, et al. Standards Track [Page 27]
RFC 6241 NETCONF Protocol June 2011
<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つの子要素（<user>）を定義しているためです。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
Enns, et al. Standards Track [Page 28]
RFC 6241 NETCONF Protocol June 2011
6.4.4. Select All <name> Elements within the <users> Subtree
6.4.4。 <users>サブツリー内のすべての<name>要素を選択
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>、<user>）と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>
Enns, et al. Standards Track [Page 29]
RFC 6241 NETCONF Protocol June 2011
6.4.5. One Specific <user> Entry
6.4.5。 1つの特定の<user>エントリ
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>、<user>）と1つのコンテンツ一致ノード（<name>）が含まれています。 <name>の値が「fred」に等しい<name>を含む兄弟セットのすべてのインスタンスがフィルター出力で選択されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
Enns, et al. Standards Track [Page 30]
RFC 6241 NETCONF Protocol June 2011
6.4.6. Specific Elements from a Specific <user> Entry
6.4.6。 特定の<user>エントリの特定の要素
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>、<user>）、1つのコンテンツ一致ノード（<name>）、および2つの選択ノード（<type>、<full-name>）が含まれています。 <name>の値が「fred」に等しい<name>を含む同じ兄弟セット内の<type>および<full-name>要素のすべてのインスタンスがフィルター出力で選択されます。 兄弟セットには選択ノードが含まれているため、<company-info>要素は含まれていません。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type/>
<full-name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
</user>
</users>
</top>
</data>
</rpc-reply>
Enns, et al. Standards Track [Page 31]
RFC 6241 NETCONF Protocol June 2011
6.4.7. Multiple Subtrees
6.4.7。 複数のサブツリー
This filter contains three subtrees (name=root, fred, barney).
このフィルターには、3つのサブツリー（name = root、fred、barney）が含まれています。
The "root" subtree filter contains two containment nodes (<users>, <user>), one content match node (<name>), and one 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つのコンテンツ一致ノード（<name>）、および1つの選択ノード（<company-info>）が含まれています。 サブツリー選択基準が満たされ、「root」の会社情報サブツリーのみがフィルター出力で選択されます。
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"のcompany-infoサブツリー内の<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>
Enns, et al. Standards Track [Page 32]
RFC 6241 NETCONF Protocol June 2011
</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>
6.4.8. Elements with Attribute Naming
6.4.8。 属性の名前が付けられた要素
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つの包含ノード（<interfaces>）、1つの属性一致式（ "ifName"）、および1つの選択ノード（<interface>）が含まれています。 「ifName」属性が「eth0」に等しい<interface>サブツリーのすべてのインスタンスがフィルター出力で選択されます。 「ifName」属性が修飾されていない場合、「schema / 1.2」名前空間の一部とは見なされないため、フィルターデータ要素と属性は修飾されます。
Enns, et al. Standards Track [Page 33]
RFC 6241 NETCONF Protocol June 2011
<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>
Enns, et al. Standards Track [Page 34]
RFC 6241 NETCONF Protocol June 2011
7. Protocol Operations
7.プロトコル操作
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 get-config o edit-config o copy-config o delete-config o lock o unlock o close-session o kill-session 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応答の戻り値は、エラー応答をチェックする必要があります（SHOULD）。
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モジュールで正式に定義されています。 次のセクションでは、各プロトコル操作のセマンティクスについて説明します。
7.1. <get-config>
7.1。 <get-config>
Description: Retrieve all or part of a specified configuration
datastore.
説明：指定した構成データストアのすべてまたは一部を取得します。
Parameters:
source: Name of the configuration datastore being queried, such
as <running/>.
source: Name of the configuration datastore being queried, such as <running/>.
Enns, et al. Standards Track [Page 35]
RFC 6241 NETCONF Protocol June 2011
filter: This parameter identifies the portions of the device
configuration datastore to retrieve. If this parameter is not
present, the entire configuration is returned.
filter：このパラメーターは、取得するデバイス構成データストアの部分を識別します。 このパラメーターが存在しない場合は、構成全体が返されます。
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）、値「xpath」を使用して、<filter>要素の「select」属性にXPath式が含まれていることを示すことができます（MAY）。
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>
Enns, et al. Standards Track [Page 36]
RFC 6241 NETCONF Protocol June 2011
<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には、サブツリーフィルタリングの追加の例が含まれています。
7.2. <edit-config>
7.2。 <編集構成>
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.
<edit-config>操作は、指定された構成のすべてまたは一部を指定されたターゲット構成データストアにロードします。 この操作により、ローカルファイル、リモートファイル、インラインなど、いくつかの方法で新しい構成を表現できます。 ターゲット構成データストアが存在しない場合は、作成されます。
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).
<edit-config>操作に、基礎となるデータモデルの同じ概念ノードに適用される複数のサブ操作が含まれている場合、操作の結果は未定義です（つまり、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.
operation：<config>サブツリーの要素には、「操作」属性が含まれる場合があります。これは、セクション3.1で定義されたNETCONF名前空間に属しています。 属性は、操作を実行する構成内のポイントを識別し、<config>サブツリー全体の複数の要素に表示される場合があります。
If the "operation" attribute is not specified, the
configuration is merged into the configuration datastore.
「operation」属性が指定されていない場合、構成は構成データストアにマージされます。
Enns, et al. Standards Track [Page 37]
RFC 6241 NETCONF Protocol June 2011
The "operation" attribute has one of the following values:
「操作」属性には、次のいずれかの値があります。
merge: The configuration data identified by the element
containing this attribute is merged with the configuration
at the corresponding level in the configuration datastore
identified by the <target> parameter. This is the default
behavior.
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.
replace：この属性を含む要素によって識別される構成データは、<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".
create：この属性を含む要素によって識別される構成データは、構成データストアに構成データがまだ存在しない場合にのみ、構成に追加されます。 構成データが存在する場合、<error-tag>値が "data-exists"の<rpc-error>要素が返されます。
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".
削除：この属性を含む要素によって識別される構成データは、構成データが構成データストアに現在存在する場合にのみ、構成から削除されます。 構成データが存在しない場合、<error-tag>値が "data-missing"の<rpc-error>要素が返されます。
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.
削除：この属性を含む要素によって識別される構成データは、構成データストアに構成データが現在存在する場合、構成から削除されます。 構成データが存在しない場合、「削除」操作はサーバーによって暗黙的に無視されます。
Parameters:
target: Name of the configuration datastore being edited, such as
<running/> or <candidate/>.
target：<running />や<candidate />など、編集中の構成データストアの名前。
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：この<edit-config>リクエストのデフォルトのオペレーション（「operation」属性で説明）を選択します。 <default-operation>パラメータのデフォルト値は「merge」です。
Enns, et al. Standards Track [Page 38]
RFC 6241 NETCONF Protocol June 2011
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.
merge：<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.
replace：<config>パラメータの構成データは、ターゲットデータストアの構成を完全に置き換えます。 これは、以前に保存した構成データをロードするのに役立ちます。
none: The target datastore is unaffected by the configuration
in the <config> parameter, unless and until the incoming
configuration data uses the "operation" attribute to request
a different operation. If the configuration in the <config>
parameter contains data for which there is not a
corresponding level in the target datastore, an <rpc-error>
is returned with an <error-tag> value of data-missing.
Using "none" allows operations like "delete" to avoid
unintentionally creating the parent hierarchy of the element
to be deleted.
なし：受信構成データが「操作」属性を使用して別の操作を要求しない限り、ターゲットデータストアは<config>パラメータの設定の影響を受けません。 <config>パラメーターの構成に、ターゲットデータストアに対応するレベルがないデータが含まれている場合、<rpc-error>が返され、<error-tag>の値はdata-missingになります。 「none」を使用すると、「delete」などの操作で、削除する要素の親階層を誤って作成することを回避できます。
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>要素は、デバイスが：validate：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>操作を実行しないでください。 これはデフォルトのテストオプションです。
set: Perform a set without a validation test first.
set：最初に検証テストなしでセットを実行します。
test-only: Perform only the validation test, without
attempting to set.
test-only：設定を行わずに、検証テストのみを実行します。
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.
エラー時継続：エラー時に構成データの処理を続行します。 エラーが記録され、エラーが発生すると否定応答が生成されます。
Enns, et al. Standards Track [Page 39]
RFC 6241 NETCONF Protocol June 2011
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.
rollback-on-error：エラー重大度<rpc-error>要素が生成されるようなエラー条件が発生した場合、サーバーは<edit-config>操作の処理を停止し、指定された構成を開始時に完全な状態に復元します この<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.
肯定応答：デバイスが要求を満たすことができた場合、<rp>要素を含む<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>
Enns, et al. Standards Track [Page 40]
RFC 6241 NETCONF Protocol June 2011
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Add an interface named "Ethernet0/0" to the running configuration,
replacing any previous interface with that name:
「Ethernet0 / 0」という名前のインターフェイスを実行コンフィギュレーションに追加し、以前のインターフェイスをその名前で置き換えます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete the configuration for an interface named "Ethernet0/0" from
the running configuration:
「Ethernet0 / 0」という名前のインターフェイスの構成を実行構成から削除します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
Enns, et al. Standards Track [Page 41]
RFC 6241 NETCONF Protocol June 2011
</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>
Enns, et al. Standards Track [Page 42]
RFC 6241 NETCONF Protocol June 2011
7.3. <copy-config>
7.3。 <コピー構成>
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".
：writable-running機能をアドバタイズしても、デバイスは<running />構成データストアを<copy-config>操作の<target>パラメータとしてサポートしないことを選択できます（MAY）。 デバイスは、リモートからリモートへのコピー操作をサポートしないことを選択できます。この場合、<source>パラメータと<target>パラメータの両方が<url>要素を使用します。 <source>パラメータと<target>パラメータが同じURLまたは構成データストアを識別する場合、「無効な値」を含むerror-タグでエラーを返す必要があります。
Parameters:
target: Name of the configuration datastore to use as the
destination of the <copy-config> operation.
target：<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.
source：<copy-config>操作のソースとして使用する構成データストアの名前、またはコピーする完全な構成を含む<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>
Enns, et al. Standards Track [Page 43]
RFC 6241 NETCONF Protocol June 2011
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.4. <delete-config>
7.4。 <削除構成>
Description: Delete a configuration datastore. The <running>
configuration datastore cannot be deleted.
説明：構成データストアを削除します。 <running>構成データストアは削除できません。
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.
target：削除する構成データストアの名前。
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>
7.5. <lock>
7.5。 <ロック>
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）スクリプトなど）、および人間のユーザーとのやり取りを恐れずに変更できるようにすることを目的としています。
Enns, et al. Standards Track [Page 44]
RFC 6241 NETCONF Protocol June 2011
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>操作は必須パラメーター<target>を取ります。 <target>パラメータは、ロックされる構成データストアを指定します。 ロックがアクティブな場合、ロックされた構成データストアで<edit-config>操作を使用し、ロックされた構成を<copy-config>操作のターゲットとして使用することは、他のNETCONFセッションでは許可されません。 さらに、システムは、これらのロックされた構成リソースが、SNMPやCLIなどの他の非NETCONF管理操作によって変更されないようにします。 <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.
ターゲット構成は<candidate>であり、すでに変更されており、これらの変更はコミットまたはロールバックされていません。
* The target configuration is <running>, and another NETCONF
session has an ongoing confirmed commit (Section 8.4).
ターゲット設定は<running>であり、別のNETCONFセッションには確認済みのコミットが継続しています（セクション8.4）。
The server MUST respond with either an <ok> element or an
<rpc-error>.
サーバーは<ok>要素または<rpc-error>のいずれかで応答する必要があります。
Enns, et al. Standards Track [Page 45]
RFC 6241 NETCONF Protocol June 2011
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.
target：ロックする構成データストアの名前。
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>要素は「lock-denied」になり、<error-info>要素にはロック所有者の<session-id>が含まれます。 ロックが非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.
例：次の例は、ロックがすでに使用されているときに、ロックの取得に失敗したことを示しています。
Enns, et al. Standards Track [Page 46]
RFC 6241 NETCONF Protocol June 2011
<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>
7.6. <unlock>
7.6 <ロック解除>
Description: The <unlock> operation is used to release a
configuration lock, previously obtained with the <lock> operation.
説明：<unlock>操作は、以前に<lock>操作で取得した構成ロックを解放するために使用されます。
An <unlock> operation will not succeed if either of the following
conditions is true:
次のいずれかの条件に該当する場合、<unlock>操作は成功しません。
* The specified lock is not currently active.
指定されたロックは現在アクティブではありません。
* The session issuing the <unlock> operation is not the same
session that obtained the lock.
<unlock>操作を発行するセッションは、ロックを取得したセッションとは異なります。
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.
target：ロックを解除する構成データストアの名前。
A NETCONF client is not permitted to unlock a configuration
datastore that it did not lock.
NETCONFクライアントは、ロックしなかった構成データストアをロック解除することはできません。
Enns, et al. Standards Track [Page 47]
RFC 6241 NETCONF Protocol June 2011
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>
7.7. <get>
7.7。 <取得>
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.
filter：このパラメーターは、取得するシステム構成と状態データの部分を指定します。 このパラメーターが存在しない場合、すべてのデバイス構成と状態情報が返されます。
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式が含まれていることを示すことができます（MAY）。
Enns, et al. Standards Track [Page 48]
RFC 6241 NETCONF Protocol June 2011
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>
7.8. <close-session>
7.8。 <セッション終了>
Description: Request graceful termination of a NETCONF session.
説明：NETCONFセッションの正常終了を要求します。
When a NETCONF server receives a <close-session> request, it will
gracefully close the session. The server will release any locks
and resources associated with the session and gracefully close any
associated connections. Any NETCONF requests received after a
<close-session> request will be ignored.
NETCONFサーバーは<close-session>リクエストを受信すると、セッションを正常に閉じます。 サーバーは、セッションに関連付けられているロックとリソースを解放し、関連付けられている接続を適切に閉じます。 <close-session>リクエストの後に受信したNETCONFリクエストは無視されます。
Enns, et al. Standards Track [Page 49]
RFC 6241 NETCONF Protocol June 2011
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>
7.9. <kill-session>
7.9。 <キルセッション>
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.
確認されたコミット（8.4）の処理中にNETCONFサーバーが<kill-session>リクエストを受信した場合、確認されたコミットが発行される前の状態に構成を復元する必要があります。
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>に含まれます。
Enns, et al. Standards Track [Page 50]
RFC 6241 NETCONF Protocol June 2011
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>
8. Capabilities
8.機能
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」と呼ばれます。 省略形はプロトコル内で使用してはいけません。
8.1. Capabilities Exchange
8.1。 能力交換
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 Enns, et al. Standards Track [Page 51] RFC 6241 NETCONF Protocol June 2011 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ピアはセッションを継続してはなりません（MUST NOT）。 共通のプロトコルバージョン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>要素を含んではいけません（MUST NOT）。
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>要素を受信しないクライアントは、（最初に<close-session>を送信せずに）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>要素を同時に送信します。 ピアは、自身のセットを送信する前に、相手側から機能セットを受信するのを待機してはなりません（MUST NOT）。
Enns, et al. Standards Track [Page 52] RFC 6241 NETCONF Protocol June 2011 8.2. Writable-Running Capability
8.2。 書き込み可能な実行機能
8.2.1. Description
8.2.1。 説明文
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.
：writable-running機能は、デバイスが<running>構成データストアへの直接書き込みをサポートしていることを示します。 つまり、デバイスは、<running>構成がターゲットである<edit-config>および<copy-config>操作をサポートします。
8.2.2. Dependencies
8.2.2。 依存関係
None.
無し。
8.2.3. Capability Identifier
8.2.3。 機能識別子
The :writable-running capability is identified by the following capability string:
：writable-running機能は、次の機能文字列で識別されます。
urn:ietf:params:netconf:capability:writable-running:1.0
8.2.4. New Operations
8.2.4。 新しいオペレーション
None.
無し。
8.2.5. Modifications to Existing Operations
8.2.5。 既存の操作の変更
8.2.5.1. <edit-config>
8.2.5.1。 <編集構成>
The :writable-running capability modifies the <edit-config> operation to accept the <running> element as a <target>.
：writable-running機能は、<running>要素を<target>として受け入れるように<edit-config>操作を変更します。
8.2.5.2. <copy-config>
8.2.5.2。 <コピー構成>
The :writable-running capability modifies the <copy-config> operation to accept the <running> element as a <target>.
：writable-running機能は、<copy-config>操作を変更して、<running>要素を<target>として受け入れます。
8.3. Candidate Configuration Capability
8.3。 候補構成機能
8.3.1. Description
8.3.1。 説明文
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 Enns, et al. Standards Track [Page 53] RFC 6241 NETCONF Protocol June 2011 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.
候補構成機能：candidateは、デバイスが候補構成データストアをサポートしていることを示します。これは、デバイスの現在の構成に影響を与えずに操作できる構成データを保持するために使用されます。 候補構成は、構成データを作成および操作するための作業場所として機能する完全な構成データセットです。 このデータに追加、削除、変更を行って、目的の構成データを構築できます。 <commit>操作は、デバイスの実行中の構成が候補構成の値に設定される原因となる場合にいつでも実行できます（MAY）。
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>操作は、実行構成を候補構成の現在の内容に効果的に設定します。 単純なコピーとしてモデル化することもできますが、いくつかの理由により、個別の操作として行われます。 高レベルの概念をファーストクラスのオペレーションとして維持することで、開発者はクライアントが要求しているものとサーバーが実行しなければならないものの両方をより明確に確認できます。 これにより、意図がより明確になり、特殊なケースがより簡単になり、操作間の相互作用がより簡単になります。 たとえば、：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>操作を実行することにより、候補の構成に対するコミットされていない変更を破棄できます。 この操作は、候補構成の内容を実行構成の内容に戻します。
8.3.2. Dependencies
8.3.2。 依存関係
None.
無し。
8.3.3. Capability Identifier
8.3.3。 機能識別子
The :candidate capability is identified by the following capability string:
：candidate機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:candidate:1.0
8.3.4. New Operations
8.3.4.1. <commit>
8.3.4。 新しいオペレーション
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.
候補となる構成のコンテンツが完了すると、構成データをコミットして、データセットをデバイスの残りの部分に公開し、新しい構成で説明されている動作に準拠するようにデバイスに要求できます。
Enns, et al. Standards Track [Page 54]
RFC 6241 NETCONF Protocol June 2011
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>値が "in-use"で失敗する必要があります。
If the system does not have the :candidate capability, the
<commit> operation is not available.
システムに：candidate機能がない場合、<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>
8.3.4.2. <discard-changes>
8.3.4.2。 <変更を破棄>
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>操作を使用して候補構成を現在実行中の構成に戻すことができます。
Enns, et al. Standards Track [Page 55]
RFC 6241 NETCONF Protocol June 2011
<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.
この操作では、候補の構成を実行中の構成の内容でリセットすることにより、コミットされていない変更を破棄します。
8.3.5. Modifications to Existing Operations
8.3.5。 既存の操作の変更
8.3.5.1. <get-config>, <edit-config>, <copy-config>, and <validate>
8.3.5.1。 <get-config>、<edit-config>、<copy-config>、および<validate>
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>パラメーターとして使用できます。 <candidate>要素は、候補構成を示すために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
</get-config>
</rpc>
8.3.5.2. <lock> and <unlock>
8.3.5.2。 <lock>および<unlock>
The candidate configuration can be locked using the <lock> operation with the <candidate> element as the <target> parameter:
<candidate>要素を<target>パラメータとして指定した<lock>操作を使用して、候補構成をロックできます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
Similarly, the candidate configuration is unlocked using the
<candidate> element as the <target> parameter:
同様に、候補構成は、<target>パラメーターとして<candidate>要素を使用してロック解除されます。
Enns, et al. Standards Track [Page 56]
RFC 6241 NETCONF Protocol June 2011
<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.
クライアントが候補の構成に対する未処理の変更で失敗した場合、回復は困難な場合があります。 簡単に回復できるように、<unlock>操作で明示的に、またはセッションの失敗から暗黙的に、ロックが解放されると、未解決の変更は破棄されます。
8.4. Confirmed Commit Capability
8.4。 確認されたコミット機能
8.4.1. Description
8.4.1。 説明文
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.
：confirmed-commit：1.1機能は、サーバーが<cancel-commit>操作と、<commit>操作の<confirmed>、<confirm-timeout>、<persist>、および<persist-id>パラメータをサポートすることを示します 。 <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.
確認された<commit>操作は、タイムアウト期間（デフォルトでは600秒= 10分）内に確認コミットが発行されない場合、元に戻す必要があります。 コミットの確認は、<confirmed>パラメータのない<commit>操作です。 タイムアウト期間は、<confirm-timeout>パラメータで調整できます。 タイマーが切れる前にフォローアップ確認済みの<commit>操作が発行されると、タイマーは新しい値（デフォルトでは600秒）にリセットされます。 確定コミットとフォローアップ確認済み<commit>操作の両方で、構成に追加の変更が導入される場合があります。
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>要素が指定されていない場合、フォローアップコミットと確認中のコミットは、確認済みのコミットを発行したセッションと同じセッションで発行する必要があります。 確認された<commit>操作で<persist>要素が指定されている場合、フォローアップコミットと確認コミットは任意のセッションで指定でき、指定された値と等しい値を持つ<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.
サーバーが：startup機能もアドバタイズする場合は、起動から変更を保存するために、実行から起動までの<copy-config>も必要です。
Enns, et al. Standards Track [Page 57] RFC 6241 NETCONF Protocol June 2011 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.
共有構成の場合、この機能により、構成ロック機能が使用されていない（つまり、<edit-config> 運転開始） したがって、共有の構成データストアでこの機能を使用するには、構成のロックも使用する必要があります（SHOULD）。
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を通知する場合があります。
8.4.2. Dependencies
8.4.2。 依存関係
The :confirmed-commit:1.1 capability is only relevant if the :candidate capability is also supported.
：confirmed-commit：1.1機能は、：candidate機能もサポートされている場合にのみ関連します。
8.4.3. Capability Identifier
8.4.3。 機能識別子
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
Enns, et al. Standards Track [Page 58]
RFC 6241 NETCONF Protocol June 2011
8.4.4. New Operations
8.4.4。 新しいオペレーション
8.4.4.1. <cancel-commit>
8.4.4.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>
Enns, et al. Standards Track [Page 59]
RFC 6241 NETCONF Protocol June 2011
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
8.4.5. Modifications to Existing Operations
8.4.5。 既存の操作の変更
8.4.5.1. <commit>
8.4.5.1。 <コミット>
The :confirmed-commit:1.1 capability allows 4 additional parameters to the <commit> operation.
：confirmed-commit：1.1機能は、<commit>操作に4つの追加パラメーターを許可します。
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.
confirm-timeout：確認されたコミットのタイムアウト期間（秒単位）。 指定しない場合、確認タイムアウトのデフォルトは600秒です。
persist:
Make the confirmed commit survive a session termination, and
set a token on the ongoing confirmed commit.
persist：確認済みのコミットがセッションの終了後も存続するようにし、進行中の確認済みのコミットにトークンを設定します。
persist-id:
Used to issue a follow-up confirmed commit or a confirming
commit from any session, with the token from the previous
<commit> operation.
persist-id：前の<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>
Enns, et al. Standards Track [Page 60]
RFC 6241 NETCONF Protocol June 2011
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>
8.5. Rollback-on-Error Capability
8.5。 エラー時のロールバック機能
8.5.1. Description
8.5.1。 説明文
This capability indicates that the server will support the "rollback-on-error" value in the <error-option> parameter to the <edit-config> operation.
この機能は、サーバーが<edit-config>操作の<error-option>パラメーターの「rollback-on-error」値をサポートすることを示しています。
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.
共有構成の場合、この機能により、構成ロック機能が使用されていない（つまり、<edit-config> 運転開始）。 したがって、共有の構成データストアでこの機能を使用するには、構成のロックも使用することを強くお勧めします。
Enns, et al. Standards Track [Page 61] RFC 6241 NETCONF Protocol June 2011 8.5.2. Dependencies
8.5.2。 依存関係
None.
無し。
8.5.3. Capability Identifier
8.5.3。 機能識別子
The :rollback-on-error capability is identified by the following capability string:
：rollback-on-error機能は、次の機能文字列で識別されます。
urn:ietf:params:netconf:capability:rollback-on-error:1.0
8.5.4. New Operations
8.5.4。 新しいオペレーション
None.
無し。
8.5.5. Modifications to Existing Operations
8.5.5。 既存の操作の変更
8.5.5.1. <edit-config>
8.5.5.1。 <編集構成>
The :rollback-on-error capability allows the "rollback-on-error" value to the <error-option> parameter on the <edit-config> operation.
：rollback-on-error機能により、<roll-on-error "値を<edit-config>操作の<error-option>パラメーターに許可できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Enns, et al. Standards Track [Page 62]
RFC 6241 NETCONF Protocol June 2011
8.6. Validate Capability
8.6 機能の検証
8.6.1. Description
8.6.1。 説明文
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.
この機能がアドバタイズされている場合、デバイスは<validate>プロトコル操作をサポートし、少なくとも構文エラーをチェックします。 さらに、この機能は、<edit-config>操作の<test-option>パラメーターをサポートし、提供されている場合は、少なくとも構文エラーをチェックします。
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はこのドキュメントで定義されており、<edit-config>操作の<test-option>パラメータに「test-only」という新しい値を追加することで、バージョン1.0を拡張しています。 古いクライアントとの下位互換性のために、この仕様に準拠するサーバーは、バージョン1.1に加えてバージョン1.0を通知する場合があります。
8.6.2. Dependencies
8.6.2。 依存関係
None.
無し。
8.6.3. Capability Identifier
8.6.3。 機能識別子
The :validate:1.1 capability is identified by the following capability string:
：validate：1.1機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:validate:1.1
8.6.4. New Operations
8.6.4。 新しいオペレーション
8.6.4.1. <validate>
8.6.4.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.
パラメータ：source：<candidate>などの検証する構成データストアの名前、または検証する完全な構成を含む<config>要素。
Enns, et al. Standards Track [Page 63]
RFC 6241 NETCONF Protocol June 2011
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.
<validate>操作は、構文エラー、パラメーターの欠落、未定義の構成データへの参照、または基になるデータモデルによって確立されたその他のルール違反など、さまざまな理由で失敗する可能性があります。
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>
8.6.5. Modifications to Existing Operations
8.6.5。 既存の操作の変更
8.6.5.1. <edit-config>
8.6.5.1。 <編集構成>
The :validate:1.1 capability modifies the <edit-config> operation to accept the <test-option> parameter.
：validate：1.1機能は、<test-option>パラメーターを受け入れるように<edit-config>操作を変更します。
8.7. Distinct Startup Capability
8.7。 明確なスタートアップ機能
8.7.1. Description
8.7.1。 説明文
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 Enns, et al. Standards Track [Page 64] RFC 6241 NETCONF Protocol June 2011 running configuration. NETCONF protocol operations refer to the startup datastore using the <startup> element.
デバイスは、個別の実行構成データストアと起動構成データストアをサポートしています。 起動構成は、デバイスの起動時に読み込まれます。 実行コンフィギュレーションに影響する操作は、スタートアップコンフィギュレーションに自動的にコピーされません。 <running>から<startup>への明示的な<copy-config>操作を使用して、スタートアップコンフィギュレーションを実行コンフィギュレーションの現在の内容に更新します。 NETCONFプロトコル操作は、<startup>要素を使用して起動データストアを参照します。
8.7.2. Dependencies
8.7.2。 依存関係
None.
無し。
8.7.3. Capability Identifier
8.7.3。 機能識別子
The :startup capability is identified by the following capability string:
：startup機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:startup:1.0
8.7.4. New Operations
8.7.4。 新しいオペレーション
None.
無し。
8.7.5. Modifications to Existing Operations
8.7.5。 既存の操作の変更
8.7.5.1. General
8.7.5.1。 一般的な
The :startup capability adds the <startup/> configuration datastore to arguments of several NETCONF operations. The server MUST support the following additional values:
：startup機能は、いくつかの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>操作を使用して、<running>構成データストアを<startup>構成データストアにコピーします。
Enns, et al. Standards Track [Page 65]
RFC 6241 NETCONF Protocol June 2011
<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>
8.8. URL Capability
8.8。 URL機能
8.8.1. Description
8.8.1。 説明文
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引数によってさらに識別されます。
8.8.2. Dependencies
8.8.2。 依存関係
None.
無し。
8.8.3. Capability Identifier
8.8.3。 機能識別子
The :url capability is identified by the following capability string:
urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
The :url capability URI MUST contain a "scheme" argument assigned a
comma-separated list of scheme names indicating which schemes the
NETCONF peer supports. For example:
：url機能URIには、NETCONFピアがサポートするスキームを示すスキーム名のコンマ区切りのリストが割り当てられた「スキーム」引数を含める必要があります。 例えば：
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
8.8.4. New Operations
8.8.4。 新しいオペレーション
None.
無し。
8.8.5. Modifications to Existing Operations
8.8.5。 既存の操作の変更
8.8.5.1. <edit-config>
8.8.5.1。 <編集構成>
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>操作を変更します。
Enns, et al. Standards Track [Page 66] RFC 6241 NETCONF Protocol June 2011 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」名前空間の要素<config>の下にXMLでエンコードされます。
8.8.5.2. <copy-config>
8.8.5.2。 <コピー構成>
The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters.
：url機能は、<source>および<target>パラメータの値として<url>要素を受け入れるように<copy-config>操作を変更します。
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が参照するファイルには、「urn：ietf：params：xml：ns：netconf：base：1.0」名前空間の要素<config>の下にXMLでエンコードされた完全なデータストアが含まれています。
8.8.5.3. <delete-config>
8.8.5.3。 <削除構成>
The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters.
：url機能は<delete-config>操作を変更して、<url>要素を<target>パラメータの値として受け入れます。
8.8.5.4. <validate>
8.8.5.4。 <検証>
The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.
：url機能は、<validate>オペレーションを変更して、<source>パラメータの値として<url>要素を受け入れます。
8.9. XPath Capability
8.9。 XPath機能
8.9.1. Description
8.9.1。 説明文
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]で使用されるものと同じであり、XSLT 1.0で使用されるのと同じルートノードの子の拡張（[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.
名前空間宣言のセットは、<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 The function library is the core function library, plus any
functions defined by the data model.
関数ライブラリは、コア関数ライブラリと、データモデルで定義された関数です。
Enns, et al. Standards Track [Page 67] RFC 6241 NETCONF Protocol June 2011 o The context node is the root node.
コンテキストノードはルートノードです。
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.
応答メッセージには、フィルター式によって選択されたサブツリーが含まれています。 このようなサブツリーごとに、データモデルルートノードからサブツリーまでのパス（サブツリーを一意に識別するために必要な要素または属性を含む）が応答メッセージに含まれます。 特定のデータインスタンスは応答で複製されません。
8.9.2. Dependencies
8.9.2。 依存関係
None.
無し。
8.9.3. Capability Identifier
8.9.3。 機能識別子
The :xpath capability is identified by the following capability string:
：xpath機能は、次の機能文字列によって識別されます。
urn:ietf:params:netconf:capability:xpath:1.0
8.9.4. New Operations
8.9.4。 新しいオペレーション
None.
無し。
8.9.5. Modifications to Existing Operations
8.9.5。 既存の操作の変更
8.9.5.1. <get-config> and <get>
8.9.5.1。 <get-config>および<get>
The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the "type" attribute of the <filter> element. When the "type" attribute is set to "xpath", a "select" attribute MUST be present on the <filter> element. The "select" attribute will be treated as an XPath expression and used to filter the returned data. The <filter> element itself MUST be empty in this case.
：xpath機能は、<get>および<get-config>操作を変更して、<filter>要素の「type」属性の値「xpath」を受け入れるようにします。 「type」属性が「xpath」に設定されている場合、「select」属性が<filter>要素に存在する必要があります。 「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.
結果ノードのすべての祖先ノードを最初にエンコードする必要があるため、応答で返される<data>要素には、基礎となるデータモデルに従って、完全に指定されたサブツリーのみが含まれます。
Enns, et al. Standards Track [Page 68]
RFC 6241 NETCONF Protocol June 2011
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.
結果ノードの兄弟ノードまたは祖先ノードが概念的なデータ構造内の特定のインスタンスを識別するために必要な場合、これらのノードも応答でエンコードする必要があります。
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>
9. Security Considerations
9.セキュリティに関する考慮事項
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.
このセクションでは、基本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で包括的な承認スキームを提供する必要があります。
Enns, et al. Standards Track [Page 69] RFC 6241 NETCONF Protocol June 2011 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、Blocks Extensible 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、BEEPなど） 必要に応じて、機密性と認証の両方を提供します。 さらに、NETCONFセッションの両端のIDは、特定の要求の承認を判断するために、もう一方の端で使用できることが期待されます。 転送や暗号化の方法などの追加情報を簡単に想定して、認証の目的で利用できるようにすることもできます。 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 Enns, et al. Standards Track [Page 70] RFC 6241 NETCONF Protocol June 2011 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が<candidate>構成のインターフェイスにIPアドレスを構成している場合、ユーザーAは<candidate>構成のコミットを許可されてはなりません（MUST NOT）。
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>操作は、NETCONFが、管理者から少なくともある程度信頼されているシステムでの使用を目的としていることを示します。 このドキュメントで指定されているように、プリンシパルがアクセスできない構成の一部をロックすることができます。 結局のところ、構成全体がロックされています。 この問題を軽減するには、2つの方法があります。 問題のセッションのセッションIDがわかっている場合は、NETCONF内からプログラムで別のNETCONFセッションを強制終了することができます。 ロックを解除するもう1つの方法は、デバイスのネイティブユーザーインターフェイス内で機能を提供することです。 これらの2つのメカニズムには、問題のあるユーザーを認証、承認、およびアカウンティング（AAA）サーバーから削除することで改善できる競合状態があります。 ただし、このようなソリューションは、SSH公開/秘密鍵のペアが使用されるシナリオなど、すべての展開シナリオで役立つわけではありません。
10. IANA Considerations
10. IANAに関する考慮事項
10.1. NETCONF XML Namespace
10.1 NETCONF XML名前空間
This document registers a URI for the NETCONF XML namespace in the IETF XML registry [RFC3688]. IANA has updated the following URI to reference this document. URI: urn:ietf:params:xml:ns:netconf:base:1.0 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 10.2. NETCONF XML Schema
10.2 NETCONF XMLスキーマ
This document registers a URI for the NETCONF XML schema in the IETF XML registry [RFC3688]. IANA has updated the following URI to reference this document. URI: urn:ietf:params:xml:schema:netconf Enns, et al. Standards Track [Page 71] RFC 6241 NETCONF Protocol June 2011 Registrant Contact: The IESG. XML: Appendix B of this document. 10.3. NETCONF YANG Module
10.3。 NETCONF YANGモジュール
This document registers a YANG module in the YANG Module Names
registry [RFC6020].
name: ietf-netconf
namespace: urn:ietf:params:xml:ns:netconf:base:1.0
prefix: nc
reference: RFC 6241
10.4. NETCONF Capability URNs
10.4。 NETCONF機能URN
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
Enns, et al. Standards Track [Page 72]
RFC 6241 NETCONF Protocol June 2011
IANA has added the following capabilities to the registry:
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
11. Contributors
In addition to the editors, this document was written by:
Ken Crozier, Cisco Systems
Ted Goddard, IceSoft
Eliot Lear, Cisco Systems
Phil Shafer, Juniper Networks
Steve Waldbusser
Margaret Wasserman, Painless Security, LLC
12. Acknowledgements
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.
Enns, et al. Standards Track [Page 73]
RFC 6241 NETCONF Protocol June 2011
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote
Procedure Call (RPC) for NETCONF", RFC 5717,
December 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010.
[RFC6242] Wasserman, M., "Using the NETCONF Configuration Protocol
over Secure Shell (SSH)", RFC 6242, June 2011.
[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-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>.
Enns, et al. Standards Track [Page 74]
RFC 6241 NETCONF Protocol June 2011
13.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[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.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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>.
Enns, et al. Standards Track [Page 75]
RFC 6241 NETCONF Protocol June 2011
Appendix A. NETCONF Error List
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: 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: 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.
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: 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.
Enns, et al. Standards Track [Page 76]
RFC 6241 NETCONF Protocol June 2011
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: 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: 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-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-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: 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.
Enns, et al. Standards Track [Page 77]
RFC 6241 NETCONF Protocol June 2011
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: 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: 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: 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-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: 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.
Enns, et al. Standards Track [Page 78]
RFC 6241 NETCONF Protocol June 2011
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: 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.
<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.
<noop-element> : identifies an element in the data
model for which the requested operation was not
attempted for that node and all its child nodes.
This element can appear zero or more times in the
<error-info> container.
Description: 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>).
Enns, et al. Standards Track [Page 79]
RFC 6241 NETCONF Protocol June 2011
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.
This error-tag is new in :base:1.1 and MUST NOT be
sent to old clients.
Appendix B. XML Schema for NETCONF Messages Layer
This section is normative.
<CODE BEGINS> file "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
-->
Enns, et al. Standards Track [Page 80]
RFC 6241 NETCONF Protocol June 2011
<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"/>
Enns, et al. Standards Track [Page 81]
RFC 6241 NETCONF Protocol June 2011
<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"
Enns, et al. Standards Track [Page 82]
RFC 6241 NETCONF Protocol June 2011
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"/>
Enns, et al. Standards Track [Page 83]
RFC 6241 NETCONF Protocol June 2011
</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"/>
Enns, et al. Standards Track [Page 84]
RFC 6241 NETCONF Protocol June 2011
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<CODE ENDS>
Appendix C. YANG Module for NETCONF Protocol Operations
This section is normative.
The ietf-netconf YANG module imports typedefs from [RFC6021].
<CODE BEGINS> file "ietf-netconf@2011-06-01.yang"
module 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;
import ietf-inet-types {
prefix inet;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
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>";
Enns, et al. Standards Track [Page 85]
RFC 6241 NETCONF Protocol June 2011
description
"NETCONF Protocol Data Types and Protocol Operations.
Copyright (c) 2011 IETF Trust and the persons identified as
the document authors. All rights reserved.
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).
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:
type : optional attribute with allowed
value strings 'subtree' and 'xpath'.
If missing, the default value is 'subtree'.
If the 'xpath' feature is supported, then the
following unqualified XML attribute is
also supported:
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 {
Enns, et al. Standards Track [Page 86]
RFC 6241 NETCONF Protocol June 2011
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.";
Enns, et al. Standards Track [Page 87]
RFC 6241 NETCONF Protocol June 2011
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
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";
}
Enns, et al. Standards Track [Page 88]
RFC 6241 NETCONF Protocol June 2011
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 {
Enns, et al. Standards Track [Page 89]
RFC 6241 NETCONF Protocol June 2011
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
Enns, et al. Standards Track [Page 90]
RFC 6241 NETCONF Protocol June 2011
"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.";
Enns, et al. Standards Track [Page 91]
RFC 6241 NETCONF Protocol June 2011
}
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
rpc get-config {
description
"Retrieve all or part of a specified configuration.";
reference "RFC 6241, Section 7.1";
input {
container source {
description
Enns, et al. Standards Track [Page 92]
RFC 6241 NETCONF Protocol June 2011
"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
Enns, et al. Standards Track [Page 93]
RFC 6241 NETCONF Protocol June 2011
"The <edit-config> operation loads all or part of a specified
configuration to the specified target configuration.";
reference "RFC 6241, Section 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.";
Enns, et al. Standards Track [Page 94]
RFC 6241 NETCONF Protocol June 2011
}
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 {
Enns, et al. Standards Track [Page 95]
RFC 6241 NETCONF Protocol June 2011
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";
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.";
}
Enns, et al. Standards Track [Page 96]
RFC 6241 NETCONF Protocol June 2011
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 {
Enns, et al. Standards Track [Page 97]
RFC 6241 NETCONF Protocol June 2011
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";
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.";
Enns, et al. Standards Track [Page 98]
RFC 6241 NETCONF Protocol June 2011
reference "RFC 6241, Section 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";
input {
container target {
description
"Particular configuration to unlock.";
choice config-target {
mandatory true;
Enns, et al. Standards Track [Page 99]
RFC 6241 NETCONF Protocol June 2011
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";
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.";
}
Enns, et al. Standards Track [Page 100]
RFC 6241 NETCONF Protocol June 2011
}
}
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";
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";
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";
Enns, et al. Standards Track [Page 101]
RFC 6241 NETCONF Protocol June 2011
}
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.
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.";
Enns, et al. Standards Track [Page 102]
RFC 6241 NETCONF Protocol June 2011
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";
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.";
Enns, et al. Standards Track [Page 103]
RFC 6241 NETCONF Protocol June 2011
}
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>
Enns, et al. Standards Track [Page 104]
RFC 6241 NETCONF Protocol June 2011
Appendix D. Capability Template
付録D.機能テンプレート
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用語の機能と呼ばれるため、YANGで記述されたデータモデルはプロトコル機能を定義する必要がありません。 機能テンプレートは、YANGメカニズムが十分に強力でない場合（たとえば、パラメーター化された機能を処理するため）、または別のデータモデリング言語が使用されている場合に使用することを目的としています。
D.1. capability-name (template)
D.1.1. Overview
D.1.2. Dependencies
D.1.3. Capability Identifier
The {name} capability is identified by the following capability
string:
{capability uri}
D.1.4. New Operations
D.1.4.1. <op-name>
D.1.5. Modifications to Existing Operations
D.1.5.1. <op-name>
If existing operations are not modified by this capability, this
section may be omitted.
D.1.6. Interactions with Other Capabilities
If this capability does not interact with other capabilities, this
section may be omitted.
Enns, et al. Standards Track [Page 105]
RFC 6241 NETCONF Protocol June 2011
Appendix E. Configuring Multiple Devices with NETCONF
付録E.NETCONFを使用した複数のデバイスの構成
This section is non-normative.
このセクションは非規範的です。
E.1. Operations on Individual Devices
E.1。 個々のデバイスでの操作
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 Checkpointing the running configuration. o Loading and validating the incoming configuration. o Changing the running configuration. o Testing the new configuration. o Making the change permanent (if desired). o Releasing the configuration lock. Let's look at the details of each step. E.1.1. Acquiring the Configuration Lock
E.1.1。 構成ロックの取得
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>操作を使用して取得できます。
Enns, et al. Standards Track [Page 106]
RFC 6241 NETCONF Protocol June 2011
<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>
E.1.2. Checkpointing the Running Configuration
E.1.2。 実行構成のチェックポイント
The running configuration can be saved into a local file as a checkpoint before loading the new configuration. If the update fails, the configuration can be restored by reloading the checkpoint file.
新しい構成をロードする前に、実行中の構成をチェックポイントとしてローカルファイルに保存できます。 更新が失敗した場合は、チェックポイントファイルを再ロードすることで構成を復元できます。
The checkpoint file can be created using the <copy-config> operation.
チェックポイントファイルは、<copy-config>操作を使用して作成できます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<url>file://checkpoint.conf</url>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
To restore the checkpoint file, reverse the <source> and <target>
parameters.
チェックポイントファイルを復元するには、<source>パラメータと<target>パラメータを逆にします。
Enns, et al. Standards Track [Page 107] RFC 6241 NETCONF Protocol June 2011 E.1.3. Loading and Validating the Incoming Configuration
E.1.3。 受信構成の読み込みと検証
If the :candidate capability is supported, the configuration can be loaded onto the device without impacting the running system.
：candidate機能がサポートされている場合、実行中のシステムに影響を与えることなく、構成をデバイスにロードできます。
<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機能をサポートしている場合、候補にロードされると、デフォルトで着信構成を検証します。 この検証を回避するには、値「set」を指定して<test-option>パラメータを渡します。 <validate>操作で完全な検証をリクエストできます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
E.1.4. Changing the Running Configuration
E.1.4。 実行構成の変更
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.
デバイスが：candidate機能をサポートしている場合は、<commit>操作を使用して実行構成を候補構成に設定します。 <confirmed>パラメータを使用して、デバイスへの接続が失敗した場合に元の構成に自動的に戻ることができるようにします。
Enns, et al. Standards Track [Page 108]
RFC 6241 NETCONF Protocol June 2011
<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>
E.1.5. Testing the New Configuration
E.1.5。 新しい構成のテスト
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ピアの動作証拠の検索）が含まれる場合があります。 追加されました）。
E.1.6. Making the Change Permanent
E.1.6。 変更を永続的にする
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.
デバイスが：startup機能をサポートしている場合、スタートアップコンフィギュレーションを<copy-config>操作のターゲットとして使用することにより、現在の構成をスタートアップコンフィギュレーションに保存できます。
Enns, et al. Standards Track [Page 109]
RFC 6241 NETCONF Protocol June 2011
<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.
デバイスが：candidate機能をサポートし、確認されたコミットが要求された場合、タイムアウトの期限が切れる前に確認コミットを送信する必要があります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
E.1.7. Releasing the Configuration Lock
E.1.7。 構成ロックの解除
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.
<unlock>操作を使用して、構成ロックを解放します。
<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.
：candidate機能がサポートされている場合、候補構成のロックを解除する必要があります。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
Enns, et al. Standards Track [Page 110]
RFC 6241 NETCONF Protocol June 2011
E.2. Operations on Multiple Devices
E.2。 複数のデバイスでの操作
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を変更すると、多くのデバイスの更新が必要になる場合があります。 これのもう1つの例は、サービスクラス定義の追加です。 デバイスの一部のみが新しい定義で更新された状態のままにしておくと、定義を参照するときに将来の障害が発生します。
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.
トランザクションのセマンティクスを提供するために、上記の単一デバイス操作で使用されるのと同じ手順が使用されますが、すべてのデバイスで並行して実行されます。 すべてのターゲットデバイスで構成ロックを取得し、すべてのデバイスが更新されて変更が永続的になるまで保持する必要があります。 構成の変更をアップロードし、すべてのデバイスで検証を実行する必要があります。 各デバイスでチェックポイントを作成する必要があります。 その後、実行コンフィギュレーションを変更、テストして、永続的にすることができます。 これらの手順のいずれかが失敗した場合、以前の構成は、それらが変更されたすべてのデバイスで復元できます。 変更が完全に実装または完全に破棄された後、各デバイスのロックを解放できます。
Enns, et al. Standards Track [Page 111]
RFC 6241 NETCONF Protocol June 2011
Appendix F. Changes from RFC 4741
This section lists major changes between this document and RFC 4741.
o Added the "malformed-message" error-tag.
o Added "remove" enumeration value to the "operation" attribute.
o Obsoleted the "partial-operation" error-tag enumeration value.
o Added <persist> and <persist-id> parameters to the <commit>
operation.
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 Added a YANG module to model the operations and removed the
operation layer from the XSD.
o Clarified lock behavior for the candidate datastore.
o Clarified the error response server requirements for the "delete"
enumeration value of the "operation" attribute.
o Added a namespace wildcarding mechanism for subtree filtering.
o Added a "test-only" value for the <test-option> parameter to the
<edit-config> operation.
o Added a <cancel-commit> operation.
o Introduced a NETCONF username and a requirement for transport
protocols to explain how a username is derived.
Enns, et al. Standards Track [Page 112]
RFC 6241 NETCONF Protocol June 2011
Authors' Addresses
Rob Enns (editor)
Juniper Networks
EMail: rob.enns@gmail.com
Martin Bjorklund (editor)
Tail-f Systems
EMail: mbj@tail-f.com
Juergen Schoenwaelder (editor)
Jacobs University
EMail: j.schoenwaelder@jacobs-university.de
Andy Bierman (editor)
Brocade
EMail: andy.bierman@brocade.com
Enns, et al. Standards Track [Page 113]