RFC 4741 - NETCONF Configuration Protocol 日本語訳

URL : https://tools.ietf.org/html/rfc4741
タイトル : RFC 4741 - NETCONF構成プロトコル
翻訳編集 : 自動生成

Network Working Group                                       R. Enns, Ed.
Request for Comments: 4741                              Juniper Networks
Category: Standards Track                                  December 2006

                     NETCONF Configuration Protocol

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）IETFトラスト（2006）。

Abstract

抽象

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer.

この文書で定義されたネットワーク構成プロトコル（NETCONF）は、インストール、操作、およびネットワーク機器の設定を削除するためのメカニズムを提供します。これは、拡張マークアップ言語（XML）は、コンフィギュレーションデータのデータエンコーディングならびにプロトコルメッセージをベース使用します。 NETCONFプロトコル操作が簡単リモートプロシージャコール（RPC）層の上に実現されます。

Table of Contents

   1. Introduction ....................................................5
      1.1. Protocol Overview ..........................................6
      1.2. Capabilities ...............................................7
      1.3. Separation of Configuration and State Data .................7
   2. Transport Protocol Requirements .................................8
      2.1. Connection-Oriented Operation ..............................9
      2.2. Authentication, Integrity, and Confidentiality .............9
      2.3. Authentication .............................................9
      2.4. Mandatory Transport Protocol ..............................10
   3. XML Considerations .............................................10
      3.1. Namespace .................................................10
      3.2. No Document Type Declarations .............................10
   4. RPC Model ......................................................10
      4.1. <rpc> Element .............................................10
      4.2. <rpc-reply> Element .......................................12
      4.3. <rpc-error> Element .......................................12
      4.4. <ok> Element ..............................................16
      4.5. Pipelining ................................................16
   5. Configuration Model ............................................16
      5.1. Configuration Datastores ..................................16
      5.2. Data Modeling .............................................17
   6. Subtree Filtering ..............................................17
      6.1. Overview ..................................................17
      6.2. Subtree Filter Components .................................18
           6.2.1. Namespace Selection ................................18
           6.2.2. Attribute Match Expressions ........................19
           6.2.3. Containment Nodes ..................................19
           6.2.4. Selection Nodes ....................................20
           6.2.5. Content Match Nodes ................................20
      6.3. Subtree Filter Processing .................................22
      6.4. Subtree Filtering Examples ................................22
           6.4.1. No Filter ..........................................22
           6.4.2. Empty Filter .......................................23
           6.4.3. Select the Entire <users> Subtree ..................23
           6.4.4. Select All <name> Elements within the
                  <users> Subtree ....................................25
           6.4.5. One Specific <user> Entry ..........................26
           6.4.6. Specific Elements from a Specific <user> Entry .....27
           6.4.7. Multiple Subtrees ..................................28
           6.4.8. Elements with Attribute Naming .....................29
   7. Protocol Operations ............................................31
      7.1. <get-config> ..............................................31
      7.2. <edit-config> .............................................34
      7.3. <copy-config> .............................................39
      7.4. <delete-config> ...........................................41
      7.5. <lock> ....................................................42

      7.6. <unlock> ..................................................44
      7.7. <get> .....................................................45
      7.8. <close-session> ...........................................47
      7.9. <kill-session> ............................................48
   8. Capabilities ...................................................49
      8.1. Capabilities Exchange .....................................49
      8.2. Writable-Running Capability ...............................50
           8.2.1. Description ........................................50
           8.2.2. Dependencies .......................................50
           8.2.3. Capability Identifier ..............................50
           8.2.4. New Operations .....................................51
           8.2.5. Modifications to Existing Operations ...............51
      8.3. Candidate Configuration Capability ........................51
           8.3.1. Description ........................................51
           8.3.2. Dependencies .......................................52
           8.3.3. Capability Identifier ..............................52
           8.3.4. New Operations .....................................52
           8.3.5. Modifications to Existing Operations ...............53
      8.4. Confirmed Commit Capability ...............................55
           8.4.1. Description ........................................55
           8.4.2. Dependencies .......................................55
           8.4.3. Capability Identifier ..............................56
           8.4.4. New Operations .....................................56
           8.4.5. Modifications to Existing Operations ...............56
      8.5. Rollback on Error Capability ..............................57
           8.5.1. Description ........................................57
           8.5.2. Dependencies .......................................57
           8.5.3. Capability Identifier ..............................57
           8.5.4. New Operations .....................................57
           8.5.5. Modifications to Existing Operations ...............57
      8.6. Validate Capability .......................................58
           8.6.1. Description ........................................58
           8.6.2. Dependencies .......................................58
           8.6.3. Capability Identifier ..............................58
           8.6.4. New Operations .....................................58
      8.7. Distinct Startup Capability ...............................60
           8.7.1. Description ........................................60
           8.7.2. Dependencies .......................................60
           8.7.3. Capability Identifier ..............................60
           8.7.4. New Operations .....................................60
           8.7.5. Modifications to Existing Operations ...............60
      8.8. URL Capability ............................................61
           8.8.1. Description ........................................61
           8.8.2. Dependencies .......................................61
           8.8.3. Capability Identifier ..............................62
           8.8.4. New Operations .....................................62
           8.8.5. Modifications to Existing Operations ...............62

      8.9. XPath Capability ..........................................63
           8.9.1. Description ........................................63
           8.9.2. Dependencies .......................................63
           8.9.3. Capability Identifier ..............................63
           8.9.4. New Operations .....................................63
           8.9.5. Modifications to Existing Operations ...............63
   9. Security Considerations ........................................64
   10. IANA Considerations ...........................................66
      10.1. NETCONF XML Namespace ....................................66
      10.2. NETCONF XML Schema .......................................66
      10.3. NETCONF Capability URNs ..................................66
   11. Authors and Acknowledgements ..................................68
   12. References ....................................................68
      12.1. Normative References .....................................68
      12.2. Informative References ...................................69
   Appendix A. NETCONF Error List ....................................70
   Appendix B. XML Schema for NETCONF RPC and Protocol Operations ....74
   Appendix C. Capability Template ...................................86
      C.1. capability-name (template) ................................86
           C.1.1. Overview ...........................................86
           C.1.2. Dependencies .......................................86
           C.1.3. Capability Identifier ..............................86
           C.1.4. New Operations .....................................86
           C.1.5. Modifications to Existing Operations ...............86
           C.1.6. Interactions with Other Capabilities ...............86
   Appendix D.  Configuring Multiple Devices with NETCONF ............87
      D.1. Operations on Individual Devices ..........................87
           D.1.1. Acquiring the Configuration Lock ...................87
           D.1.2. Loading the Update .................................88
           D.1.3. Validating the Incoming Configuration ..............89
           D.1.4. Checkpointing the Running Configuration ............89
           D.1.5. Changing the Running Configuration .................90
           D.1.6. Testing the New Configuration ......................91
           D.1.7. Making the Change Permanent ........................91
           D.1.8. Releasing the Configuration Lock ...................92
      D.2. Operations on Multiple Devices ............................92
   Appendix E. Deferred Features .....................................93

1. Introduction

1. はじめに

The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets.

NETCONFプロトコルは、ネットワークデバイスを管理することができるような単純な機構、構成データ情報を取得することができ、新しい構成データをアップロードして操作することができると規定しています。プロトコルは、デバイスがフル、正式なアプリケーション・プログラミング・インターフェース（API）を公開することを可能にします。アプリケーションは、フルと部分の構成データ・セットを送受信するために、この単純なAPIを使用することができます。

The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML [1] and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange.

NETCONFプロトコルは、リモートプロシージャコール（RPC）パラダイムを使用します。クライアントは、[1] XMLでRPCを符号化し、安全な、接続指向のセッションを使用してサーバに送信します。サーバは、XMLでエンコードされた応答で応答します。要求と応答の両方の内容は、完全に両当事者が交換に課せられた構文制約を認識できるように、XMLののDTDまたはXMLスキーマ、または両方に記載されています。

A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native functionality of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface.

NETCONFの重要な側面は、それが密接にデバイスのネイティブ機能を反映するために、管理プロトコルの機能性を可能にすることです。これは、実装コストを削減し、新しい機能へのタイムリーなアクセスを可能にします。また、アプリケーションは、デバイスのネイティブ・ユーザー・インターフェースの構文と意味内容の両方にアクセスすることができます。

NETCONF allows a client to discover the set of protocol extensions supported by a server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. Standard and non-standard capabilities can be defined with semantic and syntactic rigor. Capabilities are discussed in Section 8.

NETCONFは、クライアントがサーバによってサポートされているプロトコルの拡張のセットを発見することができます。これらの「機能」は、デバイスによって公開される機能を利用するために、その動作を調整するために、クライアントを許可します。機能の定義を容易に非集中方法で拡張することができます。標準および非標準機能は、セマンティックと構文厳格に定義することができます。機能はセクション8で説明されています。

The NETCONF protocol is a building block in a system of automated configuration. XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XML-based transformation technologies, such as XSLT [8], to provide a system for automated generation of full and partial configurations. The system can query one or more databases for data about networking topologies, links, policies, customers, and services. This data can be transformed using one or more XSLT scripts from a task-oriented, vendor-independent data schema into a form that is specific to the vendor, product, operating system, and software release. The resulting data can be passed to the device using the NETCONF protocol.

NETCONFプロトコルは、自動化された構成のシステムのビルディングブロックです。 XMLは、階層的なコンテンツのための可撓性が、完全に指定されたエンコーディング機構を提供する、交換の共通語です。 NETCONFは、完全および部分構成の自動生成のためのシステムを提供するために、そのようなXSLT [8]などのXMLベースの変換技術と協調して使用することができます。システムは、ネットワークトポロジ、リンク、ポリシー、顧客、およびサービスに関するデータのために1つ以上のデータベースを照会することができます。このデータは、タスク指向の、ベンダーに依存しないデータのベンダーに固有の形式に変換スキーマ、製品、オペレーティングシステム、およびソフトウェアリリースから1つ以上のXSLTスクリプトを使用して形質転換することができます。得られたデータは、NETCONFプロトコルを使用してデバイスに渡すことができます。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。

1.1. Protocol Overview

1.1. プロトコルの概要

NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server. The client can be a script or application typically running as part of a network manager. The server is typically a network device. The terms "device" and "server" are used interchangeably in this document, as are "client" and "application".

NETCONFは、クライアントとサーバ間の通信を容易にするための簡単なRPCベースのメカニズムを使用しています。クライアントは、スクリプトまたはアプリケーションは、通常、ネットワーク管理者の一部として実行することができます。サーバーは通常、ネットワークデバイスです。「クライアント」と「応用」されているような用語「デバイス」と「サーバー」は、この文書では交換可能に使用されています。

A NETCONF session is the logical connection between a network administrator or network configuration application and a network device. A device MUST support at least one NETCONF session and SHOULD support multiple sessions. Global configuration attributes can be changed during any authorized session, and the effects are visible in all sessions. Session-specific attributes affect only the session in which they are changed.

NETCONFセッションは、ネットワーク管理者またはネットワーク・コンフィギュレーション・アプリケーションとネットワークデバイス間の論理接続です。デバイスは、少なくとも1つのNETCONFセッションをサポートしなければならないし、複数のセッションをサポートする必要があります。グローバル構成属性は、任意の許可セッション中に変更することができ、効果はすべてのセッションで表示されます。セッション固有の属性は、それらを変更しただけのセッションに影響を与えます。

NETCONF can be conceptually partitioned into four layers:

NETCONFは概念的に4層に分割することができます。

              Layer                      Example
         +-------------+      +-----------------------------+
     (4) |   Content   |      |     Configuration data      |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (3) | Operations  |      | <get-config>, <edit-config> |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (2) |     RPC     |      |    <rpc>, <rpc-reply>       |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (1) |  Transport  |      |   BEEP, SSH, SSL, console   |
         |   Protocol  |      |                             |
         +-------------+      +-----------------------------+

1. The transport protocol layer provides a communication path between the client and server. NETCONF can be layered over any transport protocol that provides a set of basic requirements. Section 2 discusses these requirements.

1.トランスポートプロトコル層は、クライアントとサーバの間の通信経路を提供します。 NETCONFは、基本的な要件のセットを提供する任意のトランスポートプロトコル上に積層することができます。第2節では、これらの要件について説明します。

2. The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. Section 4 documents this protocol.

2. RPC層は、RPCを符号化するための簡単な、トランスポートに依存しないフレーミング機構を提供します。第4章では、このプロトコルを文書化します。

3. The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base operations.

前記動作層は、XMLでエンコードされたパラメータを使用してRPCメソッドとして呼び出さベース操作のセットを定義します。第7節は基本操作のリストを詳述します。

4. The content layer is outside the scope of this document. Given the current proprietary nature of the configuration data being manipulated, the specification of this content depends on the NETCONF implementation. It is expected that a separate effort to specify a standard data definition language and standard content will be undertaken.

4.コンテンツの層は、この文書の範囲外です。操作されるコンフィギュレーション・データの現在の独自の性質を考えると、このコンテンツの仕様は、NETCONF実装に依存します。標準的なデータ定義言語と標準コンテンツを指定するための別の努力が行われることが期待されます。

1.2. Capabilities

1.2. 機能

A NETCONF capability is a set of functionality that supplements the base NETCONF specification. The capability is identified by a uniform resource identifier (URI). These URIs should follow the guidelines as described in Section 8.

NETCONFの機能はベースNETCONFの仕様を補完する機能のセットです。能力は、ユニフォームリソース識別子（URI）によって識別されます。第8章で説明したようにこれらのURIは、ガイドラインに従ってください。

Capabilities augment the base operations of the device, describing both additional operations and the content allowed inside operations. The client can discover the server's capabilities and use any additional operations, parameters, and content defined by those capabilities.

機能は、追加の動作と操作内部許容コンテンツの両方を記述し、デバイスのベース動作を補強します。クライアントは、サーバの機能を発見し、それらの能力によって定義された任意の追加の操作、パラメータ、およびコンテンツを使用することができます。

The capability definition may name one or more dependent capabilities. To support a capability, the server MUST support any capabilities upon which it depends.

機能の定義は、一つ以上の依存する機能を指定することができます。機能をサポートするために、サーバーは、それが依存するすべての機能をサポートしなければなりません。

Section 8 defines the capabilities exchange that allows the client to discover the server's capabilities. Section 8 also lists the set of capabilities defined in this document.

第8章では、クライアントがサーバの機能を発見することを可能にする機能交換を定義します。セクション8も、この文書で定義された機能のセットを示しています。

Additional capabilities can be defined at any time in external documents, allowing the set of capabilities to expand over time. Standards bodies may define standardized capabilities, and implementations may define proprietary ones. A capability URI MUST sufficiently distinguish the naming authority to avoid naming collisions.

追加機能は、機能のセットは、時間の経過とともに拡大することができ、外部の文書でいつでも定義することができます。標準化団体は、標準化された機能を定義することができ、実装は独自のものを定義することができます。機能は、URIは十分に名前の衝突を避けるために、命名権を区別しなければなりません。

1.3. Separation of Configuration and State Data

1.3. 構成と状態データの分離

The information that can be retrieved from a running system is separated into two classes, configuration data and state data. Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. When a device is performing configuration operations, a number of problems would arise if state data were included:

実行中のシステムから取得できる情報は、2つのクラス、構成データと状態データとに分離されます。コンフィギュレーション・データは、現在の状態にその初期デフォルト状態からシステムを変換するために必要とする書き込み可能なデータのセットです。状態データは、読み取り専用のステータス情報などのデータを設定および統計情報を収集されていないシステム上の追加データです。デバイスは、構成操作を実行しているときの状態データは含まれていた場合、多くの問題が生じるであろう。

o Comparisons of configuration data sets would be dominated by irrelevant entries such as different statistics.

コンフィギュレーション・データ・セットのOの比較は、異なる統計のような無関係なエントリによって支配されるであろう。

o Incoming data could contain nonsensical requests, such as attempts to write read-only data.

O受信データは、読み取り専用のデータを書き込もうとして無意味な要求を、含めることができます。

o The data sets would be large.

Oデータセットは大だろう。

o Archived data could contain values for read-only data items, complicating the processing required to restore archived data.

Oアーカイブデータはアーカイブされたデータを復元するために必要な処理を複雑に、読み取り専用のデータ項目の値を含めることができます。

To account for these issues, the NETCONF protocol recognizes the difference between configuration data and state data and provides operations for each. The <get-config> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data.

これらの問題を考慮して、NETCONFプロトコルは、構成データと状態データとの差を認識し、それぞれのための操作を提供します。 <GET>操作が構成および状態データを取得しながら<GET-config>の動作は、専用の設定データを取得します。

Note that the NETCONF protocol is focused on the information required to get the device into its desired running state. The inclusion of other important, persistent data is implementation specific. For example, user files and databases are not treated as configuration data by the NETCONF protocol.

NETCONFプロトコルがその所望の実行状態にデバイスを取得するために必要な情報に焦点を当てていることに注意してください。その他の重要な、永続的なデータを含めることは、実装固有のものです。たとえば、ユーザーファイルとデータベースは、NETCONFプロトコルによって構成データとして扱われません。

If a local database of user authentication data is stored on the device, whether it is included in configuration data is an implementation-dependent matter.

ユーザ認証データのローカルデータベースがデバイスに格納されている場合、それはコンフィギュレーションデータに含まれているか否かを実装依存問題です。

2. Transport Protocol Requirements

2.トランスポートプロトコルの要件

NETCONF uses an RPC-based communication paradigm. A client sends a series of one or more RPC request operations, which cause the server to respond with a corresponding series of RPC replies.

NETCONFは、RPCベースの通信パラダイムを使用します。クライアントは、サーバーがRPC応答の対応するシリーズで応答する原因となる、一つ以上のRPC要求の一連の操作を送信します。

The NETCONF protocol can be layered on any transport protocol that provides the required set of functionality. It is not bound to any particular transport protocol, but allows a mapping to define how it can be implemented over any specific protocol.

NETCONFプロトコルは、機能の必要なセットを提供する任意のトランスポートプロトコル上に積層することができます。これは、任意の特定のトランスポートプロトコルにバインドされていませんが、マッピングは、それがいかなる特定のプロトコル上で実装する方法を定義することができます。

The transport protocol MUST provide a mechanism to indicate the session type (client or server) to the NETCONF protocol layer.

トランスポートプロトコルは、NETCONFプロトコル層にセッション・タイプ（クライアントまたはサーバ）を示すためのメカニズムを提供しなければなりません。

This section details the characteristics that NETCONF requires from the underlying transport protocol.

このセクションでは、NETCONFは、基礎となるトランスポートプロトコルから必要と特徴を詳しく説明します。

2.1. Connection-Oriented Operation

2.1. コネクション指向の操作

NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide reliable, sequenced data delivery.

NETCONFは、ピア間の永続的な接続を必要とする、コネクション型です。この接続は、信頼性、配列決定されたデータ配信を提供する必要があります。

NETCONF connections are long-lived, persisting between protocol operations. This allows the client to make changes to the state of the connection that will persist for the lifetime of the connection. For example, authentication information specified for a connection remains in effect until the connection is closed.

NETCONF接続は、プロトコル動作の間持続する、長寿命です。これは、クライアントが接続の存続期間持続する接続の状態を変更することができます。接続が閉じられるまで、例えば、接続のための指定された認証情報が有効なまま。

In addition, resources requested from the server for a particular connection MUST be automatically released when the connection closes, making failure recovery simpler and more robust. For example, when a lock is acquired by a client, the lock persists until either it is explicitly released or the server determines that the connection has been terminated. If a connection is terminated while the client holds a lock, the server can perform any appropriate recovery. The lock operation is further discussed in Section 7.5.

接続は、障害回復がよりシンプルかつ堅牢な作り、閉じたときに加えて、特定の接続のためのサーバから要求されたリソースが自動的に解放されなければなりません。ロックがクライアントによって取得された場合、それが明示的に解放されるか、サーバが接続を終了したと判断するまで、例えば、ロックが持続します。クライアントがロックを保持している間、接続が終了した場合、サーバーは、任意の適切なリカバリを実行することができます。ロック操作はさらに、セクション7.5で議論されています。

2.2. Authentication, Integrity, and Confidentiality

2.2. 認証、整合性、および機密性

NETCONF connections must provide authentication, data integrity, and confidentiality. NETCONF depends on the transport protocol for this capability. A NETCONF peer assumes that appropriate levels of security and confidentiality are provided independently of this document. For example, connections may be encrypted in TLS [9] or SSH [10], depending on the underlying protocol.

NETCONF接続は認証、データの整合性、および機密性を提供しなければなりません。 NETCONFはこの機能のためのトランスポートプロトコルに依存します。 NETCONFピアは、セキュリティおよび機密性の適切なレベルは、独立して、この文書の設けられていることを前提としています。例えば、接続は、基礎となるプロトコルに応じて、TLS [9]又はSSH [10]で暗号化することができます。

2.3. Authentication

2.3. 認証

NETCONF connections must be authenticated. The transport protocol is responsible for authentication. The peer assumes that the connection's authentication information has been validated by the underlying protocol using sufficiently trustworthy mechanisms and that the peer's identity has been sufficiently proven.

NETCONF接続が認証される必要があります。トランスポートプロトコルは、認証のために責任があります。ピアは、接続の認証情報が十分に信頼できるメカニズムを使用して基礎となるプロトコルによって検証し、ピアの識別情報が十分に証明されていることをされていることを前提としています。

One goal of NETCONF is to provide a programmatic interface to the device that closely follows the functionality of the device's native interface. Therefore, it is expected that the underlying protocol uses existing authentication mechanisms defined by the device. For example, a device that supports RADIUS [11] should allow the use of RADIUS to authenticate NETCONF sessions.

NETCONFの目標の1つは密接にデバイスのネイティブインタフェースの機能を、以下のデバイスへのプログラム・インタフェースを提供することです。したがって、基本的なプロトコルは、デバイスによって定義されている既存の認証メカニズムを使用することが期待されます。例えば、RADIUS [11]をサポートするデバイスは、RADIUSを使用することがNETCONFセッションを認証できるようにするべきです。

The authentication process should result in an identity whose permissions are known to the device. These permissions MUST be enforced during the remainder of the NETCONF session.

認証プロセスは、その権限デバイスに知られているアイデンティティを生じるはずです。これらの権限は、NETCONFセッションの残りの部分の間に実施されなければなりません。

2.4. Mandatory Transport Protocol

2.4. 必須トランスポートプロトコル

A NETCONF implementation MUST support the SSH transport protocol mapping [4].

NETCONF実装は、SSHトランスポートプロトコルのマッピングをサポートしなければならない[4]。

3. XML Considerations

3. XMLの考慮事項

XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.

XMLは、複雑な階層データは、読み取り保存、およびXMLに固有の伝統的なテキストツールとツールの両方で操作することができるテキスト形式で表現されることを可能にする、NETCONFのための符号化フォーマットとして機能します。

This section discusses a small number of XML-related considerations pertaining to NETCONF.

このセクションでは、NETCONFに関連するXML関連の考慮事項の少数について説明します。

3.1. Namespace

3.1. 名前空間

All NETCONF protocol elements are defined in the following namespace:

すべてのNETCONFプロトコル要素は、次の名前空間で定義されています。

urn:ietf:params:xml:ns:netconf:base:1.0

URN：IETF：のparams：XML：NS：NETCONF：ベース：1.0

NETCONF capability names MUST be URIs [5]. NETCONF capabilities are discussed in Section 8.

NETCONF機能名はURIのでなければならない[5]。 NETCONF機能はセクション8で説明されています。

3.2. No Document Type Declarations

3.2. いいえドキュメントタイプ宣言ません

Document type declarations MUST NOT appear in NETCONF content.

文書型宣言は、NETCONFの内容に現れてはいけません。

4. RPC Model

4. RPCモデル

The NETCONF protocol uses an RPC-based communication model. NETCONF peers use <rpc> and <rpc-reply> elements to provide transport protocol-independent framing of NETCONF requests and responses.

NETCONFプロトコルは、RPCベースの通信モデルを使用します。 NETCONFピアは使用<RPC>と<RPC-返信>要素は、NETCONF要求と応答のトランスポートプロトコルに依存しないフレーミングを提供します。

4.1. <rpc> Element

4.1. <RPC>エレメント

The <rpc> element is used to enclose a NETCONF request sent from the client to the server.

<RPC>要素は、クライアントからサーバに送られたNETCONF要求を囲むために使用されます。

The <rpc> element has a mandatory attribute "message-id", which is an arbitrary string chosen by the sender of the RPC that will commonly encode a monotonically increasing integer. The receiver of the RPC does not decode or interpret this string but simply saves it to be used as a "message-id" attribute in any resulting <rpc-reply> message. For example:

<RPC>要素は、一般的に単調に増加する整数をコードするRPCの送信者によって選択された任意の文字列であり、必須属性「メッセージID」を有します。 RPCの受信機は、デコード又は解釈、この文字列を単に任意得られた<rpc-応答>メッセージ内の「メッセージID」属性として使用するためにそれを保存しません。例えば：

       <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <some-method>
           <!-- method parameters here... -->
         </some-method>
       </rpc>

If additional attributes are present in an <rpc> element, a NETCONF peer MUST return them unmodified in the <rpc-reply> element.

追加の属性は、<RPC>要素内に存在する場合、NETCONFピアは<RPC返信>要素に、それらが非修飾返さなければなりません。

The name and parameters of an RPC are encoded as the contents of the <rpc> element. The name of the RPC is an element directly inside the <rpc> element, and any parameters are encoded inside this element.

名前とRPCのパラメータは、<RPC>要素の内容として符号化されます。 RPCの名前を直接<RPC>要素内の要素であり、そして任意のパラメータは、この要素の内部に符号化されます。

The following example invokes a method called <my-own-method>, which has two parameters, <my-first-parameter>, with a value of "14", and <another-parameter>, with a value of "fred":

次の例は、「フレッド」の値が、「14」、および<他のパラメータ>の値と、2つのパラメータ<私の第パラメータ>を有する<MY-自法>と呼ばれるメソッドを、呼び出します：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <MY-自身法のxmlns = "http://example.net/me/my-自身/ 1.0" > <私の-最初のパラメータ> 14 </私の-最初のパラメータ> <他のパラメータ>フレッド</他のパラメータ> </私-自身-方法> </ RPC>

The following example invokes a <rock-the-house> method with a <zip-code> parameter of "27606-0100":

次の例では、<ロック・ハウス>「27606から0100」の<郵便番号>パラメータを持つメソッドを呼び出します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック・ハウスのxmlns = "http://example.net/rock/1.0" > <郵便番号> 27606-0100 </郵便番号> </ロック・ハウス> </ RPC>

The following example invokes the NETCONF <get> method with no parameters:

次の例では、パラメータなしでNETCONF <GET>メソッドを呼び出します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET /> </ RPC>

4.2. <rpc-reply> Element

4.2. <RPC-返信>要素

The <rpc-reply> message is sent in response to an <rpc> operation.

<rpc-応答>メッセージは、<RPC>操作に応答して送信されます。

The <rpc-reply> element has a mandatory attribute "message-id", which is equal to the "message-id" attribute of the <rpc> for which this is a response.

<RPC返信>要素は、これが応答された<RPC>の「メッセージID」属性に等しい必須属性「メッセージID」を有します。

A NETCONF peer MUST also return any additional attributes included in the <rpc> element unmodified in the <rpc-reply> element.

NETCONFピアはまた、<RPC返信>要素で修飾されていない<RPC>要素に含まれる任意の追加属性を返さなければなりません。

The response name and response data are encoded as the contents of the <rpc-reply> element. The name of the reply is an element directly inside the <rpc-reply> element, and any data is encoded inside this element.

応答名と応答データは、<RPC返信>要素の内容として符号化されます。応答の名前を直接<RPC返信>要素内の要素であり、任意のデータは、この要素の内部に符号化されます。

For example:

例えば：

The following <rpc> element invokes the NETCONF <get> method and includes an additional attribute called "user-id". Note that the "user-id" attribute is not in the NETCONF namespace. The returned <rpc-reply> element returns the "user-id" attribute, as well as the requested content.

次の<RPC>要素は、NETCONF <GET>メソッドを呼び出し、「ユーザーID」と呼ばれる追加の属性を含んでいます。「ユーザID」属性はNETCONFの名前空間ではないことに注意してください。返さ<RPC返信>要素は、「ユーザID」属性だけでなく、要求されたコンテンツを返します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：EX = "http://example.net/content/1.0" 例：ユーザID = "フレッド"> <GET /> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ex="http://example.net/content/1.0" ex:user-id="fred"> <data>  </data> </rpc-reply>

<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：EX = "http://example.net/content/1.0" EX：ユーザ-id = "フレッド"> <データ> <！ - ここに内容... - > </データ> </ RPC-返信>

4.3. <rpc-error> Element

4.3. <RPC-エラー>要素

The <rpc-error> element is sent in <rpc-reply> messages if an error occurs during the processing of an <rpc> request.

エラーが<RPC>要求の処理中に発生した場合、<RPCエラー>要素は、<RPC返信>メッセージで送信されます。

If a server encounters multiple errors during the processing of an <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error> elements. However, a server is not required to detect or report more than one <rpc-error> element, if a request contains multiple errors. A server is not required to check for particular error conditions in a specific sequence. A server MUST return an <rpc-error> element if any error conditions occur during processing and SHOULD return an <rpc-error> element if any warning conditions occur during processing.

サーバーは<RPC>要求<RPC返信>の処理中に複数のエラーが発生した場合に複数の<RPCエラー>要素を含んでいてもよいです。要求が複数のエラーが含まれている場合は、サーバは、複数の<RPC-エラー>要素を検出または報告する必要はありません。サーバーは、特定の配列中の特定のエラー状態をチェックする必要はありません。エラー状態が処理中に発生し、任意の警告条件は、処理中に発生した場合、<RPCエラー>要素を返す必要がある場合、サーバは、<RPCエラー>要素を返さなければなりません。

A server MUST NOT return application-level- or data-model-specific error information in an <rpc-error> element for which the client does not have sufficient access rights.

サーバは、クライアントが十分なアクセス権を持たないため、<RPCエラー>要素には、アプリケーション、レベルやデータ・モデル固有のエラー情報を返してはなりません。

The <rpc-error> element includes the following information:

<RPCエラー>要素は、以下の情報が含まれます。

error-type: Defines the conceptual layer that the error occurred. Enumeration. One of:

エラータイプ：エラーが発生したことを概念的な層を定義します。列挙。の一つ：

* transport

*輸送

* rpc

* RPC

* protocol

*プロトコル

* application

* 応用

error-tag: Contains a string identifying the error condition. See Appendix A for allowed values.

エラータグは：エラー状態を識別する文字列が含まれています。使用できる値については、付録Aを参照してください。

error-severity: Contains a string identifying the error severity, as determined by the device. One of:

エラーの重大度：デバイスによって決定されるように、エラーの重大度を識別する文字列を含んでいます。の一つ：

* error

*エラー

* warning

*警告

error-app-tag: Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition.

エラーアプリタグは：が存在する場合、データ・モデル固有または実装固有のエラー状態を識別する文字列を含んでいます。いかなる適切なアプリケーション・エラー・タグは、特定のエラー状態に関連することができない場合には、この要素が存在しないであろう。

error-path: Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace.

エラーパスは：エラーは特定のRPCエラー要素で報告されて関連付けられているノードに要素パスを識別する絶対XPathの[2]式を含みます。いかなる適切なペイロード要素が特定のエラー状態に関連することができない場合、またはQStringのは「エラー情報」容器に戻さ「悪い要素が」エラーに関連付けられているノードを識別するのに十分である場合は、この要素が存在しないであろう。 XPath表現を解釈する場合には、名前空間宣言のセットは、デフォルトの名前空間を含むRPCエラー要素にスコープのものです。

error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute as defined in [1] and discussed in [12].

エラーメッセージ：エラー状態を記述する人間の表示に適した文字列が含まれています。いかなる適切なメッセージが特定のエラー状態のために提供されていない場合、この要素が存在しないであろう。 [1]で定義されており、[12]で説明したようにlang属性：この要素は、XMLを含むべきです。

error-info: Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in Appendix A defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information.

エラー情報：プロトコルに、データ・モデル固有のエラー内容が含まれています。そのようなエラー内容は、特定のエラー状態のために提供されていない場合、この要素が存在しないであろう。付録Aのリストには、各エラーのいずれかの必須のエラー情報の内容を定義します。任意のプロトコルによって義務付けられたコンテンツの後に、データモデルの定義は、特定のアプリケーション層のエラー情報がエラー情報コンテナに含まれることを強制してもよいです。実装は、拡張および/または実装固有のデバッグ情報を提供するために、追加の要素を含んでもよいです。

Appendix A enumerates the standard NETCONF errors.

付録Aには、標準のNETCONFのエラーを列挙します。

Example:

例：

An error is returned if an <rpc> element is received without a message-id attribute. Note that only in this case is it acceptable for the NETCONF peer to omit the message-id attribute in the <rpc-reply> element.

<RPC>要素は、メッセージIDの属性なしで受信された場合、エラーが返されます。この場合のみに、<RPC返信>要素内のメッセージ-id属性を省略するNETCONFピアことが許容可能であることに留意されたいです。

<RPCのxmlns = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <GET-config>の<ソース> <ランニング/> </ソース> </取得-config>の</ RPC>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>rpc</error-type> <error-tag>missing-attribute</error-tag> <error-severity>error</error-severity> <error-info> <bad-attribute>message-id</bad-attribute> <bad-element>rpc</bad-element> </error-info> </rpc-error> </rpc-reply>

<RPC返信のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <RPCエラー> <エラータイプ> RPC </エラータイプ> <エラータグ>欠落属性< /エラータグ> <エラーの重大度>誤り</エラーの重大度> <エラー情報> <悪い属性>メッセージID </悪い属性> <悪い要素> RPC </不良素子> </エラー・インフォメーション> </ RPC-エラー> </ RPC-返信>

The following <rpc-reply> illustrates the case of returning multiple <rpc-error> elements.

次の<RPC返信>複数の<RPCエラー>要素を返す場合を示しています。

Note that the data models used in the examples in this section use the <name> element to distinguish between multiple instances of the <interface> element.

このセクションの例で使用されるデータモデルは、<インターフェイス>要素の複数のインスタンスを区別するために、<name>要素を使用することに留意されたいです。

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>application</error-type> <error-tag>invalid-value</error-tag> <error-severity>error</error-severity> <error-message xml:lang="en"> MTU value 25000 is not within range 256..9192 </error-message> <error-info> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>25000</mtu> </interface> </top> </error-info> </rpc-error> <rpc-error> <error-type>application</error-type> <error-tag>invalid-value</error-tag> <error-severity>error</error-severity> <error-message xml:lang="en"> Invalid IP address for interface Ethernet1/0 </error-message> <error-info> <top xmlns="http://example.com/schema/1.2/config"> <interface xc:operation="replace"> <name>Ethernet1/0</name> <address> <name>1.4</name> <prefix-length>24</prefix-length> </address> </interface> </top> </error-info> </rpc-error> </rpc-reply>

<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：XC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0 「> <RPCエラー> <エラータイプ>アプリケーション</エラータイプ> <エラータグ>無効値</エラータグ> <エラーの重大度>誤り</エラーの重大度> <エラーメッセージのXML ：LANG = "EN"> MTU値25000がレンジ256..9192 </エラーメッセージ> <エラー情報> <トップのxmlns = "http://example.com/schema/1.2/config" 内ではありません> <インターフェイス> <名前>のEthernet0 / 0 </名前> <MTU> 25000 </ MTU> </インターフェイス> </トップ> </エラー・インフォメーション> </ RPC-エラー> <RPC-エラー> <エラー型>アプリケーション</エラータイプ> <エラータグ>無効値</エラータグ> <エラーの重大度>誤り</エラーの重大度> <エラーメッセージのXML：langは=「EN」>インターフェイスの無効なIPアドレスethernet1を/ 0 </エラー・メッセージ> <エラー情報> <トップのxmlns = "http://example.com/schema/1.2/config"> <境界xc：操作= "置き換え"> <名前> ethernet1を/ 0 </名前> <アドレス> <名前> 1.4 </名前> <プレフィックス長> 24 </プレフィックス長> </アドレス> </インターフェイス> </トップ> </エラー・インフォメーション> </ RPCエラー> </ RPC-返信>

4.4. <ok> Element

4.4. <OK>要素

The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request. For example:

<OK>要素は、エラーまたは警告が<RPC>要求の処理中に発生していないメッセージ場合<RPC返信>に送信されます。例えば：

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

4.5. Pipelining

4.5. パイプライン

NETCONF <rpc> requests MUST be processed serially by the managed device. Additional <rpc> requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.

NETCONF <RPC>リクエストは、管理対象デバイスでシリアルに処理しなければなりません。以前のものが完了する前に追加の<RPC>リクエストを送るかもしれません。管理対象デバイスは、唯一の要求が受信された順に応答を送らなければなりません。

5. Configuration Model

5.構成モデル

NETCONF provides an initial set of operations and a number of capabilities that can be used to extend the base. NETCONF peers exchange device capabilities when the session is initiated as described in Section 8.1.

NETCONFは、操作の初期セットとベースを拡張するために使用することができる機能の数を提供します。 8.1節で説明したようにセッションが開始されたときNETCONFピアは、デバイスの機能を交換します。

5.1. Configuration Datastores

5.1. コンフィギュレーション・データストア

NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them. A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands.

NETCONFは、1つ以上の構成データストアの存在を定義し、それらに構成操作を可能にします。コンフィギュレーション・データストアは、所望の動作状態にその初期デフォルト状態からデバイスを取得するために必要とされるコンフィギュレーション・データの完全なセットとして定義されます。コンフィギュレーション・データストアは、状態データや幹部のコマンドが含まれていません。

Only the <running> configuration datastore is present in the base model. Additional configuration datastores may be defined by capabilities. Such configuration datastores are available only on devices that advertise the capabilities.

のみ<ランニング>コンフィギュレーション・データストアは、ベースモデルに存在しています。追加の構成データストアは、能力によって定義することができます。このような構成のデータストアにのみ機能を通知デバイス上で利用可能です。

o Running: The complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. NETCONF protocol operations refer to this datastore using the <running> element.

Oの実行：ネットワークデバイス上で現在アクティブな完全な構成を。このタイプの唯一のコンフィギュレーション・データストアは、デバイス上に存在し、それは常に存在しています。 NETCONFプロトコルの動作は、<実行>要素を使用して、このデータストアを参照します。

The capabilities in Sections 8.3 and 8.7 define the <candidate> and <startup> configuration datastores, respectively.

セクション8.3と8.7での機能は、それぞれ、<候補>と<スタートアップ>コンフィギュレーションデータストアを定義します。

5.2. Data Modeling

5.2. データモデリング

Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model.

データモデリングおよびコンテンツの問題はNETCONFプロトコルの範囲外です。仮定は、デバイスのデータ・モデルは、アプリケーションによく知られていると判断し、両当事者は、このようなデータのレイアウト、封じ込め、キーイング、検索、置き換え、および管理だけでなく、課されるその他の制約などの問題を認識しているということですデータモデルによる。

NETCONF carries configuration data inside the <config> element that is specific to device's data model. The protocol treats the contents of that element as opaque data. The device uses capabilities to announce the set of data models that the device implements. The capability definition details the operation and constraints imposed by data model.

NETCONFは、デバイスのデータ・モデルに固有の<config>要素内の構成データを運びます。プロトコルは、不透明なデータとしてその要素の内容を処理します。デバイスは、デバイスが実装するデータモデルのセットを発表する能力を使用しています。機能の定義は、操作とデータモデルによる制約を詳しく説明しています。

Devices and managers may support multiple data models, including both standard and proprietary data models.

デバイスと管理者は、標準および独自のデータモデルの両方を含む複数のデータ・モデルをサポートすることができます。

6. Subtree Filtering

6.サブツリーのフィルタリング

6.1. Overview

6.1. 概要

XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the <rpc-reply> for a <get> or <get-config> operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The agent does not need to utilize any data-model-specific semantics during processing, allowing for simple and centralized implementation strategies.

XMLサブツリーフィルタリングは、アプリケーションが<GET>または<GET-config>の動作のために<RPC返信>に含める特定のXMLサブツリーを選択することを可能にする機構です。含めるためのフィルタの小さなセットは、単純なコンテンツ完全一致、および選択は、いくつかの有用なだけでなく、非常に限られた、選択メカニズムを可能にする、提供されます。エージェントは、シンプルで集中管理実装戦略を可能に、処理中に任意のデータ・モデル固有のセマンティクスを利用する必要はありません。

Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output.

概念的には、サブツリーのフィルタは、フィルタ選択基準を表すゼロ個以上の要素のサブツリー、から構成されています。サブツリー内の各封じ込めレベルで、兄弟ノードのセットは、論理的にそのサブツリーと根への要素のパスはフィルタ出力に含まれているかどうかを決定するために、サーバーによって処理されます。

All elements present in a particular subtree within a filter must match associated nodes present in the server's conceptual data model. XML namespaces may be specified (via 'xmlns' declarations) within the filter data model. If they are, the declared namespace must first exactly match a namespace supported by the server. Note that prefix values for qualified namespaces are not relevant when comparing filter elements to elements in the underlying data model. Only data associated with a specified namespace will be included in the filter output.

フィルタ内の特定のサブツリー内に存在するすべての要素は、サーバの概念データモデルに存在する関連するノードと一致しなければなりません。 XML名前空間は、フィルタ・データ・モデル内（「のxmlns」宣言を介して）指定することができます。その場合、宣言された名前空間は、最初に正確に、サーバーでサポートされている名前空間と一致する必要があります。基礎となるデータモデル内の要素にフィルタエレメントを比較するときに資格の名前空間の接頭辞値は関連していないことに注意してください。指定された名前空間に関連付けられているデータのみがフィルタ出力に含まれます。

Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified configuration datastore on the server are selected by the filter. A node must exactly match the namespace and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below <filter>.

サブツリーフィルタで指定された各ノードは、包含フィルタを表します。サーバー上の指定された構成データストア内の基礎となるデータ・モデル（複数可）にのみ関連するノードは、フィルタによって選択されます。ノードは、正確にフィルタの絶対パス名が<フィルター>下の層から開始するように調整されることを除いて、フィルタデータに与えられた要素の名前空間と階層と一致しなければなりません。

Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data.

応答メッセージは、フィルタによって選択された唯一のサブツリーが含まれています。要求に存在していた任意の選択基準は、特定の選択されたサブツリー内で、また、応答に含まれています。リーフノードとしてフィルタで発現いくつかの要素が展開されることに注意フィルタの出力に（すなわち、部分木を含みます）。特定のデータ・インスタンスは、要求が同じデータを選択する複数のフィルタサブツリーの表現が含まれている場合には対応して複製されません。

6.2. Subtree Filter Components

6.2. サブツリーフィルタ部品

A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter:

サブツリーフィルタは、XML要素とそのXML属性で構成されています。サブツリーフィルター中に存在することができるコンポーネントの5種類があります。

o Namespace Selection

名前空間の選択O

o Attribute Match Expressions

A leaf node that contains simple content is called a "content match node". It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content. The following constraints apply to content match nodes:

シンプルなコンテンツが含まれているリーフノードは、「コンテンツマッチノード」と呼ばれています。フィルタ出力のためにその兄弟ノードの一部またはすべてを選択するために使用され、それが葉ノード要素の内容に完全一致フィルタを表しています。次の制約はコンテンツマッチノードに適用されます。

o A content match node must not contain nested elements (i.e., must resolve to a simpleType in the XML Schema Definition (XSD)).

Oコンテンツマッチノードは、ネストされた要素を含む（すなわち、XMLスキーマ定義（XSD）で単純に解決しなければならない）はなりません。

o Multiple content match nodes (i.e., sibling nodes) are logically combined in an "AND" expression.

O複数のコンテンツマッチノード（即ち、兄弟ノード）が論理的に「AND」式に結合されます。

o Filtering of mixed content is not supported.

O混合コンテンツのフィルタリングがサポートされていません。

o Filtering of list content is not supported.

Oリストのコンテンツのフィルタリングはサポートされていません。

o Filtering of whitespace-only content is not supported.

O空白のみのコンテンツのフィルタリングはサポートされていません。

o A content match node must contain non-whitespace characters. An empty element (e.g., <foo></foo>) will be interpreted as a selection node (e.g., <foo/>).

Oコンテンツマッチノードは非空白文字が含まれている必要があります。空要素（例えば、<FOO> </ FOO>）は、選択ノード（例えば、<FOO />）として解釈されます。

o Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified.

空白文字を先頭と末尾のoを無視されますが、テキスト文字のブロック内の任意の空白文字は無視されたり変更されません。

If all specified sibling content match nodes in a subtree filter expression are 'true', then the filter output nodes are selected in the following manner:

サブツリーフィルタ式で指定されたすべての兄弟コンテンツマッチノードが「真」である場合、フィルタ出力ノードは、次のように選択されます。

o Each content match node in the sibling set is included in the filter output.

O兄弟セットにおける各コンテンツマッチノードは、フィルタ出力に含まれています。

o If any containment nodes are present in the sibling set, then they are processed further and included if any nested filter criteria are also met.

O任意封じ込めノードが兄弟セットに存在する場合、それらは、さらに処理され、ネストされたフィルタ基準も満たされた場合に含まれます。

o If any selection nodes are present in the sibling set, then all of them are included in the filter output.

任意選択ノードが兄弟セットに存在する場合、O、次いで、それらのすべては、フィルタ出力に含まれています。

o Otherwise (i.e., there are no selection or containment nodes in the filter sibling set), all the nodes defined at this level in the underlying data model (and their subtrees, if any) are returned in the filter output.

Oそうでない場合には（もしあれば、そのサブツリー）基礎となるデータ・モデルでは、このレベルで定義されたすべてのノード（すなわち、フィルタ兄弟セットには選択または封じ込めノードが存在しない）、フィルタ出力に返されます。

If any of the sibling content match node tests are 'false', then no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match node(s).

兄弟コンテンツマッチノードテストのいずれかが「偽」である場合、さらなるフィルタ処理が、その兄弟セットに対して実行されず、兄弟サブツリーのいずれも、コンテンツマッチノード（単数または複数）を含む、フィルタによって選択されていません。

Example:

例：

<フィルタタイプ= "サブツリー"> <トップのxmlns = "http://example.com/schema/1.2/config"> <ユーザー> <ユーザー> <名前>フレッド</名前> </ユーザー> </ユーザー> </トップ> </フィルタ>

In this example, the <users> and <user> nodes are both containment nodes, and <name> is a content match node. Since no sibling nodes of <name> are specified (and therefore no containment or selection nodes), all of the sibling nodes of <name> are returned in the filter output. Only 'user' nodes in the 'http://example.com/schema/1.2/config' namespace that match the element hierarchy and for which the <name> element is equal to 'fred' will be included in the filter output.

この例では、<ユーザ>および<ユーザー>ノードは、両方の封じ込めノードであり、<名前>は、コンテンツマッチノードです。 <名前>のない兄弟ノードが指定されていない（したがってない封じ込めまたは選択ノード）されているので、<名前>の兄弟ノードの全ては、フィルタ出力に返されます。「http://example.com/schema/1.2/config」の「ユーザ」ノードのみエレメントの階層を一致させているため、<name>要素が「フレッド」と等しい名前空間は、フィルタ出力に含まれます。

6.3. Subtree Filter Processing

6.3. サブツリーフィルタ処理

The filter output (the set of selected nodes) is initially empty.

フィルタ出力（選択されたノードのセット）は、最初は空です。

Each subtree filter can contain one or more data model fragments, which represent portions of the data model that should be selected (with all child nodes) in the filter output.

各サブツリーフィルタは、フィルタの出力に（すべての子ノードで）選択されるべきデータ・モデルの部分を表す1つのまたは複数のデータモデルフラグメントを含むことができます。

Each subtree data fragment is compared by the server to the internal data models supported by the server. If the entire subtree data-fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data.

各サブツリーのデータフラグメントは、サーバによってサポートされる内部データモデルにサーバによって比較されます。（フィルタで指定された最も内側の要素へ、ルートから開始）サブツリー全体のデータフラグメントフィルタが正確にサポートされるデータモデルの対応する部分と一致する場合、そのノードとそのすべての子が結果データに含まれています。

The server processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root elements in the filter are considered in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent.

サーバは、ルートからリーフノードに開始、共に同じ親ノード（兄弟セット）を持つすべてのノードを処理します。フィルタのルート要素は、それらが共通の親を持っていないにもかかわらず、（それらが同じ名前空間にあると仮定すると）同じ兄弟セットで考慮されています。

For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed.

各兄弟セットのために、サーバは、フィルタ出力に含まれる（又は潜在的に含む）されたノードを判定し、その兄弟サブツリーをフィルタ出力から（剪定）除外されます。サーバは、最初のノードのタイプが兄弟セット中に存在し、それらのタイプの規則に従ってノードを処理するかを決定します。兄弟セット内の任意のノードが選択されている場合、プロセスは再帰的に選択された各ノードの兄弟セットに適用されます。フィルタで指定されたすべてのサブツリー内のすべての兄弟のセットが処理されるまでアルゴリズムが続きます。

6.4. Subtree Filtering Examples

6.4. サブツリーフィルタリングの例

6.4.1. No Filter

6.4.1. フィルター設定なし

Leaving out the filter on the get operation returns the entire data model.

get操作でフィルタを省略すると、全データモデルを返します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET /> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data>  </data> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <データ> < - データの...セット全体が返さ... - ！ - > </データ> </ RPC-返信>

6.4.2. Empty Filter

6.4.2. 空フィルタ

An empty filter will select nothing because no content match or selection nodes are present. This is not an error. The filter type attribute used in these examples is discussed further in Section 7.1.

何のコンテンツ一致または選択ノードが存在しないので、空のフィルタは何も選択しません。これはエラーではありません。これらの例で使用されるフィルタのタイプ属性は、7.1節で詳しく説明されています。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET> <フィルタタイプ= "サブツリー"> </フィルタ> </ GET> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> </data> </rpc-reply>

<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> </データ> </ RPC返信>

6.4.3. Select the Entire <users> Subtree

6.4.3. 全体<ユーザー>サブツリーを選択

The filter in this example contains one selection node (<users>), so just that subtree is selected by the filter. This example represents the fully-populated <users> data model in most of the filter examples that follow. In a real data model, the <company-info> would not likely be returned with the list of users for a particular host or network.

この例では、フィルタは、これだけそのサブツリーをフィルタによって選択された一つの選択ノード（<ユーザー>）を含んでいます。この例では、以下のフィルタの例のほとんどにおいて完全移入<ユーザー>データモデルを表します。実際のデータモデルでは、<会社情報>おそらく特定のホストまたはネットワークのユーザーのリストを返すことはないでしょう。

NOTE: The filtering and configuration examples used in this document appear in the namespace "http://example.com/schema/1.2/config". The root element of this namespace is <top>. The <top> element and its descendents represent an example configuration data model only.

注：この文書で使用されているフィルタリングとコンフィギュレーションの例では、名前空間「http://example.com/schema/1.2/config」に表示されます。この名前空間のルート要素は<トップ>です。 <TOP>要素とその子孫は一例の構成データ・モデルを表します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー ">

<トップのxmlns = "http://example.com/schema/1.2/config"> <ユーザー/> </トップ> </フィルタ> </取得-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> <user> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> <company-info> <dept>2</dept> <id>3</id> </company-info> </user> </users> </top> </data> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/schema/1.2 / configの "> <ユーザー> <ユーザー> <名前>ルート</名前> <タイプ>スーパー</タイプ> <フルネーム>チャーリー・ルート</フルネーム> <会社情報> <DEPT> 1 </ DEPT> <ID> 1 </ ID> </会社情報> </ユーザー> <ユーザー> <名前>フレッド</名前> <タイプ>管理者</入力> <フルネーム>フレッド・フリントストーン</フル名前> <会社情報> <DEPT> 2 </ DEPT> <ID> 2 </ ID> </会社情報> </ユーザー> <ユーザー> <名前>バーニー</名前> <タイプ>管理者</タイプ> <フルネーム>バーニー瓦礫</フルネーム> <会社情報> <DEPT> 2 </ DEPT> <ID> 3 </ ID> </会社情報> </ユーザー> </ユーザー> </トップ> </データ> </ RPC-返信>

The following filter request would have produced the same result, but only because the container <users> defines one child element (<user>).

次のフィルタ要求が同じ結果を生じたであろうが、唯一のコンテナ<ユーザー>ための子要素（<ユーザー>）を定義します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/schema/1.2/config "> <ユーザー> <ユーザー/> </ユーザー> </トップ> </フィルタ> </取得-config>の</ RPC>

6.4.4. Select All <name> Elements within the <users> Subtree

6.4.4. すべての<名前> <ユーザー>内の要素サブツリーを選択

This filter contains two containment nodes (<users>, <user>) and one selector node (<name>). All instances of the <name> element in the same sibling set are selected in the filter output. The manager may need to know that <name> is used as an instance identifier in this particular data structure, but the server does not need to know that meta-data in order to process the request.

このフィルタは、2つの収容ノード（<ユーザー>、<ユーザ>）と1つのセレクタノードを含む（<名前>）。同じ兄弟セットで、<name>要素のすべてのインスタンスは、フィルタの出力に選択されています。マネージャは、<名前>は、この特定のデータ構造にインスタンス識別子として使用されていることを知っておく必要があるかもしれないが、サーバーは、要求を処理するためにそのメタデータを知る必要はありません。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/schema/1.2/config "> <ユーザー> <ユーザー> <名/> </ユーザー> </ユーザー> </トップ> </フィルタ> < /取得-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/schema/1.2 / configの "> <ユーザー>

<user> <name>root</name> </user> <user> <name>fred</name> </user> <user> <name>barney</name> </user> </users> </top> </data> </rpc-reply>

<ユーザー> <名前>ルート</名前> </ユーザー> <ユーザー> <名前>フレッド</名前> </ユーザー> <ユーザー> <名前>バーニー</名前> </ユーザー> </ユーザー> < /トップ> </データ> </ RPC-返信>

6.4.5. One Specific <user> Entry

6.4.5. ある特定の<ユーザー>エントリ

This filter contains two containment nodes (<users>, <user>) and one content match node (<name>). All instances of the sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output.

このフィルタは、2つの収容ノード（<ユーザー>、<ユーザ>）と、1つのコンテンツ・マッチ・ノードが含まれている（<名前>）。兄弟のすべてのインスタンスは、<名前>の値が「フレッド」はフィルタ出力で選択されている等しいため、<名前>を含むセット。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/schema/1.2/config "> <ユーザー> <ユーザー> <名前>フレッド</名前> </ユーザー> </ユーザー> </トップ> < /フィルタ> </取得-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/schema/1.2 / configの "> <ユーザー> <ユーザー> <名前>フレッド</名前> <タイプ>管理者</入力> <フルネーム>フレッド・フリントストーン</フルネーム>

<company-info> <dept>2</dept> <id>2</id> </company-info> </user> </users> </top> </data> </rpc-reply>

<会社情報> <DEPT> 2 </ DEPT> <ID> 2 </ ID> </会社情報> </ユーザー> </ユーザー> </トップ> </データ> </ RPC-返信>

6.4.6. Specific Elements from a Specific <user> Entry

6.4.6. 特定の<ユーザー>エントリから特定の要素

This filter contains two containment nodes (<users>, <user>), one content match node (<name>), and two selector nodes (<type>, <full-name>). All instances of the <type> and <full-name> elements in the same sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output. The <company-info> element is not included because the sibling set contains selection nodes.

このフィルタは、二つの収容ノードを含む（<ユーザー>、<ユーザ>）、一つのコンテンツ・マッチ・ノード（<名前>）、および2つのセレクタノード（<タイプ>、<フル名前>）。 <タイプ>とのすべてのインスタンスは、<フル名前> <名前>の値が「フレッド」に等しいため、<名前>を含む同じ兄弟セット内の要素は、フィルタ出力に選択されます。兄弟セットが選択ノードが含まれているため、<会社-info>要素が含まれていません。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/schema/1.2/config "> <ユーザー> <ユーザー> <名前>フレッド</名前> <タイプ/> <フルネーム/> </ユーザー> </ユーザー> </トップ> </フィルタ> </取得-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>fred</name> <type>admin</type>

<full-name>Fred Flintstone</full-name> </user> </users> </top> </data> </rpc-reply>

<フルネーム>フレッド・フリントストーン</フルネーム> </ユーザー> </ユーザー> </トップ> </データ> </ RPC-返信>

6.4.7. Multiple Subtrees

6.4.7. 複数のサブツリー

This filter contains three subtrees (name=root, fred, barney).

このフィルタは、3つのサブツリー（名前=ルート、フレッド、バーニー）が含まれています。

The "root" subtree filter contains two containment nodes (<users>, <user>), one content match node (<name>), and one selector node (<company-info>). The subtree selection criteria is met, and just the company-info subtree for "root" is selected in the filter output.

「ルート」サブツリーフィルタは、二つの収容ノードを含む（<ユーザー>、<ユーザ>）、一つのコンテンツ・マッチ・ノード（<名前>）、および1つのセレクタノード（<会社情報>）。サブツリーの選択基準が満たされ、そして「根」のためだけの会社情報サブツリーは、フィルタ出力に選択されています。

The "fred" subtree filter contains three containment nodes (<users>, <user>, <company-info>), one content match node (<name>), and one selector node (<id>). The subtree selection criteria is met, and just the <id> element within the company-info subtree for "fred" is selected in the filter output.

「フレッド」サブツリーフィルタ三の収容ノード（<ユーザー>、<ユーザ>、<会社情報>）、一つのコンテンツ・マッチ・ノードが含まれている（<名前>）、および1つのセレクタノード（<ID>）。サブツリーの選択基準が満たされ、そして「フレッド」のための会社情報サブツリー内だけで、<id>の要素は、フィルタ出力に選択されています。

The "barney" subtree filter contains three containment nodes (<users>, <user>, <company-info>), two content match nodes (<name>, <type>), and one selector node (<dept>). The subtree selection criteria is not met because user "barney" is not a "superuser", and the entire subtree for "barney" (including its parent <user> entry) is excluded from the filter output.

"バーニー" サブツリーフィルタ三の収容ノード（<ユーザー>、<ユーザ>、<会社情報>）、2つのコンテンツマッチノード（<名前>、<タイプ>）、および1つのセレクターノードを含む（<DEPT>）。ユーザ「バーニー」はフィルタ出力から除外され、「スーパーユーザ」、及び（親<ユーザー>エントリを含む）「バーニー」のサブツリー全体ではないため、サブツリー選択基準が満たされていません。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <トップのxmlns =" http://example.com/schema/1.2/config "> <ユーザー> <ユーザー> <名前>ルート</名前> <会社情報/> </ユーザー> <ユーザー> <名前>フレッド</名前> <会社情報> <ID /> </会社情報> </ユーザー>

<user> <name>barney</name> <type>superuser</type> <company-info> <dept/> </company-info> </user> </users> </top> </filter> </get-config> </rpc>

<ユーザー> <名前>バーニー</名前> <タイプ>スーパー</タイプ> <会社情報> <DEPT /> </会社情報> </ユーザー> </ユーザー> </トップ> </フィルタ> </ GET-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <company-info> <id>2</id> </company-info> </user> </users> </top> </data> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/schema/1.2 / configの "> <ユーザー> <ユーザー> <名前>ルート</名前> <会社情報> <DEPT> 1 </ DEPT> <ID> 1 </ ID> </会社情報> </ユーザー> <ユーザー> <名前>フレッド</名前> <会社情報> <ID> 2 </ ID> </会社情報> </ユーザー> </ユーザー> </トップ> </データ> </ RPC-返信>

6.4.8. Elements with Attribute Naming

6.4.8. 属性のネーミングを持つ要素

In this example, the filter contains one containment node (<interfaces>), one attribute match expression (ifName), and one selector node (<interface>). All instances of the <interface> subtree that have an ifName attribute equal to "eth0" are selected in the filter output. The filter data elements and attributes must be qualified because the ifName attribute will not be considered part of the 'schema/1.2' namespace if it is unqualified.

この例では、フィルタは、一の収容ノード（<インターフェース>）、1つの属性一致式（ifNameから）、および1つのセレクタノード（<インターフェース>）を含んでいます。 ifNameを持っている<インターフェース>サブツリーは「eth0の」に等しい属性のすべてのインスタンスは、フィルタの出力に選択されています。それが修飾されていない場合のifName属性は「スキーマ/ 1.2」名前空間の一部とみなされることはありませんので、フィルタデータ要素と属性を修飾する必要があります。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET> <フィルタタイプ= "サブツリー"> <T：トップのxmlns：T = "HTTP ：//example.com/schema/1.2/stats "> <T：インターフェイス> <T：インタフェースT：のifName =" eth0" の/> </ T：インターフェイス> </ T：トップ> </フィルタ> </取得> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <t:top xmlns:t="http://example.com/schema/1.2/stats"> <t:interfaces> <t:interface t:ifName="eth0"> <t:ifInOctets>45621</t:ifInOctets> <t:ifOutOctets>774344</t:ifOutOctets> </t:interface> </t:interfaces> </t:top> </data> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <T：トップのxmlns：T = "http://example.com /schema/1.2/stats "> <T：インターフェイス> <T：インタフェースT：のifName =" eth0" の> <T：のifInOctets> 45621 </ T：のifInOctets> <T：ifOutOctets> 774344 </ T：ifOutOctets> < / T：インタフェース> </ T：インターフェイス> </ T：トップ> </データ> </ RPC返信>

If ifName were a child node instead of an attribute, then the following request would produce similar results.

ifNameは、子ノードの代わりに、属性があった場合は、次のリクエストは、同様の結果を生じるであろう。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET> <フィルタタイプ= "サブツリー"> <トップのxmlnsは= "HTTP：//例.COM /スキーマ/ 1.2 /統計 "> <インターフェース> <インターフェース> <のifName> eth0の</のifName> </インターフェイス> </インターフェイス> </ TOP> </フィルタ> </取得> </ RPC>

7. Protocol Operations

7.プロトコル操作

The NETCONF protocol provides a small set of low-level operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration datastores. Additional operations are provided, based on the capabilities advertised by the device.

NETCONFプロトコルは、デバイス構成を管理し、デバイスの状態情報を取得するために、低レベルの操作の小さなセットを提供します。基本プロトコルは、取得、設定、コピー、およびコンフィギュレーション・データストアを削除する操作を提供します。追加の操作は、デバイスによってアドバタイズ機能に基づいて、提供されています。

The base protocol includes the following protocol operations:

ベースプロトコルは、以下のプロトコルの動作を含みます。

o get

Oを取得

o get-config

O得る-config設定を

o edit-config

O編集-config設定

o copy-config

Oコピー-config設定

o delete-config

O削除-config設定を

o lock

Oロック

o unlock

Oロック解除

o close-session

Oクローズセッション

o kill-session

O殺すセッションを

A protocol operation may fail for various reasons, including "operation not supported". An initiator should not assume that any operation will always succeed. The return values in any RPC reply should be checked for error responses.

プロトコルの動作は、「サポートされていない操作」を含む様々な理由で失敗する可能性があります。イニシエータは、任意の操作が常に成功すると仮定してはいけません。任意のRPC応答での戻り値はエラー応答のためにチェックする必要があります。

The syntax and XML encoding of the protocol operations are formally defined in the XML schema in Appendix B. The following sections describe the semantics of each protocol operation.

プロトコル操作の構文とXMLエンコーディングを正式付録BにXMLスキーマで定義されている次のセクションでは、各プロトコルの動作の意味を説明しています。

7.1. <get-config>

7.1. <GET-config>の

Description:

説明：

Retrieve all or part of a specified configuration.

指定された構成の全部または一部を取得します。

Parameters:

パラメーター：

source:

ソース：

Name of the configuration datastore being queried, such as <running/>.

そのような</実行>のように、照会されるコンフィギュレーションデータストアの名前。

filter:

フィルタ：

The filter element identifies the portions of the device configuration to retrieve. If this element is unspecified, the entire configuration is returned.

フィルタ要素は、取得するために、装置構成の部分を識別する。この要素が指定されていない場合、全体の構成が返されます。

The filter element may optionally contain a "type" attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value "subtree" explicitly identifies this type of filtering.

フィルタエレメントは、必要に応じて、「タイプ」属性を含むことができます。この属性は、フィルタエレメント内で使用されるフィルター構文の種類を示します。 NETCONFのデフォルトのフィルタリング機構としてサブツリーフィルタリングと呼ばれ、値「サブツリー」は、明示的にフィルタリングのこのタイプを識別するセクション6に記載されています。

If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression.

NETCONFのピアがサポートしている場合：XPathの機能（8.9節）を、値「XPathは、」フィルタ要素のselect属性は、XPath式が含まれていることを示すために使用することができます。

Positive Response:

肯定的な反応：

If the device can satisfy the request, the server sends an <rpc-reply> element containing a <data> element with the results of the query.

デバイスが要求を満たすことができる場合、サーバは、クエリの結果と、<データ>要素を含む<RPC返信>要素を送信します。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

Example: To retrieve the entire <users> subtree:

例：全体の<ユーザー>サブツリーを取得するには：

</filter> </get-config> </rpc>

</フィルタ> </取得-config>の</ RPC>

If the configuration is available in multiple formats, such as XML and text, an XML namespace can be used to specify which format is desired. In the following example, the client uses a specific element (<config-text>) in a specific namespace to indicate to the server the desire to receive the configuration in an alternative format. The server may support any number of distinct formats or views into the configuration data, with the client using the <filter> parameter to select between them.

コンフィギュレーションは、XMLやテキストなどの複数のフォーマットで利用可能である場合は、XML名前空間が所望されるフォーマットを指定するために使用することができます。次の例では、クライアントは、サーバに別の形式で設定を受信したいという要望を示すために特定の名前空間内の特定の要素（<CONFIG-テキスト>）を使用します。サーバは、それらの間で選択するために、<フィルター>パラメータを使用してクライアントと、コンフィギュレーションデータに異なる形式またはビューの任意の数をサポートすることができます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/> </ソース> <フィルタタイプ=」サブツリー "> <！ - 要求の構成のテキスト版 - >の<config-テキストのxmlns =" http://example.com/text/1.2/config "/> </フィルタ> </取得-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0">

<データ>の<config-テキストのxmlns = "http://example.com/text/1.2/config"> <！ - コンフィギュレーション・テキスト... - > </ configのテキスト> </データ> </ RPC -reply>

Section 6 contains additional examples of subtree filtering.

第6節では、サブツリーのフィルタリングの追加の例が含まれています。

7.2. <edit-config>

7.2. <編集-config>の

Description:

説明：

The <edit-config> operation loads all or part of a specified configuration to the specified target configuration. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration does not exist, it will be created. If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear instead of the <config> parameter and should identify a local configuration file.

<編集-config>の操作は、指定したターゲット設定に指定された構成の全部または一部をロードします。この操作は、新しい設定は、ローカルファイル、リモートファイル、またはインラインを使用するなど、いくつかの方法で表現することを可能にします。ターゲットの設定が存在しない場合は、それが作成されます。 NETCONFのピアがサポートしている場合：URL能力（8.8節）を、<URL>要素ではなく、<設定>パラメータで表示されることができ、ローカル設定ファイルを特定する必要があります。

The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the <copy-config> message. Instead, the target configuration is changed in accordance with the source's data and requested operations.

デバイスは、ソースおよびターゲットの構成を分析し、要求された変更を行います。ターゲット構成は、必ずしも<コピー設定>メッセージのように、置換されていません。代わりに、ターゲットの設定は元のデータと要求された操作に応じて変更されます。

Attributes:

属性：

operation:

操作：

Elements in the <config> subtree may contain an "operation" attribute. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the <config> subtree.

<config>のサブツリー内の要素は、「操作」の属性が含まれていてもよいです。属性は、操作を実行する構成でポイントを識別し、<設定>サブツリー全体にわたって複数の要素に表示されることがあります。

If the operation attribute is not specified, the configuration is merged into the configuration datastore.

操作属性が指定されていない場合、コンフィギュレーションは、コンフィギュレーションデータストアにマージされます。

The operation attribute has one of the following values:

操作属性には、次のいずれかの値があります。

merge: The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the target parameter. This is the default behavior.

マージ：この属性を含む要素によって識別される構成データは、ターゲット・パラメータによって識別される構成データストア内の対応するレベルで設定とマージされます。これがデフォルトの動作です。

replace: The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the target parameter. Unlike a <copy-config> operation, which replaces the entire target configuration, only the configuration actually present in the config parameter is affected.

置き換え：この属性を含む要素で識別されるコンフィギュレーション・データをターゲットパラメータによって識別されるコンフィギュレーション・データストア内の任意の関連する構成を置き換えます。ターゲット全体構成を置き換える<コピー設定>動作とは異なり、設定パラメータに実際に存在する構成のみが影響を受けます。

create: The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist on the device. If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of data-exists.

作成：構成データがすでにデバイス上に存在していない場合だけ、この属性を含む要素で識別されるコンフィギュレーション・データをコンフィギュレーションに追加されます。コンフィギュレーションデータが存在する場合は、<RPCエラー>要素の<エラータグ>値が返されるデータが存在します。

delete: The configuration data identified by the element containing this attribute is deleted in the configuration datastore identified by the target parameter.

削除：この属性を含む要素で識別されるコンフィギュレーション・データは、ターゲットパラメータによって識別されるコンフィギュレーション・データストアに削除されます。

Parameters:

パラメーター：

target:

ターゲット：

Name of the configuration datastore being edited, such as <running/> or <candidate/>.

コンフィギュレーションデータストアの名前は、<実行/>または<候補/>のように、編集されています。

default-operation:

デフォルトの動作：

Selects the default operation (as described in the "operation" attribute) for this <edit-config> request. The default value for the default-operation parameter is "merge".

この<編集-config>の要求のために（「操作」属性で説明したように）デフォルトの操作を選択します。デフォルトの動作パラメータのデフォルト値は「マージ」です。

The default-operation parameter is optional, but if provided, it must have one of the following values:

デフォルトの動作パラメータは任意ですが、提供されている場合、それは次の値のいずれかが必要です。

merge: The configuration data in the <config> parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior.

マージ：<設定>パラメータ内の構成データは、ターゲットデータストア内の対応するレベルで設定とマージされます。これがデフォルトの動作です。

replace: The configuration data in the <config> parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data.

置き換える：<設定>パラメータで設定データを完全にターゲットデータストアに設定を置き換えます。これは、ロード以前に保存したコンフィギュレーション・データに便利です。

none: The target datastore is unaffected by the configuration in the <config> parameter, unless and until the incoming configuration data uses the "operation" attribute to request a different operation. If the configuration in the <config> parameter contains data for which there is not a corresponding level in the target datastore, an <rpc-error> is returned with an <error-tag> value of data-missing. Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted.

いずれ：受信設定データが異なる動作を要求するために「操作」属性を使用しなければまで、ターゲット・データストアは、<設定>パラメータで構成によって影響されません。 <設定>パラメータで設定はターゲット・データストアに対応するレベルがされていないデータが含まれている場合、<RPCエラーは>データ欠落の<エラータグ>値が返されます。「none」を使用していないと、誤って削除される要素の親階層を作成しないように「削除」のような操作を可能にします。

test-option:

テストオプション：

The test-option element may be specified only if the device advertises the :validate capability (Section 8.6).

検証機能（セクション8.6）：テストオプションエレメントは、デバイスがアドバタイズする場合にのみ指定することができます。

The test-option element has one of the following values:

テスト・オプションの要素は、次のいずれかの値があります。

test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the <edit-config> operation. This is the default test-option.

テスト、その後セット：設定しようとする前に、検証テストを実行します。検証エラーが発生した場合は、<編集-config>の操作を実行しないでください。これはデフォルトのテストオプションです。

set: Perform a set without a validation test first.

セット：最初の検証テストせずにセットを実行します。

error-option:

エラーオプション：

The error-option element has one of the following values:

エラー・オプションの要素は、次のいずれかの値があります。

stop-on-error: Abort the edit-config operation on first error. This is the default error-option.

ストップ・オン・エラー：最初のエラーで編集・設定操作を中止します。これがデフォルトのエラー・オプションです。

continue-on-error: Continue to process configuration data on error; error is recorded, and negative response is generated if any errors occur.

引き続きオンエラー：エラー時にコンフィギュレーション・データを処理し続けます。エラーが記録され、エラーが発生した場合、負の応答が生成されます。

rollback-on-error: If an error condition occurs such that an error severity <rpc-error> element is generated, the server will stop processing the edit-config operation and restore the specified configuration to its complete state at the start of this edit-config operation. This option requires the server to support the :rollback-on-error capability described in Section 8.5.

ロールバック・オン・エラー：エラー状態は、発生した場合は、そのエラーの重大度<RPC-エラー>要素が生成され、編集・設定操作の処理を停止し、この編集の開始時にその完全な状態に指定された設定を復元するサーバー-config操作。セクション8.5で説明したロールバック・オン・エラー機能：このオプションでは、サポートするためのサーバが必要です。

config:

設定：

A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. Capabilities are discussed in Section 8.

コンフィギュレーション・データの階層は、デバイスのデータ・モデルの一つで定義されています。コンテンツは、装置が適切なデータ・モデルを検出できるようにするために、適切な名前空間に配置する必要があり、その能力の定義によって定義される内容は、そのデータモデルの制約に従わなければなりません。機能はセクション8で説明されています。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element.

デバイスは、<RPC返信>の要求を満たすことができた場合、<OK>要素を含む送信されます。

Negative Response:

否定応答：

An <rpc-error> response is sent if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>応答が送信されます。

Example:

例：

The <edit-config> examples in this section utilize a simple data model, in which multiple instances of the 'interface' element may be present, and an instance is distinguished by the 'name' element within each 'interface' element.

このセクション内の<編集設定>例は、「インタフェース」要素の複数のインスタンスが存在してもよく、そしてインスタンスがそれぞれ「インタフェース」要素内に「名前」要素によって区別された単純なデータ・モデルを利用します。

Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration:

実行コンフィギュレーションの「のEthernet0 / 0」という名前のインターフェイス上で1500にMTUを設定します。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>1500</mtu> </interface> </top> </config> </edit-config> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </標的> <設定> <トップxmlns = "http://example.com/schema/1.2/config"> <インターフェース> <名前>をEthernet0 / 0 </名前> <MTU> 1500 </ MTU> </インターフェイス> </ TOP> </コンフィグ> </編集-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

Add an interface named "Ethernet0/0" to the running configuration, replacing any previous interface with that name:

その名前で以前のインターフェースを置き換え、実行コンフィギュレーションに「のEthernet0 / 0」という名前のインターフェイスを追加します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定>

<target> <running/> </target> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://example.com/schema/1.2/config"> <interface xc:operation="replace"> <name>Ethernet0/0</name> <mtu>1500</mtu> <address> <name>192.0.2.4</name> <prefix-length>24</prefix-length> </address> </interface> </top> </config> </edit-config> </rpc>

<ターゲット> <実行/> </ target>に<設定のxmlns：XC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <トップのxmlns = "http://example.com/schema/ 1.2 /設定 "> <境界xc：操作=" "> <名前>のEthernet0 / 0 </名前> <MTU> 1500 </ MTU> <アドレス> <名前> 192.0.2.4 </名前> <プレフィックス長を置き換えます> 24 </プレフィックス長> </アドレス> </インターフェイス> </ TOP> </ config>の</編集設定> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

Delete the configuration for an interface named "Ethernet0/0" from the running configuration:

実行コンフィギュレーションから「のEthernet0 / 0」という名前のインターフェイスのコンフィギュレーションを削除します。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <default-operation>none</default-operation> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://example.com/schema/1.2/config"> <interface xc:operation="delete"> <name>Ethernet0/0</name> </interface> </top> </config> </edit-config> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </ target>に<デフォルトの動作>なし</デフォルトの動作> <設定のxmlns：XC = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <トップのxmlns = "http://example.com/schema/1.2/config" > <境界xc：操作= "削除"> <名前>のEthernet0 / 0 </名前> </インターフェイス> </トップ> </ config>の</編集-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

Delete interface 192.0.2.4 from an OSPF area (other interfaces configured in the same area are unaffected):

OSPF領域（同じ領域で構成された他のインターフェイスが影響を受けない）からインターフェイス192.0.2.4を削除します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </ target>に<デフォルトの動作>なし</デフォルトの動作> <設定のxmlns：XC = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <トップのxmlns = "http://example.com/schema/1.2/config" > <プロトコル> <OSPF> <地域> <名前> 0.0.0.0 </名前> <インターフェース> <インターフェイスXC：オペレーション= "削除"> <名前> 192.0.2.4 </名前> </インターフェイス> </インターフェース> </エリア> </ OSPF> </プロトコル> </トップ> </ config>の</編集-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

7.3. <copy-config>

7.3. <コピー設定>

Description:

説明：

Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed.

別の完全な構成データストアの内容全体構成データストアを作成するか、または交換してください。ターゲットデータストアが存在する場合は、上書きされます。許可されていればそうでない場合は、新しいものが作成されます。

If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <source> or <target> parameter.

NETCONFのピアがサポートしている場合：URL能力（8.8節）を、<URL>要素は、<ソース>または<対象>パラメータとして表示されます。

Even if it advertises the :writable-running capability, a device may choose not to support the <running/> configuration datastore as the <target> parameter of a <copy-config> operation. A device may choose not to support remote-to-remote copy operations, where both the <source> and <target> parameters use the <url> element.

それはアドバタイズ場合でも：書き込み可能な走行性能を、デバイスは、<コピー-config>の操作の<対象>パラメータとして<ランニング/>コンフィギュレーションデータストアをサポートしないこともできます。デバイスは、<ソース>と<target>にパラメータの両方が<URL>要素を使用してリモートツーリモートコピー操作をサポートしないことを選んでもよいです。

If the source and target parameters identify the same URL or configuration datastore, an error MUST be returned with an error-tag containing invalid-value.

ソースとターゲットのパラメータが同じURLまたは構成データストアを識別した場合、エラーは、無効な値を含むエラータグで返さなければなりません。

Parameters:

パラメーター：

target:

ターゲット：

Name of the configuration datastore to use as the destination of the copy operation.

コピー操作の宛先として使用するために、構成データストアの名前。

source:

ソース：

Name of the configuration datastore to use as the source of the copy operation or the <config> element containing the configuration subtree to copy.

コピー操作のソースまたはコピーする構成サブツリーを含む<config>要素として使用するコンフィギュレーションデータストアの名前。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.

デバイスは、<RPC返信>の要求を満たすことができた場合、<OK>要素を含むことが送られます。

Negative Response:

否定応答：

An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>内に含まれています。

Example:

例：

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <running/> </target> <source> <url>https://user@example.com:passphrase/cfg/new.txt</url> </source> </copy-config> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コピー設定> <ターゲット> <実行/> </ターゲット> <ソース> <URL > HTTPS：//user@example.com：パスフレーズ/ CFG / new.txt </ URL> </ソース> </コピー-config>の</ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

7.4. <delete-config>

7.4. <削除-config>の

Description:

説明：

Delete a configuration datastore. The <running> configuration datastore cannot be deleted.

コンフィギュレーション・データストアを削除します。 <ランニング>コンフィギュレーション・データストアを削除することはできません。

If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <target> parameter.

NETCONFのピアがサポートしている場合：URL能力（8.8節）を、<URL>要素は、<対象>パラメータとして表示されます。

Parameters:

パラメーター：

target:

ターゲット：

Name of the configuration datastore to delete.

削除するコンフィギュレーションデータストアの名前。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.

デバイスは、<RPC返信>の要求を満たすことができた場合、<OK>要素を含むことが送られます。

Negative Response:

否定応答：

An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>内に含まれています。

Example:

例：

<RPCメッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <削除-config>の<対象> <起動/> </ target>に</削除、コンフィグ> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

7.5. <lock>

7.5. <ロック>

Description:

説明：

The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users.

ロック操作は、クライアントがデバイスのコンフィギュレーション・システムをロックすることができます。このようなロックは短命であることと、クライアントが他のNETCONFクライアント、非NETCONFクライアント（例えば、SNMP、およびコマンドラインインターフェイス（CLI）スクリプト）、そして人間のユーザとの相互作用を恐れることなく変更を行うことができるようにすることを意図しています。

An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target.

既存のセッションまたは他のエンティティは、ロック対象の任意の部分のロックを保持している場合は、設定をロックしようとする試みは失敗しなければなりません。

When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error.

ロックが取得されると、サーバは、このセッションによって要求されたもの以外のロックされたリソースへの変更を防止しなければなりません。リソースを変更するには、SNMPとCLIの要求は、適切なエラーで失敗しなければなりません。

The duration of the lock is defined as beginning when the lock is acquired and lasting until either the lock is released or the NETCONF session closes. The session closure may be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, or simple inactivity timeout. This criteria is dependent on the implementation and the underlying transport.

ロックのいずれかが解放されるか、NETCONFセッションが終了するまでロックを取得し、持続されたときにロックの継続時間は、初めのように定義されます。セッションの閉鎖は、明示的にクライアントによって実行される、または暗黙的な基礎となる交通機関の故障、または単純な無活動タイムアウトなどの基準に基づいて、サーバで実行することができます。この基準は、実装と基本的な輸送に依存しています。

The lock operation takes a mandatory parameter, target. The target parameter names the configuration that will be locked. When a lock is active, using the <edit-config> operation on the locked configuration and using the locked configuration as a target of the <copy-config> operation will be disallowed by any other NETCONF session. Additionally, the system will ensure that these locked configuration resources will not be modified by other non-NETCONF management operations such as SNMP and CLI. The <kill-session> message (at the RPC layer) can be used to force the release of a lock owned by another NETCONF session. It is beyond the scope of this document to define how to break locks held by other entities.

ロック操作は必須のパラメータ、ターゲットを取ります。ターゲットパラメータ名ロックされます設定。ロックがロックされた構成の<編集設定>操作を使用し、<コピー設定>のターゲットとしてロック構成を使用して、アクティブになっているときの動作は、他のNETCONFセッションによって許可されるであろう。また、システムは、これらのロックされた構成リソースは、SNMPやCLIなどの他の非NETCONF管理操作によって改変されないことを保証します。（RPC層で）<殺すセッション>メッセージは、別のNETCONFセッションが所有するロックの解放を強制するために使用することができます。これは、他のエンティティが保持しているロックを解除する方法を定義するには、この文書の範囲外です。

A lock MUST not be granted if either of the following conditions is true:

次の条件のいずれかに該当する場合にロックが付与されなければなりません。

* A lock is already held by any NETCONF session or another entity.

*ロックがすでに任意のNETCONFセッションまたは別のエンティティによって保持されています。

* The target configuration is <candidate>, it has already been modified, and these changes have not been committed or rolled back.

*ターゲットの設定は、<候補>で、それはすでに修正されており、これらの変更は、コミットまたはロールバックされていません。

The server MUST respond with either an <ok> element or an <rpc-error>.

サーバーは、<OK>要素や<RPC-エラー>のいずれかで応じなければなりません。

A lock will be released by the system if the session holding the lock is terminated for any reason.

ロックを保持しているセッションが何らかの理由で終了した場合、ロックは、システムによって解放されます。

Parameters:

パラメーター：

target:

ターゲット：

Name of the configuration datastore to lock.

ロックするコンフィギュレーションデータストアの名前。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.

デバイスは、<RPC-応答を>要求を満たすことができた場合は、<OK>要素が含まれて送信されます。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

If the lock is already held, the <error-tag> element will be 'lock-denied' and the <error-info> element will include the <session-id> of the lock owner. If the lock is held by a non-NETCONF entity, a <session-id> of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target.

ロックがすでに保持されている場合は、<エラータグ>要素には、「ロック・拒否」され、<エラー-info>要素には、ロック所有者の<セッション-id>を含めます。ロックが0（ゼロ）の非NETCONFエンティティの<session-id>で保持されている場合が含まれます。ターゲットの偶数部分ピースのロックを行う他の任意のエンティティがそのターゲットに得られるから（グローバルである）NETCONFロックを防止することに留意されたいです。

Example:

例：

The following example shows a successful acquisition of a lock.

次の例では、ロックの取得に成功を示しています。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック> <ターゲット> <実行/> </ target>に</ロック> </ RPC >

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/>  </rpc-reply>

<RPC-返信メッセージID = "101" のxmlns = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <OK /> <！ - ロックが成功した - > </ RPC-返信>

Example:

例：

The following example shows a failed attempt to acquire a lock when the lock is already in use.

次の例では、ロックが既に使用されているときにロックの取得に失敗したを示しています。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック> <ターゲット> <実行/> </ target>に</ロック> </ RPC >

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error>  <error-type>protocol</error-type> <error-tag>lock-denied</error-tag> <error-severity>error</error-severity> <error-message> Lock failed, lock is already held </error-message> <error-info> <session-id>454</session-id>  </error-info> </rpc-error> </rpc-reply>

<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <RPCエラー> <！ - ロックに失敗しました - > <エラータイプ>プロトコル</エラータイプ> <エラータグ>ロック拒否</エラータグ> <エラーの重大度>誤り</エラーの重大度> <エラーメッセージ>ロックに失敗し、ロックが既に保持されている</エラーメッセージ> <エラー情報> <セッションID> 454 </セッションID> <！ - ロックはNETCONFセッションによって保持されている454 - > </エラー・インフォメーション> </ RPC-エラー> </ RPC-返信>

7.6. <unlock>

7.6. <ロック解除>

Description:

説明：

The unlock operation is used to release a configuration lock, previously obtained with the <lock> operation.

ロック解除操作は、以前<ロック>操作で得られた、設定ロックを解除するために使用されます。

An unlock operation will not succeed if any of the following conditions are true:

以下の条件のいずれかに該当する場合、ロック解除操作は成功しません。

* the specified lock is not currently active

*指定されたロックは、現在アクティブではありません

* the session issuing the <unlock> operation is not the same session that obtained the lock

*セッション発行操作がロックを取得した同じセッションではない<ロック解除>

The server MUST respond with either an <ok> element or an <rpc-error>.

サーバーは、<OK>要素や<RPC-エラー>のいずれかで応じなければなりません。

Parameters:

パラメーター：

target:

ターゲット：

Name of the configuration datastore to unlock.

ロックを解除するには、構成データストアの名前。

A NETCONF client is not permitted to unlock a configuration datastore that it did not lock.

NETCONFクライアントは、それがロックしていなかったコンフィギュレーションデータストアのロックを解除することが許可されていません。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.

デバイスは、<RPC-応答を>要求を満たすことができた場合は、<OK>要素が含まれて送信されます。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック解除> <ターゲット> <実行/> </ target>に</アンロック> </ RPC >

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

7.7. <get>

7.7. <GET>

Description:

説明：

Retrieve running configuration and device state information.

コンフィギュレーションおよびデバイスの状態情報を実行している取得します。

Parameters:

パラメーター：

filter:

フィルタ：

This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned.

このパラメータは、システム構成や状態データの一部を取得するために指定します。このパラメータが空の場合、すべてのデバイスの設定と状態の情報が返されます。

The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value 'subtree' explicitly identifies this type of filtering.

フィルタエレメントは、必要に応じて「タイプ」属性を含むことができます。この属性は、フィルタエレメント内で使用されるフィルター構文の種類を示します。 NETCONFのデフォルトのフィルタリング機構としてサブツリーフィルタリングと呼ばれ、明示的にフィルタリングのこのタイプを識別する値「サブツリー」のセクション6に記載されています。

If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute of the filter element contains an XPath expression.

NETCONFピアがサポートしている場合：XPathの能力（セクション8.9）を、値「XPathは、」フィルタ要素のselect属性は、XPath式を含むことを示すために使用されてもよいです。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent. The <data> section contains the appropriate subset.

デバイスは、<RPC返信>の要求を満たすことができた場合に送信されます。 <データ>セクションでは、適切なサブセットを含みます。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

Example:

例：

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/stats"> <interfaces> <interface> <ifName>eth0</ifName> <ifInOctets>45621</ifInOctets> <ifOutOctets>774344</ifOutOctets> </interface> </interfaces> </top> </data> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <データ> <トップのxmlns = "http://example.com/schema/1.2 /統計 "> <インターフェース> <インターフェース> <のifName> eth0の</のifName> <のifInOctets> 45621 </のifInOctets> <ifOutOctets> 774344 </ ifOutOctets> </インターフェイス> </インターフェイス> </ TOP> </データ> </ RPC-返信>

7.8. <close-session>

7.8. <クローズセッション>

Description:

説明：

Request graceful termination of a NETCONF session.

NETCONFセッションの優雅な終了を要求。

When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a <close-session> request will be ignored.

NETCONFサーバは<クローズセッション>要求を受信すると、それは優雅にセッションが終了します。サーバーは、セッションに関連付けられたすべてのロックやリソースを解放し、優雅に関連するすべての接続を閉じます。 <クローズセッション>の後に受信したすべてのNETCONF要求は要求は無視されます。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.

デバイスは、<RPC返信>の要求を満たすことができた場合、<OK>要素を含むことが送られます。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <クローズセッション/> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

7.9. <kill-session>

7.9. <キルセッション>

Description:

説明：

Force the termination of a NETCONF session.

NETCONFセッションの終了を強制します。

When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections.

NETCONFエンティティが開いているセッションのために<殺すセッション>要求を受信すると、それは、現在のプロセスですべての操作を中止したセッションに関連付けられたすべてのロックやリソースを解放し、関連するすべての接続を閉じます。

If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it must restore the configuration to its state before the confirmed commit was issued.

コミット確認（8.4節）を処理しながら、NETCONFサーバは<殺すセッション>要求を受信した場合に発行されたコミットを確認する前に、それはその状態に設定を復元する必要があります。

Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock.

そうでなければ、<殺すセッション>動作設定またはロックを保持しているエンティティによって作ら他の装置の状態の変更をロールバックしません。

Parameters:

パラメーター：

session-id:

セッションID：

Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an 'invalid-value' error is returned.

NETCONFセッションのセッション識別子は終了します。この値は、現在のセッションIDと等しい場合、「不正な値」というエラーが返されます。

Positive Response:

肯定的な反応：

If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.

デバイスは、<RPC返信>の要求を満たすことができた場合、<OK>要素を含むことが送られます。

Negative Response:

否定応答：

An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.

要求が何らかの理由で完了できない場合は、<RPCエラー>要素は、<RPC-返信>に含まれています。

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <殺すセッション> <セッションID> 4 </セッションID> </ kill-セッション> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

8. Capabilities

8.機能

This section defines a set of capabilities that a client or a server MAY implement. Each peer advertises its capabilities by sending them during an initial capabilities exchange. Each peer needs to understand only those capabilities that it might use and MUST ignore any capability received from the other peer that it does not require or does not understand.

このセクションでは、クライアントまたはサーバが実装してもよい（MAY）機能のセットを定義します。各ピアは、最初の機能交換の際にそれらを送信することにより、その機能をアドバタイズします。各ピアは、それが使用する可能性がありますのみこれらの機能を理解することが必要であり、それは必要としないか、理解していない他のピアから受信したすべての機能を無視しなければなりません。

Additional capabilities can be defined using the template in Appendix C. Future capability definitions may be published as standards by standards bodies or published as proprietary extensions.

追加機能は、標準化団体によって標準規格として公開または独自の拡張機能として公開することができる付録C.将来性の定義にテンプレートを使用して定義することができます。

A NETCONF capability is identified with a URI. The base capabilities are defined using URNs following the method described in RFC 3553 [6]. Capabilities defined in this document have the following format:

NETCONFの機能は、URIで識別されます。ベース機能はRFC 3553に記載された方法以下のURNを使用して定義されている[6]。この文書で定義された機能は、次の形式を持っています。

urn:ietf:params:netconf:capability:{name}:1.0

URN：IETF：paramsは：NETCONF：能力：{名前}：1.0

where {name} is the name of the capability. Capabilities are often referenced in discussions and email using the shorthand :{name}. For example, the foo capability would have the formal name "urn:ietf:params:netconf:capability:foo:1.0" and be called ":foo". The shorthand form MUST NOT be used inside the protocol.

ここで、{名前}は機能の名前です。 {名}：機能は、多くの場合、速記を使用して議論し、電子メールで参照されています。呼ばれる "：foo" というたとえば、fooという機能が正式名称 "：IETF：のparams：NETCONF：機能：：FOO 1.0壷" を持っているでしょう。速記形式は、プロトコル内部で使用してはいけません。

8.1. Capabilities Exchange

8.1. 機能交換

Capabilities are advertised in messages sent by each peer during session establishment. When the NETCONF session is opened, each peer (both client and server) MUST send a <hello> element containing a list of that peer's capabilities. Each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.0".

機能は、セッション確立時に各ピアによって送信されたメッセージでアドバタイズされています。 NETCONFセッションが開かれると、各ピア（クライアントとサーバーの両方）は、そのピアの機能のリストを含む<こんにちは>要素を送らなければなりません。各ピアは、少なくともベースNETCONF機能を送らなければなりません、 "URN：IETF：のparams：NETCONF：ベース：1.0"。

A server sending the <hello> element MUST include a <session-id> element containing the session ID for this NETCONF session. A client sending the <hello> element MUST NOT include a <session-id> element.

<こんにちは>要素を送信するサーバは、このNETCONFセッションのセッションIDを含む<セッションID>要素を含まなければなりません。送信クライアントは、<こんにちは>要素は、<セッションID>要素を含んではいけません。

A server receiving a <session-id> element MUST NOT continue the NETCONF session. Similarly, a client that does not receive a <session-id> element in the server's <hello> message MUST NOT continue the NETCONF session. In both cases, the underlying transport should be closed.

<セッションID>要素を受信するサーバは、NETCONFセッションを継続してはなりません。同様に、サーバーの中の<session-id>の要素を受信していないクライアントは、<こんにちは>メッセージは、NETCONFセッションを継続してはなりません。どちらの場合も、根本的な輸送が閉鎖されるべきです。

In the following example, a server advertises the base NETCONF capability, one NETCONF capability defined in the base NETCONF document, and one implementation-specific capability.

次の例では、サーバは、ベースNETCONF能力、ベースNETCONF文書で定義されNETCONF能力、および一実装固有の能力をアドバタイズ。

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> <capability> urn:ietf:params:netconf:capability:startup:1.0 </capability> <capability> http://example.net/router/2.3/myfeature </capability> </capabilities> <session-id>4</session-id> </hello>

<ハローのxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <機能> <機能> URN：IETF：paramsは：NETCONF：塩基：1.0 </機能> <機能> URN：IETF： params：NETCONF：機能：スタートアップ：1.0 </機能> <機能> http://example.net/router/2.3/myfeature </機能> </機能> <セッションID> 4 </セッションID> < /こんにちは>

Each peer sends its <hello> element simultaneously as soon as the connection is open. A peer MUST NOT wait to receive the capability set from the other side before sending its own set.

各ピアは、すぐに接続が開かれているとして同時にその<こんにちは>要素を送信します。ピアは、独自のセットを送信する前に、他の側からの設定機能を受け取るために待ってはなりません。

8.2. Writable-Running Capability

8.2. 書き込み可能・ランニング能力

8.2.1. Description

8.2.1. 説明

The :writable-running capability indicates that the device supports direct writes to the <running> configuration datastore. In other words, the device supports edit-config and copy-config operations where the <running> configuration is the target.

：書き込み可能な走行性能は、デバイスが<ランニング>コンフィギュレーションデータストアへの直接書き込みをサポートしていることを示しています。言い換えれば、デバイスは、<ランニング>コンフィギュレーションがターゲットである編集-configおよびコピー設定操作をサポートしています。

8.2.2. Dependencies

8.2.2. 依存関係

None.

無し。

8.2.3. Capability Identifier

8.2.3. 機能識別子

The :writable-running capability is identified by the following capability string:

：書き込み可能なラン機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:writable-running:1.0

URN：IETF：のparams：NETCONF：機能：書き込み可能なランニング：1.0

8.2.4. New Operations

8.2.4. 新事業

None.

無し。

8.2.5. Modifications to Existing Operations

8.2.5. 既存事業への変更

8.2.5.1. <edit-config>

8.2.5.1。 <編集-config>の

The :writable-running capability modifies the <edit-config> operation to accept the <running> element as a <target>.

：書き込み可能な走行性能は、<対象>として<ランニング>要素を受け入れるために、<編集-config>の操作を変更します。

8.2.5.2. <copy-config>

8.2.5.2。 <コピー設定>

The :writable-running capability modifies the <copy-config> operation to accept the <running> element as a <target>.

：書き込み可能な走行性能は、<対象>として<ランニング>要素を受け入れるために、<コピー-config>の操作を変更します。

8.3. Candidate Configuration Capability

8.3. 候補の設定機能

8.3.1. Description

8.3.1. 説明

The candidate configuration capability, :candidate, indicates that the device supports a candidate configuration datastore, which is used to hold configuration data that can be manipulated without impacting the device's current configuration. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes may be made to this data to construct the desired configuration data. A <commit> operation may be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration.

候補設定機能、：候補者、デバイスはデバイスの現在の構成に影響を与えずに操作することができ、構成データを保持するために使用された候補の構成データストアを、サポートしていることを示しています。候補コンフィギュレーションはコンフィギュレーションデータを作成し、操作するための作業場所として機能する完全なコンフィギュレーション・データ・セットです。追加、削除、および変更は、所望の構成データを構築するためにこのデータを参照することができます。 <コミット>操作は、デバイスの実行コンフィギュレーションは、候補設定の値に設定されるようにする任意の時点で行うことができます。

The <commit> operation effectively sets the running configuration to the current contents of the candidate configuration. While it could be modeled as a simple copy, it is done as a distinct operation for a number of reasons. In keeping high-level concepts as first class operations, we allow developers to see more clearly both what the client is requesting and what the server must perform. This keeps the intentions more obvious, the special cases less complex, and the interactions between operations more straightforward. For example, the :confirmed-commit capability (Section 8.4) would make no sense as a "copy confirmed" operation.

<コミット>操作を効果的に、候補構成の現在の内容に実行コンフィギュレーションを設定します。それは単純なコピーとしてモデル化することができますが、それは多くの理由のために個別の操作として行われます。最初のクラスの操作のような高レベルの概念を維持するには、我々は、開発者は、両方のサーバーが実行しなければならないものをクライアントが要求していると、何よりはっきりと見ることができます。これは、より多くの明白な意図、あまり複雑で特殊なケース、そしてより簡単な操作の間の相互作用を保持します。たとえば、：操作を「コピーが確認さ」であることが確認されコミット機能（8.4節）は意味をなさないでしょう。

The candidate configuration may be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it must assume that other sessions may be able to modify the candidate configuration at the same time. It is therefore prudent for a client to lock the candidate configuration before modifying it.

候補コンフィギュレーションは、複数のセッション間で共有することができます。クライアントは、候補設定が共有されていないことを具体的な情報を持っていない限り、それは他のセッションが同時に候補の設定を変更することがあり得ることを前提としなければなりません。クライアントがそれを変更する前に、候補の設定をロックすることがゆえ賢明です。

The client can discard any uncommitted changes to the candidate configuration by executing the <discard-changes> operation. This operation reverts the contents of the candidate configuration to the contents of the running configuration.

クライアントは、<廃棄変更>操作を実行することにより、候補構成にコミットされていない変更を廃棄することができます。この操作は実行コンフィギュレーションの内容を候補コンフィギュレーションの内容を元に戻します。

8.3.2. Dependencies

8.3.2. 依存関係

None.

無し。

8.3.3. Capability Identifier

8.3.3. 機能識別子

The :candidate capability is identified by the following capability string:

：候補機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:candidate:1.0

URN：IETF：のparams：NETCONF：機能：候補：1.0

8.3.4. New Operations

8.3.4. 新事業

8.3.4.1. <commit>

8.3.4.1。 <コミット>

Description:

説明：

         When a candidate configuration's content is complete, the
         configuration data can be committed, publishing the data set to
         the rest of the device and requesting the device to conform to
         the behavior described in the new configuration.

To commit the candidate configuration as the device's new current configuration, use the <commit> operation.

デバイスの新しい現在の構成として、候補コンフィギュレーションをコミットするには、<コミット>操作を使用します。

The <commit> operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration.

動作は、候補コンフィギュレーションに含まれるコンフィギュレーションデータを実装するためにデバイスに指示する<コミット>。デバイスは、候補コンフィギュレーションデータストアの変更のすべてをコミットすることができない場合は、実行コンフィギュレーションは変更されませんしなければなりません。デバイスがコミットに成功した場合、実行中のコンフィギュレーションは、候補コンフィギュレーションの内容で更新する必要があります。

If the system does not have the :candidate capability, the <commit> operation is not available.

システムが持っていない場合は、次の候補の能力を、操作が利用できない<コミット>。

Positive Response:

肯定的な反応：

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

Negative Response:

否定応答：

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> </ RPC> </コミット>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

8.3.4.2. <discard-changes>

8.3.4.2。 <廃棄の変更>

If the client decides that the candidate configuration should not be committed, the <discard-changes> operation can be used to revert the candidate configuration to the current running configuration.

クライアントは、候補設定がコミットされるべきではないと判断した場合は、<廃棄-変更は>操作は、現在の実行コンフィギュレーションに候補設定を元に戻すために使用することができます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <廃棄変更/> </ RPC>

This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration.

この操作は実行コンフィギュレーションの内容を候補設定をリセットすることにより、コミットされていない変更を破棄します。

8.3.5. Modifications to Existing Operations

8.3.5. 既存事業への変更

8.3.5.1. <get-config>, <edit-config>, <copy-config>, and <validate>

8.3.5.1。 <GET-config>の、<編集-config>の、<コピー設定>、および<検証>

The candidate configuration can be used as a source or target of any <get-config>, <edit-config>, <copy-config>, or <validate> operation as a <source> or <target> parameter. The <candidate> element is used to indicate the candidate configuration:

候補設定は、<ソース>または<対象>パラメータとして任意の<GET-config>の、<編集-config>の、<コピー設定>、または<検証>操作のソースまたはターゲットとして使用することができます。 <候補>要素は、候補の構成を示すために使用されます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <！ - 任意NETCONF動作 - > <GET-config>の<ソース> <候補/ > </ソース> </取得-config>の</ RPC>

8.3.5.2. <lock> and <unlock>

8.3.5.2。 <ロック>と<ロック解除>

The candidate configuration can be locked using the <lock> operation with the <candidate> element as the <target> parameter:

候補設定は、<target>にパラメータとして<ロック> <候補>と操作要素を使用してロックすることができます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック> <ターゲット> <候補/> </ target>に</ロック> </ RPC >

Similarly, the candidate configuration is unlocked using the <candidate> element as the <target> parameter:

同様に、候補となる構成は、<target>にパラメータとして<候補>要素を使用してロック解除されます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック解除> <ターゲット> <候補/> </ target>に</アンロック> </ RPC >

When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the <unlock> operation or implicitly from session failure.

クライアントは、候補者の設定に未処理の変更に失敗した場合、回復が困難な場合があります。ロックが解除されたときに容易に回収を容易にするために、未処理の変更は、破棄され、明示的に<ロック解除>動作にまたは暗黙的にセッションの失敗からかどうか。

8.4. Confirmed Commit Capability

8.4. 確認したコミット機能

8.4.1. Description

8.4.1. 説明

The :confirmed-commit capability indicates that the server will support the <confirmed> and <confirm-timeout> parameters for the <commit> protocol operation. See Section 8.3 for further details on the <commit> operation.

：確認コミット機能は、サーバは、<確認>サポートおよび<コミット>プロトコル動作のための<確認のタイムアウト>パラメータになることを示しています。 <コミット>操作の詳細については、セクション8.3を参照してください。

A confirmed commit operation MUST be reverted if a follow-up commit (called the "confirming commit") is not issued within 600 seconds (10 minutes). The timeout period can be adjusted with the <confirm-timeout> element. The confirming commit can itself include a <confirmed> parameter.

フォローアップがコミット場合コミット動作確認は、600秒（10分）以内に発行されていない（「コミット確認」と呼ばれる）逆戻りしなければなりません。タイムアウト期間は、<確認タイムアウト>要素で調整することができます。コミット確認すること自体が、<確認>パラメータを含めることができます。

If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued.

確認を発行するセッションが確認タイムアウトが満了する前に何らかの理由で終了されてコミットした場合に発行されたコミットを確認する前に、サーバーはその状態に設定を復元する必要があります。

If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued.

確認のタイムアウトの期限が切れる前にデバイスが何らかの理由で再起動すると発行されたコミットを確認する前に、サーバーはその状態に設定を復元する必要があります。

If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. Note that any commit operation, including a commit which introduces additional changes to the configuration, will serve as a confirming commit. Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the manager can explicitly restore the configuration to its state before the confirmed commit was issued.

確認のコミットが発行されていない場合、デバイスは事前確認コミットの発行状態にその設定を元に戻すします。設定に追加の変更を導入するコミットを含め、すべての操作をコミットすることに注意してください、確認がコミットとして機能します。確認したコミットが発行される前にこのように期限切れに確認のタイムアウトを待たずに確認コミットし、元に戻す変更をキャンセルするために、管理者が明示的にその状態に設定を復元することができます。

For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the edit-config operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration databases, configuration locking should also be used.

編集設定操作される前に、共有構成では、この機能は、機能をロックする構成が（換言すれば、ロックが取得され使用されていない限り、誤って、変更または削除する（他のNETCONFセッションを介して、例えば、）他のコンフィギュレーションの変更を引き起こす可能性が開始）。したがって、強く共有構成データベースでこの機能を使用するためには、コンフィギュレーション・ロックも使用しなければならないことが示唆されます。

8.4.2. Dependencies

8.4.2. 依存関係

The :confirmed-commit capability is only relevant if the :candidate capability is also supported.

候補機能もサポートされています：場合は確認コミット機能はのみ有効です。

8.4.3. Capability Identifier

8.4.3. 機能識別子

The :confirmed-commit capability is identified by the following capability string:

：確認-コミット機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:confirmed-commit:1.0

URN：IETF：のparams：NETCONF：機能：確認コミット：1.0

8.4.4. New Operations

8.4.4. 新事業

None.

無し。

8.4.5. Modifications to Existing Operations

8.4.5. 既存事業への変更

8.4.5.1. <commit>

8.4.5.1。 <コミット>

The :confirmed-commit capability allows 2 additional parameters to the <commit> operation.

：確認コミット機能は、<コミット>操作に2つの追加のパラメータを可能にします。

Parameters:

パラメーター：

confirmed:

確認しました：

Perform a confirmed commit operation.

コミット動作確認を行います。

confirm-timeout:

確認のタイムアウトを：

            Timeout period for confirmed commit, in seconds.  If
            unspecified, the confirm timeout defaults to 600 seconds.

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コミット> <確認/> <確認タイムアウト> 120 </確認タイムアウト> </ > </ RPC>コミット

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

8.5. Rollback on Error Capability

8.5. エラー能力にロールバック

8.5.1. Description

8.5.1. 説明

This capability indicates that the server will support the 'rollback-on-error' value in the <error-option> parameter to the <edit-config> operation.

この機能は、サーバーが<編集-config>の動作に<エラー・オプション>パラメータに「ロールバック・オン・エラー」値をサポートすることを示しています。

8.5.2. Dependencies

8.5.2. 依存関係

None

無し

8.5.3. Capability Identifier

8.5.3. 機能識別子

The :rollback-on-error capability is identified by the following capability string:

：ロールバック・オン・エラー機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:rollback-on-error:1.0

URN：IETF：のparams：NETCONF：機能：ロールバック・オン・エラー：1.0

8.5.4. New Operations

8.5.4. 新事業

None.

無し。

8.5.5. Modifications to Existing Operations

8.5.5. 既存事業への変更

8.5.5.1. <edit-config>

8.5.5.1。 <編集-config>の

The :rollback-on-error capability allows the 'rollback-on-error' value to the <error-option> parameter on the <edit-config> operation.

：ロールバック・オン・エラー機能は、<編集-config>の操作で<エラー・オプション>パラメータに「ロールバック・オン・エラー」値を可能にします。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>rollback-on-error</error-option> <config> <top xmlns="http://example.com/schema/1.2/config">

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </ target>に<誤りオプション>ロールバック・オン・エラー</エラーオプション>の<config> <トップのxmlns = "http://example.com/schema/1.2/config">

<interface> <name>Ethernet0/0</name> <mtu>100000</mtu> </interface> </top> </config> </edit-config> </rpc>

<インターフェース> <名前>をEthernet0 / 0 </名前> <MTU> 100000 </ MTU> </インターフェイス> </ TOP> </ config>の</編集設定> </ RPC>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

8.6. Validate Capability

8.6. 機能を検証します

8.6.1. Description

8.6.1. 説明

Validation consists of checking a candidate configuration for syntactical and semantic errors before applying the configuration to the device.

検証は、デバイスに設定を適用する前に、構文とセマンティック・エラーの候補の設定をチェックで構成されています。

If this capability is advertised, the device supports the <validate> protocol operation and checks at least for syntax errors. In addition, this capability supports the test-option parameter to the <edit-config> operation and, when it is provided, checks at least for syntax errors.

この機能がアドバタイズされる場合、デバイスは、少なくとも構文エラー<検証>プロトコルの動作とチェックをサポートしています。また、この機能は、<編集-config>の動作テスト・オプションパラメータをサポートしており、それが与えられたときに、少なくとも構文エラーをチェックします。

8.6.2. Dependencies

8.6.2. 依存関係

None.

無し。

8.6.3. Capability Identifier

8.6.3. 機能識別子

The :validate capability is identified by the following capability string:

：検証機能は、次の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:validate:1.0

URN：IETF：のparams：NETCONF：機能：検証：1.0

8.6.4. New Operations

8.6.4. 新事業

8.6.4.1. <validate>

8.6.4.1。 <検証>

Description:

説明：

         This protocol operation validates the contents of the specified
         configuration.

Parameters:

パラメーター：

source:

ソース：

            Name of the configuration datastore being validated, such as
            <candidate> or the <config> element containing the
            configuration subtree to validate.

Positive Response:

肯定的な反応：

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

Negative Response:

否定応答：

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

A validate operation can fail for any of the following reasons:

検証操作は、次のいずれかの理由で失敗することがあります。

+ Syntax errors

+構文エラー

+ Missing parameters

+欠落パラメータ

+ References to undefined configuration data

+未定義の構成データへの参照

Example:

例：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <検証> <ソース> <候補/> </ソース> </検証> </ RPC >

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>

<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>

8.7. Distinct Startup Capability

8.7. 明確なスタートアップ機能

8.7.1. Description

8.7.1. 説明

The device supports separate running and startup configuration datastores. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit <copy-config> operation from the <running> to the <startup> must be invoked to update the startup configuration to the current contents of the running configuration. NETCONF protocol operations refer to the startup datastore using the <startup> element.

デバイスは、別の実行およびスタートアップコンフィギュレーションデータストアをサポートしています。実行コンフィギュレーションに影響を与える操作が自動的にスタートアップコンフィギュレーションにコピーされません。 <スタートアップ>と<ランニング>からの明示的な<コピー-config>の操作を実行コンフィギュレーションの現在の内容にスタートアップコンフィギュレーションを更新するために呼び出されなければなりません。 NETCONFプロトコルの動作は、<起動>要素を使用して、起動データストアを参照します。

8.7.2. Dependencies

8.7.2. 依存関係

None.

無し。

8.7.3. Capability Identifier

8.7.3. 機能識別子

The :startup capability is identified by the following capability string:

：スタートアップ機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:startup:1.0

URN：IETF：のparams：NETCONF：機能：スタートアップ：1.0

8.7.4. New Operations

8.7.4. 新事業

None.

無し。

8.7.5. Modifications to Existing Operations

8.7.5. 既存事業への変更

8.7.5.1. General

8.7.5.1。一般的な

The :startup capability adds the <startup/> configuration datastore to arguments of several NETCONF operations. The server MUST support the following additional values:

：スタートアップ機能は、複数のNETCONFオペレーションの引数に<スタートアップ/>コンフィギュレーションデータストアを追加します。サーバーは、以下の追加の値をサポートしなければなりません：

   +--------------------+--------------------------+-------------------+
   | Operation          | Parameters               | Notes             |
   +--------------------+--------------------------+-------------------+
   | <get-config>       | <source>                 |                   |
   |                    |                          |                   |
   | <copy-config>      | <source> <target>        |                   |
   |                    |                          |                   |
   | <lock>             | <target>                 |                   |
   |                    |                          |                   |
   | <unlock>           | <target>                 |                   |
   |                    |                          |                   |
   | <validate>         | <source>                 | If :validate is   |
   |                    |                          | advertised        |
   +--------------------+--------------------------+-------------------+

To save the startup configuration, use the copy-config operation to copy the <running> configuration datastore to the <startup> configuration datastore.

スタートアップコンフィギュレーションを保存するには、<スタートアップ>コンフィギュレーション・データストアに<ランニング>コンフィギュレーションデータストアをコピーするには、copy-config設定操作を使用します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コピー設定> <ソース> <実行/> </ソース> <ターゲット> <起動/> </ target>を</コピー-config>の</ RPC>

8.8. URL Capability

8.8. URL機能

8.8.1. Description

8.8.1. 説明

The NETCONF peer has the ability to accept the <url> element in <source> and <target> parameters. The capability is further identified by URL arguments indicating the URL schemes supported.

NETCONFピアは、<ソース>に<URL>要素と<target>にパラメータを受け入れる能力を有しています。機能はさらに、サポートURLスキームを示すURLの引数によって識別されます。

8.8.2. Dependencies

8.8.2. 依存関係

None.

無し。

8.8.3. Capability Identifier

8.8.3. 機能識別子

The :url capability is identified by the following capability string:

：URL機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}

URN：IETF：のparams：NETCONF：機能：URL：？1.0スキーム= {名、...}

The :url capability URI MUST contain a "scheme" argument assigned a comma-separated list of scheme names indicating which schemes the NETCONF peer supports. For example:

：URL機能は、URIは、NETCONFピアがサポートしているスキームを示すスキーム名のカンマ区切りリストを割り当てられている「スキーム」引数を含まなければなりません。例えば：

urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

URN：IETF：のparams：NETCONF：機能：URL：？1.0スキーム= HTTP、FTP、ファイル

8.8.4. New Operations

8.8.4. 新事業

None.

無し。

8.8.5. Modifications to Existing Operations

8.8.5. 既存事業への変更

8.8.5.1. <edit-config>

8.8.5.1。 <編集-config>の

The :url capability modifies the <edit-config> operation to accept the <url> element as an alternative to the <config> parameter. If the <url> element is specified, then it should identify a local configuration file.

：URL機能は、<設定>パラメータの代わりとして、<URL>要素を受け入れるために、<編集-config>の操作を変更します。 <URL>要素が指定されている場合、それはローカル設定ファイルを特定する必要があります。

8.8.5.2. <copy-config>

8.8.5.2。 <コピー設定>

The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters.

：URL機能は、<ソース>の値として<URL>要素と<target>にパラメータを受け入れるために、<コピー設定>動作を変更します。

8.8.5.3. <delete-config>

8.8.5.3。 <削除-config>の

The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters. If this parameter contains a URL, then it should identify a local configuration file.

：URL機能は、<対象>パラメータの値として、<URL>要素を受け入れるために、<削除-config>の操作を変更します。このパラメータはURLが含まれている場合、それはローカル設定ファイルを特定する必要があります。

8.8.5.4. <validate>

8.8.5.4。 <検証>

The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.

：URL機能は、<source>のパラメータの値として<URL>要素を受け入れるように<検証>動作を変更します。

8.9. XPath Capability

8.9. XPathの能力

8.9.1. Description

8.9.1. 説明

The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the <filter> element. XPath is described in [2].

XPathの機能は、NETCONFピアが<フィルタ>要素のXPath式の使用をサポートしていることを示しています。 XPathの[2]に記載されています。

The XPath expression must return a node-set.

XPath式はノードセットを返さなければなりません。

The XPath expression is evaluated in a context where the context node is the root node, and the set of namespace declarations are those in scope on the filter element, including the default namespace.

XPath式は、コンテキストノードがルートノードであるコンテキストで評価され、名前空間宣言のセットは、デフォルトの名前空間を含むフィルタエレメント上の範囲のものを、です。

8.9.2. Dependencies

8.9.2. 依存関係

None.

無し。

8.9.3. Capability Identifier

8.9.3. 機能識別子

The :xpath capability is identified by the following capability string:

：XPathの機能は、以下の機能文字列によって識別されます。

urn:ietf:params:netconf:capability:xpath:1.0

URN：IETF：のparams：NETCONF：機能：XPathの：1.0

8.9.4. New Operations

8.9.4. 新事業

None.

無し。

8.9.5. Modifications to Existing Operations

8.9.5. 既存事業への変更

8.9.5.1. <get-config> and <get>

8.9.5.1。 <GET-config設定>と<GET>

The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", a select attribute MUST be present on the filter element. The select attribute will be treated as an XPath expression and used to filter the returned data. The filter element itself MUST be empty in this case.

：XPathの機能は、フィルタ要素のtype属性に値「XPathを」受け入れるために<GET>と<GET-config>の操作を変更します。 type属性が「のxpath」に設定されている場合は、select属性は、フィルタエレメント上に存在しなければなりません。 select属性には、XPath式として扱われ、返されたデータをフィルタリングするために使用されます。フィルタエレメント自体は、この場合、空でなければなりません。

For example:

例えば：

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <GET-config>の<ソース> <実行/>

</source>  <filter type="xpath" select="top/users/user[name='fred']"/> </get-config> </rpc>

</ソース> <！ - フレッドという名前のユーザーを取得します - > <フィルタタイプ= "のxpath" を選択= "トップ/ユーザー/ユーザー[名= 'フレッド']" /> </取得-config>の</ RPC >

9. Security Considerations

9.セキュリティの考慮事項

This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. Implementors SHOULD provide a comprehensive authorization scheme with NETCONF.

このようなスキームは、メタデータモデルやデータモデルに接続する必要があり、この文書では、認可スキームを指定していません。実装者は、NETCONFとの包括認可スキームを提供する必要があります。

Authorization of individual users via the NETCONF server may or may not map 1:1 to other interfaces. First, the data models may be incompatible. Second, it may be desirable to authorize based on mechanisms available in the transport protocol layer (TELNET, SSH, etc).

他のインターフェイスに1：NETCONFサーバを介して個々のユーザの権限は、OR 1をマッピングしてもしなくてもよいです。まず、データモデルは互換性がない可能性があります。第二に、トランスポートプロトコル層（TELNET、SSHなど）で利用可能なメカニズムに基づいて許可することが望ましい場合があります。

In addition, operations on configurations may have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, a partially complete access list could be committed from a candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device if the lock on the candidate configuration does not also apply to the <copy-config> operation when applied to it.

これらの操作はまた、ファイルのグローバルロックによって守られていないか、ときに操作されるオブジェクトあればまた、構成上の操作は、予期せぬ結果をもたらす可能性があります。例えば、部分的に完全なアクセスリストは、候補設定のロックはまた、<コピーには適用されない場合のいずれか安全でないか、アクセスできないデバイスにつながる、候補設定のロックの所有者に知られず候補設定からコミットすることができそれに適用される-config>操作。

Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol should be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces.

構成情報は機密その性質です。明確かつ整合性チェックなしでその送信は、古典的な盗聴攻撃に開いてデバイスを残します。構成情報は、多くの場合、小文字が区別され、すべてのそれらのパスワード、ユーザー名、サービス記述、およびトポロジ情報が含まれています。このため、このプロトコルは1つが他の管理インターフェイスを体験することが予想される攻撃のすべての方法に十分注意して慎重に実装する必要があります。

The protocol, therefore, must minimally support options for both confidentiality and authentication. It is anticipated that the underlying protocol (SSH, BEEP, etc) will provide for both confidentiality and authentication, as is required. It is further expected that the identity of each end of a NETCONF session will be available to the other in order to determine authorization for any given request. One could also easily envision additional information, such as transport and encryption methods, being made available for purposes of authorization. NETCONF itself provide no means to re-authenticate, much less authenticate. All such actions occur at lower layers.

プロトコルは、そのため、機密性と認証の両方のサポートオプションを最小限にしなければなりません。必要とされる基礎となるプロトコル（SSH、BEEPなど）は、機密性と認証の両方を提供することが予想されます。さらにNETCONFセッションの両端のアイデンティティは、任意の要求に対する認可を決定するために、他に利用可能であることが期待されます。一つは、また、簡単に承認の目的のために利用可能になる、などの輸送や暗号化の方法として、追加の情報を思い描くことができます。 NETCONF自体は再認証する手段を提供しない、はるかに少ない認証。すべてのそのような行動は、下位層で発生します。

Different environments may well allow different rights prior to and then after authentication. Thus, an authorization model is not specified in this document. When an operation is not properly authorized, a simple "access denied" is sufficient. Note that authorization information may be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection.

異なる環境はよく前にして、認証後に異なる権利せることができます。したがって、承認モデルは、この文書で指定されていません。操作が適切に承認されていない場合は、簡単な「アクセス拒否」で十分です。接続のセキュリティを確保するためのすべてのより多くの理由である、設定情報の形式で交換することができること、認可情報に注意してください。

That having been said, it is important to recognize that some operations are clearly more sensitive by nature than others. For instance, <copy-config> to the startup or running configurations is clearly not a normal provisioning operation, whereas <edit-config> is. Such global operations MUST disallow the changing of information that an individual does not have authorization to perform. For example, if a user A is not allowed to configure an IP address on an interface but user B has configured an IP address on an interface in the <candidate> configuration, user A must not be allowed to commit the <candidate> configuration.

つまり、一部の操作は明らかに他よりも本質的に、より敏感であることを認識することが重要である、と述べていました。たとえば、<コピー-config>の起動や実行中の構成に<編集-config>のであるのに対し、明らかに通常のプロビジョニング操作ではありません。このような世界的な操作は、個人が実行する権限を持っていない情報の変更を禁止しなければなりません。ユーザAは、インタフェース上のIPアドレスを設定するために許可されていないが、ユーザBが<候補>構成におけるインターフェイスのIPアドレスを設定している場合、例えば、ユーザAは、<候補>構成をコミットさせてはなりません。

Similarly, just because someone says "go write a configuration through the URL capability at a particular place", this does not mean that an element should do it without proper authorization.

同様に、誰かが「特定の場所でURL機能による設定を記述して行く」と言う理由だけで、これは、要素が適切な承認なしにそれを行う必要があることを意味するものではありません。

The <lock> operation will demonstrate that NETCONF is intended for use by systems that have at least some trust of the administrator. As specified in this document, it is possible to lock portions of a configuration that a principal might not otherwise have access to. After all, the entire configuration is locked. To mitigate this problem, there are two approaches. It is possible to kill another NETCONF session programmatically from within NETCONF if one knows the session identifier of the offending session. The other possible way to break a lock is to provide an function within the device's native user interface. These two mechanisms suffer from a race condition that may be ameliorated by removing the offending user from an AAA server. However, such a solution is not useful in all deployment scenarios, such as those where SSH public/private key pairs are used.

<ロック>操作は、NETCONFは、管理者の少なくともいくつかの信頼を持っているシステムで使用するためのものであることを実証します。この文書で指定されているように、本人がそれ以外へのアクセス権を持っていない可能性があります設定の一部をロックすることが可能です。結局、全体の構成がロックされています。この問題を軽減するために、2つの方法があります。 1つは、問題のセッションのセッション識別子を知っている場合NETCONFの中からプログラム別のNETCONFセッションを死滅させることが可能です。ロックを解除するために、他の可能な方法は、デバイスのネイティブ・ユーザー・インターフェース内の機能を提供することです。これら二つのメカニズムは、AAAサーバから問題のあるユーザを除去することによって改善することができる競合状態に苦しみます。しかし、このような解決策は、SSH公開鍵/秘密鍵のペアが使用されている場合、それらなど、すべての展開シナリオ、に有用ではありません。

10. IANA Considerations

10. IANAの考慮事項

10.1. NETCONF XML Namespace

10.1. NETCONFのXML名前空間

This document registers a URI for the NETCONF XML namespace in the IETF XML registry [7].

この文書は、IETF XMLレジストリにNETCONFのXML名前空間のURIを登録する[7]。

Following the format in RFC 3688, IANA has made the following registration.

RFC 3688でのフォーマットに続いて、IANAは、以下の登録をしました。

URI: urn:ietf:params:xml:ns:netconf:base:1.0

URI：URN：IETF：のparams：XML：NS：NETCONF：ベース：1.0

Registrant Contact: The IESG.

登録者連絡先：IESG。

XML: N/A, the requested URI is an XML namespace.

XML：N / Aは、要求されたURIは、XML名前空間があります。

10.2. NETCONF XML Schema

10.2. NETCONF XMLスキーマ

This document registers a URI for the NETCONF XML schema in the IETF XML registry [7].

この文書は、IETF XMLレジストリにNETCONF XMLスキーマのURIを登録する[7]。

Following the format in RFC 3688, IANA has made the following registration.

RFC 3688でのフォーマットに続いて、IANAは、以下の登録をしました。

URI: urn:ietf:params:xml:schema:netconf

URI：URN：IETF：のparams：XML：スキーマ：NETCONF

Registrant Contact: The IESG.

登録者連絡先：IESG。

XML: Appendix B of this document.

XML：このドキュメントの付録B。

10.3. NETCONF Capability URNs

10.3. NETCONF能力壺

This document creates a registry that allocates NETCONF capability identifiers. Additions to the registry require IETF Standards Action.

この文書では、NETCONF機能識別子を割り当て、レジストリを作成します。レジストリへの追加は、IETF標準化行動を必要とします。

The initial content of the registry contains the capability URNs defined in Section 8.

レジストリの初期の内容は、第8項に定義された機能壺が含まれています。

Following the guidelines in RFC 3553 [6], IANA assigned a NETCONF sub-namespace as follows:

次のようにRFC 3553のガイドライン以下の[6]、IANAはNETCONFサブ名前空間を割り当てます。

Registry name: netconf

レジストリ名：NETCONF

Specification: Section 8 of this document.

仕様：このドキュメントのセクション8。

Repository: The following table.

リポジトリ：次の表。

   +--------------------+----------------------------------------------+
   | Index              | Capability Identifier                        |
   +--------------------+----------------------------------------------+
   | :writable-running  | urn:ietf:params:netconf:capability:writable- |
   |                    | running:1.0                                  |
   |                    |                                              |
   | :candidate         | urn:ietf:params:netconf:capability:candidate |
   |                    | :1.0                                         |
   |                    |                                              |
   | :confirmed-commit  | urn:ietf:params:netconf:capability:confirmed |
   |                    | -commit:1.0                                  |
   |                    |                                              |
   | :rollback-on-error | urn:ietf:params:netconf:capability:rollback- |
   |                    | on-error:1.0                                 |
   |                    |                                              |
   | :validate          | urn:ietf:params:netconf:capability:validate: |
   |                    | 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 |
   +--------------------+----------------------------------------------+

Index value: The capability name.

インデックス値：機能名。

11. Authors and Acknowledgements

11.著者と謝辞

This document was written by:

この文書は、によって書かれました：

Andy Bierman

アンディBierman

Ken Crozier, Cisco Systems

ケン・クロージャー、シスコシステムズ

Rob Enns, Juniper Networks

ロブエンス、ジュニパーネットワークス

Ted Goddard, IceSoft

テッド・ゴダード、IceSoft

Eliot Lear, Cisco Systems

エリオット・リア、シスコシステムズ

Phil Shafer, Juniper Networks

フィル・シェーファー、ジュニパーネットワークス

Steve Waldbusser

スティーブWaldbusser

Margaret Wasserman, ThingMagic

マーガレットワッサーマン、ThingMagic

The authors would like to acknowledge the members of the NETCONF working group. In particular, we would like to thank Wes Hardaker for his persistance and patience in assisting us with security considerations. We would also like to thank Randy Presuhn, Sharon Chisholm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, and Dave Harrington for all of their valuable advice.

著者は、NETCONFワーキンググループのメンバーを確認したいと思います。特に、我々はセキュリティ上の配慮で私たちを支援して彼の永続性と忍耐のためのウェスHardakerに感謝したいと思います。我々はまた、彼らの貴重なアドバイスのすべてのためのランディPresuhn、シャロン・チザム、ユルゲンSchoenwalder、グレン・ウォーターズ、デビッド・パーキンス、Weijingチェン、サイモンLeinen、キース・アレン、そしてデイブ・ハリントンに感謝したいと思います。

12. References

12.参考文献

12.1. Normative References

12.1. 引用規格

[1] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium, http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.

[1] Sperberg-マックイーン、C.、パオリ、J.、MALER、E.、およびT.ブレイ、 "拡張マークアップ言語（XML）1.0（第二版）"、ワールドワイドウェブコンソーシアムは、http：// WWW。 w3.org/TR/2000/REC-xml-20001006、2000年10月。

[2] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation, http://www.w3.org/TR/1999/REC-xpath-19991116, November 1999.

[2]クラーク、J.とS. DeRose、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告、http://www.w3.org/TR/1999/REC-xpath-19991116、11月1999。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[4] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.

[4]ワッサーマン、M.とT.ゴダード、RFC 4742 "NETCONF構成プロトコルを使用したセキュアシェル（SSH）を超える"、2006年12月。

[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[5]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。

[6] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.

[6] Mealling、M.、Masinter、L.、ハーディー、T.、およびG. Klyne、BCP 73、RFC 3553、2003年6月 "登録プロトコル・パラメータのためのIETF URNサブ名前空間"。

[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[7] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

12.2. Informative References

12.2. 参考文献

[8] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation, http://www.w3.org/TR/1999/REC-xslt-19991116, November 1999.

[8]クラーク、J.、 "XSL変換（XSLT）バージョン1.0"、World Wide Web Consortium（W3C）の勧告、http://www.w3.org/TR/1999/REC-xslt-19991116、1999年11月。

[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[9]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。

[10] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[10] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。

[11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤルイン" [11] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン。

[12] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.

[12]ホレンベック、S.、ローズ、M.、およびL. Masinter、 "IETFプロトコル内で拡張マークアップ言語（XML）の使用のためのガイドライン"、BCP 70、RFC 3470、2003年1月。

Appendix A. NETCONF Error List

付録A. NETCONFのエラー一覧

Tag: in-use Error-type: protocol, application Severity: error Error-info: none Description: The request requires a resource that already in use.

タグ：使用中のエラー・タイプ：プロトコル、アプリケーションの重要度：エラーはエラー・情報：なし説明：要求が既に使用中のリソースが必要です。

Tag: invalid-value Error-type: protocol, application Severity: error Error-info: none Description: The request specifies an unacceptable value for one or more parameters.

タグ：無効な値エラー・タイプ：プロトコル、アプリケーションの重要度：エラーエラー-情報：なし説明：要求は、1つのまたは複数のパラメータの許容できない値を指定します。

Tag: too-big Error-type: transport, rpc, protocol, application Severity: error Error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle.

タグ：あまりにもビッグエラー型：輸送、RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：なし説明：要求または応答は、（それが生成される）の実装が処理するには大きすぎます。

Tag: missing-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the missing attribute <bad-element> : name of the element that should contain the missing attribute Description: An expected attribute is missing.

タグ：欠落している属性のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い属性>：欠落している属性の説明が含まれている必要があり要素の名前：行方不明の属性<悪い要素>の名前：予想される属性が欠落しています。

Tag: bad-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the attribute w/ bad value <bad-element> : name of the element that contains the attribute with the bad value Description: An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch.

タグ：悪い属性エラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い属性>：/悪い値<悪い要素>ワット属性の名前：の属性が含まれている要素の名前不正な値説明：属性値が正しくありません。例えば、間違った種類、範囲外、パターンが一致しません。

Tag: unknown-attribute Error-type: rpc, protocol, application Severity: error Error-info: <bad-attribute> : name of the unexpected attribute <bad-element> : name of the element that contains the unexpected attribute Description: An unexpected attribute is present.

タグ：未知の属性のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い属性>：予期しない属性<悪い要素>の名前：予期しない属性の説明が含まれている要素の名前：予想外の属性が存在しています。

Tag: missing-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the missing element Description: An expected element is missing.

タグ：欠落している要素のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い要素>：不足している要素の説明の名前：予想される要素が欠落しています。

Tag: bad-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch.

タグ：悪い要素のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い要素>：不正な値説明/ wの要素の名前：要素の値が正しくありません。例えば、間違った種類、範囲外、パターンが一致しません。

Tag: unknown-element Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the unexpected element Description: An unexpected element is present.

タグ：未知の要素のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い要素>：予期しない要素の説明の名前：予期しない要素が存在しています。

Tag: unknown-namespace Error-type: rpc, protocol, application Severity: error Error-info: <bad-element> : name of the element that contains the unexpected namespace <bad-namespace> : name of the unexpected namespace Description: An unexpected namespace is present.

タグ：不明な名前空間のエラー・タイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：<悪い要素>：予期しない名前空間が含まれている要素の名前<悪い名前空間>：予期しない名前空間の説明の名前：予想外の名前空間が存在しています。

Tag: access-denied Error-type: rpc, protocol, application Severity: error Error-info: none Description: Access to the requested RPC, protocol operation, or data model is denied because authorization failed.

タグ：アクセス拒否エラー・タイプ：RPC、プロトコル、アプリケーションの重要度：エラーエラー-情報：なし説明：認証が失敗したため、要求されたRPCへのアクセス、プロトコル動作、またはデータモデルは拒否されます。

Tag: lock-denied Error-type: protocol Severity: error Error-info: <session-id> : session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock Description: Access to the requested lock is denied because the lock is currently held by another entity.

タグ：ロック拒否エラー型：プロトコル重大度：エラーエラー-情報：<セッションID>：セッションのセッションIDを非NETCONFエンティティがロックの説明を保持して示すために要求されたロック、またはゼロを保持している：要求へのアクセスロックが現在、別のエンティティによって保持されているので、ロックが拒否されます。

Tag: resource-denied Error-type: transport, rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because of insufficient resources.

タグ：リソース拒否エラー型：輸送、RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：なし説明：要求がリソース不足で完了することができませんでした。

Tag: rollback-failed Error-type: protocol, application Severity: error Error-info: none Description: Request to rollback some configuration change (via rollback-on-error or discard-changes operations) was not completed for some reason.

タグ：ロールバックして失敗したエラー・タイプ：プロトコル、アプリケーションの重要度：エラーエラー-情報：なし説明：（on-errorをロールバックまたは破棄・変更を操作経由で）いくつかの設定の変更をロールバックする要求が何らかの理由で完了しませんでした。

Tag: data-exists Error-type: application Severity: error Error-info: none Description: Request could not be completed because the relevant data model content already exists. For example, a 'create' operation was attempted on data that already exists.

タグ：アプリケーションの重要度：エラーエラー-情報：なし説明：関連するデータモデルの内容がすでに存在しているため、要求を完了できませんでしたエラータイプのデータは、存在しています。たとえば、「作成」操作がすでに存在するデータにしようとしました。

Tag: data-missing Error-type: application Severity: error Error-info: none Description: Request could not be completed because the relevant data model content does not exist. For example, a 'replace' or 'delete' operation was attempted on data that does not exist.

タグ：データ欠落エラータイプ：アプリケーション重要度：エラーエラー-情報：なし説明：関連するデータモデルのコンテンツが存在しないため、要求を完了できませんでした。例えば、「交換する」または「削除」操作は存在しないデータにしようとしました。

Tag: operation-not-supported Error-type: rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation.

タグ：操作 - サポートされていないエラータイプ：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：なし説明：要求された操作は、この実装ではサポートされていないため、要求を完了できませんでした。

Tag: operation-failed Error-type: rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because the requested operation failed for some reason not covered by any other error condition.

タグ：エラー型の操作が、失敗しました：RPC、プロトコル、アプリケーション重要度：エラーエラー-情報：なし説明：要求された操作は、他のエラー条件によってカバーされていない何らかの理由で失敗したため、要求を完了できませんでした。

Tag: partial-operation Error-type: application Severity: error Error-info: <ok-element> : identifies an element in the data model for which the requested operation has been completed for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.

タグ：パーシャル・操作エラータイプ：アプリケーション重要度：エラーエラー-情報：<OK-要素>：要求された操作は、そのノードとそのすべての子ノードのために完成されたデータモデルの要素を識別します。この要素は、<エラー情報>容器に0回以上出現することができます。

                <err-element> : identifies an element in the data model
                for which the requested operation has failed for that
                node and all its child nodes.  This element
                can appear zero or more times in the <error-info>
                container.

<noop-element> : identifies an element in the data model for which the requested operation was not attempted for that node and all its child nodes. This element can appear zero or more times in the <error-info> container. Description: Some part of the requested operation failed or was not attempted for some reason. Full cleanup has not been performed (e.g., rollback not supported) by the server. The error-info container is used to identify which portions of the application data model content for which the requested operation has succeeded (<ok-element>), failed (<bad-element>), or not been attempted (<noop-element>).

<NOOP-要素>：要求された操作は、そのノードとそのすべての子ノードに対して試行されなかったデータ・モデル内の要素を識別する。この要素は、<エラー情報>容器に0回以上出現することができます。説明：要求された操作の一部が失敗したか、何らかの理由で試みられませんでした。完全なクリーンアップは、サーバによって（例えば、ロールバックサポートされていない）が行われていません。エラー情報コンテナが要求された操作が成功したため、アプリケーションデータモデルコンテンツ（<OK-要素>）のどの部分を識別するために使用される、（<不良素子>）が失敗した、または試みられていない（<NOOP-要素>）。

Appendix B. XML Schema for NETCONF RPC and Protocol Operations

NETCONF RPCおよびプロトコル動作のための付録B. XMLスキーマ

BEGIN

ベギン

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en">  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> This import accesses the xml: attribute groups for the xml:lang as declared on the error-message element. </xs:documentation> </xs:annotation> </xs:import>  <xs:simpleType name="messageIdType"> <xs:restriction base="xs:string"> <xs:maxLength value="4095"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="SessionId"> <xs:restriction base="xs:unsignedInt"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="SessionIdOrZero"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>  <xs:complexType name="rpcType"> <xs:sequence> <xs:element ref="rpcOperation"/>

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns = "壷：IETF：のparams：XML ：NS：NETCONF：ベース：1.0" のtargetNamespace = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0" のelementFormDefault = "資格" attributeFormDefault = "修飾されていない" XML：LANG = "！EN"> < - インポート標準のXML定義 - > <XS：インポート名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "http://www.w3.org/2001/xml.xsd">エラー・メッセージの要素で宣言としてLANG：<XS：注釈> <XS：ドキュメント>：XMLの属性グループこのインポートは、XMLにアクセスします。 </ XS：ドキュメンテーション> </ XS：注釈> </ XS：インポート> <！ - メッセージ-id属性 - > <XS：単純型名= "messageIdType"> <XS：制限ベース= "XS：文字列" > <XS：maxLengthの値= "4095" /> </ XS：制限> </ XS：単純> < - セッションIDに使用されるタイプ - > <XS：！単純名= "のSessionId"> <XS：制約ベース= "XS：unsignedInt型"> <XS：のminInclusive値= "1" /> </ XS：制限> </ XS：単純> <XS：simpleTypeの名前= "SessionIdOrZero"> <XS：制限基地= "XS ：unsignedInt型 "/> </ XS：単純> < - <RPC！>要素 - > <XS：complexTypeの名前=" rpcType "> <XS：シーケンス> <XS：要素REF =" rpcOperation "/>

</xs:sequence> <xs:attribute name="message-id" type="messageIdType" use="required"/>  <xs:anyAttribute processContents="lax"/> </xs:complexType> <xs:element name="rpc" type="rpcType"/>  <xs:simpleType name="ErrorType"> <xs:restriction base="xs:string"> <xs:enumeration value="transport"/> <xs:enumeration value="rpc"/> <xs:enumeration value="protocol"/> <xs:enumeration value="application"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="ErrorTag"> <xs:restriction base="xs:string"> <xs:enumeration value="in-use"/> <xs:enumeration value="invalid-value"/> <xs:enumeration value="too-big"/> <xs:enumeration value="missing-attribute"/> <xs:enumeration value="bad-attribute"/> <xs:enumeration value="unknown-attribute"/> <xs:enumeration value="missing-element"/> <xs:enumeration value="bad-element"/> <xs:enumeration value="unknown-element"/> <xs:enumeration value="unknown-namespace"/> <xs:enumeration value="access-denied"/> <xs:enumeration value="lock-denied"/> <xs:enumeration value="resource-denied"/> <xs:enumeration value="rollback-failed"/> <xs:enumeration value="data-exists"/> <xs:enumeration value="data-missing"/> <xs:enumeration value="operation-not-supported"/> <xs:enumeration value="operation-failed"/> <xs:enumeration value="partial-operation"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="ErrorSeverity"> <xs:restriction base="xs:string"> <xs:enumeration value="error"/> <xs:enumeration value="warning"/> </xs:restriction>

</ XS：シーケンス> <XS：属性名= "メッセージID" タイプ= "messageIdType" 使用= "必須" /> < - 任意の属性は、<RPC>要素を供給することができます！。 - > <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの> <XS：要素名= "RPC" タイプ= "rpcType" /> < - RPC-エラーを構築するために使用されるデータ型と要素！ - > <XS：単純型名= "ERRORTYPE"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "輸送" /> <XS：列挙値= "RPC" /> <XS：列挙値= "プロトコル" /> <XS：列挙値= "アプリケーション" /> </ XS：制限> </ XS：単純> <XS：単純型名= "ErrorTag"> <XS：制限ベース= "XS：文字列 "> <XS：列挙値=" 使用中 "/> <XS：列挙値=" 無効値 "/> <XS：列挙値=" あまりにも大きな "/> <XS：列挙値=" がありません-attribute "/> <XS：列挙値=" 悪い属性 "/> <XS：列挙値=" 未知の属性 "/> <XS：列挙値=" 欠けている要素 "/> <XS：列挙値= "悪い要素" /> <XS：列挙値= "未知の要素" /> <XS：列挙値= "不明な名前空間" /> <XS：列挙値= "アクセス拒否" /> <XS：列挙値= "ロック拒否" /> <XS：列挙値= "リソース拒否" /> <XS：ENU meration値=「ロールバックに失敗した」/> <XS：列挙値は= /> <XS「のデータは、存在する」：列挙値=「データ欠落」/> <XS：列挙値=「サポート操作ではありません」/ > <XS：列挙値= "操作に失敗した" /> <XS：列挙値= "部分運転" /> </ XS：制限> </ XS：単純> <XS：単純型名= "ErrorSeverity"> < XS：制限ベース= "XS：文字列"> <XS：列挙値= "エラー" /> <XS：列挙値= "警告" /> </ XS：制限>

</xs:simpleType> <xs:complexType name="errorInfoType"> <xs:sequence> <xs:choice> <xs:element name="session-id" type="SessionIdOrZero"/> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:sequence> <xs:element name="bad-attribute" type="xs:QName" minOccurs="0" maxOccurs="1"/> <xs:element name="bad-element" type="xs:QName" minOccurs="0" maxOccurs="1"/> <xs:element name="ok-element" type="xs:QName" minOccurs="0" maxOccurs="1"/> <xs:element name="err-element" type="xs:QName" minOccurs="0" maxOccurs="1"/> <xs:element name="noop-element" type="xs:QName" minOccurs="0" maxOccurs="1"/> <xs:element name="bad-namespace" type="xs:QName" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:sequence> </xs:choice>  <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="rpcErrorType"> <xs:sequence> <xs:element name="error-type" type="ErrorType"/> <xs:element name="error-tag" type="ErrorTag"/> <xs:element name="error-severity" type="ErrorSeverity"/> <xs:element name="error-app-tag" type="xs:string" minOccurs="0"/> <xs:element name="error-path" type="xs:string" minOccurs="0"/> <xs:element name="error-message" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="error-info" type="errorInfoType" minOccurs="0"/> </xs:sequence>

</ XS：単純> <XS：complexTypeの名前= "errorInfoType"> <XS：シーケンス> <XS：選択> <XS：要素名= "セッションID" タイプ= "SessionIdOrZero" /> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：シーケンス> <XS：要素名= "悪い属性" タイプ= "XS：QNameの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS：要素名= "悪い要素" タイプ= "XS：QNameの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS：要素名= "OK-要素" タイプ= "XS：QNameの" minOccurs属性= "0" のmaxOccurs =」 1 "/> <XS：要素名=" ERR-要素を "TYPE = "XS：QNameの" minOccurs属性= "0" のmaxOccurs = "1"/> <XS：要素名= "NOOP-要素" タイプ=" XS： QNameの」minOccurs属性= "0" のmaxOccurs = "1" /> <XS：要素名= "悪い名前空間" タイプ= "XS：QNameの" minOccurs属性= "0" のmaxOccurs = "1" /> </ XS：シーケンス> </ XS：シーケンス> </ XS：選択> <！ - 他の名前空間からの要素はまた、NETCONF要素に従うことを許可されている - > <XS：任意の名前空間= "##他" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名= "rpcErrorType"> <XS：配列> <XS：要素名= "エラータイプ" タイプ= "ERRORTYPE" /> < XS：要素名= "エラータグ" タイプ= "ErrorTag" /> <XS：要素名= "エラー重大度" TYPE = "ErrorSeverity" /> <XS：要素名= "エラーアプリタグ" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "エラーフリー" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "エラーメッセージ" のminOccurs = "0"> <XS：complexTypeの> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性REF = "XML：langの" 使用= "オプション" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "エラー情報" タイプ= "errorInfoType" のminOccurs = "0" /> </ XS：シーケンス>

</xs:complexType>  <xs:complexType name="rpcReplyType"> <xs:choice> <xs:element name="ok"/> <xs:group ref="rpcResponse"/> </xs:choice> <xs:attribute name="message-id" type="messageIdType" use="optional"/>  <xs:anyAttribute processContents="lax"/> </xs:complexType> <xs:group name="rpcResponse"> <xs:sequence> <xs:element name="rpc-error" type="rpcErrorType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="data" type="dataInlineType" minOccurs="0"/> </xs:sequence> </xs:group> <xs:element name="rpc-reply" type="rpcReplyType"/>  <xs:simpleType name="testOptionType"> <xs:restriction base="xs:string"> <xs:enumeration value="test-then-set"/> <xs:enumeration value="set"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="errorOptionType"> <xs:restriction base="xs:string"> <xs:annotation> <xs:documentation> Use of the rollback-on-error value requires the :rollback-on-error capability. </xs:documentation> </xs:annotation> <xs:enumeration value="stop-on-error"/> <xs:enumeration value="continue-on-error"/> <xs:enumeration value="rollback-on-error"/>

</ XS：complexTypeの> <！ - <RPC-返信>要素 - > <XS：complexTypeの名前は= "rpcReplyType"> <XS：選択> <XS：要素名= "OK" /> <XS：グループ参照= "rpcResponse" /> </ XS：選択> <XS：属性名= "メッセージID" タイプ= "messageIdType" 使用= "オプション" /> < - RPCは<付属任意の属性！>要素が返されなければならないが<RPC返信>に。 - > <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの> <XS：グループ名= "rpcResponse"> <XS：配列> <XS：要素名= "RPCエラー" タイプ= "rpcErrorType "のminOccurs =" 0" のmaxOccurs = "無制限" /> <XS：要素名= "データ" タイプ= "dataInlineType" のminOccurs = "0" /> </ XS：配列> </ XS：グループ> <XS：要素名前= "RPC-返信" タイプ= "rpcReplyType" /> - <編集-config>のにパラメータ - > <XS <<テスト・オプションの種類！>：単純型名= "testOptionType"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "テスト、その後セット" /> <XS：列挙値= "設定" /> </ XS：制限> </ XS：！単純> < - タイプ単純名= "errorOptionType"> <XS：：制限ベース= "XS：文字列"> <XS：注釈> <XS：ドキュメント>の使用> <XS - <編集設定>から<エラー・オプション>パラメータロールバック・オン・エラー機能：ロールバック・オン・エラー値が必要です。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：列挙値= "ストップ・オン・エラー" /> <XS：列挙値= "継続・オン・エラー" /> <XS：列挙値= "ロールバック-on-エラー "/>

</xs:restriction> </xs:simpleType>  <xs:complexType name="rpcOperationType"/> <xs:element name="rpcOperation" type="rpcOperationType" abstract="true"/>  <xs:complexType name="configInlineType"> <xs:complexContent> <xs:extension base="xs:anyType"/> </xs:complexContent> </xs:complexType>  <xs:complexType name="dataInlineType"> <xs:complexContent> <xs:extension base="xs:anyType"/> </xs:complexContent> </xs:complexType>  <xs:simpleType name="FilterType"> <xs:restriction base="xs:string"> <xs:annotation> <xs:documentation> Use of the xpath value requires the :xpath capability. </xs:documentation> </xs:annotation> <xs:enumeration value="subtree"/> <xs:enumeration value="xpath"/> </xs:restriction> </xs:simpleType> <xs:complexType name="filterInlineType"> <xs:complexContent> <xs:extension base="xs:anyType"> <xs:attribute name="type" type="FilterType" default="subtree"/>  <xs:attribute name="select"/> </xs:extension>

</ XS：制限> </ XS：単純> < - rpcOperationType：！すべてのNETCONF操作の基本型として使用 - > <XS：complexTypeの名= "rpcOperationType" /> <XS：要素名= "rpcOperation"タイプ= "rpcOperationType" 抽象= "真" /> - 要素<！<設定用タイプ> - > <XS：complexTypeの名= "configInlineType"> <XS：complexContentを> <XS：増設ベース= "XS：anyTypeを"/> - 要素</ XS：：complexContentを> </ XS！complexTypeの> <<データの種類> - > <XS：complexTypeの名=" dataInlineType "> <XS：complexContentを> <XS：増設ベース=" XS：anyTypeの "/> - 要素</ XS：：complexContentを> </ XS！complexTypeの> <<フィルタの種類> - > <XS：単純型名=" のfilterType "> <XS：制限ベース=" XS：文字列 "> <XS：注釈> <XS：XPathの機能：ドキュメントは>のXPath値の使用が必要です。 </ XS：ドキュメント> </ XS：注釈> <XS：列挙値= "サブツリー" /> <XS：列挙値= "XPathの" /> </ XS：制限> </ XS：単純> <XS：complexTypeの名前= "filterInlineType"> <XS：complexContentを> <XS：増設ベース= "XS：anyTypeの"> <XS：属性名= "タイプ" タイプ= "のfilterType" デフォルト= "サブツリー" /> < - タイプであれば！ = "のxpath"、XPath式は、select要素に表示されます - > <XS：属性名= /> </ XS "を選択"：拡張>

</xs:complexContent> </xs:complexType>  <xs:annotation> <xs:documentation> The startup datastore can be used only if the :startup capability is advertised. The candidate datastore can be used only if the :candidate datastore is advertised. </xs:documentation> </xs:annotation> <xs:complexType name="configNameType"/> <xs:element name="config-name" type="configNameType" abstract="true"/> <xs:element name="startup" type="configNameType" substitutionGroup="config-name"/> <xs:element name="candidate" type="configNameType" substitutionGroup="config-name"/> <xs:element name="running" type="configNameType" substitutionGroup="config-name"/>  <xs:simpleType name="editOperationType"> <xs:restriction base="xs:string"> <xs:enumeration value="merge"/> <xs:enumeration value="replace"/> <xs:enumeration value="create"/> <xs:enumeration value="delete"/> </xs:restriction> </xs:simpleType> <xs:attribute name="operation" type="editOperationType" default="merge"/>  <xs:simpleType name="defaultOperationType"> <xs:restriction base="xs:string"> <xs:enumeration value="merge"/> <xs:enumeration value="replace"/> <xs:enumeration value="none"/> </xs:restriction> </xs:simpleType>  <xs:complexType name="configURIType">

</ XS：complexContentを> </ XS：complexTypeの> <！ - コンフィギュレーション・データストア名 - > <XS：注釈> <XS：ドキュメンテーション>スタートアップデータストアは、場合にのみ使用することができます：スタートアップ機能がアドバタイズされます。候補データストアアドバタイズさ：候補データストアは、場合にのみ使用することができます。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの名前= "configNameType" /> <XS：要素名= "設定名" タイプ= "configNameType" 抽象= "真" /> <XS：要素名前=タイプ= "configNameType" のsubstitutionGroup = "設定名" /> <XS "スタートアップ"：要素名= "候補" タイプ= "configNameType" のsubstitutionGroup = "設定名" /> <XS：要素名= "ランニングを"タイプ=" configNameType "のsubstitutionGroup = "設定名"/> <！ - <編集設定で使用される操作属性> - > <XS：単純型名= "editOperationType"> <XS：制限ベース=" XS：文字列 "> <XS：列挙値は=" マージ "/> <XS：列挙値は=" "/> <XS：列挙値=" 置き換え作成 "/> <XS：列挙値は=" /> </ XS」を削除：制限> </ XS：単純> <XS：属性名= "操作" タイプ= "editOperationType" デフォルト= /> < "マージ" - <既定の操作！>要素 - > <XS：単純型名=」 defaultOperationType "> <XS：制限ベース=" XS：文字列 "> <XS：列挙値=" マージ "/> <XS：列挙値=" 交換 "/> <XS：列挙値=" なし "/> </ XS：制限> </ XS ：単純> <！ - <URL>要素 - > <XS：complexTypeの名= "configURIType">

<xs:annotation> <xs:documentation> Use of the url element requires the :url capability. </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:extension base="xs:anyURI"/> </xs:simpleContent> </xs:complexType>  <xs:complexType name="rpcOperationSourceType"> <xs:choice> <xs:element name="config" type="configInlineType"/> <xs:element ref="config-name"/> <xs:element name="url" type="configURIType"/> </xs:choice> </xs:complexType>  <xs:complexType name="getConfigSourceType"> <xs:choice> <xs:element ref="config-name"/> <xs:element name="url" type="configURIType"/> </xs:choice> </xs:complexType>  <xs:complexType name="rpcOperationTargetType"> <xs:choice> <xs:element ref="config-name"/> <xs:element name="url" type="configURIType"/> </xs:choice> </xs:complexType>  <xs:complexType name="getConfigType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="source" type="getConfigSourceType"/> <xs:element name="filter" type="filterInlineType" minOccurs="0"/>

<XS：注釈> <XS：ドキュメント> url要素の使用が必要です。URLの能力を。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：simpleContentを> <XS：増設ベース= "XS：anyURIの" /> </ XS：simpleContentを> </ XS：complexTypeの> <！ - タイプ<ソースの（<GET-config>のを除く）>要素 - > <XS：complexTypeの名前= "rpcOperationSourceType"> <XS：選択> <XS：要素名= "設定" タイプ= "configInlineType" /> <XS：要素REF = "コンフィグ名" /> <XS：要素名= "URL" タイプ= "configURIType" /> </ XS：選択> </ XS：complexTypeの> < - のためのタイプ<ソース> <！GET-configに要素> - > <XS：complexTypeの名前= "getConfigSourceType"> <XS：選択> <XS：要素REF = "設定名" /> <XS：要素名= "URL" タイプ= "configURIType" /> </ XS：選択> </ XS：complexTypeの> < - <ターゲットのタイプ！>要素 - > <XS：complexTypeの名前= "rpcOperationTargetType"> <XS：選択> <XS：要素REF = "設定名" / > <XS：要素名= "URL" タイプ= "configURIType" /> </ XS：選択> </ XS：！complexTypeの> < - <GET-config>の操作 - > <XS：complexTypeの名= "getConfigType "> <XS：complexContentを> <XS：拡張ベース=" rpcOperationType "> <XS：配列> <XS：要素名=" ソース "タイプ=" GE tConfigSourceType "/> <XS：要素名=" フィルタ」タイプ= "filterInlineType" のminOccurs = "0" />

</xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="get-config" type="getConfigType" substitutionGroup="rpcOperation"/>  <xs:complexType name="editConfigType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:annotation> <xs:documentation> Use of the test-option element requires the :validate capability. Use of the url element requires the :url capability. </xs:documentation> </xs:annotation> <xs:element name="target" type="rpcOperationTargetType"/> <xs:element name="default-operation" type="defaultOperationType" minOccurs="0"/> <xs:element name="test-option" type="testOptionType" minOccurs="0"/> <xs:element name="error-option" type="errorOptionType" minOccurs="0"/> <xs:choice> <xs:element name="config" type="configInlineType"/> <xs:element name="url" type="configURIType"/> </xs:choice> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="edit-config" type="editConfigType" substitutionGroup="rpcOperation"/>  <xs:complexType name="copyConfigType"> <xs:complexContent>

</ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名=は、 "get-設定" タイプ= "getConfigType" のsubstitutionGroup = "rpcOperation" /> <！ - - <編集-config>の操作 - > <XS：complexTypeの名前= "editConfigType"> <XS：complexContentを> <XS：増設ベース= "rpcOperationType"> <XS：シーケンス> <XS：注釈> <XS：ドキュメント>検証機能：テスト・オプションの要素の使用が必要です。 URL機能：url要素の使用が必要です。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：要素名= "ターゲット" タイプ= "rpcOperationTargetType" /> <XS：要素名= "デフォルト動作" タイプ= "defaultOperationType" のminOccurs = "0" / > <XS：要素名= "テスト・オプション" TYPE = "testOptionType" のminOccurs = "0" /> <XS：要素名= "エラー・オプション" TYPE = "errorOptionType" のminOccurs = "0" /> <XS：選択肢> <XS：要素名= "設定" タイプ= "configInlineType" /> <XS：要素名= "URL" タイプ= "configURIType" /> </ XS：選択> </ XS：シーケンス> </ XS：拡張子> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "編集設定" タイプ= "editConfigType" のsubstitutionGroup = "rpcOperation" /> < - <コピー設定！>操作 - > <XS：complexTypeの名= "copyConfigType"> <XS：complexContentを>

<xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="target" type="rpcOperationTargetType"/> <xs:element name="source" type="rpcOperationSourceType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="copy-config" type="copyConfigType" substitutionGroup="rpcOperation"/>  <xs:complexType name="deleteConfigType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="target" type="rpcOperationTargetType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="delete-config" type="deleteConfigType" substitutionGroup="rpcOperation"/>  <xs:complexType name="getType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="filter" type="filterInlineType" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="get" type="getType" substitutionGroup="rpcOperation"/>  <xs:complexType name="lockType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="target" type="rpcOperationTargetType"/>

<XS：拡張ベース= "rpcOperationType"> <XS：配列> <XS：要素名= "ターゲット" タイプ= "rpcOperationTargetType" /> <XS：要素名= "ソース" タイプ= "rpcOperationSourceType" /> </ XS ：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "コピー-config設定" タイプ= "copyConfigType" のsubstitutionGroup = "rpcOperation" /> < - <削除！ -config>操作 - > <XS：complexTypeの名前= "deleteConfigType"> <XS：complexContentを> <XS：拡張ベース= "rpcOperationType"> <XS：配列> <XS：要素名= "ターゲット" タイプ= "rpcOperationTargetType "/> </ XS：配列> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名=" 消去-configと」TYPE = "deleteConfigType" のsubstitutionGroup = "rpcOperation" /> <！ - <操作>を取得 - > <XS：complexTypeの名前= "のgetType"> <XS：complexContentを> <XS：増設ベース= "rpcOperationType"> <XS：シーケンス> <XS：要素名= "フィルタを"タイプ= "filterInlineType" のminOccurs = "0" /> </ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "GET" タイプ= "のgetType"substitutionGroup = "rpcOperation" /> - 操作 - > <XS <<ロック！>：complexTypeの名前= "LOCKTYPE"> <XS：complexContentを> <XS：増設ベース= "rpcOperationType"> <XS：シーケンス> <XS ：要素名= "ターゲット" タイプ= "rpcOperationTargetType" />

</xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="lock" type="lockType" substitutionGroup="rpcOperation"/>  <xs:complexType name="unlockType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="target" type="rpcOperationTargetType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="unlock" type="unlockType" substitutionGroup="rpcOperation"/>  <xs:complexType name="validateType"> <xs:annotation> <xs:documentation> The validate operation requires the :validate capability. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="source" type="rpcOperationSourceType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="validate" type="validateType" substitutionGroup="rpcOperation"/>  <xs:simpleType name="confirmTimeoutType"> <xs:restriction base="xs:unsignedInt"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> <xs:complexType name="commitType">

</ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "ロック" タイプ= "LOCKTYPE" のsubstitutionGroup = "rpcOperation" /> < - <！動作>アンロック - > <XS：complexTypeの名前= "unlockType"> <XS：complexContentを> <XS：増設ベース= "rpcOperationType"> <XS：配列> <XS：要素名= "ターゲット" タイプ= "rpcOperationTargetType" /> </ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "アンロック" タイプ= "unlockType" のsubstitutionGroup = "rpcOperation" /> <！ - - <検証>操作 - > <XS：complexTypeの名は= "validateType"> <XS：注釈> <XS：機能を検証：ドキュメント>検証操作が必要です。 </ XS：ドキュメント> </ XS：注釈> <XS：complexContentを> <XS：拡張ベース= "rpcOperationType"> <XS：配列> <XS：要素名= "ソース" タイプ= "rpcOperationSourceType" /> </ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "検証" タイプ= "validateType" のsubstitutionGroup = "rpcOperation" /> < - <コミット！>操作 - > <XS：simpleTypeの名前= "confirmTimeoutType"> <XS：制限基地= "XS：unsignedInt型"> <XS：のminInclusive値= "1" /> </ XS：制限> </ XS：simpleTypeの> < XS：complexTypeの名前= "commitType">

<xs:annotation> <xs:documentation> The commit operation requires the :candidate capability. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:annotation> <xs:documentation> Use of the confirmed and confirm-timeout elements requires the :confirmed-commit capability. </xs:documentation> </xs:annotation> <xs:element name="confirmed" minOccurs="0"/> <xs:element name="confirm-timeout" type="confirmTimeoutType" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="commit" type="commitType" substitutionGroup="rpcOperation"/>  <xs:complexType name="discardChangesType"> <xs:annotation> <xs:documentation> The discard-changes operation requires the :candidate capability. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="rpcOperationType"/> </xs:complexContent> </xs:complexType> <xs:element name="discard-changes" type="discardChangesType" substitutionGroup="rpcOperation"/>  <xs:complexType name="closeSessionType"> <xs:complexContent> <xs:extension base="rpcOperationType"/> </xs:complexContent>

<XS：注釈>候補機能：<XS：ドキュメント>コミット操作が必要です。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：complexContentを> <XS：増設ベース= "rpcOperationType"> <XS：シーケンス> <XS：注釈> <XS：ドキュメント>確認し、確認のタイムアウトの使用確認コミット機能：要素が必要です。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：要素名= "確認" のminOccurs = "0" /> <XS：要素名= "確認タイムアウト" タイプ= "confirmTimeoutType" のminOccurs = "0" / > </ XS：シーケンス> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "コミット" タイプ= "commitType" のsubstitutionGroup = "rpcOperation" /> <！ - <廃棄変化>操作 - > <XS：complexTypeの名= "discardChangesType"> <XS：注釈> <XS：候補機能：ドキュメントは>廃棄変更操作が必要です。 </ XS：ドキュメント> </ XS：注釈> <XS：complexContentを> <XS：増設ベース= "rpcOperationType" /> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名=「廃棄変更"タイプ=" discardChangesType」のsubstitutionGroup = "rpcOperation" /> - 操作 - > <XS <<クローズセッション！>：complexTypeの名前= "closeSessionType"> <XS：complexContentを> <XS：増設ベース= "rpcOperationType" /> </ XS：complexContentを>

</xs:complexType> <xs:element name="close-session" type="closeSessionType" substitutionGroup="rpcOperation"/>  <xs:complexType name="killSessionType"> <xs:complexContent> <xs:extension base="rpcOperationType"> <xs:sequence> <xs:element name="session-id" type="SessionId" minOccurs="1"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="kill-session" type="killSessionType" substitutionGroup="rpcOperation"/>  <xs:element name="hello"> <xs:complexType> <xs:sequence> <xs:element name="capabilities"> <xs:complexType> <xs:sequence> <xs:element name="capability" type="xs:anyURI" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="session-id" type="SessionId" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

</ XS：complexTypeの> <XS：要素名= "クローズセッション" タイプ= "closeSessionType" のsubstitutionGroup = "rpcOperation" /> <XS < - - <キル・セッション>操作！>：complexTypeの名前= "killSessionType "> <XS：complexContentを> <XS：拡張ベース=" rpcOperationType "> <XS：配列> <XS：要素名=" セッションID」タイプ= "のSessionId" のminOccurs = "1" /> </ XS：配列> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "殺すセッションを" タイプ= "killSessionType" のsubstitutionGroup = "rpcOperation" /> < - <こんにちは！>要素 - > <XS：要素名は= "こんにちは"> <XS：complexTypeの> <XS：シーケンス> <XS：要素名= "能力"> <XS：complexTypeの> <XS：シーケンス> <XS：要素名=」機能」TYPE = "XS：anyURIの" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "セッションID" タイプ= "のSessionId" minOccurs = "0" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>

END

終わり

Appendix C. Capability Template

付録C.能力テンプレート

C.1. capability-name (template)

C.1。機能名（テンプレート）

C.1.1. Overview

C.1.1。概要

C.1.2. Dependencies

C.1.2。依存関係

C.1.3. Capability Identifier

C.1.3。機能識別子

The {name} capability is identified by the following capability string:

{名前}能力は、以下の能力文字列によって識別されます。

{capability uri}

{能力URI}

C.1.4. New Operations

C.1.4。新事業

C.1.4.1. <op-name>

C.1.4.1。 <オペアンプ名>

C.1.5. Modifications to Existing Operations

C.1.5。既存事業への変更

C.1.5.1. <op-name>

C.1.5.1。 <オペアンプ名>

If existing operations are not modified by this capability, this section may be omitted.

既存の操作は、この機能によって変更されていない場合は、このセクションを省略してもよいです。

C.1.6. Interactions with Other Capabilities

C.1.6。その他の機能との相互作用

If this capability does not interact with other capabilities, this section may be omitted.

この機能は他の機能と相互作用しない場合は、このセクションを省略してもよいです。

Appendix D. Configuring Multiple Devices with NETCONF

付録D.は、NETCONFを使用した複数のデバイスの設定します

D.1. Operations on Individual Devices

D.1。個々のデバイスの操作

Consider the work involved in performing a configuration update against a single individual device. In making a change to the configuration, the application needs to build trust that its change has been made correctly and that it has not impacted the operation of the device. The application (and the application user) should feel confident that their change has not damaged the network.

単一個々のデバイスに対する設定の更新を実行するのに必要な作業を考えてみましょう。構成に変更を加えることで、アプリケーションは、その変更が正しく行われていることを信頼関係を構築する必要があり、それは、デバイスの動作に影響を与えていないこと。アプリケーション（およびアプリケーションユーザ）は、その変更がネットワークを損傷していないことを確信する必要があります。

Protecting each individual device consists of a number of steps:

個々のデバイスを保護することがステップ数で構成されています。

o Acquiring the configuration lock.

コンフィギュレーションロックを取得O。

o Loading the update.

O更新をロードします。

o Validating the incoming configuration.

入ってくるコンフィギュレーションの検証、O。

o Checkpointing the running configuration.

O実行コンフィギュレーションのチェックポイント。

o Changing the running configuration.

実行コンフィギュレーションを変更し、O。

o Testing the new configuration.

O新しい構成をテストします。

o Making the change permanent (if desired).

変化は永久的作るO（必要な場合）。

o Releasing the configuration lock.

設定のロックを解除O。

Let's look at the details of each step.

各ステップの詳細を見てみましょう。

D.1.1. Acquiring the Configuration Lock

D.1.1。設定のロックを取得

A lock should be acquired to prevent simultaneous updates from multiple sources. If multiple sources are affecting the device, the application is hampered in both testing of its change to the configuration and in recovery should the update fail. Acquiring a short-lived lock is a simple defense to prevent other parties from introducing unrelated changes.

ロックは、複数のソースからの同時更新を防止するために取得する必要があります。複数のソースがデバイスに影響を与えている場合、アプリケーションは、構成への変更の両方のテストに阻まれ、回復に更新が失敗するはずです。短命のロックを取得することは無関係な変化を導入することから、他の当事者を防止するためのシンプルな防衛です。

The lock can be acquired using the <lock> operation.

ロックは<ロック>操作を使用して取得することができます。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック> <ターゲット> <実行/> </標的>

</lock> </rpc>

</ロック> </ RPC>

D.1.2. Loading the Update

D.1.2。アップデートのロード

The configuration can be loaded onto the device without impacting the running system. If the :url capability is supported and lists "file" as a supported scheme, incoming changes can be placed in a local file.

コンフィギュレーションは、稼働中のシステムに影響を与えることなく、デバイスにロードすることができます。場合は、次のURL機能はサポート方式としてサポートされており、リストの「ファイル」され、入ってくるの変更は、ローカルファイルに配置することができます。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <url>file://incoming.conf</url> </target> <source> <config>  </config> </source> </copy-config> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コピー設定> <ターゲット> <URL>ファイル：//incoming.conf </ URL > </ target>を<ソース> <設定> <！ - ここに入ってくる場所の設定 - > </ config>の</ソース> </コピー-config>の</ RPC>

If the :candidate capability is supported, the candidate configuration can be used.

場合は、次の候補機能がサポートされ、候補の構成が使用することができます。

<RPCメッセージID = "101" のxmlns = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <編集-config>の<対象> <候補/> </ target>を<設定> <！ - ここに入ってくる場所の設定 - > </ config>の</編集-config>の</ RPC>

If the update fails, the user file can be deleted using the <delete-config> operation, or the candidate configuration can be reverted using the <discard-changes> operation.

更新に失敗した場合、ユーザーファイルは、<削除-config>の操作を使用して削除することができ、または候補の設定は、<廃棄の変更>操作を使用して元に戻すことができます。

D.1.3. Validating the Incoming Configuration

D.1.3。着信設定の検証

Before the incoming configuration is applied, validating it is often useful. Validation allows the application to gain confidence that the change will succeed and simplifies recovery if it does not.

入ってくる設定が適用される前に、それを検証することが有用であることが多いです。検証は、アプリケーションが変更が成功するという確信を得ることができますし、そうでない場合は、リカバリを簡素化します。

If the device supports the :url capability and lists "file" as a supported scheme, use the <validate> operation with the <source> parameter set to the proper user file:

デバイスがサポートしている場合：サポートされている方式として、URL機能とリスト「ファイル」を、適切なユーザファイルに設定し、<ソース>パラメータと<検証>操作を使用します。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <validate> <source> <url>file://incoming.conf</url> </source> </validate> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <検証> <ソース> <URL>ファイル：//incoming.conf </ URL> < /ソース> </検証> </ RPC>

If the device supports the :candidate capability, some validation will be performed as part of loading the incoming configuration into the candidate. For full validation, either pass the <validate> parameter during the <edit-config> step given above, or use the <validate> operation with the <source> parameter set to <candidate>.

デバイスがサポートしている場合は、次の候補の能力を、いくつかの検証は、候補に入ってくる構成をロードの一部として実行されます。完全な検証のために、上記の<編集設定>ステップの間に<検証>パラメータを渡し、または<候補>に設定<ソース>パラメータと<検証>操作を使用しますか。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <検証> <ソース> <候補/> </ソース> </検証> </ RPC >

D.1.4. Checkpointing the Running Configuration

D.1.4。実行コンフィギュレーションのチェックポイント

The running configuration can be saved into a local file as a checkpoint before loading the new configuration. If the update fails, the configuration can be restored by reloading the checkpoint file.

実行コンフィギュレーションは、新しいコンフィギュレーションをロードする前にチェックポイントとしてローカルファイルに保存することができます。更新に失敗した場合、コンフィギュレーションチェックポイントファイルをリロードすることによって復元することができます。

The checkpoint file can be created using the <copy-config> operation.

チェックポイントファイルは、<コピー-config>の操作を使用して作成することができます。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <url>file://checkpoint.conf</url>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コピー設定> <ターゲット> <URL>ファイル：//checkpoint.conf </ URL >

</target> <source> <running/> </source> </copy-config> </rpc>

</ target>を<ソース> <ランニング/> </ソース> </コピー-config>の</ RPC>

To restore the checkpoint file, reverse the source and target parameters.

チェックポイントファイルを復元するには、ソースとターゲットのパラメータを逆に。

D.1.5. Changing the Running Configuration

D.1.5。実行コンフィギュレーションの変更

When the incoming configuration has been safely loaded onto the device and validated, it is ready to impact the running system.

着信設定が安全装置にロードされ、検証された場合には、実行中のシステムに影響を与える準備ができています。

If the device supports the :url capability and lists "file" as a supported scheme, use the <edit-config> operation to merge the incoming configuration into the running configuration.

デバイスがサポートしている場合：サポートされている方式として、URL機能とリスト「ファイル」を、実行コンフィギュレーションへの着信設定をマージするために、<編集-config>の操作を使用します。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <url>file://incoming.conf</url> </config> </edit-config> </rpc>

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </標的> <設定> <URL >ファイル：//incoming.conf </ URL> </ config>の</編集-config>の</ RPC>

If the device supports the :candidate capability, use the <commit> operation to set the running configuration to the candidate configuration. Use the <confirmed> parameter to allow automatic reversion to the original configuration if connectivity to the device fails.

デバイスがサポートしている場合：候補の能力を、候補コンフィギュレーションに実行コンフィギュレーションを設定するには、<コミット>操作を使用します。デバイスへの接続が失敗した場合、元の構成に自動復帰を可能にし、<確認>パラメータを使用します。

D.1.6. Testing the New Configuration

D.1.6。新しい設定のテスト

Now that the incoming configuration has been integrated into the running configuration, the application needs to gain trust that the change has affected the device in the way intended without affecting it negatively.

今の着信設定は実行コンフィギュレーションに統合されていることを、アプリケーションは変更が負それに影響を与えることなく、意図したように、デバイスに影響を与えた信頼を獲得する必要があります。

To gain this confidence, the application can run tests of the operational state of the device. The nature of the test is dependent on the nature of the change and is outside the scope of this document. Such tests may include reachability from the system running the application (using ping), changes in reachability to the rest of the network (by comparing the device's routing table), or inspection of the particular change (looking for operational evidence of the BGP peer that was just added).

この信頼を得るために、アプリケーションは、デバイスの動作状態のテストを実行することができます。テストの性質は、変更の性質に依存すると、この文書の範囲外です。そのような試験は、ネットワークの残りの部分への到達可能性の変化、または特定の変更の検査（デバイスのルーティングテーブルを比較することによって）（PINGを使用して）アプリケーションを実行しているシステムから到達可能性を含んでいてもよい（BGPピアの動作証拠を探していますちょうど）を加えました。

D.1.7. Making the Change Permanent

D.1.7。変更パーマネントを作ります

When the configuration change is in place and the application has sufficient faith in the proper function of this change, the application should make the change permanent.

構成変更が整備されていると、アプリケーションがこの変更の適切な機能で十分な信仰を持っている場合、アプリケーションは、変更を永続化する必要があります。

If the device supports the :startup capability, the current configuration can be saved to the startup configuration by using the startup configuration as the target of the <copy-config> operation.

デバイスがサポートしている場合：スタートアップ機能を、現在の設定は、<コピー-config>の操作の対象としてスタートアップコンフィギュレーションを使用してスタートアップコンフィギュレーションに保存することができます。

<RPCメッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <コピー設定> <ターゲット> <起動/> </ターゲット> <ソース> <実行/> </ソース> </コピー-config>の</ RPC>

If the device supports the :candidate capability and a confirmed commit was requested, the confirming commit must be sent before the timeout expires.

デバイスがサポートしている場合：コミット確認の候補能力と要求されたタイムアウトの期限が切れる前に、コミット確認を送信する必要があります。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> </ RPC> </コミット>

D.1.8. Releasing the Configuration Lock

D.1.8。設定のロックを解除

When the configuration update is complete, the lock must be released, allowing other applications access to the configuration.

設定の更新が完了すると、ロックが設定に、他のアプリケーションへのアクセスを許可する、解放されなければなりません。

Use the <unlock> operation to release the configuration lock.

設定のロックを解除するために、<ロック解除>操作を使用します。

<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック解除> <ターゲット> <実行/> </ target>に</アンロック> </ RPC >

D.2. Operations on Multiple Devices

D.2。複数のデバイスでの操作

When a configuration change requires updates across a number of devices, care should be taken to provide the required transaction semantics. The NETCONF protocol contains sufficient primitives upon which transaction-oriented operations can be built. Providing complete transactional semantics across multiple devices is prohibitively expensive, but the size and number of windows for failure scenarios can be reduced.

構成変更がデバイスの数全体の更新を必要とする場合には、注意が必要なトランザクションセマンティクスを提供するために取られるべきです。 NETCONFプロトコルはトランザクション指向のオペレーションを構築することができ、その上に十分なプリミティブが含まれています。複数のデバイス間で完全なトランザクション・セマンティクスを提供することは非常に高価ですが、障害シナリオのためのウィンドウの大きさと数を削減することができます。

There are two classes of multi-device operations. The first class allows the operation to fail on individual devices without requiring all devices to revert to their original state. The operation can be retried at a later time, or its failure simply reported to the user. An example of this class might be adding an NTP server. For this class of operations, failure avoidance and recovery are focused on the individual device. This means recovery of the device, reporting the failure, and perhaps scheduling another attempt.

マルチデバイス操作の2つのクラスがあります。最初のクラスは、操作が元の状態に戻すには、すべてのデバイスを必要とすることなく、個々のデバイスに失敗することを可能にします。操作は後で再試行することができ、またはその障害は、単にユーザに報告します。このクラスの例は、NTPサーバを追加することがあります。操作のこのクラスでは、障害回避と回復は、個々のデバイスに焦点を当てています。これは失敗を報告し、デバイスの回復を意味し、おそらく別の試みをスケジュールします。

The second class is more interesting, requiring that the operation should complete on all devices or be fully reversed. The network should either be transformed into a new state or be reset to its original state. For example, a change to a VPN may require updates to a number of devices. Another example of this might be adding a class-of-service definition. Leaving the network in a state where only a portion of the devices have been updated with the new definition will lead to future failures when the definition is referenced.

第二のクラスは、操作がすべてのデバイスで完了する必要がありますまたは完全に逆転されることを必要、より興味深いものです。ネットワークは、新しい状態に変換されなければならないのいずれか、または元の状態にリセットされます。例えば、VPNへの変化は、デバイスの数の更新を必要とするかもしれません。本の別の例は、サービスクラス定義を追加することがあります。デバイスの部分は定義が参照されたときに、将来の故障につながる新しい定義で更新されているだけの状態でネットワークを残します。

To give transactional semantics, the same steps used in single device operations listed above are used, but are performed in parallel across all devices. Configuration locks should be acquired on all target devices and kept until all devices are updated and the changes made permanent. Configuration changes should be uploaded and validation performed across all devices. Checkpoints should be made on each device. Then the running configuration can be changed, tested, and made permanent. If any of these steps fail, the previous configurations can be restored on any devices upon which they were changed. After the changes have been completely implemented or completely discarded, the locks on each device can be released.

トランザクション・セマンティクスを与えるために、上記単一のデバイス操作で使用したのと同じ手順が使用されるが、すべてのデバイス間で並行して行われます。コンフィギュレーション・ロックは、すべてのターゲットデバイス上で取得し、すべてのデバイスが更新され、変更を永続行われるまで維持されなければなりません。設定の変更は、アップロードされたと検証は、すべてのデバイス間で実行する必要があります。チェックポイントは、各デバイス上でなされるべきです。次に、実行コンフィギュレーションは、変更、テスト、および永久的にすることができます。これらのステップのいずれかが失敗した場合、以前の設定は、彼らが変更された時に任意のデバイスに復元することができます。変更が完全に実装または完全に廃棄された後、各デバイスのロックを解除することができます。

Appendix E. Deferred Features

付録E.繰延特長

The following features have been deferred until a future revision of this document.

次の機能は、このドキュメントの今後の改正まで延期されています。

o Granular locking of configuration objects.

構成オブジェクトのO粒状ロック。

o Named configuration files/datastores.

Oコンフィギュレーションファイル/データストアの名前付き。

o Support for multiple NETCONF channels.

複数のNETCONFチャネルのOサポート。

o Asynchronous notifications.

非同期通知O。

o Explicit protocol support for rollback of configuration changes to prior versions.

以前のバージョンへの設定変更をロールバックするためのO明示的なプロトコルのサポート。

Editor's Address

編集者の住所

Rob Enns Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 US

ロブエンスジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089米国

EMail: rpe@juniper.net

メールアドレス：rpe@juniper.net

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2006）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。