RFC 8527 - RESTCONF Extensions to Support the Network Management Datastore Architecture 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8527
タイトル : RFC 8527 - ネットワーク管理データストアアーキテクチャをサポートするRESTCONF拡張
翻訳編集 : 自動生成

[要約] RFC 8527は、RESTCONFを拡張してネットワーク管理データストアアーキテクチャをサポートするためのものです。その目的は、ネットワークデバイスの設定や状態情報を効果的に管理するための標準化された手法を提供することです。

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8527                                Tail-f Systems
Updates: 8040                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                        Juniper Networks
                                                               K. Watsen
                                                         Watsen Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2019

RESTCONF Extensions to Support the Network Management Datastore Architecture

ネットワーク管理データストアアーキテクチャをサポートするRESTCONF拡張

Abstract

概要

This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

このドキュメントは、RFC 8342で定義されたネットワーク管理データストアアーキテクチャ（NMDA）をサポートするために、RFC 8040で定義されたRESTCONFプロトコルを拡張します。

This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.

このドキュメントでは、新しいデータストアリソースを導入し、新しいクエリパラメータを追加し、NMDAを実装するRESTCONFサーバーによるYANGライブラリ（RFC 8525で説明）の使用を要求することにより、RFC 8040を更新します。

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 https://www.rfc-editor.org/info/rfc8527.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8527で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Datastore and YANG Library Requirements .........................3
   3. RESTCONF Extensions .............................................4
      3.1. New Datastore Resources ....................................4
      3.2. Protocol Operations ........................................5
           3.2.1. The "with-defaults" Query Parameter on the
                  Operational State Datastore .........................5
           3.2.2. New "with-origin" Query Parameter ...................6
   4. IANA Considerations .............................................7
   5. Security Considerations .........................................7
   6. Normative References ............................................7
   Authors' Addresses .................................................9

1. Introduction

1. はじめに

This document extends the RESTCONF protocol defined in [RFC8040] in order to support the Network Management Datastore Architecture (NMDA) defined in [RFC8342].

このドキュメントは、[RFC8342]で定義されたネットワーク管理データストアアーキテクチャ（NMDA）をサポートするために、[RFC8040]で定義されたRESTCONFプロトコルを拡張します。

This document updates [RFC8040] in order to enable RESTCONF clients to discover which datastores are supported by the RESTCONF server, determine which modules are supported in each datastore, and interact with all the datastores supported by the NMDA. Specifically, the update introduces new datastore resources, adds a new query parameter, and requires the usage of the YANG library [RFC8525] by RESTCONF servers implementing the NMDA.

このドキュメントは、[RFC8040]を更新して、RESTCONFクライアントがRESTCONFサーバーでサポートされているデータストアを検出し、各データストアでサポートされているモジュールを特定し、NMDAでサポートされているすべてのデータストアとやり取りできるようにします。具体的には、更新では新しいデータストアリソースが導入され、新しいクエリパラメータが追加され、NMDAを実装するRESTCONFサーバーによるYANGライブラリ[RFC8525]の使用が必要になります。

The solution presented in this document is backwards compatible with [RFC8040]. This is achieved by only adding new resources and leaving the semantics of the existing resources unchanged.

このドキュメントで提示されているソリューションは、[RFC8040]と下位互換性があります。これは、新しいリソースを追加し、既存のリソースのセマンティクスを変更しないままにすることで実現されます。

1.1. Terminology

1.1. 用語

This document uses the terminology defined by the NMDA [RFC8342].

このドキュメントでは、NMDA [RFC8342]で定義されている用語を使用しています。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. Datastore and YANG Library Requirements

2. データストアとYANGライブラリの要件

An NMDA-compliant RESTCONF server MUST support the operational state datastore and MUST implement at least revision 2019-01-04 of the "ietf-yang-library" module defined in [RFC8525].

NMDA準拠のRESTCONFサーバーは、動作状態データストアをサポートする必要があり、[RFC8525]で定義されている「ietf-yang-library」モジュールの少なくともリビジョン2019-01-04を実装する必要があります。

Such a server identifies that it supports the NMDA both by implementing the {+restconf}/ds/ietf-datastores:operational resource and by implementing at least revision 2019-01-04 of the "ietf-yang-library" module.

このようなサーバーは、{+ restconf} / ds / ietf-datastores：operationalリソースを実装することと、「ietf-yang-library」モジュールの少なくともリビジョン2019-01-04を実装することの両方によって、NMDAをサポートすることを識別します。

A RESTCONF client can test if a server supports the NMDA by using either the HEAD or GET methods on {+restconf}/ds/ietf-datastores:operational.

RESTCONFクライアントは、{+ restconf} / ds / ietf-datastores：operationalでHEADメソッドまたはGETメソッドを使用して、サーバーがNMDAをサポートしているかどうかをテストできます。

A RESTCONF client can discover which datastores and YANG modules the server supports by reading the YANG library information from the operational state datastore.

RESTCONFクライアントは、運用状態データストアからYANGライブラリー情報を読み取ることにより、サーバーがサポートするデータストアとYANGモジュールを検出できます。

3. RESTCONF Extensions

3. RESTCONF拡張

This section describes the RESTCONF extensions needed to support the NMDA.

このセクションでは、NMDAをサポートするために必要なRESTCONF拡張について説明します。

3.1. New Datastore Resources

3.1. 新しいデータストアリソース

This document defines a set of new resources representing datastores as defined in [RFC8342]. These resources are available using the following resource path template:

このドキュメントは、[RFC8342]で定義されているデータストアを表す一連の新しいリソースを定義します。これらのリソースは、次のリソースパステンプレートを使用して利用できます。

     {+restconf}/ds/<datastore>

The <datastore> path component is encoded as an "identityref" according to the JSON encoding rules for identities, defined in Section 6.8 of [RFC7951]. The namespace-qualified form MUST be used. Such an identity MUST be derived from the "datastore" identity defined in the "ietf-datastores" YANG module [RFC8342].

<datastore>パスコンポーネントは、[RFC7951]のセクション6.8で定義されているIDのJSONエンコードルールに従って「identityref」としてエンコードされます。名前空間で修飾された形式を使用する必要があります。そのようなアイデンティティは、「ietf-datastores」YANGモジュール[RFC8342]で定義された「データストア」アイデンティティから派生しなければなりません（MUST）。

Specifically:

具体的には：

o The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore.

o リソース{+ restconf} / ds / ietf-datastores：operationalは、動作状態データストアを指します。

o The resource {+restconf}/ds/ietf-datastores:running refers to the running configuration datastore.

o リソース{+ restconf} / ds / ietf-datastores：runningは、実行構成データストアを指します。

o The resource {+restconf}/ds/ietf-datastores:intended refers to the intended configuration datastore.

o リソース{+ restconf} / ds / ietf-datastores：intendedは、目的の構成データストアを指します。

An NMDA-compliant server MUST implement {+restconf}/ds/ietf-datastores:operational. Other datastore resources MAY be implemented.

NMDA準拠のサーバーは、{+ restconf} / ds / ietf-datastores：operationalを実装する必要があります。他のデータストアリソースが実装される場合があります。

YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational.

YANGアクションは、{+ restconf} / ds / ietf-datastores：operationalでのみ呼び出すことができます。

As an example, if a server implements a datastore called "ds-ephemeral", defined in a module called "example-ds-ephemeral", then the server would implement the resource {+restconf}/ds/example-ds-ephemeral:ds-ephemeral.

例として、サーバーが「example-ds-ephemeral」というモジュールで定義された「ds-ephemeral」というデータストアを実装する場合、サーバーはリソース{+ restconf} / ds / example-ds-ephemeralを実装します。 ds-ephemeral。

3.2. Protocol Operations

3.2. プロトコル操作

The protocol operations available for the new datastore resources (see Section 3.1) are the same as the protocol operations defined in [RFC8040] for the {+restconf}/data resource with the following exceptions:

新しいデータストアリソース（セクション3.1を参照）で使用できるプロトコル操作は、[+ restconf} / dataリソースに対して[RFC8040]で定義されているプロトコル操作と同じですが、次の例外があります。

o Dynamic configuration datastores are excluded, as each dynamic configuration datastore definition needs to be reviewed for what protocol operations it supports.

o 動的構成データストアの定義は、サポートするプロトコル操作について確認する必要があるため、除外されます。

o Some datastores are read-only by nature (e.g., <intended>); hence, any attempt to modify these datastores will fail. A server MUST return a response with a "405 Method Not Allowed" status-line and an error-tag value of "operation-not-supported".

o 一部のデータストアは本質的に読み取り専用です（例：<intended>）。したがって、これらのデータストアを変更しようとすると失敗します。サーバーは、「405 Method Not Allowed」ステータス行と「operation-not-supported」のエラータグ値を含む応答を返さなければなりません（MUST）。

o The semantics of the "with-defaults" query parameter (Section 4.8.9 of [RFC8040]) differ when interacting with the operational state datastore. The semantics are described in Section 3.2.1.

o 「with-defaults」クエリパラメータのセマンティクス（[RFC8040]のセクション4.8.9）は、運用状態データストアとやり取りするときに異なります。セマンティクスについては、セクション3.2.1で説明します。

o [RFC8040], Section 3.5.4, paragraph 3 does not apply when interacting with any resource under {+restconf}/ds.

o [RFC8040]、セクション3.5.4、パラグラフ3は、{+ restconf} / dsでリソースとやり取りする場合には適用されません。

3.2.1. The "with-defaults" Query Parameter on the Operational State Datastore

3.2.1. 運用状態データストアの「with-defaults」クエリパラメータ

Support for the "with-defaults" query parameter (Section 4.8.9 of [RFC8040]) is OPTIONAL when interacting with {+restconf}/ds/ietf-datastores:operational. The associated capability to indicate a server's support is identified with the URI:

「+ -defaults」クエリパラメータ（[RFC8040]のセクション4.8.9）のサポートは、{+ restconf} / ds / ietf-datastores：operationalと対話する場合のオプションです。サーバーのサポートを示す関連機能は、URIで識別されます。

     urn:ietf:params:restconf:capability:with-operational-defaults:1.0

For servers that support it, the behavior of the "with-defaults" query parameter on the operational state datastore is defined as follows:

これをサポートするサーバーの場合、動作状態データストアの「with-defaults」クエリパラメータの動作は次のように定義されます。

o If no "with-defaults" query parameter is specified, or if it is set to "explicit", "report-all", or "report-all-tagged", then the "in use" values, as defined in Section 5.3 of [RFC8342], are returned from the operational state datastore, even if a node happens to have a default statement in the YANG module and this default value is being used by the server. If the "with-defaults" parameter is set to "report-all-tagged", any values that match the schema default are tagged with additional metadata, as described in Section 4.8.9 of [RFC8040].

o 「with-defaults」クエリパラメータが指定されていない場合、または「explicit」、「report-all」、または「report-all-tagged」に設定されている場合、セクション5.3で定義されている「使用中」の値の[RFC8342]の値は、ノードがYANGモジュールにデフォルトのステートメントを持っていて、このデフォルト値がサーバーによって使用されている場合でも、動作状態データストアから返されます。 [RFC8040]のセクション4.8.9で説明されているように、「with-defaults」パラメータが「report-all-tagged」に設定されている場合、スキーマのデフォルトと一致する値にはすべて追加のメタデータがタグ付けされます。

o If the "with-defaults" query parameter is set to "trim", all "in use" values are returned, except that the output is filtered to exclude any values that match the default defined in the YANG schema.

o 「with-defaults」クエリパラメータが「trim」に設定されている場合、YANGスキーマで定義されているデフォルトと一致する値を除外するように出力がフィルタリングされることを除いて、すべての「使用中」の値が返されます。

Servers are not required to support all values in the "with-defaults" query parameter on the operational state datastore. If a request is made using a value that is not supported, then the error handling behavior is as described in Section 4.8.9 of [RFC8040].

サーバーは、運用状態データストアの「with-defaults」クエリパラメータのすべての値をサポートする必要はありません。サポートされていない値を使用してリクエストが行われた場合、エラー処理の動作は[RFC8040]のセクション4.8.9に記載されています。

3.2.2. New "with-origin" Query Parameter

3.2.2. 新しい「with-origin」クエリパラメータ

A new query parameter named "with-origin" is added to the GET operation. If present, it requests that the server includes "origin" metadata annotations in its response, as detailed in the NMDA. This parameter is only valid when querying {+restconf}/ds/ietf-datastores:operational or any datastores with identities derived from the "operational" identity. Otherwise, if an invalid datastore is specified, then the server MUST return a response with a "400 Bad Request" status-line, using an error-tag value of "invalid-value". "origin" metadata annotations are not included unless a client explicitly requests them.

「with-origin」という名前の新しいクエリパラメータがGET操作に追加されます。存在する場合は、NMDAで詳しく説明されているように、サーバーがその応答に「元の」メタデータアノテーションを含めることを要求します。このパラメーターは、{+ restconf} / ds / ietf-datastores：operationalまたは「操作可能な」IDから派生したIDを持つデータストアをクエリする場合にのみ有効です。それ以外の場合、無効なデータストアが指定されていると、サーバーは「無効な値」のエラータグ値を使用して、「400 Bad Request」ステータス行を含む応答を返さなければなりません（MUST）。「元の」メタデータアノテーションは、クライアントが明示的に要求しない限り含まれません。

Data in the operational state datatstore can come from multiple sources. The server should return the "origin" metadata annotation value that most accurately indicates the source of the operational value, as specified in Section 5.3.4 of [RFC8342].

運用状態データストア内のデータは、複数のソースから取得できます。サーバーは、[RFC8342]のセクション5.3.4で指定されているように、運用値のソースを最も正確に示す「origin」メタデータアノテーション値を返す必要があります。

When encoding the "origin" metadata annotation for a hierarchy of returned nodes, the annotation can be omitted for a child node when the value matches that of the parent node, as described in the "ietf-origin" YANG module [RFC8342].

返されたノードの階層の「origin」メタデータアノテーションをエンコードする場合、「ietf-origin」YANGモジュール[RFC8342]で説明されているように、値が親ノードの値と一致する場合、子ノードのアノテーションは省略できます。

Support for the "with-origin" query parameter is OPTIONAL. It is identified with the URI:

「with-origin」クエリパラメータのサポートはオプションです。 URIで識別されます。

     urn:ietf:params:restconf:capability:with-origin:1.0

4. IANA Considerations

4. IANAに関する考慮事項

This document defines two capability identifier URNs in the "RESTCONF Capability URNs" registry defined in [RFC8040]:

このドキュメントでは、[RFC8040]で定義されている「RESTCONF Capability URNs」レジストリで2つの機能識別子URNを定義しています。

     Index
     Capability Identifier
     ---------------------

     :with-origin
     urn:ietf:params:restconf:capability:with-origin:1.0

     :with-operational-defaults
     urn:ietf:params:restconf:capability:with-operational-defaults:1.0

5. Security Considerations

5. セキュリティに関する考慮事項

This document extends the RESTCONF protocol by introducing new datastore resources. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The RESTCONF protocol uses the network configuration access control model [RFC8341], which provides the means to restrict access for particular RESTCONF users to a preconfigured subset of all available RESTCONF protocol operations and content.

このドキュメントでは、新しいデータストアリソースを導入することでRESTCONFプロトコルを拡張しています。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC8446]です。 RESTCONFプロトコルは、ネットワーク構成アクセス制御モデル[RFC8341]を使用します。これは、特定のRESTCONFユーザーのアクセスを、使用可能なすべてのRESTCONFプロトコル操作とコンテンツの事前構成済みサブセットに制限する手段を提供します。

The security constraints for the base RESTCONF protocol (see Section 12 of [RFC8040]) apply to the new RESTCONF datastore resources defined in this document.

基本RESTCONFプロトコルのセキュリティ制限（[RFC8040]のセクション12を参照）は、このドキュメントで定義されている新しいRESTCONFデータストアリソースに適用されます。

6. Normative References

6. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC7951] Lhotka、L。、「YANGでモデル化されたデータのJSONエンコーディング」、RFC 7951、DOI 10.17487 / RFC7951、2016年8月、<https://www.rfc-editor.org/info/rfc7951>。

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8341] Bierman、A。およびM. Bjorklund、「Network Configuration Access Control Model」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https://www.rfc-editor.org/info/rfc8341 >。

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「Network Management Datastore Architecture（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、< https://www.rfc-editor.org/info/rfc8342>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

[RFC8525] Bierman、A.、Bjorklund、M.、Schoenwaelder、J.、Watsen、K。、およびR. Wilton、「YANG Library」、RFC 8525、DOI 10.17487 / RFC8525、2019年3月、<https：// www .rfc-editor.org / info / rfc8525>。

Authors' Addresses

著者のアドレス

Martin Bjorklund Tail-f Systems

Martin Bjorklund Tail-fシステム

   Email: mbj@tail-f.com

Juergen Schoenwaelder Jacobs University

ユルゲンシェーンヴェルダージェイコブス大学

   Email: j.schoenwaelder@jacobs-university.de

Phil Shafer Juniper Networks

Phil Shaferジュニパーネットワークス

   Email: phil@juniper.net

Kent Watsen Watsen Networks

   Email: kent+ietf@watsen.net

Robert Wilton Cisco Systems

   Email: rwilton@cisco.com