[要約] RFC 8528は、YANGスキーママウントの仕様を定義しており、ネットワークデバイスの複数のスキーマを統合するための機能を提供します。目的は、ネットワーク管理者が複数のデバイスを効果的に管理できるようにすることです。
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 8528 Tail-f Systems
Category: Standards Track L. Lhotka
ISSN: 2070-1721 CZ.NIC
March 2019
YANG Schema Mount
スキーママウント
Abstract
概要
This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.
このドキュメントでは、YANGモジュールのセットで定義されたスキーマツリーを、別のYANGモジュールのスキーマツリーで定義されたマウントポイントに追加するメカニズムを定義しています。
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/rfc8528.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8528で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
2. Terminology and Notation ........................................6
2.1. Tree Diagrams ..............................................7
2.2. Namespace Prefixes .........................................7
3. Schema Mount ....................................................8
3.1. Mount Point Definition .....................................8
3.2. Data Model .................................................9
3.3. Specification of the Mounted Schema ........................9
3.4. Multiple Levels of Schema Mount ...........................10
4. Referring to Data Nodes in the Parent Schema ...................10
5. RPC Operations and Notifications ...............................11
6. NMDA Considerations ............................................12
7. Interaction with NACM ..........................................12
8. Implementation Notes ...........................................13
9. Schema Mount YANG Module .......................................13
10. IANA Considerations ...........................................18
11. Security Considerations .......................................18
12. References ....................................................19
12.1. Normative References .....................................19
12.2. Informative References ...................................21
Appendix A. Example: Device Model with LNEs and NIs ..............22
A.1. Physical Device ...........................................22
A.2. Logical Network Elements ..................................24
A.3. Network Instances .........................................27
A.4. Invoking an RPC Operation .................................28
Contributors ......................................................28
Authors' Addresses ................................................28
Modularity and extensibility are among the leading design principles of the YANG data modeling language. As a result, the same YANG module can be combined with various sets of other modules to form a data model that is tailored to meet the requirements of a specific use case. Server implementors are only required to specify all YANG modules comprising the data model (together with their revisions and other optional choices) in the YANG library data ([RFC7895], [RFC8525], and Section 5.6.4 of [RFC7950]) implemented by the server. Such YANG modules appear in the data model "side by side", i.e., top-level data nodes of each module (if there are any) are also top-level nodes of the overall data model.
モジュール性と拡張性は、YANGデータモデリング言語の主要な設計原則の1つです。その結果、同じYANGモジュールを他のさまざまなモジュールセットと組み合わせて、特定のユースケースの要件を満たすように調整されたデータモデルを形成できます。サーバーの実装者は、YANGライブラリデータ（[RFC7895]、[RFC8525]、および[RFC7950]のセクション5.6.4）でデータモデルを構成するすべてのYANGモジュールを指定する必要があります（リビジョンおよびその他のオプションの選択とともに）。サーバー。このようなYANGモジュールは、データモデルに「並べて」表示されます。つまり、各モジュールのトップレベルのデータノード（存在する場合）は、データモデル全体のトップレベルのノードでもあります。
YANG has two mechanisms for contributing a schema hierarchy defined elsewhere to the contents of an internal node of the schema tree. These mechanisms are realized through the following YANG statements:
YANGには、他の場所で定義されたスキーマ階層をスキーマツリーの内部ノードのコンテンツに提供するための2つのメカニズムがあります。これらのメカニズムは、次のYANGステートメントによって実現されます。
o The "uses" statement explicitly incorporates the contents of a grouping defined in the same or another module. See Section 4.2.6 of [RFC7950] for more details.
o 「uses」ステートメントは、同じまたは別のモジュールで定義されたグループ化の内容を明示的に組み込んでいます。詳細については、[RFC7950]のセクション4.2.6を参照してください。
o The "augment" statement explicitly adds contents to a target node defined in the same or another module. See Section 4.2.8 of [RFC7950] for more details.
o 「augment」ステートメントは、同じまたは別のモジュールで定義されたターゲットノードにコンテンツを明示的に追加します。詳細については、[RFC7950]のセクション4.2.8を参照してください。
With both mechanisms, the YANG module with the "uses" or "augment" statement explicitly defines the exact location in the schema tree where the new nodes are placed.
どちらのメカニズムでも、「uses」または「augment」ステートメントを含むYANGモジュールは、新しいノードが配置されるスキーマツリー内の正確な場所を明示的に定義します。
In some cases, these mechanisms are not sufficient; it is sometimes necessary for an existing module (or a set of modules) to be added to the data model starting at locations other than the root. For example, YANG modules such as "ietf-interfaces" [RFC8343] are defined so as to be used in a data model of a physical device. Now suppose we want to model a device that supports multiple logical devices [RFC8530], each of which has its own instantiation of "ietf-interfaces", and possibly other modules; at the same time, we want to be able to manage all these logical devices from the master device. Hence, we would like to have a schema tree like this:
場合によっては、これらのメカニズムでは不十分です。ルート以外の場所から開始して、既存のモジュール（またはモジュールのセット）をデータモデルに追加する必要がある場合があります。例えば、「ietf-interfaces」[RFC8343]などのYANGモジュールは、物理デバイスのデータモデルで使用されるように定義されています。ここで、複数の論理デバイス[RFC8530]をサポートするデバイスをモデル化するとします。各デバイスには、「ietf-interfaces」の独自のインスタンス化と、場合によっては他のモジュールがあります。同時に、マスターデバイスからこれらすべての論理デバイスを管理できるようにしたいと考えています。したがって、次のようなスキーマツリーが必要です。
+--rw interfaces
| +--rw interface* [name]
| ...
+--rw logical-network-element* [name]
+--rw name
| ...
+--rw interfaces
+--rw interface* [name]
...
With the "uses" approach, the complete schema tree of "ietf-interfaces" would have to be wrapped in a grouping, and then this grouping would have to be used at the top level (for the master device) and then also in the "logical-network-element" list (for the logical devices). This approach has several disadvantages:
"uses"アプローチでは、 "ietf-interfaces"の完全なスキーマツリーをグループ化にラップし、このグループ化をトップレベル（マスターデバイスの場合）で使用し、さらに「logical-network-element」リスト（論理デバイス用）。このアプローチにはいくつかの欠点があります。
o It is not scalable because every time there is a new YANG module that needs to be added to the logical device model, we have to update the model for logical devices with another "uses" statement pulling in contents of the new module.
o 論理デバイスモデルに追加する必要がある新しいYANGモジュールがあるたびに、新しいモジュールの内容を取り込む別の「uses」ステートメントで論理デバイスのモデルを更新する必要があるため、スケーラブルではありません。
o Absolute references to nodes defined inside a grouping may break if the grouping is used in different locations.
o グループ化が別の場所で使用されている場合、グループ化内で定義されたノードへの絶対参照が壊れる可能性があります。
o Nodes defined inside a grouping belong to the namespace of the module where it is used, which makes references to such nodes from other modules difficult or even impossible.
o グループ内で定義されたノードは、それが使用されているモジュールの名前空間に属しているため、他のモジュールからのそのようなノードへの参照が困難または不可能にさえなります。
o It would be difficult for vendors to add proprietary modules when the "uses" statements are defined in a standard module.
o 「uses」ステートメントが標準モジュールで定義されている場合、ベンダーが独自のモジュールを追加することは困難です。
With the "augment" approach, "ietf-interfaces" would have to augment the "logical-network-element" list with all its nodes and, at the same time, define all its nodes at the top level. The same hierarchy of nodes would thus have to be defined twice, which is clearly not scalable either.
「拡張」アプローチでは、「ietf-interfaces」は「logical-network-element」リストをそのすべてのノードで拡張し、同時にそのすべてのノードをトップレベルで定義する必要があります。したがって、ノードの同じ階層を2回定義する必要がありますが、これも明らかにスケーラブルではありません。
This document introduces a new mechanism, denoted as "schema mount", that allows for mounting one data model consisting of any number of YANG modules at a specified location of another (parent) schema. Unlike the "uses" and "augment" approaches discussed above, the mounted modules needn't be specially prepared for mounting; consequently, existing modules such as "ietf-interfaces" can be mounted without any modifications.
このドキュメントでは、「スキーママウント」と呼ばれる新しいメカニズムを紹介します。これにより、任意の数のYANGモジュールで構成される1つのデータモデルを別の（親）スキーマの指定された場所にマウントできます。上記の「用途」や「拡張」のアプローチとは異なり、マウントされたモジュールは、マウントのために特別に準備する必要はありません。その結果、「ietf-interfaces」などの既存のモジュールを変更せずにマウントできます。
The basic idea of schema mount is to label a data node in the parent schema as the mount point and then define a complete data model to be attached to the mount point so that the labeled data node effectively becomes the root node of the mounted data model.
スキーママウントの基本的な考え方は、親スキーマのデータノードにマウントポイントとしてラベルを付け、マウントポイントにアタッチする完全なデータモデルを定義して、ラベル付けされたデータノードがマウントされたデータモデルのルートノードになるようにすることです。 。
In principle, the mounted schema can be specified at three different phases of the data model life cycle:
原則として、マウントされたスキーマは、データモデルのライフサイクルの3つの異なるフェーズで指定できます。
1. Design time: The mounted schema is defined along with the mount point in the parent YANG module. In this case, the mounted schema has to be the same for every implementation of the parent module.
1. 設計時：マウントされたスキーマは、親YANGモジュールのマウントポイントとともに定義されます。この場合、マウントされたスキーマは、親モジュールのすべての実装で同じである必要があります。
2. Implementation time: The mounted schema is defined by a server implementor and is as stable as the YANG library information of the server.
2. 実装時間：マウントされたスキーマはサーバーの実装者によって定義され、サーバーのYANGライブラリ情報と同じくらい安定しています。
3. Run time: The mounted schema is defined by instance data that is part of the mounted data model. If there are multiple instances of the same mount point (e.g., in multiple entries of a list), the mounted data model may be different for each instance.
3. 実行時：マウントされたスキーマは、マウントされたデータモデルの一部であるインスタンスデータによって定義されます。同じマウントポイントの複数のインスタンスがある場合（リストの複数のエントリなど）、マウントされたデータモデルはインスタンスごとに異なる場合があります。
The schema mount mechanism defined in this document provides support only for the latter two cases. Design-time mounts are outside the scope of this document and could be possibly dealt with in a future revision of the YANG data modeling language.
このドキュメントで定義されているスキーママウントメカニズムは、後者の2つの場合にのみサポートを提供します。設計時のマウントは、このドキュメントの範囲外であり、YANGデータモデリング言語の将来のリビジョンで処理される可能性があります。
Schema mount applies to the data model and specifically does not assume anything about the source of instance data for the mounted schemas. It may be implemented using the same instrumentation as the rest of the system, or it may be implemented by querying some other system. Future specifications may define mechanisms to control or monitor the implementation of specific mount points.
スキーママウントはデータモデルに適用され、具体的には、マウントされたスキーマのインスタンスデータのソースについて何も想定しません。システムの他の部分と同じインストルメンテーションを使用して実装することも、他のシステムにクエリを実行して実装することもできます。将来の仕様では、特定のマウントポイントの実装を制御または監視するメカニズムを定義する可能性があります。
How and when specific mount points are instantiated by the server is out of scope for this document. Such mechanisms may be defined in future specifications.
特定のマウントポイントがサーバーによってインスタンス化される方法と時期は、このドキュメントの範囲外です。そのようなメカニズムは将来の仕様で定義されるかもしれません。
This document allows mounting of complete data models only. Other specifications may extend this model by defining additional mechanisms such as mounting sub-hierarchies of a module.
このドキュメントでは、完全なデータモデルのマウントのみを許可しています。他の仕様では、モジュールのサブ階層のマウントなどの追加メカニズムを定義することにより、このモデルを拡張できます。
The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342].
このドキュメントのYANGモジュールは、ネットワーク管理データストアアーキテクチャ（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]で説明されているように解釈されます。
The following terms are defined in [RFC7950] and are not redefined here:
以下の用語は[RFC7950]で定義されており、ここでは再定義されません。
o action
o アクション
o container
o コンテナ
o data node
o だた ので
o list
o リスト
o RPC operation
o RPC操作
o schema node
o ｓちぇま ので
o schema tree
o スキーマツリー
The following terms are defined in [RFC8342] and are not redefined here:
以下の用語は[RFC8342]で定義されており、ここでは再定義されません。
o client
o クライアント
o notification
o 通知
o operational state
o 稼働状態
o server
o サーバ
The following term is defined in [RFC8343] and is not redefined here:
次の用語は[RFC8343]で定義されており、ここでは再定義されていません。
o system-controlled interface
o システム制御インターフェース
The following term is defined in [RFC8525] and is not redefined here:
次の用語は[RFC8525]で定義されており、ここでは再定義されていません。
o YANG library content identifier The following additional terms are used in this document:
o YANGライブラリコンテンツ識別子このドキュメントでは、次の追加用語が使用されています。
o mount point: A container or a list node whose definition contains the "mount-point" extension statement. The argument of the "mount-point" extension statement defines a label for the mount point.
o マウントポイント：定義に「mount-point」拡張ステートメントが含まれているコンテナーまたはリストノード。 「mount-point」拡張ステートメントの引数は、マウントポイントのラベルを定義します。
o schema: A collection of schema trees with a common root.
o schema：共通のルートを持つスキーマツリーのコレクション。
o top-level schema: A schema rooted at the root node.
o トップレベルスキーマ：ルートノードをルートとするスキーマ。
o mounted schema: A schema rooted at a mount point.
o マウントされたスキーマ：マウントポイントをルートとするスキーマ。
o parent schema (of a mounted schema): A schema containing the mount point.
o （マウントされたスキーマの）親スキーマ：マウントポイントを含むスキーマ。
o schema mount: The mechanism to combine data models defined in this document.
o スキーママウント：このドキュメントで定義されているデータモデルを組み合わせるメカニズム。
Tree diagrams used in this document follow the notation defined in [RFC8340].
このドキュメントで使用されるツリー図は、[RFC8340]で定義された表記に従います。
In this document, names of data nodes, YANG extensions, actions, and other data model objects are often used without a prefix when the YANG module in which they are defined is clear from the context. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.
このドキュメントでは、データノードの名前、YANG拡張機能、アクション、およびその他のデータモデルオブジェクトは、それらが定義されているYANGモジュールがコンテキストから明確である場合、プレフィックスなしで使用されることがよくあります。それ以外の場合、表1に示すように、対応するYANGモジュールに関連付けられた標準の接頭辞を使用して名前に接頭辞が付けられます。
+---------+------------------------+----------------------+
| Prefix | YANG module | Reference |
+---------+------------------------+----------------------+
| yangmnt | ietf-yang-schema-mount | Section 9 |
| inet | ietf-inet-types | [RFC6991] |
| yang | ietf-yang-types | [RFC6991] |
| yanglib | ietf-yang-library | [RFC7895], [RFC8525] |
+---------+------------------------+----------------------+
Table 1: Namespace Prefixes
表1：名前空間プレフィックス
The schema mount mechanism defined in this document provides a new extensibility mechanism for use with YANG 1.1 [RFC7950]. In contrast to the existing mechanisms described in Section 1, schema mount defines the relationship between the source and target YANG modules outside these modules.
このドキュメントで定義されているスキーママウントメカニズムは、YANG 1.1 [RFC7950]で使用するための新しい拡張メカニズムを提供します。セクション1で説明した既存のメカニズムとは対照的に、スキーママウントは、これらのモジュールの外部にあるソースとターゲットのYANGモジュール間の関係を定義します。
A container or list node becomes a mount point if the "mount-point" extension statement (defined in the "ietf-yang-schema-mount" module) is used in its definition. This extension can appear only as a substatement of "container" and "list" statements.
定義で「mount-point」拡張ステートメント（「ietf-yang-schema-mount」モジュールで定義）が使用されている場合、コンテナまたはリストノードはマウントポイントになります。この拡張機能は、「コンテナー」および「リスト」ステートメントのサブステートメントとしてのみ表示できます。
The argument of the "mount-point" extension statement is a YANG identifier that defines a label for the mount point. A module MAY contain multiple "mount-point" extension statements having the same argument.
「mount-point」拡張ステートメントの引数は、マウントポイントのラベルを定義するYANG識別子です。モジュールには、同じ引数を持つ複数の「マウントポイント」拡張ステートメントを含めることができます（MAY）。
It is therefore up to the designer of the parent schema to decide about the placement of mount points. A mount point can also be made conditional by placing "if-feature" and/or "when" as substatements of the "container" or "list" statement that represents the mount point.
したがって、マウントポイントの配置について決定するのは、親スキーマの設計者です。マウントポイントは、マウントポイントを表す「コンテナー」または「リスト」ステートメントのサブステートメントとして「if-feature」や「when」を配置することによって、条件付きにすることもできます。
The "mount-point" extension statement MUST NOT be used in a YANG version 1 module [RFC6020]. If used in a YANG version 1 module, it would not be possible to invoke mounted RPC operations and receive mounted notifications. See Section 5 for details. Note, however, that modules written in any YANG version, including version 1, can be mounted under a mount point.
「マウントポイント」拡張ステートメントは、YANGバージョン1モジュール[RFC6020]で使用してはなりません（MUST NOT）。 YANGバージョン1モジュールで使用すると、マウントされたRPC操作を呼び出して、マウントされた通知を受け取ることができなくなります。詳細については、セクション5を参照してください。ただし、バージョン1を含むすべてのYANGバージョンで記述されたモジュールは、マウントポイントの下にマウントできることに注意してください。
Note that the "mount-point" extension statement does not define a new data node.
「mount-point」拡張ステートメントは新しいデータノードを定義しないことに注意してください。
This document defines the YANG 1.1 module [RFC7950] "ietf-yang-schema-mount", which has the following structure:
このドキュメントは、次の構造を持つYANG 1.1モジュール[RFC7950] "ietf-yang-schema-mount"を定義しています。
module: ietf-yang-schema-mount
+--ro schema-mounts
+--ro namespace* [prefix]
| +--ro prefix yang:yang-identifier
| +--ro uri? inet:uri
+--ro mount-point* [module label]
+--ro module yang:yang-identifier
+--ro label yang:yang-identifier
+--ro config? boolean
+--ro (schema-ref)
+--:(inline)
| +--ro inline!
+--:(shared-schema)
+--ro shared-schema!
+--ro parent-reference* yang:xpath1.0
Mounted schemas for all mount points in the parent schema are determined from state data in the "/schema-mounts" container.
親スキーマのすべてのマウントポイントのマウントされたスキーマは、「/ schema-mounts」コンテナの状態データから決定されます。
Generally, the modules that are mounted under a mount point have no relation to the modules in the parent schema; specifically, if a module is mounted, it may or may not be present in the parent schema; if present, its data will generally have no relationship to the data of the parent. Exceptions are possible and need to be defined in the model itself. For example, [RFC8530] defines a mechanism to bind interfaces to mounted logical network elements.
一般に、マウントポイントの下にマウントされるモジュールは、親スキーマのモジュールとは関係ありません。具体的には、モジュールがマウントされている場合、親スキーマに存在する場合と存在しない場合があります。存在する場合、そのデータは通常、親のデータとは関係ありません。例外が発生する可能性があり、モデル自体で定義する必要があります。たとえば、[RFC8530]は、マウントされた論理ネットワーク要素にインターフェースをバインドするメカニズムを定義しています。
The "/schema-mounts" container has the "mount-point" list as one of its children. Every entry of this list refers (through its key) to a mount point and specifies the mounted schema.
「/ schema-mounts」コンテナには、その子の1つとして「mount-point」リストがあります。このリストのすべてのエントリは、そのキーを介してマウントポイントを参照し、マウントされたスキーマを指定します。
If a mount point is defined in the parent schema but does not have an entry in the "mount-point" list, then the mounted schema is void, i.e., instances of that mount point MUST NOT contain any data except those that are defined in the parent schema.
マウントポイントが親スキーマで定義されているが、「マウントポイント」リストにエントリがない場合、マウントされたスキーマは無効になります。つまり、そのマウントポイントのインスタンスには、親スキーマ。
If multiple mount points with the same name are defined in the same module -- either directly or because the mount point is defined in a grouping and the grouping is used multiple times -- then the corresponding "mount-point" entry applies equally to all such mount points.
同じ名前の複数のマウントポイントが同じモジュールで定義されている場合-直接またはマウントポイントがグループ化で定義されているため、グループ化が複数回使用されている場合-対応する「マウントポイント」エントリはすべてに等しく適用されますそのようなマウントポイント。
The "config" property of mounted schema nodes is overridden and all nodes in the mounted schema are read-only ("config false") if at least one of the following conditions is satisfied for a mount point:
マウントされたスキーマノードの「config」プロパティはオーバーライドされ、マウントポイントで次の条件の少なくとも1つが満たされた場合、マウントされたスキーマのすべてのノードは読み取り専用（「config false」）になります。
o The mount point is itself defined as "config false".
o マウントポイント自体は「config false」として定義されています。
o The "config" leaf in the corresponding entry of the "mount-point" list is set to "false".
o 「mount-point」リストの対応するエントリの「config」リーフは「false」に設定されます。
An entry of the "mount-point" list can specify the mounted schema in two different ways: "inline" or "shared-schema".
「マウントポイント」リストのエントリは、「インライン」または「共有スキーマ」の2つの異なる方法でマウントされたスキーマを指定できます。
The mounted schema is determined at run time: every instance of the mount point that exists in the operational state MUST contain a copy of YANG library data that defines the mounted schema in exactly the same way as a top-level schema. A client is expected to retrieve this data from the instance tree. In the "inline" case, instances of the same mount point MAY use different mounted schemas, whereas in the "shared-schema" case, all instances MUST use the same mounted schema. This means that in the "shared-schema" case, all instances of the same mount point MUST have the same YANG library content identifier. In the "inline" case, if two instances have the same YANG library content identifier, it is not guaranteed that the YANG library contents are equal for these instances.
マウントされたスキーマは実行時に決定されます。運用状態にあるマウントポイントのすべてのインスタンスには、マウントされたスキーマをトップレベルのスキーマとまったく同じ方法で定義するYANGライブラリデータのコピーが含まれている必要があります。クライアントは、インスタンスツリーからこのデータを取得する必要があります。 「インライン」の場合、同じマウントポイントのインスタンスは異なるマウント済みスキーマを使用できますが、「共有スキーマ」の場合、すべてのインスタンスは同じマウント済みスキーマを使用する必要があります。つまり、「共有スキーマ」の場合、同じマウントポイントのすべてのインスタンスは、同じYANGライブラリコンテンツ識別子を持つ必要があります。 「インライン」の場合、2つのインスタンスが同じYANGライブラリコンテンツ識別子を持っていると、これらのインスタンスのYANGライブラリコンテンツが等しいことが保証されません。
Examples of "inline" and "shared-schema" can be found in Appendix A.2 and Appendix A.3, respectively.
「インライン」と「共有スキーマ」の例は、それぞれ付録A.2と付録A.3にあります。
YANG modules in a mounted schema MAY again contain mount points under which other schemas can be mounted. Consequently, it is possible to construct data models with an arbitrary number of mounted schemas. A schema for a mount point contained in a mounted module can be specified by implementing the "ietf-yang-library" and "ietf-yang-schema-mount" modules in the mounted schema and specifying the schemas in exactly the same way as the top-level schema.
マウントされたスキーマのYANGモジュールには、他のスキーマをマウントできるマウントポイントが含まれる場合があります。したがって、任意の数のスキーマがマウントされたデータモデルを構築することが可能です。マウントされたモジュールに含まれるマウントポイントのスキーマは、マウントされたスキーマに「ietf-yang-library」モジュールと「ietf-yang-schema-mount」モジュールを実装し、スキーマをとまったく同じ方法で指定することで指定できます。トップレベルのスキーマ。
A fundamental design principle of schema mount is that the mounted schema works exactly as a top-level schema, i.e., it is confined to the "mount jail". This means that all paths in the mounted schema (in leafrefs, instance-identifiers, XPath [XPATH] expressions, and target nodes of "augment" statements) are interpreted with the mount point as the root node. YANG modules of the mounted schema as well as corresponding instance data thus cannot refer to schema nodes or instance data outside the "mount jail".
スキーママウントの基本的な設計原則は、マウントされたスキーマがトップレベルのスキーマとまったく同じように機能することです。つまり、「マウント刑務所」に限定されます。これは、マウントされたスキーマ（leafref、インスタンス識別子、XPath [XPATH]式、および「augment」ステートメントのターゲットノード）のすべてのパスが、マウントポイントをルートノードとして解釈されることを意味します。したがって、マウントされたスキーマのYANGモジュールおよび対応するインスタンスデータは、「マウントジェイル」外のスキーマノードまたはインスタンスデータを参照できません。
However, this restriction is sometimes too severe. A typical example is network instances (NIs) [RFC8529] in which each NI has its own routing engine but the list of interfaces is global and shared by all NIs. If we want to model this organization with the NI schema mounted using schema mount, the overall schema tree would look schematically as follows:
ただし、この制限は厳しすぎる場合があります。典型的な例は、ネットワークインスタンス（NI）[RFC8529]で、各NIには独自のルーティングエンジンがありますが、インターフェイスのリストはグローバルであり、すべてのNIによって共有されます。スキーママウントを使用してマウントされたNIスキーマを使用してこの組織をモデル化する場合、スキーマツリー全体は次のようになります。
+--rw interfaces
| +--rw interface* [name]
| ...
+--rw network-instances
+--rw network-instance* [name]
+--rw name
+--mp root
+--rw routing
...
Here, the "root" container is the mount point for the NI schema. Routing configuration inside an NI often needs to refer to interfaces (at least those that are assigned to the NI), which is impossible unless such a reference can point to a node in the parent schema (interface name).
ここで、「ルート」コンテナはNIスキーマのマウントポイントです。多くの場合、NI内のルーティング構成はインターフェース（少なくともNIに割り当てられているもの）を参照する必要がありますが、そのような参照が親スキーマ（インターフェース名）のノードを指すことができない限り、これは不可能です。
Therefore, schema mount also allows for such references. For every mount point in the "shared-schema" case, it is possible to specify a leaf-list named "parent-reference" that contains zero or more XPath 1.0 expressions. Each expression is evaluated with the node in the parent data tree where the mount point is defined as the context node. The result of this evaluation MUST be a node-set (see the description of the "parent-reference" node for a complete definition of the evaluation context). For the purposes of evaluating XPath expressions within the mounted data tree, the union of all such node-sets is added to the accessible data tree.
したがって、スキーマのマウントでは、このような参照も可能です。 「共有スキーマ」の場合のすべてのマウントポイントについて、ゼロ以上のXPath 1.0式を含む「parent-reference」という名前のリーフリストを指定できます。各式は、マウントポイントがコンテキストノードとして定義されている親データツリーのノードで評価されます。この評価の結果はノードセットでなければなりません（評価コンテキストの完全な定義については、「親参照」ノードの説明を参照してください）。マウントされたデータツリー内のXPath式を評価するために、そのようなすべてのノードセットの和集合がアクセス可能なデータツリーに追加されます。
It is worth emphasizing that the nodes specified in the "parent-reference" leaf-list are available in the mounted schema only for XPath evaluations. In particular, they cannot be accessed in the mounted schema via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
「親参照」リーフリストで指定されたノードは、XPath評価の場合のみマウントされたスキーマで使用できることを強調する価値があります。特に、マウントされたスキーマでは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスできません。
If a mounted YANG module defines an RPC operation, clients can invoke this operation as if it were defined as an action for the corresponding mount point; see Section 7.15 of [RFC7950]. An example of this is given in Appendix A.4.
マウントされたYANGモジュールがRPC操作を定義している場合、クライアントは、対応するマウントポイントのアクションとして定義されているかのように、この操作を呼び出すことができます。 [RFC7950]のセクション7.15を参照してください。この例を付録A.4に示します。
Similarly, if the server emits a notification defined at the top level of any mounted module, it MUST be represented as if the notification was connected to the mount point; see Section 7.16 of [RFC7950].
同様に、サーバーがマウントされたモジュールのトップレベルで定義された通知を送信する場合、通知がマウントポイントに接続されているかのように表現する必要があります。 [RFC7950]のセクション7.16を参照してください。
Note that inline actions and notifications will not work when they are contained within a list node without a "key" statement (see Sections 7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points that contain modules with RPCs, actions, and notifications SHOULD NOT have any ancestor node that is a list node without a "key" statement. This requirement applies to the definition of modules using the "mount-point" extension statement.
「キー」ステートメントなしでリストノード内に含まれている場合、インラインアクションと通知は機能しないことに注意してください（[RFC7950]のセクション7.15および7.16を参照）。したがって、有用であるためには、RPC、アクション、および通知を備えたモジュールを含むマウントポイントに、「キー」ステートメントのないリストノードである祖先ノードを含めるべきではありません（SHOULD NOT）。この要件は、「mount-point」拡張ステートメントを使用したモジュールの定義に適用されます。
The schema mount solution presented in this document is designed to work with both servers that implement the NMDA [RFC8342] and old servers that don't implement the NMDA.
このドキュメントで紹介するスキーママウントソリューションは、NMDA [RFC8342]を実装するサーバーと、NMDAを実装しない古いサーバーの両方で動作するように設計されています。
Specifically, a server that doesn't support the NMDA MAY implement revision 2016-06-21 of "ietf-yang-library" [RFC7895] under a mount point. A server that supports the NMDA MUST implement at least revision 2019-01-04 of "ietf-yang-library" [RFC8525] under a mount point.
具体的には、NMDAをサポートしないサーバーは、マウントポイントの下に「ietf-yang-library」[RFC7895]のリビジョン2016-06-21を実装できます（MAY）。 NMDAをサポートするサーバーは、マウントポイントの下に少なくとも「ietf-yang-library」[RFC8525]のリビジョン2019-01-04を実装する必要があります。
If the Network Configuration Access Control Model (NACM) [RFC8341] is implemented on a server, it is used to control access to nodes defined by the mounted schema in the same way as for nodes defined by the top-level schema.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]がサーバーに実装されている場合、マウントされたスキーマによって定義されたノードへのアクセスを、トップレベルのスキーマによって定義されたノードと同じ方法で制御するために使用されます。
For example, suppose the module "ietf-interfaces" is mounted in the "root" container in the "logical-network-element" list defined in [RFC8530]. Then, the following NACM path can be used to control access to the "interfaces" container (where the character '\' is used where a line break has been inserted for formatting reasons):
たとえば、モジュール「ietf-interfaces」が、[RFC8530]で定義されている「logical-network-element」リストの「root」コンテナにマウントされているとします。次に、次のNACMパスを使用して、「インターフェース」コンテナへのアクセスを制御できます（フォーマット上の理由で改行が挿入されている場所に文字「\」が使用されています）。
<path xmlns:lne=
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
/lne:logical-network-elements\
/lne:logical-network-element/lne:root/if:interfaces
</path>
Network management of devices that use a data model with schema mount can be implemented in different ways. However, the following implementation options are envisioned as typical:
スキーママウント付きのデータモデルを使用するデバイスのネットワーク管理は、さまざまな方法で実装できます。ただし、次の実装オプションは一般的なものとして想定されています。
o shared management: Instance data of both parent and mounted schemas are accessible within the same management session.
o 共有管理：同じ管理セッション内で、親スキーマとマウントされたスキーマの両方のインスタンスデータにアクセスできます。
o split management: One (master) management session has access to instance data of both parent and mounted schemas; in addition, an extra session that has access only to the mounted data tree exists for every instance of the mount point.
o 分割管理：1つの（マスター）管理セッションは、親スキーマとマウントされたスキーマの両方のインスタンスデータにアクセスできます。さらに、マウントされたデータツリーにのみアクセスできる追加のセッションが、マウントポイントのインスタンスごとに存在します。
This module references [RFC6991] and [RFC7950].
このモジュールは[RFC6991]と[RFC7950]を参照します。
<CODE BEGINS> file "ietf-yang-schema-mount@2019-01-14.yang"
module ietf-yang-schema-mount {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
prefix yangmnt;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
組織「IETF NETMOD（NETCONFデータモデリング言語）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>";
description "This module defines a YANG extension statement that can be used to incorporate data models defined in other YANG modules in a module. It also defines operational state data that specify the overall structure of the data model.
説明「このモジュールは、他のYANGモジュールで定義されたデータモデルをモジュールに組み込むために使用できるYANG拡張ステートメントを定義します。また、データモデルの全体的な構造を指定する運用状態データも定義します。
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 (RFC 2119) (RFC 8174) 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（RFC 2119）（RFC 8174）で説明されているように解釈されます。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2019 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 (https://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8528;
see the RFC itself for full legal notices.";
revision 2019-01-14 {
description
"Initial revision.";
reference
"RFC 8528: YANG Schema Mount";
}
/*
* Extensions
*/
extension mount-point {
argument label;
description
"The argument 'label' is a YANG identifier, i.e., it is of the
type 'yang:yang-identifier'.
The 'mount-point' statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a 'uses' statement.
「mount-point」ステートメントは、明示的にも「uses」ステートメントを介しても、YANGバージョン1モジュールで使用してはなりません（MUST NOT）。
The 'mount-point' statement MAY be present as a substatement of 'container' and 'list' and MUST NOT be present elsewhere. There MUST NOT be more than one 'mount-point' statement in a given 'container' or 'list' statement.
「mount-point」ステートメントは、「container」および「list」のサブステートメントとして存在する場合があり、他の場所に存在してはなりません。特定の「コンテナー」または「リスト」ステートメント内に複数の「マウントポイント」ステートメントがあってはなりません。
If a mount point is defined within a grouping, its label is bound to the module where the grouping is used.
マウントポイントがグループ内で定義されている場合、そのラベルはグループが使用されているモジュールにバインドされます。
A mount point defines a place in the node hierarchy where other data models may be attached. A server that implements a module with a mount point populates the '/schema-mounts/mount-point' list with detailed information on which data models are mounted at each mount point.
マウントポイントは、他のデータモデルを接続できるノード階層内の場所を定義します。マウントポイントを持つモジュールを実装するサーバーは、「/ schema-mounts / mount-point」リストに、各マウントポイントでマウントされるデータモデルに関する詳細情報を入力します。
Note that the 'mount-point' statement does not define a new
data node.";
}
/*
* State data nodes
*/
container schema-mounts {
config false;
description
"Contains information about the structure of the overall
mounted data model implemented in the server.";
list namespace {
key "prefix";
description
"This list provides a mapping of namespace prefixes that are
used in XPath expressions of 'parent-reference' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
list mount-point {
key "module label";
description "Each entry of this list specifies a schema for a particular mount point.
説明「このリストの各エントリは、特定のマウントポイントのスキーマを指定します。
Each mount point MUST be defined using the 'mount-point'
extension in one of the modules listed in the server's
YANG library instance with conformance type 'implement'.";
leaf module {
type yang:yang-identifier;
description
"Name of a module containing the mount point.";
}
leaf label {
type yang:yang-identifier;
description
"Label of the mount point defined using the 'mount-point'
extension.";
}
leaf config {
type boolean;
default "true";
description
"If this leaf is set to 'false', then all data nodes in the
mounted schema are read-only ('config false'), regardless
of their 'config' property.";
}
choice schema-ref {
mandatory true;
description
"Alternatives for specifying the schema.";
container inline {
presence
"A complete self-contained schema is mounted at the
mount point.";
description
"This node indicates that the server has mounted at least
the module 'ietf-yang-library' at the mount point, and
its instantiation provides the information about the
mounted schema.
Different instances of the mount point may have
different schemas mounted.";
}
container shared-schema {
presence
"The mounted schema together with the 'parent-reference'
make up the schema for this mount point.";
description "This node indicates that the server has mounted at least the module 'ietf-yang-library' at the mount point, and its instantiation provides the information about the mounted schema. When XPath expressions in the mounted schema are evaluated, the 'parent-reference' leaf-list is taken into account.
説明 "このノードは、サーバーが少なくともモジュール 'ietf-yang-library'をマウントポイントにマウントしたことを示し、そのインスタンス化により、マウントされたスキーマに関する情報が提供されます。マウントされたスキーマのXPath式が評価されると、「親-reference 'リーフリストが考慮されます。
Different instances of the mount point MUST have the
same schema mounted.";
leaf-list parent-reference {
type yang:xpath1.0;
description
"Entries of this leaf-list are XPath 1.0 expressions
that are evaluated in the following context:
- The context node is the node in the parent data tree where the mount-point is defined.
- コンテキストノードは、マウントポイントが定義されている親データツリーのノードです。
- The accessible tree is the parent data tree *without* any nodes defined in modules that are mounted inside the parent schema.
- アクセス可能なツリーは、親スキーマ内にマウントされたモジュールで定義されたノードがない*ない*親データツリーです。
- The context position and context size are both equal to 1.
- コンテキスト位置とコンテキストサイズはどちらも1です。
- The set of variable bindings is empty.
- 変数バインディングのセットが空です。
- The function library is the core function library defined in the W3C XPath 1.0 document (http://www.w3.org/TR/1999/REC-xpath-19991116) and the functions defined in Section 10 of RFC 7950.
- 関数ライブラリは、W3C XPath 1.0ドキュメント（http://www.w3.org/TR/1999/REC-xpath-19991116）で定義されているコア関数ライブラリであり、RFC 7950のセクション10で定義されている関数です。
- The set of namespace declarations is defined by the 'namespace' list under 'schema-mounts'.
- 名前空間宣言のセットは、「スキーママウント」の下の「名前空間」リストによって定義されます。
Each XPath expression MUST evaluate to a node-set (possibly empty). For the purposes of evaluating XPath expressions whose context nodes are defined in the mounted schema, the union of all these node-sets together with ancestor nodes are added to the accessible data tree.
各XPath式はノードセット（おそらく空）に評価される必要があります。マウントされたスキーマでコンテキストノードが定義されているXPath式を評価するために、これらのすべてのノードセットと祖先ノードの和集合がアクセス可能なデータツリーに追加されます。
Note that in the case 'ietf-yang-schema-mount' is itself mounted, a 'parent-reference' in the mounted module may refer to nodes that were brought into the accessible tree through a 'parent-reference' in the parent schema.";
「ietf-yang-schema-mount」自体がマウントされている場合、マウントされたモジュールの「親参照」は、親スキーマの「親参照」を通じてアクセス可能なツリーに持ち込まれたノードを参照する場合があることに注意してください。 。 ";
}
}
}
}
}
}
<CODE ENDS>
<コード終了>
This document registers a URI in the "IETF XML Registry" [RFC3688].
このドキュメントは、「IETF XMLレジストリ」[RFC3688]にURIを登録します。
URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-yang-schema-mount登録者の連絡先：IESG。 XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-yang-schema-mount
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
prefix: yangmnt
reference: RFC 8528
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）です[RFC6242]。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成済みサブセットに制限する手段を提供します。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: o /schema-mounts: The schema defined by this state data provides detailed information about a server implementation that may help an attacker identify the server capabilities and server implementations with known bugs. Server vulnerabilities may be specific to particular modules included in the schema, module revisions, module features, or even module deviations. For example, if a particular operation on a particular data node is known to cause a server to crash or significantly degrade device performance, then the schema information will help an attacker identify server implementations with such a defect, in order to launch a denial-of-service attack on the device.
このYANGモジュールの一部の読み取り可能なデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。したがって、これらのデータノードへの読み取りアクセスを制御することが重要です（たとえば、get、get-config、または通知を介して）。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。o / schema-mounts：この状態データによって定義されたスキーマは、攻撃者が既知のバグのあるサーバー機能とサーバー実装を識別するのに役立つサーバー実装に関する詳細情報を提供します。サーバーの脆弱性は、スキーマに含まれる特定のモジュール、モジュールのリビジョン、モジュールの機能、またはモジュールの逸脱に固有の場合があります。たとえば、特定のデータノードでの特定の操作によってサーバーがクラッシュしたりデバイスのパフォーマンスが大幅に低下したりすることがわかっている場合、スキーマ情報は攻撃者がそのような欠陥のあるサーバーの実装を特定し、拒否を開始するのに役立ちます-デバイスへのサービス攻撃。
It is important to take into account the security considerations for all nodes in the mounted schemas and to control access to these nodes by using the mechanism described in Section 7.
マウントされたスキーマのすべてのノードのセキュリティに関する考慮事項を考慮し、セクション7で説明されているメカニズムを使用してこれらのノードへのアクセスを制御することが重要です。
Care must be taken when the "parent-reference" XPath expressions are constructed, since the result of the evaluation of these expressions is added to the accessible tree for any XPath expression found in the mounted schema.
これらの式の評価結果は、マウントされたスキーマで検出されたXPath式のアクセス可能なツリーに追加されるため、「親参照」XPath式を構築するときは注意が必要です。
[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>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//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, <https://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月、<https://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, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「Using the NETCONF Protocol over Secure Shell（SSH）」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.
[RFC7895] Bierman、A.、Bjorklund、M。、およびK. Watsen、「YANG Module Library」、RFC 7895、DOI 10.17487 / RFC7895、2016年6月、<https://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, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[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>。
[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]クラークJ.およびS.デローズ、「XMLパス言語（XPath）バージョン1.0」、World Wide Web Consortium Recommendation REC-xpath-19991116、1999年11月、<http://www.w3.org/TR/ 1999 / REC-xpath-19991116>。
[DEVICE-YANG] Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. Hopps, "Network Device YANG Logical Organization", Work in Progress, draft-ietf-rtgwg-device-model-02, March 2017.
[DEVICE-YANG] Lindem、A.、Ed。、Berger、L.、Ed。、Bogdanovic、D。、およびC. Hopps、「Network Device YANG Logical Organization」、Work in Progress、draft-ietf-rtgwg-device -model-02、2017年3月。
[IS-IS-YANG] Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for IS-IS protocol", Work in Progress, draft-ietf-isis-yang-isis-cfg-34, January 2019.
[IS-IS-YANG] Litkowski、S.、Yeung、D.、Lindem、A.、Zhang、J。、およびL. Lhotka、「IS-ISプロトコルのYANGデータモデル」、Work in Progress、draft-ietf -isis-yang-isis-cfg-34、2019年1月。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M。およびL. Berger、編、「YANGツリー図」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https://www.rfc-editor.org/info/ rfc8340>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.
[RFC8529] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D。、およびX. Liu、「YANG Data Model for Network Instances」、RFC 8529、DOI 10.17487 / RFC8529、2019年3月、<https ：//www.rfc-editor.org/info/rfc8529>。
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, March 2019, <https://www.rfc-editor.org/info/rfc8530>.
[RFC8530] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D。、およびX. Liu、「YANG Model for Logical Network Elements」、RFC 8530、DOI 10.17487 / RFC8530、2019年3月、<https ：//www.rfc-editor.org/info/rfc8530>。
[YANG-MOUNT] Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined Information from Remote Datastores", Work in Progress, draft-clemm-netmod-mount-06, March 2017.
[YANG-MOUNT] Clemm、A.、Voit、E.、J。Medved、「Mounting YANG-Defined Information from Remote Datastores」、Work in Progress、draft-clemm-netmod-mount-06、2017年3月。
Appendix A. Example: Device Model with LNEs and NIs
付録A.例：LINEとNIを備えたデバイスモデル
This non-normative example demonstrates an implementation of the device model as specified in Section 2 of [DEVICE-YANG], using both logical network elements (LNEs) and network instances (NIs).
この非規範的な例は、論理ネットワーク要素（LNE）とネットワークインスタンス（NI）の両方を使用して、[DEVICE-YANG]のセクション2で指定されているデバイスモデルの実装を示しています。
In these examples, the character '\' is used where a line break has been inserted for formatting reasons.
これらの例では、フォーマット上の理由から改行が挿入されている場所に文字「\」が使用されています。
The data model for the physical device may be described by this YANG library content, assuming the server supports the NMDA:
物理デバイスのデータモデルは、サーバーがNMDAをサポートしていると仮定して、このYANGライブラリコンテンツで記述できます。
{
"ietf-yang-library:yang-library": {
"content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"module-set": [
{
"name": "physical-device-modules",
"module": [
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
},
{
"name": "iana-if-type",
"revision": "2015-06-12",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": ["arbitrary-names", "pre-provisioning" ],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-02-22",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-logical-network-element",
"revision": "2018-03-20",
"feature": [ "bind-lne-name" ],
"namespace":
"urn:ietf:params:xml:ns:yang:\
ietf-logical-network-element"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
}
]
}
],
"schema": [
{
"name": "physical-device-schema",
"module-set": [ "physical-device-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "physical-device-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "physical-device-schema"
}
]
}
}
Each LNE can have a specific data model that is determined at run time, so it is appropriate to mount it using the "inline" method. Hence, the following "schema-mounts" data is used:
各LNEは実行時に決定される特定のデータモデルを持つことができるため、「インライン」方式を使用してマウントするのが適切です。したがって、次の「スキーママウント」データが使用されます。
{
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"inline": {}
}
]
}
}
An administrator of the host device has to configure an entry for each LNE instance, for example:
ホストデバイスの管理者は、LNEインスタンスごとにエントリを設定する必要があります。次に例を示します。
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ietf-logical-network-element:bind-lne-name": "eth0"
}
]
},
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "lne-1",
"managed": true,
"description": "LNE with NIs",
"root": {
...
}
}
...
]
}
}
and then also place necessary state data as the contents of the "root" instance, which should include at least:
そして、必要な状態データを「ルート」インスタンスのコンテンツとして配置します。これには少なくとも以下が含まれている必要があります。
o YANG library data specifying the LNE's data model, for example, assuming the server does not implement the NMDA:
o LNEのデータモデルを指定するYANGライブラリデータ。たとえば、サーバーがNMDAを実装していないと仮定します。
{
"ietf-yang-library:modules-state": {
"module-set-id": "9358e11874068c8be06562089e94a89e0a392019",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "implement"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"feature": [
"ipv6-privacy-autoconf"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-03-20",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
}
}
o state data for interfaces assigned to the LNE instance (that effectively become system-controlled interfaces for the LNE), for example:
o ONEインスタンスに割り当てられたインターフェース（実質的にONEのシステム制御インターフェースになる）の状態データ。次に例を示します。
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2016-12-16T17:11:27+02:00"
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "fe80::42a8:f0ff:fea8:24fe",
"origin": "link-layer",
"prefix-length": 64
}
]
}
}
]
}
}
Assuming that network instances share the same data model, it can be mounted using the "shared-schema" method as follows:
ネットワークインスタンスが同じデータモデルを共有すると仮定すると、次のように「共有スキーマ」メソッドを使用してマウントできます。
{
"ietf-yang-schema-mount:schema-mounts": {
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface[\
ni:bind-network-instance-name = current()/../ni:name]"
]
}
}
]
}
}
Note also that the "ietf-interfaces" module appears in the "parent-reference" leaf-list for the mounted NI schema. This means that references to LNE interfaces, such as "outgoing-interface" in static routes, are valid despite the fact that "ietf-interfaces" isn't part of the NI schema.
「ietf-interfaces」モジュールが、マウントされたNIスキーマの「親参照」リーフリストに表示されることにも注意してください。これは、「ietf-interfaces」がNIスキーマの一部ではないにもかかわらず、静的ルートの「outgoing-interface」などのLNEインターフェースへの参照が有効であることを意味します。
Assume that the mounted NI data model also implements the "ietf-isis" module [IS-IS-YANG]. An RPC operation defined in this module, such as "clear-adjacency", can be invoked by a client session of an LNE's RESTCONF server as an action tied to the mount point of a particular network instance using a request URI like this (all on one line):
マウントされたNIデータモデルも「ietf-isis」モジュール[IS-IS-YANG]を実装するとします。このモジュールで定義されている「clear-adjacency」などのRPC操作は、LNEのRESTCONFサーバーのクライアントセッションによって、このようなリクエストURIを使用して特定のネットワークインスタンスのマウントポイントに関連付けられたアクションとして呼び出すことができます（すべて1行）：
POST /restconf/data/ietf-network-instance:network-instances/
network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1
Contributors
貢献者
The idea of having some way to combine schemas from different YANG modules into one has been proposed independently by others:
さまざまなYANGモジュールのスキーマを1つに結合する方法があるというアイデアは、他のユーザーによって独自に提案されています。
o Authors of [YANG-MOUNT]:
o [YANG-MOUNT]の作成者：
* Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
* Lou Berger、LabN Consulting、L.L.C。、<lberger@labn.net>
* Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
* Alexander Clemm、Huawei、<alexander.clemm@huawei.com>
* Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
* Christian Hopps、Deutsche Telekom、<chopps@chopps.org>
o Jan Medved, Cisco, <jmedved@cisco.com>
o Jan Medved、Cisco、<jmedved@cisco.com>
o Eric Voit, Cisco, <evoit@cisco.com>
o Eric Voit、Cisco、<evoit@cisco.com>
Authors' Addresses
著者のアドレス
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com
Ladislav Lhotka CZ.NIC
ラディスラフ・ロトカCZ.NIC
Email: lhotka@nic.cz