[要約] RFC 8340は、YANGツリーダイアグラムの標準化を目的としています。このRFCは、YANGデータモデルの視覚的な表現を提供し、ネットワーク機器の設定や管理を容易にすることを目指しています。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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に記載されているように保証なしで提供されます。
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
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}?
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.
1. モジュールで定義された最上位のデータノード。2つのスペースでオフセットされます。
2. Augmentations, offset by two spaces and identified by the keyword "augment" followed by the augment target node and a colon (":") character.
2. 2つのスペースでオフセットされ、キーワード "augment"の後に拡張ターゲットノードとコロン（ "："）文字が続くことで識別される拡張。
3. RPCs, offset by two spaces and identified by "rpcs:".
3. RPC。2つのスペースでオフセットされ、「rpcs：」で識別されます。
4. Notifications, offset by two spaces and identified by "notifications:".
4. 通知。2つのスペースでオフセットされ、「通知：」で識別されます。
5. Groupings, offset by two spaces and identified by the keyword "grouping" followed by the name of the grouping and a colon (":") character.
5. グループ化。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.
6. 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.
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>
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>
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.
グループ化は、「グループ化」セクションにオプションで存在できます。
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」セクションに存在する場合があります。
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>
Single line comments, starting with "//" (possibly indented) and ending at the end of the line, may be used in the tree notation.
"//"（おそらくインデントされている）で始まり、行の終わりで終わる単一行コメントは、ツリー表記で使用できます。
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
<flags>は次のいずれかです。構成データノードと選択ノードのrw非構成データノードと選択ノードのro、rpcsとアクションへの出力パラメーター、およびrpcsとアクションへの入力パラメーター-wの使用rpcsの場合はグループ化-x、通知の場合はアクション-n「マウントポイント」拡張ステートメントを含むノードのmp
Case nodes do not have any <flags>.
ケースノードには<フラグ>がありません。
<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
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の場合！プレゼンスコンテナーの場合*リーフリストまたはリスト[<キー>]の場合リストのキーの場合/マウントされたモジュールの最上位のデータノードの場合@マウントポイントの親で識別されるモジュールの最上位のデータノードの場合参照
<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 "{...}?"
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>）の間では、任意の空白を使用できます。たとえば、追加の空白を使用して、フィールドを「列揃え」して（リストやコンテナ内など）、読みやすさを向上させることができます。
This section provides general guidelines related to the use of tree diagrams in RFCs.
このセクションでは、RFCでのツリー図の使用に関する一般的なガイドラインを示します。
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:
/ 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
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」が適切に機能します。
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」コマンドラインパラメータを使用して、グループ化されたツリー図を作成できます。
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 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
"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」フラグを使用して上記のようにツリー図で識別できます。
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
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],
このような図では、マウントポイントは、グループ化を使用するコンテナーのように扱う必要があります。フラグは、上記の「構成」リーフに基づいて設定する必要があります。また、マウントまたは参照されるモジュールの最上位ノードに対して、上記のマウント関連のオプションを表示する必要があります。 [YANG-NIs]から抜粋した次の例は、
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モジュール「ietf-routing」[YANG-Routing]と「ietf-ospf」[OSPF-YANG]がマウントされた前の例を表し、YANGモジュールのノード「ietf-interfaces」[RFC8343]から親参照を介してアクセス可能、「true」を示す「config」：
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」リーフによって決定され、最上位のマウントされたノードに示されます。
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
...
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
There is no security impact related to the tree diagrams defined in this document.
このドキュメントで定義されているツリー図に関連するセキュリティへの影響はありません。
[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.
[OSPF-YANG] Yeung、D.、Qu、Y.、Zhang、J.、Chen、I。、およびA. Lindem、「OSPFプロトコルのヤンデータモデル」、作業中、draft-ietf-ospf-yang -10、2018年3月。
[PYANG] "pyang", February 2018, <https://github.com/mbj4668/pyang>.
[PYANG]「pyang」、2018年2月、<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>.
[RFC7407] Bjorklund、M。、およびJ. Schoenwaelder、「SNMP構成用のYANGデータモデル」、RFC 7407、DOI 10.17487 / RFC7407、2014年12月、<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>.
[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 >。
[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>。
[SCHEMA-MOUNT] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", Work in Progress, draft-ietf-netmod-schema-mount-08, October 2017.
[スキーママウント] Bjorklund、M。およびL. Lhotka、「YANGスキーママウント」、作業中、draft-ietf-netmod-schema-mount-08、2017年10月。
[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-NIs] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D。、およびX. Liu、「YANG Model for Network Instances」、Work in Progress、draft-ietf-rtgwg-ni-モデル-11、2018年3月。
[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.
[YANG-Routing] Lhotka、L.、Lindem、A。、およびY. Qu、「ルーティング管理用のYANGデータモデル（NMDAバージョン）」、作業中、draft-ietf-netmod-rfc8022bis-11、2018年1月。
Authors' Addresses
著者のアドレス
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com
Lou Berger (editor) LabN Consulting, L.L.C.
ルーバーガー（編集者）LabN Consulting、L.L.C.
Email: lberger@labn.net