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
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.
本文档捕获模块树形图中使用的当前语法。本文件旨在为该定义提供一个单一位置。这种语法可能会根据杨语的演变不时更新。
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）的产品。它代表了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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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. 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.
杨树图最早发表于RFC6536。此类图表用于提供数据模型的简化图形表示，并可通过“pyang”[pyang]等工具自动生成。本文档描述杨树图中使用的语法。预计本文件将根据需要对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}?
+--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.
本节描述杨树图中使用的符号的含义。
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.
模块的完整树形图表示所有元素。它包括模块的名称以及顶级模块语句（通常为容器）、扩充、RPC和通知的部分，所有这些都在模块语句下标识。模块树可以作为一个整体、一个或多个部分、甚至节点子集包含在文档中。
A module is identified by "module:" followed by the module-name. This is followed by one or more sections, in order:
模块由“模块：”标识，后跟模块名称。然后是一个或多个部分，顺序如下：
1. The top-level data nodes defined in the module, offset by two spaces.
1. 模块中定义的顶级数据节点，偏移两个空格。
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:".
3. RPC，由两个空格偏移，并由“RPC:”标识。
4. Notifications, offset by two spaces and identified by "notifications:".
4. 通知，由两个空格隔开，并由“通知：”标识。
5. Groupings, offset by two spaces and identified by the keyword "grouping" followed by the name of the grouping and a colon (":") character.
5. 分组，由两个空格偏移，由关键字“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. yang数据，由两个空格偏移，由关键字“yang data”标识，后跟yang数据结构的名称和冒号（“：”）字符。
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 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>
module: <module-name>
+--<node>
| +--<node>
| +--<node>
+--<node>
+--<node>
+--<node>
augment <target-node>:
+--<node>
+--<node>
+--<node>
+--<node>
augment <target-node>:
+--<node>
augment <target-node>:
+--<node>
+--<node>
+--<node>
+--<node>
augment <target-node>:
+--<node>
rpcs:
+--<rpc-node>
+--<rpc-node>
+--<node>
| +--<node>
+--<node>
rpcs:
+--<rpc-node>
+--<rpc-node>
+--<node>
| +--<node>
+--<node>
notifications:
+--<notification-node>
+--<notification-node>
+--<node>
| +--<node>
+--<node>
notifications:
+--<notification-node>
+--<notification-node>
+--<node>
| +--<node>
+--<node>
grouping <grouping-name>:
+--<node>
+--<node>
| +--<node>
+--<node>
grouping <grouping-name>:
+--<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>
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:”标识，后跟（子）模块名称。例如：
submodule: <module-name>
+--<node>
| +--<node>
| +--<node>
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传输”分组：
+--rw tls
+---u 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
+--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.
如果模块定义了“阳数据”结构[RFC8040]，则这些结构可以选择性地出现在“阳数据”部分中。
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>
+--<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:
模块中的每个节点打印为：
<status>--<flags> <name><opts> <type> <if-features>
<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用于非配置数据节点和选择节点，输出参数用于RPC和操作，通知参数-w用于RPC和操作的输入参数-u用于分组-x用于RPC和操作-n用于通知mp用于包含“装载点”的节点扩展语句
Case nodes do not have any <flags>.
案例节点没有任何<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
<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>是下列各项之一：？对于可选的叶、选项、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> 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草稿和RFC将文本行中可能出现的字符数限制为72个字符。当节点的树表示导致一条线超过此限制时，该线应在<opts>和<type>之间或<type>和<if feature>之间断开。新行应缩进，以使其从<name>下方开始，空格偏移量至少为两个字符。例如：
notifications:
+---n yang-library-change
+--ro module-set-id
-> /modules-state/module-set-id
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:
augment/nat:nat/nat:instances/nat:instance/nat:mapping表/nat:mapping条目：
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树——树线长度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草稿或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.
不同的子树。当文档中包含长图时，作者应考虑是否将长图包含在文档主体中或附录中。
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
+--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
+--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
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.
[schema-mount]中定义了“YANG schema-mount”，值得进行一些具体讨论。模式装载是一种通用机制，允许在另一个（父）模式的指定位置装载一个或多个模块。特定位置称为“装载点”，模式中的任何容器或列表节点都可以用作装载点。通过将“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
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模式装载”）提供。模式装载模块支持公开装载的模式和“父引用”。父引用用于装载模块内的XML路径语言（XPath）评估，不表示客户端可访问的路径；引用的信息可通过父模式供客户端使用。模式挂载还定义了一个“内联”类型的挂载点，其中挂载的模块通过库模块公开。
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 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路由”[YANG路由]和“ietf ospf”[ospf-YANG]，可通过父引用访问YANG模块“ietf接口”[RFC8343]中的节点，并且“配置”指示“真”：
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@
| ...
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路由”模块，尽管它列在模式装载模块（或内联库）中，但树形图中没有特殊的装载相关符号。
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模式装载”模块的“配置”叶确定，并在顶级装载节点上指示。
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路由”模块的“配置”叶指示“false”时，“rt:routing”子树中的节点将具有不同的标志：
+--ro rt:routing/
| +--ro router-id?
| +--ro control-plane-protocols
...
+--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]杨，D.，曲，Y.，张，J.，陈，I.，和A.林登，“OSPF协议的YANG数据模型”，正在进行的工作，草稿-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.Schoenwaeld，“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.，Ed.“YANG 1.1数据建模语言”，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.，“用于接口管理的YANG数据模型”，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.
[SCHEMA-MOUNT]Bjorklund，M.和L.Lhotka，“YANG SCHEMA MOUNT”，正在进行的工作，草稿-ietf-netmod-SCHEMA-MOUNT-082017年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，“网络实例的杨模型”，正在进行的工作，草稿-ietf-rtgwg-ni-Model-112018年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版本）”，正在进行的工作，草案-ietf-netmod-rfc8022bis-11，2018年1月。
Authors' Addresses
作者地址
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-f系统
Email: mbj@tail-f.com
Email: mbj@tail-f.com
Lou Berger (editor) LabN Consulting, L.L.C.
Lou Berger（编辑）LabN咨询公司，L.L.C。
Email: lberger@labn.net
Email: lberger@labn.net