ヤンツリー図
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 8340 Tail-f Systems
BCP: 215 L. Berger, Ed.
Category: Best Current Practice LabN Consulting, L.L.C.
ISSN: 2070-1721 March 2018
YANG Tree Diagrams
ヤンツリー図
Abstract
概要
This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
このドキュメントは、YANGモジュールツリー図で使用されている現在の構文をキャプチャします。 このドキュメントの目的は、この定義に対して単一の場所を提供することです。 この構文は、YANG言語の進化に基づいて随時更新される場合があります。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8340.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8340で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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に記載されているように保証なしで提供されます。
Bjorklund & Berger Best Current Practice [Page 1]
RFC 8340 YANG Tree Diagrams March 2018
Table of Contents
1. Introduction ....................................................2
2. Tree Diagram Syntax .............................................3
2.1. Submodules .................................................5
2.2. Groupings ..................................................5
2.3. yang-data ..................................................5
2.4. Collapsed Node Representation ..............................6
2.5. Comments ...................................................6
2.6. Node Representation ........................................6
3. Usage Guidelines for RFCs .......................................7
3.1. Wrapping Long Lines ........................................8
3.2. Groupings ..................................................8
3.3. Long Diagrams ..............................................8
4. YANG Schema Mount Tree Diagrams .................................9
4.1. Representation of Mounted Schema Trees ....................10
5. IANA Considerations ............................................12
6. Security Considerations ........................................12
7. Informative References .........................................12
Authors' Addresses ................................................13
1.はじめに............................................... ..... 2
2.ツリー図の構文............................................. ３
2.1。サブモジュール................................................................. 5
2.2。グルーピング................................................................. .5
2.3。ヤンデータ............................................... ... 5
2.4。折りたたまれたノード表現.............................. 6
2.5。コメント................................................................ ..6
2.6。ノード表現........................................ 6
3. RFCの使用ガイドライン................................................. 7
3.1。長い行の折り返し................................................................. 8
3.2。グルーピング................................................................. .8
3.3。長い図表.............................................. 8
4. YANGスキーママウントツリー図................................. 9
4.1。マウントされたスキーマツリーの表現.................... 10
5. IANAの考慮事項............................................ 12
6.セキュリティに関する注意事項........................................ 12
7.参考資料.................................................. 12
著者のアドレス............................................... .13
1. Introduction
1.はじめに
YANG tree diagrams were first published in RFC 6536. Such diagrams are used to provide a simplified graphical representation of a data model and can be automatically generated via tools such as "pyang" [PYANG]. This document describes the syntax used in YANG tree diagrams. It is expected that this document will be updated or replaced as changes to the YANG language [RFC7950] necessitate.
YANGツリー図は、RFC 6536で最初に公開されました。 このような図は、データモデルの簡略化されたグラフィック表現を提供するために使用され、「pyang」[PYANG]などのツールを介して自動的に生成できます。 このドキュメントでは、YANGツリー図で使用される構文について説明します。 このドキュメントは、YANG言語[RFC7950]への変更に応じて更新または置き換えられることが期待されています。
Today's common practice is to include the definition of the syntax used to represent a YANG module in every document that provides a tree diagram. This practice has several disadvantages; therefore, the purpose of this document is to provide a single location for this definition. It is not the intent of this document to restrict future changes, but rather to ensure that such changes are easily identified and suitably agreed upon.
今日の一般的な方法は、ツリー図を提供するすべてのドキュメントに、YANGモジュールを表すために使用される構文の定義を含めることです。 この方法にはいくつかの欠点があります。 したがって、このドキュメントの目的は、この定義に対して単一の場所を提供することです。 このドキュメントの目的は、将来の変更を制限することではなく、そのような変更が容易に識別され、適切に合意されるようにすることです。
An example tree diagram can be found in Section 3 of [RFC8343]; the following is a portion of it:
ツリー図の例は、[RFC8343]のセクション3にあります。 以下はその一部です：
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--rw description? string
+--rw type identityref
+--rw enabled? boolean
+--rw link-up-down-trap-enable? enumeration {if-mib}?
Bjorklund & Berger Best Current Practice [Page 2]
RFC 8340 YANG Tree Diagrams March 2018
2. Tree Diagram Syntax
2.ツリー図の構文
This section describes the meaning of the symbols used in YANG tree diagrams.
このセクションでは、YANGツリー図で使用される記号の意味について説明します。
A full tree diagram of a module represents all elements. It includes the name of the module and sections for top-level module statements (typically containers), augmentations, rpcs, and notifications all identified under a module statement. Module trees may be included in a document as a whole, by one or more sections, or even by subsets of nodes.
モジュールの完全なツリー図は、すべての要素を表します。 これには、モジュールの名前と、最上位のモジュールステートメント（通常はコンテナー）、拡張、rpcs、およびモジュールステートメントの下で識別される通知のセクションが含まれます。 モジュールツリーは、1つまたは複数のセクション、またはノードのサブセットによって、ドキュメント全体に含めることができます。
A module is identified by "module:" followed by the module-name. This is followed by one or more sections, in order:
モジュールは、「module：」とそれに続くmodule-nameで識別されます。 この後に、1つ以上のセクションが順番に続きます。
1. The top-level data nodes defined in the module, offset by
two spaces.
モジュールで定義された最上位のデータノード。2つのスペースでオフセットされます。
2. Augmentations, offset by two spaces and identified by the keyword
"augment" followed by the augment target node and a colon (":")
character.
2つのスペースでオフセットされ、キーワード "augment"で識別され、その後に拡張ターゲットノードとコロン（ "："）文字が続く拡張。
3. RPCs, offset by two spaces and identified by "rpcs:".
RPC。2つのスペースでオフセットされ、「rpcs：」で識別されます。
4. Notifications, offset by two spaces and identified by
"notifications:".
通知。2つのスペースでオフセットされ、「通知：」で識別されます。
5. Groupings, offset by two spaces and identified by the keyword
"grouping" followed by the name of the grouping and a colon (":")
character.
グループ化。2つのスペースでオフセットされ、キーワード "grouping"の後にグループ化の名前とコロン（ "："）文字が続きます。
6. yang-data, offset by two spaces and identified by the keyword
"yang-data" followed by the name of the yang-data structure and a
colon (":") character.
2つのスペースでオフセットされ、キーワード "yang-data"とそれに続くyang-data構造の名前とコロン（ "："）文字で識別されるyang-data。
The relative organization of each section is provided using a
text-based format that is typical of a file system directory tree
display command. Each node in the tree is prefaced with "+--".
Schema nodes that are children of another node are offset from the
parent by three spaces. Sibling schema nodes are listed with the
same space offset and, when separated by lines, are linked via a
vertical bar ("|") character.
各セクションの相対的な構成は、ファイルシステムのディレクトリツリー表示コマンドに典型的なテキストベースの形式を使用して提供されます。 ツリーの各ノードの前には「+-」が付いています。 別のノードの子であるスキーマノードは、親から3つのスペースだけオフセットされます。 兄弟スキーマノードは同じスペースオフセットでリストされ、線で区切られている場合、垂直バー（ "|"）文字でリンクされます。
Bjorklund & Berger Best Current Practice [Page 3] RFC 8340 YANG Tree Diagrams March 2018 The full format, including spacing conventions, is:
間隔の規則を含む完全な形式は次のとおりです。
module: <module-name>
+--<node>
| +--<node>
| +--<node>
+--<node>
+--<node>
+--<node>
augment <target-node>:
+--<node>
+--<node>
+--<node>
+--<node>
augment <target-node>:
+--<node>
rpcs:
+--<rpc-node>
+--<rpc-node>
+--<node>
| +--<node>
+--<node>
notifications:
+--<notification-node>
+--<notification-node>
+--<node>
| +--<node>
+--<node>
grouping <grouping-name>:
+--<node>
+--<node>
| +--<node>
+--<node>
grouping <grouping-name>:
+--<node>
yang-data <yang-data-name>:
+--<node>
+--<node>
| +--<node>
+--<node>
yang-data <yang-data-name>:
+--<node>
Bjorklund & Berger Best Current Practice [Page 4]
RFC 8340 YANG Tree Diagrams March 2018
2.1. Submodules
2.1。 サブモジュール
Submodules are represented in the same fashion as modules but are identified by "submodule:" followed by the (sub)module-name. For example:
サブモジュールはモジュールと同じ方法で表されますが、「サブモジュール：」で識別され、その後に（サブ）モジュール名が続きます。 例えば：
submodule: <module-name>
+--<node>
| +--<node>
| +--<node>
2.2. Groupings
2.2。 グルーピング
Nodes within a used grouping are normally expanded as if the nodes were defined at the location of the "uses" statement. However, it is also possible to not expand the "uses" statement but to instead print the name of the grouping.
使用されたグループ内のノードは、通常、「uses」ステートメントの場所でノードが定義されたかのように展開されます。 ただし、「uses」ステートメントを展開せずに、グループ化の名前を出力することもできます。
For example, the following diagram shows the "tls-transport" grouping from [RFC7407] unexpanded:
たとえば、次の図は、[RFC7407]からの「tls-transport」グループ化を示しています。
+--rw tls
+---u tls-transport
If the grouping is expanded, it could be printed as:
グループ化が展開されている場合、次のように出力されます。
+--rw tls
+--rw port? inet:port-number
+--rw client-fingerprint? x509c2n:tls-fingerprint
+--rw server-fingerprint? x509c2n:tls-fingerprint
+--rw server-identity? snmp:admin-string
Groupings may optionally be present in the "groupings" section.
グループ化は、「グループ化」セクションにオプションで存在できます。
2.3. yang-data
2.3。 ヤン・データ
If the module defines a "yang-data" structure [RFC8040], these structures may optionally be present in the "yang-data" section.
モジュールが「yang-data」構造[RFC8040]を定義している場合、これらの構造はオプションで「yang-data」セクションに存在する場合があります。
Bjorklund & Berger Best Current Practice [Page 5] RFC 8340 YANG Tree Diagrams March 2018 2.4. Collapsed Node Representation
2.4。 折りたたまれたノードの表現
At times when the composition of the nodes within a module schema is not important in the context of the presented tree, sibling nodes and their children can be collapsed using the notation "..." in place of the text lines used to represent the summarized nodes. For example:
提示されたツリーのコンテキストでモジュールスキーマ内のノードの構成が重要ではない場合、要約ノードを表すために使用されるテキスト行の代わりに「...」という表記を使用して、兄弟ノードとその子を折りたたむことができます。 ノード。 例えば：
+--<node>
| ...
+--<node>
+--<node>
+--<node>
2.5. Comments
2.5。 コメント
Single line comments, starting with "//" (possibly indented) and ending at the end of the line, may be used in the tree notation.
"//"（おそらくインデントされている）で始まり、行の終わりで終わる単一行コメントは、ツリー表記で使用できます。
2.6. Node Representation
2.6。 ノード表現
Each node in a YANG module is printed as:
YANGモジュールの各ノードは次のように出力されます。
<status>--<flags> <name><opts> <type> <if-features>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<status>は次のいずれかです。
+ 現在の
x 廃止予定の
o 廃止された
<flags> is one of:
rw for configuration data nodes and choice nodes
ro for non-configuration data nodes and choice nodes,
output parameters to rpcs and actions, and
notification parameters
-w for input parameters to rpcs and actions
-u for uses of a grouping
-x for rpcs and actions
-n for notifications
mp for nodes containing a "mount-point" extension statement
Case nodes do not have any <flags>.
<flags>は次のいずれかです。
rw 構成データノードおよび選択ノード用
ro 非構成データノードと選択ノード、rpcsとアクションへの出力パラメーター、および通知パラメーター
-w rpcsおよびアクションへの入力パラメーター
-u グループ化の使用のため
-x RPCとアクション
-n 通知用
mp 「マウントポイント」拡張ステートメントを含むノードの場合
ケースノードには<フラグ>がありません。
Bjorklund & Berger Best Current Practice [Page 6]
RFC 8340 YANG Tree Diagrams March 2018
<name> is the name of the node
(<name>) means that the node is a choice node
:(<name>) means that the node is a case node
<name>はノードの名前です
（<name>）は、ノードが選択ノードであることを意味します
：（<name>）は、ノードがケースノードであることを意味します
If the node is augmented into the tree from another module,
its name is printed as <prefix>:<name>, where <prefix> is the
prefix defined in the module where the node is defined.
ノードが別のモジュールからツリーに追加されている場合、その名前は<prefix>：<name>として出力されます。<prefix>は、ノードが定義されているモジュールで定義されているプレフィックスです。
If the node is a case node, there is no space before the
<name>.
ノードがケースノードの場合、<name>の前にスペースはありません。
<opts> is one of:
? for an optional leaf, choice, anydata, or anyxml
! for a presence container
* for a leaf-list or list
[<keys>] for a list's keys
/ for a top-level data node in a mounted module
@ for a top-level data node of a module identified in a
mount point parent reference
<opts>は次のいずれかです。
? オプションのleaf、choice、anydata、またはanyxmlの場合
! プレゼンスコンテナ用
* リーフリストまたはリストの場合
[<keys>] リストのキー
/ マウントされたモジュールの最上位データノードの場合
@ マウントポイントの親参照で識別されるモジュールの最上位データノード
<type> is the name of the type for leafs and leaf-lists
<type>は、リーフとリーフリストのタイプの名前です
If the type is a leafref, the type is printed as either
(1) "-> TARGET", where TARGET is the leafref path,
with prefixes removed if possible or (2) "leafref".
タイプがleafrefの場合、タイプは（1） "-> TARGET"として出力されます。ここでTARGETはleafrefパスであり、可能であればプレフィックスが削除されているか、（2） "leafref"です。
<if-features> is the list of features this node depends on,
printed within curly brackets and a question mark "{...}?"
<if-features>は、このノードが依存する機能のリストで、中括弧と疑問符「{...}？」内に出力されます
Arbitrary whitespace is allowed between any of the whitespace- separated fields (e.g., <opts> and <type>). Additional whitespace may, for example, be used to "column align" fields (e.g., within a list or container) to improve readability.
空白で区切られたフィールド（<opts>と<type>など）の間には任意の空白を使用できます。 たとえば、追加の空白を使用して、フィールドを「列揃え」して（リストやコンテナ内など）、読みやすさを向上させることができます。
3. Usage Guidelines for RFCs
3. RFCの使用ガイドライン
This section provides general guidelines related to the use of tree diagrams in RFCs.
このセクションでは、RFCでのツリー図の使用に関する一般的なガイドラインを示します。
Bjorklund & Berger Best Current Practice [Page 7] RFC 8340 YANG Tree Diagrams March 2018 3.1. Wrapping Long Lines
3.1。 長い行の折り返し
Internet-Drafts and RFCs limit the number of characters that may appear in a line of text to 72 characters. When the tree representation of a node results in a line being longer than this limit, the line should be broken between <opts> and <type> or between <type> and <if-feature>. The new line should be indented so that it starts below <name> with a whitespace offset of at least two characters. For example:
Internet-DraftsとRFCは、テキストの行に表示できる文字数を72文字に制限しています。 ノードのツリー表現の結果、この制限よりも長い行になる場合、<opts>と<type>の間、または<type>と<if-feature>の間で行を分割する必要があります。 新しい行は、少なくとも2文字の空白オフセットで<name>の下から始まるようにインデントする必要があります。 例えば：
notifications:
+---n yang-library-change
+--ro module-set-id
-> /modules-state/module-set-id
Long paths (e.g., leafref paths or augment targets) can be split and
printed on more than one line. For example:
長いパス（たとえば、leafrefパスまたは拡張ターゲット）は、複数の行に分割して印刷できます。 例えば：
augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
/nat:mapping-entry:
The previously mentioned "pyang" command can be helpful in producing
such output; for example, the notification diagram above was produced
using:
前述の「pyang」コマンドは、このような出力を生成するのに役立ちます。 たとえば、上記の通知図は以下を使用して作成されました。
pyang -f tree --tree-line-length 50 ietf-yang-library.yang
When a tree diagram is included as a figure in an Internet-Draft or
RFC, "--tree-line-length 69" works well.
ツリー図がInternet-DraftまたはRFCに図として含まれている場合、「--tree-line-length 69」が適切に機能します。
3.2. Groupings
3.2。 グルーピング
If the YANG module is comprised of groupings only, then the tree diagram should contain the groupings. The "pyang" compiler can be used to produce a tree diagram with groupings using the "-f tree --tree-print-groupings" command-line parameters.
YANGモジュールがグループ化のみで構成されている場合、ツリー図にはグループ化が含まれている必要があります。 「pyang」コンパイラを使用すると、「-f tree --tree-print-groupings」コマンドラインパラメータを使用して、グループ化されたツリー図を作成できます。
3.3. Long Diagrams
3.3。 ロングダイアグラム
Tree diagrams can be split into sections to correspond to document structure. As tree diagrams are intended to provide a simplified view of a module, diagrams longer than a page should generally be avoided. If the complete tree diagram for a module becomes too long, the diagram can be split into several smaller diagrams. For example, it might be possible to have one diagram with the data node and another with all notifications. If the data nodes tree is too long, it is also possible to split the diagram into smaller diagrams for Bjorklund & Berger Best Current Practice [Page 8] RFC 8340 YANG Tree Diagrams March 2018 different subtrees. When long diagrams are included in a document, authors should consider whether to include the long diagram in the main body of the document or in an appendix.
ツリー図は、ドキュメント構造に対応するようにセクションに分割できます。 ツリー図はモジュールの簡略化されたビューを提供することを目的としているため、ページよりも長い図は一般に避けられるべきです。 モジュールの完全なツリー図が長すぎる場合は、図をいくつかの小さな図に分割できます。 たとえば、1つの図にデータノードを、もう1つの図にすべての通知を含めることができます。 データノードツリーが長すぎる場合は、図を異なるサブツリーの小さな図に分割することもできます。 長い図表がドキュメントに含まれている場合、作成者は長い図表をドキュメントの本体に含めるか、付録に含めるかを検討する必要があります。
An example of such a split can be found in [RFC7407], where Section 2.4 of that document shows the diagram for "engine configuration":
そのような分割の例は、[RFC7407]にあり、そのドキュメントのセクション2.4は、「エンジン構成」の図を示しています。
+--rw snmp
+--rw engine
// more parameters from the "engine" subtree here
Further, Section 2.5 of [RFC7407] shows the diagram for "target
configuration":
さらに、[RFC7407]のセクション2.5は、「ターゲット構成」の図を示しています。
+--rw snmp
+--rw target* [name]
// more parameters from the "target" subtree here
The previously mentioned "pyang" command can be helpful in producing
such output; for example, the above example was produced using:
前述の「pyang」コマンドは、このような出力を生成するのに役立ちます。 たとえば、上記の例は以下を使用して作成されました。
pyang -f tree --tree-path /snmp/target ietf-snmp.yang
4. YANG Schema Mount Tree Diagrams
4. YANGスキーママウントツリー図
"YANG schema mount" is defined in [SCHEMA-MOUNT] and warrants some specific discussion. Schema mount is a generic mechanism that allows for the mounting of one or more YANG modules at a specified location of another (parent) schema. The specific location is referred to as a "mount point", and any container or list node in a schema may serve as a mount point. Mount points are identified via the inclusion of the "mount-point" extension statement as a substatement under a container or list node. Mount point nodes are thus directly identified in a module schema definition and can be identified in a tree diagram as indicated above using the "mp" flag.
「YANGスキーママウント」は[SCHEMA-MOUNT]で定義されており、特定の議論が必要です。 スキーママウントは、1つまたは複数のYANGモジュールを別の（親）スキーマの指定された場所にマウントできるようにする一般的なメカニズムです。 特定の場所は「マウントポイント」と呼ばれ、スキーマ内の任意のコンテナーまたはリストノードがマウントポイントとして機能します。 マウントポイントは、「mount-point」拡張ステートメントをコンテナまたはリストノードの下のサブステートメントとして含めることで識別されます。 したがって、マウントポイントノードはモジュールスキーマ定義で直接識別され、「mp」フラグを使用して上記のツリー図で識別できます。
Bjorklund & Berger Best Current Practice [Page 9] RFC 8340 YANG Tree Diagrams March 2018 In the following example taken from [YANG-NIs], "vrf-root" is a container that includes the "mount-point" extension statement as part of its definition:
[YANG-NIs]から抜粋した次の例では、「vrf-root」は、その定義の一部として「mount-point」拡張ステートメントを含むコンテナです。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
| +--mp vrf-root
4.1. Representation of Mounted Schema Trees
4.1。 マウントされたスキーマツリーの表現
The actual modules made available under a mount point are controlled
by a server and are provided to clients. This information is
typically provided via the schema mount module
("ietf-yang-schema-mount") defined in [SCHEMA-MOUNT]. The schema
mount module supports the exposure of both mounted schema and
"parent-references". Parent references are used for XML Path
Language (XPath) evaluation within mounted modules and do not
represent client-accessible paths; the referenced information is
available to clients via the parent schema. Schema mount also
defines an "inline" type of mount point, where mounted modules are
exposed via the YANG library module.
マウントポイントで使用できる実際のモジュールは、サーバーによって制御され、クライアントに提供されます。 この情報は通常、[SCHEMA-MOUNT]で定義されているスキーママウントモジュール（ "ietf-yang-schema-mount"）を介して提供されます。 スキーママウントモジュールは、マウントされたスキーマと「親参照」の両方の公開をサポートしています。 親参照は、マウントされたモジュール内のXMLパス言語（XPath）評価に使用され、クライアントがアクセス可能なパスを表すものではありません。 参照される情報は、親スキーマを介してクライアントが利用できます。 スキーママウントは、マウントされたモジュールがYANGライブラリモジュールを介して公開される「インライン」タイプのマウントポイントも定義します。
Although the modules made available under a mount point are not specified in YANG modules that include mount points, the document defining the module will describe the intended use of the module and may identify both modules that will be mounted and parent modules that can be referenced by mounted modules. An example of such a description can be found in [YANG-NIs]. A specific implementation of a module containing mount points will also support a specific list of mounted and referenced modules. In describing both intended use and actual implementations, it is helpful to show how mounted modules would be instantiated and referenced under a mount point using tree diagrams.
マウントポイントで使用できるようになっているモジュールは、マウントポイントを含むYANGモジュールでは指定されていませんが、モジュールを定義するドキュメントには、モジュールの使用目的が記載されており、マウントされる両方のモジュールと、 マウントされたモジュール。 そのような説明の例は、[YANG-NIs]にあります。 マウントポイントを含むモジュールの特定の実装は、マウントおよび参照されるモジュールの特定のリストもサポートします。 使用目的と実際の実装の両方を説明する際に、ツリー図を使用して、マウントされたモジュールがどのようにインスタンス化され、マウントポイントの下で参照されるかを示すことが役立ちます。
In such diagrams, the mount point should be treated much like a container that uses a grouping. The flags should also be set based on the "config" leaf mentioned above, and the mount-related options indicated above should be shown for the top-level nodes in a mounted or referenced module. The following example, taken from [YANG-NIs], Bjorklund & Berger Best Current Practice [Page 10] RFC 8340 YANG Tree Diagrams March 2018 represents the prior example with the YANG modules "ietf-routing" [YANG-Routing] and "ietf-ospf" [OSPF-YANG] mounted, nodes from the YANG module "ietf-interfaces" [RFC8343] accessible via a parent-reference, and "config" indicating "true":
このような図では、マウントポイントは、グループ化を使用するコンテナーのように扱う必要があります。 フラグは、上記の「構成」リーフに基づいて設定する必要があります。また、マウントまたは参照されたモジュールの最上位ノードに対して、上記のマウント関連オプションを表示する必要があります。 [YANG-NIs]から抜粋した次の例は、YANGモジュール「ietf-routing」[YANG-Routing]および「ietf-ospf」[OSPF-YANG]がマウントされた、YANGモジュール「ietf」のノードを使用した前の例を表しています。 -interfaces "[RFC8343]は親参照を介してアクセスでき、" config "は" true "を示します。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
+--mp vrf-root
+--ro rt:routing-state/
| +--ro router-id?
| +--ro control-plane-protocols
| +--ro control-plane-protocol* [type name]
| +--ro ospf:ospf
| +--ro instance* [af]
| ...
+--rw rt:routing/
| +--rw router-id?
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf
| +--rw instance* [af]
| ...
+--ro if:interfaces@
| ...
+--ro if:interfaces-state@
| ...
It is worth highlighting that the "ietf-ospf" module augments the
"ietf-routing" module, and although it is listed in the schema mount
module (or inline YANG library), there is no special mount-related
notation in the tree diagram.
「ietf-ospf」モジュールが「ietf-routing」モジュールを補強することは強調する価値があります。スキーママウントモジュール（またはインラインYANGライブラリ）にリストされていますが、ツリーダイアグラムには特別なマウント関連の表記はありません。 。
A mount point definition alone is not sufficient to identify whether the mounted modules are used for configuration data or for non-configuration data. This is determined by the "ietf-yang-schema-mount" module's "config" leaf associated with the specific mount point and is indicated on the top-level mounted nodes.
マウントポイントの定義だけでは、マウントされたモジュールが構成データに使用されているのか、非構成データに使用されているのかを識別するには不十分です。 これは、特定のマウントポイントに関連付けられた「ietf-yang-schema-mount」モジュールの「config」リーフによって決定され、最上位のマウントされたノードに示されます。
Bjorklund & Berger Best Current Practice [Page 11] RFC 8340 YANG Tree Diagrams March 2018 For example, in the above tree, when the "config" leaf for the "ietf-routing" module indicates "false", the nodes in the "rt:routing" subtree would have different flags:
たとえば、上記のツリーで、「ietf-routing」モジュールの「config」リーフが「false」を示している場合、「rt：routing」サブツリーのノードには異なるフラグがあります。
+--ro rt:routing/
| +--ro router-id?
| +--ro control-plane-protocols
...
5. IANA Considerations
5. IANAに関する考慮事項
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
6. Security Considerations
6.セキュリティに関する考慮事項
There is no security impact related to the tree diagrams defined in this document.
このドキュメントで定義されているツリー図に関連するセキュリティへの影響はありません。
7. Informative References
7.有益な参照
[OSPF-YANG]
Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem,
"Yang Data Model for OSPF Protocol", Work in Progress,
draft-ietf-ospf-yang-10, March 2018.
[PYANG] "pyang", February 2018,
<https://github.com/mbj4668/pyang>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[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>.
[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>.
[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>.
[SCHEMA-MOUNT]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", Work in
Progress, draft-ietf-netmod-schema-mount-08, October 2017.
Bjorklund & Berger Best Current Practice [Page 12]
RFC 8340 YANG Tree Diagrams March 2018
[YANG-NIs] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Network Instances", Work in
Progress, draft-ietf-rtgwg-ni-model-11, March 2018.
[YANG-Routing]
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", Work in Progress,
draft-ietf-netmod-rfc8022bis-11, January 2018.
Authors' Addresses
Martin Bjorklund
Tail-f Systems
Email: mbj@tail-f.com
Lou Berger (editor)
LabN Consulting, L.L.C.
Email: lberger@labn.net
Bjorklund & Berger Best Current Practice [Page 13]