idnits 2.17.1 draft-ietf-netmod-yang-tree-diagrams-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 194 has weird spacing: '... rw for c...' == Line 195 has weird spacing: '... ro for n...' == Line 198 has weird spacing: '... mp for ...' -- The document date (June 29, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-05 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Intended status: Standards Track L. Berger, Ed. 5 Expires: December 31, 2017 LabN Consulting, L.L.C. 6 June 29, 2017 8 YANG Tree Diagrams 9 draft-ietf-netmod-yang-tree-diagrams-01 11 Abstract 13 This document captures the current syntax used in YANG module Tree 14 Diagrams. The purpose of the document is to provide a single 15 location for this definition. This syntax may be updated from time 16 to time based on the evolution of the YANG language. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 31, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Collapsed Node Representation . . . . . . . . . . . . . . 4 57 2.4. Node Representation . . . . . . . . . . . . . . . . . . . 4 58 2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 5 60 3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 6 61 4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 YANG Tree Diagrams were first published in [RFC7223]. Such diagrams 69 are commonly used to provided a simplified graphical representation 70 of a data model and can be automatically generated via tools such as 71 "pyang". (See ). This document 72 provides the syntax used in YANG Tree Diagrams. It is expected that 73 this document will be updated or replaced as changes to the YANG 74 language, see [RFC7950], necessitate. 76 Today's common practice is include the definition of the syntax used 77 to represent a YANG module in every document that provides a tree 78 diagram. This practice has several disadvantages and the purpose of 79 the document is to provide a single location for this definition. It 80 is not the intent of this document to restrict future changes, but 81 rather to ensure such changes are easily identified and suitably 82 agreed upon. 84 An example tree diagram can be found in [RFC7223] Section 3. A 85 portion of which follows: 87 +--rw interfaces 88 | +--rw interface* [name] 89 | +--rw name string 90 | +--rw description? string 91 | +--rw type identityref 92 | +--rw enabled? boolean 93 | +--rw link-up-down-trap-enable? enumeration 95 The remainder of this document contains YANG Tree Diagram syntax 96 based on output from pyang version 1.7.1. 98 2. Tree Diagram Syntax 100 This section provides the meaning of the symbols used in YANG Tree 101 diagrams. 103 A full tree diagram of a module represents all elements. It includes 104 the name of the module and sections for top level module statements 105 (typically containers), augmentations, rpcs and notifications all 106 identified under a module statement. Module trees may be included in 107 a document as a whole, by one or more sections, or even subsets of 108 nodes. 110 A module is identified by "module:" followed the module-name. Top 111 level module statements are listed immediately following, offset by 4 112 spaces. Augmentations are listed next, offset by 2 spaces and 113 identified by the keyword "augment" followed by the augment target 114 node and a colon (':') character. This is followed by, RPCs which 115 are identified by "rpcs:" and are also offset by 2 spaces. 116 Notifications are last and are identified by "notifications:" and are 117 also offset by 2 spaces. 119 The relative organization of each section is provided using a text- 120 based format that is typical of a file system directory tree display 121 command. Each node in the tree is prefaces with '+--'. Schema nodes 122 that are children of another node are offset from the parent by 3 123 spaces. Schema peer nodes separated are listed with the same space 124 offset and, when separated by lines, linked via a pipe ('|') 125 character. 127 The full format, including spacing conventions is: 129 module: 131 +-- 132 | +-- 133 | +-- 134 +-- 135 +-- 136 +-- 137 augment : 138 +-- 139 +-- 140 +-- 141 +-- 143 rpcs: 144 +-- 145 +-- 147 notifications: 148 +-- 149 +-- 150 | +-- 151 +-- 153 2.1. Submodules 155 Submodules are represented in the same fashion as modules, but are 156 identified by "submodule:" followed the (sub)module-name. For 157 example: 159 submodule: 161 +-- 162 | +-- 163 | +-- 165 2.2. Groupings 167 Nodes within a used grouping are expanded as if the nodes were 168 defined at the location of the uses statement. 170 2.3. Collapsed Node Representation 172 At times when the composition of the nodes within a module schema are 173 not important in the context of the presented tree, peer nodes and 174 their children can be collapsed using the notation '...' in place of 175 the text lines used to represent the summarized nodes. For example: 177 +-- 178 | ... 179 +-- 180 +-- 181 +-- 183 2.4. Node Representation 185 Each node in a YANG module is printed as: 187 188 is one of: 189 + for current 190 x for deprecated 191 o for obsolete 193 is one of: 194 rw for configuration data 195 ro for non-configuration data 196 -x for rpcs and actions 197 -n for notifications 198 mp for schema mount points 200 is the name of the node 201 () means that the node is a choice node 202 :() means that the node is a case node 204 If the node is augmented into the tree from another module, its 206 name is printed as :. 208 is one of: 209 ? for an optional leaf, choice, anydata or anyxml 210 ! for a presence container 211 * for a leaf-list or list 212 [] for a list's keys 213 / for a mounted module 214 @ for a node made available via a schema mount 215 parent reference 217 is the name of the type for leafs and leaf-lists 219 If the type is a leafref, the type is printed as "-> TARGET", 220 where TARGET is either the leafref path, with prefixed removed 221 if possible. 223 is the list of features this node depends on, 224 printed within curly brackets and a question mark "{...}?" 226 2.5. Extensions 228 TBD 230 3. Usage Guidelines For RFCs 232 This section provides general guidelines related to the use of tree 233 diagrams in RFCs. This section covers [Authors' note: will cover] 234 different types of trees and when to use them; for example, complete 235 module trees, subtrees, trees for groupings etc. 237 3.1. Wrapping Long Lines 239 Internet Drafts and RFCs limit the number of characters that may in a 240 line of text to 72 characters. When the tree representation of a 241 node results in line being longer than this limit the line should be 242 broken between and . The type should be indented so 243 that the new line starts below with a white space offset of at 244 least two characters. For example: 246 notifications: 247 +---n yang-library-change 248 +--ro module-set-id 249 -> /modules-state/module-set-id 251 The previously 'pyang' command can be helpful in producing such 252 output, for example the above example was produced using: 254 pyang -f tree --tree-line-length 50 < ietf-yang-library.yang 256 4. YANG Schema Mount Tree Diagrams 258 YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and 259 warrants some specific discussion. Schema mount document is a 260 generic mechanism that allows for mounting one data model consisting 261 of any number of YANG modules at a specified location of another 262 (parent) schema. Modules containing mount points will identify mount 263 points by name using the mount-point extension. These mount-points 264 should be identified, as indicated above using the 'mp' flag. For 265 example: 267 module: ietf-network-instance 268 +--rw network-instances 269 +--rw network-instance* [name] 270 +--rw name string 271 +--rw enabled? boolean 272 +--rw description? string 273 +--rw (ni-type)? 274 +--rw (root-type)? 275 +--:(vrf-root) 276 | +--mp vrf-root? 278 Note that a mount point definition alone is not sufficient to 279 identify if a mount point configuration or for non-configuration 280 data. This is determined by the yang-schema-mount module 'config' 281 leaf associated with the specific mount point. 283 In describing the intended use of a module containing a mount point, 284 it is helpful to show how the mount point would look with mounted 285 modules. In such cases, the mount point should be treated much like 286 a container that uses a grouping. The flags should also be set based 287 on the 'config' leaf mentioned above, and the mount realted options 288 indicated above should be shown. For example, the following 289 represents the prior example with YANG Routing and OSPF modules 290 mounted, YANG Interface module nodes accessible via a parent- 291 reference, and 'config' indicating true: 293 module: ietf-network-instance 294 +--rw network-instances 295 +--rw network-instance* [name] 296 +--rw name string 297 +--rw enabled? boolean 298 +--rw description? string 299 +--rw (ni-type)? 300 +--rw (root-type)? 301 +--:(vrf-root) 302 +--mp vrf-root? 303 +--ro rt:routing-state/ 304 | ... 305 +--rw rt:routing/ 306 | ... 307 +--ro if:interfaces@ 308 | ... 309 +--ro if:interfaces-state@ 310 ... 312 The with 'config' indicating false, the only change would be to the 313 flag on the rt:routing node: 315 +--ro rt:routing/ 317 5. IANA Considerations 319 There are no IANA requests or assignments included in this document. 321 6. Informative References 323 [I-D.ietf-netmod-schema-mount] 324 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 325 ietf-netmod-schema-mount-05 (work in progress), May 2017. 327 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 328 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 329 . 331 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 332 RFC 7950, DOI 10.17487/RFC7950, August 2016, 333 . 335 Authors' Addresses 337 Martin Bjorklund 338 Tail-f Systems 340 Email: mbj@tail-f.com 342 Lou Berger (editor) 343 LabN Consulting, L.L.C. 345 Email: lberger@labn.net