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
<edit-config> 　<edit-config>operationの<error-option>パラメーターの値に
roll-on-errorを設定してよい。
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

　構文エラー、パラメーター不足、定義されないconfigurationデータへの参照、デー
タモデル上の違反等により<validate>operationは失敗する可能性がある。
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
<ok/>
</rpc-reply>
<edit-config> 　<edit-config>operationが<test-option>パラメーターを許容するように変更
する。
8.7. Distinct Startup Capability
名前 Distinct Startup Capability
:startup
概要　デバイスはrunning configuration とstartup configurationをサポートす
る。Startup configurationはブート時にデバイスによってロードされる。
Running configurationに影響があるoperationは自動的にはstartup
configuration datastoreにコピーされない。<running>から<startup>への
<copy-config>operationはstartup configurationをrunning
configurationで更新するために使用する。NETCONFプロトコルは
<startup>elementを指定することでstartup datastoreを参照する。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:writable-running:1.0
Modifications to Existing Operations 　:startup capabilityはNETCONF operationの引数に
<startup/>configuration datastoreを追加する。サーバーは以下の拡張をサ
ポートすること（MUST）。
<get-config> 　<source>への<startup/>設定をサポート。
<copy-config> 　<srouce>、<tartget>への<startup/>設定をサポート。
<lock> 　<tartget>への<startup/>設定をサポート。
<unlock> 　<tartget>への<startup/>設定をサポート。
<validate> 　<souce>への<startup/>設定をサポート。
　※:validate:1.1がアドバタイズされている場合のみ。
41

<delete-config> 　<tartget>への<startup/>設定をサポート。
　※デバイスを工場出荷時のデフォルト設定にする。
8.8. URL Capability
名前 URL Capability
:url
概要　NETCONFピアは<source>、<tartge>への<url>element設定をサポートする。こ
のcapabilityはサポートされているURLスキームを示すURL引数でさらに分類される。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
　:url capability　URIには"scheme"引数が含まれ（MUST）、NETCONFピアがサ
ポートするスキーム名をカンマ区切りで記載する。
例）
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
<edit-config> 　:url capabilityは<config>パラメーターの代わりに<url>elementの設定をサ
ポートする。urlが参照するファイルには、
"urn:ietf:params:xml:ns:netconf:base:1.0" namespaceの
<config>element配下にXMLエンコードされたconfigurationが含まれている。
<copy-config> 　:url capabilityは<source>、<target>への<url>elementの設定をサポート
する。urlが参照するファイルには、
"urn:ietf:params:xml:ns:netconf:base:1.0" namespaceの
<config>element配下にXMLエンコードされたconfigurationが含まれている。
<delete-config> 　:url capabilityは<target>への<url>elementの設定をサポートする。
<validate> 　:url capabilityは<source>への<url>elementの設定をサポートする。
8.9. XPath Capability
名前 XPath Capability
概要　XPath capabilityはNETCONFピアが<filter>elementへのXPathの使用をサ
ポートすることを示す。XPathは
https://www.w3.org/TR/1999/REC-xpath-19991116/参照。
　XPathに使用されるデータモデルはXPath 1.0である。Rootノードは任意の数の子
ノードを持ってよい（MAY）。XPathは以下のコンテキストで評価される。
● 　Namespace宣言は<filter>elementのスコープ内にあるものである。
● 　可変バインディングはデータモデルで定義される。可変バインディングが定義
されていない場合はempty。
● 　Function libraryはcore function libraryとデータモデルで定義さ
れた全てのfunction。
42

● 　コンテキストノードはrootノード。
　XPathはノードであること（MUST）。ノードでない場合、operationは
"invalid-value"errorで失敗する。Responseメッセージにはfilterで選択された
サブツリーが含まれる。サブツリー毎にデータモデルのrootノードからサブツリーまで
のパスがresponseメッセージに含まれる。
Dependencies なし
Capability Identifier urn:ietf:params:netconf:capability:xpath:1.0
<get>、<get-config> 　:xpath capabilityは<filter>elementの"type"attributeに値"xpath"を
サポートするように<get>、<get-config>を拡張する。"type"attributeに
"xpath"が設定されている場合、"select"attributeは<filter>elementに存在す
ること（MUST）。"select"attributeはXPathであり、フィルタリングするために使
用される。<filter>elementはemptyであること（MUST）。
　XPathの結果はノードの集合であること（MUST）。各ノードはデータモデル内のノー
ドであること（MUST）。各ノードを識別するため、以下の規則が定義される。
● 　親ノードが先にエンコードされるため（MUST）、repsonseの
<data>elementはデータモデルに従うサブツリーのみを含む。
● 　特定のインスタンスを識別するために親ノード、兄弟ノードが必要な場合、そ
れらもresponseでエンコードされること（MUST）。
<get-config>
<source>
<running/>
</source>

<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>
<data>
<users>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
9. Security Considerations
　Base NETCONF message layerとNETCONFプロトコルoperationのセキュリティについて述べる。NETCONFトランスポー
トのセキュリティはトランスポートプロトコルのドキュメントに記載されており、NETCONFで操作されるコンテンツのセキュリ
ティはデータモデルを定義するドキュメントに記載されている。
43

本ドキュメントでは、認証スキームは規定されない。それらはデータモデルに関連するため。実装者はNETCONFに統合的な認証
スキームを提供すること（SHOULD）。
　NETCONFサーバーを介した個々のユーザーの認証は、インターフェースと1:1の場合があり、そうでない場合もある。例えば、
データモデルと互換性がない、トランスポートレイヤ（例：SSH、BEEP）による認証が望ましい場合等がある。
　さらに、configurationへのoperationはlockされたいないと意図しない結果になる場合がある。例えば、running
configurationがlockされていない場合、candidate configurationのlock者がcommitした場合、設定の不整合により
デバイスが利用不可能になる可能性がある。
　Configurationはセキュリティ上、重要である。Integrityチェック無しで送信すると、デバイスは盗聴やインジェクショ
ン攻撃にさらされる。Configurationにはパスワード、ユーザー名、サービス内容、トポロジ情報等が含まれる可能性がある。
そのため、プロトコル実装は攻撃方法に対して適切に実装すること（SHOULD）。
　上記より、プロトコルは最低限、機密性と認証の両方の機能をサポートすること（MUST）。トランスポートプロトコル（SSH、
BEEP等）は必要に応じて機密性と認証の両方を提供する。NETCONFセッションの各ピアの識別情報は、requestの許可を決定す
るために使用することが期待される。NETCONF自体は再認証（re-auth）の方法を提供せず、認証機能自体も十分でない。この
ような機能はすべて下位レイヤで提供する。
　特定のoperationは特に重要である。例えば<copy-config>をstartup/runningに実行するのは通常のプロビジョニング
操作ではない。そのような実行権限を持たない情報の更新、operationは禁止すること（MUST）。例えば、ユーザーAがイン
ターフェース上でIPアドレスを変更することは許可されていないが、ユーザーBが<candidate>でインターフェース上にIPアド
レスを設定している場合、ユーザーAによる<candidate>のcommitはできないこと（MUST NOT）。適切な権限無しにURL
capabilityを使用して特定のconfigurationで設定することも同様である。
　<lock>operationにより、アクセスさせないconfigurationをロックすることが可能である。しかし、そのような場合は結
局configuration全体をロックすることになる。解決方法の1つが、問題のセッションを強制終了することである。もう一つ
は、ネイティブユーザーインターフェース内に機能を提供することである。これらの方法は、問題のあるユーザーをAAAサーバー
から削除することにより解消する。ただし、そのような解決方法は、SSH公開鍵/秘密鍵を使用するシナリオには適用できない。
10. IANA Considerations
10.1. NETCONF XML Namespace
本ドキュメントはNETCONF XML namespaceのURIをIFTF XML registry[RFC3688
https://tools.ietf.org/html/rfc3688]に登録する。
　URI: urn:ietf:params:xml:ns:netconf:base:1.0
10.2. NETCONF XML Schema
　本ドキュメントはNETCONF XML schemaのURIをIFTF XML registry[RFC3688
　URI: urn:ietf:params:xml:schema:netconf
　XML: Appendix B参照。
10.3. NETCONF YANG Module
　本ドキュメントはYANG moduleをYANG Module Names registry[RFC6020
　name: ietf-netconf
　namespace: urn:ietf:params:xml:ns:netconf:base:1.0
44

prefix: nc
　reference: RFC 6241
10.4. NETCONF Capability URNs
　IANAはNETCONF capabilityの識別子を割り当てるregistry "Network Configuration Protocol (NETCONF)
Capability URNs"を管理する。Registryへの追加にはIETF Standards Actionが必要である。
　本ドキュメントの下記のcapabilityを更新、追加する。
: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
:base:1.1　（追加） :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
13. References
https://tools.ietf.org/html/rfc6241#section-13
Appendix A. NETCONF Error List
　本ドキュメントで定義されるエラーのリスト。
error-tag in-use
error-type protocol, application
error-severity error
error-info none
Description Requestには既に使用中のリソースが必要である。
error-tag invalid-value
45

error-info none
Description Requestの1つ以上のパラメーターに許容外の値が設定されている。
error-tag too-big
error-type Transport, rpc, protocol, application
error-info none
Description Requestまたは生成されるresponseが実装のサイズオーバー。
error-tag missing-attribute
error-type rpc, protocol, application
error-info
<bad-attribute> 不足しているattributeの名前。
<bad-element> 不足しているattributeを含むと想定されるelementの名前。
Description 期待するattributeが無い。
error-tag bad-attribute
error-info
<bad-attribute> 不正な値が設定されたattributeの名前。
<bad-element> 不正な値が設定されたattributeのelementの名前。
Description Attributeの値が正しくない。Typeの不一致、範囲外等。
error-tag unknown-attribute
46

error-info
<bad-attribute> 予期しないattributeの名前。
<bad-element> 予期しないattributeのelementの名前。
Description 予期しないattributeが設定されている。
error-tag missing-element
error-info
<bad-element> 不足しているelementの名前。
Description 期待するelementが不足している。
error-tag bad-element
error-info
<bad-element> 不正な値のelementの名前。
Description Elementの値が不正。例：type異常、範囲外、パターンの不一致。
error-tag unknown-element
error-info
<bad-element> 予期しないelementの名前。
Description 予期しないelementが設定されている。
error-tag unknown-namespace
error-info
47

<bad-element> 予期しないnamespaceを含むelement。
<bad-namespace> 予期しないnamespace
Description 予期しないnamespaceが設定されている。
error-tag access-denied
error-info なし
Description 認証に失敗したため、要求されたプロトコルoperationまたはデータモデルへのアクセ
スが拒否された。
error-tag lock-denied
error-info
<session-id> 要求されたlockほ所持しているセッションのセッションID。非NETCONFエンティティ
がロックを所持している場合は0が設定される。
Description ロックが他のエンティティにより所持されているため、要求されたロックの取得が拒否
された。
error-tag resource-denied
error-type transport, rpc, protocol, application
error-info なし
Description リソース不足で要求を完了できなかった。
error-tag rollback-failed
error-info なし
Description 何らかの理由でconfiguration変更をロールバックする処理（rollback-on-error
または<discard-change>）が完了しなかった。
48

error-tag data-exists
error-type application
error-info なし
Description データモデルのコンテンツが既に存在するため、要求を完了できなかった。
例）既に存在するデータに対するcreate operation。
error-tag data-mission
error-info なし
Description データモデルのコンテンツが存在しないため、要求を完了できなかった。
例）存在しないデータに対するdelete operation
error-tag operation-not-supported
error-info なし
Description 要求されたoperationがサポートされていないため、要求が完了できなかった。
error-tag operation-failed
error-info なし
Description 要求されたoperationが他のエラー以外の何らかの原因で失敗したため、要求を完了で
きなかった。
error-tag partial-operation
49

error-info
<ok-element> 要求されたoperationが完了したelement。<error-info>に複数設定されてよい。
<err-element> 要求されたoperationが失敗したelement。<error-info>に複数設定されてよい。
<noop-element> 要求されたoperationが試行されなかったelement。<error-info>に複数設定され
てよい。
Description このerror-tagはobsoleteされているため、本仕様準拠のサーバーは送信しないこと
（SHOULD NOT）。
要求されたoperationの一部が失敗したか試行されなかったことを示す。ロールバック
がサポートされていない等の理由で、サーバー側の完全なoperationクリーンアップが
実行されなかった。
error-tag malformed-message
error-type rpc
error-info なし
Description メッセージを正しくパースできなかったため、メッセージを処理できなかった。
例）メッセージに無効な文字が含まれる。
このerror-tagはbase:1.1で新規追加されたため、古いクライアントには送信しない
こと（MUST NOT）。
Appendix B. XML Schema for NETCONF Messages Layer
NETCONF MessagesレイヤのXML Schema。
https://tools.ietf.org/html/rfc6241#appendix-B
Appendix C. YANG Module for NETCONF Protocol Operations
NETCONFプロトコルoperationのYANG Module。
https://tools.ietf.org/html/rfc6241#appendix-C
Appendix D. Capability Template
　Capabilityを定義するためのテンプレートを規定する。YANGで書かれたデータモデルでは、通常capabilityを定義sルウ必
要はない。YANGを使用ｓるうとデータモデルとデータモデルを宣言するcapabiityを定義できる。Capabilityテンプレート
は、YANGが不十分だったり（例：parameterized features等）、YANG以外のデータモデリング言語が使用される場合に使
用される。
50

D.1. capability-name (template)
D.1.1. Overview
D.1.2. Dependencies
D.1.3. Capability Identifier
　{name} capabilityは以下のcapabilityで識別される。
　string:
　　{capability uri}
D.1.4. New Operations
D.1.4.1. <op-name>
D.1.5. Modifications to Existing Operations
　既存のoperaitonがこのcapabilityによって変更されない場合、このsectionは省略してよい。
D.1.5.1. <op-name>
D.1.6. Interactions with Other Capabilities
　このcapabilityが他のcapabilityと関連しない場合、このsectionは省略してよい。
Appendix E. Configuring Multiple Devices with NETCONF
　1つのデバイスのconfigurationを変更する場合を検討する。Configurationを変更する場合、アプリケーションは変更が
正しく実行され、デバイスの動作、ネットワークに問題が無いことを確認する必要がある。
　デバイスのconfigurationを安全に変更するためにはステップがある。
1. Acquiring the configuration lock
Configurationのロックの取得
2. Checkpointing the running configuration
Running configurationのチェックポイント
3. Changing the running configuration
Running configurationの変更
4. Testing the new configuration
新しいconfigurationのテスト
5. Making the change permanent (if desired)
変更の永続化（必要ならば）
6. Releasing the configuration lock
Configurationのロック解放
各ステップの詳細を以降に示す。
51

E.1.1. Acquiring the Configuration Lock
　複数の更新元からの更新の競合を防ぐためにはロックを取得する必要がある。
　ロックは<lock> operationで取得できる。
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
　:candidate capabilityがサポートされている場合、Candidate configurationをロックする必要がある。
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
E.1.2. Checkpointing the Running Configuration
　新しいconfigurationをロードする前にrunning configurationをローカルファイルに保存してよい。更新が失敗した場
合、チェックポイントファイルをロードすることで復元できる。
　チェックポイントファイルは<copy-config> operationで作成できる。
<copy-config>
<target>
<url>file://checkpoint.conf</url>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
　チェックポイントファイルで復元するためには<source>と<target>を逆にする。
E.1.3. Loading and Validating the Incoming Configuration
　:candidate capabilityがサポートされている場合、実行中のシステムへの影響無しにconfigurationをデバイスにロー
ドできる。
<edit-config>
<target>
52

<candidate/>
</target>
<config>

</config>
</edit-config>
</rpc>
　デバイスが:validate:1.1 capabilityをサポートしている場合、デフォルトではcandidateが設定された契機で
configurationを検証する。これを変更するには、<test-option>に"set"を設定する。検証は<validate> operation
で実行できる。
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
E.1.4. Changing the Running Configuration
　Configurationがロードされ、検証されると実行中のシステムへ適用する準備が完了する。
　デバイスが:candidate capabilityをサポートしている場合は<commit> operationでrunning configurationに
candidate configurationを設定する。<confirmed>パラメーターを使用することで、デバイスへの接続失敗時に自動的に
ロールバックすることができる。
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
　:candidate capabilityがサポートされていない場合、configurationの変更は即座にrunningにロードされる。
<edit-config>
<target>
<running/>
</target>
<config>

</config>
</edit-config>
</rpc>
E.1.5. Testing the New Configuration
　変更がrunning configurationに反映されたため、アプリケーションは変更により問題が発生しないか確認する必要があ
る。
　確認のために、アプリケーションは動作のテストをしてよい。テストの内容は本ドキュメントのスコープ外である。例えば、シ
ステムからの到達性確認（ping）、ネットワークの疎通確認（ルーティングテーブル）等がある。
53

E.1.6. Making the Change Permanent
　Configurationの変更後、アプリケーションは変更を永続化してよい。
　デバイスが:startup capabilityをサポートしている場合、startup configurationを<copy-config> operation
のtargetにすることでstartup configurationに保存できる。
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
　デバイスが:candidate capabilityをサポートし、confirmed commitが要求された場合、タイムアウト前に
confirming commitを送信する必要がある。
<commit/>
</rpc>
E.1.7. Releasing the Configuration Lock
　Configurationの更新の完了後、ロックを解放して他のアプリケーションがconfigurationにアクセスできるようにする。
　<unlock> operationを使用してconfigurationのロックを解放する。
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
　:candidate capabilityがサポートされている場合、candidate configurationのロックを解除する。
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
E.2. Operations on Multiple Devices
　多数のデバイス間でconfigurationの変更が必要な場合、トランザクションのセマンティクスに注意する必要がある。
　
　マルチデバイスoperationには2つのクラスがある。
54

第一のクラスは、全てのデバイスを元の状態に戻す必要がなく、個々のデバイスでoperationを失敗させる。失敗した
operationは後で再試行してもよいし、単に失敗を認識するだけでもよい。具体例には、NTPサーバーの追加がある。このクラス
のoperationでは障害回避、復旧は個々のデバイスで考慮される。
　第二のクラスは、operationが全てのデバイスで完了するか、全て元に戻すかのどちらかである。例えば、VPNを変更するため
には複数のデバイスを変更する必要がある。デバイスの一部だけが新しい設定で更新された場合、問題になる可能性がある。
　
　上記のセマンティクスを提供するために、単一デバイスと同様の手順が全てのデバイスで並列（parallel）に実行される。全
てのデバイスでロックを取得し、更新され、保持、検証される。チェックポイントは各デバイスで行う必要がある。その後、
Running configurationを変更し、テストし、永続化ｓるう。いずれかの手順で失敗した場合、全てのデバイスはローヅバッ
ク可能である。変更が完了or破棄されると各デバイスのロックが解除される。
Appendix F. Changes from RFC 4741
RFC 4741と本ドキュメントの主な変更点のリスト。
"malformed-message" error-tagの追加。
"operation"attributeに"remove"追加。
"partial-operation" error-tagの廃止。
<commit>operationへの<persist>、<persist-id>の追加。
Base protocol URIの更新、<hello> message exchangeの明確化し、特定のセッションで使用されているプロトコル
バージョンの選択する。
Operationをモデル化するためのYANG moduleを追加。XSDからoperation layerを削除。
Candidate datastoreへのlockの挙動を明確化。
"operation"attributeの"delete"に対するエラー動作の明確化。
サブツリーフィルターに関するnamespace ワイルドカードのメカニズム追加。
<test-option>に設定される値<test-only>を<edit-config>operationに追加。
<cancel-commit>operationの追加。
NETCONF usernameとトランスポートプロトコルの要件を追加。Usernameの設定方法の説明追加。
55

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