draft-ietf-netmod-yang-tree-diagrams-02.txt   draft-ietf-netmod-yang-tree-diagrams-03.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track L. Berger, Ed. Intended status: Best Current Practice L. Berger, Ed.
Expires: April 28, 2018 LabN Consulting, L.L.C. Expires: June 22, 2018 LabN Consulting, L.L.C.
October 25, 2017 December 19, 2017
YANG Tree Diagrams YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams-02 draft-ietf-netmod-yang-tree-diagrams-03
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 the document is to provide a single Diagrams. The purpose of the 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2018. This Internet-Draft will expire on June 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Collapsed Node Representation . . . . . . . . . . . . . . 5 2.4. Collapsed Node Representation . . . . . . . . . . . . . . 6
2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Node Representation . . . . . . . . . . . . . . . . . . . 5 2.6. Node Representation . . . . . . . . . . . . . . . . . . . 6
3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 6 3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 7
3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 7 3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 7
3.2. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 8
4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 8 3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Representation of Instance Data Trees . . . . . . . . . . 8 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.1. Representation of Mounted Schema Trees . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
YANG Tree Diagrams were first published in [RFC7223]. Such diagrams YANG Tree Diagrams were first published in [RFC6536]. Such diagrams
are commonly used to provided a simplified graphical representation are commonly used to provided a simplified graphical representation
of a data model and can be automatically generated via tools such as of a data model and can be automatically generated via tools such as
"pyang". (See <https://github.com/mbj4668/pyang>). This document "pyang". (See <https://github.com/mbj4668/pyang>). This document
provides the syntax used in YANG Tree Diagrams. It is expected that provides the syntax used in YANG Tree Diagrams. It is expected that
this document will be updated or replaced as changes to the YANG this document will be updated or replaced as changes to the YANG
language, see [RFC7950], necessitate. language, see [RFC7950], necessitate.
Today's common practice is include the definition of the syntax used Today's common practice is include the definition of the syntax used
to represent a YANG module in every document that provides a tree to represent a YANG module in every document that provides a tree
diagram. This practice has several disadvantages and the purpose of diagram. This practice has several disadvantages and the purpose of
skipping to change at page 3, line 44 skipping to change at page 3, line 52
character. character.
6. yang-data, offset by 2 spaces, and identified by the keyword 6. yang-data, offset by 2 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 text-
based format that is typical of a file system directory tree display based format that is typical of a file system directory tree display
command. Each node in the tree is prefaces with "+--". Schema nodes command. Each node in the tree is prefaces with "+--". Schema nodes
that are children of another node are offset from the parent by 3 that are children of another node are offset from the parent by 3
spaces. Schema peer nodes separated are listed with the same space spaces. Sibling schema nodes are listed with the same space offset
offset and, when separated by lines, linked via a vertical bar ("|") and, when separated by lines, linked via a vertical bar ("|")
character. 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>:
+--<node> +--<node>
+--<node> +--<node>
skipping to change at page 5, line 12 skipping to change at page 6, line 4
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 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 expanded as if the nodes were Nodes within a used grouping are normally expanded as if the nodes
defined at the location of the uses statement. were defined at the location of the "uses" statement. However, it is
also possible to not expand the "uses" statement, but instead print
the name of the grouping.
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 are
not important in the context of the presented tree, peer 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>
2.5. Comments 2.5. Comments
skipping to change at page 6, line 10 skipping to change at page 7, line 4
2.6. Node Representation 2.6. Node Representation
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
ro for non-configuration data ro for non-configuration data
-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 statment mp for nodes containing a "mount-point" extension statment
<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>. its name is printed as <prefix>:<name>.
skipping to change at page 6, line 39 skipping to change at page 7, line 33
? 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 in a parent referenced module
<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 printed as "-> TARGET", If the type is a leafref, the type is printed as "-> TARGET",
where TARGET is either the leafref path, with prefixed removed where TARGET is either the leafref path, with prefixes removed
if possible. if possible.
<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 "{...}?"
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.
skipping to change at page 7, line 27 skipping to change at page 8, line 18
-> /modules-state/module-set-id -> /modules-state/module-set-id
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-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. Long Diagrams 3.2. Groupings
As tree diagrams are intended to provide a simplified view of a If the YANG module is comprised of groupings only, then the tree
module, diagrams longer than a page should generally be avoided. If diagram should contain the groupings. The 'pyang' compiler can be
the complete tree diagram for a module becomes too long, the diagram used to produce a tree diagram with groupings using the "-f tree --
can be split into several smaller diagrams. For example, it might be tree-print-groupings" command line parameters.
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 3.3. Long Diagrams
possible to split the diagram into smaller diagrams for different
subtrees. When long diagrams are included in a document, authors Tree diagrams can be split into sections to correspond to document
should consider whether to include the long diagram in the main body structure. As tree diagrams are intended to provide a simplified
of the document or in an appendix. 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 An example of such a split can be found in [RFC7407], where section
2.4 shows the diagram for "engine configuration": 2.4 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 shows the diagram for "target configuration":
skipping to change at page 8, line 14 skipping to change at page 9, line 14
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 [I-D.ietf-netmod-schema-mount] and
warrants some specific discussion. Schema mount is a generic warrants some specific discussion. Schema mount is a generic
mechanism that allows for mounting of one or more data modules at a mechanism that allows for mounting of one or more YANG modules at a
specified location of another (parent) schema. The specific location specified location of another (parent) schema. The specific location
is referred to as a mount point, and any container or list node in a 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 schema may serve as a mount point. Mount points are identified via
the inclusion of the "mount-point" extension statement as a the inclusion of the "mount-point" extension statement as a
substament under a container or list node. Mount point nodes are substament under a container or list node. Mount point nodes are
thus directly identified in a module schema definition and can be thus directly identified in a module schema definition and can be
identified in a tree diagram as indicated above using the "mp" flag. identified in a 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 [I-D.ietf-rtgwg-ni-model],
"vrf-root" is a container that includes the "mount-point" extension "vrf-root" is a container that includes the "mount-point" extension
skipping to change at page 8, line 38 skipping to change at page 9, line 38
+--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 Instance Data 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 is controlled
by a server and is provided to clients. This information is by a server and is provided to clients. This information is
typically provided via the Schema Mount module defined in typically provided via the Schema Mount module defined in
[I-D.ietf-netmod-schema-mount]. The Schema Mount module supports [I-D.ietf-netmod-schema-mount]. The Schema Mount module supports
exposure of both mounted schema and "parent-references". Parent exposure of both mounted schema and "parent-references". Parent
references are used for XPath evaluation within mounted modules and references are used for XPath evaluation within mounted modules and
do not represent client-accessible paths; the referenced information do not represent client-accessible paths; the referenced information
is available to clients via the parent schema. Schema mount also is available to clients via the parent schema. Schema mount also
defines an "inline" type mount point where mounted modules are defines an "inline" type mount point where mounted modules are
skipping to change at page 9, line 16 skipping to change at page 10, line 16
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 [I-D.ietf-rtgwg-ni-model]. A specific
implementation of a module containing mount points will also support implementation of a module containing mount points will also support
a specific list of mounted and referenced modules. In describing a specific list of mounted and referenced modules. In describing
both intended use and actual implementations, it is helpful to show both intended use and actual implementations, it is helpful to show
how mounted modules would be instantiated and referenced under a how mounted modules would be instantiated and referenced under a
mount point using tree diagrams. mount point using tree 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 realted 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
[I-D.ietf-rtgwg-ni-model], represents the prior example with YANG [I-D.ietf-rtgwg-ni-model], represents the prior example with YANG
Routing and OSPF modules mounted, YANG Interface module nodes Routing and OSPF modules mounted, YANG Interface module nodes
accessible via a parent-reference, and "config" indicating true: 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
skipping to change at page 10, line 16 skipping to change at page 11, line 16
module, and while it is listed in the Schema Mount module (or inline module, and while it is listed in the Schema Mount module (or inline
YANG library) there is no special mount-related notation in the tree YANG library) there is no special mount-related notation in the tree
diagram. diagram.
A mount point definition alone is not sufficient to identify if the A mount point definition alone is not sufficient to identify if the
mounted modules are used for configuration or for non-configuration mounted modules are used for configuration or for non-configuration
data. This is determined by the "ietf-yang-schema-mount" module's data. This is determined by the "ietf-yang-schema-mount" module's
"config" leaf associated with the specific mount point and is "config" leaf associated with the specific mount point and is
indicated on the top level mounted nodes. For example in the above indicated on the top level mounted nodes. For example in the above
tree, when the "config" for the routing module indicates false, the tree, when the "config" for the routing module indicates false, the
only change would be to the flag on the rt:routing node: nodes in the "rt:routing" subtree would have different flags:
+--ro rt:routing/ +--ro rt:routing/
| +--ro router-id?
| +--ro control-plane-protocols
...
5. IANA Considerations 5. IANA Considerations
There are no IANA requests or assignments included in this document. There are no IANA requests or assignments included in this document.
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] [I-D.ietf-netmod-schema-mount]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
ietf-netmod-schema-mount-08 (work in progress), October ietf-netmod-schema-mount-08 (work in progress), October
2017. 2017.
[I-D.ietf-rtgwg-ni-model] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
model-04 (work in progress), September 2017. 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 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>. <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",
 End of changes. 22 change blocks. 
44 lines changed or deleted 63 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/