5. Configuration Model 13
5.1. Configuration Datastores 13
5.2. Data Modeling 13
6. Subtree Filtering 13
6.1. Overview 14
6.2. Subtree Filter Components 14
6.2.1. Namespace Selection 14
6.2.2. Attribute Match Expressions 14
6.2.4. Selection Nodes 15
6.2.5. Content Match Nodes 15
6.3. Subtree Filter Processing 16
6.4. Subtree Filtering Examples 16
6.4.1. No Filter 16
6.4.2. Empty Filter 17
6.4.3. Select the Entire <users> Subtree 17
6.4.4. Select All <name> Elements within the <users> Subtree 18
6.4.5. One Specific <user> Entry 19
6.4.6. Specific Elements from a Specific <user> Entry 20
6.4.7. Multiple Subtrees 21
6.4.8. Elements with Attribute Naming 22
7. Protocol Operations 23
7.1. <get-config> 23
7.2. <edit-config> 24
7.3. <copy-config> 28
7.4. <delete-config> 29
7.5. <lock> 29
7.6. <unlock> 31
7.7. <get> 31
7.8. <close-session> 32
7.9. <kill-session> 33
8. Capabilities 33
8.1. Capabilities Exchange 34
8.2. Writable-Running Capability 35
8.3. Candidate Configuration Capability 35
8.4. Confirmed Commit Capability 37
8.5. Rollback-on-Error Capability 39
8.6. Validate Capability 40
8.7. Distinct Startup Capability 41
8.8. URL Capability 41
8.9. XPath Capability 42
9. Security Considerations 43
10. IANA Considerations 44
10.1. NETCONF XML Namespace 44
10.2. NETCONF XML Schema 44
10.4. NETCONF Capability URNs 45
13. References 45
2

Appendix A. NETCONF Error List 45
Appendix B. XML Schema for NETCONF Messages Layer 50
Appendix C. YANG Module for NETCONF Protocol Operations 50
Appendix D. Capability Template 50
D.1. capability-name (template) 50
D.1.1. Overview 51
D.1.2. Dependencies 51
D.1.3. Capability Identifier 51
D.1.4. New Operations 51
D.1.4.1. <op-name> 51
D.1.5. Modifications to Existing Operations 51
D.1.5.1. <op-name> 51
D.1.6. Interactions with Other Capabilities 51
Appendix E. Configuring Multiple Devices with NETCONF 51
E.1.1. Acquiring the Configuration Lock 52
E.1.2. Checkpointing the Running Configuration 52
E.1.3. Loading and Validating the Incoming Configuration 52
E.1.4. Changing the Running Configuration 53
E.1.5. Testing the New Configuration 53
E.1.6. Making the Change Permanent 53
E.1.7. Releasing the Configuration Lock 54
E.2. Operations on Multiple Devices 54
Appendix F. Changes from RFC 4741 55
1. Introduction
　NETCONFプロトコルはネットワークデバイスを管理、情報取得、設定、操作できるシンプルなメカニズムを定義する。このプロ
トコルにより、ネットワークデバイスはAPIを公開することができる。アプリケーションはこのシンプルなAPIを使用して
configuration dataを送受信できる。
　NETCONFプロトコルはRPCを使用する。クライアントはRPCをXMLでエンコードし、コネクション指向のセキュアなセッション
でサーバーに送信する(Request)。サーバーはXMLでエンコードされた応答で応答する(Response)。RequestとResponseの
コンテンツはXML DTD or XMLスキーマまたはその両方で記述され、クライアント、サーバーの両方がsyntaxを認識できる。
　NETCONFの重要なポイントは、管理プロトコルの機能がネットワークデバイスのネイティブ機能に対応できることである。これ
により、実装コストが削減され、新機能への即時対応、アクセス提供が可能になる。さらに、アプリケーションはネットワークデ
バイスのネイティブなインターフェースに直接またはNETCONF経由でのアクセスが可能になる。
　クライアントは、NETCONFによりサーバーでサポートされているプロトコル拡張を検出できる。"Capability"はクライアン
トがネットワークデバイスによって公開された機能を利用するために使用される。Capabilityの定義は個別に簡単に拡張でき
る。標準 or 非標準のcapabilityが定義できる。CapabilityはSection 8参照。
　NETCONFプロトコルはauto configurationシステムの一部である。XMLは階層的なコンテンツにアクセスするためのエン
コーディングメカニズムを提供する。NETCONFはXSLT [W3C.REC-xslt-19991116]のようなXML変換技術を使用して
configurationを生成するシステムを提供する。データはNETCONFプロトコルを使用してネットワークデバイスに送信すること
ができる。
3

"MUST" "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL"はhttps://tools.ietf.org/html/rfc2119の通り解釈される。
1.1. Terminology
用語意味
Candidate configuration datastore デバイスの現在のconfigurationに影響を与えることなく
操作でき、running configuration datastoreにコ
ミットができるconfiguration datastore。全てのデバ
イスがcandidate configuration datastoreをサポー
トしているわけではない。
Capability NETCONF仕様への補完機能。
クライアントサーバーのプロトコルoperationを呼び出す。クライアント
はサーバーからのnotificationを登録することができる。
Configuration data システムをinitial default stateからcurrent
stateに遷移するために必要な書き込み可能なdata set。
Datastore 情報の保存とアクセスのための概念的な場所。Datastoreは
例えば、ファイル、DB、フラッシュメモリ等またはそれらの
組み合わせで実装してよい。
Configuration datastore デバイスをinitial default stateから所望の
operational stateにするために必要なconfiguration
dataの全setを保持するdatastore。
Message（メッセージ） Well-formed XMLであり、各セッションで送受信されるプ
ロトコルelement。
Notification 特定のイベントがサーバーによって認識されたことを示す、
サーバー契機のメッセージ。
Protocol operation（プロトコルoperation） NETCONFプロトコルで使用されるremote procedure
call。
Remote procedure call（RPC） <rpc>と<rpc-reply>を交換することで実現される。
Running Configuration datastore デバイスで現在アクティブな全cofigurationを保持する
configuration datastore。running
configuration datastoreは常に存在する。
サーバークライアントによって呼び出されたプロトコルoperationを
実行する。サーバーはクライアントにnotificationを送信
できる。
セッションクライアントとサーバーはコネクション指向のセキュアな
セッションを使用してメッセージを交換する。
Startup configuration datastore Boot時にデバイスがロードしたconfigurationを保持する
configuration datastore。startup
configuration datastoreとrunning
configuration datastoreを分離するデバイスにのみ存
在する。
State data 読み取り専用 state情報や統計情報などのconfiguration
dataではないシステム上のデータ。
4

ユーザークライアントの認証されたidentity。クライアントの認証さ
れたidentityは一般にNETCONF usernameを呼ばれる。
1.2. Protocol Overview
　NETCONFはシンプルなRPCのメカニズムを使用してクライアントとサーバー間の通信を容易にする。クライアントは一般的に
ネットワークマネージャーの一部として動作する。サーバーは一般的にネットワークデバイスである。
　NETCONFセッションはネットワーク configuration applicationとネットワークデバイスとの間の論理的なコネクション
である。デバイスは最低限1つのNETCONFセッションをサポートすること（MUST）また複数のセッションもサポートすること（
SHOULD）。
　Global configuration attributeはセッションで変更することができ、その変更は全てのセッションに影響がある。
　Session-specific attributeは変更されたセッションにのみ影響する。
　NETCONFのコンセプト図はFigure 1のように4つのレイヤに分割できる。
5

Figure 1: NETCONF Protocol Layers
(1)Secure Transportレイヤ
　クライアント-サーバー間の通信パスを提供する。NETCONFはSection 2の要件を満たす全てのトランスポートプロ
トコル上で動作できる。
(2)Messagesレイヤ
　RPCとnotificationをエンコードするための、トランスポートプロトコルに依存しないフレームメカニズムを提供
する。Section 4でRPCメッセージとnotification[https://tools.ietf.org/html/rfc5277]について述べ
る。
(3)Operationsレイヤ
XMLエンコードされたパラメーターをもつRPCメソッドとして呼び出されるプロトコル操作を定義する。Section 7で
プロトコルoperationの詳細を述べる。
(4)Contentレイヤ
このドキュメントのスコープ外。NETCONFデータモデルを標準化するための作業が期待される。
　YANG data modeling language[https://tools.ietf.org/html/rfc6020]はOperations layer、Contents
layerをカバーするNETCONFデータモデルとプロトコルoperationを規定するために開発された。
1.3. Capabilities
　NETCONF capabilityはNETCONF仕様を補完する機能である。Capabilityは
URI[https://tools.ietf.org/html/rfc3986]によって識別される。
　
　Capablityは追加のoperationとoperationで許容されるcontentの両方を記述し、デバイスのoperationを補完する。
クライアントはサーバーのcapabilityを確認し、そのcapablityで定義されたoperation、パラメーター、contentsを使用
できる。
　
　Capabilityの定義には、1つ以上の依存するcapability（dependent capability）の名前を付けてもよい。
Capabilityをサポートするためにはサーバーは依存するcapablityを全てサポートすること（MUST）。
　Section 8では、クライアントがサーバーのcapabilityを確認するcapability exchangeを定義する。さらに、このド
キュメントで定義されたCapabilityのリストを示す。
　追加のcapabilityは外部文書で自由に定義、拡張できる。Capability URIは名前の衝突を避けるために考慮すること（
MUST）。
6

1.4. Separation of Configuration and State Data
　運用中のシステムから取得できる情報は、configuration dataとstate dataの2つのクラスに分かれる。
Configuration dataはシステムをinitial default stateからcurrent stateに遷移させるために必要な書き込み可能
なデータの集合である。State dataは読み取り専用のステータス情報や統計情報等のconfiguration dataではないシステム
上のデータである。デバイスがconfigurationのoperationを実行しているときにstate dataが含まれている場合、様々な
問題が発生する。
● Configuration dataを比較する際、統計情報等の無駄な比較によって時間がかかる。
● 受信データに読み取り専用データへの書き込み等の無駄な要求が含まれる可能性がある。
● データ・セットが大きくなる。
● 圧縮データに読み取り専用のデータが含まれている可能性があり、その場合は解凍に時間がかかる。
　
　これらの問題を解決するために、NETCONFプロトコルでは、configuration dataとstate dataを区別し、別々の
operationを提供する。<get-config>operationはconfiguration dataのみを取得し、<get>operationは
configuration dataおよびstate dataを取得する。
　NETCONFプロトコルは、デバイスを所望のrunning stateにするために必要な情報にフォーカスしてる。他の重要で永続的な
データに対応することは実装固有である。例えば、NETCONFプロトコルではユーザーファイル、データベースはconfiguration
dataとして扱われない。
　ユーザー認証データがデバイスに格納されている場合、それをconfiguration dataに含むかどうかは実装に依存する。
2. Transport Protocol Requirements
　NETCONFはRPCベースの通信を使用する。クライアントは1つ以上のRPC requestメッセージを送信する。サーバーは対応す
るRPC responseメッセージで応答する。
　
　NETCONFプロトコルは要求される機能を提供するトランスポートプロトコル上で実現される。特定のトランスポートプロトコル
に依存しないが、特定のプロトコルに実装する方法を定義することができる。
　
　トランスポートプロトコルはセッションタイプ（クライアント or サーバー）をNETCONF protocolレイヤに示すメカニズム
を提供すること（MUST）。
　
　このsectionではNETCONFが要求するトランスポートプロトコルの機能について詳解する。
2.1. Connection-Oriented Operation
　NETCONFはコネクション指向であり、ピア間には永続的なコネクションが必要である。このコネクションは信頼性の高い、順序
性のあるデータ配信を提供すること（MUST）。NETCONFのコネクションはプロトコルoperationされている間、長期間持続され
る。
　さらに、特定のコネクションのためにサーバーから要求されたリソースは、コネクションが終了したときに自動的に解放される
ため、障害復旧が容易になる。例えば、クライアントによってロックが取得されると、ロックは明示的に解放されるか、サーバー
がコネクションの終了を判断するまで継続する。クライアントがロックを保持している間にコネクションが終了すると、サーバー
はリカバリを実行できる。<lock>operationはSection 7.5で述べる。
2.2. Authentication, Integrity, and Confidentiality
　NETCONFコネクションは、認証、integrity、機密性、replay protectionを提供すること（MUST）。NETCONFピアはこ
れらのセキュリティが本書とは独立して提供されることを前提としている。例えば、
TLS[https://tools.ietf.org/html/rfc5246]またはSSH[https://tools.ietf.org/html/rfc4251]を使用してよ
い。
7

NETCONFコネクションは認証されること（MUST）。トランスポートプロトコルはクライアントへの認証とサーバーへの認証を
行う。NETCONFピアはトランスポートプロトコルによって、コネクションの認証情報が検証されていること、およびピアの識別情
報が正しいことを前提としている。
　NETCONFの1つの目標は、デバイスのネイティブインターフェースの機能のAPIをデバイスに提供することである。そのため、
デバイス上で利用可能な認証メカニズムを使用することが期待される。例えば、
RADIUS[https://tools.ietf.org/html/rfc2865]をサポートするデバイス上のNETCONFサーバーはRADIUSを使用して
NETCONセッションを認証する。
　認証プロセスでは認証されたクライアントidentityを提供する（MUST）。認証されたクライアントのidentityはNETCONF
usernameと呼ばれる。Usernameは [https://www.w3.org/TR/2000/REC-xml-20001006]のSection 2.2 "Char"
productionと同一の文字列である。Usernameを算出するために使用するアルゴリズムは、トランスポートプロトコル、トラン
スポートプロトコルで使用する認証メカニズムに依存する。トランスポートプロトコルは、他のNETCONFレイヤで使用される
usernameを提供すること（MUST）。
　Usernameで特定されるクライアントのアクセス許可は、NETCONFサーバーの設定の一部である。このアクセス許可は
NETCONFセッションに適用される（MUST）。アクセス制御の設定方法の詳細はこのドキュメントのスコープ外である。
2.3. Mandatory Transport Protocol
　NETCONFの実装はSSHトランスポートプロトコルマッピング[https://tools.ietf.org/html/rfc6242]をサポートする
こと（MUST）。
3. XML Considerations
XMLはNETCONFのエンコーディングフォーマットであり、テキストツール、XML用のツールの両方で読み書き、保存が可能なテ
キスト形式で複雑な階層データを表現できる。
全てのNETCONFメッセージはUTF-8[https://tools.ietf.org/html/rfc3629]でエンコードされたwell-formed XML
であること（MUST）。ピアがwell-formed XMLでないか、UTF-8でエンコードされていない<rpc>メッセージを受信した場
合、"malformed-message" errorで応答すること（SHOULD）。応答が送信できない場合、サーバーはセッションを終了する
こと（MUST）。
　
　NETCONFメッセージはXML declaration（宣言）[https://www.w3.org/TR/2000/REC-xml-20001006のSection
2.8]から開始する。
　　#XML宣言の例：<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
　
　このSectionではNETCONFに関連するXMLの事項について述べる。
3.1. Namespace
　全てのNETCONFプロトコルelementは以下のnamespaceで定義される。
urn:ietf:params:xml:ns:netconf:base:1.0
　NETCONFのcapability名はURI[https://tools.ietf.org/html/rfc3986]であること（MUST）。NETCONFの
capabilityはsection 8参照。
3.2. Document Type Declarations
　Document type宣言（declarations））[https://www.w3.org/TR/2000/REC-xml-20001006のSection 2.8]は
NETCONF contentには存在しないこと。
　　#Document type宣言の例：<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
8

4. RPC Model
　NETCONFプロトコルはRPCベースの通信を使用する。NETCONFピアは<rpc>elementと<rpc-reply>elementを使用してト
ランスポートプロトコルに依存しない、NETCONF requestとresponseを提供する。
　Messagesレイヤ RPCの構文とXMLエンコーディングはAppendix BのXMLスキーマで定義される。
4.1. <rpc> Element
<rpc>elementには必須attributeの"message-id"がある。これはRPCの送信者によって選択された文字列であり、一般的
にはインクリメントされる整数である。RPC受信者はこの文字列をデコードしたり解釈せずに、応答の<rpc-reply>メッセージ
の"message-id"attributeに使用するために保存する。送信者はこの文字列が変更されずに応答されることを希望する場合、
"message-id"の値が[https://www.w3.org/TR/2000/REC-xml-20001006]で定義されたnormalization rule（正規
化規則）で正規化されていることを保証すること（MUST）。下記は例。
#normalizationの解説
#http://www.y-adagio.com/public/standards/jis_xml/main.html#AVNormalize
#http://www.atmarkit.co.jp/fxml/rensai/w3cread19/w3cread19.html
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>

</some-method>
</rpc>
　他のattributeが<rpc>elementに存在する場合、NETCONFピアは<rpc-reply>elementで変更せずattributeを応答す
ること（MUST）。これには任意の"xmlns" attributeが含まれる。
　RPCの名前とパラメーターは<rpc>elementのcontentとしてエンコードされる。RPCの名前は<rpc>elementの直下に存在
するelementである。その中に他の全てのパラメーターが含まれる。
　以下の例では<my-own-method>メソッドを呼び出している。このメソッドには値が14の<my-first-parameter>、値が
fredの<another-parameter>の2つのパラメーターが含まれる。
<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>
　以下の例では<rock-the-house>メソッドを値27606-0100のパラメーター<zip-code>で呼び出している。
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
　以下の例では、NETCONF <get>メソッドをパラメーター無しで呼び出している。
9

<get/>
</rpc>
4.2. <rpc-reply> Element
　<rpc-reply>メッセージは<rpc>メッセージの応答として送信される。
　<rpc-reply>elementには必須attribute"message-id"がある。これは<rpc>の"message-id"attributeと同じであ
る。
　NETCONFサーバーは<rpc-reply>elementに<rpc>elementに含まれる他のattributeも返すこと（MUST）。
　Responseデータは<rpc-reply>elementに1つ以上のchild elementとしてエンコードされる。
　以下の<rpc>elementはNETCONF <get>メソッドを呼び出し、"user-id"というattributeを含む。
"user-id"attributeがNETCONF namespaceにないことに注意せよ。<rpc-reply>は"user-id"attributeと要求され
たcontentを返す。
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:ex="http://example.net/content/1.0"
ex:user-id="fred">
<data>

</data>
</rpc-reply>
4.3. <rpc-error> Element
　<rpc-error>elementは<rpc>requestの処理中にエラーが発生した場合、<rpc-reply>メッセージで送信される。
　<rpc>requestの処理中にサーバーで複数のエラーが発生した場合、<rpc-reply>は複数の<rpc-error>elementを含んで
よい（MAY）。しかし、requestに複数のエラーが含まれている場合、サーバーは複数の<rpc-error>elementを検出/報告す
る必要はない。サーバーは特定の順序でエラーをチェックする必要はない。処理中にエラーが発生した場合、サーバーは
<rpc-error>elementを返すこと（MUST）。
　サーバーはクライアントがアクセス権をもたないアプリケーションレベル、データモデル固有のエラー情報を
<rpc-error>elementで返してはならない（MUST NOT）。
　#不正に読み取られるの防止
　<rpc-error>elementには以下の情報が含まれる。
名前説明必須パラメーター
error-type エラーが発生したレイヤを定義する
Enumeration。
○ 下記の中の1つ。
　transport（Secure Transportレイ
10

ヤ）
　rpc（Messagesレイヤ）
　protocol（Operationsレイヤ）
　application（Contentレイヤ）
error-tag エラーを識別する文字列。許容される値は
Appendix Aを参照。
○ https://tools.ietf.org/html/rfc624
1#appendix-A
error-severity デバイスによって決定されたエラーの重要度
を識別する文字列。
○ 下記の中の1つ。
　error
　warinig
このドキュメントではwarningを使用する
<error-tag>は定義されていない。
error-app-tag データモデル固有または実装固有のエラーを
識別する文字列。エラーを適当な
error-app-tagに関連付けられない場合、
このelementは存在しない。サーバーはデー
タモデル固有と実装固有のerror-app-tag
が存在する場合、データモデル固有の値を使
用すること（MUST）。
error-path 特定の<rpc-error>elementで報告される
エラーに関連するノードへのelement path
を指定する絶対
XPath[https://www.w3.org/TR/1999/
REC-xpath-19991116/]。Elementまたは
datastore nodeがエラーに関連付けられな
い場合、このelementは存在しない。
XPathは以下のコンテキストで解釈される。
● Namespace宣言は
<rpc-error>elementのscopeにあ
る。
● 可変bindingはempty。
● Function libraryはcore
function library。
コンテキストノードは報告されたエラーに関
連付けられたノードに依存する。
● Payload elementをエラーに関連付け
ることができる場合、コンテキストノー
ドは<rpc>elementである。
● そうでない場合、コンテキストノードは
全てのデータモデルの最上位ノードを子
ノードとするノードである。
error-message 人向けの文字列でエラーを表現する。エラー
に対する適当なメッセージが存在しない場
合、このelementは存在しない。この
elementは
[https://www.w3.org/TR/2000/REC-x
ml-20001006]で定義され、RFC3470の通
り、"xml:lang" attributeを含むこと（
SHOULD)。
error-info プロトコルまたはデータモデル固有のエラー
contentが含まれる。エラーに対してそのよ
うなエラーcontentが提供されていない場
合、このelementは存在しない。Appendix
Aに各エラーに必須のerror-info
contentを定義する。データモデルは特定の
アプリケーションレイヤのエラー情報が
error-infoに含まれることを要求してもよ
い（MAY）。実装は拡張/実装固有のデバッグ
情報を提供するために使用してもよい（MAY
11

）。
　Appendix AにNETCONFの標準エラーを記載する。
　<message-id>attribute無しで<rpc>elementを受信した場合、エラーが返される。この場合に限り、NETCONFピアは
<rpc-reply>elementの"message-id"attributeを省略できる。
　#設定するパラメーターはAppendix Aで指定されている。
<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>#Messagesレイヤなのでrpc
<error-tag>missing-attribute</error-tag>#Appendix Aで指定されている
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>#attributeの名前
<bad-element>rpc</bad-element>#不足しているattributeのelementの名前
</error-info>
</rpc-error>
</rpc-reply>
次の<rpc-reply>は複数の<rpc-error>elementを返す場合の例である。
このsectionの例で使用されているデータモデルは<name>elementを使用して<interface>elementの複数のインスタンス
を区別している。
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-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-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
12

</error-message>
</rpc-error>
</rpc-reply>
4.4. <ok> Element
<rpc>requestの処理中にエラーまたはwarningが発生せず、operationによるデータが返されなかった場合、
<ok>elementが<rpc-reply>メッセージで送信される。
<ok/>
</rpc-reply>
4.5. Pipelining
<rpc>requestは、管理対象のデバイスによりシリアルに処理されること（MUST）。追加の<rpc>requestが前のrequestが
完了する前に送信されてもよい（MAY）。管理対象のデバイスはrequestを受信した順序でresponseを送信すること（MUST
）。
5. Configuration Model
　NETCONFは基本operationとそれを補完するためのcapabilityを提供する。NETCONFピアはSection 8.1に記載のとお
り、セッション開始時にデバイスのcapabilityを交換する。
5.1. Configuration Datastores
　NETCONFは1つ以上のconfiguration datastoreを定義し、それらの操作を可能とする。configuration datastoreは
デバイスをinitial default stateから所望のrunning stateにするために必要な全configuration dataとして定義さ
れる。Configuration datastoreにはstate data、executive commandは含まれない。
#executive commandって何？
　Running configuration datastoreはデバイスで現在アクティブな全configurationを保持する。このタイプの
configuration datastoreはデバイスに1つだけ、常に存在する。NETCONFプロトコルoperationは<running>element
を使用してこのdatastoreにアクセスする。
　基本モデルには<running> configuration datastoreのみが存在する。追加のconfiguration datastoreが
capabilityによって定義されてよい（MAY）。追加のdatastoreはcapabilityをadvertiseするデバイスでのみ使用でき
る。
　Section 8.3、8.7のcapabilityは<candidate>、<startup> configuration datastoreを定義する。
5.2. Data Modeling
　データモデリングとcontentはNETCONFプロトコルのスコープ外。
　NETCONFはデバイス固有のデータモデルを<config>element内に格納する。プロトコルはそのelementのcontentを解釈で
きないデータとして扱う。デバイスはデバイスが実装するデータモデルをcapabilityで通知する。Capabilityの定義はデータ
モデルで定義されたoperation、制限を示す。
　デバイスとマネージャーは標準データモデルと固有データモデルの両方を含む複数のデータモデルをサポートしてよい。
13

6. Subtree Filtering
6.1. Overview
　XMLサブツリーのフィルタリングは、特定のXMLサブツリーを<get>または<get-config>の<rcp-reply>に含めるようにア
プリケーションが選択できるようにするメカニズムである。包含(inclusion)、完全一致(exact-match)、選択
(selection)のための少数のフィルタが提供される。サーバーはデータモデルに固有ではなく、シンプルな実装が可能になる。
サブツリーフィルターのコンセプトは、フィルター選択基準(filter selection criteria)を表す0個以上のelementサブ
ツリーから構成される。サーバーの指定されたdatastore内の関連するノードのみがフィルタによって選択される。<fileter>
の直下の階層から開始するようにフィルター絶対パス名が設定されることを除き、フィルターデータに指定されたelementの選択
基準と階層に一致するnodeが選択される。
　Responseメッセージにはフィルターによって選択されたサブツリーのみが含まれる。Any selection criteria that
were present in the request, within a particular selected subtree, are also included in the
response。Leaf nodeとしてフィルターに示されるelementは、フィルターのアウトプットにサブツリーとして含まれる。
Requestに同じデータを選択する複数のフィルターサブツリーが含まれている場合、データインスタンスはresponseに複製され
ない。
6.2. Subtree Filter Components
　サブツリーフィルターはXML elementとXML attributeで構成される。サブツリーフィルターには5つのタイプのコンポーネ
ントがある。
● Namespace Selection
● Attribute Match Expressions
● Containment Nodes
● Selection Nodes
● Content Match Nodes
6.2.1. Namespace Selection
<filter>element内のnamespaceがデータモデルと同じ場合、namespaceが一致すると判断される。Namespaceによる選
択では1つ以上のelementをフィルターに指定すること（MUST）。
Namespaceワイルドカードのメカニズムが定義される。<filter>element内のelementがnamespaceで指定されない場合
（例：xmlns=""）、サーバーはそのサブツリーフィルターノードを処理するときに、サポートする全てのXML namespaceを選
択すること（MUST）。このワイルドカードのメカニズムはXML attributeには適用されない。
　修飾されたnamespaceのprefixはフィルタelementとデータモデルのelementを比較する場合に無視される。
#qualified name（修飾されたname）=QNameという。
<body xmlns:book="http://example.com/ns/book/">
<book:title>test</book:title>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>
　上記の例では<top>elementがselection nodeであり、"http://example.com/schema/1.2/config" namespace
内のtopとその子ノードがフィルタのアウトプットに格納される。
14

6.2.2. Attribute Match Expressions
　サブツリーフィルターに設定されるattributeはattribute match expressionである。任意の数の（修飾or非修飾）の
XML attributeが任意のタイプのフィルーターノードに設定されてよい（MAY）。そのノードに適用される選択基準に加えて、
選択されたデータは指定された全てのattributeに一致する値を持つこと（MUST）。Elementが指定されたattributeを含ま
ない場合、フィルターで選択されない。
<t:top xmlns:t="http://example.com/schema/1.2/config">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
　上記の例では、<top>elementと<interface>elementはcontainment node、<interface>elementはselection
node、ifNameはattribute match expressionである。
　"http://example.com/schema/1.2/config" namespaceの"top"ノード内の"interfaces"ノード内の
"interface"ノードで"ifName"attributeの値が"eth0"のノードのみがアウトプットに含まれる。
6.2.3. Containment Nodes
　サブツリーフィルター内に子elementを含むノードを”containment nodes（包含ノード）”という。各子elementは別の包
含ノードを含む任意のタイプのノードでよい。サブツリーフィルターで指定されたcontainment node毎にnamespace、階層、
attribute match expressionが含まれる。
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
　上記の例では、<top>がcontainment nodeである。#子elementがusersでselection node
6.2.4. Selection Nodes
フィルター内のempty leaf nodeは"selection node（選択ノード）"と呼ばれ、データモデルに対する"explicit
selection（明示的選択）"フィルタを示す。フィルターのためにempty leaf nodeは空のタグ（例：<foo /> or
<foo></foo>）で宣言することができる。この形式ではwhitespaceは無視される。
<users/>
</top>
</filter>
上記の例では、<top>elementはcontainment node、<users>elementはselection nodeである。
　Configuration datastoreの"http://example.com/schema/1.2/config" namespaceの<top>element内の”
user”ノードのみがアウトプットに含まれる。
6.2.5. Content Match Nodes
　単純なleaf nodeを"content match node"と呼ぶ。フィルタ出力用のノードの一部を洗濯するために使用され、leaf
node elementに一致するフィルタを表す。Content match nodeには以下の制約がある。
● Content match nodeはネストされたelementを含まないこと（MUST NOT）。
15

● 複数のcontent match node（sibling nodes）はANDで結合される。
● Mixed contentのフィルタリングはサポートされない。
● List contentのフィルタリングはサポートされない。
● Whitespace-only contentはサポートされない。
● Content match nodeは空白以外の文字を含むこと（MUST）。empty element（例：<foo></foo>）は
selection node（<foo />）として解釈される。
● 頭と末尾の空白文字は無視されるが、文字内の空白文字は無視されない。
指定された全てのcontentがサブツリーフィルター内のノードに一致する場合、フィルタの出力は以下のように設定される。
● 各content match nodeがフィルタの出力に含まれる。
● Containment nodeがネストされている場合、さらにフィルタ処理が実施される。
● Selection nodeがネストされている場合、それらの全てがフィルタ出力に含まれる。
● それ以外の場合（つまりselection node、containment nodeが存在しない場合）、データモデルで定義された
ノードがフィルタのアウトプットに設定される。
　Content match nodeに一致しない場合、フィルタ出力には何も設定されない。
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
　上記の例では<users>nodeと<user>nodeはcontainment nodeであり、<name>はcontent match ndoeである。
　<name>のsibling nodeは設定されていないため、<name>のsibling nodeは全てフィルタのアウトプットに設定される。
指定された階層で<name>elementが"fred"であり、http://example.com/schema/1.2/config namespaceの"user"
ノードがフィルタのアウトプットに含まれる。
6.3. Subtree Filter Processing
　各サブツリーフィルターには、1つ以上のデータモデルフラグメントを含めることができる。これは、フィルター出力に選択さ
れるデータモデルの部分を表す。
　各サブツリーのデータフラグメントはサーバーがサポートするデータモデルと比較される。データフラグメントがデータモデル
と完全一致する場合、そのノードと全ての子が結果に含まれる。
6.4. Subtree Filtering Examples
6.4.1. No Filter
<get>operationでフィルターを終了すると全データモデルが返される。
<get/>
</rpc>
<data>

</data>
16

</rpc-reply>
6.4.2. Empty Filter
　Emptyフィルターはcontent match nodes、selection nodeが存在しないため何も選択しない。これはエラーではない。
以下の例で使用されている<filter>elementの"type" attributeはSection 7.1参照。
<get>
</filter>
</get>
</rpc>
<data>
</data>
</rpc-reply>
6.4.3. Select the Entire <users> Subtree
　この例のフィルターには1つのselection node(<users>)が含まれているため、そのサブツリーがフィルターで選択され
る。
　注意：本ドキュメントで使用されているフィルターの例は"http://example.com/schema/1.2/config" namespaceに
ある。このnamespaceのroot elementは<top>である。
<get-config>
<source>
<running/>
</source>
<users/>
</top>
</filter>
</get-config>
</rpc>
<data>
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
17

</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>
　以下のフィルターは<users>が1つの子element<user>を定義しているため、同じ結果を生成する。
<get-config>
<source>
<running/>
</source>
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
6.4.4. Select All <name> Elements within the <users> Subtree
　このフィルターには2つのcontainment node<users>、<user>と1つのselection node<name>が含まれる。選択され
た<name>elementの全てのインスタンスがアウトプットされる。クライアントは<name>がインスタンスの識別子として使用さ
れていることを知る必要があるかもしれないが、サーバーは意識する必要がない。
<get-config>
<source>
<running/>
</source>
18

<users>
<user>
<name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<data>
<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
　このフィルターには2つのcontainment node<users>、<user>と1つのcontent match node<name>が含まれる。
<name>の値が"fred"に等しい<name>を含む全てのインスタンスがアウトプットされる。
<get-config>
<source>
<running/>
</source>
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<data>
19

<users>
<user>
<name>fred</name>
<type>admin</type>
<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
　このフィルタには2つのcontainment node<users>、<user>、1つのcontent match node<name>、2つのselection
node<type>、<full-name>が含まれる。<name>の値が"fred"に等しい<name>の<type>、<full-name>elementの全て
のインスタンスがアウトプットされる。Selection nodeが含まれるため、<company-info>elementは含まれない。
<get-config>
<source>
<running/>
</source>
<users>
<user>
<name>fred</name>
<type/>
<full-name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<data>
<users>
<user>
<name>fred</name>
<type>admin</type>
</user>
</users>
</top>
</data>
</rpc-reply>
20

6.4.7. Multiple Subtrees
　このフィルターには3つのサブツリー(name=root, fred, barney)が含まれている。
　rootサブツリーフィルターには2つのcontainment node<users>、<user>、1つのselection node<company-info>
が含まれる。サブツリー選択基準によりrootの<company-info>サブツリーが選択される。
　fredサブツリーフィルターには3つのcontainment node<users>、<user>、<company-info>、1つのcontent match
node<name>、1つのselection node<id>が含まれる。サブツリー選択基準により<company-info>サブツリーの"fred"の
<id>elementが選択される。
　barneyサブツリーフィルターには3つのcontainment node<users>、<user>、<company-info>、2つのcontent
match node<name>、<type>、1つのselection node<dept>が含まれる。user barneyが"superuser"でなく、
barneyのサブツリーがフィルタから除外されるため、選択されない。
<get-config>
<source>
<running/>
</source>
<users>
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<company-info>
<dept/>
</company-info>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<data>
<users>
<user>
<name>root</name>
<company-info>
<dept>1</dept>
21

<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
　この例では、containment node<interfaces>、attribute match expression"ifName"、selection
node<interface>が含まれる。ifName attributeが"eth0"に等しい<interface>サブツリーの全てのインスタンスが選
択される。フィルターdata elementとattributeは修飾されているため、ifName attributeはschema/1.2 namespace
とみなされ、修飾される。
<get>
<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>
<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>
ifNameがattributeではなく子ノードである場合、以下のrequestは同じ結果になる。
<get>
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
22

<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
7. Protocol Operations
　NETCONFプロトコルはデバイスconfigを管理し、デバイスのstate情報を取得するための低レベルのoperationを提供す
る。Baseプロトコルはconfiguration datastoreを読み取り、設定、コピー、削除するためのoperationを提供する。デバ
イスによってadvertiseされるcapabilityによって追加のoperationが提供される。
　Baseプロトコルには以下のプロトコルoperationが含まれる。
● get
● get-config
● edit-config
● copy-config
● delete-config
● lock
● unlock
● close-session
● kill-session
　プロトコルoperationは"operation not supported"等の様々な理由で失敗する可能性がある。Initiatorはどのよう
なoperationでも必ず成功すると想定しないこと（SHOULD NOT）。RPC replyの戻り値によりエラー応答のチェックをするこ
と（SHOULD）。
　プロトコルoperationの構文（シンタックス）とXMLエンコーディングはAppendix CのYANG moduleで定義される。以下の
sectionでは各プロトコルoperationのセマンティクスについて説明する。
7.1. <get-config>
名前 get-config
概要　指定されたconfiguration datastoreの全て/一部を取得する。
パラメーター
source 　<running/>のようなqueryされるconfiguration datastoreの名前。
filter 　このパラメーターはデバイスのconfiguration datastoreを取得する箇
所を指定する。このパラメーターが存在しない場合は全てが送信される。
　オプションで"type"attributeを含んでよい（MAY）。このattributeは
<filter>element内で使用されるフィルタータイプを示す。NETCONFのデ
フォルトフィルター（Section 6）はサブツリーフィルターとよばれ、値
"subtree"で指定する。NETCONFピアが:xpath capability（Section
8.9）をサポートしている場合、値"xpath"は<filter>elementの
"select"attributeにXPathが含まれていることを示す。
Positive Response 　デバイスがrequestを完了した場合、サーバーはqueryの結果
<data>elementを含む<rpc-reply>elementを送信する。
23

Negative Response 　デバイスがrequestを完了できなかった場合、<rpc-error>elementが
<rpc-reply>elementに含まれる。
Example <users>サブツリーを取得する。
<get-config>
<source>
<running/>
</source>
<users/>
</top>
</filter>
</get-config>
</rpc>
<data>
<users>
<user>
<name>root</name>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>

</users>
</top>
</data>
</rpc-reply>
7.2. <edit-config>
名前 edit-config
概要　Configurationを指定されたconfiguration datastoreにロードす
る。Targetのconfiguration datastoreが存在しない場合は作成され
る。NETCONFピアが:url capability(Section 8.8)をサポートしている
場合、<config>の代わりに<url>を使用してもよい。
Attributes
operation 　<config>内のelementはSection 3.1で定義されたNETCONF
namespaceに属する"operation" attributeを含んでよい(MAY)。この
attributeはoperationを識別し、<config>内に複数存在してよい(MAY)
。
　"operation" attributeが存在しない場合、configurationの親ノー
ドに適用されたoperationが適用される。親ノードのoperationがない場
合、<default-operation>パラメーターの値が使用される。
<default-operation>パラメーターが指定されていない場合、
24

configuration datastoreへmargeされる。
　"operation" attributeには以下の値のいずれか1つが設定される。
● merge
　<target>で指定されたconfiguration datastoreの
configurationにマージされる。デフォルトの動作。
● replace
　Configurationによって<target>で指定されたconfiguration
datastoreを置き換える。<copy-config>operationと異なり、
<config>内のパラメーターのみが設定される。過去に設定したconfig
をロードしたい場合等に使う。
● create
　Configuration datastoreに<config>のデータが存在しない場合
のみ、データが追加される。既に存在する場合、<error-tag>が
"data-exists"の<rpc-error>が返される。
● delete
Configuration datastoreに<config>のデータが存在する場合の
み、データが削除される。存在しない場合、<error-tag>が
"data-missing"の<rpc-error>が返される。
● remove
　Configuration datastoreに<config>のデータが存在する場合の
み、データが削除される。存在しない場合、"remove" operationは無
視される。
merge/replaceの違い
#<edit-config> operation+mergeは既存のconfigurationはそのまま、
新規のconfigurationで更新/新規追加する。
#<edit-config> operation+replaceは既存configurationを全て削除
し、新規のconfigurationで置き換える。
#例：hello-timeを40から60にするときに、hello-time=60を
<edit-config>した場合
# merge：hello-timeが40から60に変更される。replace：全configが消
え、hello-time=60だけが残る。
#http://discuss.tail-f.com/t/difference-between-merge-and-r
eplace-attribute-in-edit-config/1568
パラメーター
target 　<running/>や<candidate/>等の編集するconfiguration
datastoreの名前。
default-operation 　<edit-config>requestのデフォルトのoperation。
<default-operation>のデフォルト値はmerge。<default-operation>
はオプション。設定可能な値は下記。
● merge
● Replace
● none
　"operation"で別のoperationが指定されるまでtargetの
datastoreは<config>パラメーターの影響を受けない。<config>に対
応するパラメーターがtarget datastoreに無い場合、<error-tag>
が"data-missing"の<rpc-error>が返される。Delete時に親要素を
消さないため等に使用する（Example参照）。
test-option 　デバイスが:validate:1.1 capabilityをサポートする場合にのみ使用
してよい（MAY）（Section 8.6）。<test-option>は下記のいずれか値が
設定される。
● test-then-set
　設定する前に検証テスト（validation）を実行する。検証テストでエ
ラーが発生して場合、<edit-config>operationを実行しない。デ
フォルトのテストオプション。
● set
　検証テスト無しに設定する。
● test-only
　設定せず、検証テストのみを行う。
25

error-option 　<error-option>には下記のいずれかの値が設定される。
● stop-on-error
　最初に発生したエラーで<edit-config> operationを中止
(abort)する。デフォルトのerror-option。
● continue-on-error
　エラーが発生しても処理を継続する。エラーは記録され、エラーが発生
した場合はnegative responseが生成される。
● rollback-on-error
　<rpc-error>等のエラーが発生した場合、サーバーは
<edit-config> operationを中止し、<edit-config>
operation前の状態にリストアする。このオプションを使用する場
合、:rollback-on-error capability（Section 8.5）のサポー
トが必要。
config デバイスのデータモデルによって定義されたconfiguration dataの階層。
適切なnamespaceにコンテンツを設定し（MUST）、データモデルの定義に
従って設定すること。
Positive Response 　デバイスがrequestを完了できた場合、<ok>elementを含む
<rpc-reply>が送信される。
Negative Response 　Requestを完了できなかった場合、<rpc-error>elementが
Example 　<interface>elementの複数のインスタンスが存在し、各
<interface>element内の<name>elementでインスタンスを区別する。
● running configuration datastoreの"Ethernet0/0"という名前
のinterfaceのMTUを1500に設定する。
<edit-config>
<target>
<running/>
</target>
<config>
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<ok/>
</rpc-reply>
● running configuration datastoreに"Ethernet0/0"という名
前のinterfaceを追加し、既存のinterfaceを置き換える。
<edit-config>
<target>
<running/>
</target>
<config
26

<interface xc:operation="replace">
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<ok/>
</rpc-reply>
● running configuration datastoreから"Ethernet0/0"という
名前のinterfaceを削除する。
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config
<interface xc:operation="delete">
</interface>
</top>
</config>
</edit-config>
</rpc>
<ok/>
</rpc-reply>
OSPFエリアからinterface 192.0.2.4を削除する。他のinterfaceには影
響を与えない。
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config
<protocols>
<ospf>
<area>
<name>0.0.0.0</name>
<interfaces>
<interface xc:operation="delete">
<name>192.0.2.4</name>
</interface>
</interfaces>
27

</area>
</ospf>
</protocols>
</top>
</config>
</edit-config>
</rpc>
<ok/>
</rpc-reply>
7.3. <copy-config>
名前 copy-config
概要　Configuration datasotre全体を作成/他のconfiguration
datastoreで置き換えをする。Target datastoreが存在する場合は上書き
される。それ以外の場合、許可されていれば新規に作成される。
　NETCONFピアが:url capability(Section 8.8)をサポートする場合、
<url>elementを<source>または<target>に設定してよい。
　:witable-running capabilityを宣言した場合でも、デバイスは
<copy-config>operationの<target>パラメーターとして、<running/>
configuration datastoreをサポートしなくてもよい（MAY）。デバイス
は、<source><target>の両方が<url>elementを使用するリモート-リ
モート間のコピーoperationをサポートしなくてもよい（MAY）。
<source><target>が同じURLまたはconfiguration datastoreの場
合、"invalid-value"のerror-tagでエラーを返す。
パラメーター
target 　<copy-config>operationのdstとして使用するconfiguration
datastoreの名前。
source 　<copy-config>operationのsrcとして使用するconfiguration
datastoreの名前。またはコピーする全configを含む<config>element。
Example <rpc message-id="101"
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user:password@example.com/cfg/new.txt</url>
</source>
</copy-config>
</rpc>
28

<ok/>
</rpc-reply>
7.4. <delete-config>
名前 delete-config
概要　Configuration datastoreを削除する。<running> configuration
datastoreは削除できない。
　NETCONFピアが:url capability（Section 8.8）をサポートする場
合、<url>elementが<target>パラメーターに設定されてよい。
パラメーター
target 　削除するconfiguration datastoreの名前。
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
<ok/>
</rpc-reply>
7.5. <lock>
名前 lock
概要　<lock> operationにより、クライアントはデバイスのconfiguration
datastore全体をロックできる。クライアントは他のNETCONFクライアン
ト、非NETCONFクライアント（例：SNMP、CLI等）等との考慮不要で変更がで
きることを可能とする。既存のセッション、他のエンティティが既にロックを
所有している場合、configuration datastoreへのロックは失敗すること
（MUST）。
　ロックが獲得された場合、サーバーはロックを獲得したセッション以外が
ロックされたリソースを変更することを禁止すること（MUST）。非NETCONFク
ライアント（SNMP、CLI等）も同様に変更を禁止し、適切なエラーとする。
　ロックは獲得したロックが解放されるか、NETCONFセッションが終了するま
で継続する。セッションの解放は、クライアントによって明示的に実行される
か、トランスポートの切断、inactivity timeout（インアクティブタイム
アウト）、サーバーによる暗黙の切断等により行われる。これらは実装とトラ
ンスポートの仕様に依存する。
　<lock> operationの必須パラメーターは<target>である。<target>は
ロックするconfiguration datastoreの名前を指定する。ロックがアク
29

ティブな場合、ロックされたconfiguration datastoreに対する
<edit-config> operationの使用、<copy-config> operationの
targetへの指定は許可されない。さらに、システムはロックされた
configurationリソースがSNMP、CLI等の非NETCONFで変更されないことを
保証する。<kill-session> operationは別のNETCONFセッションが所持
するロックを強制的に解放するために使用する。他のエンティティが所有する
ロックを解放する方法の定義は本ドキュメントのスコープ外である。
　以下のいずれかの条件を満たす場合、ロックを許可しないこと（MUST NOT
）。
● ロックは既にNETCONFセッションまたは他のエンティティによって所有さ
れている。
● Targetのconfigurationが<candidate>であり、変更済みでそれらの
変更がcommit or rollbackされていない。
● Target configurationが<running>であり、別のNETCONFセッショ
ンがconfirmed commit中である（Section 8.4）。
　サーバーは<ok>または<rpc-error>のいずれかで応答すること（MUST）。
　何らかの理由でロックを所有しているNETCONFセッションが終了した場合、
システムによってロックが解放されること。
パラメーター
target 　ロックするconfiguration datastoreの名前。
　ロックが既に所有されている場合、<error-tag>elementは
"lock-denied"になり、<error-info>elementにはロック所有者の
<session-id>が設定される。ロックが非NETCONFエンティティによって所有
されている場合、<session-id>には0が設定される。
Example ● ロックの獲得が成功
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<ok/> 
</rpc-reply>
● 既にNETCONFセッション454がロック済みのためロックの獲得が失敗
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-error> 
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
30

<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>

</error-info>
</rpc-error>
</rpc-reply>
7.6. <unlock>
名前 unlock
概要　<unlock>operationは<lock>operationで取得された
configuration lockを解放するために使用される。
　次のいずれかの条件を満たす場合、<unlock>operationは失敗する。
● 指定したlockがアクティブではない。
● <unlock>operationを発行したセッションがlockを取得したセッ
ションと異なる。
　サーバーは<ok>elementまたは<rpc-error>elementのどちらかで応答
すること（MUST）。
パラメーター
target 　Unlockするconfiguration datastoreの名前。
　NETCONFクライアントはlockされていないconfiguration datastore
をunlockできない。
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<ok/>
</rpc-reply>
7.7. <get>
名前 get
概要　Running configurationとdevice state informationを取得す
る。
パラメーター
31

filter 　　このパラメーターはデバイスのconfiguration datastoreを取得する
箇所を指定する。このパラメーターが存在しない場合は全ての
configuration、state informationが送信される。
　オプションで"type"attributeを含んでよい（MAY）。このattributeは
<filter>element内で使用されるフィルタータイプを示す。NETCONFのデ
フォルトフィルター（Section 6）はサブツリーフィルターとよばれ、値
"subtree"で指定する。NETCONFピアが:xpath capability（Section
8.9）をサポートしている場合、値"xpath"は<filter>elementの
"select"attributeにXPathが含まれていることを示す。
Positive Response 　デバイスがrequestを完了した場合、サーバーはqueryの結果
<data>elementを含む<rpc-reply>elementを送信する。
<get>
<interfaces>
<interface>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
<data>
<interfaces>
<interface>
<ifInOctets>45621</ifInOctets>
<ifOutOctets>774344</ifOutOctets>
</interface>
</interfaces>
</top>
</data>
</rpc-reply>
7.8. <close-session>
名前 close-session
概要　NETCONFセッションの正常終了を要求する。
　NETCONFサーバーが<close-session>requestを受信するとセッション
は正常終了する。サーバーはセッションに関連するlock、リソースを解放し、
接続を正常終了する。<close-session>request後に受信したNETCONF
requestは全て無視される。
パラメーター
なし
32

<close-session/>
</rpc>
<ok/>
</rpc-reply>
7.9. <kill-session>
名前 kill-session
概要　NETCONFセッションを強制終了する。
　NETCONFエンティティがセッションへの<kill-session>requestを受信
した場合、処理中のoperationを中止し、セッションに関連するlockとリ
ソースを解放し、接続を終了する。
　NETCONFサーバーがcommit（Section 8.4）を処理中に
<kill-session>requestを受信した場合、commitが発行される前の
configurationにリストアすること（MUST）。それ以外の場合、
<kill-session>operationはlockを保持するエンティティによる
cofigurationへの変更、device stateの変更をロールバックしない。
パラメーター
session-id 　強制終了するNETCONFセッションのセッションID。この値が現在のセッショ
ンIDと等しい場合、"invalid-value"errorが返される。
<kill-session>
</kill-session>
</rpc>
<ok/>
</rpc-reply>
8. Capabilities
33

このsectionではクライアントまたはサーバーが実装してもよい（MAY）capabilityを定義する。各ピアはinitial
capabilities exchangeでcapabilityを送信することで自身のcapabilityをアドバタイズする。各ピアは使用する可能性
のあるcapabilityだけを理解(understand)する必要があり、受信したcapabilityで不要または理解できない(does node
understand)ものは無視すること（MUST）。
　Appendix Dのテンプレートを使用して追加のcapabilityを定義してよい。独自拡張も可能。
　NETCONF capabilityはURIで識別される。Base capabilityはRFC
3553[https://tools.ietf.org/html/rfc3553]に記述される方法に従い、URNで定義される。本ドキュメントで定義され
るcapabilityフォーマットは下記である。
　urn:ietf:params:netconf:capability:{name}:1.x
　{name}はcapabilityの名前である。Capabilityに複数のバージョンがある場合、:{name}または:{name}:{version}
という省略形を使ってemail等で参照されることがある。
例えば、foo capabilityは正式名称"urn:ietf:params:netconf:capability:foo:1.0"であり、":foo"と呼ばれ
る。プロトコルでは省略形を使用しないこと（MUST NOT）。
8.1. Capabilities Exchange
　Capabilityはセッション確立中に各ピアによって送信されたメッセージによってアドバタイズされる。NETCONFセッションが
オープンになると、各ピア（クライアント、サーバーの両方）は、自身のcapabilityのリストを含む<hello>elementを送信
すること（MUST）。各ピアは最低限、base NETCONF capability "urn:ietf:params:netconf:base:1.1"を送信する
こと（MUST）。ピアは複数のプロトコルバージョンのサポートを示すために前のNETCONFバージョン capabilityを含めてよ
い（MAY）。
　両方のNETCONFピアは相手のピアが共通のプロトコルバージョンをアドバタイズしたことを確認すること（MUST）。
Protocol version capability URIを比較する場合、URI文字列の最後にパラメーターが付与さている場合、base part
のみが使用される。共通のprotocol varsion capabilityが無い場合、NETCONFピアはセッションを継続しないこと（MUST
）。共通のプロトコルバージョンURIが複数存在する場合、最も大きい番号（最新）のプロトコルバージョンを両方のピアが使用
すること（MUST）。
　#パラメーターは”;”、”=”のようなものだと思う。例："urn:ietf:params:netconf:base:1.1;param=xx"
　<hello>elementを送信するサーバーはそのNETCONFセッションのセッションIDを含む<session-id>elementを含めるこ
と（MUST）。<hello>elementを送信するクライアントは<session-id>elementを含めないこと（MUST NOT）。
　<session-id>elementが含まれる<hello>メッセージを受信したサーバーはNETCONFセッションを終了すること（MUST
）。クライアントはサーバーの<hello>メッセージに<session-id>elementが含まれていない場合、<close-session>を送
信せずにNETCONFセッションを終了すること（MUST）。
　以下の例では、サーバーはbase NETCONF capability、base NETCONF documentで定義されたNETCONF capability
1個、実装固有のcapability 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>
34

</hello>
　各ピアはコネクションのオープン時に同時に<hello>elementを送信する。ピアは自身のcapability送信について、相手か
らのcapability受信を待たないこと（MUST NOT）。
8.2. Writable-Running Capability
名前 Writable-Running Capability
:writable-running
概要　:writable-running capabilityはデバイスが<running>configuration
datasotreへの書き込みをサポートすることを示す。デバイスは
<running>configuration datastoreをtargetにする<edit-config>、
<copy-config>operationをサポートする。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:writable-running:1.0
New Operations なし
Modifications to Existing Operations
<edit-config> 　:writable-running capabilityは<running>elementを<target>に指定でき
るように<edit-config>operationを変更する。
<copy-config> 　:writable-running capabilityは<running>elementを<target>に指定でき
るように<copy-config>operationを変更する。
8.3. Candidate Configuration Capability
名前 Candidate Configuration Capability
:candidate
概要　Candidate configuration capability（:candidate）はデバイスがデバイス
のrunning configurationに影響を与えずに変更可能なcandidate
configuration datastoreをサポートしていることを示す。Candidate
configurationはconfigurationを作成、変更するためのwork領域として機能する
完全なconfiguration datastoreである。<commit> operationにより、
candidate configurationをrunning configurationに設定できる。
Candidate configurationは複数のセッションで共有される。クライアントが「
candidate configurationが共有されていない」という情報を持っていない限り、他
のセッションとcandidate configurationが共有されていると想定すること（MUST
）。そのため、クライアントがcandidate configurationを変更する場合はロックす
るのが望ましい。
　クライアントは<discard-changes> operationを実行することでcandidate
configurationのコミットされていない変更を破棄できる。このoperationにより
candidate configurationはrunning configurationになる。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:candidate:1.0
New Operations
35

<commit> 　Candidate configurationの変更が完了後、configuration dataをコミット
することで、他のデバイスに変更を公開し、デバイスに新しいconfigurationで動作さ
せることを要求できる。
　Candidate configurationをコミットするためには<commit> operationを使
用する。
　<commit> operationはcandidate configurationを組み込むようにデバイス
に指示をする。デバイスがcandidate configuration datastore内の全ての変更
をコミットできない場合、running configurationは変更しないこと（MUST）。デ
バイスがコミットが成功した場合、running configurationをcandidate
configurationで更新すること（MUST）。
　Running configurationまたはcandidate configurationが異なるセッション
からロックされている場合、<commit> operationは<error-tag>が"in-use"で失
敗すること（MUST）。
　システムが:candidate capabilityをサポートしていない場合、<commit>
operationは使用できない。
Positive Response 　デバイスがrequestを完了できた場合、<ok>elementを含む<rpc-reply>が送信さ
れる。
<commit/>
</rpc>
<ok/>
</rpc-reply>
<discard-changes> 　<discard-changes> operationによってクライアントはcandidate
configurationをrunning configuationに戻すことができる。クライアントが
candidate configurationをコミットしないと判断した場合等に使用する。
　このoperationは、running configurationでcandidate configurationを
リセットすることで、コミットされていない全ての変更を破棄する。
れる。
<discard-changes/>
</rpc>
<get-config>, <edit-config>,
<copy-config>, and <validate>
　<candidate>elementによりcandidate configurationを<source>または
<tartget>に設定できる。
<get-config>
<source>
<candidate/>
</source>
</get-config>
</rpc>
36

<lock> and <unlock> 　<candidate>elementによりcandidate configurationを<tartget>に設定で
きる。
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
8.4. Confirmed Commit Capability
名前 Confirmed Commit Capability
:confirmed-commit:1.1
概要　:confirmed-commit:1.1 capabilityはサーバーが
<cancel-commit>operationと<commit>operationのパラメーターである
<confirmed>、<confirm-timeout>、<presist>、<persist-id>をサポートす
ることを示す。また、"to be confirmed"（確認中）の
<commit>operation(confirmed commit)とconfirming（確認のための）
<commit>operationを区別する。<commit>operationの詳細はsection 8.3参
照。
　Confirming commitがタイムアウト期間内（デフォルト600秒(10分)）に発行され
ない場合、confirmed<commit>operationは元に戻すこと（MUST）。Confirming
commitとは、<confirmed>パラメーター無しの<commit>operationであり、成功し
た場合は元に戻せない。タイムアウト期間は<confirm-timeout>パラメーターで調整
できる。タイマーが満了する前にconfirmed <commit>operationが発行されると、
タイマーは新しい値（デフォルト600秒）にリセットされる。Confirming commitと
confirmed <commit>operationの両方でconfigurationに変更が加えられてよい
（MAY）。
　Confirmed <commit>operationに<persist>elementが含まれていない場合、
後続のconfirmed <commit>とconfirming <commit>はconfirmed <commit>が
発行されたセッションと同一のセッションで発行すること（MUST）。Confirmed
<commit>operationに<persist>elementが含まれている場合、後続のconfirmed
<commit>とconfirming <commit>は任意のセッションで発行することができ、その
際は<persist>elementで指定された値と同じ値が設定された
<persist-id>elementを含むこと（MUST）。
　Shared configurationの場合、configuration lock（例：他のNETCONFセッ
ションへのlock）が使用されない限り、configuration変更が誤って削除、変更され
る可能性がある。そのため、Shared configuration datastoreには
configuration lockを使用することを推奨する（SHOULD）。
　このCapabilityはVersion 1.0で定義された（
RFC4741[https://tools.ietf.org/html/rfc4741]）。Version 1.1は本ド
キュメントで定義されており、新しいoperation<cancel-commit>、新しいオプショ
ンパラメーター<persist>、<persist-id>が追加された。下位互換性のために
Version1.1のサーバーはVersion 1.0をアドバタイズしてもよい（MAY）。
Dependencies :candidate capability
37

Capability Identifier urn:ietf:params:netconf:capability:confirmed-commit:1.1
New Operations
名前 cancel-commit
概要　Confirmed commitを取り消す。<persist-id>が指定されていない場合、
confirmed <commit>を発行した同じセッションで<cancel-commit>operationを
発行すること（MUST）。
パラメーター
persist-id 　<commit>のシーケンスを取り消す。設定する値は<commit>operationの
<persist>で指定された値と等しいこと（MUST）。値が一致しない場合、operation
は"invalid-value"errorで失敗する。
れる。
例 <rpc message-id="101"
<commit>
<confirmed/>
</commit>
</rpc>
<ok/>
</rpc-reply>
<cancel-commit/>
</rpc>
<commit> 　:confirmed-commit:1.1 capabilityは<commit>operationに4つのパラメー
ターを追加する。
confirmed 　Confirmed <commit>operationを実行する。
confirm-timeout 　Confirmed <commit>のタイムアウト期間（秒）。未指定の場合は600秒。
persist 　Confirmed <commit>をセッション終了後も継続させ、そのコミットのトークンを設
定する。
persist-id 　以前の<commit>operationのトークンを使用し、後続のconfirmed <commit>、
confirming <commit>をする。
例1 <rpc message-id="101"
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
38

</rpc>
<ok/>
</rpc-reply>
例2 
<commit>
<confirmed/>
<persist>IQ,d4668</persist>
</commit>
</rpc>
<ok/>
</rpc-reply>

<commit>
<persist-id>IQ,d4668</persist-id>
</commit>
</rpc>
<ok/>
</rpc-reply>
8.5. Rollback-on-Error Capability
名前 Rollback-on-Error Capability
:rollback-on-error
概要　このcapabilityはサーバーが<edit-config>operationの<error-option>パ
ラメーターの値で”roll-on-error”をサポートしていることを示す。
　Shared configurationの場合、configuration lock（例：他のNETCONFセッ
ションへのlock）が使用されない限り、configuration変更が誤って削除、変更され
る可能性がある。そのため、Shared configuration datastoreには
configuration lockを使用することを推奨する（SHOULD）。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:rollback-on-error:1.0
New Operations なし
<edit-config> 　<edit-config>operationの<error-option>パラメーターの値に
roll-on-errorを設定してよい。
例 <rpc message-id="101"
39

<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<interface>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<ok/>
</rpc-reply>
8.6. Validate Capability
名前 Validate Capability
:validate:1.1
概要　Validateはconfigurationをデバイスに適用する前に、構文、セマンティクスのエ
ラーをチェックする。このcapabilityがアドバタイズされる場合、デバイスは
<validate>operationをサポートし、最低限構文エラーをチェックする。さらに、
capabilityは<edit-config>operationに対する<test-option>パラメーターを
サポートし、最低限構文エラーをチェックする。
このcapabilityのversion 1.0は
RFC4741[https://tools.ietf.org/html/rfc4741]で定義された。Version
1.1は本ドキュメントで定義され、<edit-config>operationの<test-option>パ
ラメーターに"test-only"が追加された。下位互換性のためにVersion1.1のサーバー
はVersion 1.0をアドバタイズしてもよい（MAY）。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:validate:1.1
New Operations
名前 validate
概要　指定されたconfigurationを検証する。
パラメーター
source 　<candidate>等のconfiguration datastoreの名前または全configurationを
含む<config>element。
れる。
40

RFC6241(Network Configuration Protocol (NETCONF))の勉強資料

RFC6241(Network Configuration Protocol (NETCONF))の勉強資料

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to RFC6241(Network Configuration Protocol (NETCONF))の勉強資料

Similar to RFC6241(Network Configuration Protocol (NETCONF))の勉強資料 (20)

More from Tetsuya Hasegawa

More from Tetsuya Hasegawa (20)

RFC6241(Network Configuration Protocol (NETCONF))の勉強資料