この文書はRFC6241の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
なお、Appendixは翻訳していません（面倒になったので）
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構成プロトコル(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.
本書では定義されたNetwork Configurationプロトコル(NETCONF)は、ネット
ワークデバイスの構成の設定と変更と削除のメカニズムを提供します。これ
はプロトコルメッセージとコンフィギュレーション・データに拡張マークアッ
プ言語の(XML)ベースのデータ符号化を使用します。NETCONFプロトコル操作
はRemote Procedure Call(RPC)として実現されます。この文書はRFC 4741を
廃止します。
Status of This Memo
この文書の状態
This is an Internet Standards Track document.
この文書はインターネット標準化作業中です。
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
この文書はインターネット技術特別調査委員会（IETF）の成果です。IETF会
員の合意を表しています。これは公開レビューを受けており、インターネッ
ト技術運営委員会（IESG）による公開が承認されています。インターネット
標準の詳細については、RFC 5741の２章を参照してください。
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6241.
この文書の現在の状態、誤記、評価に関する情報は、
http：//www.rfc-editor.org/info/rfc6241で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
著作権（Ｃ）２０１１、IETF信託と文書の著者と認識される人々。す
べての権利は当方に帰属します。
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
この文書はこの文書の公開日に有効なBCP 78とIETF信託のIETF文書に関連
する法的条項（http://trustee.ietf.org/license-info）の対象となりま
す。これらの文書は、この文書に関するあなたの権利と制限を説明してい
るので、注意深く確認してください。この文書内のプログラムコードの利
用には、IETF信託の法的条項の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信託にこのような資料の変更を許可する権利を付
与していない可能性があります。そのような資料の著作権を管理する人物か
ら適切な許可を取得しない場合、RFCとしての公開や英語以外の言語への翻
訳を除き、この文書はIETF標準手続以外で、修正できず２次的著作物を作れ
ないかもしれません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Separation of Configuration and State Data . . . . . . . 10
2. Transport Protocol Requirements . . . . . . . . . . . . . . . 11
2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 11
2.2. Authentication, Integrity, and Confidentiality . . . . . 12
2.3. Mandatory Transport Protocol . . . . . . . . . . . . . . 12
3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 13
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Document Type Declarations . . . . . . . . . . . . . . . 13
4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 13
4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 16
4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 19
5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 19
5.1. Configuration Datastores . . . . . . . . . . . . . . . . 19
5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 20
6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 21
6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 21
6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 22
6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 23
6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 23
6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 24
6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 25
6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 26
6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 26
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 27
6.4.4. Select All <name> Elements within the <users>
Subtree . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 30
6.4.6. Specific Elements from a Specific <user> Entry . . . 31
6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 32
6.4.8. Elements with Attribute Naming . . . . . . . . . . . 33
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 35
7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 35
7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 37
7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 43
7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 44
7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 49
7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 50
8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 51
8.2. Writable-Running Capability . . . . . . . . . . . . . . . 53
8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 53
8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 53
8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 53
8.2.5. Modifications to Existing Operations . . . . . . . . 53
8.3. Candidate Configuration Capability . . . . . . . . . . . 53
8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 54
8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 54
8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 54
8.3.5. Modifications to Existing Operations . . . . . . . . 56
8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 57
8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 57
8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 58
8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 58
8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 59
8.4.5. Modifications to Existing Operations . . . . . . . . 60
8.5. Rollback-on-Error Capability . . . . . . . . . . . . . . 61
8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 61
8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 62
8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 62
8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 62
8.5.5. Modifications to Existing Operations . . . . . . . . 62
8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 63
8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 63
8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 63
8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 63
8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 63
8.6.5. Modifications to Existing Operations . . . . . . . . 64
8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 64
8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 64
8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 65
8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 65
8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 65
8.7.5. Modifications to Existing Operations . . . . . . . . 65
8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 66
8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 66
8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 66
8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 66
8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 66
8.8.5. Modifications to Existing Operations . . . . . . . . 66
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 67
8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 67
8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 68
8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 68
8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 68
8.9.5. Modifications to Existing Operations . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 71
10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 71
10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 72
10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 72
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 76
Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 80
Appendix C. YANG Module for NETCONF Protocol Operations . . . . 85
Appendix D. Capability Template . . . . . . . . . . . . . . . . 105
D.1. capability-name (template) . . . . . . . . . . . . . . . 105
D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 105
D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 105
D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 105
D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 105
D.1.5. Modifications to Existing Operations . . . . . . . . 105
D.1.6. Interactions with Other Capabilities . . . . . . . . 105
Appendix E. Configuring Multiple Devices with NETCONF . . . . . 106
E.1. Operations on Individual Devices . . . . . . . . . . . . 106
E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 106
E.1.2. Checkpointing the Running Configuration . . . . . . . 107
E.1.3. Loading and Validating the Incoming Configuration . . 108
E.1.4. Changing the Running Configuration . . . . . . . . . 108
E.1.5. Testing the New Configuration . . . . . . . . . . . . 109
E.1.6. Making the Change Permanent . . . . . . . . . . . . . 109
E.1.7. Releasing the Configuration Lock . . . . . . . . . . 110
E.2. Operations on Multiple Devices . . . . . . . . . . . . . 111
Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 112
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)を使用します。クライアントはXML
[W3C.REC-xml-20001006]でRPCをコード化し、安全で接続指向のセッション
を使用して、RPCをサーバに送ります。サーバはXMLでコード化されている回
答を返します。双方がコンテンツの構文を認識できるように、要求と応答の
両方のコンテンツはXML DTDかXML schemasかまたは両方で完全に記述されま
す。
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は対話と、柔
軟で階層的な内容のコード化を完全に定義しているが、共通語です。XSLT
[W3C.REC-xslt-19991116]などのXMLベースの変換技術を利用し、全部また
は一部の構成の自動化システムを提供するのにNETCONFを使用できます。シ
ステムはネットワークトポロジーとリンクとポリシーと顧客とサービスに
関するデータのため、データベースに質問できます。このデータは、XSLT
スクリプトを使用して、タスクに依存形式や、ベンダー・製品・オペレー
ティングシステム・ソフトウェアリリースを指定するベンダ独立の形式に
変換できます。NETCONFプロトコルを使用することで変換結果のデータをデ
バイスに渡せます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と
"OPTIONAL"はRFC2119[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.
クライアント：サーバー上でプロトコルオペレーションを実施します。
これに加えて、クライアントは、サーバーから通知書を受信する予約が
できます。
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.
通知：特定のイベントがサーバーで認識されたことを示しているサーバー
から送られたメッセージ。
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.
サーバー：クライアントが起動するプロトコルオペレーションを実行しま
す。これに加えて、サーバーは通知をクライアントに送信することができ
ます。
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.
ユーザー：クライアントの認証された識別子。クライアントの認証された
識別子は一般に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セッションとはネットワーク管理者やネットワーク設定アプリケーショ
ンと、ネットワークデバイスとの間の論理的な関係です。デバイスは、少なくと
も１つのNETCONFセッションをさぽーとしなければならず(MUST)と複数のセッ
ションをサポートすべきです(SHOULD)。全ての認可されたセッション中に、グ
ローバル構成属性を変えることができ、その効果はすべてのセッションに影響
します。セッション固有属性は変更を行ったセッションだけに影響します。
NETCONF can be conceptually partitioned into four layers as shown in
Figure 1.
図１に示すように、概念的にNETCONFを４層に分離できます。
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.
セキュアトランスポート層はクライアントとサーバの間の通信路
を提供します。基本的な要件を提供する任意のトランスポート・プロ
トコル上で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.
オペレーション層は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.
コンテンツ層はこの文書の範囲外です。標準のデータ定義言語と標準のコ
ンテンツ指定する別の取り組みが引き続き行われると予想されます。
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.
NETCONFデータモデルとプロトコルオペレーションを指定するために、YANGデー
タモデル化言語[RFC6020]が開発され、これは図１のオペレーションをコンテ
ンツ層に対応します。
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基本仕様を補う機能です。能力はリソース識別子(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.
能力定義は依存する能力の名前を指定するかもしれません。ある能力をサポー
トするためには、サーバはその能力が依存するすべての能力もサポートしなけ
ればなりません(MUST)。
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は名前の衝突を避けるため命名者の区別をしなければなりま
せん(MUST)。
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:
実行システムから検索できる情報はコンフィグレーションデータと状態データ
の２種類に分かれます。コンフィギュレーションデータはシステムを初期のデ
フォルト状態から現状に変えるのに必要である書き込み可能なデータです。状
態データは読込専用状態情報や統計情報など設定が行われないシステムの追加
にデータです。デバイスが設定オペレーションを実行しているとき、状態デー
タが含まれているなら、多くの問題が起こるでしょう:
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.
格納されたデータは書込禁止データ項目の値を含むかもしれず、バック
アップデータからの復旧処理が複雑になります。
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ベースの通信をします。クライアントは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プロトコル層のセッションタイプ
(クライアントかサーバ)を示すメカニズムを提供しなければなりません(MUST)。
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は接続指向で、２者間の永続的接続を必要とします。この接続は信頼
でき、直列データの配送を提供しなければなりません(MUST)。NETCONF接続は
プロトコルオペレーションの間に継続し長命です。
In addition, resources requested from the server for a particular
connection MUST be automatically released when the connection closes,
making failure recovery simpler and more robust. For example, when a
lock is acquired by a client, the lock persists until either it is
explicitly released or the server determines that the connection has
been terminated. If a connection is terminated while the client
holds a lock, the server can perform any appropriate recovery. The
<lock> operation is further discussed in Section 7.5.
さらに、障害回復をより簡単でより強健にするため、接続が終わると個別の
接続のためのサーバから要求された資源は自動的に開放しなければなりませ
ん。例えば、クライアントがロックをしている時、ロックが明示的に解放さ
れるか、サーバが接続が終了したと決定するまで、ロックは持続します。ク
ライアントがロックをしたまま接続が終えたなら、サーバは適切な回復処理
を実行できます。7.5章でロック操作についてさらに議論します。
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接続は認証と完全性と秘密性を提供しなければなりません(MUST)。
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接続は認証しなければなりません(MUST)。トランスポート・プロトコ
ルはクライアントへのサーバ認証とサーバへのクライアント認証の責任があ
ります。NETCONFの当事者は接続の認証情報が十分信頼できるメカニズムを使
用する下位プロトコルによって有効にされ、通信相手の同一性が検証された
と仮定します。
One goal of NETCONF is to provide a programmatic interface to the
device that closely follows the functionality of the device's native
interface. Therefore, it is expected that the underlying protocol
uses existing authentication mechanisms available on the device. For
example, a NETCONF server on a device that supports RADIUS [RFC2865]
might allow the use of RADIUS to authenticate NETCONF sessions.
NETCONFの1つの目標はデバイスのネイティブのインタフェースの機能に密接
に従うデバイスのプログラム用インタフェースを供給することです。したがっ
て、下位プロトコルがデバイスで利用可能な既存の認証機構を使用すると予想
されます。例えば、RADIUS [RFC2865]をサポートするデバイスは、NETCONFセッ
ションを認証するのにRADIUSを使用でしょう。
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.
認証プロセスは、サーバーが権限を判定できる認証されたクライアント識別
子を返さなければなりません(MUST)。クライアントの認証された識別子は一
般にNETCONFユーザー名と呼ばれます。ユーザー名は[W3C.REC-xml-20001006]
の2.2章の"Char"に従った文字列です。ユーザー名を得るのに用いられるア
ルゴリズムはトランスポートプロトコル固有で、トランスポートプロトコル
の使った認証メカニズムに特有です。トランスポートプロトコルは、他の
NETCONF層で使うためのユーザー名を提供しなければなりません(MUST)。
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セッションの間に適用されなければなりません(MUST)。アクセス制
御がどのように構成されるの詳細はこの文書の範囲外です。
2.3. Mandatory Transport Protocol
2.3. 義務的なトランスポート・プロトコル
A NETCONF implementation MUST support the SSH transport protocol
mapping [RFC6242].
NETCONF実装は、SSH[RFC6242].をトランスポート・プロトコルとしてサポー
トしなければなりません。
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メッセージは整形式XMLで、UTF-8[RFC3629]でコード化し
なければなりません (MUST)。整形式XMLでないかUTF-8でコード化されてい
ない<rpc>を受信した当事者は"malformed-message"を返すべきです(SHOULD)。
何らかの理由で応答を送れないならば、サーバーはセッションを終了しなけ
ればなりません(MUST)。
A NETCONF message MAY begin with an XML declaration (see Section 2.8
of [W3C.REC-xml-20001006]).
NETCONFメッセージはXML宣言から始まるかもしれません(MAY)
（[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]に違いありません(MUST)。8章でNETCONF
能力について議論します。
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はトランスポート・プロトコルから独立したNETCONF要求と応答のフ
レーミングを提供するのに<rpc>と<rpc-reply>要素を使います。
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.
クライアントからサーバーに送信されるNETCONF要求を囲むのに、<rpc>要素
が用いられます。
The <rpc> element has a mandatory attribute "message-id", which is a
string chosen by the sender of the RPC that will commonly encode a
monotonically increasing integer. The receiver of the RPC does not
decode or interpret this string but simply saves it to be used as a
"message-id" attribute in any resulting <rpc-reply> message. The
sender MUST ensure that the "message-id" value is normalized
according to the XML attribute value normalization rules defined in
[W3C.REC-xml-20001006] if the sender wants the string to be returned
unmodified. For example:
<rpc>要素は必須属性"message-id"を持ちます、これはRPCの送信者が選ぶ文
字列で、普通は単調増加する整数をコード化したものです。RPCの受信者はこ
の文字列を解読や解釈せず、応答で返す<rpc-reply>メッセージの"message-id"
属性に使用するために保存します。送信者は文字列が変更されずに返される
事を望むならば、送信者は[W3C.REC-xml-20001006]で定められるXML属性値正
規化規則に従って"message-id"値を正規化されていることを確実にしなけれ
ばなりません(MUST)。例えば:
<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>要
素に変更せずに設定しなければなりません(MUST)。これは"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>と呼ばれる、値が"14"の<my-first-parameter>と
値が"fred"の<another-parameter>と、２つのパラメータを持つメソッドを示
します：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<my-own-method xmlns="http://example.net/me/my-own/1.0">
<my-first-parameter>14</my-first-parameter>
<another-parameter>fred</another-parameter>
</my-own-method>
</rpc>
The following example invokes a <rock-the-house> method with a
<zip-code> parameter of "27606-0100":
以下の例は、値が"27606-0100"の<zip-code>を持つ<rock-the-house>
メソッドを起動します：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
The following example invokes the NETCONF <get> method with no
parameters:
以下の例は、パラメータなしのNETCONF <get>メソッドを起動します：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
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>要素に含まれる他の属性を修正なしで<rpc-reply>要素
で返さなければなりません(MUST)
The response data is encoded as one or more child elements to the
<rpc-reply> element.
応答データは<rpc-reply>要素のコンテンツとしてコード化されます。
For example:
たとえば：
The following <rpc> element invokes the NETCONF <get> method and
includes an additional attribute called "user-id". Note that the
"user-id" attribute is not in the NETCONF namespace. The returned
<rpc-reply> element returns the "user-id" attribute, as well as the
requested content.
以下の<rpc>要素はNETCONF <get>メソッドとして起動され、"user-id"とい
う属性を含みます。"user-id"属性がNETCONF名前空間にないことに注意して
ください。返された<rpc-reply>要素は要求されたコンテンツだけでなく
"user-id"属性も返します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<data>
<!-- contents here... -->
</data>
</rpc-reply>
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>要素が含まれるかもしれません(MAY)。しかし、要求に複数のエ
ラーがある場合に、サーバーが複数の<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.
Enumeration. One of:
エラーが発生した概念上のレイヤを示します。列挙型。以下の1つ：
* 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-severity: Contains a string identifying the error severity, as
determined by the device. One of:
デバイスが決めたエラーの程度を示す文字列を含みます。以下の1つ：
* 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.
"warning"列挙を利用する<error-tag>値がこの文書で定義されない点に注
意してください。これは、将来の使用のために予約されています。
error-app-tag: Contains a string identifying the data-model-specific
or implementation-specific error condition, if one exists. This
element will not be present if no appropriate application error-
tag can be associated with a particular error condition. If a
data-model-specific and an implementation-specific error-app-tag
both exist, then the data-model-specific value MUST be used by the
server.
もしあれば、データモデル固有か実装固有のエラー状態を示す文字列を含
みます。適切なアプリケーションエラータグが特定のエラー状態と関係し
ていることがありえないならば、この要素は存在しません。データモデル
固有と実装固有のエラーアプリタグの両方があるならば、データモデル
固有の値をサーバは用いなければなりません(MUST)。
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.
<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].
エラー状態を記述する人間が読みやすい文字列を含みます。適切なメッ
セージが特定のエラー状態に対して用意されていないならば、この要素
は存在しません。この要素は[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コンテナ内にアプリケーション層エラー情報を含めることを、
データ・モデル定義は命じるかもしれません(MAY)。拡張や実装特有のデ
バッグ情報を提供するために、実装は追加の要素を含めるかもしれません
(MAY)。
Appendix A enumerates the standard NETCONF errors.
付録Ａは、標準的なNETCONFエラーを列挙します。
Example: An error is returned if an <rpc> element is received
without a "message-id" attribute. Note that only in this case is
it acceptable for the NETCONF peer to omit the "message-id"
attribute in the <rpc-reply> element.
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.
この章の例で使われるデータ・モデルで複数の<interface>要素を区別する
のに<name>要素をを使用する点に注意してください。
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
</error-path>
<error-message xml:lang="en">
MTU value 25000 is not within range 256..9192
</error-message>
</rpc-error>
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
</error-path>
<error-message xml:lang="en">
Invalid IP address for interface Ethernet1/0
</error-message>
</rpc-error>
</rpc-reply>
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:
<ok>要素は、<rpc>の処理中にエラーも警告状態も起きなかった際に、
<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>要求は管理対象装置で並列処理されなければなりません(MUST)。
前の処理が終わる前に次の<rpc>が送られるかもしれません(MAY)。管理対
象装置は要求を受け取ったと順序で応答を返します(MUST)。
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は、拡張の基礎として、最初のオペレーションと能力を提供します。
セッションが8.1章で書かれ様に始められるとき、NETCONFは装置間でデバイス
能力を交渉します。
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はコンフィグレーションデータストアの存在を定めて、コンフィグ
レーションデータストアのコンフィグレーションのオペレーションを許し
ます。コンフィグレーションデータストアは、デバイスを初期状態から望
ましい作動状態に変更するために必要な完全なコンフィグレーションデー
タと定義されます。コンフィグレーションデータストアは、状態データま
たは実行コマンドを含みません。
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.
ランニングコンフィグレーションデータストアは、ネットワークデバイスで
現在有効なコンフィグレーションを維持します。デバイスでこの種類のコン
フィグレーションデータストアは１つだけ存在し、常に存在します。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>コンフィグレーションデータストアだけが存在
します。能力によって、追加のコンフィグレーションデータストアが、定
義されるかもしれません(MAY)。このようなコンフィグレーションデータ
ストアは、この能力を公表するデバイスでだけで利用可能です。
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サブツリーフィルタリングは、アプリケーションが<get>や<get-config>
オペレーションに対する<rpc-reply>に含める特定のXMLサブツリーを選ぶ
のを可能とするメカニズムです。包含と、単純な内容完全一致と、選択の
フィルタが提供され、これは役に立ちますが、限定的でもある選択メカニ
ズムを構成します。サーバーはフィルター処理は処理の間にデータモデル
特有の意味を利用する必要はなく、単純で集中化した実装を考慮します。
Conceptually, a subtree filter is comprised of zero or more element
subtrees, which represent the filter selection criteria. At each
containment level within a subtree, the set of sibling nodes is
logically processed by the server to determine if its subtree and
path of elements to the root are included in the filter output.
概念的に、サブツリー・フィルタは0以上の要素のサブツリーから成り、これ
はフィルタ選択基準を意味します。サブツリーの中の各レベルで、そのサブ
ツリーとルートへの要素パスがフィルタ出力に含まれるかどうか決定するた
めに、サーバは兄弟ノードを論理的に処理します。
Each node specified in a subtree filter represents an inclusive
filter. Only associated nodes in underlying data model(s) within the
specified datastore on the server are selected by the filter. A node
is selected if it matches the selection criteria and hierarchy of
elements given in the filter data, except that the filter absolute
path name is adjusted to start from the layer below <filter>.
サブツリー・フィルタで指定されている各々のノードは包含フィルタを意味
します。サーバーの指定されたコンフィグレーションデータストアの中にあ
るデータモデルに関するノードだけ、フィルタで選ばれます。フィルタ絶対
パス名が<filter>階層の下にある場合を除き、フィルタ・データで伝えられ
る要素の選択基準と階層に一致するノードだけ、フィルタで選ばれます。
Response messages contain only the subtrees selected by the filter.
Any selection criteria that were present in the request, within a
particular selected subtree, are also included in the response. Note
that some elements expressed in the filter as leaf nodes will be
expanded (i.e., subtrees included) in the filter output. Specific
data instances are not duplicated in the response in the event that
the request contains multiple filter subtree expressions that select
the same data.
応答メッセージはフィルタで選ばれるサブツリーだけを含みます。要求に存
在した選択基準と特定の選ばれたサブツリーも応答にも含まれます。フィル
タで末端ノードとして表されるいくつかの要素がフィルタ出力で拡大（すな
わち、サブツリーが含められる）ことに注意すべきです。要求に同じデータ
を選ぶ複数のフィルタ・サブツリー表現が含まれる場合に、応答でこのデー
タを重複させません。
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属性から成ります。サブツリー・
フィルタに存在できる５種類の構成要素があります：
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名前空間がデータモデルの名前空間と同じということです。名前
空間選択が単独で使えないことに注意してください。なんらかの要素をフィ
ルタ出力に入れたければ、最低１つの要素を指定しなければなりません(MUST)。
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名前空間を評価しなければなりません (MUST)。この
ワイルドカードメカニズムは、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属性が、どんな種類のフィルタ・ノードにで
も存在する場合があります(MAY)。通常そのノードに適用できる選択基準
に加えて、選ばれたデータは、ノードで指定されているあらゆる属性の
適合する値に対応しなければなりません(MUST)。指定された属性で含むと
定められていない要素は、フィルタ出力で選ばれません。
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'の'interface'ノードで、値が
'eth0'の'ifName'属性があり、'top'ノード下の'interfaces'ノードとして
現れるノードは、フィルタ出力に含まれます。
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"名前空間にあり、コンフィグレー
ションデータストアのルートの<top>要素内の"users"ノードだけ、フィルタ
出力に含まれます。
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.
コンテンツ一致ノードは、入れ子の要素を含んではいけません(MUST NOT)。
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/>).
コンテンツ一致ノードは空白でない文字を含まなければなりません(MUST)。
空の要素（例えば<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:
サブツリー・フィルタ表現のすべての指定された兄弟のコンテンツ一致ノー
ドが"真"ならば、フィルタ出力ノードは以下の方法で選ばれます：
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)。
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).
兄弟のコンテンツ一致ノードのテストのいずれかが'偽'ならば、兄弟のフィル
タ処理は実行されません、そして、コンテンツ一致ノードも含め兄弟のサブツ
リーのどれもフィルタで選ばれません。
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.
各々のサブツリー・フィルタは一つ以上のデータ・モデルの一部分を含むこ
とができ、これはデータ・モデルのフィルタ出力で選ばれるであろう部分
（すべての子ノード）を表します。
Each subtree data fragment is compared by the server to the internal
data models supported by the server. If the entire subtree data-
fragment filter (starting from the root to the innermost element
specified in the filter) exactly matches a corresponding portion of
the supported data model, then that node and all its children are
included in the result data.
各々のサブツリー・データ断片は、サーバーでサポートされる内部のデータ
モデルと、サーバーによって比較されます。全てのサブツリーデータ部分
フィルタ（ルートから始まりフィルタで指定されている一番奥の要素まで）
が正確にサポートされたデータ・モデルの対応する分に一致するならば、
そのノードとすべてのその子ノードが結果データに含まれます。
The server processes all nodes with the same parent node (sibling
set) together, starting from the root to the leaf nodes. The root
elements in the filter are considered in the same sibling set
(assuming they are in the same namespace), even though they do not
have a common parent.
サーバーは、ルートから末端ノードに向かい、同じ親ノード（兄弟の集合）
のすべてのノードを同時に処理します。フィルタのルートノードは、共通の
親がいないですが、（同じ名前空間にいるならば）同じ兄弟ノードと考えま
す。
For each sibling set, the server determines which nodes are included
(or potentially included) in the filter output, and which sibling
subtrees are excluded (pruned) from the filter output. The server
first determines which types of nodes are present in the sibling set
and processes the nodes according to the rules for their type. If
any nodes in the sibling set are selected, then the process is
recursively applied to the sibling sets of each selected node. The
algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.
各兄弟ごとに、サーバーはどのノードがフィルタ出力に含まれるか（または
潜在的に含まれうるか）、そしてどの兄弟のサブツリーがフィルタ出力から
除外されるか決定します。サーバーは、最初にどの種類のノードが兄弟に存
在するかについて決定して、彼らの種別毎の規則に従って、ノードを処理し
ます。兄弟のあるノードが選ばれるならば、選ばれたノードの兄弟に再帰的
に処理が適用されます。フィルタで指定されているすべてのサブツリーのす
べての兄弟のセットが処理されるまで、アルゴリズムは続きます。
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>
<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.
この例のフィルタは１つの選択ノード（<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"に現れます。この名前空
間のroot要素は<top>です。<top>要素とその子は、コンフィギュレーション
データ・モデルの例でしかありません。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
<user>
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
<company-info>
<dept>2</dept>
<id>3</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
The following filter request would have produced the same result, but
only because the container <users> defines one child element
(<user>).
以下のフィルタ要求は同じ結果をもたらしますが、コンテナ<users>で１つの
子要素(<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>
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.
このフィルタは、２つの内包ノード(<users>, <user>)と１つの選択ノード
(<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>
6.4.5. One Specific <user> Entry
6.4.5. １つの特定の<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.
このフィルタは、２つの内包ノード(<users>, <user>)と１つのコンテンツ一
致ノード(<name>)を含みます。<name>を含む兄弟のすべてから、<name>が
"fred"に等しいのがフィルタ出力で選ばれます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
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.
このフィルタは、２つの内包ノード(<users>, <user>)と１つのコンテンツ一
致ノード(<name>)と２つの選択ノード(<type>, <full-name>)を含みます。
同じ兄弟から<type>と<full-name>要素は<name>を含み、<name>の値が"fred"
のものがフィルタ出力で選ばれます。兄弟のセットが選択ノードを含むので、
<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>
6.4.7. Multiple Subtrees
6.4.7. 複数のサブツリー
This filter contains three subtrees (name=root, fred, barney).
このフィルタは、３つのサブツリー(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.
"root"サブツリー・フィルタは、２つの内包ノード(<users>,<user>)、１つ
のコンテンツ一致ノード(<name>)と、１つの選択ノード(<company-info>)を
含みます。サブツリー選択基準を適用し、そして、"root"のcompany-infoサ
ブツリーは、フィルタ出力で選ばれます。
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"サブツリー・フィルタは、３つの内包ノード(<users>, <user>,
<company-info>)、１つのコンテンツ一致ノード(<name>)と、１つの選択ノー
ド(<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"サブツリー・フィルタは、３つの内包ノード(<users>, <user>,
<company-info>)、２つのコンテンツ一致ノード(<name>, <type>)と、１つの
選択ノード(<dept>)を含みます。ユーザ"barney"は"superuser"ではないので
サブツリー選択基準が適用されません、そして"barney"の全てのサブツリー
（親となる<user>項目を含む）が、フィルタ出力から除外されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<type>superuser</type>
<company-info>
<dept/>
</company-info>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
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.
この例では、フィルタは１つの内包ノード(<interfaces>)と、１つの属性一
致表現("ifName")と、１つの選択ノード(<interface>)を含みます。"ifName"属性
が"eth0"である<interface>サブツリーのすべての要素はフィルタ出力で選ば
れます。指定がないので"ifName"属性は"schema/1.2"名前空間の一部と考えら
れないので、フィルタ・データ・要素と属性は制限されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0">
<t:ifInOctets>45621</t:ifInOctets>
<t:ifOutOctets>774344</t:ifOutOctets>
</t:interface>
</t:interfaces>
</t:top>
</data>
</rpc-reply>
If "ifName" were a child node instead of an attribute, then the
following request would produce similar results.
"ifName"が属性でなく子ノードであるならば、以下の要求は類似した結果をも
たらすでしょう。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
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.
プロトコルオペレーションは、"オペレーションをサポートしていない"とい
う理由を含め、いろいろな理由で失敗する場合があります。オペレーション
の開始者は、いかなるオペレーションも常に成功すると仮定すべきではあり
ません(SHOULD NOT)。エラー応答の確認のために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>
Description: Retrieve all or part of a specified configuration
datastore.
説明：指定されたコンフィグレーションの全部または一部を読み出す。
Parameters:
パラメータ：
source: Name of the configuration datastore being queried, such
as <running/>.
問い合わせるコンフィグレーションデータストアの名前、例えば
<running/>。
filter: This parameter identifies the portions of the device
configuration datastore to retrieve. If this parameter is not
present, the entire configuration is returned.
このパラメータは、デバイスコンフィグレーションデータストアの読み
出す部分を指定します。この要素を指定しないならば、全てのコンフィ
グレーションを返します。
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"属性を含むかもしれません(MAY)。この属性は、フィ
ルタ要素内で使われるフィルター構文の種類を示します。NETCONFのデ
フォルトのフィルタリング・メカニズムは、サブツリー・フィルタリ
ングと呼ばれて、6章で記述されます。"subtree"は、このフィルタリ
ングを明確に指定します。
If the NETCONF peer supports the :xpath capability
(Section 8.9), the value "xpath" MAY be used to indicate that
the "select" attribute on the <filter> element contains an
XPath expression.
もしNETCONFの実装が:xpath能力(8.9章)をサポートするならば、
<filter>要素の"select"属性がXPath表現を含むことを示すのに
"xpath"を用いるかもしれません(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>
<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>
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.
<config>サブツリーの要素は、"operation"属性を含むかもしれません。
この属性はコンフィグレーションのオペレーションを実行する部分を特
定し、<config>サブツリーの複数の要素に現れるかもしれません(MAY)。
If the "operation" attribute is not specified, the
configuration is merged into the configuration datastore.
"operation"属性が指定されないならば、コンフィグレーションは
コンフィグレーションデータストアに合併されます。
The "operation" attribute has one of the following values:
"operation"属性は、以下の値の１つを持ちます：
merge: The configuration data identified by the element
containing this attribute is merged with the configuration
at the corresponding level in the configuration datastore
identified by the <target> parameter. This is the default
behavior.
<target>パラメータで示されるコンフィグレーションデータスト
アで、この属性を含む要素で指定されるコンフィグレーションデー
タは、対応するレベルでコンフィグレーションに合併されます。
これは、デフォルト振舞いです。
replace: The configuration data identified by the element
containing this attribute replaces any related configuration
in the configuration datastore identified by the <target>
parameter. If no such configuration data exists in the
configuration datastore, it is created. Unlike a
<copy-config> operation, which replaces the entire target
configuration, only the configuration actually present in
the <config> parameter is affected.
<target>パラメータによって確認されるコンフィグレーションデー
タストアで、この属性を含んでいる要素で指定されるコンフィグレー
ションデータは、関連したコンフィグレーションで置き換えられま
す。コンフィグレーションデータストアで関連したコンフィグレー
ションがなければ、作られます。<copy-config>オペレーションが
全てのターゲットコンフィグレーションを置き換えるのと違い、
<config>パラメータにあるコンフィグレーションだけは、影響を受
けます。
create: The configuration data identified by the element
containing this attribute is added to the configuration if
and only if the configuration data does not already exist in
the configuration datastore. If the configuration data
exists, an <rpc-error> element is returned with an
<error-tag> value of "data-exists".
コンフィグレーションデータがコンフィグレーションデータストア
にすでに存在しない場合に限り、この属性を含む要素で指定される
コンフィグレーションデータはコンフィグレーションに加えられま
す。コンフィグレーションデータが存在するならば、"data-exists"
が設定される<error-tag>を含む<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.
この属性に含まれる要素で指定されるコンフィグレーションデータ
は、コンフィグレーションデータストアの中に存在する場合、コン
フィグレーションから削除されます。コンフィグレーションデータ
が存在しないならば、"remove"オペレーションはサーバーで黙って
無視されます。
Parameters:
パラメータ：
target: Name of the configuration datastore being edited, such as
<running/> or <candidate/>.
<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".
この<edit-config>要求のデフォルト動作（"operation"属性で定める
動作）を選択します。<default-operation>パラメータのデフォルト値
は"merge"です。
The <default-operation> parameter is optional, but if provided,
it has one of the following values:
<default-operation>パラメータの設定は任意な設定ですが、設定する
ならば以下の値の１つです：
merge: The configuration data in the <config> parameter is
merged with the configuration at the corresponding level in
the target datastore. This is the default behavior.
<config>パラメータで示されるコンフィグレーションデータはター
ゲットコンフィグレーションデータストアの対応するレベルのコ
ンフィグレーションに合併されます。これは、デフォルトふるま
いです。
replace: The configuration data in the <config> parameter
completely replaces the configuration in the target
datastore. This is useful for loading previously saved
configuration data.
<config>パラメータで示されるコンフィグレーションデータはター
ゲットコンフィグレーションデータストアのコンフィグレーション
を置き換えます。これは、過去に保存したコンフィグレーションデー
タをロードする際に有用です。
none: The target datastore is unaffected by the configuration
in the <config> parameter, unless and until the incoming
configuration data uses the "operation" attribute to request
a different operation. If the configuration in the <config>
parameter contains data for which there is not a
corresponding level in the target datastore, an <rpc-error>
is returned with an <error-tag> value of data-missing.
Using "none" allows operations like "delete" to avoid
unintentionally creating the parent hierarchy of the element
to be deleted.
入力コンフィグレーションデータが"operation"属性を使用して他
の動作を指定しない限り、<config>パラメータのコンフィグレーショ
ンでターゲットデータストアは変更しません。もし<config>パラメー
タがターゲットデータストアに対応するレベルがないのコンフィグ
レーションを含むなら、data-missingを設定した<error-tag>を含む
<rpc-error>が返されます。"none"を使うことで、意図しない削除さ
れる要素の親階層を構築を避けれます。
test-option: The <test-option> element MAY be specified only if
the device advertises the :validate:1.1 capability
(Section 8.6).
<test-option>要素はデバイスが:validate能力（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.
設定する前に検証を実施。もし検証でエラーが発生するならば
<edit-config>操作を行いません。これはtest-optionのデフォル
トです。
set: Perform a set without a validation test first.
最初に確認テストなしで設定を実行します。
test-only: Perform only the validation test, without
attempting to set.
設定することなく、確認テストだけを実行します。
error-option: The <error-option> element has one of the following
values:
<error-option>要素は、以下の値の１つです：
stop-on-error: Abort the <edit-config> operation on first
error. This is the default error-option.
最初のエラーで<edit-config>操作を中止。これはerror-optionの
デフォルトです。
continue-on-error: Continue to process configuration data on
error; error is recorded, and negative response is generated
if any errors occur.
エラーとなったコンフィグレーションデータの処理を続行;エラー
は記録されます、そして、エラーが発生するならば、エラー応答が
発生します。
rollback-on-error: If an error condition occurs such that an
error severity <rpc-error> element is generated, the server
will stop processing the <edit-config> operation and restore
the specified configuration to its complete state at the
start of this <edit-config> operation. This option requires
the server to support the :rollback-on-error capability
described in Section 8.5.
<rpc-error>要素が生成されるようなエラー状態が起こると、サー
バーは<edit-config>処理を止めて、指定したコンフィグレーショ
ンを<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.
デバイスのデータ・モデルの１つで定義されるコンフィグレーショ
ンデータの階層。デバイスが適切なデータモデルを認識するため、
コンテンツは適切な名前空間に置かれなければならず(MUST)、その
能力定義によって定義されるようにコンテンツがデータモデルの制
約に従わな変えればなりません(MUST)。能力は、8章で論じられます。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent containing an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> response is sent if the request
cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>応答が
送られます。
Example: The <edit-config> examples in this section utilize a simple
data model, in which multiple instances of the <interface> element
can be present, and an instance is distinguished by the <name>
element within each <interface> element.
例：この章の<edit-config>の例は単純なデータ・モデルを使用し、モデルは
複数の'interface'要素があり、<interface>要素は要素内の<name>要素で
区別されます。
Set the MTU to 1500 on an interface named "Ethernet0/0" in the
running configuration:
ランニングコンフィグレーションの"Ethernet0/0"という名前のインター
フェースで、MTUを1500にします：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Add an interface named "Ethernet0/0" to the running configuration,
replacing any previous interface with that name:
ランニングコンフィギュレーションに"Ethernet0/0"という名前のインター
フェースを追加し、その名前の前のインターフェースと置換します：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete the configuration for an interface named "Ethernet0/0" from
the running configuration:
ランニングコンフィギュレーションから"Ethernet0/0"という名前のイン
ターフェースを削除します：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete interface 192.0.2.4 from an OSPF area (other interfaces
configured in the same area are unaffected):
OSPFエリアから192.0.2.4インターフェースを削除します(同じエリアの
他のインターフェースは変更しません）：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<protocols>
<ospf>
<area>
<name>0.0.0.0</name>
<interfaces>
<interface xc:operation="delete">
<name>192.0.2.4</name>
</interface>
</interfaces>
</area>
</ospf>
</protocols>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.3. <copy-config>
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章）をサポートするなら、<source>か
<target>要素に<url>要素が現れることができます。
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能力を通知するなら、デバイスは<copy-config>
操作の<target>パラメータで<running/>をサポートしないかもしれませ
ん(MAY)。デバイスは遠隔から遠隔へのコピー操作をサポートしないか
もしれず、<source>と<target>の両パラメータで<url>要素を使えない
かもしれません(MAY)。もしソースとターゲットパラメータが同じURLま
たはコンフィグレーションデータストアを示すなら、invalid-valueの
error-tagを含むエラーを返さなければなりません(MUST)。
Parameters:
パラメータ：
target: Name of the configuration datastore to use as the
destination of the <copy-config> operation.
<copy-config>オペレーションで宛先に使用するコンフィグレーションデータ
ストアの名前。
source: Name of the configuration datastore to use as the source
of the <copy-config> operation, or the <config> element
containing the complete configuration to copy.
<copy-config>オペレーションのコピー元のコンフィグレーションデー
タストアの名前、あるいは、コピーする全コンフィグレーションを含む
<config>要素。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> element is included within the
<rpc-reply> if the request cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user:password@example.com/cfg/new.txt</url>
</source>
</copy-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.4. <delete-config>
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章)をサポートするならば、<target>パラ
メータに<url>要素を設定できます。
Parameters:
パラメータ：
target: Name of the configuration datastore to delete.
削除するコンフィグレーションデータストアの名前。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> element is included within the
<rpc-reply> if the request cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.5. <lock>
Description: The <lock> operation allows the client to lock the
entire configuration datastore system of a device. Such locks are
intended to be short-lived and allow a client to make a change
without fear of interaction with other NETCONF clients, non-
NETCONF clients (e.g., SNMP and command line interface (CLI)
scripts), and human users.
説明： <lock>オペレーションは、クライアントがデバイスの全コンフィグ
レーションデータストアシステムをロックするのを許可します。このロッ
クは短命と想定され、依頼者が他のNETCONFクライアントや、NETCONFク
ライアントでない者（例えばSNMPやコマンドラインインターフェース
（CLI）スクリプト）や人間のユーザーとの対話の影響を心配せずに変更
をすることを、意図します。
An attempt to lock the configuration datastore MUST fail if an
existing session or other entity holds a lock on any portion of
the lock target.
既存のセッションまたは他者がロック対象のどこかにロックを持つならば、
コンフィグレーションデータストアのロックの試みが失敗しなければなり
ません(MUST)。
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.
ロックが得られると、サーバーはこのセッションで要求される変更を除き、
ロックされた資源への全ての変更を禁止しなければなりません(MUST)。リ
ソースを変更するSNMPとCLIの要求は適切なエラーで失敗しなければなり
ません(MUST)。
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セッションで認められません。その上、システムは確実にこれら
のロックされたコンフィグレーション資源が他のNETCONF以外の管理操作
（例えばSNMPとCLI）によって修正されないようにします。<kill-session>
オペレーションは他のNETCONFセッションの所有するロックの解放の強制に
用いることができます。他の者が持つロックを解放する方法を定めること
は、この文書の範囲外です。
A lock MUST NOT be granted if any of the following conditions is
true:
以下の状況のいずれかの場合に、ロックを与えてはなりません(MUST NOT)：
* 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>を返します(MUST)。
A lock will be released by the system if the session holding the
lock is terminated for any reason.
何らかの理由でロックをもつセッションが終了したら、ロックはシステム
によって解放されます。
Parameters:
パラメータ：
target: Name of the configuration datastore to lock.
ロックするコンフィグレーションデータストアの名前。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that contains an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
If the lock is already held, the <error-tag> element will be
"lock-denied" and the <error-info> element will include the
<session-id> of the lock owner. If the lock is held by a non-
NETCONF entity, a <session-id> of 0 (zero) is included. Note that
any other entity performing a lock on even a partial piece of a
target will prevent a NETCONF lock (which is global) from being
obtained on that target.
もしロックが存在するなら<error-tag>要素は"lock-denied"で、<error-info>
要素はロック所有者の<session-id>を含みます。ロックがNETCONF以外で
保持されるならば０（ゼロ）の<session-id>を含みます。たとえ部分的な
ロックであっても、ターゲットのロックを持つ者は、そのターゲットの
（全体の）NETCONFロックを妨げることに注意すべきです。
Example: The following example shows a successful acquisition of a
lock.
例：以下の例は、ロックの成功した取得を示します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <!-- lock succeeded -->
</rpc-reply>
Example: The following example shows a failed attempt to acquire a
lock when the lock is already in use.
例：以下の例は、ロックがすでに使用中であるとき、ロックを得る失敗した
試みを示します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <!-- lock failed -->
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>
<!-- lock is held by NETCONF session 454 -->
</error-info>
</rpc-error>
</rpc-reply>
7.6. <unlock>
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>を返さなければなりません(MUST)。
Parameters:
パラメータ：
target: Name of the configuration datastore to unlock.
ロックを外すコンフィグレーションデータストアの名前。
A NETCONF client is not permitted to unlock a configuration
datastore that it did not lock.
NETCONFクライアント、自身でロックを得ていないコンフィグレー
ションデータストアのロックの解放は許されません。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that contains an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.7. <get>
Description: Retrieve running configuration and device state
information.
説明：ランニングコンフィグレーションとデバイス状態を検索。
Parameters:
パラメータ：
filter: This parameter specifies the portion of the system
configuration and state data to retrieve. If this parameter is
not present, all the device configuration and state information
is returned.
このパラメータは、システムコンフィグレーションの状態情報の検索
する部分を指定します。このパラメータが存在しないならば、すべて
のデバイスコンフィグレーションと状態情報が返されます。
The <filter> element MAY optionally contain a "type" attribute.
This attribute indicates the type of filtering syntax used
within the <filter> element. The default filtering mechanism
in NETCONF is referred to as subtree filtering and is described
in Section 6. The value "subtree" explicitly identifies this
type of filtering.
<filter>要素は"type"属性を含むかもしれません(MAY)。この属性は
<filter>要素内で使われるフィルタリング構文の種類を示します。
NETCONFのデフォルトのフィルタリング・メカニズムは、サブツリー・
フィルタリングと呼ばれて、6章で記述されます。値"subtree"は、
この種類のフィルタリングを明示的に示します。
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章)を持つならば、<filter>要素の
"select"属性がXPath表現を含むことを示すのに値"xpath"が用いら
れるかもしれません(MAY)。
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>
Description: Request graceful termination of a NETCONF session.
説明： NETCONFセッションの上品な終了を要求。
When a NETCONF server receives a <close-session> request, it will
gracefully close the session. The server will release any locks
and resources associated with the session and gracefully close any
associated connections. Any NETCONF requests received after a
<close-session> request will be ignored.
NETCONFサーバーが<close-session>を受けるとき、セッションを上品に終
了します。サーバーはセッションに関連したすべてのロックと資源を解放
し、上品に関連する接続を終了します。<close-session>要求の受信後は全
てのNETCONF要求を無視します。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
正常応答：デバイスが要求に応えられるならば、<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>
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>
を受けるならば、コミットを立証をする前の状態にコンフィグレーション
を戻さなければなりません(MUST)。
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.
終了させるNETCONFセッションのセッション識別子。この値が現在の
セッションIDと等しいならば、"invalid-value"エラーが返されます。
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
正常応答：デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>
を送ります。
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
エラー応答：要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
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.
この章はクライアントまたはサーバーが実装するかもしれない能力を定めま
す(MAY)。各当事者は、最初の能力交渉の間に、能力を送ることで、その能力
の存在を伝えます。各当事者は、自己の使うかもしれない能力だけを理解する
必要があり、他の当事者から受け取る必要としないか理解しないどんな能力を
無視しなければなりません(MUST)。
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"と呼ばれて
います。省略記載はプロトコルの中に使われません(MUST NOT)。
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
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>要素を送らなければなりません(MUST)。各
当事者は少なくとも基本NETCONF能力"urn:ietf:params:netconf:base:1.1"を
送ります。複数のバージョンのプロトコルをサポートすることを示すために、
当事者は前のNETCONFバージョンの能力を含めるかもしれません(MAY)。
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の当事者は、相手が共通のプロトコルバージョンを通知した
ことを確認しなければなりません(MUST)。プロトコルバージョン能力URIを
比較するとき、URI文字列の終わりにパラメータがコード化されていても、
基本部分だけを使います。共通するプロトコルバージョン能力が見つからな
ければ、NETCONFの当事者はセッションを続けてはなりません(MUST NOT)。
共通するプロトコルバージョンURIが複数存在するならば、両方の当事者は
最も大きい数（最新）のプロトコルバージョンを使わなければなりません
(MUST)。
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>要素を含めなければなりません(MUST)。クライアントの送
る<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
セッションを終了しなければなりません(MUST)。同様にサーバーからの
<hello>メッセージで<session-id>要素を受信しなかったクライアントも
（<close-session>を送らずに）NETCONFセッションを終了しなければなり
ません (MUST)。
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文書で定め
られる１つの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)。
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>
The :writable-running capability modifies the <edit-config> operation
to accept the <running> element as a <target>.
:writable-running能力は<edit-config>オペレーションの<target>として
<running>を受け入れます。
8.2.5.2. <copy-config>
The :writable-running capability modifies the <copy-config> operation
to accept the <running> element as a <target>.
:writable-running能力は<copy-config>オペレーションの<target>として
<running>を受け入れます。
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
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.
候補コンフィグレーションは、複数のセッションで共有できます。クライアン
トには候補コンフィグレーションが共有されないという特定の情報がない限り、
他のセッションが同時に候補コンフィグレーションを修正することができると
仮定しなければなりません(MUST)。したがって、クライアントが候補コンフィ
グレーションを修正する前に候補コンフィグレーションをロックすることは賢
明です。
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. 新オペレーション
8.3.4.1. <commit>
Description:
説明：
When the candidate configuration's content is complete, the
configuration data can be committed, publishing the data set to
the rest of the device and requesting the device to conform to
the behavior described in the new configuration.
候補コンフィグレーションの内容が完成すると、コンフィグレーショ
ンデータはコミットできます、残りのデバイスにデータセットを送り、
デバイスに新しいコンフィグレーションで記述されるふるまいに従う
ことを要求します。
To commit the candidate configuration as the device's new
current configuration, use the <commit> operation.
候補コンフィグレーションを装置の新しい現用コンフィグレーション
としてコミットするために、<commit>オペレーションを使います。
The <commit> operation instructs the device to implement the
configuration data contained in the candidate configuration.
If the device is unable to commit all of the changes in the
candidate configuration datastore, then the running
configuration MUST remain unchanged. If the device does
succeed in committing, the running configuration MUST be
updated with the contents of the candidate configuration.
<commit>オペレーションは候補コンフィグレーションに含まれるコ
ンフィグレーションデータを導入するようにデバイスに指示します。
デバイスは候補コンフィグレーションデータストアの変化の全てを
コミットできないならば、ランニングコンフィグレーションは変更
されません(MUST)。デバイスがコミットに成功するならば、ランニ
ングコンフィグレーションは候補コンフィグレーションの内容で更
新されなければなりません(MUST)。
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"に
して失敗しなければなりません(MUST)。
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>
If the client decides that the candidate configuration is not to be
committed, the <discard-changes> operation can be used to revert the
candidate configuration to the current running configuration.
依頼者が候補コンフィグレーションをコミットしないと決めるならば、
<discard-changes>オペレーションは、候補コンフィグレーションをランニン
グコンフィグレーションに戻すのに用いることができます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
This operation discards any uncommitted changes by resetting the
candidate configuration with the content of the running
configuration.
ランニングコンフィグレーションの内容で候補コンフィグレーションをリセッ
トすることで、このオペレーションはコミットしていない変更を放棄します。
8.3.5. Modifications to Existing Operations
8.3.5. 既存オペレーションの変更
8.3.5.1. <get-config>, <edit-config>, <copy-config>, and <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>
The candidate configuration can be locked using the <lock> operation
with the <candidate> element as the <target> parameter:
候補コンフィグレーションは、<lock>オペレーションの<target>パラメータ
に<candidate>要素を使い、ロックできます：
<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>要素を使い、候補コンフィグレー
ションのロック解放ができます：
<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>立証オペレーションは元に戻されます。コミット確認
は<confirmed>パラメータのない<commit>オペレーションです。タイムアウト
期間は<confirm-timeout>パラメータで調節できます。タイマが切れる前に後
続の<commit>立証オペレーションが行われたら、タイマーは新しい値（デ
フォルトによる600秒）でリセットされます。コミット確認も後続の
<commit>立証オペレーションもコンフィギュレーションに更なる変更をする
かもしれません(MAY)。
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.
<commit>立証オペレーションで<persist>要素がなければ、後続のコミット立
証とコミット確認は、コミット立証と同じセッションで行われなければなり
ません(MUST)。<commit>立証オペレーションで<persist>要素があれば、後続
のコミット立証とコミット確認は、任意のセッションで可能で、このとき
<persist-id>要素の値は<persist>要素で与えた値と同じでなければなりませ
ん(MUST)
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>は、変更をスタートアップへ保存するために必要です。
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>要素も含まれてない限り、サーバはコンフィ
グレーションの状態をコミット立証を行う前の状態にしなければなりません
(MUST)。
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.
デバイスが何らかの理由でタイムアウト前に再起動した場合、サーバはコン
フィグレーションの状態をコミット立証を行う前の状態にしなければなりま
せん(MUST)。
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操作が始まる前にロックが開始している）、
この機能は他のコンフィグレーション変更（たとえば、他のNETCONFセッション
を通して）が不注意に変更や削除される原因になることがありえます。したがっ
て、共有コンフィグレーションデータストアでこの機能を働かすためには、コ
ンフィグレーションロックを使うべき(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は
この文書で定められてバージョン1.0を拡張しました、新しいオペレーション
<cancel-commit>の導入と、２つの新しいオプションのパラメータ<persist>と
<persist-id>を加えました。古いクライアントとの下位互換性のために、この
仕様に従うサーバーは、バージョン1.1に加えてバージョン1.0を通知しする
かもしれません(MAY)。
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
8.4.4. New Operations
8.4.4. 新オペレーション
8.4.4.1. <cancel-commit>
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>オペレーションはコミット立証を実
施したのと同じセッションで実施しなければなりません(MUST)。
Parameters:
パラメータ：
persist-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>パラメータで与えた値と同じでなければなりま
せん(MUST)。値が一致しなければ、オペレーションは
"invalid-value"エラーで失敗します。
Positive Response:
正常応答：
If the device was able to satisfy the request, an <rpc-reply>
is sent that contains an <ok> element.
デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>を
送ります。
Negative Response:
エラー応答：
An <rpc-error> element is included in the <rpc-reply> if the
request cannot be completed for any reason.
要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-commit/>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
8.4.5. Modifications to Existing Operations
8.4.5. 既存オペレーションの変更
8.4.5.1. <commit>
The :confirmed-commit:1.1 capability allows 4 additional parameters
to the <commit> operation.
:confirmed-commit:1.1能力は<commit>オペレーションに４つのパラメータ
を追加します。
Parameters:
パラメータ：
confirmed:
Perform a confirmed <commit> operation.
<commit>立証オペレーションを実行。
confirm-timeout:
Timeout period for confirmed commit, in seconds. If
unspecified, the confirm timeout defaults to 600 seconds.
コミット立証の秒単位のタイムアウト期間。明示しなければコミッ
トの立証タイムアウトは600秒がデフォルトになります。
persist:
Make the confirmed commit survive a session termination, and
set a token on the ongoing confirmed commit.
セッション終了時にコミット立証を残し、実施中のコミット立証の
トークンを設定します。
persist-id:
Used to issue a follow-up confirmed commit or a confirming
commit from any session, with the token from the previous
<commit> operation.
任意のセッションから後続のコミット立証かコミット確認を実施
する際に使い、前の<commit>オペレーションのトークンです。
Example:
例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Example:
例：
<!-- start a persistent confirmed-commit -->
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<persist>IQ,d4668</persist>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<!-- confirm the persistent confirmed-commit,
possibly from another session -->
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<persist-id>IQ,d4668</persist-id>
</commit>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
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>オペレーションが始まる前にロックが
得られない限り）、この機能は（例えば他のNETCONFセッションを通して）、
不注意な変更や削除にいる他のコンフィギュレーション変更を起こすかもしれ
ません。したがって、共有コンフィギュレーションデータストアでこの機能を
働かすために、コンフィギュレーションのロックを使うべきことが強く示唆さ
れます。
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>
The :rollback-on-error capability allows the "rollback-on-error"
value to the <error-option> parameter on the <edit-config> operation.
:rollback-on-error能力が<edit-config>オペレーションの<error-option>
パラメータで値"rollback-on-error"を許します。
<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>
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は
この文書で定められてバージョン1.0を拡張し、<edit-config>オペレーショ
ンの<test-option>パラメータに新しい値"test-only"の追加します。古いクラ
イアントとの下位互換性のために、この仕様に従うサーバーは、バージョン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>
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.
<candidate>の様な検証するコンフィグレーションデータストアの名
前、あるいは、検証対象の全コンフィグレーションの<config>要素。
Positive Response:
正常応答：
If the device was able to satisfy the request, an <rpc-reply>
is sent that contains an <ok> element.
デバイスが要求に応えられるならば、<ok>要素を含む<rpc-reply>を
送ります。
Negative Response:
エラー応答：
An <rpc-error> element is included in the <rpc-reply> if the
request cannot be completed for any reason.
要求が何らかの理由で完了できなければ、<rpc-error>要素が
<rpc-reply>に含められます。
A <validate> operation can fail for a number of reasons, such
as syntax errors, missing parameters, references to undefined
configuration data, or any other violations of rules
established by the underlying data model.
<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>
The :validate:1.1 capability modifies the <edit-config> operation to
accept the <test-option> parameter.
:validate:1.1能力は<edit-config>を<test-option>パラメータを受け入れる
ように修正します。
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
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/>コン
フィグレーションデータストアを加えます。サーバーは、以下の値をサポー
トしなければなりません(MUST)：
+--------------------+--------------------------+-------------------+
| 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.
スタートアップコンフィグレーションを保存するために、<running>コンフィグ
レーションデータストアから<startup>コンフィグレーションデータストアへ
<copy-config>オペレーションを行います。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
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:
:url能力は以下の能力文字列で識別されます：
urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
The :url capability URI MUST contain a "scheme" argument assigned a
comma-separated list of scheme names indicating which schemes the
NETCONF peer supports. For example:
:url能力URIは、NETCONF実装がサポートする計画名のカンマ区切りリストを
設定した"scheme"引数を含まなければなりません(MUST)。たとえば：
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>
The :url capability modifies the <edit-config> operation to accept
the <url> element as an alternative to the <config> parameter.
:url能力が<edit-config>オペレーションを<config>パラメータの代わり
に<url>要素を受け入れるように変更します。
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.
ＵＲＬで指定するファイルは修正するコンフィグレーションデータの階層を
含み、"urn:ietf:params:xml:ns:netconf:base:1.0"名前空間の<config>要素
下でXMLでコード化されます。
8.8.5.2. <copy-config>
The :url capability modifies the <copy-config> operation to accept
the <url> element as the value of the <source> and the <target>
parameters.
:url能力が<copy-config>オペレーションを<source>と<target>パラメータ
の値として<url>要素を受け入れるように変更します。
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.
ＵＲＬで指定するファイルは完全なコンフィグレーションデータストアを
含み、"urn:ietf:params:xml:ns:netconf:base:1.0"名前空間の<config>要素
下でXMLでコード化されます。
8.8.5.3. <delete-config>
The :url capability modifies the <delete-config> operation to accept
the <url> element as the value of the <target> parameters.
:url能力が<delete-config>オペレーションを<target>パラメータの値とし
て<url>要素を受け入れるように変更します。
8.8.5.4. <validate>
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章)を含みます。具
体的には、ルートノードが複数の子の要素ノードを持つかもしれない(MAY)こと
を意味します。
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.
関数ライブラリは、コア関数ライブラリとデータモデルで定義される任意の
関数です。
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表現はノード集合を返さなければなりません(MUST)。ノード集合を返さ
なければ、オペレーションは"invalid-value"エラーで失敗します。
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>要素の"xpath"
属性で"xpath"の與を受け入れます。"xpath"属性に"xpath"が設定されるとき、
<filter>要素に"select"属性が設定されなければなりません(MUST)。"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:
選択表現のXPathの結果はノード集合でなければなりません(MUST)。ノード集
合の各ノードは、元になるデータモデルのノードと一致しなければなりません
(MUST)。きちんと各ノードを確認するために、以下の符号化規則が定められま
す：
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.
結果のノードのすべての祖先ノードは、最初にコード化されなければなり
ません(MUST)、つまり応答で返される<data>要素は、元になるデータモデ
ルに従った、完全に指定されたサブツリーだけを含みます。
o If any sibling or ancestor nodes of the result node are needed to
identify a particular instance within a conceptual data structure,
then these nodes MUST also be encoded in the response.
概念上のデータ構造の内の特定のインスタンスを識別するのに、結果のノー
ドの兄弟または祖先ノードが必要であるならば、これらのノードは応答内に
コード化されなければなりません(MUST)。
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
を提供すべきです(SHOULD)。
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サーバーによる個々のユーザーの認可は、他のインターフェースに
１対１で対応するかもしれないし、しないかもしれません。第１に、データ・
モデルは矛盾するかもしれません。第２に、セキュアトランスポート層（例
えば、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.
コンフィグレーション情報は、本質的に敏感です。素のままで完全性検査を
していない伝送路はデバイスを古典的な盗聴攻撃と偽データ挿入攻撃にさら
されたままにします。コンフィグレーション情報はパスワードやユーザー名
やサービスの詳細やトポロジー情報を含み、そして、その全ては敏感です。
このため、他の管理インターフェースで得た経験で予想されるあらゆる種類
の攻撃に対する十分な注意を払い、プロトコルは慎重に実装すべきです(SHOULD)。
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.
したがって、プロトコルは最低限、守秘と認証のオプションをサポートし
なければなりません(MUST)。下位プロトコル（SSH、BEEP、その他）が必要
な守秘と認証の供給をすると予期されます。要求を認可するために、NETCONF
セッションの両端の識別子が相互に利用できると予想されます。トランス
ポートや暗号化などの情報は、認可のために利用可能と考えられます。
NETCONF自体は再認証手段を提供しません、追加の認証はしません。すべて
の認証行動は、下層で起こります。
Different environments may well allow different rights prior to and
then after authentication. Thus, an authorization model is not
specified in this document. When an operation is not properly
authorized, a simple "access denied" is sufficient. Note that
authorization information can be exchanged in the form of
configuration information, which is all the more reason to ensure the
security of the connection.
認証前後で異なる環境は異なる権利を許すでしょう。このように、認可モデ
ルは、この文書に明記されていません。オペレーションがきちんと認可され
ないとき、単純な"access denied"で十分です。認可情報がコンフィグレーショ
ン情報の形で交換できることに注意してください、これは接続の安全を確実
にするもう１つの理由です。
That having been said, it is important to recognize that some
operations are clearly more sensitive by nature than others. For
instance, <copy-config> to the startup or running configurations is
clearly not a normal provisioning operation, whereas <edit-config>
is. Such global operations MUST disallow the changing of information
that an individual does not have authorization to perform. For
example, if user A is not allowed to configure an IP address on an
interface but user B has configured an IP address on an interface in
the <candidate> configuration, user A MUST NOT be allowed to commit
the <candidate> configuration.
あるオペレーションが本質的に他のオペレーションより明らかに敏感であ
ることを認識するのは重要です。たとえば、スタートアップやランニング
コンフィグレーションに<copy-config>をするのは、<edit-config>と同じ
であり、明らかに通常の操作ではありません。実行者に実行権限がない場
合に、このようなグローバルオペレーションで情報を変更する事を認めて
はなりません(MUST)。たとえば、ユーザー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が意図したとおりに動作することを証明します。この文書に定め
られた通り、原則としてコンフィグレーションの他人がアクセスしないかも
しれない部分をロックすることができます。結局は、コンフィグレーション
の全てがロックされます。この問題を軽くするために、２つのアプローチが
あります。問題のあるセッションのセッション識別子を知っているならば、
NETCONF内からプログラム的に他のNETCONFセッションを止めることができま
す。ロックをこわす他の考えられる方法は、装置のネイティブ・ユーザー・
インターフェイスの中で機能を提供することです。２つのメカニズムが競合
する場合、認証認可課金(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].
この文書はIETF XML登録所[RFC3688]にNETCONF XML名前空間のための
URIを登録します。
IANA has updated the following URI to reference this document.
IANAは以下のURIのリファレンスにこの文書をつける更新をしました。
URI: urn:ietf:params:xml:ns:netconf:base:1.0
Registrant Contact: The IESG.
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].
この文書はIETF XML登録所[RFC3688]にNETCONF XMLスキーマのための
URIを登録します。
IANA has updated the following URI to reference this document.
IANAは以下のURIのリファレンスにこの文書をつける更新をしました。
URI: urn:ietf:params:xml:schema:netconf
Registrant Contact: The IESG.
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].
この文書はYANGモジュール名登録所[RFC6020]でYANGモジュールを登録します。
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
IANA has added the following capabilities to the registry:
IANAは登記所に以下の能力を追加しました。
Index
Capability Identifier
------------------------
:base:1.1
urn:ietf:params:netconf:base:1.1
:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
:validate:1.1
urn:ietf:params:netconf:capability:validate:1.1
11. Contributors
11. 貢献者
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
12. 謝辞
The authors would like to acknowledge the members of the NETCONF
working group. In particular, we would like to thank Wes Hardaker
for his persistence and patience in assisting us with security
considerations. We would also like to thank Randy Presuhn, Sharon
Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen,
Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch, and Kent
Watsen for all of their valuable advice.
著者は、NETCONF専門調査委員会のメンバーに感謝したいと思います。特に
Wes Hardakerに、セキュリティの考察で我々を助ける際の彼の持続と忍耐に
対して感謝したいです。我々は、Randy Presuhn, Sharon Chisholm,
Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen,
Dave Harrington, Ladislav Lhotka, Tom Petch, and Kent Watsenに彼らの
価値あるアドバイスの全てに対して感謝します。
13. References
13. 参考文献
13.1. Normative References
13.1. 参照する参考文献
[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>.
13.2. Informative References
13.2. 有益な参考文献
[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>.
Appendix A. NETCONF Error List
付録 A. NETCONFエラーリスト
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.
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.
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.
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>).
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
付録 B. NETCONFメッセージレイヤーのXMLスキーマ
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
-->
<xs:simpleType name="messageIdType">
<xs:restriction base="xs:string">
<xs:maxLength value="4095"/>
</xs:restriction>
</xs:simpleType>
<!--
Types used for session-id
-->
<xs:simpleType name="SessionId">
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SessionIdOrZero">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<!--
<rpc> element
-->
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType"
use="required"/>
<!--
Arbitrary attributes can be supplied with <rpc> element.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
<!--
data types and elements used to construct rpc-errors
-->
<xs:simpleType name="ErrorType">
<xs:restriction base="xs:string">
<xs:enumeration value="transport"/>
<xs:enumeration value="rpc"/>
<xs:enumeration value="protocol"/>
<xs:enumeration value="application"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorTag">
<xs:restriction base="xs:string">
<xs:enumeration value="in-use"/>
<xs:enumeration value="invalid-value"/>
<xs:enumeration value="too-big"/>
<xs:enumeration value="missing-attribute"/>
<xs:enumeration value="bad-attribute"/>
<xs:enumeration value="unknown-attribute"/>
<xs:enumeration value="missing-element"/>
<xs:enumeration value="bad-element"/>
<xs:enumeration value="unknown-element"/>
<xs:enumeration value="unknown-namespace"/>
<xs:enumeration value="access-denied"/>
<xs:enumeration value="lock-denied"/>
<xs:enumeration value="resource-denied"/>
<xs:enumeration value="rollback-failed"/>
<xs:enumeration value="data-exists"/>
<xs:enumeration value="data-missing"/>
<xs:enumeration value="operation-not-supported"/>
<xs:enumeration value="operation-failed"/>
<xs:enumeration value="partial-operation"/>
<xs:enumeration value="malformed-message"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorSeverity">
<xs:restriction base="xs:string">
<xs:enumeration value="error"/>
<xs:enumeration value="warning"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="errorInfoType">
<xs:sequence>
<xs:choice>
<xs:element name="session-id" type="SessionIdOrZero"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:sequence>
<xs:element name="bad-attribute" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="ok-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="err-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="noop-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-namespace" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
<!-- elements from any other namespace are also allowed
to follow the NETCONF elements -->
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rpcErrorType">
<xs:sequence>
<xs:element name="error-type" type="ErrorType"/>
<xs:element name="error-tag" type="ErrorTag"/>
<xs:element name="error-severity" type="ErrorSeverity"/>
<xs:element name="error-app-tag" type="xs:string"
minOccurs="0"/>
<xs:element name="error-path" type="xs:string" minOccurs="0"/>
<xs:element name="error-message" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="error-info" type="errorInfoType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--
operation attribute used in <edit-config>
-->
<xs:simpleType name="editOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="merge"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="create"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="remove"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="operation" type="editOperationType"/>
<!--
<rpc-reply> element
-->
<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:sequence>
<xs:element ref="rpc-error"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="rpcResponse"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:choice>
<xs:attribute name="message-id" type="messageIdType"
use="optional"/>
<!--
Any attributes supplied with <rpc> element must be returned
on <rpc-reply>.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc-reply" type="rpcReplyType"/>
<!--
<rpc-error> element
-->
<xs:element name="rpc-error" type="rpcErrorType"/>
<!--
rpcOperationType: used as a base type for all
NETCONF operations
-->
<xs:complexType name="rpcOperationType"/>
<xs:element name="rpcOperation" type="rpcOperationType"
abstract="true"/>
<!--
rpcResponseType: used as a base type for all
NETCONF responses
-->
<xs:complexType name="rpcResponseType"/>
<xs:element name="rpcResponse" type="rpcResponseType"
abstract="true"/>
<!--
<hello> element
-->
<xs:element name="hello">
<xs:complexType>
<xs:sequence>
<xs:element name="capabilities">
<xs:complexType>
<xs:sequence>
<xs:element name="capability" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="session-id" type="SessionId"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<CODE ENDS>
Appendix C. YANG Module for NETCONF Protocol Operations
付録 C. NETCONFプロトコル操作用のYANGモジュール
This section is normative.
この章は参照です。
The ietf-netconf YANG module imports typedefs from [RFC6021].
ietf-netconf YANGモジュールは、[RFC6021]からtypedefをインポートします。
<CODE BEGINS> file "ietf-netconf@2011-06-01.yang"
module ietf-netconf {
// 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>";
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 {
description
"NETCONF :writable-running capability;
If the server advertises the :writable-running
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.2";
}
feature candidate {
description
"NETCONF :candidate capability;
If the server advertises the :candidate
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.3";
}
feature confirmed-commit {
if-feature candidate;
description
"NETCONF :confirmed-commit:1.1 capability;
If the server advertises the :confirmed-commit:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.4";
}
feature rollback-on-error {
description
"NETCONF :rollback-on-error capability;
If the server advertises the :rollback-on-error
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.5";
}
feature validate {
description
"NETCONF :validate:1.1 capability;
If the server advertises the :validate:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.6";
}
feature startup {
description
"NETCONF :startup capability;
If the server advertises the :startup
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.7";
}
feature url {
description
"NETCONF :url capability;
If the server advertises the :url
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.8";
}
feature xpath {
description
"NETCONF :xpath capability;
If the server advertises the :xpath
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.9";
}
// NETCONF Simple Types
typedef session-id-type {
type uint32 {
range "1..max";
}
description
"NETCONF Session Id";
}
typedef session-id-or-zero-type {
type uint32;
description
"NETCONF Session Id or Zero to indicate none";
}
typedef error-tag-type {
type enumeration {
enum in-use {
description
"The request requires a resource that
already is in use.";
}
enum invalid-value {
description
"The request specifies an unacceptable value for one
or more parameters.";
}
enum too-big {
description
"The request or response (that would be generated) is
too large for the implementation to handle.";
}
enum missing-attribute {
description
"An expected attribute is missing.";
}
enum bad-attribute {
description
"An attribute value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-attribute {
description
"An unexpected attribute is present.";
}
enum missing-element {
description
"An expected element is missing.";
}
enum bad-element {
description
"An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-element {
description
"An unexpected element is present.";
}
enum unknown-namespace {
description
"An unexpected namespace is present.";
}
enum access-denied {
description
"Access to the requested protocol operation or
data model is denied because authorization failed.";
}
enum lock-denied {
description
"Access to the requested lock is denied because the
lock is currently held by another entity.";
}
enum resource-denied {
description
"Request could not be completed because of
insufficient resources.";
}
enum rollback-failed {
description
"Request to roll back some configuration change (via
rollback-on-error or <discard-changes> operations)
was not completed for some reason.";
}
enum data-exists {
description
"Request could not be completed because the relevant
data model content already exists. For example,
a 'create' operation was attempted on data that
already exists.";
}
enum data-missing {
description
"Request could not be completed because the relevant
data model content does not exist. For example,
a 'delete' operation was attempted on
data that does not exist.";
}
enum operation-not-supported {
description
"Request could not be completed because the requested
operation is not supported by this implementation.";
}
enum operation-failed {
description
"Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.";
}
enum partial-operation {
description
"This error-tag is obsolete, and SHOULD NOT be sent
by servers conforming to this document.";
}
enum malformed-message {
description
"A message could not be handled because it failed to
be parsed correctly. For example, the message is not
well-formed XML or it uses an invalid character set.";
}
}
description "NETCONF Error Tag";
reference "RFC 6241, Appendix A";
}
typedef error-severity-type {
type enumeration {
enum error {
description "Error severity";
}
enum warning {
description "Warning severity";
}
}
description "NETCONF Error Severity";
reference "RFC 6241, Section 4.3";
}
typedef edit-operation-type {
type enumeration {
enum merge {
description
"The configuration data identified by the
element containing this attribute is merged
with the configuration at the corresponding
level in the configuration datastore identified
by the target parameter.";
}
enum replace {
description
"The configuration data identified by the element
containing this attribute replaces any related
configuration in the configuration datastore
identified by the target parameter. If no such
configuration data exists in the configuration
datastore, it is created. Unlike a
<copy-config> operation, which replaces the
entire target configuration, only the configuration
actually present in the config parameter is affected.";
}
enum create {
description
"The configuration data identified by the element
containing this attribute is added to the
configuration if and only if the configuration
data does not already exist in the configuration
datastore. If the configuration data exists, an
<rpc-error> element is returned with an
<error-tag> value of 'data-exists'.";
}
enum delete {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if and only if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, an <rpc-error> element is returned with
an <error-tag> value of 'data-missing'.";
}
enum remove {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, the 'remove' operation is silently ignored
by the server.";
}
}
default "merge";
description "NETCONF 'operation' attribute values";
reference "RFC 6241, Section 7.2";
}
// NETCONF Standard Protocol Operations
rpc get-config {
description
"Retrieve all or part of a specified configuration.";
reference "RFC 6241, Section 7.1";
input {
container source {
description
"Particular configuration to retrieve.";
choice config-source {
mandatory true;
description
"The configuration to retrieve.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.
This is optional-to-implement on the server because
not all servers will support filtering for this
datastore.";
}
}
}
anyxml filter {
description
"Subtree or XPath filter to use.";
nc:get-filter-element-attributes;
}
}
output {
anyxml data {
description
"Copy of the source datastore subset that matched
the filter criteria (if any). An empty data container
indicates that the request did not produce any results.";
}
}
}
rpc edit-config {
description
"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.";
}
leaf test-option {
if-feature validate;
type enumeration {
enum test-then-set {
description
"The server will test and then set if no errors.";
}
enum set {
description
"The server will set without a test first.";
}
enum test-only {
description
"The server will only test and not set, even
if there are no errors.";
}
}
default "test-then-set";
description
"The test option to use.";
}
leaf error-option {
type enumeration {
enum stop-on-error {
description
"The server will stop on errors.";
}
enum continue-on-error {
description
"The server may continue on errors.";
}
enum rollback-on-error {
description
"The server will roll back on errors.
This value can only be used if the 'rollback-on-error'
feature is supported.";
}
}
default "stop-on-error";
description
"The error option to use.";
}
choice edit-content {
mandatory true;
description
"The content for the edit operation.";
anyxml config {
description
"Inline Config content.";
}
leaf url {
if-feature url;
type inet:uri;
description
"URL-based config content.";
}
}
}
}
rpc copy-config {
description
"Create or replace an entire configuration datastore with the
contents of another complete configuration datastore.";
reference "RFC 6241, Section 7.3";
input {
container target {
description
"Particular configuration to copy to.";
choice config-target {
mandatory true;
description
"The configuration target of the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config target.
This is optional-to-implement on the server.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
container source {
description
"Particular configuration to copy from.";
choice config-source {
mandatory true;
description
"The configuration source for the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
rpc delete-config {
description
"Delete a configuration datastore.";
reference "RFC 6241, Section 7.4";
input {
container target {
description
"Particular configuration to delete.";
choice config-target {
mandatory true;
description
"The configuration target to delete.";
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
}
}
rpc lock {
description
"The lock operation allows the client to lock the configuration
system of a device.";
reference "RFC 6241, Section 7.5";
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;
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.";
}
}
}
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";
}
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.";
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.";
}
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>
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.
Appendix E. Configuring Multiple Devices with NETCONF
付録 E. NETCONFを使用した複数のデバイスの構成
This section is non-normative.
この章は非標準です。
E.1. Operations on Individual Devices
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
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.
<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
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.
<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.
E.1.3. Loading and Validating the Incoming Configuration
If the :candidate capability is supported, the configuration can be
loaded onto the device without impacting the running system.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
If the device supports the :validate:1.1 capability, it will by
default validate the incoming configuration when it is loaded into
the candidate. To avoid this validation, pass the <test-option>
parameter with the value "set". Full validation can be requested
with the <validate> operation.
<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
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.
<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
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).
E.1.6. Making the Change Permanent
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.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
If the device supports the :candidate capability and a confirmed
commit was requested, the confirming commit must be sent before the
timeout expires.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
E.1.7. Releasing the Configuration Lock
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.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
If the :candidate capability is supported, the candidate
configuration should be unlocked.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
E.2. Operations on Multiple Devices
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.
There are two classes of multi-device operations. The first class
allows the operation to fail on individual devices without requiring
all devices to revert to their original state. The operation can be
retried at a later time, or its failure simply reported to the user.
An example of this class might be adding an NTP server. For this
class of operations, failure avoidance and recovery are focused on
the individual device. This means recovery of the device, reporting
the failure, and perhaps scheduling another attempt.
The second class is more interesting, requiring that the operation
should complete on all devices or be fully reversed. The network
should either be transformed into a new state or be reset to its
original state. For example, a change to a VPN may require updates
to a number of devices. Another example of this might be adding a
class-of-service definition. Leaving the network in a state where
only a portion of the devices have been updated with the new
definition will lead to future failures when the definition is
referenced.
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.
Appendix F. Changes from RFC 4741
付録 F. RFC 4741からの変更
This section lists major changes between this document and RFC 4741.
この章では、この文書と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.
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