draft-ietf-netmod-yang-tree-diagrams-06.txt   rfc8340.txt 
Network Working Group M. Bjorklund Internet Engineering Task Force (IETF) M. Bjorklund
Internet-Draft Tail-f Systems Request for Comments: 8340 Tail-f Systems
Intended status: Best Current Practice L. Berger, Ed. BCP: 215 L. Berger, Ed.
Expires: August 12, 2018 LabN Consulting, L.L.C. Category: Best Current Practice LabN Consulting, L.L.C.
February 8, 2018 ISSN: 2070-1721 March 2018
YANG Tree Diagrams YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams-06
Abstract Abstract
This document captures the current syntax used in YANG module Tree This document captures the current syntax used in YANG module tree
Diagrams. The purpose of this document is to provide a single diagrams. The purpose of this document is to provide a single
location for this definition. This syntax may be updated from time location for this definition. This syntax may be updated from time
to time based on the evolution of the YANG language. to time based on the evolution of the YANG language.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 12, 2018. 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.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3 2. Tree Diagram Syntax .............................................3
2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Submodules .................................................5
2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Groupings ..................................................5
2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. yang-data ..................................................5
2.4. Collapsed Node Representation . . . . . . . . . . . . . . 6 2.4. Collapsed Node Representation ..............................6
2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Comments ...................................................6
2.6. Node Representation . . . . . . . . . . . . . . . . . . . 7 2.6. Node Representation ........................................6
3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 8 3. Usage Guidelines for RFCs .......................................7
3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 8 3.1. Wrapping Long Lines ........................................8
3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Groupings ..................................................8
3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Long Diagrams ..............................................8
4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 10 4. YANG Schema Mount Tree Diagrams .................................9
4.1. Representation of Mounted Schema Trees . . . . . . . . . 10 4.1. Representation of Mounted Schema Trees ....................10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations ............................................12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................12
7. Informative References . . . . . . . . . . . . . . . . . . . 12 7. Informative References .........................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses ................................................13
1. Introduction 1. Introduction
YANG Tree Diagrams were first published in [RFC6536]. Such diagrams YANG tree diagrams were first published in RFC 6536. Such diagrams
are used to provided a simplified graphical representation of a data are used to provide a simplified graphical representation of a data
model and can be automatically generated via tools such as "pyang". model and can be automatically generated via tools such as "pyang"
(See <https://github.com/mbj4668/pyang>). This document describes [PYANG]. This document describes the syntax used in YANG tree
the syntax used in YANG Tree Diagrams. It is expected that this diagrams. It is expected that this document will be updated or
document will be updated or replaced as changes to the YANG language, replaced as changes to the YANG language [RFC7950] necessitate.
see [RFC7950], necessitate.
Today's common practice is to include the definition of the syntax Today's common practice is to include the definition of the syntax
used to represent a YANG module in every document that provides a used to represent a YANG module in every document that provides a
tree diagram. This practice has several disadvantages and the tree diagram. This practice has several disadvantages; therefore,
purpose of this document is to provide a single location for this 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 definition. It is not the intent of this document to restrict future
changes, but rather to ensure such changes are easily identified and changes, but rather to ensure that such changes are easily identified
suitably agreed upon. and suitably agreed upon.
An example tree diagram can be found in [RFC7223] Section 3. A An example tree diagram can be found in Section 3 of [RFC8343]; the
portion of which follows: following is a portion of it:
+--rw interfaces +--rw interfaces
| +--rw interface* [name] +--rw interface* [name]
| +--rw name string +--rw name string
| +--rw description? string +--rw description? string
| +--rw type identityref +--rw type identityref
| +--rw enabled? boolean +--rw enabled? boolean
| +--rw link-up-down-trap-enable? enumeration +--rw link-up-down-trap-enable? enumeration {if-mib}?
2. Tree Diagram Syntax 2. Tree Diagram Syntax
This section describes the meaning of the symbols used in YANG Tree This section describes the meaning of the symbols used in YANG tree
diagrams. diagrams.
A full tree diagram of a module represents all elements. It includes A full tree diagram of a module represents all elements. It includes
the name of the module and sections for top level module statements the name of the module and sections for top-level module statements
(typically containers), augmentations, rpcs and notifications all (typically containers), augmentations, rpcs, and notifications all
identified under a module statement. Module trees may be included in identified under a module statement. Module trees may be included in
a document as a whole, by one or more sections, or even subsets of a document as a whole, by one or more sections, or even by subsets of
nodes. nodes.
A module is identified by "module:" followed the module-name. This A module is identified by "module:" followed by the module-name.
is followed by one or more sections, in order: This is followed by one or more sections, in order:
1. The top-level data nodes defined in the module, offset by 2 1. The top-level data nodes defined in the module, offset by
spaces. two spaces.
2. Augmentations, offset by 2 spaces and identified by the keyword 2. Augmentations, offset by two spaces and identified by the keyword
"augment" followed by the augment target node and a colon (":") "augment" followed by the augment target node and a colon (":")
character. character.
3. RPCs, offset by 2 spaces and identified by "rpcs:". 3. RPCs, offset by two spaces and identified by "rpcs:".
4. Notifications, offset by 2 spaces and identified by 4. Notifications, offset by two spaces and identified by
"notifications:". "notifications:".
5. Groupings, offset by 2 spaces, and identified by the keyword 5. Groupings, offset by two spaces and identified by the keyword
"grouping" followed by the name of the grouping and a colon (":") "grouping" followed by the name of the grouping and a colon (":")
character. character.
6. yang-data, offset by 2 spaces, and identified by the keyword 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 "yang-data" followed by the name of the yang-data structure and a
colon (":") character. colon (":") character.
The relative organization of each section is provided using a text- The relative organization of each section is provided using a
based format that is typical of a file system directory tree display text-based format that is typical of a file system directory tree
command. Each node in the tree is prefaces with "+--". Schema nodes display command. Each node in the tree is prefaced with "+--".
that are children of another node are offset from the parent by 3 Schema nodes that are children of another node are offset from the
spaces. Sibling schema nodes are listed with the same space offset parent by three spaces. Sibling schema nodes are listed with the
and, when separated by lines, linked via a vertical bar ("|") same space offset and, when separated by lines, are linked via a
character. vertical bar ("|") character.
The full format, including spacing conventions is: The full format, including spacing conventions, is:
module: <module-name> module: <module-name>
+--<node> +--<node>
| +--<node> | +--<node>
| +--<node> | +--<node>
+--<node> +--<node>
+--<node> +--<node>
+--<node> +--<node>
augment <target-node>: augment <target-node>:
skipping to change at page 6, line 7 skipping to change at page 5, line 7
yang-data <yang-data-name>: yang-data <yang-data-name>:
+--<node> +--<node>
+--<node> +--<node>
| +--<node> | +--<node>
+--<node> +--<node>
yang-data <yang-data-name>: yang-data <yang-data-name>:
+--<node> +--<node>
2.1. Submodules 2.1. Submodules
Submodules are represented in the same fashion as modules, but are Submodules are represented in the same fashion as modules but are
identified by "submodule:" followed the (sub)module-name. For identified by "submodule:" followed by the (sub)module-name. For
example: example:
submodule: <module-name> submodule: <module-name>
+--<node> +--<node>
| +--<node> | +--<node>
| +--<node> | +--<node>
2.2. Groupings 2.2. Groupings
Nodes within a used grouping are normally expanded as if the nodes Nodes within a used grouping are normally expanded as if the nodes
were defined at the location of the "uses" statement. However, it is were defined at the location of the "uses" statement. However, it is
also possible to not expand the "uses" statement, but instead print also possible to not expand the "uses" statement but to instead print
the name of the grouping. the name of the grouping.
For example, the following diagram shows the "tls-transport" grouping For example, the following diagram shows the "tls-transport" grouping
from [RFC7407] unexpanded: from [RFC7407] unexpanded:
+--rw tls +--rw tls
+---u tls-transport +---u tls-transport
If the grouping is expanded, it could be printed as: If the grouping is expanded, it could be printed as:
skipping to change at page 6, line 46 skipping to change at page 6, line 7
Groupings may optionally be present in the "groupings" section. Groupings may optionally be present in the "groupings" section.
2.3. yang-data 2.3. yang-data
If the module defines a "yang-data" structure [RFC8040], these If the module defines a "yang-data" structure [RFC8040], these
structures may optionally be present in the "yang-data" section. structures may optionally be present in the "yang-data" section.
2.4. Collapsed Node Representation 2.4. Collapsed Node Representation
At times when the composition of the nodes within a module schema are 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 not important in the context of the presented tree, sibling nodes and
their children can be collapsed using the notation "..." in place of their children can be collapsed using the notation "..." in place of
the text lines used to represent the summarized nodes. For example: the text lines used to represent the summarized nodes. For example:
+--<node> +--<node>
| ... | ...
+--<node> +--<node>
+--<node> +--<node>
+--<node> +--<node>
skipping to change at page 7, line 28 skipping to change at page 6, line 35
Each node in a YANG module is printed as: 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: <status> is one of:
+ for current + for current
x for deprecated x for deprecated
o for obsolete o for obsolete
<flags> is one of: <flags> is one of:
rw for configuration data rw for configuration data nodes and choice nodes
ro for non-configuration data, output parameters to rpcs ro for non-configuration data nodes and choice nodes,
and actions, and notification parameters output parameters to rpcs and actions, and
notification parameters
-w for input parameters to rpcs and actions -w for input parameters to rpcs and actions
-u for uses of a grouping -u for uses of a grouping
-x for rpcs and actions -x for rpcs and actions
-n for notifications -n for notifications
mp for nodes containing a "mount-point" extension statement mp for nodes containing a "mount-point" extension statement
Case nodes do not have any <flags>.
<name> is the name of the node <name> is the name of the node
(<name>) means that the node is a choice node (<name>) means that the node is a choice node
:(<name>) means that the node is a case node :(<name>) means that the node is a case node
If the node is augmented into the tree from another module, If the node is augmented into the tree from another module,
its name is printed as <prefix>:<name>, where <prefix> is the its name is printed as <prefix>:<name>, where <prefix> is the
prefix defined in the module where the node is defined. prefix defined in the module where the node is defined.
If the node is a case node, there is no space before the
<name>.
<opts> is one of: <opts> is one of:
? for an optional leaf, choice, anydata or anyxml ? for an optional leaf, choice, anydata, or anyxml
! for a presence container ! for a presence container
* for a leaf-list or list * for a leaf-list or list
[<keys>] for a list's keys [<keys>] for a list's keys
/ for a top-level data node in a mounted module / for a top-level data node in a mounted module
@ for a top-level data node in a parent referenced module @ for a top-level data node of a module identified in a
mount point parent reference
<type> is the name of the type for leafs and leaf-lists <type> is the name of the type for leafs and leaf-lists
If the type is a leafref, the type is either printed as If the type is a leafref, the type is printed as either
"-> TARGET", where TARGET is the leafref path, with prefixes (1) "-> TARGET", where TARGET is the leafref path,
removed if possible, or printed as "leafref". with prefixes removed if possible or (2) "leafref".
<if-features> is the list of features this node depends on, <if-features> is the list of features this node depends on,
printed within curly brackets and a question mark "{...}?" printed within curly brackets and a question mark "{...}?"
Arbitrary whitespace is allowed between any of the whitespace Arbitrary whitespace is allowed between any of the whitespace-
separated fields (e.g., <opts> and <type>). Additional whitespace separated fields (e.g., <opts> and <type>). Additional whitespace
may for example be used to column align fields (e.g., within a list may, for example, be used to "column align" fields (e.g., within a
or container) to improve readability. list or container) to improve readability.
3. Usage Guidelines For RFCs 3. Usage Guidelines for RFCs
This section provides general guidelines related to the use of tree This section provides general guidelines related to the use of tree
diagrams in RFCs. diagrams in RFCs.
3.1. Wrapping Long Lines 3.1. Wrapping Long Lines
Internet Drafts and RFCs limit the number of characters that may in a Internet-Drafts and RFCs limit the number of characters that may
line of text to 72 characters. When the tree representation of a appear in a line of text to 72 characters. When the tree
node results in line being longer than this limit the line should be representation of a node results in a line being longer than this
broken between <opts> and <type>, or between <type> and <if-feature>. limit, the line should be broken between <opts> and <type> or between
The new line should be indented so that it starts below <name> with a <type> and <if-feature>. The new line should be indented so that it
white space offset of at least two characters. For example: starts below <name> with a whitespace offset of at least two
characters. For example:
notifications: notifications:
+---n yang-library-change +---n yang-library-change
+--ro module-set-id +--ro module-set-id
-> /modules-state/module-set-id -> /modules-state/module-set-id
Long paths (e.g., leafref paths or augment targets) can be split and Long paths (e.g., leafref paths or augment targets) can be split and
printed on more than one line. For example: printed on more than one line. For example:
augment /nat:nat/nat:instances/nat:instance/nat:mapping-table augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
/nat:mapping-entry: /nat:mapping-entry:
The previously mentioned "pyang" command can be helpful in producing The previously mentioned "pyang" command can be helpful in producing
such output, for example the notification diagram above was produced such output; for example, the notification diagram above was produced
using: using:
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 When a tree diagram is included as a figure in an Internet-Draft or
RFC, "--tree-line-length 69" works well. RFC, "--tree-line-length 69" works well.
3.2. Groupings 3.2. Groupings
If the YANG module is comprised of groupings only, then the tree If the YANG module is comprised of groupings only, then the tree
diagram should contain the groupings. The 'pyang' compiler can be diagram should contain the groupings. The "pyang" compiler can be
used to produce a tree diagram with groupings using the "-f tree -- used to produce a tree diagram with groupings using the
tree-print-groupings" command line parameters. "-f tree --tree-print-groupings" command-line parameters.
3.3. Long Diagrams 3.3. Long Diagrams
Tree diagrams can be split into sections to correspond to document Tree diagrams can be split into sections to correspond to document
structure. As tree diagrams are intended to provide a simplified structure. As tree diagrams are intended to provide a simplified
view of a module, diagrams longer than a page should generally be view of a module, diagrams longer than a page should generally be
avoided. If the complete tree diagram for a module becomes too long, avoided. If the complete tree diagram for a module becomes too long,
the diagram can be split into several smaller diagrams. For example, the diagram can be split into several smaller diagrams. For example,
it might be possible to have one diagram with the data node and 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, another with all notifications. If the data nodes tree is too long,
it is also possible to split the diagram into smaller diagrams for it is also possible to split the diagram into smaller diagrams for
different subtrees. When long diagrams are included in a document, different subtrees. When long diagrams are included in a document,
authors should consider whether to include the long diagram in the authors should consider whether to include the long diagram in the
main body of the document or in an appendix. main body of the document or in an appendix.
An example of such a split can be found in [RFC7407], where section An example of such a split can be found in [RFC7407], where
2.4 shows the diagram for "engine configuration": Section 2.4 of that document shows the diagram for "engine
configuration":
+--rw snmp +--rw snmp
+--rw engine +--rw engine
// more parameters from the "engine" subtree here // more parameters from the "engine" subtree here
Further, section 2.5 shows the diagram for "target configuration": Further, Section 2.5 of [RFC7407] shows the diagram for "target
configuration":
+--rw snmp +--rw snmp
+--rw target* [name] +--rw target* [name]
// more parameters from the "target" subtree here // more parameters from the "target" subtree here
The previously mentioned "pyang" command can be helpful in producing The previously mentioned "pyang" command can be helpful in producing
such output, for example the above example was produced using: such output; for example, the above example was produced using:
pyang -f tree --tree-path /snmp/target ietf-snmp.yang pyang -f tree --tree-path /snmp/target ietf-snmp.yang
4. YANG Schema Mount Tree Diagrams 4. YANG Schema Mount Tree Diagrams
YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and "YANG schema mount" is defined in [SCHEMA-MOUNT] and warrants some
warrants some specific discussion. Schema mount is a generic specific discussion. Schema mount is a generic mechanism that allows
mechanism that allows for mounting of one or more YANG modules at a for the mounting of one or more YANG modules at a specified location
specified location of another (parent) schema. The specific location of another (parent) schema. The specific location is referred to as
is referred to as a mount point, and any container or list node in a a "mount point", and any container or list node in a schema may serve
schema may serve as a mount point. Mount points are identified via as a mount point. Mount points are identified via the inclusion of
the inclusion of the "mount-point" extension statement as a the "mount-point" extension statement as a substatement under a
substatement under a container or list node. Mount point nodes are container or list node. Mount point nodes are thus directly
thus directly identified in a module schema definition and can be identified in a module schema definition and can be identified in a
identified in a tree diagram as indicated above using the "mp" flag. tree diagram as indicated above using the "mp" flag.
In the following example taken from [I-D.ietf-rtgwg-ni-model], In the following example taken from [YANG-NIs], "vrf-root" is a
"vrf-root" is a container that includes the "mount-point" extension container that includes the "mount-point" extension statement as part
statement as part of its definition: of its definition:
module: ietf-network-instance module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
+--rw (root-type) +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
| +--mp vrf-root | +--mp vrf-root
4.1. Representation of Mounted Schema Trees 4.1. Representation of Mounted Schema Trees
The actual modules made available under a mount point is controlled The actual modules made available under a mount point are controlled
by a server and is provided to clients. This information is by a server and are provided to clients. This information is
typically provided via the Schema Mount module defined in typically provided via the schema mount module
[I-D.ietf-netmod-schema-mount]. The Schema Mount module supports ("ietf-yang-schema-mount") defined in [SCHEMA-MOUNT]. The schema
exposure of both mounted schema and "parent-references". Parent mount module supports the exposure of both mounted schema and
references are used for XPath evaluation within mounted modules and "parent-references". Parent references are used for XML Path
do not represent client-accessible paths; the referenced information Language (XPath) evaluation within mounted modules and do not
is available to clients via the parent schema. Schema mount also represent client-accessible paths; the referenced information is
defines an "inline" type mount point where mounted modules are 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. exposed via the YANG library module.
While the modules made available under a mount point are not Although the modules made available under a mount point are not
specified in YANG modules that include mount points, the document specified in YANG modules that include mount points, the document
defining the module will describe the intended use of the module and defining the module will describe the intended use of the module and
may identify both modules that will be mounted and parent modules may identify both modules that will be mounted and parent modules
that can be referenced by mounted modules. An example of such a that can be referenced by mounted modules. An example of such a
description can be found in [I-D.ietf-rtgwg-ni-model]. A specific description can be found in [YANG-NIs]. A specific implementation of
implementation of a module containing mount points will also support a module containing mount points will also support a specific list of
a specific list of mounted and referenced modules. In describing mounted and referenced modules. In describing both intended use and
both intended use and actual implementations, it is helpful to show actual implementations, it is helpful to show how mounted modules
how mounted modules would be instantiated and referenced under a would be instantiated and referenced under a mount point using tree
mount point using tree diagrams. diagrams.
In such diagrams, the mount point should be treated much like a In such diagrams, the mount point should be treated much like a
container that uses a grouping. The flags should also be set based container that uses a grouping. The flags should also be set based
on the "config" leaf mentioned above, and the mount related options on the "config" leaf mentioned above, and the mount-related options
indicated above should be shown for the top level nodes in a mounted indicated above should be shown for the top-level nodes in a mounted
or referenced module. The following example, taken from or referenced module. The following example, taken from [YANG-NIs],
[I-D.ietf-rtgwg-ni-model], represents the prior example with YANG represents the prior example with the YANG modules "ietf-routing"
Routing and OSPF modules mounted, YANG Interface module nodes [YANG-Routing] and "ietf-ospf" [OSPF-YANG] mounted, nodes from the
accessible via a parent-reference, and "config" indicating true: YANG module "ietf-interfaces" [RFC8343] accessible via a
parent-reference, and "config" indicating "true":
module: ietf-network-instance module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
+--rw (root-type) +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
skipping to change at page 11, line 49 skipping to change at page 11, line 38
| +--rw control-plane-protocols | +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name] | +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf | +--rw ospf:ospf
| +--rw instance* [af] | +--rw instance* [af]
| ... | ...
+--ro if:interfaces@ +--ro if:interfaces@
| ... | ...
+--ro if:interfaces-state@ +--ro if:interfaces-state@
| ... | ...
It is worth highlighting that the OSPF module augments the Routing It is worth highlighting that the "ietf-ospf" module augments the
module, and while it is listed in the Schema Mount module (or inline "ietf-routing" module, and although it is listed in the schema mount
YANG library) there is no special mount-related notation in the tree module (or inline YANG library), there is no special mount-related
diagram. notation in the tree diagram.
A mount point definition alone is not sufficient to identify if the A mount point definition alone is not sufficient to identify whether
mounted modules are used for configuration or for non-configuration the mounted modules are used for configuration data or for
data. This is determined by the "ietf-yang-schema-mount" module's non-configuration data. This is determined by the
"config" leaf associated with the specific mount point and is "ietf-yang-schema-mount" module's "config" leaf associated with the
indicated on the top level mounted nodes. For example in the above specific mount point and is indicated on the top-level mounted nodes.
tree, when the "config" for the routing module indicates false, the
nodes in the "rt:routing" subtree would have different flags: 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:
+--ro rt:routing/ +--ro rt:routing/
| +--ro router-id? | +--ro router-id?
| +--ro control-plane-protocols | +--ro control-plane-protocols
... ...
5. IANA Considerations 5. IANA Considerations
There are no IANA requests or assignments included in this document. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
There is no security impact related to the tree diagrams defined in There is no security impact related to the tree diagrams defined in
this document. this document.
7. Informative References 7. Informative References
[I-D.ietf-netmod-schema-mount] [OSPF-YANG]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem,
ietf-netmod-schema-mount-08 (work in progress), October "Yang Data Model for OSPF Protocol", Work in Progress,
2017. draft-ietf-ospf-yang-10, March 2018.
[I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
model-05 (work in progress), December 2017.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [PYANG] "pyang", February 2018,
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://github.com/mbj4668/pyang>.
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/info/rfc7407>. December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <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.
[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 Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Lou Berger (editor) Lou Berger (editor)
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
 End of changes. 56 change blocks. 
174 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/