--- 1/draft-ietf-netmod-yang-tree-diagrams-04.txt 2018-01-23 09:15:49.896123955 -0800 +++ 2/draft-ietf-netmod-yang-tree-diagrams-05.txt 2018-01-23 09:15:49.924124621 -0800 @@ -1,19 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Best Current Practice L. Berger, Ed. -Expires: June 24, 2018 LabN Consulting, L.L.C. - December 21, 2017 +Expires: July 27, 2018 LabN Consulting, L.L.C. + January 23, 2018 YANG Tree Diagrams - draft-ietf-netmod-yang-tree-diagrams-04 + draft-ietf-netmod-yang-tree-diagrams-05 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,103 +23,103 @@ 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 June 24, 2018. + This Internet-Draft will expire on July 27, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 7 - 3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 8 - 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 9 - 4.1. Representation of Mounted Schema Trees . . . . . . . . . 9 + 2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.6. Node Representation . . . . . . . . . . . . . . . . . . . 7 + 3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 8 + 3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 8 + 3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 9 + 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 10 + 4.1. Representation of Mounted Schema Trees . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Informative References . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction YANG Tree Diagrams were first published in [RFC6536]. 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. + are used to provided a simplified graphical representation of a data + model and can be automatically generated via tools such as "pyang". + (See ). 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, + see [RFC7950], necessitate. - Today's common practice is 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 and the purpose of - the 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 such changes are easily identified and suitably - agreed upon. + 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 and the + purpose of the 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 such changes are easily identified and + suitably agreed upon. An example tree diagram can be found in [RFC7223] Section 3. A 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 2. Tree Diagram Syntax - This section provides the meaning of the symbols used in YANG Tree + 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 subsets of nodes. 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 + 1. The top-level data nodes defined in the module, offset by 2 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:". @@ -200,20 +199,34 @@ | +-- | +-- 2.2. Groupings 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 instead print the name of the grouping. + For example, the following diagram shows the "tls-transport" grouping + from [RFC7407] unexpanded: + + +--rw tls + +---u tls-transport + + If the grouping is expanded, it could be printed as: + + +--rw tls + +--rw port? inet:port-number + +--rw client-fingerprint? x509c2n:tls-fingerprint + +--rw server-fingerprint? x509c2n:tls-fingerprint + +--rw server-identity? snmp:admin-string + Groupings may optionally be present in the "groupings" section. 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 @@ -222,80 +235,87 @@ the text lines used to represent the summarized nodes. For example: +-- | ... +-- +-- +-- 2.5. Comments - Single line comments, starting with "//" and ending at the end of the - line, may be used in the tree notation. + Single line comments, starting with "//" (possibly indented) 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 + ro for non-configuration data, 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 statment + mp for nodes containing a "mount-point" extension statement 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 :. + its name is printed as :, where is the + prefix defined in the module where the node is defined. 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 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 either printed as "-> TARGET", where TARGET is the leafref path, with prefixes removed if possible, or printed as "leafref". 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., and ). Additional whitespace + may for example be used to column align fields (e.g., within a list + or container) to improve readability. + 3. Usage Guidelines For RFCs This section provides general guidelines related to the use of tree 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: + broken between and , or between and . + The new line should be indented so that it 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 Long paths (e.g., leafref paths or augment targets) can be split and printed on more than one line. For example: augment /nat:nat/nat:instances/nat:instance/nat:mapping-table @@ -351,21 +371,21 @@ 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 is a generic mechanism that allows for 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 - substament under a container or list node. Mount point nodes are + 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. 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] @@ -473,22 +493,22 @@ Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 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-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, . [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, .