--- 1/draft-ietf-netmod-yang-tree-diagrams-01.txt 2017-10-25 06:13:14.732200755 -0700 +++ 2/draft-ietf-netmod-yang-tree-diagrams-02.txt 2017-10-25 06:13:14.756201327 -0700 @@ -1,19 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track L. Berger, Ed. -Expires: December 31, 2017 LabN Consulting, L.L.C. - June 29, 2017 +Expires: April 28, 2018 LabN Consulting, L.L.C. + October 25, 2017 YANG Tree Diagrams - draft-ietf-netmod-yang-tree-diagrams-01 + draft-ietf-netmod-yang-tree-diagrams-02 Abstract This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the 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 @@ -23,52 +23,56 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 31, 2017. + This Internet-Draft will expire on April 28, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.3. Collapsed Node Representation . . . . . . . . . . . . . . 4 - 2.4. Node Representation . . . . . . . . . . . . . . . . . . . 4 - 2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 5 - 3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 6 - 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 6. Informative References . . . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.4. Collapsed Node Representation . . . . . . . . . . . . . . 5 + 2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.6. Node Representation . . . . . . . . . . . . . . . . . . . 5 + 3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 6 + 3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 7 + 3.2. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 7 + 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 8 + 4.1. Representation of Instance Data Trees . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. Informative References . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction YANG Tree Diagrams were first published in [RFC7223]. Such diagrams are commonly used to provided a simplified graphical representation of a data model and can be automatically generated via tools such as "pyang". (See ). This document provides the syntax used in YANG Tree Diagrams. It is expected that this document will be updated or replaced as changes to the YANG language, see [RFC7950], necessitate. @@ -85,259 +89,397 @@ portion of which follows: +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration - The remainder of this document contains YANG Tree Diagram syntax - based on output from pyang version 1.7.1. - 2. Tree Diagram Syntax This section provides 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 subsets of nodes. - A module is identified by "module:" followed the module-name. Top - level module statements are listed immediately following, offset by 4 - spaces. Augmentations are listed next, offset by 2 spaces and - identified by the keyword "augment" followed by the augment target - node and a colon (':') character. This is followed by, RPCs which - are identified by "rpcs:" and are also offset by 2 spaces. - Notifications are last and are identified by "notifications:" and are - also offset by 2 spaces. + A module is identified by "module:" followed 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 4 + spaces. + + 2. Augmentations, offset by 2 spaces and identified by the keyword + "augment" followed by the augment target node and a colon (":") + character. + + 3. RPCs, offset by 2 spaces and identified by "rpcs:". + + 4. Notifications, offset by 2 spaces and identified by + "notifications:". + + 5. Groupings, offset by 2 spaces, and identified by the keyword + "grouping" followed by the name of the grouping and a colon (":") + character. + + 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 + colon (":") 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 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 spaces. Schema peer nodes separated are listed with the same space - offset and, when separated by lines, linked via a pipe ('|') + offset and, when separated by lines, linked via a vertical bar ("|") character. The full format, including spacing conventions is: module: - +-- | +-- | +-- +-- +-- +-- + augment : +-- +-- +-- +-- + augment : + +-- rpcs: + +-- + +-- +-- + | +-- +-- notifications: + +-- + +-- + +-- + | +-- + +-- + + grouping : +-- +-- | +-- +-- + grouping : + +-- + + yang-data : + +-- + +-- + | +-- + +-- + yang-data : + +-- 2.1. Submodules Submodules are represented in the same fashion as modules, but are identified by "submodule:" followed the (sub)module-name. For example: submodule: +-- | +-- | +-- 2.2. Groupings Nodes within a used grouping are expanded as if the nodes were defined at the location of the uses statement. -2.3. Collapsed Node Representation + Groupings may optionally be present in the "groupings" section. + +2.3. yang-data + + If the module defines a "yang-data" structure [RFC8040], these + structures may optionally be present in the "yang-data" section. + +2.4. Collapsed Node Representation 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 - 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: +-- | ... +-- +-- +-- -2.4. Node Representation +2.5. Comments + + Single line comments, starting with "//" and ending at the end of the + line, may be used in the tree notation. + +2.6. Node Representation Each node in a YANG module is printed as: + is one of: + + for current + x for deprecated o for obsolete is one of: rw for configuration data ro for non-configuration data -x for rpcs and actions -n for notifications - mp for schema mount points + mp for nodes containing a "mount-point" extension statment is the name of the node () means that the node is a choice node :() means that the node is a case node - If the node is augmented into the tree from another module, its - - name is printed as :. + If the node is augmented into the tree from another module, + its name is printed as :. is one of: ? for an optional leaf, choice, anydata or anyxml ! for a presence container * for a leaf-list or list [] for a list's keys - / for a mounted module - @ for a node made available via a schema mount - parent reference + / for a top-level data node in a mounted module + @ for a top-level data node in a parent referenced module is the name of the type for leafs and leaf-lists If the type is a leafref, the type is printed as "-> TARGET", where TARGET is either the leafref path, with prefixed removed if possible. is the list of features this node depends on, printed within curly brackets and a question mark "{...}?" -2.5. Extensions - - TBD - 3. Usage Guidelines For RFCs This section provides general guidelines related to the use of tree - diagrams in RFCs. This section covers [Authors' note: will cover] - different types of trees and when to use them; for example, complete - module trees, subtrees, trees for groupings etc. + diagrams in RFCs. 3.1. Wrapping Long Lines Internet Drafts and RFCs limit the number of characters that may in a line of text to 72 characters. When the tree representation of a node results in line being longer than this limit the line should be broken between and . The type should be indented so that the new line starts below with a white space offset of at least two characters. For example: notifications: +---n yang-library-change +--ro module-set-id -> /modules-state/module-set-id - The previously 'pyang' command can be helpful in producing such - output, for example the above example was produced using: + The previously mentioned "pyang" command can be helpful in producing + 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 + RFC, "--tree-line-length 69" works well. + +3.2. Long Diagrams + + 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 shows the diagram for "engine configuration": + + +--rw snmp + +--rw engine + // more parameters from the "engine" subtree here + + Further, section 2.5 shows the diagram for "target configuration": + + +--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 -f tree --tree-path /snmp/target ietf-snmp.yang 4. YANG Schema Mount Tree Diagrams YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and - warrants some specific discussion. Schema mount document is a - generic mechanism that allows for mounting one data model consisting - of any number of YANG modules at a specified location of another - (parent) schema. Modules containing mount points will identify mount - points by name using the mount-point extension. These mount-points - should be identified, as indicated above using the 'mp' flag. For - example: + warrants some specific discussion. Schema mount is a generic + mechanism that allows for mounting of one or more data 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 + substament 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. + + In the following example taken from [I-D.ietf-rtgwg-ni-model], + "vrf-root" is a container that includes the "mount-point" extension + statement as part of its definition: 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)? + +--rw (root-type) +--:(vrf-root) - | +--mp vrf-root? + | +--mp vrf-root - Note that a mount point definition alone is not sufficient to - identify if a mount point configuration or for non-configuration - data. This is determined by the yang-schema-mount module 'config' - leaf associated with the specific mount point. +4.1. Representation of Instance Data Trees - In describing the intended use of a module containing a mount point, - it is helpful to show how the mount point would look with mounted - modules. In such cases, 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 realted options - indicated above should be shown. For example, the following - represents the prior example with YANG Routing and OSPF modules - mounted, YANG Interface module nodes accessible via a parent- - reference, and 'config' indicating true: + The actual modules made available under a mount point is controlled + by a server and is provided to clients. This information is + typically provided via the Schema Mount module defined in + [I-D.ietf-netmod-schema-mount]. The Schema Mount module supports + exposure of both mounted schema and "parent-references". Parent + references are used for 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 mount point where mounted modules are + exposed via the YANG library module. + + While 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 [I-D.ietf-rtgwg-ni-model]. 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. + + 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 realted options + indicated above should be shown for the top level nodes in a mounted + or referenced module. The following example, taken from + [I-D.ietf-rtgwg-ni-model], represents the prior example with YANG + Routing and OSPF modules mounted, YANG Interface module nodes + accessible via a parent-reference, and "config" indicating true: module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw name string +--rw enabled? boolean +--rw description? string +--rw (ni-type)? - +--rw (root-type)? + +--rw (root-type) +--:(vrf-root) - +--mp 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@ - ... + | ... - The with 'config' indicating false, the only change would be to the - flag on the rt:routing node: + It is worth highlighting that the OSPF module augments the Routing + 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 + diagram. + + A mount point definition alone is not sufficient to identify if the + mounted modules are used for configuration 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. For example in the above + tree, when the "config" for the routing module indicates false, the + only change would be to the flag on the rt:routing node: +--ro rt:routing/ 5. IANA Considerations There are no IANA requests or assignments included in this document. -6. Informative References +6. Security Considerations + + There is no security impact related to the tree diagrams defined in + this document. + +7. Informative References [I-D.ietf-netmod-schema-mount] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- - ietf-netmod-schema-mount-05 (work in progress), May 2017. + ietf-netmod-schema-mount-08 (work in progress), October + 2017. + + [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-04 (work in progress), September 2017. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, - . + . + + [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for + SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, + December 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, - . + . + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . Authors' Addresses Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Lou Berger (editor) LabN Consulting, L.L.C.