[要約] RFC 8040はRESTCONFプロトコルに関する仕様であり、ネットワークデバイスの設定と状態の管理を目的としています。RESTfulなインターフェースを使用して、ネットワークデバイスの構成や操作を行うための標準化された手法を提供します。
Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 8040 YumaWorks
Category: Standards Track M. Bjorklund
ISSN: 2070-1721 Tail-f Systems
K. Watsen
Juniper Networks
January 2017
RESTCONF Protocol
RESTCONFプロトコル
Abstract
概要
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).
このドキュメントでは、ネットワーク構成プロトコル（NETCONF）で定義されたデータストアの概念を使用して、YANGで定義されたデータにアクセスするためのプログラムインターフェイスを提供するHTTPベースのプロトコルについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8040.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8040で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Terminology ................................................5
1.1.1. NETCONF .............................................6
1.1.2. HTTP ................................................6
1.1.3. YANG ................................................7
1.1.4. NETCONF Notifications ...............................7
1.1.5. Terms ...............................................8
1.1.6. URI Template and Examples ..........................10
1.1.7. Tree Diagrams ......................................11
1.2. Subset of NETCONF Functionality ...........................11
1.3. Data-Model-Driven API .....................................12
1.4. Coexistence with NETCONF ..................................13
1.5. RESTCONF Extensibility ....................................14
2. Transport Protocol .............................................15
2.1. Integrity and Confidentiality .............................15
2.2. HTTPS with X.509v3 Certificates ...........................16
2.3. Certificate Validation ....................................16
2.4. Authenticated Server Identity .............................16
2.5. Authenticated Client Identity .............................16
3. Resources ......................................................17
3.1. Root Resource Discovery ...................................18
3.2. RESTCONF Media Types ......................................20
3.3. API Resource ..............................................20
3.3.1. {+restconf}/data ...................................21
3.3.2. {+restconf}/operations .............................22
3.3.3. {+restconf}/yang-library-version ...................22
3.4. Datastore Resource ........................................23
3.4.1. Edit Collision Prevention ..........................23
3.5. Data Resource .............................................24
3.5.1. Timestamp ..........................................25
3.5.2. Entity-Tag .........................................25
3.5.3. Encoding Data Resource Identifiers in the
Request URI ........................................26
3.5.4. Default Handling ...................................29
3.6. Operation Resource ........................................30
3.6.1. Encoding Operation Resource Input Parameters .......31
3.6.2. Encoding Operation Resource Output Parameters ......36
3.6.3. Encoding Operation Resource Errors .................38
3.7. Schema Resource ...........................................40
3.8. Event Stream Resource .....................................41
3.9. "errors" YANG Data Template ...............................41
4. RESTCONF Methods ...............................................42
4.1. OPTIONS ...................................................43
4.2. HEAD ......................................................43
4.3. GET .......................................................43
4.4. POST ......................................................45
4.4.1. Create Resource Mode ...............................45
4.4.2. Invoke Operation Mode ..............................47
4.5. PUT .......................................................48
4.6. PATCH .....................................................50
4.6.1. Plain Patch ........................................50
4.7. DELETE ....................................................51
4.8. Query Parameters ..........................................52
4.8.1. The "content" Query Parameter ......................54
4.8.2. The "depth" Query Parameter ........................54
4.8.3. The "fields" Query Parameter .......................55
4.8.4. The "filter" Query Parameter .......................56
4.8.5. The "insert" Query Parameter .......................57
4.8.6. The "point" Query Parameter ........................57
4.8.7. The "start-time" Query Parameter ...................58
4.8.8. The "stop-time" Query Parameter ....................58
4.8.9. The "with-defaults" Query Parameter ................59
5. Messages .......................................................60
5.1. Request URI Structure .....................................61
5.2. Message Encoding ..........................................62
5.3. RESTCONF Metadata .........................................63
5.3.1. XML Metadata Encoding Example ......................64
5.3.2. JSON Metadata Encoding Example .....................65
5.4. Return Status .............................................65
5.5. Message Caching ...........................................66
6. Notifications ..................................................66
6.1. Server Support ............................................66
6.2. Event Streams .............................................67
6.3. Subscribing to Receive Notifications ......................68
6.3.1. NETCONF Event Stream ...............................70
6.4. Receiving Event Notifications .............................70
7. Error Reporting ................................................73
7.1. Error Response Message ....................................75
8. RESTCONF Module ................................................79
9. RESTCONF Monitoring ............................................85
9.1. restconf-state/capabilities ...............................86
9.1.1. Query Parameter URIs ...............................87
9.1.2. The "defaults" Protocol Capability URI .............87
9.2. restconf-state/streams ....................................88
9.3. RESTCONF Monitoring Module ................................89
10. YANG Module Library ...........................................93
10.1. modules-state/module .....................................93
11. IANA Considerations ...........................................94
11.1. The "restconf" Relation Type .............................94
11.2. Registrations for New URIs and YANG Modules ..............94
11.3. Media Types ..............................................95
11.3.1. Media Type "application/yang-data+xml" ............95
11.3.2. Media Type "application/yang-data+json" ...........96
11.4. RESTCONF Capability URNs .................................97
11.5. Registration of "restconf" URN Sub-namespace .............98
12. Security Considerations .......................................99
13. References ...................................................100
13.1. Normative References ....................................100
13.2. Informative References ..................................104
Appendix A. Example YANG Module ..................................105
A.1. "example-jukebox" YANG Module .............................106
Appendix B. RESTCONF Message Examples ............................112
B.1. Resource Retrieval Examples ...............................112
B.1.1. Retrieve the Top-Level API Resource ...................112
B.1.2. Retrieve the Server Module Information ................114
B.1.3. Retrieve the Server Capability Information ............117
B.2. Data Resource and Datastore Resource Examples .............118
B.2.1. Create New Data Resources .............................118
B.2.2. Detect Datastore Resource Entity-Tag Change ...........119
B.2.3. Edit a Datastore Resource .............................121
B.2.4. Replace a Datastore Resource ..........................122
B.2.5. Edit a Data Resource ..................................122
B.3. Query Parameter Examples ..................................123
B.3.1. "content" Parameter ...................................123
B.3.2. "depth" Parameter .....................................126
B.3.3. "fields" Parameter ....................................130
B.3.4. "insert" Parameter ....................................132
B.3.5. "point" Parameter .....................................133
B.3.6. "filter" Parameter ....................................134
B.3.7. "start-time" Parameter ................................134
B.3.8. "stop-time" Parameter .................................135
B.3.9. "with-defaults" Parameter .............................135
Acknowledgements .................................................137
Authors' Addresses ...............................................137
There is a need for standard mechanisms to allow Web applications to access the configuration data, state data, data-model-specific Remote Procedure Call (RPC) operations, and event notifications within a networking device, in a modular and extensible manner.
Webアプリケーションがモジュール化された拡張可能な方法で、ネットワークデバイス内の構成データ、状態データ、データモデル固有のリモートプロシージャコール（RPC）操作、およびイベント通知にアクセスできるようにする標準メカニズムが必要です。
This document defines a protocol based on HTTP [RFC7230] called "RESTCONF", for configuring data defined in YANG version 1 [RFC6020] or YANG version 1.1 [RFC7950], using the datastore concepts defined in the Network Configuration Protocol (NETCONF) [RFC6241].
このドキュメントでは、ネットワーク構成プロトコル（NETCONF）[RFC6241]で定義されているデータストアの概念を使用して、YANGバージョン1 [RFC6020]またはYANGバージョン1.1 [RFC7950]で定義されたデータを構成するための、「RESTCONF」と呼ばれるHTTP [RFC7230]に基づくプロトコルを定義します。 ]。
NETCONF defines configuration datastores and a set of Create, Read, Update, Delete (CRUD) operations that can be used to access these datastores. NETCONF also defines a protocol for invoking these operations. The YANG language defines the syntax and semantics of datastore content, configuration, state data, RPC operations, and event notifications.
NETCONFは、構成データストアと、これらのデータストアへのアクセスに使用できる一連の作成、読み取り、更新、削除（CRUD）操作を定義します。 NETCONFは、これらの操作を呼び出すためのプロトコルも定義します。 YANG言語は、データストアのコンテンツ、構成、状態データ、RPC操作、およびイベント通知の構文とセマンティクスを定義します。
RESTCONF uses HTTP methods to provide CRUD operations on a conceptual datastore containing YANG-defined data, which is compatible with a server that implements NETCONF datastores.
RESTCONFはHTTPメソッドを使用して、YANG定義データを含む概念的なデータストアにCRUD操作を提供します。これは、NETCONFデータストアを実装するサーバーと互換性があります。
If a RESTCONF server is co-located with a NETCONF server, then there are protocol interactions with the NETCONF protocol; these interactions are described in Section 1.4. The RESTCONF server MAY provide access to specific datastores using operation resources, as described in Section 3.6. The RESTCONF protocol does not specify any mandatory operation resources. The semantics of each operation resource determine if and how datastores are accessed.
RESTCONFサーバーがNETCONFサーバーと同じ場所にある場合、NETCONFプロトコルとのプロトコルの相互作用があります。これらの相互作用については、セクション1.4で説明します。 RESTCONFサーバーは、セクション3.6で説明されているように、操作リソースを使用して特定のデータストアへのアクセスを提供できます。 RESTCONFプロトコルは必須の操作リソースを指定しません。各操作リソースのセマンティクスは、データストアへのアクセスの有無と方法を決定します。
Configuration data and state data are exposed as resources that can be retrieved with the GET method. Resources representing configuration data can be modified with the DELETE, PATCH, POST, and PUT methods. Data is encoded with either XML [W3C.REC-xml-20081126] or JSON [RFC7159].
構成データと状態データは、GETメソッドで取得できるリソースとして公開されます。構成データを表すリソースは、DELETE、PATCH、POST、およびPUTメソッドを使用して変更できます。データはXML [W3C.REC-xml-20081126]またはJSON [RFC7159]のいずれかでエンコードされます。
Data-model-specific RPC operations defined with the YANG "rpc" or "action" statements can be invoked with the POST method. Data-model-specific event notifications defined with the YANG "notification" statement can be accessed.
YANGの「rpc」または「action」ステートメントで定義されたデータモデル固有のRPC操作は、POSTメソッドで呼び出すことができます。 YANGの「通知」ステートメントで定義されたデータモデル固有のイベント通知にアクセスできます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following terms are defined in [RFC6241]:
以下の用語は[RFC6241]で定義されています：
o candidate configuration datastore
o 候補構成データストア
o configuration data
o 設定データ
o datastore
o データストア
o configuration datastore
o 構成データストア
o running configuration datastore
o 実行構成データストア
o startup configuration datastore
o スタートアップ構成データストア
o state data
o 状態データ
o user
o ユーザー
The following terms are defined in [RFC3986]:
以下の用語は[RFC3986]で定義されています：
o fragment
o 断片
o path
o 道
o query
o クエリ
The following terms are defined in [RFC7230]:
以下の用語は[RFC7230]で定義されています：
o header field
o ヘッダーフィールド
o message-body
o メッセージ本文
o request-line
o リクエストライン
o request URI
o リクエストURI
o status-line The following terms are defined in [RFC7231]:
o status-line [RFC7231]では、次の用語が定義されています。
o method
o 方法
o request
o リクエスト
o resource
o 資源
The following term is defined in [RFC7232]:
次の用語は、[RFC7232]で定義されています。
o entity-tag
o エンティティタグ
The following terms are defined in [RFC7950]:
以下の用語は[RFC7950]で定義されています：
o action
o アクション
o container
o コンテナ
o data node
o だた ので
o key leaf
o キーリーフ
o leaf
o 葉
o leaf-list
o リーフリスト
o list
o リスト
o mandatory node
o まんだとｒｙ ので
o ordered-by user
o 注文したユーザー
o presence container
o プレゼンスコンテナ
o RPC operation
o RPC操作
o top-level data node
o トップレベルのデータノード
The following term is defined in [RFC5277]:
次の用語は[RFC5277]で定義されています。
o notification replay
o 通知の再生
The following terms are used within this document:
このドキュメントでは、次の用語が使用されています。
o API resource: the resource that models the RESTCONF root resource and the sub-resources to access YANG-defined content. It is defined with the YANG data template named "yang-api" in the "ietf-restconf" module.
o APIリソース：RESTCONFルートリソースと、YANG定義のコンテンツにアクセスするためのサブリソースをモデル化するリソース。 「ietf-restconf」モジュールの「yang-api」という名前のYANGデータテンプレートで定義されています。
o client: a RESTCONF client.
o client：RESTCONFクライアント。
o data resource: a resource that models a YANG data node. It is defined with YANG data definition statements.
o データリソース：YANGデータノードをモデル化するリソース。 YANGデータ定義文で定義されています。
o datastore resource: the resource that models a programmatic interface using NETCONF datastore concepts. By default, RESTCONF methods access a unified view of the underlying datastore implementation on the server. It is defined as a sub-resource within the API resource.
o データストアリソース：NETCONFデータストアの概念を使用してプログラムインターフェイスをモデル化するリソース。デフォルトでは、RESTCONFメソッドは、サーバー上の基礎となるデータストア実装の統合ビューにアクセスします。 APIリソース内のサブリソースとして定義されます。
o edit operation: a RESTCONF operation on a data resource using either a POST, PUT, PATCH, or DELETE method. This is not the same as the NETCONF edit operation (i.e., one of the values for the "nc:operation" attribute: "create", "replace", "merge", "delete", or "remove").
o 編集操作：POST、PUT、PATCH、またはDELETEメソッドのいずれかを使用した、データリソースに対するRESTCONF操作。これは、NETCONF編集操作とは異なります（つまり、「nc：operation」属性の値の1つ：「create」、「replace」、「merge」、「delete」、または「remove」）。
o event stream resource: a resource that represents an SSE (Server-Sent Events) event stream. The content consists of text using the media type "text/event-stream", as defined by the SSE specification [W3C.REC-eventsource-20150203]. Event stream contents are described in Section 3.8.
o イベントストリームリソース：SSE（サーバー送信イベント）イベントストリームを表すリソース。コンテンツは、SSE仕様[W3C.REC-eventsource-20150203]で定義されているメディアタイプ「text / event-stream」を使用したテキストで構成されています。イベントストリームの内容については、3.8項を参照してください。
o media type: HTTP uses Internet media types [RFC2046] in the "Content-Type" and "Accept" header fields in order to provide open and extensible data typing and type negotiation.
o メディアタイプ：HTTPは、オープンで拡張可能なデータタイプおよびタイプネゴシエーションを提供するために、「Content-Type」および「Accept」ヘッダーフィールドでインターネットメディアタイプ[RFC2046]を使用します。
o NETCONF client: a client that implements the NETCONF protocol. Called "client" in [RFC6241].
o NETCONFクライアント：NETCONFプロトコルを実装するクライアント。 [RFC6241]では「クライアント」と呼ばれています。
o NETCONF server: a server that implements the NETCONF protocol. Called "server" in [RFC6241].
o NETCONFサーバー：NETCONFプロトコルを実装するサーバー。 [RFC6241]では「サーバー」と呼ばれています。
o operation: the conceptual RESTCONF operation for a message, derived from the HTTP method, request URI, header fields, and message-body.
o 操作：メッセージの概念的なRESTCONF操作。HTTPメソッド、リクエストURI、ヘッダーフィールド、およびメッセージ本文から派生します。
o operation resource: a resource that models a data-model-specific operation that is in turn defined with a YANG "rpc" or "action" statement. It is invoked with the POST method.
o 操作リソース：データモデル固有の操作をモデル化するリソースで、YANGの「rpc」または「action」ステートメントで定義されます。 POSTメソッドで呼び出されます。
o patch: a PATCH method on the target datastore or data resource. The media type of the message-body content will identify the patch type in use.
o パッチ：ターゲットデータストアまたはデータリソースに対するPATCHメソッド。メッセージ本文コンテンツのメディアタイプは、使用中のパッチタイプを識別します。
o plain patch: a specific media type for use with the PATCH method; see Section 4.6.1. It can be used for simple "merge" edit operations. It is specified by a request Content-Type of "application/yang-data+xml" or "application/yang-data+json".
o プレーンパッチ：PATCHメソッドで使用する特定のメディアタイプ。セクション4.6.1を参照してください。簡単な「マージ」編集操作に使用できます。 「application / yang-data + xml」または「application / yang-data + json」のリクエストContent-Typeによって指定されます。
o query parameter: a parameter (and its value, if any), encoded within the query component of the request URI.
o クエリパラメータ：リクエストURIのクエリコンポーネント内にエンコードされたパラメータ（および、存在する場合はその値）。
o resource type: one of the RESTCONF resource classes defined in this document. One of "api", "datastore", "data", "operation", "schema", or "event stream".
o リソースタイプ：このドキュメントで定義されているRESTCONFリソースクラスの1つ。 「api」、「datastore」、「data」、「operation」、「schema」、または「event stream」のいずれか。
o RESTCONF capability: an optional RESTCONF protocol feature that is advertised by a particular server if the feature is supported on that server. The feature is identified by an IANA-registered NETCONF Capability URI and advertised with an entry in the "capability" leaf-list defined in Section 9.3.
o RESTCONF機能：特定のサーバーで機能がサポートされている場合に、そのサーバーによってアドバタイズされるオプションのRESTCONFプロトコル機能。この機能は、IANAに登録されたNETCONF機能URIによって識別され、セクション9.3で定義された「機能」リーフリストのエントリでアドバタイズされます。
o RESTCONF client: a client that implements the RESTCONF protocol.
o RESTCONFクライアント：RESTCONFプロトコルを実装するクライアント。
o RESTCONF server: a server that implements the RESTCONF protocol.
o RESTCONFサーバー：RESTCONFプロトコルを実装するサーバー。
o retrieval request: a request using the GET or HEAD methods.
o 取得リクエスト：GETまたはHEADメソッドを使用したリクエスト。
o schema resource: a resource that is used by the client to retrieve a YANG schema with the GET method. It has a representation with the media type "application/yang".
o スキーマリソース：クライアントがGETメソッドを使用してYANGスキーマを取得するために使用するリソース。メディアタイプ「application / yang」で表現されています。
o server: a RESTCONF server.
o server：RESTCONFサーバー。
o "stream" list: the set of data resource instances that describe the event stream resources available from the server. This information is defined in the "ietf-restconf-monitoring" module as the "stream" list. It can be retrieved using the target resource "{+restconf}/data/ietf-restconf-monitoring:restconf-state/streams/ stream". The "stream" list contains information about each stream, such as the URL to retrieve the event stream data.
o 「ストリーム」リスト：サーバーから利用可能なイベントストリームリソースを記述するデータリソースインスタンスのセット。この情報は、「ietf-restconf-monitoring」モジュールで「ストリーム」リストとして定義されています。ターゲットリソース「{+ restconf} / data / ietf-restconf-monitoring：restconf-state / streams / stream」を使用して取得できます。 「ストリーム」リストには、イベントストリームデータを取得するためのURLなど、各ストリームに関する情報が含まれています。
o stream resource: an event stream resource.
o ストリームリソース：イベントストリームリソース。
o target resource: the resource that is associated with a particular message, identified by the "path" component of the request URI.
o ターゲットリソース：リクエストURIの「パス」コンポーネントで識別される、特定のメッセージに関連付けられているリソース。
o yang-data extension: a YANG external statement that conforms to the "yang-data" extension statement, found in Section 8. The yang-data extension is used to define YANG data structures that are meant to be used as YANG data templates. These data structures are not intended to be implemented as part of a configuration datastore or as an operational state within the server, so normal YANG data definition statements cannot be used.
o yang-data拡張：セクション8にある「yang-data」拡張ステートメントに準拠するYANG外部ステートメント。yang-data拡張は、YANGデータテンプレートとして使用されることを意図したYANGデータ構造を定義するために使用されます。これらのデータ構造は、構成データストアの一部として、またはサーバー内の操作状態として実装されることを意図していないため、通常のYANGデータ定義ステートメントは使用できません。
o YANG data template: a schema for modeling protocol message components as conceptual data structures using YANG. This allows the messages to be defined in an encoding-independent manner. Each YANG data template is defined with the "yang-data" extension, found in Section 8. Representations of instances conforming to a particular YANG data template can be defined for YANG. The XML representation is defined in YANG version 1.1 [RFC7950] and supported with the "application/yang-data+xml" media type. The JSON representation is defined in "JSON Encoding of Data Modeled with YANG" [RFC7951] and supported with the "application/yang-data+json" media type.
o YANGデータテンプレート：プロトコルメッセージコンポーネントをYANGを使用して概念的なデータ構造としてモデル化するためのスキーマ。これにより、エンコーディングに依存しない方法でメッセージを定義できます。各YANGデータテンプレートは、セクション8にある「yang-data」拡張を使用して定義されます。特定のYANGデータテンプレートに準拠するインスタンスの表現は、YANGに対して定義できます。 XML表現はYANGバージョン1.1 [RFC7950]で定義されており、 "application / yang-data + xml"メディアタイプでサポートされています。 JSON表現は、「YANGでモデル化されたデータのJSONエンコーディング」[RFC7951]で定義され、「application / yang-data + json」メディアタイプでサポートされています。
Throughout this document, the URI template [RFC6570] syntax "{+restconf}" is used to refer to the RESTCONF root resource outside of an example. See Section 3.1 for details.
このドキュメント全体を通して、URIテンプレート[RFC6570]構文「{+ restconf}」は、例の外のRESTCONFルートリソースを参照するために使用されます。詳細については、セクション3.1を参照してください。
For simplicity, all of the examples in this document use "/restconf" as the discovered RESTCONF API root path. Many of the examples throughout the document are based on the "example-jukebox" YANG module defined in Appendix A.1.
簡単にするために、このドキュメントのすべての例では、検出されたRESTCONF APIルートパスとして「/ restconf」を使用しています。ドキュメント全体の例の多くは、付録A.1で定義されている「example-jukebox」YANGモジュールに基づいています。
Many protocol header lines and message-body text within examples throughout the document are split into multiple lines for display purposes only. When a line ends with a backslash ("\") as the last character, the line is wrapped for display purposes. It is to be considered to be joined to the next line by deleting the backslash, the following line break, and the leading whitespace of the next line.
ドキュメント全体の例に含まれる多くのプロトコルヘッダー行とメッセージ本文テキストは、表示のみを目的として複数の行に分割されています。行が最後の文字としてバックスラッシュ（ "\"）で終わる場合、その行は表示のために折り返されます。バックスラッシュ、次の改行、および次の行の先頭の空白を削除することにより、次の行に結合されていると見なされます。
A simplified graphical representation of the data model is used in this document. The meanings of the symbols in these diagrams are as follows:
このドキュメントでは、データモデルの簡略化されたグラフィカル表現を使用しています。これらの図の記号の意味は次のとおりです。
o Brackets "[" and "]" enclose list keys.
o 大括弧 "["と "]"はリストキーを囲みます。
o Abbreviations before data node names: "rw" means configuration data (read-write), "ro" means state data (read-only), and "x" means operation resource (executable).
o データノード名の前の略語：「rw」は構成データ（読み取り/書き込み）を意味し、「ro」は状態データ（読み取り専用）を意味し、「x」は操作リソース（実行可能）を意味します。
o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
o データノード名の後の記号： "？"オプションのノード「！」を意味しますプレゼンスコンテナを意味し、「*」はリストとリーフリストを意味します。
o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
o 括弧は選択ノードとケースノードを囲み、ケースノードもコロン（ "："）でマークされます。
o Ellipsis ("...") stands for contents of subtrees that are not shown.
o 省略記号（ "..."）は、表示されていないサブツリーのコンテンツを表します。
RESTCONF does not need to mirror the full functionality of the NETCONF protocol, but it does need to be compatible with NETCONF. RESTCONF achieves this by implementing a subset of the interaction capabilities provided by the NETCONF protocol -- for instance, by eliminating datastores and explicit locking.
RESTCONFは、NETCONFプロトコルの全機能をミラーリングする必要はありませんが、NETCONFと互換性がある必要があります。 RESTCONFは、NETCONFプロトコルによって提供される対話機能のサブセットを実装することによってこれを実現します。たとえば、データストアと明示的なロックを排除します。
RESTCONF uses HTTP methods to implement the equivalent of NETCONF operations, enabling basic CRUD operations on a hierarchy of conceptual resources.
RESTCONFはHTTPメソッドを使用してNETCONF操作に相当するものを実装し、概念的なリソースの階層で基本的なCRUD操作を可能にします。
The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data resources represented by YANG data models. These basic edit operations allow the running configuration to be altered by a RESTCONF client.
HTTP POST、PUT、PATCH、およびDELETEメソッドは、YANGデータモデルによって表されるデータリソースを編集するために使用されます。これらの基本的な編集操作により、実行構成をRESTCONFクライアントで変更できます。
RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows Representational State Transfer (REST) principles [REST-Dissertation] and is compatible with the NETCONF datastore model.
RESTCONFは、NETCONFを置き換えるものではなく、Representational State Transfer（REST）の原則[REST-Dissertation]に準拠し、NETCONFデータストアモデルと互換性のあるHTTPインターフェイスを提供することを目的としています。
RESTCONF combines the simplicity of HTTP with the predictability and automation potential of a schema-driven API. Knowing the YANG modules used by the server, a client can derive all management resource URLs and the proper structure of all RESTCONF requests and responses. This strategy obviates the need for responses provided by the server to contain Hypermedia as the Engine of Application State (HATEOAS) links, originally described in Roy Fielding's doctoral dissertation [REST-Dissertation], because the client can determine the links it needs from the YANG modules.
RESTCONFは、HTTPのシンプルさと、スキーマ駆動型APIの予測可能性および自動化の可能性を組み合わせます。サーバーが使用するYANGモジュールを知っているクライアントは、すべてのRESTCONF要求と応答のすべての管理リソースURLと適切な構造を導出できます。クライアントがYANGから必要なリンクを決定できるため、この戦略では、Roy Fieldingの博士論文[REST-Dissertation]で最初に説明されたアプリケーション状態のエンジン（HATEOAS）リンクとしてハイパーメディアを含めるために、サーバーから提供される応答の必要性がなくなります。モジュール。
RESTCONF utilizes the YANG library [RFC7895] to allow a client to discover the YANG module conformance information for the server, in case the client wants to use it.
RESTCONFはYANGライブラリ[RFC7895]を利用して、クライアントが使用したい場合に備えて、クライアントがサーバーのYANGモジュール適合情報を発見できるようにします。
The server can optionally support the retrieval of the YANG modules it uses, as identified in its YANG library. See Section 3.7 for details.
サーバーは、YANGライブラリーで識別されているように、使用するYANGモジュールの取得をオプションでサポートできます。詳細はセクション3.7を参照してください。
The URIs for data-model-specific RPC operations and datastore content are predictable, based on the YANG module definitions.
データモデル固有のRPC操作とデータストアコンテンツのURIは、YANGモジュール定義に基づいて予測可能です。
The RESTCONF protocol operates on a conceptual datastore defined with the YANG data modeling language. The server lists each YANG module it supports using the "ietf-yang-library" YANG module defined in [RFC7895]. The server MUST implement the "ietf-yang-library" module, which MUST identify all of the YANG modules used by the server, in the "modules-state/module" list. The conceptual datastore contents, data-model-specific RPC operations, and event notifications are identified by this set of YANG modules.
RESTCONFプロトコルは、YANGデータモデリング言語で定義された概念的なデータストアで動作します。サーバーは、[RFC7895]で定義されている「ietf-yang-library」YANGモジュールを使用して、サポートする各YANGモジュールをリストします。サーバーは「ietsf-yang-library」モジュールを実装する必要があります。これは、サーバーが使用するすべてのYANGモジュールを「modules-state / module」リストで識別しなければなりません（MUST）。概念的なデータストアの内容、データモデル固有のRPC操作、およびイベント通知は、このYANGモジュールのセットによって識別されます。
The classification of data as configuration data or non-configuration data is derived from the YANG "config" statement. Behavior related to the ordering of data is derived from the YANG "ordered-by" statement. Non-configuration data is also called "state data".
構成データまたは非構成データとしてのデータの分類は、YANGの「config」ステートメントから導き出されます。データの順序に関連する動作は、YANGの「ordered-by」ステートメントから派生しています。非構成データは「状態データ」とも呼ばれます。
The RESTCONF datastore editing model is simple and direct, similar to the behavior of the :writable-running capability in NETCONF. Each RESTCONF edit of a data resource within the datastore resource is activated upon successful completion of the edit.
RESTCONFデータストア編集モデルはシンプルで直接的なもので、NETCONFの：writable-running機能の動作に似ています。データストアリソース内のデータリソースの各RESTCONF編集は、編集が正常に完了するとアクティブになります。
RESTCONF can be implemented on a device that supports the NETCONF protocol.
RESTCONFは、NETCONFプロトコルをサポートするデバイスに実装できます。
The following figure shows the system components if a RESTCONF server is co-located with a NETCONF server:
次の図は、RESTCONFサーバーがNETCONFサーバーと同じ場所に配置されている場合のシステムコンポーネントを示しています。
+-----------+ +-----------------+
| Web app | <-------> | |
+-----------+ RESTCONF | network device |
| |
+-----------+ | +-----------+ |
| NETCONF | <-------> | | datastore | |
| Client | NETCONF | | | |
+-----------+ | +-----------+ |
+-----------------+
The following figure shows the system components if a RESTCONF server is implemented in a device that does not have a NETCONF server:
次の図は、NETCONFサーバーのないデバイスにRESTCONFサーバーが実装されている場合のシステムコンポーネントを示しています。
+-----------+ +-----------------+
| Web app | <-------> | |
+-----------+ RESTCONF | network device |
| |
+-----------------+
There are interactions between the NETCONF protocol and RESTCONF protocol related to edit operations. It is possible that locks are in use on a RESTCONF server, even though RESTCONF cannot manipulate locks. In such a case, the RESTCONF protocol will not be granted write access to data resources within a datastore.
編集操作に関連するNETCONFプロトコルとRESTCONFプロトコルの間に相互作用があります。 RESTCONFがロックを操作できない場合でも、RESTCONFサーバーでロックが使用されている可能性があります。このような場合、RESTCONFプロトコルは、データストア内のデータリソースへの書き込みアクセスを許可されません。
If the NETCONF server supports :writable-running, all edits to configuration nodes in {+restconf}/data are performed in the running configuration datastore. The URI template "{+restconf}" is defined in Section 1.1.6.
NETCONFサーバーが：writable-runningをサポートしている場合、{+ restconf} / data内の構成ノードに対するすべての編集は、実行中の構成データストアで実行されます。 URIテンプレート「{+ restconf}」はセクション1.1.6で定義されています。
Otherwise, if the device supports :candidate, all edits to configuration nodes in {+restconf}/data are performed in the candidate configuration datastore. The candidate MUST be automatically committed to running immediately after each successful edit. Any edits from other sources that are in the candidate datastore will also be committed. If a confirmed commit procedure is in progress by any NETCONF client, then any new commit will act as the confirming commit. If the NETCONF server is expecting a
それ以外の場合、デバイスが：candidateをサポートしていれば、{+ restconf} / data内の構成ノードへのすべての編集は候補構成データストアで実行されます。候補者は、編集が成功するたびに、すぐに実行するように自動的にコミットする必要があります。候補データストアにある他のソースからの編集もコミットされます。確認されたコミット手順がNETCONFクライアントによって進行中の場合、新しいコミットは確認コミットとして機能します。 NETCONFサーバーが
"persist-id" parameter to complete the confirmed commit procedure, then the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. The error-tag "in-use" is used in this case.
確認済みのコミット手順を完了するための「persist-id」パラメーター。次にRESTCONF編集操作が「409 Conflict」ステータス行で失敗する必要があります。この場合、エラータグ「使用中」が使用されます。
If the NETCONF server supports :startup, the RESTCONF server MUST automatically update the non-volatile startup configuration datastore, after the "running" datastore has been altered as a consequence of a RESTCONF edit operation.
NETCONFサーバーが：startupをサポートしている場合、RESTCONFサーバーは、RESTCONF編集操作の結果として「実行中」のデータストアが変更された後、不揮発性スタートアップ構成データストアを自動的に更新する必要があります。
If a datastore that would be modified by a RESTCONF operation has an active lock from a NETCONF client, the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. The error-tag value "in-use" is returned in this case.
RESTCONF操作によって変更されるデータストアにNETCONFクライアントからのアクティブなロックがある場合、RESTCONF編集操作は「409 Conflict」ステータス行で失敗する必要があります。この場合、エラータグ値「使用中」が返されます。
There are two extensibility mechanisms built into RESTCONF:
RESTCONFには、2つの拡張メカニズムが組み込まれています。
o protocol version
o プロトコルバージョン
o optional capabilities
o オプション機能
This document defines version 1 of the RESTCONF protocol. If a future version of this protocol is defined, then that document will specify how the new version of RESTCONF is identified. It is expected that a different RESTCONF root resource will be used, which will be located using a different link relation (see Section 3.1).
このドキュメントでは、RESTCONFプロトコルのバージョン1を定義しています。このプロトコルの将来のバージョンが定義されている場合、そのドキュメントはRESTCONFの新しいバージョンを識別する方法を指定します。異なるリンク関係を使用して配置される異なるRESTCONFルートリソースが使用されることが予想されます（セクション3.1を参照）。
The server will advertise all protocol versions that it supports in its host-meta data.
サーバーは、ホストメタデータでサポートするすべてのプロトコルバージョンをアドバタイズします。
In this example, the server supports both RESTCONF version 1 and a fictitious version 2.
この例では、サーバーはRESTCONFバージョン1と架空のバージョン2の両方をサポートしています。
The client might send the following:
クライアントは以下を送信する場合があります。
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/restconf'/>
<Link rel='restconf2' href='/restconf2'/>
</XRD>
RESTCONF also supports a server-defined list of optional capabilities, which are listed by a server using the "ietf-restconf-monitoring" module defined in Section 9.3. This document defines several query parameters in Section 4.8. Each optional parameter has a corresponding capability URI, defined in Section 9.1.1, that is advertised by the server if supported.
RESTCONFは、オプション機能のサーバー定義リストもサポートします。これは、9.3節で定義されている「ietf-restconf-monitoring」モジュールを使用してサーバーによってリストされます。このドキュメントでは、セクション4.8でいくつかのクエリパラメータを定義しています。オプションの各パラメータには、セクション9.1.1で定義されている対応する機能URIがあり、サポートされている場合はサーバーによって通知されます。
The "capability" leaf-list can identify any sort of server extension. Currently, this extension mechanism is used to identify optional query parameters that are supported, but it is not limited to that purpose. For example, the "defaults" URI defined in Section 9.1.2 specifies a mandatory URI identifying server default-handling behavior.
「機能」リーフリストは、あらゆる種類のサーバーエクステンションを識別できます。現在、この拡張メカニズムは、サポートされているオプションのクエリパラメータを識別するために使用されていますが、その目的に限定されません。たとえば、セクション9.1.2で定義されている「デフォルト」URIは、サーバーのデフォルト処理動作を識別する必須のURIを指定します。
A new sub-resource type could be identified with a capability if it is optional to implement. Mandatory protocol features and new resource types require a new revision of the RESTCONF protocol.
新しいサブリソースタイプは、実装するかどうかがオプションの場合、機能で識別できます。必須のプロトコル機能と新しいリソースタイプには、RESTCONFプロトコルの新しいリビジョンが必要です。
HTTP [RFC7230] is an application-layer protocol that may be layered on any reliable transport-layer protocol. RESTCONF is defined on top of HTTP, but due to the sensitive nature of the information conveyed, RESTCONF requires that the transport-layer protocol provide both data integrity and confidentiality. A RESTCONF server MUST support the Transport Layer Security (TLS) protocol [RFC5246] and SHOULD adhere to [RFC7525]. The RESTCONF protocol MUST NOT be used over HTTP without using the TLS protocol.
HTTP [RFC7230]は、任意の信頼できるトランスポート層プロトコルに重ねることができるアプリケーション層プロトコルです。 RESTCONFはHTTPの上で定義されますが、伝達される情報の機密性のため、RESTCONFはトランスポート層プロトコルがデータの整合性と機密性の両方を提供することを要求します。 RESTCONFサーバーはTransport Layer Security（TLS）プロトコル[RFC5246]をサポートしなければならず（MUST）、[RFC7525]に準拠する必要があります。 RESTCONFプロトコルは、TLSプロトコルを使用せずにHTTP経由で使用してはなりません（MUST NOT）。
RESTCONF does not require a specific version of HTTP. However, it is RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all implementations.
RESTCONFは特定のバージョンのHTTPを必要としません。ただし、すべての実装で少なくともHTTP / 1.1 [RFC7230]をサポートすることをお勧めします。
Given the nearly ubiquitous support for HTTP over TLS [RFC7230], RESTCONF implementations MUST support the "https" URI scheme, which has the IANA-assigned default port 443.
HTTP over TLS [RFC7230]のほぼ至る所でのサポートを考えると、RESTCONF実装は、IANAが割り当てたデフォルトポート443を持つ「https」URIスキームをサポートする必要があります。
RESTCONF servers MUST present an X.509v3-based certificate when establishing a TLS connection with a RESTCONF client. The use of X.509v3-based certificates is consistent with NETCONF over TLS [RFC7589].
RESTCONFサーバーは、RESTCONFクライアントとのTLS接続を確立するときに、X.509v3ベースの証明書を提示する必要があります。 X.509v3ベースの証明書の使用は、TLSを介したNETCONF [RFC7589]と一貫しています。
The RESTCONF client MUST either (1) use X.509 certificate path validation [RFC5280] to verify the integrity of the RESTCONF server's TLS certificate or (2) match the server's TLS certificate with a certificate obtained by a trusted mechanism (e.g., a pinned certificate). If X.509 certificate path validation fails and the presented X.509 certificate does not match a certificate obtained by a trusted mechanism, the connection MUST be terminated, as described in Section 7.2.1 of [RFC5246].
RESTCONFクライアントは、（1）X.509証明書パス検証[RFC5280]を使用してRESTCONFサーバーのTLS証明書の整合性を検証するか、または（2）サーバーのTLS証明書を信頼できるメカニズム（たとえば、ピン留めされた）によって取得された証明書と一致させる必要があります。証明書）。 X.509証明書パスの検証が失敗し、提示されたX.509証明書が信頼できるメカニズムによって取得された証明書と一致しない場合、[RFC5246]のセクション7.2.1で説明されているように、接続を終了する必要があります。
The RESTCONF client MUST check the identity of the server according to Section 3.1 of [RFC2818].
RESTCONFクライアントは、[RFC2818]のセクション3.1に従ってサーバーのIDを確認する必要があります。
The RESTCONF server MUST authenticate client access to any protected resource. If the RESTCONF client is not authenticated, the server SHOULD send an HTTP response with a "401 Unauthorized" status-line, as defined in Section 3.1 of [RFC7235]. The error-tag value "access-denied" is used in this case.
RESTCONFサーバーは、保護されたリソースへのクライアントアクセスを認証する必要があります。 RESTCONFクライアントが認証されていない場合、[RFC7235]のセクション3.1で定義されているように、サーバーは「401 Unauthorized」ステータス行を含むHTTP応答を送信する必要があります（SHOULD）。この場合、エラータグ値「access-denied」が使用されます。
To authenticate a client, a RESTCONF server SHOULD require authentication based on TLS client certificates (Section 7.4.6 of [RFC5246]). If certificate-based authentication is not feasible (e.g., because one cannot build the required PKI for clients), then HTTP authentication MAY be used. In the latter case, one of the HTTP authentication schemes defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" (Section 5.1 in [RFC7235]) MUST be used.
クライアントを認証するために、RESTCONFサーバーはTLSクライアント証明書に基づく認証を必要とします（SHOULD）（[RFC5246]のセクション7.4.6）。証明書ベースの認証が実行可能でない場合（たとえば、クライアントに必要なPKIを構築できないため）、HTTP認証を使用できます（MAY）。後者の場合、「ハイパーテキスト転送プロトコル（HTTP）認証方式レジストリ」（[RFC7235]のセクション5.1）で定義されているHTTP認証方式の1つを使用する必要があります。
A server MAY also support the combination of both client certificates and an HTTP client authentication scheme, with the determination of how to process this combination left as an implementation decision.
サーバーは、クライアント証明書とHTTPクライアント認証方式の両方の組み合わせもサポートする場合があり（MAY）、この組み合わせの処理方法の決定は実装の決定として残されます。
The RESTCONF client identity derived from the authentication mechanism used is hereafter known as the "RESTCONF username" and subject to the NETCONF Access Control Model (NACM) [RFC6536]. When a client certificate is presented, the RESTCONF username MUST be derived using the algorithm defined in Section 7 of [RFC7589]. For all other cases, when HTTP authentication is used, the RESTCONF username MUST be provided by the HTTP authentication scheme used.
使用される認証メカニズムから派生したRESTCONFクライアントIDは、以降「RESTCONFユーザー名」と呼ばれ、NETCONFアクセス制御モデル（NACM）[RFC6536]の対象となります。クライアント証明書が提示される場合、RESTCONFユーザー名は、[RFC7589]のセクション7で定義されたアルゴリズムを使用して導出する必要があります。他のすべてのケースでは、HTTP認証が使用される場合、RESTCONFユーザー名は、使用されるHTTP認証スキームによって提供される必要があります。
The RESTCONF protocol operates on a hierarchy of resources, starting with the top-level API resource itself (Section 3.1). Each resource represents a manageable component within the device.
RESTCONFプロトコルは、トップレベルのAPIリソース自体（セクション3.1）から始めて、リソースの階層で動作します。各リソースは、デバイス内の管理可能なコンポーネントを表します。
A resource can be considered as a collection of data and the set of allowed methods on that data. It can contain nested child resources. The child resource types and the methods allowed on them are specific to the data model.
リソースは、データのコレクションと、そのデータで許可されているメソッドのセットと見なすことができます。ネストされた子リソースを含めることができます。子リソースのタイプとそれらで許可されるメソッドは、データモデルに固有です。
A resource has a representation associated with a media type identifier, as represented by the "Content-Type" header field in the HTTP response message. A resource has one or more representations, each associated with a different media type. When a representation of a resource is sent in an HTTP message, the associated media type is given in the "Content-Type" header. A resource can contain zero or more nested resources. A resource can be created and deleted independently of its parent resource, as long as the parent resource exists.
リソースには、HTTP応答メッセージの「Content-Type」ヘッダーフィールドで表されるように、メディアタイプ識別子に関連付けられた表現があります。リソースには1つ以上の表現があり、それぞれが異なるメディアタイプに関連付けられています。リソースの表現がHTTPメッセージで送信されると、関連付けられたメディアタイプが「Content-Type」ヘッダーに示されます。リソースには、0個以上のネストされたリソースを含めることができます。親リソースが存在する限り、親リソースとは関係なく、リソースを作成および削除できます。
The RESTCONF resources are accessed via a set of URIs defined in this document. The set of YANG modules supported by the server will determine the data-model-specific RPC operations, top-level data nodes, and event notification messages supported by the server.
RESTCONFリソースには、このドキュメントで定義されている一連のURIを介してアクセスします。サーバーがサポートするYANGモジュールのセットは、データモデル固有のRPC操作、トップレベルのデータノード、およびサーバーがサポートするイベント通知メッセージを決定します。
The RESTCONF protocol does not include a data resource discovery mechanism. Instead, the definitions within the YANG modules advertised by the server are used to construct an RPC operation or data resource identifier.
RESTCONFプロトコルには、データリソース検出メカニズムは含まれていません。代わりに、サーバーによってアドバタイズされたYANGモジュール内の定義を使用して、RPC操作またはデータリソース識別子が構築されます。
In line with the best practices defined by [RFC7320], RESTCONF enables deployments to specify where the RESTCONF API is located. When first connecting to a RESTCONF server, a RESTCONF client MUST determine the root of the RESTCONF API. There MUST be exactly one "restconf" link relation returned by the device.
[RFC7320]で定義されたベストプラクティスに沿って、RESTCONFはRESTCONF APIが配置されている場所を展開で指定できるようにします。 RESTCONFサーバーに最初に接続するとき、RESTCONFクライアントはRESTCONF APIのルートを決定する必要があります。デバイスから返される「restconf」リンク関係は1つだけである必要があります。
The client discovers this by getting the "/.well-known/host-meta" resource ([RFC6415]) and using the <Link> element containing the "restconf" attribute:
クライアントは、「/。well-known / host-meta」リソース（[RFC6415]）を取得し、「restconf」属性を含む<Link>要素を使用して、これを発見します。
Example returning /restconf:
/ restconfを返す例：
The client might send the following:
クライアントは以下を送信する場合があります。
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/restconf'/>
</XRD>
After discovering the RESTCONF API root, the client MUST use this value as the initial part of the path in the request URI, in any subsequent request for a RESTCONF resource.
RESTCONF APIルートを検出した後、クライアントは、RESTCONFリソースに対する後続のリクエストで、リクエストURIのパスの最初の部分としてこの値を使用する必要があります。
In this example, the client would use the path "/restconf" as the RESTCONF root resource.
この例では、クライアントはRESTCONFルートリソースとしてパス「/ restconf」を使用します。
Example returning /top/restconf:
/ top / restconfを返す例：
The client might send the following:
クライアントは以下を送信する場合があります。
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/top/restconf'/>
</XRD>
In this example, the client would use the path "/top/restconf" as the RESTCONF root resource.
この例では、クライアントはRESTCONFルートリソースとしてパス「/ top / restconf」を使用します。
The client can now determine the operation resources supported by the server. In this example, a custom "play" operation is supported:
これで、クライアントはサーバーがサポートする操作リソースを判別できます。この例では、カスタムの「再生」操作がサポートされています。
The client might send the following:
クライアントは以下を送信する場合があります。
GET /top/restconf/operations HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
Content-Type: application/yang-data+json
{ "operations" : { "example-jukebox:play" : [null] } }
If the Extensible Resource Descriptor (XRD) contains more than one link relation, then only the relation named "restconf" is relevant to this specification.
Extensible Resource Descriptor（XRD）に複数のリンク関係が含まれている場合、「restconf」という名前の関係のみがこの仕様に関連します。
Note that any given endpoint (host:port) can only support one RESTCONF server, due to the root resource discovery mechanism. This limits the number of RESTCONF servers that can run concurrently on a host, since each server must use a different port.
ルートリソースの検出メカニズムにより、特定のエンドポイント（host：port）がサポートできるRESTCONFサーバーは1つだけであることに注意してください。各サーバーは異なるポートを使用する必要があるため、これにより、ホスト上で同時に実行できるRESTCONFサーバーの数が制限されます。
The RESTCONF protocol defines two application-specific media types to identify representations of data that conforms to the schema for a particular YANG construct.
RESTCONFプロトコルは、2つのアプリケーション固有のメディアタイプを定義して、特定のYANG構成のスキーマに準拠するデータの表現を識別します。
This document defines media types for XML and JSON serialization of YANG data. Other documents MAY define other media types for different serializations of YANG data. The "application/yang-data+xml" media type is defined in Section 11.3.1. The "application/yang-data+json" media type is defined in Section 11.3.2.
このドキュメントでは、YANGデータのXMLおよびJSONシリアル化のメディアタイプを定義します。他のドキュメントは、YANGデータの異なるシリアル化のために他のメディアタイプを定義するかもしれません。 「application / yang-data + xml」メディアタイプは、セクション11.3.1で定義されています。 「application / yang-data + json」メディアタイプは、セクション11.3.2で定義されています。
The API resource contains the RESTCONF root resource for the RESTCONF datastore and operation resources. It is the top-level resource located at {+restconf} and has the media type "application/yang-data+xml" or "application/yang-data+json".
APIリソースには、RESTCONFデータストアおよび操作リソース用のRESTCONFルートリソースが含まれています。これは{+ restconf}にあるトップレベルのリソースであり、メディアタイプは「application / yang-data + xml」または「application / yang-data + json」です。
YANG tree diagram for an API resource:
APIリソースのYANGツリー図：
+---- {+restconf}
+---- data
| ...
+---- operations?
| ...
+--ro yang-library-version string
The "yang-api" YANG data template is defined using the "yang-data" extension in the "ietf-restconf" module, found in Section 8. It specifies the structure and syntax of the conceptual child resources within the API resource.
「yang-api」YANGデータテンプレートは、セクション8にある「ietf-restconf」モジュールの「yang-data」拡張を使用して定義されます。これは、APIリソース内の概念的な子リソースの構造と構文を指定します。
The API resource can be retrieved with the GET method.
APIリソースは、GETメソッドで取得できます。
The {+restconf} root resource name used in responses representing the root of the "ietf-restconf" module MUST identify the "ietf-restconf" YANG module. For example, a request to GET the root resource "/restconf" in JSON format will return a representation of the API resource named "ietf-restconf:restconf".
「ietf-restconf」モジュールのルートを表す応答で使用される{+ restconf}ルートリソース名は、「ietf-restconf」YANGモジュールを識別しなければなりません。たとえば、ルートリソース「/ restconf」をJSON形式で取得するリクエストは、「ietf-restconf：restconf」という名前のAPIリソースの表現を返します。
This resource has the following child resources:
このリソースには、次の子リソースがあります。
+----------------------+---------------------------------+
| Child Resource | Description |
+----------------------+---------------------------------+
| data | Contains all data resources |
| operations | Data-model-specific operations |
| yang-library-version | "ietf-yang-library" module date |
+----------------------+---------------------------------+
RESTCONF API Resource
RESTCONF APIリソース
This mandatory resource represents the combined configuration and state data resources that can be accessed by a client. It cannot be created or deleted by the client. The datastore resource type is defined in Section 3.4.
この必須リソースは、クライアントがアクセスできる構成と状態のデータリソースの組み合わせを表します。クライアントで作成または削除することはできません。データストアのリソースタイプはセクション3.4で定義されています。
Example:
例：
This example request by the client would retrieve only the non-configuration data nodes that exist within the "library" resource, using the "content" query parameter (see Section 4.8.1).
クライアントによるこのサンプル要求は、「コンテンツ」クエリパラメータを使用して、「ライブラリ」リソース内に存在する非構成データノードのみを取得します（セクション4.8.1を参照）。
GET /restconf/data/example-jukebox:jukebox/library\
?content=nonconfig HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+xml
<library xmlns="https://example.com/ns/example-jukebox">
<artist-count>42</artist-count>
<album-count>59</album-count>
<song-count>374</song-count>
</library>
This optional resource is a container that provides access to the data-model-specific RPC operations supported by the server. The server MAY omit this resource if no data-model-specific RPC operations are advertised.
このオプションのリソースは、サーバーがサポートするデータモデル固有のRPC操作へのアクセスを提供するコンテナーです。データモデル固有のRPC操作が通知されない場合、サーバーはこのリソースを省略してもよい（MAY）。
Any data-model-specific RPC operations defined in the YANG modules advertised by the server MUST be available as child nodes of this resource.
サーバーによってアドバタイズされたYANGモジュールで定義されたデータモデル固有のRPC操作は、このリソースの子ノードとして使用できる必要があります。
The access point for each RPC operation is represented as an empty leaf. If an operation resource is retrieved, the empty leaf representation is returned by the server.
各RPC操作のアクセスポイントは、空のリーフとして表されます。操作リソースが取得されると、空のリーフ表現がサーバーから返されます。
Operation resources are defined in Section 3.6.
操作リソースはセクション3.6で定義されています。
This mandatory leaf identifies the revision date of the "ietf-yang-library" YANG module that is implemented by this server. In the example that follows, the revision date for the module version found in [RFC7895] is used.
この必須リーフは、このサーバーによって実装される「ietf-yang-library」YANGモジュールの改訂日を識別します。次の例では、[RFC7895]にあるモジュールバージョンの改訂日が使用されます。
Example:
例：
GET /restconf/yang-library-version HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+xml
<yang-library-version
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">\
2016-06-21\
</yang-library-version>
The "{+restconf}/data" subtree represents the datastore resource, which is a collection of configuration data and state data nodes.
「{+ restconf} / data」サブツリーは、データストアリソースを表します。これは、構成データと状態データノードのコレクションです。
This resource type is an abstraction of the system's underlying datastore implementation. The client uses it to edit and retrieve data resources, as the conceptual root of all configuration and state data that is present on the device.
このリソースタイプは、システムの基盤となるデータストア実装を抽象化したものです。クライアントは、デバイスに存在するすべての構成および状態データの概念的なルートとして、データリソースを編集および取得するためにそれを使用します。
Configuration edit transaction management and configuration persistence are handled by the server and not controlled by the client. A datastore resource can be written directly with the POST and PATCH methods. Each RESTCONF edit of a datastore resource is saved to non-volatile storage by the server if the server supports non-volatile storage of configuration data, as described in Section 1.4.
構成編集トランザクション管理と構成永続性はサーバーによって処理され、クライアントによって制御されません。データストアリソースは、POSTおよびPATCHメソッドを使用して直接書き込むことができます。セクション1.4で説明されているように、サーバーが構成データの不揮発性ストレージをサポートしている場合、データストアリソースの各RESTCONF編集は、サーバーによって不揮発性ストレージに保存されます。
If the datastore resource represented by the "{+restconf}/data" subtree is retrieved, then the datastore and its contents are returned by the server. The datastore is represented by a node named "data" in the "ietf-restconf" module namespace.
「{+ restconf} / data」サブツリーで表されるデータストアリソースが取得されると、データストアとそのコンテンツがサーバーから返されます。データストアは、「ietf-restconf」モジュール名前空間の「data」という名前のノードで表されます。
Two edit collision detection and prevention mechanisms are provided in RESTCONF for the datastore resource: a timestamp and an entity-tag. Any change to configuration data resources updates the timestamp and entity-tag of the datastore resource. In addition, the RESTCONF server MUST return an error if the datastore is locked by an external source (e.g., NETCONF server).
RESTCONFには、データストアリソース用の2つの編集衝突検出および防止メカニズム（タイムスタンプとエンティティタグ）が用意されています。構成データリソースを変更すると、データストアリソースのタイムスタンプとエンティティタグが更新されます。さらに、データストアが外部ソース（NETCONFサーバーなど）によってロックされている場合、RESTCONFサーバーはエラーを返す必要があります。
The last change time is maintained, and the "Last-Modified" header field (Section 2.2 of [RFC7232]) is returned in the response for a retrieval request. The "If-Unmodified-Since" header field (Section 3.4 of [RFC7232]) can be used in edit operation requests to cause the server to reject the request if the resource has been modified since the specified timestamp.
最終変更時刻が維持され、「Last-Modified」ヘッダーフィールド（[RFC7232]のセクション2.2）が取得リクエストのレスポンスで返されます。 「If-Unmodified-Since」ヘッダーフィールド（[RFC7232]のセクション3.4）を使用して、指定されたタイムスタンプ以降にリソースが変更されている場合、サーバーがリクエストを拒否するように編集操作リクエストを送信できます。
The server SHOULD maintain a last-modified timestamp for the datastore resource, defined in Section 3.4. This timestamp is only affected by configuration child data resources and MUST NOT be updated for changes to non-configuration child data resources. Last-modified timestamps for data resources are discussed in Section 3.5.
サーバーは、セクション3.4で定義されているデータストアリソースの最終変更タイムスタンプを維持する必要があります（SHOULD）。このタイムスタンプは構成子データリソースによってのみ影響を受け、非構成子データリソースへの変更のために更新してはなりません。データリソースの最終変更のタイムスタンプについては、セクション3.5で説明します。
If the RESTCONF server is co-located with a NETCONF server, then the last-modified timestamp MUST be for the "running" datastore. Note that it is possible that other protocols can cause the last-modified timestamp to be updated. Such mechanisms are out of scope for this document.
RESTCONFサーバーがNETCONFサーバーと同じ場所にある場合、最後に変更されたタイムスタンプは「実行中」のデータストアのものでなければなりません。他のプロトコルが最終変更のタイムスタンプを更新させる可能性があることに注意してください。このようなメカニズムは、このドキュメントの範囲外です。
The server MUST maintain a unique opaque entity-tag for the datastore resource and MUST return it in the "ETag" (Section 2.3 of [RFC7232]) header in the response for a retrieval request. The client MAY use an "If-Match" header in edit operation requests to cause the server to reject the request if the resource entity-tag does not match the specified value.
サーバーは、データストアリソースの一意の不透明なエンティティタグを維持する必要があり、取得リクエストに対する応答の「ETag」（[RFC7232]のセクション2.3）ヘッダーでそれを返す必要があります。クライアントは、編集操作要求で「If-Match」ヘッダーを使用して、リソースのエンティティタグが指定された値と一致しない場合にサーバーが要求を拒否するようにすることができます（MAY）。
The server MUST maintain an entity-tag for the top-level {+restconf}/data resource. This entity-tag is only affected by configuration data resources and MUST NOT be updated for changes to non-configuration data. Entity-tags for data resources are discussed in Section 3.5. Note that each representation (e.g., XML vs. JSON) requires a different entity-tag.
サーバーは最上位の{+ restconf} / dataリソースのエンティティタグを維持する必要があります。このエンティティタグは構成データリソースによってのみ影響を受け、非構成データへの変更のために更新してはなりません。データリソースのエンティティタグについては、セクション3.5で説明します。各表現（XMLとJSONなど）には異なるエンティティタグが必要です。
If the RESTCONF server is co-located with a NETCONF server, then this entity-tag MUST be for the "running" datastore. Note that it is possible that other protocols can cause the entity-tag to be updated. Such mechanisms are out of scope for this document.
RESTCONFサーバーがNETCONFサーバーと同じ場所にある場合、このエンティティタグは「実行中」のデータストア用である必要があります。他のプロトコルによってエンティティタグが更新される可能性があることに注意してください。このようなメカニズムは、このドキュメントの範囲外です。
Changes to configuration data resources affect the timestamp and entity-tag for that resource, any ancestor data resources, and the datastore resource.
構成データリソースへの変更は、そのリソース、すべての祖先データリソース、およびデータストアリソースのタイムスタンプとエンティティタグに影響します。
For example, an edit to disable an interface might be done by setting the leaf "/interfaces/interface/enabled" to "false". The "enabled" data node and its ancestors (one "interface" list instance, and the "interfaces" container) are considered to be changed. The datastore is considered to be changed when any top-level configuration data node is changed (e.g., "interfaces").
たとえば、インターフェースを無効にする編集は、リーフ「/ interfaces / interface / enabled」を「false」に設定することで実行できます。 「有効」なデータノードとその祖先（1つの「インターフェース」リストインスタンス、および「インターフェース」コンテナ）は変更されたと見なされます。データストアは、最上位の構成データノードが変更されると変更されたと見なされます（「インターフェース」など）。
A data resource represents a YANG data node that is a descendant node of a datastore resource. Each YANG-defined data node can be uniquely targeted by the request-line of an HTTP method. Containers, leafs, leaf-list entries, list entries, anydata nodes, and anyxml nodes are data resources.
データリソースは、データストアリソースの子孫ノードであるYANGデータノードを表します。 YANGで定義された各データノードは、HTTPメソッドのリクエストラインによって一意にターゲットにすることができます。コンテナ、リーフ、リーフリストエントリ、リストエントリ、anydataノード、anyxmlノードはデータリソースです。
The representation maintained for each data resource is the YANG-defined subtree for that node. HTTP methods on a data resource affect both the targeted data node and all of its descendants, if any.
各データリソースに対して維持される表現は、そのノードのYANG定義のサブツリーです。データリソースのHTTPメソッドは、対象のデータノードとその子孫（存在する場合）の両方に影響します。
A data resource can be retrieved with the GET method. Data resources are accessed via the "{+restconf}/data" URI. This subtree is used to retrieve and edit data resources.
データリソースはGETメソッドで取得できます。データリソースには、「{+ restconf} / data」URIを介してアクセスします。このサブツリーは、データリソースの取得と編集に使用されます。
For configuration data resources, the server MAY maintain a last-modified timestamp for the resource and return the "Last-Modified" header field when it is retrieved with the GET or HEAD methods.
構成データリソースの場合、サーバーはリソースの最終変更のタイムスタンプを維持し、GETまたはHEADメソッドで取得したときに「Last-Modified」ヘッダーフィールドを返す場合があります。
The "Last-Modified" header field can be used by a RESTCONF client in subsequent requests, within the "If-Modified-Since" and "If-Unmodified-Since" header fields.
「Last-Modified」ヘッダーフィールドは、「If-Modified-Since」および「If-Unmodified-Since」ヘッダーフィールド内の後続のリクエストでRESTCONFクライアントによって使用できます。
If maintained, the resource timestamp MUST be set to the current time whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource timestamp for the datastore MUST be used instead. If the RESTCONF server is co-located with a NETCONF server, then the last-modified timestamp for a configuration data resource MUST represent the instance within the "running" datastore.
維持される場合、リソースのタイムスタンプは、リソースまたはリソース内の構成リソースが変更されるたびに、現在の時刻に設定する必要があります。維持されない場合は、代わりにデータストアのリソースタイムスタンプを使用する必要があります。 RESTCONFサーバーがNETCONFサーバーと同じ場所にある場合、構成データリソースの最終変更タイムスタンプは、「実行中」のデータストア内のインスタンスを表す必要があります。
This timestamp is only affected by configuration data resources and MUST NOT be updated for changes to non-configuration data.
このタイムスタンプは構成データリソースによってのみ影響を受け、非構成データへの変更のために更新してはなりません。
For configuration data resources, the server SHOULD maintain a resource entity-tag for each resource and return the "ETag" header field when it is retrieved as the target resource with the GET or HEAD methods. If maintained, the resource entity-tag MUST be updated whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource entity-tag for the datastore MUST be used instead.
構成データリソースの場合、サーバーは各リソースのリソースエンティティタグを維持し、GETまたはHEADメソッドでターゲットリソースとして取得されたときに「ETag」ヘッダーフィールドを返す必要があります。維持される場合、リソースエンティティタグは、リソースまたはリソース内の構成リソースが変更されるたびに更新される必要があります。維持されない場合は、代わりにデータストアのリソースエンティティタグを使用する必要があります。
The "ETag" header field can be used by a RESTCONF client in subsequent requests, within the "If-Match" and "If-None-Match" header fields.
「ETag」ヘッダーフィールドは、RESTCONFクライアントが後続のリクエストで「If-Match」および「If-None-Match」ヘッダーフィールド内で使用できます。
This entity-tag is only affected by configuration data resources and MUST NOT be updated for changes to non-configuration data. If the RESTCONF server is co-located with a NETCONF server, then the entity-tag for a configuration data resource MUST represent the instance within the "running" datastore.
このエンティティタグは構成データリソースによってのみ影響を受け、非構成データへの変更のために更新してはなりません。 RESTCONFサーバーがNETCONFサーバーと同じ場所にある場合、構成データリソースのエンティティタグは、「実行中」のデータストア内のインスタンスを表す必要があります。
In YANG, data nodes can be identified with an absolute XPath expression, defined in [XPath], starting from the document root to the target resource. In RESTCONF, URI-encoded path expressions are used instead.
YANGでは、データノードは、[XPath]で定義された、ドキュメントルートからターゲットリソースまでの絶対XPath式で識別できます。 RESTCONFでは、URIエンコードされたパス式が代わりに使用されます。
A predictable location for a data resource is important, since applications will code to the YANG data model module, which uses static naming and defines an absolute path location for all data nodes.
アプリケーションは、静的な命名を使用してすべてのデータノードの絶対パスの場所を定義するYANGデータモデルモジュールにコーディングするため、データリソースの予測可能な場所が重要です。
A RESTCONF data resource identifier is encoded from left to right, starting with the top-level data node, according to the "api-path" rule in Section 3.5.3.1. The node name of each ancestor of the target resource node is encoded in order, ending with the node name for the target resource. If a node in the path is defined in a module other than its parent node or its parent is the datastore, then the module name followed by a colon character (":") MUST be prepended to the node name in the resource identifier. See Section 3.5.3.1 for details.
RESTCONFデータリソース識別子は、セクション3.5.3.1の「api-path」ルールに従って、トップレベルのデータノードから始まり、左から右にエンコードされます。ターゲットリソースノードの各祖先のノード名は、ターゲットリソースのノード名で終わる順にエンコードされます。パス内のノードがその親ノード以外のモジュールで定義されている場合、またはその親がデータストアである場合は、モジュール名の後にコロン文字（ "："）が付いたものを、リソース識別子のノード名の前に付加する必要があります。詳細については、セクション3.5.3.1を参照してください。
If a data node in the path expression is a YANG leaf-list node, then the leaf-list value MUST be encoded according to the following rules:
パス式のデータノードがYANGリーフリストノードである場合、リーフリスト値は次のルールに従ってエンコードする必要があります。
o The identifier for the leaf-list MUST be encoded using one path segment [RFC3986].
o リーフリストの識別子は、1つのパスセグメント[RFC3986]を使用してエンコードする必要があります。
o The path segment is constructed by having the leaf-list name, followed by an "=" character, followed by the leaf-list value (e.g., /restconf/data/top-leaflist=fred).
o パスセグメントは、リーフリスト名、 "="文字、リーフリスト値（/ restconf / data / top-leaflist = fredなど）で構成されます。
o The leaf-list value is specified as a string, using the canonical representation for the YANG data type. Any reserved characters MUST be percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].
o リーフリストの値は、YANGデータ型の正規表現を使用して文字列として指定されます。 [RFC3986]のセクション2.1および2.5によると、予約文字はパーセントでエンコードする必要があります。
o YANG 1.1 allows duplicate leaf-list values for non-configuration data. In this case, there is no mechanism to specify the exact matching leaf-list instance.
o YANG 1.1では、非構成データのリーフリスト値の重複を許可しています。この場合、正確に一致するリーフリストインスタンスを指定するメカニズムはありません。
o The comma (",") character is percent-encoded [RFC3986], even though multiple key values are not possible for a leaf-list. This is more consistent and avoids special processing rules.
o カンマ（ "、"）文字はパーセントエンコード[RFC3986]ですが、リーフリストでは複数のキー値は使用できません。これはより一貫性があり、特別な処理ルールを回避します。
If a data node in the path expression is a YANG list node, then the key values for the list (if any) MUST be encoded according to the following rules:
パス式のデータノードがYANGリストノードである場合、リストのキー値（存在する場合）は、次の規則に従ってエンコードする必要があります。
o The key leaf values for a data resource representing a YANG list MUST be encoded using one path segment [RFC3986].
o YANGリストを表すデータリソースのキーリーフ値は、1つのパスセグメントを使用してエンコードする必要があります[RFC3986]。
o If there is only one key leaf value, the path segment is constructed by having the list name, followed by an "=" character, followed by the single key leaf value.
o キーリーフ値が1つしかない場合、パスセグメントは、リスト名、 "="文字、単一のキーリーフ値の順に構成されます。
o If there are multiple key leaf values, the path segment is constructed by having the list name, followed by the value of each leaf identified in the "key" statement, encoded in the order specified in the YANG "key" statement. Each key leaf value except the last one is followed by a comma character.
o 複数のキーリーフ値がある場合、パスセグメントは、リスト名に続けて、「キー」ステートメントで識別された各リーフの値をYANG「キー」ステートメントで指定された順序でエンコードすることによって構築されます。最後のものを除く各キーリーフ値の後にはコンマ文字が続きます。
o The key value is specified as a string, using the canonical representation for the YANG data type. Any reserved characters MUST be percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986]. The comma (",") character MUST be percent-encoded if it is present in the key value.
o キー値は、YANGデータ型の正規表現を使用して、文字列として指定されます。 [RFC3986]のセクション2.1および2.5によると、予約文字はパーセントでエンコードする必要があります。コンマ（ "、"）文字は、キー値に存在する場合はパーセントでエンコードする必要があります。
o All of the components in the "key" statement MUST be encoded. Partial instance identifiers are not supported.
o 「key」ステートメントのすべてのコンポーネントはエンコードする必要があります。部分的なインスタンス識別子はサポートされていません。
o Missing key values are not allowed, so two consecutive commas are interpreted as a comma, followed by a zero-length string, followed by a comma. For example, "list1=foo,,baz" would be interpreted as a list named "list1" with three key values, and the second key value is a zero-length string.
o キー値の欠落は許可されないため、2つの連続するコンマはコンマとして解釈され、その後に長さゼロの文字列が続き、その後にコンマが続きます。たとえば、 "list1 = foo ,, baz"は、3つのキー値を持つ "list1"という名前のリストとして解釈され、2番目のキー値は長さゼロの文字列です。
o Note that non-configuration lists are not required to define keys. In this case, a single list instance cannot be accessed.
o キーを定義するために非構成リストは必要ないことに注意してください。この場合、単一のリストインスタンスにはアクセスできません。
o The "list-instance" Augmented Backus-Naur Form (ABNF) [RFC5234] rule defined in Section 3.5.3.1 represents the syntax of a list instance identifier.
o セクション3.5.3.1で定義された「リストインスタンス」拡張バッカスナウアフォーム（ABNF）[RFC5234]ルールは、リストインスタンス識別子の構文を表します。
Examples:
例：
container top {
list list1 {
key "key1 key2 key3";
...
list list2 {
key "key4 key5";
...
leaf X { type string; }
}
}
leaf-list Y {
type uint32;
}
}
For the above YANG definition, the container "top" is defined in the "example-top" YANG module, and a target resource URI for leaf "X" would be encoded as follows:
上記のYANG定義の場合、コンテナ「top」は「example-top」YANGモジュールで定義され、リーフ「X」のターゲットリソースURIは次のようにエンコードされます。
/restconf/data/example-top:top/list1=key1,key2,key3/\
list2=key4,key5/X
For the above YANG definition, a target resource URI for leaf-list "Y" would be encoded as follows:
上記のYANG定義の場合、リーフリスト「Y」のターゲットリソースURIは次のようにエンコードされます。
/restconf/data/example-top:top/Y=instance-value
The following example shows how reserved characters are percent-encoded within a key value. The value of "key1" contains a comma, single-quote, double-quote, colon, double-quote, space, and forward slash (,'":" /). Note that double-quote is not a reserved character and does not need to be percent-encoded. The value of "key2" is the empty string, and the value of "key3" is the string "foo".
次の例は、予約文字がキー値内でパーセントエンコードされる方法を示しています。 「key1」の値には、コンマ、一重引用符、二重引用符、コロン、二重引用符、スペース、およびスラッシュ（、 '"：" /）が含まれています。二重引用符は予約文字ではなく、パーセントエンコードする必要がないことに注意してください。 「key2」の値は空の文字列で、「key3」の値は文字列「foo」です。
Example URL:
URLの例：
/restconf/data/example-top:top/list1=%2C%27"%3A"%20%2F,,foo
The "api-path" ABNF [RFC5234] syntax is used to construct RESTCONF path identifiers. Note that this syntax is used for all resources, and the API path starts with the RESTCONF root resource. Data resources are required to be identified under the "{+restconf}/data" subtree.
「api-path」ABNF [RFC5234]構文は、RESTCONFパス識別子を構築するために使用されます。この構文はすべてのリソースに使用され、APIパスはRESTCONFルートリソースで始まることに注意してください。データリソースは、「{+ restconf} / data」サブツリーの下で識別される必要があります。
An identifier is not allowed to start with the case-insensitive string "XML", according to YANG identifier rules. The syntax for "api-identifier" and "key-value" MUST conform to the JSON identifier encoding rules in Section 4 of [RFC7951]: The RESTCONF root resource path is required. Additional sub-resource identifiers are optional. The characters in a key value string are constrained, and some characters need to be percent-encoded, as described in Section 3.5.3.
YANG識別子の規則に従って、識別子は大文字と小文字を区別しない文字列「XML」で始めることはできません。 「api-identifier」と「key-value」の構文は、[RFC7951]のセクション4のJSON識別子エンコーディングルールに準拠する必要があります。RESTCONFルートリソースパスが必要です。追加のサブリソース識別子はオプションです。セクション3.5.3で説明されているように、キー値文字列の文字は制限されており、一部の文字はパーセントエンコードする必要があります。
api-path = root *("/" (api-identifier / list-instance))
root = string ;; replacement string for {+restconf}
api-identifier = [module-name ":"] identifier
module-name = identifier
list-instance = api-identifier "=" key-value *("," key-value)
key-value = string ;; constrained chars are percent-encoded
string = <an unquoted string>
identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".")
RESTCONF requires that a server report its default-handling mode (see Section 9.1.2 for details). If the optional "with-defaults" query parameter is supported by the server, a client may use it to control the retrieval of default values (see Section 4.8.9 for details).
RESTCONFでは、サーバーがデフォルトの処理モードを報告する必要があります（詳細は、セクション9.1.2を参照）。オプションの「with-defaults」クエリパラメータがサーバーでサポートされている場合、クライアントはそれを使用してデフォルト値の取得を制御できます（詳細については、セクション4.8.9を参照）。
If a leaf or leaf-list is missing from the configuration and there is a YANG-defined default for that data resource, then the server MUST use the YANG-defined default as the configured value.
リーフまたはリーフリストが構成から欠落しており、そのデータリソースにYANGで定義されたデフォルトがある場合、サーバーは構成された値としてYANGで定義されたデフォルトを使用する必要があります。
If the target of a GET method is a data node that represents a leaf or leaf-list that has a default value and the leaf or leaf-list has not been instantiated yet, the server MUST return the default value or values that are in use by the server. In this case, the server MUST ignore its "basic-mode", described in Section 4.8.9, and return the default value.
GETメソッドのターゲットが、デフォルト値を持つリーフまたはリーフリストを表すデータノードであり、リーフまたはリーフリストがまだインスタンス化されていない場合、サーバーはデフォルト値または使用中の値を返す必要がありますサーバーによって。この場合、サーバーはセクション4.8.9で説明されている「基本モード」を無視し、デフォルト値を返さなければなりません（MUST）。
If the target of a GET method is a data node that represents a container or list that has any child resources with default values, for the child resources that have not been given values yet, the server MAY return the default values that are in use by the server in accordance with its reported default-handling mode and query parameters passed by the client.
GETメソッドのターゲットが、デフォルト値を持つ子リソースを持つコンテナまたはリストを表すデータノードである場合、まだ値が与えられていない子リソースについて、サーバーは、報告されたデフォルト処理モードおよびクライアントから渡されたクエリパラメータに応じたサーバー。
An operation resource represents an RPC operation defined with the YANG "rpc" statement or a data-model-specific action defined with a YANG "action" statement. It is invoked using a POST method on the operation resource.
操作リソースは、YANG「rpc」ステートメントで定義されたRPC操作、またはYANG「アクション」ステートメントで定義されたデータモデル固有のアクションを表します。これは、操作リソースのPOSTメソッドを使用して呼び出されます。
An RPC operation is invoked as:
RPC操作は次のように呼び出されます。
POST {+restconf}/operations/<operation>
The <operation> field identifies the module name and rpc identifier string for the desired operation.
<operation>フィールドは、目的の操作のモジュール名とrpc識別子文字列を識別します。
For example, if "module-A" defined a "reset" RPC operation, then invoking the operation would be requested as follows:
たとえば、「module-A」が「リセット」RPCオペレーションを定義した場合、オペレーションの呼び出しは次のように要求されます。
POST /restconf/operations/module-A:reset HTTP/1.1
Server: example.com
An action is invoked as:
アクションは次のように呼び出されます。
POST {+restconf}/data/<data-resource-identifier>/<action>
where <data-resource-identifier> contains the path to the data node where the action is defined, and <action> is the name of the action.
<data-resource-identifier>には、アクションが定義されているデータノードへのパスが含まれ、<action>はアクションの名前です。
For example, if "module-A" defined a "reset-all" action in the container "interfaces", then invoking this action would be requested as follows:
たとえば、「module-A」がコンテナ「interfaces」で「reset-all」アクションを定義した場合、このアクションの呼び出しは次のように要求されます。
POST /restconf/data/module-A:interfaces/reset-all HTTP/1.1
Server: example.com
If the RPC operation is invoked without errors and if the "rpc" or "action" statement has no "output" section, the response message MUST NOT include a message-body and MUST send a "204 No Content" status-line instead.
RPC操作がエラーなしで呼び出され、「rpc」または「action」ステートメントに「output」セクションがない場合、応答メッセージにメッセージ本文を含めてはならず、代わりに「204 No Content」ステータス行を送信する必要があります。
All operation resources representing RPC operations supported by the server MUST be identified in the "{+restconf}/operations" subtree, defined in Section 3.3.2. Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the "{+restconf}/data" subtree.
サーバーがサポートするRPC操作を表すすべての操作リソースは、セクション3.3.2で定義されている「{+ restconf} / operations」サブツリーで識別される必要があります。 YANGアクションを表す操作リソースは、「{+ restconf} / data」サブツリー内のURIを使用して呼び出されるため、このサブツリーでは識別されません。
If the "rpc" or "action" statement has an "input" section, then instances of these input parameters are encoded in the module namespace where the "rpc" or "action" statement is defined, in an XML element or JSON object named "input", which is in the module namespace where the "rpc" or "action" statement is defined.
「rpc」または「action」ステートメントに「input」セクションがある場合、これらの入力パラメーターのインスタンスは、「rpc」または「action」ステートメントが定義されているモジュール名前空間のXML要素またはJSONオブジェクト「入力」。これは、「rpc」または「アクション」ステートメントが定義されているモジュール名前空間にあります。
If the "rpc" or "action" statement has an "input" section and the "input" object tree contains any child data nodes that are considered mandatory nodes, then a message-body MUST be sent by the client in the request.
「rpc」または「action」ステートメントに「input」セクションがあり、「input」オブジェクトツリーに必須ノードと見なされる子データノードが含まれている場合は、リクエストでクライアントがメッセージ本文を送信する必要があります。
If the "rpc" or "action" statement has an "input" section and the "input" object tree does not contain any child nodes that are considered mandatory nodes, then a message-body MAY be sent by the client in the request.
「rpc」または「action」ステートメントに「input」セクションがあり、「input」オブジェクトツリーに必須ノードと見なされる子ノードが含まれていない場合は、リクエストでクライアントからメッセージ本文を送信できます（MAY）。
If the "rpc" or "action" statement has no "input" section, the request message MUST NOT include a message-body.
「rpc」または「action」ステートメントに「input」セクションがない場合、要求メッセージにメッセージ本文を含めることはできません。
Examples:
例：
The following YANG module is used for the RPC operation examples in this section.
このセクションのRPC操作の例では、次のYANGモジュールを使用しています。
module example-ops {
namespace "https://example.com/ns/example-ops";
prefix "ops";
organization "Example, Inc.";
contact "support at example.com";
description "Example Operations Data Model Module.";
revision "2016-07-07" {
description "Initial version.";
reference "example.com document 3-3373.";
}
rpc reboot {
description "Reboot operation.";
input {
leaf delay {
type uint32;
units "seconds";
default 0;
description
"Number of seconds to wait before initiating the
reboot operation.";
}
leaf message {
type string;
description
"Log message to display when reboot is started.";
}
leaf language {
type string;
description "Language identifier string.";
reference "RFC 5646.";
}
}
}
rpc get-reboot-info {
description
"Retrieve parameters used in the last reboot operation.";
output {
leaf reboot-time {
type uint32;
description
"The 'delay' parameter used in the last reboot
operation.";
}
leaf message {
type string;
description
"The 'message' parameter used in the last reboot
operation.";
}
leaf language {
type string;
description
"The 'language' parameter used in the last reboot
operation.";
}
}
}
}
The following YANG module is used for the YANG action examples in this section.
このセクションのYANGアクションの例では、次のYANGモジュールが使用されています。
module example-actions {
yang-version 1.1;
namespace "https://example.com/ns/example-actions";
prefix "act";
import ietf-yang-types { prefix yang; }
organization "Example, Inc.";
contact "support at example.com";
description "Example Actions Data Model Module.";
revision "2016-07-07" {
description "Initial version.";
reference "example.com document 2-9973.";
}
container interfaces {
description "System interfaces.";
list interface {
key name;
description "One interface entry.";
leaf name {
type string;
description "Interface name.";
}
action reset {
description "Reset an interface.";
input {
leaf delay {
type uint32;
units "seconds";
default 0;
description
"Number of seconds to wait before starting the
interface reset.";
}
}
}
action get-last-reset-time {
description
"Retrieve the last interface reset time.";
output {
leaf last-reset {
type yang:date-and-time;
mandatory true;
description
"Date and time of the last interface reset, or
the last reboot time of the device.";
}
}
}
}
}
} RPC Input Example:
RPC入力の例：
The client might send the following POST request message to invoke the "reboot" RPC operation:
クライアントは次のPOST要求メッセージを送信して、「再起動」RPC操作を呼び出す場合があります。
POST /restconf/operations/example-ops:reboot HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<input xmlns="https://example.com/ns/example-ops">
<delay>600</delay>
<message>Going down for system maintenance</message>
<language>en-US</language>
</input>
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
The same example request message is shown here using JSON encoding:
ここでは、JSONエンコーディングを使用した同じリクエストメッセージの例を示します。
POST /restconf/operations/example-ops:reboot HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-ops:input" : {
"delay" : 600,
"message" : "Going down for system maintenance",
"language" : "en-US"
}
}
Action Input Example:
アクション入力の例：
The client might send the following POST request message to invoke the "reset" action:
クライアントは、次のPOSTリクエストメッセージを送信して「リセット」アクションを呼び出す場合があります。
POST /restconf/data/example-actions:interfaces/\
interface=eth0/reset HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<input xmlns="https://example.com/ns/example-actions">
<delay>600</delay>
</input>
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
The same example request message is shown here using JSON encoding:
ここでは、JSONエンコーディングを使用した同じリクエストメッセージの例を示します。
POST /restconf/data/example-actions:interfaces/\
interface=eth0/reset HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{ "example-actions:input" : {
"delay" : 600
}
}
If the "rpc" or "action" statement has an "output" section, then instances of these output parameters are encoded in the module namespace where the "rpc" or "action" statement is defined, in an XML element or JSON object named "output", which is in the module namespace where the "rpc" or "action" statement is defined.
「rpc」または「action」ステートメントに「output」セクションがある場合、これらの出力パラメーターのインスタンスは、「rpc」または「action」ステートメントが定義されているモジュール名前空間のXML要素またはJSONオブジェクト「出力」。これは、「rpc」または「アクション」ステートメントが定義されているモジュール名前空間にあります。
If the RPC operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section and the "output" object tree contains any child data nodes that are considered mandatory nodes, then a response message-body MUST be sent by the server in the response.
RPC操作がエラーなしで呼び出され、「rpc」または「action」ステートメントに「output」セクションがあり、「output」オブジェクトツリーに必須ノードと見なされる子データノードが含まれている場合、応答メッセージ本文応答でサーバーから送信する必要があります。
If the RPC operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section and the "output" object tree does not contain any child nodes that are considered mandatory nodes, then a response message-body MAY be sent by the server in the response.
RPC操作がエラーなしで呼び出され、「rpc」または「action」ステートメントに「output」セクションがあり、「output」オブジェクトツリーに必須ノードと見なされる子ノードが含まれていない場合、応答メッセージ-ボディはレスポンスでサーバーから送信される場合があります。
The request URI is not returned in the response. Knowledge of the request URI may be needed to associate the output with the specific "rpc" or "action" statement used in the request.
リクエストURIはレスポンスで返されません。リクエストで使用される特定の「rpc」または「action」ステートメントに出力を関連付けるには、リクエストURIの知識が必要になる場合があります。
Examples:
例：
RPC Output Example:
RPC出力の例：
The "example-ops" YANG module defined in Section 3.6.1 is used for this example.
この例では、セクション3.6.1で定義された「example-ops」YANGモジュールが使用されます。
The client might send the following POST request message to invoke the "get-reboot-info" operation:
クライアントは、次のPOSTリクエストメッセージを送信して、「get-reboot-info」操作を呼び出します。
POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"example-ops:output" : {
"reboot-time" : 30,
"message" : "Going down for system maintenance",
"language" : "en-US"
}
}
The same response is shown here using XML encoding:
ここでは、XMLエンコーディングを使用して同じ応答を示しています。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
<output xmlns="https://example.com/ns/example-ops">
<reboot-time>30</reboot-time>
<message>Going down for system maintenance</message>
<language>en-US</language>
</output>
Action Output Example:
アクション出力の例：
The "example-actions" YANG module defined in Section 3.6.1 is used for this example.
この例では、セクション3.6.1で定義されている「example-actions」YANGモジュールが使用されます。
The client might send the following POST request message to invoke the "get-last-reset-time" action:
クライアントは、次のPOSTリクエストメッセージを送信して、「get-last-reset-time」アクションを呼び出します。
POST /restconf/data/example-actions:interfaces/\
interface=eth0/get-last-reset-time HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"example-actions:output" : {
"last-reset" : "2015-10-10T02:14:11Z"
}
}
If any errors occur while attempting to invoke the operation or action, then an "errors" media type is returned with the appropriate error status.
操作またはアクションを呼び出そうとしたときにエラーが発生した場合、「エラー」メディアタイプが適切なエラーステータスとともに返されます。
If (1) the RPC operation input is not valid or (2) the RPC operation is invoked but errors occur, then a message-body containing an "errors" resource MUST be sent by the server, as defined in Section 3.9.
（1）RPC操作入力が無効であるか、（2）RPC操作が呼び出されたがエラーが発生した場合、3.9で定義されているように、「エラー」リソースを含むメッセージ本文をサーバーから送信する必要があります。
Using the "reboot" RPC operation from the example in Section 3.6.1, the client might send the following POST request message:
セクション3.6.1の例の「再起動」RPC操作を使用して、クライアントは次のPOSTリクエストメッセージを送信する場合があります。
POST /restconf/operations/example-ops:reboot HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<input xmlns="https://example.com/ns/example-ops">
<delay>-33</delay>
<message>Going down for system maintenance</message>
<language>en-US</language>
</input>
The server might respond with an "invalid-value" error:
サーバーが「無効な値」エラーで応答する場合があります。
HTTP/1.1 400 Bad Request
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>protocol</error-type>
<error-tag>invalid-value</error-tag>
<error-path xmlns:ops="https://example.com/ns/example-ops">
/ops:input/ops:delay
</error-path>
<error-message>Invalid input parameter</error-message>
</error>
</errors>
The same response is shown here using JSON encoding:
ここでは、JSONエンコードを使用して同じ応答を示しています。
HTTP/1.1 400 Bad Request
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{ "ietf-restconf:errors" : {
"error" : [
{
"error-type" : "protocol",
"error-tag" : "invalid-value",
"error-path" : "/example-ops:input/delay",
"error-message" : "Invalid input parameter"
}
]
}
}
The server can optionally support the retrieval of the YANG modules it uses. If retrieval is supported, then the "schema" leaf MUST be present in the associated "module" list entry, defined in [RFC7895].
サーバーは、オプションで、使用するYANGモジュールの取得をサポートできます。検索がサポートされている場合、「スキーマ」リーフは、[RFC7895]で定義されている、関連する「モジュール」リストエントリに存在している必要があります。
To retrieve a YANG module, a client first needs to get the URL for retrieving the schema, which is stored in the "schema" leaf. Note that there is no required structure for this URL. The URL value shown below is just an example.
YANGモジュールを取得するには、クライアントはまず、「スキーマ」リーフに格納されているスキーマを取得するためのURLを取得する必要があります。このURLに必要な構造はないことに注意してください。以下に示すURL値は一例です。
The client might send the following GET request message:
クライアントは次のGET要求メッセージを送信する場合があります。
GET /restconf/data/ietf-yang-library:modules-state/\
module=example-jukebox,2016-08-15/schema HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"ietf-yang-library:schema" :
"https://example.com/mymodules/example-jukebox/2016-08-15"
}
Next, the client needs to retrieve the actual YANG schema.
次に、クライアントは実際のYANGスキーマを取得する必要があります。
The client might send the following GET request message:
クライアントは次のGET要求メッセージを送信する場合があります。
GET https://example.com/mymodules/example-jukebox/\
2016-08-15 HTTP/1.1
Host: example.com
Accept: application/yang
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang
// entire YANG module contents deleted for this example...
//この例ではYANGモジュールの内容全体が削除されています...
An event stream resource represents a source for system-generated event notifications. Each stream is created and modified by the server only. A client can retrieve a stream resource or initiate a long-poll server-sent event stream [W3C.REC-eventsource-20150203], using the procedure specified in Section 6.3.
イベントストリームリソースは、システム生成のイベント通知のソースを表します。各ストリームはサーバーによってのみ作成および変更されます。クライアントは、セクション6.3で指定された手順を使用して、ストリームリソースを取得するか、サーバーから送信されるロングポーリングイベントストリームを開始できます[W3C.REC-eventsource-20150203]。
An event stream functions according to the "NETCONF Event Notifications" specification [RFC5277]. The available streams can be retrieved from the "stream" list, which specifies the syntax and semantics of the stream resources.
イベントストリームは、「NETCONFイベント通知」仕様[RFC5277]に従って機能します。使用可能なストリームは、ストリームリソースの構文とセマンティクスを指定する「ストリーム」リストから取得できます。
The "errors" YANG data template models a collection of error information that is sent as the message-body in a server response message if an error occurs while processing a request message. It is not considered as a resource type because no instances can be retrieved with a GET request.
「エラー」YANGデータテンプレートは、要求メッセージの処理中にエラーが発生した場合にサーバー応答メッセージのメッセージ本文として送信されるエラー情報のコレクションをモデル化します。 GETリクエストではインスタンスを取得できないため、リソースタイプとは見なされません。
The "ietf-restconf" YANG module contains the "yang-errors" YANG data template, which specifies the syntax and semantics of an "errors" container within a RESTCONF response. RESTCONF error-handling behavior is defined in Section 7.
「ietf-restconf」YANGモジュールには、「ヤンエラー」YANGデータテンプレートが含まれています。これは、RESTCONF応答内の「エラー」コンテナの構文とセマンティクスを指定します。 RESTCONFエラー処理動作は、セクション7で定義されています。
The RESTCONF protocol uses HTTP methods to identify the CRUD operations requested for a particular resource.
RESTCONFプロトコルは、HTTPメソッドを使用して、特定のリソースに対して要求されたCRUD操作を識別します。
The following table shows how the RESTCONF operations relate to NETCONF protocol operations.
次の表は、RESTCONF操作とNETCONFプロトコル操作の関係を示しています。
+----------+-------------------------------------------------------+
| RESTCONF | NETCONF |
+----------+-------------------------------------------------------+
| OPTIONS | none |
| | |
| HEAD | <get-config>, <get> |
| | |
| GET | <get-config>, <get> |
| | |
| POST | <edit-config> (nc:operation="create") |
| | |
| POST | invoke an RPC operation |
| | |
| PUT | <copy-config> (PUT on datastore) |
| | |
| PUT | <edit-config> (nc:operation="create/replace") |
| | |
| PATCH | <edit-config> (nc:operation depends on PATCH content) |
| | |
| DELETE | <edit-config> (nc:operation="delete") |
+----------+-------------------------------------------------------+
CRUD Methods in RESTCONF
RESTCONFのCRUDメソッド
The "remove" edit operation attribute for the NETCONF <edit-config> RPC operation is not supported by the HTTP DELETE method. The resource must exist or the DELETE method will fail. The PATCH method is equivalent to a "merge" edit operation when using a plain patch (see Section 4.6.1); other media types may provide more granular control.
NETCONF <edit-config> RPC操作の「削除」編集操作属性は、HTTP DELETEメソッドではサポートされていません。リソースが存在しないと、DELETEメソッドは失敗します。 PATCHメソッドは、プレーンパッチ（セクション4.6.1を参照）を使用する場合の「マージ」編集操作と同等です。他のメディアタイプは、より詳細な制御を提供する場合があります。
Access control mechanisms are used to limit what CRUD operations can be used. In particular, RESTCONF is compatible with the NETCONF Access Control Model (NACM) [RFC6536], as there is a specific mapping between RESTCONF and NETCONF operations. The resource path needs to be converted internally by the server to the corresponding YANG instance identifier. Using this information, the server can apply the NACM access control rules to RESTCONF messages.
アクセス制御メカニズムを使用して、使用できるCRUD操作を制限します。特に、RESTCONFとNETCONF操作の間には特定のマッピングがあるため、RESTCONFはNETCONF Access Control Model（NACM）[RFC6536]と互換性があります。リソースパスは、サーバーによって内部的に対応するYANGインスタンス識別子に変換される必要があります。この情報を使用して、サーバーはNACMアクセス制御規則をRESTCONFメッセージに適用できます。
The server MUST NOT allow any RESTCONF operation for any resources that the client is not authorized to access.
サーバーは、クライアントがアクセスを許可されていないリソースに対してRESTCONF操作を許可してはなりません（MUST NOT）。
The implementation of all methods (except PATCH [RFC5789]) is defined in [RFC7231]. This section defines the RESTCONF protocol usage for each HTTP method.
すべてのメソッドの実装（PATCH [RFC5789]を除く）は[RFC7231]で定義されています。このセクションでは、各HTTPメソッドのRESTCONFプロトコルの使用法を定義します。
The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource (e.g., GET, POST, DELETE). The server MUST implement this method.
OPTIONSメソッドは、特定のリソース（GET、POST、DELETEなど）に対してサーバーがサポートするメソッドを検出するためにクライアントによって送信されます。サーバーはこのメソッドを実装する必要があります。
The "Accept-Patch" header field MUST be supported and returned in the response to the OPTIONS request, as defined in [RFC5789].
[Accept-Patch]ヘッダーフィールドは、[RFC5789]で定義されているように、OPTIONS要求への応答でサポートおよび返される必要があります。
The RESTCONF server MUST support the HEAD method. The HEAD method is sent by the client to retrieve just the header fields (which contain the metadata for a resource) that would be returned for the comparable GET method, without the response message-body. It is supported for all resources that support the GET method.
RESTCONFサーバーはHEADメソッドをサポートする必要があります。 HEADメソッドはクライアントによって送信され、応答メッセージ本文なしで、比較可能なGETメソッドに対して返されるヘッダーフィールド（リソースのメタデータを含む）のみを取得します。 GETメソッドをサポートするすべてのリソースでサポートされます。
The request MUST contain a request URI that contains at least the root resource. The same query parameters supported by the GET method are supported by the HEAD method.
リクエストには、少なくともルートリソースを含むリクエストURIが含まれている必要があります。 GETメソッドでサポートされているものと同じクエリパラメータが、HEADメソッドでもサポートされています。
The access control behavior is enforced as if the method was GET instead of HEAD. The server MUST respond the same as if the method was GET instead of HEAD, except that no response message-body is included.
アクセス制御動作は、メソッドがHEADではなくGETであるかのように適用されます。サーバーは、応答メッセージ本文が含まれていないことを除いて、メソッドがHEADではなくGETである場合と同じように応答する必要があります。
The RESTCONF server MUST support the GET method. The GET method is sent by the client to retrieve data and metadata for a resource. It is supported for all resource types, except operation resources. The request MUST contain a request URI that contains at least the root resource.
RESTCONFサーバーはGETメソッドをサポートする必要があります。 GETメソッドは、リソースのデータとメタデータを取得するためにクライアントによって送信されます。操作リソースを除くすべてのリソースタイプでサポートされています。リクエストには、少なくともルートリソースを含むリクエストURIが含まれている必要があります。
The server MUST NOT return any data resources for which the user does not have read privileges. If the user is not authorized to read the target resource, an error response containing a "401 Unauthorized" status-line SHOULD be returned. The error-tag value "access-denied" is returned in this case. A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is returned in this case.
サーバーは、ユーザーが読み取り権限を持たないデータリソースを返してはなりません（MUST NOT）。ユーザーにターゲットリソースの読み取りが許可されていない場合は、「401 Unauthorized」ステータス行を含むエラー応答を返す必要があります（SHOULD）。この場合、エラータグ値「access-denied」が返されます。 [RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。この場合、エラータグ値「無効値」が返されます。
If the user is authorized to read some but not all of the target resource, the unauthorized content is omitted from the response message-body, and the authorized content is returned to the client.
ユーザーがターゲットリソースのすべてではなく一部を読み取ることを許可されている場合、不正なコンテンツが応答メッセージ本文から省略され、許可されたコンテンツがクライアントに返されます。
If any content is returned to the client, then the server MUST send a valid response message-body. More than one element MUST NOT be returned for XML encoding. If multiple elements are sent in a JSON message-body, then they MUST be sent as a JSON array. In this case, any timestamp or entity-tag returned in the response MUST be associated with the first element returned.
コンテンツがクライアントに返される場合、サーバーは有効な応答メッセージ本文を送信する必要があります。 XMLエンコーディングでは、複数の要素を返してはいけません。複数の要素がJSONメッセージ本文で送信される場合、それらはJSON配列として送信される必要があります。この場合、応答で返されたタイムスタンプまたはエンティティタグは、返された最初の要素に関連付けられている必要があります。
If a retrieval request for a data resource representing a YANG leaf-list or list object identifies more than one instance and XML encoding is used in the response, then an error response containing a "400 Bad Request" status-line MUST be returned by the server. The error-tag value "invalid-value" is used in this case. Note that a non-configuration list is not required to define any keys. In this case, the retrieval of a single list instance is not possible.
YANGリーフリストまたはリストオブジェクトを表すデータリソースの取得リクエストで複数のインスタンスが識別され、応答でXMLエンコーディングが使用されている場合、「400 Bad Request」ステータス行を含むエラー応答をサーバ。この場合、エラータグ値「無効値」が使用されます。キーを定義するために非構成リストは必要ないことに注意してください。この場合、単一のリストインスタンスを取得することはできません。
If a retrieval request for a data resource represents an instance that does not exist, then an error response containing a "404 Not Found" status-line MUST be returned by the server. The error-tag value "invalid-value" is used in this case.
データリソースの取得リクエストが存在しないインスタンスを表す場合、「404 Not Found」ステータス行を含むエラー応答がサーバーから返される必要があります。この場合、エラータグ値「無効値」が使用されます。
If the target resource of a retrieval request is for an operation resource, then a "405 Method Not Allowed" status-line MUST be returned by the server. The error-tag value "operation-not-supported" is used in this case.
検索要求のターゲットリソースが操作リソース用である場合、サーバーから「405メソッドは許可されていません」というステータス行が返される必要があります。この場合、エラータグ値「operation-not-supported」が使用されます。
Note that the way that access control is applied to data resources may not be completely compatible with HTTP caching. The "Last-Modified" and "ETag" header fields maintained for a data resource are not affected by changes to the access control rules for that data resource. It is possible for the representation of a data resource that is visible to a particular client to be changed without detection via the "Last-Modified" or "ETag" values.
アクセス制御がデータリソースに適用される方法は、HTTPキャッシングと完全に互換性がない場合があることに注意してください。データリソース用に維持されている "Last-Modified"および "ETag"ヘッダーフィールドは、そのデータリソースのアクセス制御ルールの変更による影響を受けません。特定のクライアントから見えるデータリソースの表現は、「Last-Modified」または「ETag」の値を介して検出されずに変更される可能性があります。
Example:
例：
The client might request the response header fields for an XML representation of a specific "album" resource:
クライアントは、特定の「アルバム」リソースのXML表現の応答ヘッダーフィールドを要求する場合があります。
GET /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
Cache-Control: no-cache
ETag: "a74eefc993a2b"
Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT
<album xmlns="http://example.com/ns/example-jukebox"
xmlns:jbox="http://example.com/ns/example-jukebox">
<name>Wasting Light</name>
<genre>jbox:alternative</genre>
<year>2011</year>
</album>
Refer to Appendix B.1 for more resource retrieval examples.
その他のリソース取得の例については、付録B.1を参照してください。
The RESTCONF server MUST support the POST method. The POST method is sent by the client to create a data resource or invoke an operation resource. The server uses the target resource type to determine how to process the request.
RESTCONFサーバーはPOSTメソッドをサポートする必要があります。 POSTメソッドは、クライアントによって送信され、データリソースを作成するか、操作リソースを呼び出します。サーバーは、ターゲットリソースタイプを使用して、リクエストの処理方法を決定します。
+-----------+------------------------------------------------+
| Type | Description |
+-----------+------------------------------------------------+
| Datastore | Create a top-level configuration data resource |
| Data | Create a configuration data child resource |
| Operation | Invoke an RPC operation |
+-----------+------------------------------------------------+
Resource Types That Support POST
POSTをサポートするリソースタイプ
If the target resource type is a datastore or data resource, then the POST is treated as a request to create a top-level resource or child resource, respectively. The message-body is expected to contain the content of a child resource to create within the parent (target resource). The message-body MUST contain exactly one instance of the expected data resource. The data model for the child tree is the subtree, as defined by YANG for the child resource.
ターゲットリソースタイプがデータストアまたはデータリソースの場合、POSTはそれぞれトップレベルリソースまたは子リソースを作成するリクエストとして扱われます。メッセージ本文には、親（ターゲットリソース）内に作成する子リソースのコンテンツが含まれている必要があります。メッセージ本文には、予期されるデータリソースのインスタンスを1つだけ含める必要があります。子リソースのYANGで定義されているように、子ツリーのデータモデルはサブツリーです。
The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the POST method for datastore and data resources. These parameters are only allowed if the list or leaf-list is "ordered-by user".
「挿入」（セクション4.8.5）および「ポイント」（セクション4.8.6）クエリパラメータは、データストアおよびデータリソースのPOSTメソッドでサポートされている必要があります。これらのパラメーターは、リストまたはリーフリストが「ordered-by user」の場合にのみ許可されます。
If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body. A "Location" header field identifying the child resource that was created MUST be present in the response in this case.
POSTメソッドが成功すると、「201 Created」ステータス行が返され、応答メッセージ本文はありません。この場合、作成された子リソースを識別する「Location」ヘッダーフィールドが応答に存在する必要があります。
If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case.
データリソースがすでに存在する場合、POSTリクエストは失敗し、「409 Conflict」ステータス行が返される必要があります。この場合、エラータグ値「resource-denied」が使用されます。
If the user is not authorized to create the target resource, an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case. A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in Section 7.
ユーザーにターゲットリソースの作成が許可されていない場合は、「403 Forbidden」ステータス行を含むエラー応答を返す必要があります（SHOULD）。この場合、エラータグ値「access-denied」が使用されます。 [RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。この場合、エラータグ値「無効値」が使用されます。他のすべてのエラー応答は、セクション7で定義された手順に従って処理されます。
Example:
例：
To create a new "jukebox" resource, the client might send the following:
新しい「ジュークボックス」リソースを作成するために、クライアントは以下を送信する場合があります。
POST /restconf/data HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{ "example-jukebox:jukebox" : {} }
If the resource is created, the server might respond as follows:
リソースが作成されると、サーバーは次のように応答する場合があります。
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Location: https://example.com/restconf/data/\
example-jukebox:jukebox
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b3a3e673be2"
Refer to Appendix B.2.1 for more resource creation examples.
リソース作成の例については、付録B.2.1を参照してください。
If the target resource type is an operation resource, then the POST method is treated as a request to invoke that operation. The message-body (if any) is processed as the operation input parameters. Refer to Section 3.6 for details on operation resources.
ターゲットリソースタイプがオペレーションリソースの場合、POSTメソッドはそのオペレーションを呼び出すリクエストとして扱われます。メッセージ本文（存在する場合）は、操作入力パラメーターとして処理されます。運用リソースの詳細については、3.6項を参照してください。
If the POST request succeeds, a "200 OK" status-line is returned if there is a response message-body, and a "204 No Content" status-line is returned if there is no response message-body.
POSTリクエストが成功すると、応答メッセージ本文がある場合は「200 OK」ステータス行が返され、応答メッセージ本文がない場合は「204 No Content」ステータス行が返されます。
If the user is not authorized to invoke the target operation, an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case. A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. All other error responses are handled according to the procedures defined in Section 7.
ユーザーにターゲット操作の呼び出しが許可されていない場合、「403 Forbidden」ステータス行を含むエラー応答が返されるべきです（SHOULD）。この場合、エラータグ値「access-denied」が使用されます。 [RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。他のすべてのエラー応答は、セクション7で定義された手順に従って処理されます。
Example:
例：
In this example, the client is invoking the "play" operation defined in the "example-jukebox" YANG module.
この例では、クライアントは「example-jukebox」YANGモジュールで定義された「play」操作を呼び出しています。
A client might send a "play" request as follows:
クライアントは、次のように「再生」リクエストを送信します。
POST /restconf/operations/example-jukebox:play HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:input" : {
"playlist" : "Foo-One",
"song-number" : 2
}
}
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
The RESTCONF server MUST support the PUT method. The PUT method is sent by the client to create or replace the target data resource. A request message-body MUST be present, representing the new data resource, or the server MUST return a "400 Bad Request" status-line. The error-tag value "invalid-value" is used in this case.
RESTCONFサーバーはPUTメソッドをサポートする必要があります。 PUTメソッドは、ターゲットデータリソースを作成または置換するためにクライアントによって送信されます。新しいデータリソースを表す要求メッセージ本文が存在する必要があります。そうでない場合、サーバーは「400 Bad Request」ステータス行を返す必要があります。この場合、エラータグ値「無効値」が使用されます。
Both the POST and PUT methods can be used to create data resources. The difference is that for POST, the client does not provide the resource identifier for the resource that will be created. The target resource for the POST method for resource creation is the parent of the new resource. The target resource for the PUT method for resource creation is the new resource.
POSTメソッドとPUTメソッドの両方を使用して、データリソースを作成できます。違いは、POSTの場合、クライアントは作成されるリソースのリソース識別子を提供しないことです。リソース作成のPOSTメソッドのターゲットリソースは、新しいリソースの親です。リソース作成のPUTメソッドのターゲットリソースは、新しいリソースです。
The PUT method MUST be supported for data and datastore resources. A PUT on the datastore resource is used to replace the entire contents of the datastore. A PUT on a data resource only replaces that data resource within the datastore.
PUTメソッドは、データおよびデータストアリソースでサポートされている必要があります。データストアリソースのPUTは、データストアのコンテンツ全体を置き換えるために使用されます。データリソースのPUTは、データストア内のそのデータリソースのみを置き換えます。
The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the list or leaf-list is "ordered-by user".
「挿入」（セクション4.8.5）および「ポイント」（セクション4.8.6）クエリパラメータは、データリソースのPUTメソッドでサポートされている必要があります。これらのパラメーターは、リストまたはリーフリストが「ordered-by user」の場合にのみ許可されます。
Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned.
[RFC7231]と一致して、PUTリクエストが新しいリソースを作成すると、「201 Created」ステータス行が返されます。既存のリソースが変更されると、「204 No Content」ステータス行が返されます。
If the user is not authorized to create or replace the target resource, an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is used in this case.
ユーザーがターゲットリソースの作成または置換を許可されていない場合、「403 Forbidden」ステータス行を含むエラー応答が返されるべきです（SHOULD）。この場合、エラータグ値「access-denied」が使用されます。
A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in Section 7.
[RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。この場合、エラータグ値「無効値」が使用されます。他のすべてのエラー応答は、セクション7で定義された手順に従って処理されます。
If the target resource represents a YANG leaf-list, then the PUT method MUST NOT change the value of the leaf-list instance.
ターゲットリソースがYANGリーフリストを表す場合、PUTメソッドはリーフリストインスタンスの値を変更してはなりません（MUST NOT）。
If the target resource represents a YANG list instance, then the key leaf values, in message-body representation, MUST be the same as the key leaf values in the request URI. The PUT method MUST NOT be used to change the key leaf values for a data resource instance.
ターゲットリソースがYANGリストインスタンスを表す場合、メッセージ本文表現のキーリーフ値は、リクエストURIのキーリーフ値と同じである必要があります。 PUTメソッドは、データリソースインスタンスのキーリーフ値を変更するために使用してはなりません（MUST NOT）。
Example:
例：
An "album" child resource defined in the "example-jukebox" YANG module is replaced, or it is created if it does not already exist.
「example-jukebox」YANGモジュールで定義された「アルバム」子リソースは置き換えられるか、まだ存在しない場合は作成されます。
To replace the "album" resource contents, the client might send the following:
「アルバム」リソースのコンテンツを置き換えるために、クライアントは以下を送信する場合があります。
PUT /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:album" : [
{
"name" : "Wasting Light",
"genre" : "example-jukebox:alternative",
"year" : 2011
}
]
}
If the resource is updated, the server might respond as follows:
リソースが更新されると、サーバーは次のように応答する場合があります。
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b27480aeda4c"
The same request is shown here using XML encoding:
ここでは、XMLエンコーディングを使用して同じリクエストを示しています。
PUT /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox"
xmlns:jbox="http://example.com/ns/example-jukebox">
<name>Wasting Light</name>
<genre>jbox:alternative</genre>
<year>2011</year>
</album>
Refer to Appendix B.2.4 for an example using the PUT method to replace the contents of the datastore resource.
PUTメソッドを使用してデータストアリソースのコンテンツを置き換える例については、付録B.2.4を参照してください。
The RESTCONF server MUST support the PATCH method for a plain patch and MAY support additional media types. The media types for the PATCH method supported by the server can be discovered by the client by sending an OPTIONS request and examining the "Accept-Patch" header field in the response (see Section 4.1).
RESTCONFサーバーはプレーンパッチのPATCHメソッドをサポートする必要があり、追加のメディアタイプをサポートする場合があります（MAY）。サーバーがサポートするPATCHメソッドのメディアタイプは、OPTIONSリクエストを送信し、応答の「Accept-Patch」ヘッダーフィールドを調べることでクライアントが検出できます（セクション4.1を参照）。
RESTCONF uses the HTTP PATCH method defined in [RFC5789] to provide an extensible framework for resource patching mechanisms. Each patch mechanism needs a unique media type.
RESTCONFは、[RFC5789]で定義されたHTTP PATCHメソッドを使用して、リソースパッチメカニズムに拡張可能なフレームワークを提供します。各パッチメカニズムには、一意のメディアタイプが必要です。
This document defines one patch mechanism (Section 4.6.1). Another patch mechanism, the YANG Patch mechanism, is defined in [YANG-Patch]. Other patch mechanisms may be defined by future specifications.
このドキュメントでは、1つのパッチメカニズムを定義しています（セクション4.6.1）。別のパッチメカニズムであるYANGパッチメカニズムは、[YANG-Patch]で定義されています。その他のパッチメカニズムは、将来の仕様で定義される可能性があります。
If the target resource instance does not exist, the server MUST NOT create it.
ターゲットリソースインスタンスが存在しない場合、サーバーはそれを作成してはなりません（MUST NOT）。
If the PATCH request succeeds, a "200 OK" status-line is returned if there is a message-body, and "204 No Content" is returned if no response message-body is sent.
PATCHリクエストが成功した場合、メッセージ本文がある場合は「200 OK」ステータス行が返され、応答メッセージ本文が送信されない場合は「204 No Content」が返されます。
If the user is not authorized to alter the target resource, an error response containing a "403 Forbidden" status-line SHOULD be returned. A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is used in this case. All other error responses are handled according to the procedures defined in Section 7.
ユーザーにターゲットリソースの変更が許可されていない場合は、「403 Forbidden」ステータス行を含むエラー応答を返す必要があります（SHOULD）。 [RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。この場合、エラータグ値「無効値」が使用されます。他のすべてのエラー応答は、セクション7で定義された手順に従って処理されます。
The plain patch mechanism merges the contents of the message-body with the target resource. The message-body for a plain patch MUST be present and MUST be represented by the media type "application/yang-data+xml" or "application/yang-data+json".
プレーンパッチメカニズムは、メッセージ本文のコンテンツをターゲットリソースとマージします。プレーンパッチのメッセージボディが存在しなければならず、メディアタイプ「application / yang-data + xml」または「application / yang-data + json」で表される必要があります。
Plain patch can be used to create or update, but not delete, a child resource within the target resource. Please see [YANG-Patch] for an alternate media type supporting the ability to delete child resources. The YANG Patch media type allows multiple suboperations (e.g., "merge", "delete") within a single PATCH method.
プレーンパッチは、ターゲットリソース内の子リソースを作成または更新するために使用できますが、削除することはできません。子リソースを削除する機能をサポートする代替メディアタイプについては、[YANG-Patch]をご覧ください。 YANGパッチメディアタイプでは、単一のPATCHメソッド内で複数のサブオペレーション（「マージ」、「削除」など）が可能です。
If the target resource represents a YANG leaf-list, then the PATCH method MUST NOT change the value of the leaf-list instance.
ターゲットリソースがYANGリーフリストを表す場合、PATCHメソッドはリーフリストインスタンスの値を変更してはなりません（MUST NOT）。
If the target resource represents a YANG list instance, then the key leaf values, in message-body representation, MUST be the same as the key leaf values in the request URI. The PATCH method MUST NOT be used to change the key leaf values for a data resource instance.
ターゲットリソースがYANGリストインスタンスを表す場合、メッセージ本文表現のキーリーフ値は、リクエストURIのキーリーフ値と同じである必要があります。 PATCHメソッドは、データリソースインスタンスのキーリーフ値を変更するために使用してはなりません（MUST NOT）。
After the plain patch is processed by the server, a response will be returned to the client, as specified in Section 4.6.
After the plain patch is processed by the server, a response will be returned to the client, as specified in Section 4.6.
Example:
例：
To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows:
「リソース」全体をPUTメソッドで置き換える代わりに、「アルバム」リソースの「年」フィールドのみを置き換えるには、クライアントが次のようにプレーンパッチを送信します。
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If-Match: "b8389233a4c"
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox">
<year>2011</year>
</album>
If the field is updated, the server might respond as follows:
If the field is updated, the server might respond as follows:
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b2788923da4c"
The RESTCONF server MUST support the DELETE method. The DELETE method is used to delete the target resource. If the DELETE request succeeds, a "204 No Content" status-line is returned.
RESTCONFサーバーはDELETEメソッドをサポートする必要があります。 DELETEメソッドは、ターゲットリソースを削除するために使用されます。 DELETE要求が成功すると、「204 No Content」ステータス行が返されます。
If the user is not authorized to delete the target resource, then an error response containing a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied" is returned in this case. A server MAY return a "404 Not Found" status-line, as described in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is returned in this case. All other error responses are handled according to the procedures defined in Section 7.
ユーザーにターゲットリソースの削除が許可されていない場合は、「403 Forbidden」ステータス行を含むエラー応答を返す必要があります（SHOULD）。この場合、エラータグ値「access-denied」が返されます。 [RFC7231]のセクション6.5.4で説明されているように、サーバーは「404 Not Found」ステータス行を返す場合があります。この場合、エラータグ値「無効値」が返されます。他のすべてのエラー応答は、セクション7で定義された手順に従って処理されます。
If the target resource represents a configuration leaf-list or list data node, then it MUST represent a single YANG leaf-list or list instance. The server MUST NOT use the DELETE method to delete more than one such instance.
ターゲットリソースが構成リーフリストまたはリストデータノードを表す場合、単一のYANGリーフリストまたはリストインスタンスを表す必要があります。サーバーは、そのような複数のインスタンスを削除するためにDELETEメソッドを使用してはなりません（MUST NOT）。
Example:
例：
To delete the "album" resource with the key "Wasting Light", the client might send the following:
キーが「Wasting Light」の「アルバム」リソースを削除するために、クライアントは以下を送信する場合があります。
DELETE /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If the resource is deleted, the server might respond as follows:
リソースが削除されると、サーバーは次のように応答する場合があります。
HTTP/1.1 204 No Content
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Each RESTCONF operation allows zero or more query parameters to be present in the request URI. Which specific parameters are allowed will depend on the resource type, and sometimes the specific target resource used, in the request.
各RESTCONF操作では、0個以上のクエリパラメータをリクエストURIに含めることができます。どの特定のパラメーターが許可されるかは、リソースタイプ、およびリクエストで使用される特定のターゲットリソースによって異なります。
o Query parameters can be given in any order.
o クエリパラメータは任意の順序で指定できます。
o Each parameter can appear at most once in a request URI.
o 各パラメーターは、リクエストURIに最大1回出現できます。
o If more than one instance of a query parameter is present, then a "400 Bad Request" status-line MUST be returned by the server. The error-tag value "invalid-value" is returned in this case.
o クエリパラメータのインスタンスが複数存在する場合は、サーバーから「400 Bad Request」ステータス行が返される必要があります。この場合、エラータグ値「無効値」が返されます。
o A default value may apply if the parameter is missing.
o パラメータがない場合は、デフォルト値が適用される場合があります。
o Query parameter names and values are case sensitive.
o クエリパラメータの名前と値では、大文字と小文字が区別されます。
o A server MUST return an error with a "400 Bad Request" status-line if a query parameter is unexpected. The error-tag value "invalid-value" is returned in this case.
o クエリパラメータが予期しないものである場合、サーバーは "400 Bad Request"ステータス行でエラーを返さなければなりません。この場合、エラータグ値「無効値」が返されます。
+---------------+---------+-----------------------------------------+
| Name | Methods | Description |
+---------------+---------+-----------------------------------------+
| content | GET, | Select config and/or non-config data |
| | HEAD | resources |
| | | |
| depth | GET, | Request limited subtree depth in the |
| | HEAD | reply content |
| | | |
| fields | GET, | Request a subset of the target resource |
| | HEAD | contents |
| | | |
| filter | GET, | Boolean notification filter for event |
| | HEAD | stream resources |
| | | |
| insert | POST, | Insertion mode for "ordered-by user" |
| | PUT | data resources |
| | | |
| point | POST, | Insertion point for "ordered-by user" |
| | PUT | data resources |
| | | |
| start-time | GET, | Replay buffer start time for event |
| | HEAD | stream resources |
| | | |
| stop-time | GET, | Replay buffer stop time for event |
| | HEAD | stream resources |
| | | |
| with-defaults | GET, | Control the retrieval of default values |
| | HEAD | |
+---------------+---------+-----------------------------------------+
RESTCONF Query Parameters
RESTCONFクエリパラメータ
Refer to Appendix B.3 for examples of query parameter usage.
クエリパラメータの使用例については、付録B.3を参照してください。
If vendors define additional query parameters, they SHOULD use a prefix (such as the enterprise or organization name) for query parameter names in order to avoid collisions with other parameters.
ベンダーが追加のクエリパラメータを定義する場合、他のパラメータとの衝突を回避するために、クエリパラメータ名にプレフィックス（エンタープライズ名や組織名など）を使用する必要があります（SHOULD）。
The "content" query parameter controls how descendant nodes of the requested data nodes will be processed in the reply.
The "content" query parameter controls how descendant nodes of the requested data nodes will be processed in the reply.
The allowed values are:
許可される値は次のとおりです。
+-----------+-----------------------------------------------------+
| Value | Description |
+-----------+-----------------------------------------------------+
| config | Return only configuration descendant data nodes |
| | |
| nonconfig | Return only non-configuration descendant data nodes |
| | |
| all | Return all descendant data nodes |
+-----------+-----------------------------------------------------+
This parameter is only allowed for GET methods on datastore and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types.
このパラメーターは、データストアおよびデータリソースのGETメソッドでのみ許可されます。他のメソッドまたはリソースタイプに使用すると、「400 Bad Request」ステータス行が返されます。
If this query parameter is not present, the default value is "all". This query parameter MUST be supported by the server.
このクエリパラメータが存在しない場合、デフォルト値は「all」です。このクエリパラメータは、サーバーでサポートされている必要があります。
The "depth" query parameter is used to limit the depth of subtrees returned by the server. Data nodes with a "depth" value greater than the "depth" parameter are not returned in a response for a GET method.
「深さ」クエリパラメータは、サーバーから返されるサブツリーの深さを制限するために使用されます。 「depth」パラメーターより大きい「depth」値を持つデータノードは、GETメソッドの応答で返されません。
The requested data node has a depth level of "1". If the "fields" parameter (Section 4.8.3) is used to select descendant data nodes, then these nodes and all of their ancestor nodes have a "depth" value of "1". (This has the effect of including the nodes specified by the fields, even if the "depth" value is less than the actual depth level of the specified fields.) Any other child node has a "depth" value that is 1 greater than its parent.
要求されたデータノードの深度レベルは「1」です。 「フィールド」パラメーター（セクション4.8.3）を使用して子孫データノードを選択すると、これらのノードとそのすべての祖先ノードの「深度」値が「1」になります。 （これには、「深さ」の値が指定されたフィールドの実際の深さレベルよりも小さい場合でも、フィールドで指定されたノードを含める効果があります。）他の子ノードの「深さ」の値は、その1よりも大きい親。
The value of the "depth" parameter is either an integer between 1 and 65535 or the string "unbounded". "unbounded" is the default.
「深さ」パラメータの値は、1〜65535の整数または文字列「無制限」のいずれかです。 「無制限」がデフォルトです。
This parameter is only allowed for GET methods on API, datastore, and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types.
This parameter is only allowed for GET methods on API, datastore, and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types.
By default, the server will include all sub-resources within a retrieved resource that have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved, then by default the datastore and all child data resources are returned.
デフォルトでは、サーバーは、要求されたリソースと同じリソースタイプを持つ、取得されたリソース内のすべてのサブリソースを含めます。例外はデータストアリソースです。このリソースタイプが取得されると、デフォルトでデータストアとすべての子データリソースが返されます。
If the "depth" query parameter URI is listed in the "capability" leaf-list defined in Section 9.3, then the server supports the "depth" query parameter.
If the "depth" query parameter URI is listed in the "capability" leaf-list defined in Section 9.3, then the server supports the "depth" query parameter.
The "fields" query parameter is used to optionally identify data nodes within the target resource to be retrieved in a GET method. The client can use this parameter to retrieve a subset of all nodes in a resource.
「フィールド」クエリパラメータは、GETメソッドで取得するターゲットリソース内のデータノードをオプションで識別するために使用されます。クライアントはこのパラメーターを使用して、リソース内のすべてのノードのサブセットを取得できます。
The server will return a message-body representing the target resource, with descendant nodes pruned as specified in the "fields-expr" value. The server does not return a set of separate sub-resources.
サーバーは、「fields-expr」値で指定されたように子孫ノードがプルーニングされた、ターゲットリソースを表すメッセージ本文を返します。サーバーは、一連の個別のサブリソースを返しません。
A value of the "fields" query parameter matches the following rule:
「fields」クエリパラメータの値は、次のルールに一致します。
fields-expr = path "(" fields-expr ")" / path ";" fields-expr / path
path = api-identifier [ "/" path ]
"api-identifier" is defined in Section 3.5.3.1.
「api-identifier」はセクション3.5.3.1で定義されています。
";" is used to select multiple nodes. For example, to retrieve only the "genre" and "year" of an album, use "fields=genre;year".
「;」複数のノードを選択するために使用されます。たとえば、アルバムの「ジャンル」と「年」のみを取得するには、「fields = genre; year」を使用します。
Parentheses are used to specify sub-selectors of a node. Note that there is no path separator character "/" between a "path" field and a left parenthesis character "(".
括弧は、ノードのサブセレクターを指定するために使用されます。 「パス」フィールドと左括弧文字「（」の間にはパス区切り文字「/」がないことに注意してください。
For example, assume that the target resource is the "album" list. To retrieve only the "label" and "catalogue-number" of the "admin" container within an album, use "fields=admin(label;catalogue-number)".
For example, assume that the target resource is the "album" list. To retrieve only the "label" and "catalogue-number" of the "admin" container within an album, use "fields=admin(label;catalogue-number)".
"/" is used in a path to retrieve a child node of a node. For example, to retrieve only the "label" of an album, use "fields=admin/label".
「/」は、ノードの子ノードを取得するためのパスで使用されます。たとえば、アルバムの「ラベル」のみを取得するには、「fields = admin / label」を使用します。
This parameter is only allowed for GET methods on API, datastore, and data resources. A "400 Bad Request" status-line is returned if used for other methods or resource types.
このパラメーターは、API、データストア、およびデータリソースのGETメソッドでのみ許可されます。他のメソッドまたはリソースタイプに使用すると、「400 Bad Request」ステータス行が返されます。
If the "fields" query parameter URI is listed in the "capability" leaf-list defined in Section 9.3, then the server supports the "fields" parameter.
「フィールド」クエリパラメータURIがセクション9.3で定義された「機能」リーフリストにリストされている場合、サーバーは「フィールド」パラメータをサポートしています。
The "filter" query parameter is used to indicate which subset of all possible events is of interest. If not present, all events not precluded by other parameters will be sent.
「filter」クエリパラメータは、考えられるすべてのイベントのどのサブセットが対象であるかを示すために使用されます。存在しない場合、他のパラメーターによって排除されないすべてのイベントが送信されます。
This parameter is only allowed for GET methods on an event stream resource. A "400 Bad Request" status-line is returned if used for other methods or resource types.
このパラメーターは、イベントストリームリソースのGETメソッドでのみ許可されます。他のメソッドまたはリソースタイプに使用すると、「400 Bad Request」ステータス行が返されます。
The format of this parameter is an XPath 1.0 expression [XPath] and is evaluated in the following context:
このパラメーターの形式はXPath 1.0式[XPath]であり、次のコンテキストで評価されます。
o The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name and the namespace is as defined by the "namespace" statement in the YANG module.
o The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name and the namespace is as defined by the "namespace" statement in the YANG module.
o The function library is the core function library defined in XPath 1.0, plus any functions defined by the data model.
o 関数ライブラリは、XPath 1.0で定義されたコア関数ライブラリと、データモデルで定義された関数です。
o The set of variable bindings is empty.
o 変数バインディングのセットが空です。
o The context node is the root node.
o コンテキストノードはルートノードです。
The "filter" query parameter is used as defined in Section 3.6 of [RFC5277]. If the boolean result of the expression is "true" when applied to the conceptual "notification" document root, then the event notification is delivered to the client.
[filter]クエリパラメータは、[RFC5277]のセクション3.6で定義されているとおりに使用されます。概念的な「通知」ドキュメントルートに適用されたときに式のブール結果が「true」の場合、イベント通知はクライアントに配信されます。
If the "filter" query parameter URI is listed in the "capability" leaf-list defined in Section 9.3, then the server supports the "filter" query parameter.
「filter」クエリパラメータURIがセクション9.3で定義された「capability」リーフリストにリストされている場合、サーバーは「filter」クエリパラメータをサポートしています。
The "insert" query parameter is used to specify how a resource should be inserted within an "ordered-by user" list.
「挿入」クエリパラメータは、「ordered-byユーザー」リスト内にリソースを挿入する方法を指定するために使用されます。
The allowed values are:
許可される値は次のとおりです。
+--------+----------------------------------------------------------+
| Value | Description |
+--------+----------------------------------------------------------+
| first | Insert the new data as the new first entry. |
| | |
| last | Insert the new data as the new last entry. |
| | |
| before | Insert the new data before the insertion point, as |
| | specified by the value of the "point" parameter. |
| | |
| after | Insert the new data after the insertion point, as |
| | specified by the value of the "point" parameter. |
+--------+----------------------------------------------------------+
The default value is "last".
デフォルト値は「最後」です。
This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is "ordered-by user".
このパラメーターは、POSTおよびPUTメソッドでのみサポートされます。また、ターゲットリソースがデータリソースであり、そのデータが「ordered-by user」であるYANGリストまたはリーフリストを表す場合にのみサポートされます。
If the values "before" or "after" are used, then a "point" query parameter for the "insert" query parameter MUST also be present, or a "400 Bad Request" status-line is returned.
「before」または「after」の値を使用する場合、「insert」クエリパラメータの「point」クエリパラメータも存在する必要があります。存在しない場合は、「400 Bad Request」ステータス行が返されます。
The "insert" query parameter MUST be supported by the server.
「挿入」クエリパラメータは、サーバーでサポートされている必要があります。
The "point" query parameter is used to specify the insertion point for a data resource that is being created or moved within an "ordered-by user" list or leaf-list.
「point」クエリパラメータは、「ordered-by user」リストまたはリーフリスト内で作成または移動されるデータリソースの挿入ポイントを指定するために使用されます。
The value of the "point" parameter is a string that identifies the path to the insertion point object. The format is the same as a target resource URI string.
「point」パラメータの値は、挿入ポイントオブジェクトへのパスを識別する文字列です。形式は、ターゲットリソースURI文字列と同じです。
This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is "ordered-by user".
このパラメーターは、POSTおよびPUTメソッドでのみサポートされます。また、ターゲットリソースがデータリソースであり、そのデータが「ordered-by user」であるYANGリストまたはリーフリストを表す場合にのみサポートされます。
If the "insert" query parameter is not present or has a value other than "before" or "after", then a "400 Bad Request" status-line is returned.
「挿入」クエリパラメータが存在しないか、「前」または「後」以外の値がある場合、「400 Bad Request」ステータス行が返されます。
This parameter contains the instance identifier of the resource to be used as the insertion point for a POST or PUT method.
このパラメーターには、POSTまたはPUTメソッドの挿入ポイントとして使用されるリソースのインスタンスIDが含まれています。
The "point" query parameter MUST be supported by the server.
「ポイント」クエリパラメータは、サーバーでサポートされている必要があります。
The "start-time" query parameter is used to trigger the notification replay feature defined in [RFC5277] and indicate that the replay should start at the time specified. If the stream does not support replay per the "replay-support" attribute returned by the "stream" list entry for the stream resource, then the server MUST return a "400 Bad Request" status-line.
「start-time」クエリパラメータは、[RFC5277]で定義されている通知再生機能をトリガーし、指定された時間に再生を開始する必要があることを示すために使用されます。ストリームが、ストリームリソースの「ストリーム」リストエントリによって返される「replay-support」属性による再生をサポートしない場合、サーバーは「400 Bad Request」ステータス行を返さなければなりません（MUST）。
The value of the "start-time" parameter is of type "date-and-time", defined in the "ietf-yang-types" YANG module [RFC6991].
「start-time」パラメータの値は、「ietf-yang-types」YANGモジュール[RFC6991]で定義されている「日時」タイプです。
This parameter is only allowed for GET methods on a "text/event-stream" data resource. A "400 Bad Request" status-line is returned if used for other methods or resource types.
このパラメーターは、「text / event-stream」データリソースのGETメソッドでのみ許可されます。他のメソッドまたはリソースタイプに使用すると、「400 Bad Request」ステータス行が返されます。
If this parameter is not present, then a replay subscription is not being requested. It is not valid to specify start times that are later than the current time. If the value specified is earlier than the log can support, the replay will begin with the earliest available notification. A client can obtain a server's current time by examining the "Date" header field that the server returns in response messages, according to [RFC7231].
このパラメーターが存在しない場合、再生サブスクリプションは要求されていません。現在時刻より後の開始時刻を指定することはできません。指定された値がログがサポートできるよりも早い場合、再生は利用可能な最も早い通知から始まります。 [RFC7231]によれば、クライアントがサーバーが応答メッセージで返す「Date」ヘッダーフィールドを調べることで、サーバーの現在の時刻を取得できます。
If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list defined in Section 9.3, and the "stop-time" query parameter MUST also be supported by the server.
このクエリパラメータがサーバーでサポートされている場合は、「再生」クエリパラメータURIがセクション9.3で定義されている「機能」リーフリストにリストされている必要があり、「stop-time」クエリパラメータもサーバーでサポートされている必要があります。 。
If the "replay-support" leaf has the value "true" in the "stream" entry (defined in Section 9.3), then the server MUST support the "start-time" and "stop-time" query parameters for that stream.
「replay-support」リーフの「ストリーム」エントリ（9.3で定義）の値が「true」の場合、サーバーはそのストリームの「start-time」および「stop-time」クエリパラメータをサポートする必要があります。
The "stop-time" query parameter is used with the replay feature to indicate the newest notifications of interest. This parameter MUST be used with, and have a value later than, the "start-time" parameter.
「stop-time」クエリパラメータは再生機能で使用され、関心のある最新の通知を示します。このパラメーターは、「start-time」パラメーターと一緒に使用する必要があり、「start-time」パラメーターよりも後の値にする必要があります。
The value of the "stop-time" parameter is of type "date-and-time", defined in the "ietf-yang-types" YANG module [RFC6991].
「stop-time」パラメータの値は、「ietf-yang-types」YANGモジュール[RFC6991]で定義されている「date-and-time」タイプです。
This parameter is only allowed for GET methods on a "text/event-stream" data resource. A "400 Bad Request" status-line is returned if used for other methods or resource types.
このパラメーターは、「text / event-stream」データリソースのGETメソッドでのみ許可されます。他のメソッドまたはリソースタイプに使用すると、「400 Bad Request」ステータス行が返されます。
If this parameter is not present, the notifications will continue until the subscription is terminated. Values in the future are valid.
このパラメーターが存在しない場合、通知はサブスクリプションが終了するまで続きます。将来の値は有効です。
If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list defined in Section 9.3, and the "start-time" query parameter MUST also be supported by the server.
このクエリパラメータがサーバーでサポートされている場合、「再生」クエリパラメータURIは、セクション9.3で定義されている「機能」リーフリストにリストされている必要があり、「開始時間」クエリパラメータもサーバーでサポートされている必要があります。 。
If the "replay-support" leaf is present in the "stream" entry (defined in Section 9.3), then the server MUST support the "start-time" and "stop-time" query parameters for that stream.
「replay-support」リーフが「ストリーム」エントリ（9.3で定義）に存在する場合、サーバーはそのストリームの「start-time」および「stop-time」クエリパラメータをサポートする必要があります。
The "with-defaults" query parameter is used to specify how information about default data nodes should be returned in response to GET requests on data resources.
「with-defaults」クエリパラメータを使用して、データリソースに対するGETリクエストに応じてデフォルトデータノードに関する情報を返す方法を指定します。
If the server supports this capability, then it MUST implement the behavior described in Section 4.5.1 of [RFC6243], except applied to the RESTCONF GET operation instead of the NETCONF operations.
サーバーがこの機能をサポートしている場合、NETCONF操作ではなくRESTCONF GET操作に適用される場合を除き、[RFC6243]のセクション4.5.1に記載されている動作を実装する必要があります。
+-------------------+-----------------------------------------------+
| Value | Description |
+-------------------+-----------------------------------------------+
| report-all | All data nodes are reported |
| | |
| trim | Data nodes set to the YANG default are not |
| | reported |
| | |
| explicit | Data nodes set to the YANG default by the |
| | client are reported |
| | |
| report-all-tagged | All data nodes are reported, and defaults are |
| | tagged |
+-------------------+-----------------------------------------------+
If the "with-defaults" parameter is set to "report-all", then the server MUST adhere to the default-reporting behavior defined in Section 3.1 of [RFC6243].
「with-defaults」パラメータが「report-all」に設定されている場合、サーバーは[RFC6243]のセクション3.1で定義されているデフォルトのレポート動作に準拠する必要があります。
If the "with-defaults" parameter is set to "trim", then the server MUST adhere to the default-reporting behavior defined in Section 3.2 of [RFC6243].
「with-defaults」パラメータが「trim」に設定されている場合、サーバーは[RFC6243]のセクション3.2で定義されているデフォルトのレポート動作に準拠する必要があります。
If the "with-defaults" parameter is set to "explicit", then the server MUST adhere to the default-reporting behavior defined in Section 3.3 of [RFC6243].
「with-defaults」パラメータが「explicit」に設定されている場合、サーバーは[RFC6243]のセクション3.3で定義されているデフォルトのレポート動作に準拠する必要があります。
If the "with-defaults" parameter is set to "report-all-tagged", then the server MUST adhere to the default-reporting behavior defined in Section 3.4 of [RFC6243]. Metadata is reported by the server as specified in Section 5.3. The XML encoding for the "default" attribute sent by the server for default nodes is defined in Section 6 of [RFC6243]. The JSON encoding for the "default" attribute MUST use the same values, as defined in [RFC6243], but encoded according to the rules in [RFC7952]. The module name "ietf-netconf-with-defaults" MUST be used for the "default" attribute.
「with-defaults」パラメータが「report-all-tagged」に設定されている場合、サーバーは[RFC6243]のセクション3.4で定義されているデフォルトのレポート動作に準拠する必要があります。メタデータは、セクション5.3で指定されているようにサーバーによって報告されます。サーバーがデフォルトノードに送信する「デフォルト」属性のXMLエンコーディングは、[RFC6243]のセクション6で定義されています。 「デフォルト」属性のJSONエンコーディングは、[RFC6243]で定義されているのと同じ値を使用する必要がありますが、[RFC7952]のルールに従ってエンコードされています。モジュール名「ietf-netconf-with-defaults」は、「default」属性に使用する必要があります。
If the "with-defaults" parameter is not present, then the server MUST adhere to the default-reporting behavior defined in its "basic-mode" parameter for the "defaults" protocol capability URI, defined in Section 9.1.2.
「with-defaults」パラメーターが存在しない場合、サーバーは、セクション9.1.2で定義された「defaults」プロトコル機能URIの「basic-mode」パラメーターで定義されたデフォルトのレポート動作に準拠する必要があります。
If the server includes the "with-defaults" query parameter URI in the "capability" leaf-list defined in Section 9.3, then the "with-defaults" query parameter MUST be supported.
サーバーがセクション9.3で定義された「機能」リーフリストに「with-defaults」クエリパラメータURIを含める場合、「with-defaults」クエリパラメータをサポートする必要があります。
Since the server does not report the "also-supported" parameter as described in Section 4.3 of [RFC6243], it is possible that some values for the "with-defaults" parameter will not be supported. If the server does not support the requested value of the "with-defaults" parameter, the server MUST return a response with a "400 Bad Request" status-line. The error-tag value "invalid-value" is used in this case.
[RFC6243]のセクション4.3で説明されているように、サーバーは「also-supported」パラメータを報告しないため、「with-defaults」パラメータの一部の値がサポートされない可能性があります。サーバーが「with-defaults」パラメーターの要求された値をサポートしない場合、サーバーは「400 Bad Request」ステータス行を含む応答を返さなければなりません（MUST）。この場合、エラータグ値「無効値」が使用されます。
The RESTCONF protocol uses HTTP messages. A single HTTP message corresponds to a single protocol method. Most messages can perform a single task on a single resource, such as retrieving a resource or editing a resource. The exception is the PATCH method, which allows multiple datastore edits within a single message.
RESTCONFプロトコルはHTTPメッセージを使用します。 1つのHTTPメッセージは、1つのプロトコルメソッドに対応します。ほとんどのメッセージは、リソースの取得やリソースの編集など、1つのリソースで1つのタスクを実行できます。例外はPATCHメソッドです。これは、単一のメッセージ内で複数のデータストア編集を可能にします。
Resources are represented with URIs following the structure for generic URIs in [RFC3986].
リソースは、[RFC3986]の汎用URIの構造に従って、URIで表されます。
A RESTCONF operation is derived from the HTTP method and the request URI, using the following conceptual fields:
RESTCONF操作は、次の概念的なフィールドを使用して、HTTPメソッドと要求URIから派生します。
<OP> /<restconf>/<path>?<query>
^ ^ ^ ^
| | | |
method entry resource query
M M O O
M M O O
M=mandatory, O=optional
M =必須、O =オプション
where:
ただし：
<OP> is the HTTP method
<restconf> is the RESTCONF root resource
<path> is the target resource URI
<query> is the query parameter list
o method: the HTTP method identifying the RESTCONF operation requested by the client, to act upon the target resource specified in the request URI. RESTCONF operation details are described in Section 4.
o method：リクエストURIで指定されたターゲットリソースを操作するためにクライアントがリクエストしたRESTCONF操作を識別するHTTPメソッド。 RESTCONF操作の詳細については、セクション4で説明します。
o entry: the root of the RESTCONF API configured on this HTTP server, discovered by getting the "/.well-known/host-meta" resource, as described in Section 3.1.
o エントリ：このHTTPサーバーで構成されているRESTCONF APIのルート。セクション3.1で説明されているように、「/。well-known / host-meta」リソースを取得することで検出されます。
o resource: the path expression identifying the resource that is being accessed by the RESTCONF operation. If this field is not present, then the target resource is the API itself, represented by the YANG data template named "yang-api", found in Section 8.
o resource：RESTCONF操作によってアクセスされているリソースを識別するパス式。このフィールドが存在しない場合、ターゲットリソースはAPI自体であり、セクション8にある「yang-api」という名前のYANGデータテンプレートで表されます。
o query: the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI. The server MUST list the optional query parameter URIs it supports in the "capability" leaf-list defined in Section 9.3.
o クエリ：RESTCONFメッセージに関連付けられたパラメータのセット。 [RFC3986]のセクション3.4をご覧ください。 RESTCONFパラメータには、おなじみの「名前=値」ペアの形式があります。ほとんどのクエリパラメータは、サーバーが実装するか、クライアントが使用するかはオプションです。オプションの各クエリパラメータは、URIで識別されます。サーバーは、セクション9.3で定義された「機能」リーフリストに、サポートするオプションのクエリパラメータURIをリストする必要があります。
There is a specific set of parameters defined, although the server MAY choose to support query parameters not defined in this document. The contents of any query parameter value MUST be encoded according to Section 3.4 of [RFC3986]. Any reserved characters MUST be percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].
特定のパラメータセットが定義されていますが、サーバーは、このドキュメントで定義されていないクエリパラメータをサポートすることを選択できます。クエリパラメータ値の内容は、[RFC3986]のセクション3.4に従ってエンコードする必要があります。 [RFC3986]のセクション2.1および2.5によると、予約文字はパーセントでエンコードする必要があります。
Note that the fragment component is not used by the RESTCONF protocol. The fragment is excluded from the target URI by a server, as described in Section 5.1 of [RFC7230].
フラグメントコンポーネントはRESTCONFプロトコルでは使用されないことに注意してください。 [RFC7230]のセクション5.1で説明されているように、フラグメントはサーバーによってターゲットURIから除外されます。
When new resources are created by the client, a "Location" header field is returned, which identifies the path of the newly created resource. The client uses this exact path identifier to access the resource once it has been created.
クライアントによって新しいリソースが作成されると、新しく作成されたリソースのパスを識別する「Location」ヘッダーフィールドが返されます。リソースが作成されると、クライアントはこの正確なパス識別子を使用してリソースにアクセスします。
The target of a RESTCONF operation is a resource. The "path" field in the request URI represents the target resource for the RESTCONF operation.
RESTCONF操作のターゲットはリソースです。リクエストURIの「パス」フィールドは、RESTCONF操作のターゲットリソースを表します。
Refer to Appendix B for examples of RESTCONF request URIs.
RESTCONFリクエストURIの例については、付録Bを参照してください。
RESTCONF messages are encoded in HTTP according to [RFC7230]. The "utf-8" character set is used for all messages. RESTCONF message content is sent in the HTTP message-body.
RESTCONFメッセージは、[RFC7230]に従ってHTTPでエンコードされます。 「utf-8」文字セットはすべてのメッセージに使用されます。 RESTCONFメッセージの内容は、HTTPメッセージ本文で送信されます。
Content is encoded in either JSON or XML format. A server MUST support one of either XML or JSON encoding. A server MAY support both XML and JSON encoding. A client will need to support both XML and JSON to interoperate with all RESTCONF servers.
コンテンツはJSONまたはXML形式でエンコードされます。サーバーは、XMLまたはJSONエンコーディングのいずれかをサポートする必要があります。サーバーはXMLとJSONエンコーディングの両方をサポートしてもよい（MAY）。クライアントは、すべてのRESTCONFサーバーと相互運用するために、XMLとJSONの両方をサポートする必要があります。
XML encoding rules for data nodes are defined in [RFC7950]. The same encoding rules are used for all XML content. JSON encoding rules are defined in [RFC7951]. Additional JSON encoding rules for metadata are defined in [RFC7952]. This encoding is valid JSON, but it also has special encoding rules to identify module namespaces and provide consistent type processing of YANG data.
データノードのXMLエンコーディングルールは、[RFC7950]で定義されています。すべてのXMLコンテンツに同じエンコーディングルールが使用されます。 JSONエンコーディングルールは[RFC7951]で定義されています。メタデータの追加のJSONエンコーディングルールは、[RFC7952]で定義されています。このエンコーディングは有効なJSONですが、モジュールの名前空間を識別し、YANGデータの一貫した型処理を提供する特別なエンコーディングルールもあります。
The request input content encoding format is identified with the "Content-Type" header field. This field MUST be present if a message-body is sent by the client.
リクエストの入力コンテンツのエンコード形式は、「Content-Type」ヘッダーフィールドで識別されます。このフィールドは、メッセージ本文がクライアントによって送信される場合に存在する必要があります。
The server MUST support the "Accept" header field and the "406 Not Acceptable" status-line, as defined in [RFC7231]. The response output content encoding formats that the client will accept are identified with the "Accept" header field in the request. If it is not specified, the request input encoding format SHOULD be used, or the server MAY choose any supported content encoding format.
[RFC7231]で定義されているように、サーバーは「Accept」ヘッダーフィールドと「406 Not Acceptable」ステータス行をサポートする必要があります。クライアントが受け入れる応答出力コンテンツのエンコード形式は、リクエストの「Accept」ヘッダーフィールドで識別されます。指定されていない場合は、リクエストの入力エンコーディング形式を使用する必要があります（SHOULD）。または、サーバーは、サポートされているコンテンツエンコーディング形式を選択できます（MAY）。
If there was no request input, then the default output encoding is XML or JSON, depending on server preference. File extensions encoded in the request are not used to identify format encoding.
リクエスト入力がない場合、デフォルトの出力エンコーディングはサーバーの設定に応じてXMLまたはJSONです。リクエストでエンコードされたファイル拡張子は、フォーマットエンコーディングの識別には使用されません。
A client can determine if the RESTCONF server supports an encoding format by sending a request using a specific format in the "Content-Type" and/or "Accept" header field. If the server does not support the requested input encoding for a request, then it MUST return an error response with a "415 Unsupported Media Type" status-line. If the server does not support any of the requested output encodings for a request, then it MUST return an error response with a "406 Not Acceptable" status-line.
クライアントは、「Content-Type」または「Accept」ヘッダーフィールドで特定の形式を使用してリクエストを送信することにより、RESTCONFサーバーがエンコード形式をサポートしているかどうかを判断できます。サーバーが要求に対して要求された入力エンコーディングをサポートしていない場合は、「415 Unsupported Media Type」ステータス行を含むエラー応答を返さなければなりません（MUST）。サーバーが要求に対して要求された出力エンコーディングのいずれもサポートしていない場合は、「406 Not Acceptable」ステータス行を含むエラー応答を返さなければなりません（MUST）。
The RESTCONF protocol needs to support the retrieval of the same metadata that is used in the NETCONF protocol. Information about default leafs, last-modified timestamps, etc. is commonly used to annotate representations of the datastore contents.
RESTCONFプロトコルは、NETCONFプロトコルで使用されるのと同じメタデータの取得をサポートする必要があります。デフォルトのリーフ、最終変更のタイムスタンプなどに関する情報は、データストアコンテンツの表現に注釈を付けるために一般的に使用されます。
With the XML encoding, the metadata is encoded as attributes in XML, according to Section 3.3 of [W3C.REC-xml-20081126]. With the JSON encoding, the metadata is encoded as specified in [RFC7952].
[W3C.REC-xml-20081126]のセクション3.3に従って、XMLエンコーディングでは、メタデータはXMLの属性としてエンコードされます。 JSONエンコードでは、メタデータは[RFC7952]で指定されているようにエンコードされます。
The following examples are based on the example in Appendix B.3.9. The "report-all-tagged" mode for the "with-defaults" query parameter requires that a "default" attribute be returned for default nodes. These examples show that attribute for the "mtu" leaf.
次の例は、付録B.3.9の例に基づいています。 「with-defaults」クエリパラメータの「report-all-tagged」モードでは、デフォルトノードの「default」属性を返す必要があります。これらの例は、「mtu」リーフのその属性を示しています。
GET /restconf/data/interfaces/interface=eth1
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
<interface
xmlns="urn:example.com:params:xml:ns:yang:example-interface">
<name>eth1</name>
<mtu xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0"
wd:default="true">1500</mtu>
<status>up</status>
</interface>
Note that RFC 6243 defines the "default" attribute with the XML Schema Definition (XSD), not YANG, so the YANG module name has to be assigned instead of derived from the YANG module. The value "ietf-netconf-with-defaults" is assigned for JSON metadata encoding.
RFC 6243は「デフォルト」属性をYANGではなくXMLスキーマ定義（XSD）で定義しているため、YANGモジュールから派生した代わりにYANGモジュール名を割り当てる必要があることに注意してください。値「ietf-netconf-with-defaults」は、JSONメタデータエンコーディングに割り当てられます。
GET /restconf/data/interfaces/interface=eth1\
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"example:interface" : [
{
"name" : "eth1",
"mtu" : 1500,
"@mtu" : {
"ietf-netconf-with-defaults:default" : true
},
"status" : "up"
}
]
}
Each message represents some sort of resource access. An HTTP "status-line" header field is returned for each request. If a status code in the "4xx" range is returned in the status-line, then the error information SHOULD be returned in the response, according to the format defined in Section 7.1. If a status code in the "5xx" range is returned in the status-line, then the error information MAY be returned in the response, according to the format defined in Section 7.1. If a status code in the "1xx", "2xx", or "3xx" range is returned in the status-line, then error information MUST NOT be returned in the response, since these ranges do not represent error conditions.
各メッセージは、ある種のリソースアクセスを表します。リクエストごとに、HTTP「ステータスライン」ヘッダーフィールドが返されます。 「4xx」の範囲のステータスコードがステータス行に返された場合、セクション7.1で定義されているフォーマットに従って、エラー情報を応答で返す必要があります（SHOULD）。 「5xx」の範囲のステータスコードがステータス行に返された場合、セクション7.1で定義されているフォーマットに従って、エラー情報が応答で返される場合があります。 「1xx」、「2xx」、または「3xx」の範囲のステータスコードがステータス行に返される場合、これらの範囲はエラー状態を表していないため、エラー情報を応答に返してはなりません（MUST NOT）。
Since the datastore contents change at unpredictable times, responses from a RESTCONF server generally SHOULD NOT be cached.
データストアの内容は予測できない時間に変更されるため、RESTCONFサーバーからの応答は通常キャッシュされるべきではありません。
The server MUST include a "Cache-Control" header field in every response that specifies whether the response should be cached.
サーバーは、応答をキャッシュするかどうかを指定する「Cache-Control」ヘッダーフィールドをすべての応答に含める必要があります。
Instead of relying on HTTP caching, the client SHOULD track the "ETag" and/or "Last-Modified" header fields returned by the server for the datastore resource (or data resource, if the server supports it). A retrieval request for a resource can include the "If-None-Match" and/or "If-Modified-Since" header fields, which will cause the server to return a "304 Not Modified" status-line if the resource has not changed. The client MAY use the HEAD method to retrieve just the message header fields, which SHOULD include the "ETag" and "Last-Modified" header fields, if this metadata is maintained for the target resource.
HTTPキャッシングに依存する代わりに、クライアントはサーバーがデータストアリソース（またはサーバーがサポートしている場合はデータリソース）から返される「ETag」または「Last-Modified」ヘッダーフィールドを追跡する必要があります（SHOULD）。リソースの取得リクエストには、「If-None-Match」または「If-Modified-Since」ヘッダーフィールドを含めることができます。これにより、リソースがリソースを持っていない場合、サーバーは「304 Not Modified」ステータス行を返します。かわった。このメタデータがターゲットリソースに対して維持されている場合、クライアントはHEADメソッドを使用してメッセージヘッダーフィールドのみを取得できます。このヘッダーフィールドには、「ETag」および「Last-Modified」ヘッダーフィールドを含める必要があります（SHOULD）。
Note that access control can be applied to data resources, such that the values in the "Last-Modified" and "ETag" headers maintained for a data resource may not be reliable, as described in Section 4.3.
セクション4.3で説明されているように、データリソースに保持されている "Last-Modified"および "ETag"ヘッダーの値が信頼できない場合があるように、アクセス制御をデータリソースに適用できることに注意してください。
The RESTCONF protocol supports YANG-defined event notifications. The solution preserves aspects of NETCONF event notifications [RFC5277] while utilizing the Server-Sent Events [W3C.REC-eventsource-20150203] transport strategy.
RESTCONFプロトコルは、YANG定義のイベント通知をサポートしています。このソリューションは、サーバー送信イベント[W3C.REC-eventsource-20150203]トランスポート戦略を利用しながら、NETCONFイベント通知[RFC5277]の側面を保持します。
A RESTCONF server MAY support RESTCONF notifications. Clients may determine if a server supports RESTCONF notifications by using the HTTP OPTIONS, HEAD, or GET method on the "stream" list. The server does not support RESTCONF notifications if an HTTP error code is returned (e.g., a "404 Not Found" status-line).
RESTCONFサーバーはRESTCONF通知をサポートする場合があります。クライアントは、「ストリーム」リストでHTTP OPTIONS、HEAD、またはGETメソッドを使用して、サーバーがRESTCONF通知をサポートするかどうかを判断できます。 HTTPエラーコードが返された場合、サーバーはRESTCONF通知をサポートしません（たとえば、「404 Not Found」ステータス行）。
A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point. A RESTCONF client can retrieve the list of supported event streams from a RESTCONF server using the GET method on the "stream" list.
通知をサポートするRESTCONFサーバーは、各通知配信サービスアクセスポイントのストリームリソースを設定します。 RESTCONFクライアントは、「ストリーム」リストでGETメソッドを使用して、サポートされているイベントストリームのリストをRESTCONFサーバーから取得できます。
The "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module (defined in Section 9.3) is used to specify the structure and syntax of the conceptual child resources within the "streams" resource.
「ietf-restconf-monitoring」モジュール（9.3項で定義）の「restconf-state / streams」コンテナ定義を使用して、「streams」リソース内の概念的な子リソースの構造と構文を指定します。
For example:
例えば：
The client might send the following request:
クライアントは次のリクエストを送信する場合があります。
GET /restconf/data/ietf-restconf-monitoring:restconf-state/\
streams HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might send the following response:
サーバーは次の応答を送信する場合があります。
HTTP/1.1 200 OK
Content-Type: application/yang-data+xml
<streams
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">
<stream>
<name>NETCONF</name>
<description>default NETCONF event stream</description>
<replay-support>true</replay-support>
<replay-log-creation-time>\
2007-07-08T00:00:00Z\
</replay-log-creation-time>
<access>
<encoding>xml</encoding>
<location>https://example.com/streams/NETCONF\
</location>
</access>
<access>
<encoding>json</encoding>
<location>https://example.com/streams/NETCONF-JSON\
</location>
</access>
</stream>
<stream>
<name>SNMP</name>
<description>SNMP notifications</description>
<replay-support>false</replay-support>
<access>
<encoding>xml</encoding>
<location>https://example.com/streams/SNMP</location>
</access>
</stream>
<stream>
<name>syslog-critical</name>
<description>Critical and higher severity</description>
<replay-support>true</replay-support>
<replay-log-creation-time>
2007-07-01T00:00:00Z
</replay-log-creation-time>
<access>
<encoding>xml</encoding>
<location>\
https://example.com/streams/syslog-critical\
</location>
</access>
</stream>
</streams>
RESTCONF clients can determine the URL for the subscription resource (to receive notifications) by sending an HTTP GET request for the "location" leaf with the "stream" list entry. The value returned by the server can be used for the actual notification subscription.
RESTCONFクライアントは、「ストリーム」リストエントリを持つ「ロケーション」リーフに対するHTTP GETリクエストを送信することにより、（通知を受信するために）サブスクリプションリソースのURLを決定できます。サーバーから返された値は、実際の通知サブスクリプションに使用できます。
The client will send an HTTP GET request for the URL returned by the server with the "Accept" type "text/event-stream".
クライアントは、「Accept」タイプが「text / event-stream」のサーバーから返されたURLに対してHTTP GETリクエストを送信します。
The server will treat the connection as an event stream, using the Server-Sent Events [W3C.REC-eventsource-20150203] transport strategy.
サーバーは、サーバー送信イベント[W3C.REC-eventsource-20150203]トランスポート戦略を使用して、接続をイベントストリームとして扱います。
The server MAY support query parameters for a GET method on this resource. These parameters are specific to each event stream.
サーバーは、このリソースのGETメソッドのクエリパラメータをサポートする場合があります。これらのパラメーターは、各イベントストリームに固有です。
For example:
例えば：
The client might send the following request:
クライアントは次のリクエストを送信する場合があります。
GET /restconf/data/ietf-restconf-monitoring:restconf-state/\
streams/stream=NETCONF/access=xml/location HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might send the following response:
サーバーは次の応答を送信する場合があります。
HTTP/1.1 200 OK
Content-Type: application/yang-data+xml
<location
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">\
https://example.com/streams/NETCONF\
</location>
The RESTCONF client can then use this URL value to start monitoring the event stream:
RESTCONFクライアントは、このURL値を使用して、イベントストリームの監視を開始できます。
GET /streams/NETCONF HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
A RESTCONF client MAY request that the server compress the events using the HTTP header field "Accept-Encoding". For instance:
RESTCONFクライアントは、サーバーがHTTPヘッダーフィールド "Accept-Encoding"を使用してイベントを圧縮することを要求する場合があります。例えば：
GET /streams/NETCONF HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Accept-Encoding: gzip, deflate
The server SHOULD support the NETCONF event stream defined in Section 3.2.3 of [RFC5277]. The notification messages for this stream are encoded in XML.
サーバーは、[RFC5277]のセクション3.2.3で定義されたNETCONFイベントストリームをサポートする必要があります（SHOULD）。このストリームの通知メッセージはXMLでエンコードされています。
The server MAY support additional streams that represent the semantic content of the NETCONF event stream, but using a representation with a different media type.
サーバーは、NETCONFイベントストリームのセマンティックコンテンツを表す追加のストリームをサポートしてもかまいませんが、異なるメディアタイプの表現を使用します。
The server MAY support the "start-time", "stop-time", and "filter" query parameters, defined in Section 4.8. Refer to Appendix B.3.6 for filter parameter examples.
サーバーは、セクション4.8で定義されている「start-time」、「stop-time」、および「filter」クエリパラメータをサポートする場合があります。フィルタパラメータの例については、付録B.3.6を参照してください。
RESTCONF notifications are encoded according to the definition of the event stream.
RESTCONF通知は、イベントストリームの定義に従ってエンコードされます。
The structure of the event data is based on the <notification> element definition in Section 4 of [RFC5277]. It MUST conform to the schema for the <notification> element in Section 4 of [RFC5277], using the XML namespace as defined in the XSD as follows:
イベントデータの構造は、[RFC5277]のセクション4の<notification>要素の定義に基づいています。次のように、XSDで定義されているXML名前空間を使用して、[RFC5277]のセクション4の<notification>要素のスキーマに準拠する必要があります。
urn:ietf:params:xml:ns:netconf:notification:1.0
For JSON-encoding purposes, the module name for the "notification" element is "ietf-restconf".
JSONエンコードの目的で、「通知」要素のモジュール名は「ietf-restconf」です。
Two child nodes within the "notification" container are expected, representing the event time and the event payload. The "eventTime" node is defined within the same XML namespace as the <notification> element. It is defined to be within the "ietf-restconf" module namespace for JSON-encoding purposes.
「通知」コンテナ内には、イベント時間とイベントペイロードを表す2つの子ノードが必要です。 「eventTime」ノードは、<notification>要素と同じXML名前空間内で定義されます。 JSONエンコードの目的で、「ietf-restconf」モジュールの名前空間内にあるように定義されています。
The name and namespace of the payload element are determined by the YANG module containing the notification-stmt representing the notification message.
ペイロード要素の名前と名前空間は、通知メッセージを表すnotification-stmtを含むYANGモジュールによって決定されます。
In the following example, the YANG module "example-mod" is used:
次の例では、YANGモジュール「example-mod」が使用されています。
module example-mod {
namespace "http://example.com/event/1.0";
prefix ex;
organization "Example, Inc.";
contact "support at example.com";
description "Example Notification Data Model Module.";
revision "2016-07-07" {
description "Initial version.";
reference "example.com document 2-9976.";
}
notification event {
description "Example notification event.";
leaf event-class {
type string;
description "Event class identifier.";
}
container reporting-entity {
description "Event specific information.";
leaf card {
type string;
description "Line card identifier.";
}
}
leaf severity {
type string;
description "Event severity description.";
}
}
}
An example SSE event notification encoded using XML:
XMLを使用してエンコードされたSSEイベント通知の例：
data: <notification
data: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
data: <eventTime>2013-12-21T00:01:00Z</eventTime>
data: <event xmlns="http://example.com/event/1.0">
data: <event-class>fault</event-class>
data: <reporting-entity>
data: <card>Ethernet0</card>
data: </reporting-entity>
data: <severity>major</severity>
data: </event>
data: </notification>
An example SSE event notification encoded using JSON:
JSONを使用してエンコードされたSSEイベント通知の例：
data: {
data: "ietf-restconf:notification" : {
data: "eventTime" : "2013-12-21T00:01:00Z",
data: "example-mod:event" : {
data: "event-class" : "fault",
data: "reporting-entity" : { "card" : "Ethernet0" },
data: "severity" : "major"
data: }
data: }
data: }
Alternatively, since neither XML nor JSON is whitespace sensitive, the above messages can be encoded onto a single line. For example:
または、XMLもJSONも空白を区別しないため、上記のメッセージを1行にエンコードできます。例えば：
XML:
XML：
data: <notification xmlns="urn:ietf:params:xml:ns:netconf:notif\
ication:1.0"><eventTime>2013-12-21T00:01:00Z</eventTime><event \
xmlns="http://example.com/event/1.0"><event-class>fault</event-\
class><reportingEntity><card>Ethernet0</card></reporting-entity>\
<severity>major</severity></event></notification>
JSON:
JSON：
data: {"ietf-restconf:notification":{"eventTime":"2013-12-21\
T00:01:00Z","example-mod:event":{"event-class": "fault","repor\
tingEntity":{"card":"Ethernet0"},"severity":"major"}}}
The SSE specification supports the following additional fields: "event", "id", and "retry". A RESTCONF server MAY send the "retry" field, and if it does, RESTCONF clients SHOULD use it. A RESTCONF server SHOULD NOT send the "event" or "id" fields, as there are no meaningful values that could be used for them that would not be redundant to the contents of the notification itself. RESTCONF servers that do not send the "id" field also do not need to support the HTTP header field "Last-Event-ID" [W3C.REC-eventsource-20150203]. RESTCONF servers that do send the "id" field SHOULD support the "start-time" query parameter as the preferred means for a client to specify where to restart the event stream.
SSE仕様は、「event」、「id」、および「retry」の追加フィールドをサポートしています。 RESTCONFサーバーは「再試行」フィールドを送信する場合があり、送信する場合、RESTCONFクライアントはそれを使用する必要があります（SHOULD）。 RESTCONFサーバーは「event」または「id」フィールドを送信しないでください。通知自体の内容に冗長ではない、それらに使用できる意味のある値がないためです。 「id」フィールドを送信しないRESTCONFサーバーは、HTTPヘッダーフィールド「Last-Event-ID」[W3C.REC-eventsource-20150203]をサポートする必要もありません。 「id」フィールドを送信するRESTCONFサーバーは、クライアントがイベントストリームを再開する場所を指定するための推奨手段として、「start-time」クエリパラメータをサポートする必要があります（SHOULD）。
HTTP status codes are used to report success or failure for RESTCONF operations. The error information that NETCONF error responses contain in the <rpc-error> element is adapted for use in RESTCONF, and <errors> data tree information is returned for the "4xx" and "5xx" classes of status codes.
HTTPステータスコードは、RESTCONF操作の成功または失敗を報告するために使用されます。 NETCONFエラー応答が<rpc-error>要素に含むエラー情報はRESTCONFでの使用に適合しており、ステータスコードの「4xx」および「5xx」クラスの<errors>データツリー情報が返されます。
Since an operation resource is defined with a YANG "rpc" statement and an action is defined with a YANG "action" statement, a mapping from the NETCONF <error-tag> value to the HTTP status code is needed. The specific error-tag and response code to use are specific to the data model and might be contained in the YANG "description" statement for the "action" or "rpc" statement.
操作リソースはYANG "rpc"ステートメントで定義され、アクションはYANG "action"ステートメントで定義されるため、NETCONF <error-tag>値からHTTPステータスコードへのマッピングが必要です。使用する特定のエラータグと応答コードはデータモデルに固有であり、「action」または「rpc」ステートメントのYANG「説明」ステートメントに含まれている場合があります。
+-------------------------+------------------+
| error-tag | status code |
+-------------------------+------------------+
| in-use | 409 |
| | |
| invalid-value | 400, 404, or 406 |
| | |
| (request) too-big | 413 |
| | |
| (response) too-big | 400 |
| | |
| missing-attribute | 400 |
| | |
| bad-attribute | 400 |
| | |
| unknown-attribute | 400 |
| | |
| bad-element | 400 |
| | |
| unknown-element | 400 |
| | |
| unknown-namespace | 400 |
| | |
| access-denied | 401 or 403 |
| | |
| lock-denied | 409 |
| | |
| resource-denied | 409 |
| | |
| rollback-failed | 500 |
| | |
| data-exists | 409 |
| | |
| data-missing | 409 |
| | |
| operation-not-supported | 405 or 501 |
| | |
| operation-failed | 412 or 500 |
| | |
| partial-operation | 500 |
| | |
| malformed-message | 400 |
+-------------------------+------------------+
Mapping from <error-tag> to Status Code
<error-tag>からステータスコードへのマッピング
When an error occurs for a request message on any resource type and the status code that will be returned is in the "4xx" range (except for status code "403 Forbidden"), the server SHOULD send a response message-body containing the information described by the "yang-errors" YANG data template within the "ietf-restconf" module found in Section 8. The Content-Type of this response message MUST be "application/yang-data", plus, optionally, a structured syntax name suffix.
リソースタイプのリクエストメッセージでエラーが発生し、返されるステータスコードが「4xx」の範囲にある場合（ステータスコード「403 Forbidden」を除く）、サーバーは情報を含む応答メッセージ本文を送信する必要があります（SHOULD）セクション8にある「ietf-restconf」モジュール内の「yang-errors」YANGデータテンプレートによって記述されます。この応答メッセージのContent-Typeは、「application / yang-data」に加えて、オプションで構造化構文名でなければなりませんサフィックス。
The client SHOULD specify the desired encoding(s) for response messages by specifying the appropriate media type(s) in the "Accept" header. If the client did not specify an "Accept" header, then the same structured syntax name suffix used in the request message SHOULD be used, or the server MAY choose any supported message-encoding format. If there is no request message, the server MUST select "application/yang-data+xml" or "application/yang-data+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error.
クライアントは、「Accept」ヘッダーで適切なメディアタイプを指定することにより、応答メッセージに必要なエンコーディングを指定する必要があります（SHOULD）。クライアントが「Accept」ヘッダーを指定しなかった場合は、リクエストメッセージで使用されているのと同じ構造化構文名のサフィックスを使用する必要があります（SHOULD）。または、サーバーはサポートされているメッセージエンコーディング形式を選択できます（MAY）。要求メッセージがない場合、サーバーはサーバーの設定に応じて「application / yang-data + xml」または「application / yang-data + json」を選択する必要があります。以下の例を除いて、このドキュメントのすべての例では、エラーが発生した場合にXMLエンコーディングが返されると想定しています。
YANG tree diagram for <errors> data:
<errors>データのYANGツリー図：
+---- errors
+---- error*
+---- error-type enumeration
+---- error-tag string
+---- error-app-tag? string
+---- error-path? instance-identifier
+---- error-message? string
+---- error-info?
The semantics and syntax for RESTCONF error messages are defined with the "yang-errors" YANG data template extension, found in Section 8.
RESTCONFエラーメッセージのセマンティクスと構文は、セクション8にある「yang-errors」YANGデータテンプレート拡張で定義されています。
Examples:
例：
The following example shows an error returned for a "lock-denied" error that can occur if a NETCONF client has locked a datastore. The RESTCONF client is attempting to delete a data resource. Note that an "Accept" header field is used to specify the desired encoding for the error message. There would be no response message-body content if this operation was successful.
次の例は、NETCONFクライアントがデータストアをロックしている場合に発生する可能性がある「ロック拒否」エラーに対して返されるエラーを示しています。 RESTCONFクライアントがデータリソースを削除しようとしています。 「Accept」ヘッダーフィールドは、エラーメッセージの目的のエンコーディングを指定するために使用されることに注意してください。この操作が成功した場合、応答メッセージ本文のコンテンツはありません。
DELETE /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 409 Conflict
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"ietf-restconf:errors" : {
"error" : [
{
"error-type" : "protocol",
"error-tag" : "lock-denied",
"error-message" : "Lock failed; lock already held"
}
]
}
}
The following example shows an error returned for a "data-exists" error on a data resource. The "jukebox" resource already exists, so it cannot be created.
次の例は、データリソースの「data-exists」エラーに対して返されるエラーを示しています。 「ジュークボックス」リソースはすでに存在するため、作成できません。
The client might send the following:
クライアントは以下を送信する場合があります。
POST /restconf/data/example-jukebox:jukebox HTTP/1.1
Host: example.com
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 409 Conflict
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>protocol</error-type>
<error-tag>data-exists</error-tag>
<error-path
xmlns:rc="urn:ietf:params:xml:ns:yang:ietf-restconf"
xmlns:jbox="https://example.com/ns/example-jukebox">\
/rc:restconf/rc:data/jbox:jukebox
</error-path>
<error-message>
Data already exists; cannot create new resource
</error-message>
</error>
</errors>
The "ietf-restconf" module defines conceptual definitions within an extension and two groupings, which are not meant to be implemented as datastore contents by a server. For example, the "restconf" container is not intended to be implemented as a top-level data node (under the "/restconf/data" URI).
「ietf-restconf」モジュールは、拡張機能と2つのグループ内の概念的な定義を定義します。これらは、サーバーによってデータストアコンテンツとして実装されることを意図していません。たとえば、「restconf」コンテナは、トップレベルのデータノード（「/ restconf / data」URIの下）として実装されることを意図していません。
Note that the "ietf-restconf" module does not have any protocol-accessible objects, so no YANG tree diagram is shown.
「ietf-restconf」モジュールにはプロトコルでアクセス可能なオブジェクトがないため、YANGツリー図は表示されていません。
<CODE BEGINS>
<コード開始>
file "ietf-restconf@2017-01-26.yang"
ファイル「ietf-restconf@2017-01-26.yang」
module ietf-restconf {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf";
prefix "rc";
organization "IETF NETCONF (Network Configuration) Working Group";
組織「IETF NETCONF（ネットワーク構成）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Andy Bierman
<mailto:andy@yumaworks.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>";
description "This module contains conceptual YANG specifications for basic RESTCONF media type definitions used in RESTCONF protocol messages.
説明「このモジュールには、RESTCONFプロトコルメッセージで使用される基本的なRESTCONFメディアタイプ定義の概念的なYANG仕様が含まれています。
Note that the YANG definitions within this module do not represent configuration data of any kind. The 'restconf-media-type' YANG extension statement provides a normative syntax for XML and JSON message-encoding purposes.
このモジュール内のYANG定義は、いかなる種類の構成データも表していません。 'restconf-media-type' YANG拡張ステートメントは、XMLおよびJSONメッセージエンコードのための規範的な構文を提供します。
Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2017 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETFドキュメントに関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8040; see the RFC itself for full legal notices.";
このバージョンのYANGモジュールはRFC 8040の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2017-01-26 {
description
"Initial revision.";
reference
"RFC 8040: RESTCONF Protocol.";
}
extension yang-data {
argument name {
yin-element true;
}
description
"This extension is used to specify a YANG data template that
represents conceptual data defined in YANG. It is
intended to describe hierarchical data independent of
protocol context or specific message-encoding format.
Data definition statements within a yang-data extension
specify the generic syntax for the specific YANG data
template, whose name is the argument of the 'yang-data'
extension statement.
Note that this extension does not define a media type. A specification using this extension MUST specify the message-encoding rules, including the content media type.
この拡張機能はメディアタイプを定義しないことに注意してください。この拡張を使用する仕様では、コンテンツのメディアタイプを含むメッセージエンコーディングルールを指定する必要があります。
The mandatory 'name' parameter value identifies the YANG data template that is being defined. It contains the template name.
必須の「name」パラメーター値は、定義されているYANGデータテンプレートを識別します。テンプレート名が含まれています。
This extension is ignored unless it appears as a top-level statement. It MUST contain data definition statements that result in exactly one container data node definition. An instance of a YANG data template can thus be translated into an XML instance document, whose top-level element corresponds to the top-level container.
この拡張機能は、トップレベルのステートメントとして表示されない限り無視されます。コンテナデータノード定義を1つだけにするデータ定義ステートメントを含める必要があります。したがって、YANGデータテンプレートのインスタンスは、最上位の要素が最上位のコンテナに対応するXMLインスタンスドキュメントに変換できます。
The module name and namespace values for the YANG module using the extension statement are assigned to instance document data conforming to the data definition statements within this extension.
拡張ステートメントを使用するYANGモジュールのモジュール名と名前空間の値は、この拡張内のデータ定義ステートメントに準拠するインスタンスドキュメントデータに割り当てられます。
The substatements of this extension MUST follow the 'data-def-stmt' rule in the YANG ABNF.
この拡張機能のサブステートメントは、YANG ABNFの「data-def-stmt」ルールに従う必要があります。
The XPath document root is the extension statement itself, such that the child nodes of the document root are represented by the data-def-stmt substatements within this extension. This conceptual document is the context for the following YANG statements:
XPathドキュメントルートは拡張ステートメント自体であり、ドキュメントルートの子ノードは、この拡張内のdata-def-stmtサブステートメントによって表されます。この概念ドキュメントは、次のYANGステートメントのコンテキストです。
- must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type
- must-stmt-when-stmt-path-stmt-min-elements-stmt-max-elements-stmt-required-stmt-unique-stmt-ordered-by-instance-identifierデータ型
The following data-def-stmt substatements are constrained when used within a 'yang-data' extension statement.
次のdata-def-stmtサブステートメントは、「yang-data」拡張ステートメント内で使用すると制約されます。
- The list-stmt is not required to have a key-stmt defined.
- The if-feature-stmt is ignored if present.
- The config-stmt is ignored if present.
- The available identity values for any 'identityref'
leaf or leaf-list nodes are limited to the module
containing this extension statement and the modules
imported into that module.
";
}
rc:yang-data yang-errors {
uses errors;
}
rc:yang-data yang-api {
uses restconf;
}
grouping errors {
description
"A grouping that contains a YANG container
representing the syntax and semantics of a
YANG Patch error report within a response message.";
container errors {
description
"Represents an error report returned by the server if
a request results in an error.";
list error {
description
"An entry containing information about one
specific error that occurred while processing
a RESTCONF request.";
reference
"RFC 6241, Section 4.3.";
leaf error-type {
type enumeration {
enum transport {
description
"The transport layer.";
}
enum rpc {
description
"The rpc or notification layer.";
}
enum protocol {
description
"The protocol operation layer.";
}
enum application {
description
"The server application layer.";
}
}
mandatory true;
description
"The protocol layer where the error occurred.";
}
leaf error-tag {
type string;
mandatory true;
description
"The enumerated error-tag.";
}
leaf error-app-tag {
type string;
description
"The application-specific error-tag.";
}
leaf error-path {
type instance-identifier;
description
"The YANG instance identifier associated
with the error node.";
}
leaf error-message {
type string;
description
"A message describing the error.";
}
anydata error-info {
description
"This anydata value MUST represent a container with
zero or more data nodes representing additional
error information.";
}
}
}
}
grouping restconf {
description
"Conceptual grouping representing the RESTCONF
root resource.";
container restconf {
description
"Conceptual container representing the RESTCONF
root resource.";
container data {
description
"Container representing the datastore resource.
Represents the conceptual root of all state data
and configuration data supported by the server.
The child nodes of this container can be any data
resources that are defined as top-level data nodes
from the YANG modules advertised by the server in
the 'ietf-yang-library' module.";
}
container operations { description "Container for all operation resources.
コンテナ操作{説明 "すべての操作リソースのコンテナ。
Each resource is represented as an empty leaf with the name of the RPC operation from the YANG 'rpc' statement.
各リソースは、YANG 'rpc'ステートメントからのRPC操作の名前が付いた空のリーフとして表されます。
For example, the 'system-restart' RPC operation defined in the 'ietf-system' module would be represented as an empty leaf in the 'ietf-system' namespace. This is a conceptual leaf and will not actually be found in the module:
たとえば、「ietf-system」モジュールで定義された「system-restart」RPC操作は、「ietf-system」名前空間で空のリーフとして表されます。これは概念的なリーフであり、モジュールでは実際には見つかりません。
module ietf-system {
leaf system-reset {
type empty;
}
}
To invoke the 'system-restart' RPC operation:
'system-restart' RPCオペレーションを呼び出すには：
POST /restconf/operations/ietf-system:system-restart
To discover the RPC operations supported by the server:
サーバーがサポートするRPC操作を検出するには：
GET /restconf/operations
GET / restconf / operations
In XML, the YANG module namespace identifies the module:
XMLでは、YANGモジュールの名前空間がモジュールを識別します。
<system-restart
xmlns='urn:ietf:params:xml:ns:yang:ietf-system'/>
In JSON, the YANG module name identifies the module:
JSONでは、YANGモジュール名がモジュールを識別します。
{ 'ietf-system:system-restart' : [null] }
";
}
leaf yang-library-version {
type string {
pattern '\d{4}-\d{2}-\d{2}';
}
config false;
mandatory true;
description
"Identifies the revision date of the 'ietf-yang-library'
module that is implemented by this RESTCONF server.
Indicates the year, month, and day in YYYY-MM-DD
numeric format.";
}
}
}
}
｝
<CODE ENDS>
<コード終了>
The "ietf-restconf-monitoring" module provides information about the RESTCONF protocol capabilities and event streams available from the server. A RESTCONF server MUST implement the "ietf-restconf-monitoring" module.
「ietf-restconf-monitoring」モジュールは、サーバーから利用可能なRESTCONFプロトコル機能とイベントストリームに関する情報を提供します。 RESTCONFサーバーは「ietf-restconf-monitoring」モジュールを実装する必要があります。
YANG tree diagram for the "ietf-restconf-monitoring" module:
「ietf-restconf-monitoring」モジュールのYANGツリー図：
+--ro restconf-state
+--ro capabilities
| +--ro capability* inet:uri
+--ro streams
+--ro stream* [name]
+--ro name string
+--ro description? string
+--ro replay-support? boolean
+--ro replay-log-creation-time? yang:date-and-time
+--ro access* [encoding]
+--ro encoding string
+--ro location inet:uri
This mandatory container holds the RESTCONF protocol capability URIs supported by the server.
この必須コンテナーは、サーバーがサポートするRESTCONFプロトコル機能のURIを保持します。
The server MAY maintain a last-modified timestamp for this container and return the "Last-Modified" header field when this data node is retrieved with the GET or HEAD methods. Note that the last-modified timestamp for the datastore resource is not affected by changes to this subtree.
サーバーはこのコンテナの最終変更のタイムスタンプを維持し、このデータノードがGETまたはHEADメソッドで取得されたときに「Last-Modified」ヘッダーフィールドを返す場合があります。データストアリソースの最終変更タイムスタンプは、このサブツリーへの変更の影響を受けないことに注意してください。
The server SHOULD maintain an entity-tag for this container and return the "ETag" header field when this data node is retrieved with the GET or HEAD methods. Note that the entity-tag for the datastore resource is not affected by changes to this subtree.
サーバーはこのコンテナのエンティティタグを維持し、このデータノードがGETまたはHEADメソッドで取得されたときに「ETag」ヘッダーフィールドを返す必要があります（SHOULD）。データストアリソースのエンティティタグは、このサブツリーへの変更の影響を受けないことに注意してください。
The server MUST include a "capability" URI leaf-list entry for the "defaults" mode used by the server, defined in Section 9.1.2.
サーバーは、セクション9.1.2で定義されている、サーバーが使用する「デフォルト」モードの「機能」URIリーフリストエントリを含める必要があります。
The server MUST include a "capability" URI leaf-list entry identifying each supported optional protocol feature. This includes optional query parameters and MAY include other capability URIs defined outside this document.
サーバーは、サポートされている各オプションのプロトコル機能を識別する「機能」URIリーフリストエントリを含める必要があります。これにはオプションのクエリパラメータが含まれ、このドキュメントの外部で定義された他の機能URIが含まれる場合があります。
A new set of RESTCONF Capability URIs are defined to identify the specific query parameters (defined in Section 4.8) supported by the server.
サーバーがサポートする特定のクエリパラメータ（セクション4.8で定義）を識別するために、RESTCONF機能URIの新しいセットが定義されています。
The server MUST include a "capability" leaf-list entry for each optional query parameter that it supports.
サーバーは、サポートするオプションのクエリパラメータごとに「機能」リーフリストエントリを含める必要があります。
+----------------+---------+---------------------------------------+
| Name | Section | URI |
| | | |
+----------------+---------+---------------------------------------+
| depth | 4.8.2 | urn:ietf:params:restconf:capability: |
| | | depth:1.0 |
| | | |
| fields | 4.8.3 | urn:ietf:params:restconf:capability: |
| | | fields:1.0 |
| | | |
| filter | 4.8.4 | urn:ietf:params:restconf:capability: |
| | | filter:1.0 |
| | | |
| replay | 4.8.7 | urn:ietf:params:restconf:capability: |
| | 4.8.8 | replay:1.0 |
| | | |
| with-defaults | 4.8.9 | urn:ietf:params:restconf:capability: |
| | | with-defaults:1.0 |
+----------------+---------+---------------------------------------+
RESTCONF Query Parameter URIs
RESTCONFクエリパラメータURI
This URI identifies the "basic-mode" default-handling mode that is used by the server for processing default leafs in requests for data resources. This protocol capability URI MUST be supported by the server and MUST be listed in the "capability" leaf-list defined in Section 9.3.
このURIは、サーバーがデータリソースのリクエストのデフォルトリーフを処理するために使用する「基本モード」のデフォルト処理モードを識別します。このプロトコル機能URIはサーバーによってサポートされなければならず（MUST）、セクション9.3で定義された「機能」リーフリストにリストされなければなりません（MUST）。
+----------+--------------------------------------------------+
| Name | URI |
+----------+--------------------------------------------------+
| defaults | urn:ietf:params:restconf:capability:defaults:1.0 |
+----------+--------------------------------------------------+
RESTCONF "defaults" Capability URI
RESTCONFの「デフォルト」機能URI
The URI MUST contain a query parameter named "basic-mode" with one of the values listed below:
URIには、次のいずれかの値を持つ「basic-mode」という名前のクエリパラメータを含める必要があります。
+------------+------------------------------------------------------+
| Value | Description |
+------------+------------------------------------------------------+
| report-all | No data nodes are considered default |
| | |
| trim | Values set to the YANG default-stmt value are |
| | default |
| | |
| explicit | Values set by the client are never considered |
| | default |
+------------+------------------------------------------------------+
The "basic-mode" definitions are specified in "With-defaults Capability for NETCONF" [RFC6243].
「基本モード」の定義は、「NETCONFのデフォルト機能あり」[RFC6243]で指定されています。
If the "basic-mode" is set to "report-all", then the server MUST adhere to the default-handling behavior defined in Section 2.1 of [RFC6243].
「basic-mode」が「report-all」に設定されている場合、サーバーは[RFC6243]のセクション2.1で定義されているデフォルトの処理動作に準拠する必要があります。
If the "basic-mode" is set to "trim", then the server MUST adhere to the default-handling behavior defined in Section 2.2 of [RFC6243].
「基本モード」が「トリム」に設定されている場合、サーバーは、[RFC6243]のセクション2.2で定義されているデフォルトの処理動作に準拠する必要があります。
If the "basic-mode" is set to "explicit", then the server MUST adhere to the default-handling behavior defined in Section 2.3 of [RFC6243].
「basic-mode」が「explicit」に設定されている場合、サーバーは[RFC6243]のセクション2.3で定義されているデフォルトの処理動作に準拠する必要があります。
Example (split for display purposes only):
例（表示目的でのみ分割）：
urn:ietf:params:restconf:capability:defaults:1.0?
basic-mode=explicit
This optional container provides access to the event streams supported by the server. The server MAY omit this container if no event streams are supported.
このオプションのコンテナは、サーバーがサポートするイベントストリームへのアクセスを提供します。イベントストリームがサポートされていない場合、サーバーはこのコンテナを省略してもよい（MAY）。
The server will populate this container with a "stream" list entry for each stream type it supports. Each stream contains a leaf called "events", which contains a URI that represents an event stream resource.
サーバーは、このコンテナに、サポートする各ストリームタイプの「ストリーム」リストエントリを入力します。各ストリームには、「イベント」と呼ばれるリーフが含まれています。リーフには、イベントストリームリソースを表すURIが含まれています。
Stream resources are defined in Section 3.8. Notifications are defined in Section 6.
ストリームリソースはセクション3.8で定義されています。通知はセクション6で定義されています。
The "ietf-restconf-monitoring" module defines monitoring information for the RESTCONF protocol.
「ietf-restconf-monitoring」モジュールはRESTCONFプロトコルの監視情報を定義します。
The "ietf-yang-types" and "ietf-inet-types" modules from [RFC6991] are used by this module for some type definitions.
[RFC6991]の「ietf-yang-types」および「ietf-inet-types」モジュールは、このモジュールによって一部の型定義に使用されます。
<CODE BEGINS>
<コード開始>
file "ietf-restconf-monitoring@2017-01-26.yang"
ファイル「ietf-restconf-monitoring@2017-01-26.yang」
module ietf-restconf-monitoring {
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring";
prefix "rcmon";
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; }
organization "IETF NETCONF (Network Configuration) Working Group";
組織「IETF NETCONF（ネットワーク構成）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Andy Bierman
<mailto:andy@yumaworks.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>";
description "This module contains monitoring information for the RESTCONF protocol.
説明「このモジュールには、RESTCONFプロトコルの監視情報が含まれています。
Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2017 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETFドキュメントに関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8040; see the RFC itself for full legal notices.";
このバージョンのYANGモジュールはRFC 8040の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2017-01-26 {
description
"Initial revision.";
reference
"RFC 8040: RESTCONF Protocol.";
}
container restconf-state {
config false;
description
"Contains RESTCONF protocol monitoring information.";
container capabilities {
description
"Contains a list of protocol capability URIs.";
leaf-list capability {
type inet:uri;
description
"A RESTCONF protocol capability URI.";
}
}
container streams {
description
"Container representing the notification event streams
supported by the server.";
reference
"RFC 5277, Section 3.4, <streams> element.";
list stream {
key name;
description
"Each entry describes an event stream supported by
the server.";
leaf name {
type string;
description
"The stream name.";
reference
"RFC 5277, Section 3.4, <name> element.";
}
leaf description {
type string;
description
"Description of stream content.";
reference
"RFC 5277, Section 3.4, <description> element.";
}
leaf replay-support {
type boolean;
default false;
description
"Indicates if replay buffer is supported for this stream.
If 'true', then the server MUST support the 'start-time'
and 'stop-time' query parameters for this stream.";
reference
"RFC 5277, Section 3.4, <replaySupport> element.";
}
leaf replay-log-creation-time {
when "../replay-support" {
description
"Only present if notification replay is supported.";
}
type yang:date-and-time;
description
"Indicates the time the replay log for this stream
was created.";
reference
"RFC 5277, Section 3.4, <replayLogCreationTime>
element.";
}
list access {
key encoding;
min-elements 1;
description
"The server will create an entry in this list for each
encoding format that is supported for this stream.
The media type 'text/event-stream' is expected
for all event streams. This list identifies the
subtypes supported for this stream.";
leaf encoding {
type string;
description
"This is the secondary encoding format within the
'text/event-stream' encoding used by all streams.
The type 'xml' is supported for XML encoding.
The type 'json' is supported for JSON encoding.";
}
leaf location {
type inet:uri;
mandatory true;
description
"Contains a URL that represents the entry point
for establishing notification delivery via
server-sent events.";
}
}
}
}
}
}
｝
<CODE ENDS>
<コード終了>
The "ietf-yang-library" module defined in [RFC7895] provides information about the YANG modules and submodules used by the RESTCONF server. Implementation is mandatory for RESTCONF servers. All YANG modules and submodules used by the server MUST be identified in the YANG module library.
[RFC7895]で定義されている「ietf-yang-library」モジュールは、RESTCONFサーバーが使用するYANGモジュールとサブモジュールに関する情報を提供します。 RESTCONFサーバーの実装は必須です。サーバーで使用されるすべてのYANGモジュールとサブモジュールは、YANGモジュールライブラリで識別される必要があります。
This mandatory list contains one entry for each YANG data model module supported by the server. There MUST be an instance of this list for every YANG module that is used by the server.
この必須リストには、サーバーでサポートされているYANGデータモデルモジュールごとに1つのエントリが含まれています。サーバーが使用するすべてのYANGモジュールごとに、このリストのインスタンスが必要です。
The contents of this list are defined in the "module" YANG list statement in [RFC7895].
このリストの内容は、[RFC7895]の「モジュール」YANGリストステートメントで定義されています。
Note that there are no protocol-accessible objects in the "ietf-restconf" module to implement, but it is possible that a server will list the "ietf-restconf" module in the YANG library if it is imported (directly or indirectly) by an implemented module.
実装する「ietf-restconf」モジュールにはプロトコルでアクセス可能なオブジェクトがないことに注意してください。ただし、サーバーが「直接または間接的に」インポートした場合、YANGライブラリに「ietf-restconf」モジュールがリストされる可能性があります。実装されたモジュール。
This specification registers the "restconf" relation type in the "Link Relation Types" registry defined by [RFC5988]:
この仕様は、[restconf]関係タイプを[RFC5988]によって定義された "Link Relation Types"レジストリに登録します。
Relation Name: restconf
関係名：restconf
Description: Identifies the root of the RESTCONF API as configured on this HTTP server. The "restconf" relation defines the root of the API defined in RFC 8040. Subsequent revisions of RESTCONF will use alternate relation values to support protocol versioning.
説明：このHTTPサーバーで構成されているRESTCONF APIのルートを識別します。 「restconf」関係は、RFC 8040で定義されたAPIのルートを定義します。RESTCONFの後続のリビジョンでは、代替の関係値を使用してプロトコルのバージョン管理をサポートします。
Reference: RFC 8040
リファレンス：RFC 8040
This document registers two URIs as namespaces in the "IETF XML Registry" [RFC3688]:
このドキュメントでは、「IETF XMLレジストリ」[RFC3688]に名前空間として2つのURIを登録しています。
URI: urn:ietf:params:xml:ns:yang:ietf-restconf Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-restconf登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
URI: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-restconf-monitoring登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
This document registers two YANG modules in the "YANG Module Names" registry [RFC6020]:
このドキュメントでは、「YANG Module Names」レジストリ[RFC6020]に2つのYANGモジュールを登録しています。
name: ietf-restconf
namespace: urn:ietf:params:xml:ns:yang:ietf-restconf
prefix: rc
reference: RFC 8040
name: ietf-restconf-monitoring
namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring
prefix: rcmon
reference: RFC 8040
Type name: application
タイプ名：アプリケーション
Subtype name: yang-data+xml
サブタイプ名：yang-data + xml
Required parameters: None
必須パラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [RFC7950].
エンコーディングに関する考慮事項：8ビット各概念的なYANGデータノードは、[RFC7950]で定義されている特定のYANGデータノードタイプのXMLエンコーディングルールと正規フォーマットに従ってエンコードされます。
Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section 12 of RFC 8040. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module.
セキュリティに関する考慮事項：RESTCONFメッセージの生成と消費に関連するセキュリティに関する考慮事項は、RFC 8040のセクション12で説明されています。追加のセキュリティに関する考慮事項は、特定のYANGデータモデルのセマンティクスに固有です。各YANGモジュールは、そのモジュールで定義されているYANGデータのセキュリティに関する考慮事項を指定することが期待されています。
Interoperability considerations: RFC 8040 specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：RFC 8040は、適合メッセージの形式とその解釈を指定しています。
Published specification: RFC 8040
公開された仕様：RFC 8040
Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG-defined data structures.
このメディアタイプを使用するアプリケーション：YANG定義のデータ構造を利用するプロトコルまたは自動化ツール内で使用されるインスタンスドキュメントデータパーサー。
Fragment identifier considerations: Fragment identifiers for this type are not defined. All YANG data nodes are accessible as resources using the path in the request URI.
フラグメントIDに関する考慮事項：このタイプのフラグメントIDは定義されていません。すべてのYANGデータノードは、リクエストURIのパスを使用してリソースとしてアクセスできます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): None
Macintosh file type code(s): "TEXT"
Person & email address to contact for further information: See the Authors' Addresses section of RFC 8040.
Person & email address to contact for further information: See the Authors' Addresses section of RFC 8040.
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: See the Authors' Addresses section of RFC 8040.
作成者：RFC 8040の「作成者のアドレス」セクションを参照してください。
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
変更管理者：Internet Engineering Task Force（mailto：iesg@ietf.org）。
Provisional registration? (standards tree only): no
仮登録？ （標準ツリーのみ）：いいえ
Type name: application
タイプ名：アプリケーション
Subtype name: yang-data+json
Subtype name: yang-data+json
Required parameters: None
必須パラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [RFC7951]. A metadata annotation is encoded according to [RFC7952].
エンコーディングに関する考慮事項：8ビット各概念的なYANGデータノードは、[RFC7951]に従ってエンコードされます。メタデータアノテーションは[RFC7952]に従ってエンコードされます。
Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section 12 of RFC 8040. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module.
セキュリティに関する考慮事項：RESTCONFメッセージの生成と消費に関連するセキュリティに関する考慮事項は、RFC 8040のセクション12で説明されています。追加のセキュリティに関する考慮事項は、特定のYANGデータモデルのセマンティクスに固有です。各YANGモジュールは、そのモジュールで定義されているYANGデータのセキュリティに関する考慮事項を指定することが期待されています。
Interoperability considerations: RFC 8040 specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：RFC 8040は、適合メッセージの形式とその解釈を指定しています。
Published specification: RFC 8040
公開された仕様：RFC 8040
Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG-defined data structures.
このメディアタイプを使用するアプリケーション：YANG定義のデータ構造を利用するプロトコルまたは自動化ツール内で使用されるインスタンスドキュメントデータパーサー。
Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as the syntax and semantics specified for the "application/json" media type.
フラグメント識別子の考慮事項：フラグメント識別子の構文とセマンティクスは、「application / json」メディアタイプに指定された構文とセマンティクスと同じです。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): None
Macintosh file type code(s): "TEXT"
Person & email address to contact for further information: See the Authors' Addresses section of RFC 8040.
詳細については、連絡先の個人と電子メールアドレス：RFC 8040の「作成者のアドレス」セクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: See the Authors' Addresses section of RFC 8040.
Author: See the Authors' Addresses section of RFC 8040.
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
変更管理者：Internet Engineering Task Force（mailto：iesg@ietf.org）。
Provisional registration? (standards tree only): no
仮登録？ （標準ツリーのみ）：いいえ
This document defines a registry for RESTCONF capability identifiers. The name of the registry is "RESTCONF Capability URNs". The review policy for this registry is "IETF Review" [RFC5226]. The registry shall record the following for each entry:
このドキュメントでは、RESTCONF機能識別子のレジストリを定義しています。レジストリの名前は「RESTCONF Capability URNs」です。このレジストリのレビューポリシーは「IETFレビュー」[RFC5226]です。レジストリは、エントリごとに以下を記録します。
o the name of the RESTCONF capability. By convention, this name begins with the colon (":") character.
o RESTCONF機能の名前。慣例により、この名前はコロン（ "："）文字で始まります。
o the URN for the RESTCONF capability.
o RESTCONF機能のURN。
o the reference for the document registering the value.
o 値を登録するドキュメントの参照。
This document registers several capability identifiers in the "RESTCONF Capability URNs" registry:
このドキュメントでは、「RESTCONF Capability URNs」レジストリにいくつかの機能識別子を登録しています。
Index Capability Identifier
---------------------------------------------------------------------
:defaults urn:ietf:params:restconf:capability:defaults:1.0
:depth urn:ietf:params:restconf:capability:depth:1.0
:fields urn:ietf:params:restconf:capability:fields:1.0
:filter urn:ietf:params:restconf:capability:filter:1.0
:replay urn:ietf:params:restconf:capability:replay:1.0
:with-defaults urn:ietf:params:restconf:capability:with-defaults:1.0
IANA has registered a new URN sub-namespace within the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry defined in [RFC3553].
IANAは、[RFC3553]で定義されている「IETF URN Sub-namespace for Registered Protocol Parameter Identifiers」レジストリ内に新しいURNサブ名前空間を登録しました。
Registry Name: restconf
レジストリ名：restconf
Specification: RFC 8040
仕様：RFC 8040
Repository: "RESTCONF Capability URNs" registry (Section 11.4)
リポジトリ：「RESTCONF Capability URNs」レジストリ（セクション11.4）
Index value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary.
インデックス値：サブパラメーターは、必要に応じて標準のURIエンコーディングを使用して、UTF-8で指定する必要があります。
Section 2.1 states that "a RESTCONF server MUST support the TLS protocol [RFC5246]." This language leaves open the possibility that a RESTCONF server might also support future versions of the TLS protocol. Of specific concern, TLS 1.3 [TLS1.3] introduces support for 0-RTT handshakes that can lead to security issues for RESTCONF APIs, as described in Appendix B.1 of the TLS 1.3 document. It is therefore RECOMMENDED that RESTCONF servers do not support 0-RTT at all (not even for idempotent requests) until an update to this RFC guides otherwise.
セクション2.1は、「RESTCONFサーバーはTLSプロトコル[RFC5246]をサポートしなければならない」と述べています。この言語は、RESTCONFサーバーがTLSプロトコルの将来のバージョンもサポートする可能性を残しています。特に懸念事項として、TLS 1.3 [TLS1.3]では、TLS 1.3ドキュメントの付録B.1で説明されているように、RESTCONF APIのセキュリティ問題につながる可能性がある0-RTTハンドシェイクのサポートが導入されています。したがって、RESTCONFサーバーは、このRFCの更新が別の方法でガイドするまで、（べき等の要求であっても）0-RTTをまったくサポートしないことをお勧めします。
Section 2.5 recommends authentication based on TLS client certificates but allows the use of any authentication scheme defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". Implementations need to be aware that the strengths of these methods vary greatly and that some may be considered experimental. Selection of any of these schemes SHOULD be performed after reading the Security Considerations section of the RFC associated with the scheme's registry entry.
セクション2.5では、TLSクライアント証明書に基づく認証を推奨していますが、「ハイパーテキスト転送プロトコル（HTTP）認証スキームレジストリ」で定義されている認証スキームを使用できます。実装では、これらのメソッドの長所が大きく異なり、一部は実験的なものと見なされる場合があることを認識する必要があります。これらのスキームの選択は、スキームのレジストリエントリに関連付けられているRFCの「セキュリティに関する考慮事項」セクションを読んだ後に実行する必要があります。
The "ietf-restconf-monitoring" YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content.
このメモで定義されている "ietf-restconf-monitoring" YANGモジュールは、NETCONFプロトコル[RFC6241]を介してアクセスされるように設計されています。最下層のNETCONF層はセキュアなトランスポート層であり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）[RFC6242]です。 NETCONFアクセス制御モデル[RFC6536]は、特定のNETCONFユーザーのアクセスを、利用可能なすべてのNETCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The RESTCONF protocol uses the NETCONF access control model [RFC6536], which provides the means to restrict access for particular RESTCONF users to a preconfigured subset of all available RESTCONF protocol operations and content.
最も低いRESTCONF層はHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC5246]です。 RESTCONFプロトコルはNETCONFアクセス制御モデル[RFC6536]を使用します。これは、特定のRESTCONFユーザーが利用可能なすべてのRESTCONFプロトコル操作とコンテンツの事前構成済みサブセットへのアクセスを制限する手段を提供します。
This section provides security considerations for the resources defined by the RESTCONF protocol. Security considerations for HTTPS are defined in [RFC7230]. Aside from the "ietf-restconf-monitoring" module (Section 9) and the "ietf-yang-library" module (Section 10), RESTCONF does not specify which YANG modules a server needs to support. Security considerations for the other modules manipulated by RESTCONF can be found in the documents defining those YANG modules.
このセクションでは、RESTCONFプロトコルで定義されたリソースのセキュリティに関する考慮事項について説明します。 HTTPSのセキュリティに関する考慮事項は、[RFC7230]で定義されています。 「ietf-restconf-monitoring」モジュール（セクション9）および「ietf-yang-library」モジュール（セクション10）を除いて、RESTCONFはサーバーがサポートする必要のあるYANGモジュールを指定しません。 RESTCONFによって操作される他のモジュールのセキュリティに関する考慮事項は、それらのYANGモジュールを定義するドキュメントに記載されています。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. There are many patterns of attack that have been observed through operational practice with existing management interfaces. It would be wise for implementers to research them and take them into account when implementing this protocol.
構成情報はその性質上非常に機密です。完全性チェックなしでクリアに送信されるため、デバイスは従来の盗聴や誤ったデータインジェクション攻撃にさらされます。多くの場合、構成情報には、パスワード、ユーザー名、サービスの説明、およびトポロジ情報が含まれますが、これらはすべて機密情報です。既存の管理インターフェースでの運用慣行を通じて観察された攻撃の多くのパターンがあります。このプロトコルを実装する際には、実装者がそれらを調査して考慮に入れることが賢明です。
Different environments may well allow different rights prior to, and then after, authentication. When a RESTCONF operation is not properly authorized, the RESTCONF server MUST return a "401 Unauthorized" status-line. Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection. Note that it is possible for a client to detect configuration changes in data resources it is not authorized to access by monitoring changes in the "ETag" and "Last-Modified" header fields returned by the server for the datastore resource.
異なる環境では、認証の前後に異なる権限が許可される場合があります。 RESTCONF操作が適切に承認されていない場合、RESTCONFサーバーは「401 Unauthorized」ステータス行を返さなければなりません（MUST）。許可情報は構成情報の形で交換できることに注意してください。これは、接続のセキュリティを確保するためのなおさらの理由です。クライアントは、データストアリソースのサーバーから返された「ETag」および「Last-Modified」ヘッダーフィールドの変更を監視することで、アクセスが許可されていないデータリソースの構成変更を検出できることに注意してください。
A RESTCONF server implementation SHOULD attempt to prevent system disruption due to excessive resource consumption required to fulfill edit requests via the POST, PUT, and PATCH methods. On such an implementation, it may be possible to construct an attack that attempts to consume all available memory or other resource types.
RESTCONFサーバーの実装は、POST、PUT、およびPATCHメソッドを介して編集リクエストを実行するために必要な過剰なリソース消費によるシステムの混乱を防止するよう試みるべきです（SHOULD）。このような実装では、利用可能なすべてのメモリまたは他のリソースタイプを消費しようとする攻撃を構築することが可能になる場合があります。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<http://www.rfc-editor.org / info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、 <http://www.rfc-editor.org/info/rfc3553>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, <http://www.rfc-editor.org/info/rfc5277>.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、DOI 10.17487 / RFC5277、2008年7月、<http://www.rfc-editor.org/info/rfc5277>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <http://www.rfc-editor.org/info/rfc5789>.
[RFC5789] Dusseault、L.およびJ. Snell、「PATCH Method for HTTP」、RFC 5789、DOI 10.17487 / RFC5789、2010年3月、<http://www.rfc-editor.org/info/rfc5789>。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <http://www.rfc-editor.org/info/rfc5988>.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、DOI 10.17487 / RFC5988、2010年10月、<http://www.rfc-editor.org/info/rfc5988>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<http：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「Secure Shell（SSH）を介したNETCONFプロトコルの使用」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<http://www.rfc-editor.org/info/rfc6242>。
[RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, <http://www.rfc-editor.org/info/rfc6243>.
[RFC6243] Bierman、A。およびB. Lengyel、「NETCONFのデフォルト機能」、RFC 6243、DOI 10.17487 / RFC6243、2011年6月、<http://www.rfc-editor.org/info/rfc6243>。
[RFC6415] Hammer-Lahav, E., Ed., and B. Cook, "Web Host Metadata", RFC 6415, DOI 10.17487/RFC6415, October 2011, <http://www.rfc-editor.org/info/rfc6415>.
[RFC6415] Hammer-Lahav、E.、Ed。、およびB. Cook、「Web Host Metadata」、RFC 6415、DOI 10.17487 / RFC6415、2011年10月、<http://www.rfc-editor.org/info/ rfc6415>。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、DOI 10.17487 / RFC6536、2012年3月、<http://www.rfc-editor.org/info/ rfc6536>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <http://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<http://www.rfc-editor.org/info/rfc6991>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<http：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content"、RFC 7231、DOI 10.17487 / RFC7231、June 2014、<http：// www.rfc-editor.org/info/rfc7231>。
[RFC7232] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests"、RFC 7232、DOI 10.17487 / RFC7232、June 2014、<http：// www .rfc-editor.org / info / rfc7232>。
[RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Authentication"、RFC 7235、DOI 10.17487 / RFC7235、June 2014、<http：// www。 rfc-editor.org/info/rfc7235>。
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <http://www.rfc-editor.org/info/rfc7320>.
[RFC7320]ノッティンガム、M。、「URI Design and Ownership」、BCP 190、RFC 7320、DOI 10.17487 / RFC7320、2014年7月、<http://www.rfc-editor.org/info/rfc7320>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, <http://www.rfc-editor.org/info/rfc7589>.
[RFC7589] Badra、M.、Luchuk、A。、およびJ. Schoenwaelder、「トランスポート層セキュリティ（TLS）での相互X.509認証でのNETCONFプロトコルの使用」、RFC 7589、DOI 10.17487 / RFC7589、2015年6月、< http://www.rfc-editor.org/info/rfc7589>。
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, <http://www.rfc-editor.org/info/rfc7895>.
[RFC7895] Bierman、A.、Bjorklund、M。、およびK. Watsen、「YANG Module Library」、RFC 7895、DOI 10.17487 / RFC7895、2016年6月、<http://www.rfc-editor.org/info/ rfc7895>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<http://www.rfc-editor.org/info/rfc7950>。
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <http://www.rfc-editor.org/info/rfc7951>.
[RFC7951] Lhotka、L。、「YANGでモデル化されたデータのJSONエンコーディング」、RFC 7951、DOI 10.17487 / RFC7951、2016年8月、<http://www.rfc-editor.org/info/rfc7951>。
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, <http://www.rfc-editor.org/info/rfc7952>.
[RFC7952] Lhotka、L。、「YANGを使用したメタデータの定義と使用」、RFC 7952、DOI 10.17487 / RFC7952、2016年8月、<http://www.rfc-editor.org/info/rfc7952>。
[W3C.REC-eventsource-20150203] Hickson, I., "Server-Sent Events", World Wide Web Consortium Recommendation REC-eventsource-20150203, February 2015, <http://www.w3.org/TR/2015/REC-eventsource-20150203>.
[W3C.REC-eventsource-20150203] Hickson、I.、 "Server-Sent Events"、World Wide Web Consortium Recommendation REC-eventsource-20150203、February 2015、<http://www.w3.org/TR/2015/ REC-eventsource-20150203>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]ブレイ、T。、パオリ、J.、Sperberg-McQueen、M。、マラー、E。、およびF.イェルガウ、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPath] Clark、J.およびS. DeRose、「XML Path Language（XPath）Version 1.0」、World Wide Web Consortium Recommendation REC-xpath-19991116、1999年11月、<http://www.w3.org/TR/ 1999 / REC-xpath-19991116>。
[REST-Dissertation] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[REST論文]フィールディング、R。、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、2000年。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-18, October 2016.
[TLS1.3] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、Work in Progress、draft-ietf-tls-tls13-18、2016年10月。
[YANG-Patch] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch Media Type", Work in Progress, draft-ietf-netconf-yang-patch-14, November 2016.
[YANG-Patch] Bierman、A.、Bjorklund、M。、およびK. Watsen、「YANG Patch Media Type」、Work in Progress、draft-ietf-netconf-yang-patch-14、2016年11月。
The example YANG module used in this document represents a simple media jukebox interface.
このドキュメントで使用されているYANGモジュールの例は、シンプルなメディアジュークボックスインターフェースを表しています。
YANG tree diagram for the "example-jukebox" module:
YANG tree diagram for the "example-jukebox" module:
+--rw jukebox!
+--rw library
| +--rw artist* [name]
| | +--rw name string
| | +--rw album* [name]
| | +--rw name string
| | +--rw genre? identityref
| | +--rw year? uint16
| | +--rw admin
| | | +--rw label? string
| | | +--rw catalogue-number? string
| | +--rw song* [name]
| | +--rw name string
| | +--rw location string
| | +--rw format? string
| | +--rw length? uint32
| +--ro artist-count? uint32
| +--ro album-count? uint32
| +--ro song-count? uint32
+--rw playlist* [name]
| +--rw name string
| +--rw description? string
| +--rw song* [index]
| +--rw index uint32
| +--rw id instance-identifier
+--rw player
+--rw gap? decimal64
rpcs:
rpcs:
+---x play
+--ro input
+--ro playlist string
+--ro song-number uint32
module example-jukebox {
module example-jukebox {
namespace "http://example.com/ns/example-jukebox";
prefix "jbox";
organization "Example, Inc.";
contact "support at example.com";
description "Example Jukebox Data Model Module.";
revision "2016-08-15" {
description "Initial version.";
reference "example.com document 1-4673.";
}
identity genre {
description
"Base for all genre types.";
}
// abbreviated list of genre classifications
identity alternative {
base genre;
description
"Alternative music.";
}
identity blues {
base genre;
description
"Blues music.";
}
identity country {
base genre;
description
"Country music.";
}
identity jazz {
base genre;
description
"Jazz music.";
}
identity pop {
base genre;
description
"Pop music.";
}
identity rock {
base genre;
description
"Rock music.";
}
container jukebox {
presence
"An empty container indicates that the jukebox
service is available.";
description "Represents a 'jukebox' resource, with a library, playlists, and a 'play' operation.";
説明「ライブラリ、プレイリスト、および「再生」操作を含む「ジュークボックス」リソースを表します。」;
container library {
container library {
description "Represents the 'jukebox' library resource.";
説明「「ジュークボックス」ライブラリリソースを表します。」;
list artist {
key name;
description
"Represents one 'artist' resource within the
'jukebox' library resource.";
leaf name {
type string {
length "1 .. max";
}
description
"The name of the artist.";
}
list album {
key name;
description
"Represents one 'album' resource within one
'artist' resource, within the jukebox library.";
leaf name {
type string {
length "1 .. max";
}
description
"The name of the album.";
}
leaf genre {
type identityref { base genre; }
description
"The genre identifying the type of music on
the album.";
}
leaf year {
type uint16 {
range "1900 .. max";
}
description
"The year the album was released.";
}
container admin {
description
"Administrative information for the album.";
leaf label {
type string;
description
"The label that released the album.";
}
leaf catalogue-number {
type string;
description
"The album's catalogue number.";
}
}
list song {
key name;
description
"Represents one 'song' resource within one
'album' resource, within the jukebox library.";
leaf name {
type string {
length "1 .. max";
}
description
"The name of the song.";
}
leaf location {
type string;
mandatory true;
description
"The file location string of the
media file for the song.";
}
leaf format {
type string;
description
"An identifier string for the media type
for the file associated with the
'location' leaf for this entry.";
}
leaf length {
type uint32;
units "seconds";
description
"The duration of this song in seconds.";
}
} // end list 'song'
} // end list 'album'
} // end list 'artist'
leaf artist-count {
type uint32;
units "artists";
config false;
description
"Number of artists in the library.";
}
leaf album-count {
type uint32;
units "albums";
config false;
description
"Number of albums in the library.";
}
leaf song-count {
type uint32;
units "songs";
config false;
description
"Number of songs in the library.";
}
} // end library
list playlist {
key name;
description
"Example configuration data resource.";
leaf name {
type string;
description
"The name of the playlist.";
}
leaf description {
type string;
description
"A comment describing the playlist.";
}
list song {
key index;
ordered-by user;
description "Example nested configuration data resource.";
説明 "ネストされた構成データリソースの例。";
leaf index { // not really needed
type uint32;
description
"An arbitrary integer index for this playlist song.";
}
leaf id {
type instance-identifier;
mandatory true;
description
"Song identifier. Must identify an instance of
/jukebox/library/artist/album/song/name.";
}
}
}
container player {
description
"Represents the jukebox player resource.";
leaf gap {
type decimal64 {
fraction-digits 1;
range "0.0 .. 2.0";
}
units "tenths of seconds";
description
"Time gap between each song.";
}
}
}
rpc play {
description
"Control function for the jukebox player.";
input {
leaf playlist {
type string;
mandatory true;
description
"The playlist name.";
}
leaf song-number {
type uint32;
mandatory true;
description
"Song number in playlist to play.";
}
}
}
}
The examples within this document use the normative YANG module "ietf-restconf" as defined in Section 8 and the non-normative example YANG module "example-jukebox" as defined in Appendix A.1.
このドキュメント内の例では、セクション8で定義されている標準のYANGモジュール「ietf-restconf」と、付録A.1で定義されている非標準の例YANGモジュール「example-jukebox」を使用しています。
This section shows some typical RESTCONF message exchanges.
このセクションでは、いくつかの典型的なRESTCONFメッセージ交換を示します。
The client starts by retrieving the RESTCONF root resource:
クライアントはRESTCONFルートリソースを取得することから始めます。
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/restconf'/>
</XRD>
The client may then retrieve the top-level API resource, using the root resource "/restconf".
クライアントは、ルートリソース「/ restconf」を使用して、トップレベルのAPIリソースを取得できます。
GET /restconf HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"ietf-restconf:restconf" : {
"data" : {},
"operations" : {},
"yang-library-version" : "2016-06-21"
}
}
To request that the response content be encoded in XML, the "Accept" header can be used, as in this example request:
応答コンテンツをXMLでエンコードするように要求するには、次の要求例のように、「Accept」ヘッダーを使用できます。
GET /restconf HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server will return the same conceptual data either way, which might be as follows:
サーバーはどちらの方法でも同じ概念データを返します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+xml
<restconf xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<data/>
<operations/>
<yang-library-version>2016-06-21</yang-library-version>
</restconf>
It is possible that the YANG library module will change over time. The client can retrieve the revision date of the "ietf-yang-library" module supported by the server from the API resource, as described in the previous section.
YANGライブラリモジュールは、時間の経過とともに変化する可能性があります。前のセクションで説明したように、クライアントはサーバーがサポートする「ietf-yang-library」モジュールの改訂日をAPIリソースから取得できます。
In this example, the client is retrieving the module information from the server in JSON format:
この例では、クライアントはサーバーからモジュール情報をJSON形式で取得しています。
GET /restconf/data/ietf-yang-library:modules-state HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Last-Modified: Thu, 26 Jan 2017 14:00:14 GMT
Content-Type: application/yang-data+json
{
"ietf-yang-library:modules-state" : {
"module-set-id" : "5479120c17a619545ea6aff7aa19838b036ebbd7",
"module" : [
{
"name" : "foo",
"revision" : "2012-01-02",
"schema" : "https://example.com/modules/foo/2012-01-02",
"namespace" : "http://example.com/ns/foo",
"feature" : [ "feature1", "feature2" ],
"deviation" : [
{
"name" : "foo-dev",
"revision" : "2012-02-16"
}
],
"conformance-type" : "implement"
},
{
"name" : "ietf-yang-library",
"revision" : "2016-06-21",
"schema" : "https://example.com/modules/\
ietf-yang-library/2016-06-21",
"namespace" :
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type" : "implement"
},
{
"name" : "foo-types",
"revision" : "2012-01-05",
"schema" :
"https://example.com/modules/foo-types/2012-01-05",
"namespace" : "http://example.com/ns/foo-types",
"conformance-type" : "import"
},
{
"name" : "bar",
"revision" : "2012-11-05",
"schema" : "https://example.com/modules/bar/2012-11-05",
"namespace" : "http://example.com/ns/bar",
"feature" : [ "bar-ext" ],
"conformance-type" : "implement",
"submodule" : [
{
"name" : "bar-submod1",
"revision" : "2012-11-05",
"schema" :
"https://example.com/modules/bar-submod1/2012-11-05"
},
{
"name" : "bar-submod2",
"revision" : "2012-11-05",
"schema" :
"https://example.com/modules/bar-submod2/2012-11-05"
}
]
}
]
}
}
In this example, the client is retrieving the capability information from the server in XML format, and the server supports all of the RESTCONF query parameters, plus one vendor parameter:
この例では、クライアントはサーバーからXML形式で機能情報を取得しており、サーバーはすべてのRESTCONFクエリパラメーターと1つのベンダーパラメーターをサポートしています。
GET /restconf/data/ietf-restconf-monitoring:restconf-state/\
capabilities HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
Content-Type: application/yang-data+xml
<capabilities
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">
<capability>\
urn:ietf:params:restconf:capability:defaults:1.0?\
basic-mode=explicit\
</capability>
<capability>\
urn:ietf:params:restconf:capability:with-defaults:1.0\
</capability>
<capability>\
urn:ietf:params:restconf:capability:depth:1.0\
</capability>
<capability>\
urn:ietf:params:restconf:capability:fields:1.0\
</capability>
<capability>\
urn:ietf:params:restconf:capability:filter:1.0\
</capability>
<capability>\
urn:ietf:params:restconf:capability:start-time:1.0\
</capability>
<capability>\
urn:ietf:params:restconf:capability:stop-time:1.0\
</capability>
<capability>\
http://example.com/capabilities/myparam\
</capability>
</capabilities>
To create a new "artist" resource within the "library" resource, the client might send the following request:
「library」リソース内に新しい「artist」リソースを作成するために、クライアントは次のリクエストを送信する場合があります。
POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:artist" : [
{
"name" : "Foo Fighters"
}
]
}
If the resource is created, the server might respond as follows:
リソースが作成されると、サーバーは次のように応答する場合があります。
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Location: https://example.com/restconf/data/\
example-jukebox:jukebox/library/artist=Foo%20Fighters
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b3830f23a4c"
To create a new "album" resource for this artist within the "jukebox" resource, the client might send the following request:
このアーティストの新しい「アルバム」リソースを「ジュークボックス」リソース内に作成するには、クライアントが次のリクエストを送信します。
POST /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox">
<name>Wasting Light</name>
<year>2011</year>
</album>
If the resource is created, the server might respond as follows:
リソースが作成されると、サーバーは次のように応答する場合があります。
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Location: https://example.com/restconf/data/\
example-jukebox:jukebox/library/artist=Foo%20Fighters/\
album=Wasting%20Light
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b8389233a4c"
In this example, the server just supports the datastore last-changed timestamp. Assume that the client has cached the "Last-Modified" header from the response to the previous request. This value is used as in the "If-Unmodified-Since" header in the following request to patch an "album" list entry with a key value of "Wasting Light". Only the "genre" field is being updated.
この例では、サーバーはデータストアの最後に変更されたタイムスタンプのみをサポートしています。クライアントが前の要求への応答からの「Last-Modified」ヘッダーをキャッシュしたと想定します。この値は、次のリクエストの「If-Unmodified-Since」ヘッダーのように使用され、「アルバム」リストのエントリに「Wasting Light」というキー値をパッチします。 「ジャンル」フィールドのみが更新されています。
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light/\
genre HTTP/1.1
Host: example.com
If-Unmodified-Since: Thu, 26 Jan 2017 20:56:30 GMT
Content-Type: application/yang-data+json
{ "example-jukebox:genre" : "example-jukebox:alternative" }
In this example, the datastore resource has changed since the time specified in the "If-Unmodified-Since" header. The server might respond as follows:
この例では、「If-Unmodified-Since」ヘッダーで指定された時間以降にデータストアリソースが変更されています。サーバーは次のように応答します。
HTTP/1.1 412 Precondition Failed
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 19:41:00 GMT
ETag: "b34aed893a4c"
In this example, assume that there is a top-level data resource named "system" from the example-system module, and this container has a child leaf called "enable-jukebox-streaming":
この例では、example-systemモジュールからの「system」というトップレベルのデータリソースがあり、このコンテナには「enable-jukebox-streaming」という子リーフがあると想定します。
container system {
leaf enable-jukebox-streaming {
type boolean;
}
}
In this example, PATCH is used by the client to modify two top-level resources at once, in order to enable jukebox streaming and add an "album" sub-resource to each of two "artist" resources:
この例では、クライアントはPATCHを使用して2つのトップレベルリソースを一度に変更し、ジュークボックスストリーミングを有効にして、「アルバム」サブリソースを2つの「アーティスト」リソースのそれぞれに追加します。
PATCH /restconf/data HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<system xmlns="http://example.com/ns/example-system">
<enable-jukebox-streaming>true</enable-jukebox-streaming>
</system>
<jukebox xmlns="http://example.com/ns/example-jukebox">
<library>
<artist>
<name>Foo Fighters</name>
<album>
<name>One by One</name>
<year>2012</year>
</album>
</artist>
<artist>
<name>Nick Cave and the Bad Seeds</name>
<album>
<name>Tender Prey</name>
<year>1988</year>
</album>
</artist>
</library>
</jukebox>
</data>
In this example, the entire configuration datastore contents are being replaced. Any child nodes not present in the <data> element but present in the server will be deleted.
この例では、構成データストアのコンテンツ全体が置き換えられています。 <data>要素には存在しないがサーバーには存在する子ノードは削除されます。
PUT /restconf/data HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<jukebox xmlns="http://example.com/ns/example-jukebox">
<library>
<artist>
<name>Foo Fighters</name>
<album>
<name>One by One</name>
<year>2012</year>
</album>
</artist>
<artist>
<name>Nick Cave and the Bad Seeds</name>
<album>
<name>Tender Prey</name>
<year>1988</year>
</album>
</artist>
</library>
</jukebox>
</data>
In this example, the client modifies one data node by adding an "album" sub-resource by sending a PATCH for the data resource:
この例では、クライアントは、データリソースのPATCHを送信して「アルバム」サブリソースを追加することにより、1つのデータノードを変更します。
PATCH /restconf/data/example-jukebox:jukebox/library/\
artist=Nick%20Cave%20and%20the%20Bad%20Seeds HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<artist xmlns="http://example.com/ns/example-jukebox">
<name>Nick Cave and the Bad Seeds</name>
<album>
<name>The Good Son</name>
<year>1990</year>
</album>
</artist>
The "content" parameter is used to select the types of data child resources (configuration and/or non-configuration) that are returned by the server for a GET method request.
「コンテンツ」パラメーターは、GETメソッド要求に対してサーバーから返されるデータ子リソースのタイプ（構成または非構成、あるいはその両方）を選択するために使用されます。
In this example, a simple YANG list is used that has configuration and non-configuration child resources.
In this example, a simple YANG list is used that has configuration and non-configuration child resources.
container events {
list event {
key name;
leaf name { type string; }
leaf description { type string; }
leaf event-count {
type uint32;
config false;
}
}
}
Example 1: content=all
例1：content = all
To retrieve all of the child resources, the "content" parameter is set to "all", or omitted, since this is the default value. The client might send the following:
すべての子リソースを取得するには、これがデフォルト値であるため、「content」パラメーターを「all」に設定するか、省略します。クライアントは以下を送信する場合があります。
GET /restconf/data/example-events:events?\
content=all HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-events:events" : {
"event" : [
{
"name" : "interface-up",
"description" : "Interface up notification count",
"event-count" : 42
},
{
"name" : "interface-down",
"description" : "Interface down notification count",
"event-count" : 4
}
]
}
}
Example 2: content=config
例2：content = config
To retrieve only the configuration child resources, the "content" parameter is set to "config". Note that the "ETag" and "Last-Modified" headers are only returned if the "content" parameter value is "config".
構成の子リソースのみを取得するには、「content」パラメーターを「config」に設定します。 「ETag」および「Last-Modified」ヘッダーは、「content」パラメーター値が「config」の場合にのみ返されることに注意してください。
GET /restconf/data/example-events:events?\
content=config HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 16:45:20 GMT
ETag: "eeeada438af"
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-events:events" : {
"event" : [
{
"name" : "interface-up",
"description" : "Interface up notification count"
},
{
"name" : "interface-down",
"description" : "Interface down notification count"
}
]
}
}
Example 3: content=nonconfig
例3：content = nonconfig
To retrieve only the non-configuration child resources, the "content" parameter is set to "nonconfig". Note that configuration ancestors (if any) and list key leafs (if any) are also returned. The client might send the following:
To retrieve only the non-configuration child resources, the "content" parameter is set to "nonconfig". Note that configuration ancestors (if any) and list key leafs (if any) are also returned. The client might send the following:
GET /restconf/data/example-events:events?\
content=nonconfig HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-events:events" : {
"event" : [
{
"name" : "interface-up",
"event-count" : 42
},
{
"name" : "interface-down",
"event-count" : 4
}
]
}
}
The "depth" parameter is used to limit the number of levels of child resources that are returned by the server for a GET method request.
「深さ」パラメーターは、GETメソッド要求に対してサーバーから返される子リソースのレベル数を制限するために使用されます。
The "depth" parameter starts counting levels at the level of the target resource that is specified, so that a depth level of "1" includes just the target resource level itself. A depth level of "2" includes the target resource level and its child nodes.
The "depth" parameter starts counting levels at the level of the target resource that is specified, so that a depth level of "1" includes just the target resource level itself. A depth level of "2" includes the target resource level and its child nodes.
This example shows how different values of the "depth" parameter would affect the reply content for the retrieval of the top-level "jukebox" data resource.
この例は、「depth」パラメーターのさまざまな値が、トップレベルの「ジュークボックス」データリソースを取得するための応答コンテンツにどのように影響するかを示しています。
Example 1: depth=unbounded
例1：depth = unbounded
To retrieve all of the child resources, the "depth" parameter is not present or is set to the default value "unbounded".
すべての子リソースを取得するには、 "depth"パラメーターが存在しないか、デフォルト値の "unbounded"に設定されています。
GET /restconf/data/example-jukebox:jukebox?\
depth=unbounded HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-jukebox:jukebox" : {
"library" : {
"artist" : [
{
"name" : "Foo Fighters",
"album" : [
{
"name" : "Wasting Light",
"genre" : "example-jukebox:alternative",
"year" : 2011,
"song" : [
{
"name" : "Wasting Light",
"location" :
"/media/foo/a7/wasting-light.mp3",
"format" : "MP3",
"length" : 286
},
{
"name" : "Rope",
"location" : "/media/foo/a7/rope.mp3",
"format" : "MP3",
"length" : 259
}
]
}
]
}
]
},
"playlist" : [
{
"name" : "Foo-One",
"description" : "example playlist 1",
"song" : [
{
"index" : 1,
"id" : "/example-jukebox:jukebox/library\
/artist[name='Foo Fighters']\
/album[name='Wasting Light']\
/song[name='Rope']"
},
{
"index" : 2,
"id" : "/example-jukebox:jukebox/library\
/artist[name='Foo Fighters']\
/album[name='Wasting Light']\
/song[name='Bridge Burning']"
}
]
}
],
"player" : {
"gap" : 0.5
}
}
}
Example 2: depth=1
例2：depth = 1
To determine if one or more resource instances exist for a given target resource, the value "1" is used.
特定のターゲットリソースに1つ以上のリソースインスタンスが存在するかどうかを判断するには、値「1」を使用します。
GET /restconf/data/example-jukebox:jukebox?depth=1 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-jukebox:jukebox" : {}
}
Example 3: depth=3
例3：depth = 3
To limit the depth level to the target resource plus two child resource layers, the value "3" is used.
深度レベルをターゲットリソースと2つの子リソースレイヤーに制限するには、値「3」を使用します。
GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-jukebox:jukebox" : {
"library" : {
"artist" : {}
},
"playlist" : [
{
"name" : "Foo-One",
"description" : "example playlist 1",
"song" : {}
}
],
"player" : {
"gap" : 0.5
}
}
}
In this example, the client is retrieving the datastore resource in JSON format, but retrieving only the "modules-state/module" list, and only the "name" and "revision" nodes from each list entry. Note that the top node returned by the server matches the target resource node (which is "data" in this example). The "module-set-id" leaf is not returned because it is not selected in the fields expression.
この例では、クライアントはJSON形式でデータストアリソースを取得していますが、「modules-state / module」リストと、各リストエントリから「name」ノードと「revision」ノードのみを取得しています。サーバーから返される最上位ノードはターゲットリソースノード（この例では「データ」）と一致することに注意してください。 「module-set-id」リーフは、フィールド式で選択されていないため返されません。
GET /restconf/data?fields=ietf-yang-library:modules-state/\
module(name;revision) HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"ietf-restconf:data" : {
"ietf-yang-library:modules-state" : {
"module" : [
{
"name" : "example-jukebox",
"revision" : "2016-08-15"
},
{
"name" : "ietf-inet-types",
"revision" : "2013-07-15"
},
{
"name" : "ietf-restconf-monitoring",
"revision" : "2017-01-26"
},
{
"name" : "ietf-yang-library",
"revision" : "2016-06-21"
},
{
"name" : "ietf-yang-types",
"revision" : "2013-07-15"
}
]
}
}
}
In this example, a new first song entry in the "Foo-One" playlist is being created.
この例では、「Foo-One」プレイリストの新しい最初の曲エントリが作成されています。
Request from client:
クライアントからのリクエスト：
POST /restconf/data/example-jukebox:jukebox/\
playlist=Foo-One?insert=first HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:song" : [
{
"index" : 1,
"id" : "/example-jukebox:jukebox/library\
/artist[name='Foo Fighters']\
/album[name='Wasting Light']\
/song[name='Rope']"
}
]
}
Response from server:
サーバーからの応答：
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
Location: https://example.com/restconf/data/\
example-jukebox:jukebox/playlist=Foo-One/song=1
ETag: "eeeada438af"
In this example, the client is inserting a new song entry in the "Foo-One" playlist after the first song.
この例では、クライアントは「Foo-One」プレイリストの最初の曲の後に新しい曲のエントリを挿入しています。
Request from client:
クライアントからのリクエスト：
POST /restconf/data/example-jukebox:jukebox/\
playlist=Foo-One?insert=after&point=\
%2Fexample-jukebox%3Ajukebox\
%2Fplaylist%3DFoo-One%2Fsong%3D1 HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:song" : [
{
"index" : 2,
"id" : "/example-jukebox:jukebox/library\
/artist[name='Foo Fighters']\
/album[name='Wasting Light']\
/song[name='Bridge Burning']"
}
]
}
Response from server:
サーバーからの応答：
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
Location: https://example.com/restconf/data/\
example-jukebox:jukebox/playlist=Foo-One/song=2
ETag: "abcada438af"
The following URIs show some examples of notification filter specifications:
次のURIは、通知フィルター仕様のいくつかの例を示しています。
// filter = /event/event-class='fault'
GET /streams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault'
// filter = /event/severity<=4
GET /streams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4
// filter = /linkUp|/linkDown
GET /streams/SNMP?filter=%2FlinkUp%7C%2FlinkDown
// filter = /*/reporting-entity/card!='Ethernet0'
GET /streams/NETCONF?\
filter=%2F*%2Freporting-entity%2Fcard%21%3D'Ethernet0'
// filter = /*/email-addr[contains(.,'company.com')]
GET /streams/critical-syslog?\
filter=%2F*%2Femail-addr[contains(.%2C'company.com')]
// Note: The module name is used as the prefix.
// filter = (/example-mod:event1/name='joe' and
// /example-mod:event1/status='online')
GET /streams/NETCONF?\
filter=(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and\
%20%2Fexample-mod%3Aevent1%2Fstatus%3D'online')
// To get notifications from just two modules (e.g., m1 + m2)
// filter=(/m1:* or /m2:*)
GET /streams/NETCONF?filter=(%2Fm1%3A*%20or%20%2Fm2%3A*)
The following URI shows an example of the "start-time" query parameter:
次のURIは、「start-time」クエリパラメータの例を示しています。
// start-time = 2014-10-25T10:02:00Z
GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z
The following URI shows an example of the "stop-time" query parameter:
次のURIは、「stop-time」クエリパラメータの例を示しています。
// start-time = 2014-10-25T10:02:00Z
// stop-time = 2014-10-25T12:31:00Z
GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\
&stop-time=2014-10-25T12%3A31%3A00Z
Assume that the server implements the module "example" defined in Appendix A.1 of [RFC6243], and assume that the server's datastore is as defined in Appendix A.2 of [RFC6243].
サーバーが[RFC6243]の付録A.1で定義されているモジュール「例」を実装し、サーバーのデータストアが[RFC6243]の付録A.2で定義されていると仮定します。
If the server's "basic-mode" parameter in the "defaults" protocol capability URI (Section 9.1.2) is "trim", the following request for interface "eth1" might be as follows:
「defaults」プロトコル機能URI（セクション9.1.2）のサーバーの「basic-mode」パラメータが「trim」の場合、インターフェース「eth1」に対する次のリクエストは次のようになる可能性があります。
Without query parameter:
クエリパラメータなし：
GET /restconf/data/example:interfaces/interface=eth1 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"example:interface" : [
{
"name" : "eth1",
"status" : "up"
}
]
}
Note that the "mtu" leaf is missing because it is set to the default "1500", and the server's default-handling "basic-mode" parameter is "trim".
「mtu」リーフはデフォルトの「1500」に設定されており、サーバーのデフォルト処理の「basic-mode」パラメーターは「trim」であるため、欠落していることに注意してください。
With query parameter:
クエリパラメータ：
GET /restconf/data/example:interfaces/interface=eth1\
?with-defaults=report-all HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{
"example:interface" : [
{
"name" : "eth1",
"mtu" : 1500,
"status" : "up"
}
]
}
Note that the server returns the "mtu" leaf because the "report-all" mode was requested with the "with-defaults" query parameter.
Note that the server returns the "mtu" leaf because the "report-all" mode was requested with the "with-defaults" query parameter.
Acknowledgements
謝辞
The authors would like to thank the following people for their contributions to this document: Ladislav Lhotka, Juergen Schoenwaelder, Rex Fernando, Robert Wilton, and Jonathan Hansford.
著者は、このドキュメントへの貢献に対して次の人々に感謝します：Ladislav Lhotka、Juergen Schoenwaelder、Rex Fernando、Robert Wilton、Jonathan Hansford。
The authors would like to thank the following people for their excellent technical reviews of this document: Mehmet Ersue, Mahesh Jethanandani, Qin Wu, Joe Clarke, Bert Wijnen, Ladislav Lhotka, Rodney Cummings, Frank Xialiang, Tom Petch, Robert Sparks, Balint Uveges, Randy Presuhn, Sue Hares, Mark Nottingham, Benoit Claise, Dale Worley, and Lionel Morand.
著者は、このドキュメントの優れた技術レビューを提供してくれた以下の人々に感謝します：Mehmet Ersue、Mahesh Jethanandani、Qin Wu、Joe Clarke、Bert Wijnen、Ladislav Lhotka、Rodney Cummings、Frank Xialiang、Tom Petch、Robert Sparks、Balint Uveges 、ランディプレスーン、スーヘアーズ、マークノッティンガム、ブノワクレイズ、デールウォーリー、ライオネルモランド。
Contributions to this material by Andy Bierman are based upon work supported by the United States Army, Space & Terrestrial Communications Directorate (S&TCD) under Contract No. W15P7T-13-C-A616. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the S&TCD.
Andy Biermanによるこの資料への貢献は、契約番号W15P7T-13-C-A616に基づいて米国陸海宇宙通信総局（S＆TCD）がサポートする作業に基づいています。この資料に記載されている意見、調査結果、結論または推奨事項は著者のものであり、必ずしもS＆TCDの見解を反映しているわけではありません。
Authors' Addresses
著者のアドレス
Andy Bierman YumaWorks
アンディ・ビアマンYumaWorks
Email: andy@yumaworks.com
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com
Kent Watsen Juniper Networks
ケントワトセンジュニパーネットワークス
Email: kwatsen@juniper.net