idnits 2.17.1 draft-ietf-netmod-module-tags-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2019) is 1665 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) ** Downref: Normative reference to an Informational RFC: RFC 8199 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Hopps 3 Internet-Draft LabN Consulting, L.L.C. 4 Updates: 8407 (if approved) L. Berger 5 Intended status: Standards Track LabN Consulting, LLC. 6 Expires: March 28, 2020 D. Bogdanovic 7 Volta Networks 8 September 25, 2019 10 YANG Module Tags 11 draft-ietf-netmod-module-tags-09 13 Abstract 15 This document provides for the association of tags with YANG modules. 16 The expectation is for such tags to be used to help classify and 17 organize modules. A method for defining, reading and writing a 18 modules tags is provided. Tags may be registered and assigned during 19 module definition; assigned by implementations; or dynamically 20 defined and set by users. This document also provides guidance to 21 future model writers; as such, this document updates RFC8407. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 28, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Some possible use cases for YANG module tags . . . . . . 3 59 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 60 2. Tag Values . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. IETF Tags . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. User Tags . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Tag Management . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Module Definition Tagging . . . . . . . . . . . . . . . . 5 67 3.2. Implementation Tagging . . . . . . . . . . . . . . . . . 5 68 3.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Tags Module Structure . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 6 71 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Other Classifications . . . . . . . . . . . . . . . . . . . . 9 73 6. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 9 74 6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9 77 7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10 78 7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12 79 7.4. Updates to the YANG Module Names Registry . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 9.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 85 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 86 Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 The use of tags for classification and organization is fairly 92 ubiquitous not only within IETF protocols, but in the internet itself 93 (e.g., "#hashtags"). One benefit of using tags for organization over 94 a rigid structure is that it is more flexible and can more easily 95 adapt over time as technologies evolve. Tags can be usefully 96 registered, but they can also serve as a non-registered mechanism 97 available for users to define themselves. This document provides a 98 mechanism to define tags and associate them with YANG modules in a 99 flexible manner. In particular, tags may be registered as well as 100 assigned during module definition; assigned by implementations; or 101 dynamically defined and set by users. 103 This document defines a YANG module [RFC7950] which provides a list 104 of module entries to allow for adding or removing of tags as well as 105 viewing the set of tags associated with a module. 107 This document defines an extension statement to be used to indicate 108 tags that SHOULD be added by the module implementation automatically 109 (i.e., outside of configuration). 111 This document also defines an IANA registry for tag prefixes as well 112 as a set of globally assigned tags. 114 Section 6 provides guidelines for authors of YANG data models. 116 This document updates [RFC8407]. 118 The YANG data model in this document conforms to the Network 119 Management Datastore Architecture defined in [RFC8342]. 121 1.1. Some possible use cases for YANG module tags 123 During this documents's development there were requests for example 124 uses of module tags. The following are a few example use cases for 125 tags. This list is certainly not exhaustive. 127 One example use of tags would be to help filter different discrete 128 categories of YANG modules supported by a device. For example, if 129 modules are suitably tagged, then an XPath query can be used to list 130 all of the vendor modules supported by a device. 132 Tags can also be used to help coordination when multiple semi- 133 independent clients are interacting with the same devices. For 134 example, one management client could mark that some modules should 135 not be used because they have not been verified to behave correctly, 136 so that other management clients avoid querying the data associated 137 with those modules. 139 Tag classification is useful for users searching module repositories 140 (e.g., YANG catalog). A query restricted to the 'ietf:routing' 141 module tag could be used to return only the IETF YANG modules 142 associated with routing. Without tags, a user would need to know the 143 name of all the IETF routing protocol YANG modules. 145 Future management protocol extensions could allow for filtering 146 queries of configuration or operational state on a server based on 147 tags. For example, return all operational state related to system- 148 management. 150 1.2. Conventions Used in This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 156 as shown here. 158 2. Tag Values 160 All tags SHOULD begin with a prefix indicating who owns their 161 definition. An IANA registry (Section 7.1) is used to support 162 registering tag prefixes. Currently 3 prefixes are defined. No 163 further structure is imposed by this document on the value following 164 the registered prefix, and the value can contain any YANG type 165 'string' characters except carriage-returns, newlines and tabs. 167 Again, except for the conflict-avoiding prefix, this document is not 168 specifying any structure on (i.e., restricting) the tag values on 169 purpose. The intent is to avoid arbitrarily restricting the values 170 that designers, implementers and users can use. As a result of this 171 choice, designers, implementers, and users are free to add or not add 172 any structure they may require to their own tag values. 174 2.1. IETF Tags 176 An IETF tag is a tag that has the prefix "ietf:". All IETF tags are 177 registered with IANA in a registry defined later in this document 178 (Section 7.2). 180 2.2. Vendor Tags 182 A vendor tag is a tag that has the prefix "vendor:". These tags are 183 defined by the vendor that implements the module, and are not 184 registered; however, it is RECOMMENDED that the vendor include extra 185 identification in the tag to avoid collisions such as using the 186 enterpise or organization name following the "vendor:" prefix (e.g., 187 vendor:example.com:vendor-defined-classifier). 189 2.3. User Tags 191 A user tag is any tag that has the prefix "user:". These tags are 192 defined by the user/administrator and are not meant to be registered. 193 Users are not required to use the "user:" prefix; however, doing so 194 is RECOMMENDED as it helps avoid collisions. 196 2.4. Reserved Tags 198 Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is 199 reserved for future use. These tag values are not invalid, but 200 simply reserved in the context of specifications (e.g., RFCs). 202 3. Tag Management 204 Tags can become associated with a module in a number of ways. Tags 205 may be defined and associated at module design time, at 206 implementation time, or via user administrative control. As the main 207 consumer of tags are users, users may also remove any tag, no matter 208 how the tag became associated with a module. 210 3.1. Module Definition Tagging 212 A module definition MAY indicate a set of tags to be added by the 213 module implementer. These design time tags are indicated using the 214 module-tag extension statement. 216 If the module is defined in an IETF standards track document, the 217 tags MUST be IETF Tags (2.1). Thus, new modules can drive the 218 addition of new IETF tags to the IANA registry defined in 219 Section 7.2, and the IANA registry can serve as a check against 220 duplication. 222 3.2. Implementation Tagging 224 An implementation MAY include additional tags associated with a 225 module. These tags SHOULD be IETF Tags (i.e., registered) or vendor 226 specific tags. 228 3.3. User Tagging 230 Tags of any kind, with or without a prefix, can be assigned and 231 removed by the user using normal configuration mechanisms. In order 232 to remove a tag from the operational datastore the user adds a 233 matching "masked-tag" entry for a given module. 235 4. Tags Module Structure 237 4.1. Tags Module Tree 239 The tree associated with the "ietf-module-tags" module follows. The 240 meaning of the symbols can be found in [RFC8340]. 242 module: ietf-module-tags 243 +--rw module-tags 244 +--rw module* [name] 245 +--rw name yang:yang-identifier 246 +--rw tag* tag 247 +--rw masked-tag* tag 249 Figure 1: YANG Module Tags Tree Diagram 251 4.2. YANG Module 253 file "ietf-module-tags@2019-09-25.yang" 254 module ietf-module-tags { 255 yang-version 1.1; 256 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; 257 prefix tags; 259 import ietf-yang-types { 260 prefix yang; 261 } 263 organization 264 "IETF NetMod Working Group (NetMod)"; 265 contact 266 "WG Web: 267 WG List: 269 Author: Christian Hopps 270 272 Author: Lou Berger 273 275 Author: Dean Bogdanovic 276 "; 278 // RFC Ed.: replace XXXX with actual RFC number and 279 // remove this note. 281 description 282 "This module describes a mechanism associating tags with YANG 283 modules. Tags may be IANA assigned or privately defined. 285 Copyright (c) 2019 IETF Trust and the persons identified as 286 authors of the code. All rights reserved. 288 Redistribution and use in source and binary forms, with or 289 without modification, is permitted pursuant to, and subject to 290 the license terms contained in, the Simplified BSD License set 291 forth in Section 4.c of the IETF Trust's Legal Provisions 292 Relating to IETF Documents 293 (https://trustee.ietf.org/license-info). 295 This version of this YANG module is part of RFC XXXX 296 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 297 for full legal notices. 299 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 300 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 301 'MAY', and 'OPTIONAL' in this document are to be interpreted as 302 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 303 they appear in all capitals, as shown here."; 305 // RFC Ed.: update the date below with the date of RFC publication 306 // and RFC number and remove this note. 308 revision 2019-09-25 { 309 description 310 "Initial revision."; 311 reference "RFC XXXX: YANG Module Tags"; 312 } 314 typedef tag { 315 type string { 316 length "1..max"; 317 pattern '[\S ]+'; 318 } 319 description 320 "A tag is a type 'string' value that does not include carriage 321 return, newline or tab characters. It SHOULD begin with a 322 registered prefix; however, tags without a registered prefix 323 SHOULD NOT be treated as invalid."; 324 } 326 extension module-tag { 327 argument tag; 328 description 329 "The argument 'tag' is of type 'tag'. This extension statement 330 is used by module authors to indicate the tags that SHOULD be 331 added automatically by the system. As such the origin of the 332 value for the pre-defined tags should be set to 'system' 333 [RFC8342]."; 334 } 336 container module-tags { 337 description 338 "Contains the list of modules and their associated tags"; 339 list module { 340 key "name"; 341 description 342 "A list of modules and their associated tags"; 343 leaf name { 344 type yang:yang-identifier; 345 mandatory true; 346 description 347 "The YANG module name."; 348 } 349 leaf-list tag { 350 type tag; 351 description 352 "Tags associated with the module. See the IANA 'YANG Module 353 Tag Prefixes' registry for reserved prefixes and the IANA 354 'IETF YANG Module Tags' registry for IETF tags. 356 The 'operational' state [RFC8342] view of this list is 357 constructed using the following steps: 359 1) System tags (i.e., tags of 'system' origin) are added. 360 2) User configured tags (i.e., tags of 'intended' origin) 361 are added. 362 3) Any tag that is equal to a masked-tag is removed."; 363 } 364 leaf-list masked-tag { 365 type tag; 366 description 367 "The list of tags that should not be associated with this 368 module. The user can remove (mask) tags from the 369 operational state datastore [RFC8342] by adding them to 370 this list. It is not an error to add tags to this list 371 that are not associated with the module, but they have no 372 operational effect."; 373 } 374 } 375 } 376 } 377 378 Figure 2: Module Tags Module 380 5. Other Classifications 382 It is worth noting that a different YANG module classification 383 document exists [RFC8199]. That document only classifies modules in 384 a logical manner and does not define tagging or any other mechanisms. 385 It divides YANG modules into two categories (service or element) and 386 then into one of three origins: standard, vendor or user. It does 387 provide a good way to discuss and identify modules in general. This 388 document defines IETF tags to support [RFC8199] style classification. 390 6. Guidelines to Model Writers 392 This section updates [RFC8407]. 394 6.1. Define Standard Tags 396 A module MAY indicate, using module-tag extension statements, a set 397 of tags that are to be automatically associated with it (i.e., not 398 added through configuration). 400 module example-module { 401 //... 402 import module-tags { prefix tags; } 404 tags:module-tag "ietf:some-new-tag"; 405 tags:module-tag "ietf:some-other-tag"; 406 // ... 407 } 409 The module writer can use existing standard tags, or use new tags 410 defined in the model definition, as appropriate. For IETF 411 standardized modules new tags MUST be assigned in the IANA registry 412 defined below, see Section 7.2. 414 7. IANA Considerations 416 7.1. YANG Module Tag Prefixes Registry 418 IANA is asked to create a new registry "YANG Module Tag Prefixes" 419 grouped under a new "Protocol" category named "YANG Module Tags". 421 This registry allocates tag prefixes. All YANG module tags SHOULD 422 begin with one of the prefixes in this registry. 424 Prefix entries in this registry should be short strings consisting of 425 lowercase ASCII alpha-numeric characters and a final ":" character. 427 The allocation policy for this registry is Specification Required 428 [RFC8126]. The Reference and Assignee values should be sufficient to 429 identify and contact the organization that has been allocated the 430 prefix. 432 The initial values for this registry are as follows. 434 +---------+----------------------------------+-----------+----------+ 435 | Prefix | Description | Reference | Assignee | 436 +---------+----------------------------------+-----------+----------+ 437 | ietf: | IETF Tags allocated in the IANA | [This | IETF | 438 | | IETF YANG Module Tags registry. | document] | | 439 | | | | | 440 | vendor: | Non-registered tags allocated by | [This | IETF | 441 | | the module implementer. | document] | | 442 | | | | | 443 | user: | Non-registered tags allocated by | [This | IETF | 444 | | and for the user. | document] | | 445 +---------+----------------------------------+-----------+----------+ 447 Other standards organizations (SDOs) wishing to allocate their own 448 set of tags should allocate a prefix from this registry. 450 7.2. IETF YANG Module Tags Registry 452 IANA is asked to create a new registry "IETF YANG Module Tags" 453 grouped under a new "Protocol" category "IETF YANG Module Tags". 454 This registry should be included below "YANG Module Tag Prefixes" 455 when listed on the same page. 457 This registry allocates tags that have the registered prefix "ietf:". 458 New values should be well considered and not achievable through a 459 combination of already existing IETF tags. 461 The allocation policy for this registry is IETF Review [RFC8126]. 463 The initial values for this registry are as follows. 465 +----------------------------+--------------------------+-----------+ 466 | Tag | Description | Reference | 467 +----------------------------+--------------------------+-----------+ 468 | ietf:network-element-class | [RFC8199] network | [RFC8199] | 469 | | element. | | 470 | | | | 471 | ietf:network-service-class | [RFC8199] network | [RFC8199] | 472 | | service. | | 473 | | | | 474 | ietf:sdo-defined-class | Module is defined by a | [RFC8199] | 475 | | standards organization. | | 476 | | | | 477 | ietf:vendor-defined-class | Module is defined by a | [RFC8199] | 478 | | vendor. | | 479 | | | | 480 | ietf:user-defined-class | Module is defined by the | [RFC8199] | 481 | | user. | | 482 | | | | 483 | ietf:hardware | Relates to hardware | [This | 484 | | (e.g., inventory). | document] | 485 | | | | 486 | ietf:software | Relates to software | [This | 487 | | (e.g., installed OS). | document] | 488 | | | | 489 | ietf:protocol | Represents a protocol | [This | 490 | | (often combined with | document] | 491 | | another tag to refine). | | 492 | | | | 493 | ietf:qos | Relates to quality of | [This | 494 | | service. | document] | 495 | | | | 496 | ietf:network-service-app | Relates to a network | [This | 497 | | service application | document] | 498 | | (e.g., an NTP server, | | 499 | | DNS server, DHCP server, | | 500 | | etc). | | 501 | | | | 502 | ietf:system-management | Relates to system | [This | 503 | | management (e.g., a | document] | 504 | | system management | | 505 | | protocol such as syslog, | | 506 | | TACAC+, SNMP, netconf, | | 507 | | ...). | | 508 | | | | 509 | ietf:oam | Relates to Operations, | [This | 510 | | Administration, and | document] | 511 | | Maintenance (e.g., BFD). | | 512 | | | | 513 | ietf:routing | Relates to routing. | [This | 514 | | | document] | 515 | | | | 516 | ietf:security | Related to security. | [This | 517 | | | document] | 518 | | | | 519 | ietf:signaling | Relates to control plane | [This | 520 | | signaling. | document] | 521 | | | | 522 | ietf:link-management | Relates to link | [This | 523 | | management. | document] | 524 +----------------------------+--------------------------+-----------+ 526 7.3. Updates to the IETF XML Registry 528 This document registers a URI in the "IETF XML Registry" [RFC3688]. 529 Following the format in [RFC3688], the following registrations have 530 been made: 532 URI: 533 urn:ietf:params:xml:ns:yang:ietf-module-tags 535 Registrant Contact: 536 The IESG. 538 XML: 539 N/A; the requested URI is an XML namespace. 541 URI: 542 urn:ietf:params:xml:ns:yang:ietf-module-tags-state 544 Registrant Contact: 545 The IESG. 547 XML: 548 N/A; the requested URI is an XML namespace. 550 7.4. Updates to the YANG Module Names Registry 552 This document registers two YANG modules in the "YANG Module Names" 553 registry [RFC6020]. Following the format in [RFC6020], the following 554 registration have been made: 556 name: 557 ietf-module-tags 559 namespace: 560 urn:ietf:params:xml:ns:yang:ietf-module-tags 562 prefix: 563 tags 565 reference: 566 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 567 this note.) 569 name: 570 ietf-module-tags-state 572 namespace: 573 urn:ietf:params:xml:ns:yang:ietf-module-tags-state 575 prefix: 576 tags 578 reference: 579 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 580 this note.) 582 8. Security Considerations 584 The YANG module defined in this memo is designed to be accessed via 585 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 586 secure transport layer and the mandatory-to-implement secure 587 transport is SSH [RFC6242]. 589 This document adds the ability to associate tag meta-data with YANG 590 modules. This document does not define any actions based on these 591 associations, and none are yet defined, and therefore it does not by 592 itself introduce any new security considerations. 594 Users of the tag-meta data may define various actions to be taken 595 based on the tag meta-data. These actions and their definitions are 596 outside the scope of this document. Users will need to consider the 597 security implications of any actions they choose to define. 599 9. References 601 9.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, 605 DOI 10.17487/RFC2119, March 1997, 606 . 608 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 609 RFC 7950, DOI 10.17487/RFC7950, August 2016, 610 . 612 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 613 Writing an IANA Considerations Section in RFCs", BCP 26, 614 RFC 8126, DOI 10.17487/RFC8126, June 2017, 615 . 617 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 618 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 619 May 2017, . 621 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 622 Classification", RFC 8199, DOI 10.17487/RFC8199, July 623 2017, . 625 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 626 and R. Wilton, "Network Management Datastore Architecture 627 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 628 . 630 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 631 Documents Containing YANG Data Models", BCP 216, RFC 8407, 632 DOI 10.17487/RFC8407, October 2018, 633 . 635 9.2. Informative References 637 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 638 DOI 10.17487/RFC3688, January 2004, 639 . 641 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 642 the Network Configuration Protocol (NETCONF)", RFC 6020, 643 DOI 10.17487/RFC6020, October 2010, 644 . 646 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 647 and A. Bierman, Ed., "Network Configuration Protocol 648 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 649 . 651 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 652 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 653 . 655 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 656 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 657 . 659 Appendix A. Examples 661 The following is a fictional NETCONF example result from a query of 662 the module tags list. For the sake of brevity only a few module 663 results are imagined. 665 666 667 668 ietf-bfd 669 ietf:network-element-class 670 ietf:oam 671 ietf:protocol 672 ietf:sdo-defined-class 673 674 675 ietf-isis 676 ietf:network-element-class 677 ietf:protocol 678 ietf:sdo-defined-class 679 ietf:routing 680 681 682 ietf-ssh-server 683 ietf:network-element-class 684 ietf:protocol 685 ietf:sdo-defined-class 686 ietf:system-management 687 688 689 691 Figure 3: Example NETCONF Query Output 693 Appendix B. Acknowledgements 695 Special thanks to Robert Wilton for his help improving the 696 introduction and providing the example use cases, as well as 697 generating the non-NMDA module. 699 Appendix C. Non-NMDA State Module. 701 As per [RFC8407] the following is a non-NMDA module to support 702 viewing the operational state for non-NMDA compliant servers. 704 file "ietf-module-tags-state@2019-09-25.yang" 705 module ietf-module-tags-state { 706 yang-version 1.1; 707 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; 708 prefix tags-s; 710 import ietf-yang-types { 711 prefix yang; 712 } 713 import ietf-module-tags { 714 prefix tags; 715 } 717 organization 718 "IETF NetMod Working Group (NetMod)"; 719 contact 720 "WG Web: 721 WG List: 723 Author: Christian Hopps 724 726 Author: Lou Berger 727 729 Author: Dean Bogdanovic 730 "; 732 // RFC Ed.: replace XXXX with actual RFC number and 733 // remove this note. 735 description 736 "This module describes a mechanism associating tags with YANG 737 modules. Tags may be IANA assigned or privately defined. 739 This is a temporary non-NMDA module that is for use by 740 implementations that don't yet support NMDA. 742 Copyright (c) 2019 IETF Trust and the persons identified as 743 authors of the code. All rights reserved. 745 Redistribution and use in source and binary forms, with or 746 without modification, is permitted pursuant to, and subject to 747 the license terms contained in, the Simplified BSD License set 748 forth in Section 4.c of the IETF Trust's Legal Provisions 749 Relating to IETF Documents 750 (https://trustee.ietf.org/license-info). 752 This version of this YANG module is part of RFC XXXX 753 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 754 for full legal notices. 756 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 757 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 758 'MAY', and 'OPTIONAL' in this document are to be interpreted as 759 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 760 they appear in all capitals, as shown here."; 762 // RFC Ed.: update the date below with the date of RFC publication 763 // and RFC number and remove this note. 765 revision 2019-09-25 { 766 description 767 "Initial revision."; 768 reference 769 "RFC XXXX: YANG Module Tags"; 770 } 772 container module-tags-state { 773 config false; 774 status deprecated; 775 description 776 "Contains the list of modules and their associated tags"; 777 list module { 778 key "name"; 779 status deprecated; 780 description 781 "A list of modules and their associated tags"; 782 leaf name { 783 type yang:yang-identifier; 784 mandatory true; 785 status deprecated; 786 description 787 "The YANG module name."; 788 } 789 leaf-list tag { 790 type tags:tag; 791 status deprecated; 792 description 793 "Tags associated with the module. See the IANA 'YANG Module 794 Tag Prefixes' registry for reserved prefixes and the IANA 795 'IETF YANG Module Tags' registry for IETF tags. 797 The contents of this list is constructed using the 798 following steps: 800 1) System tags (i.e., tags of added by the system) are added. 801 2) User configured tags (i.e., tags added by configuration) 802 are added. 803 3) Any tag that is equal to a masked-tag present in the 804 corresponding ietf-module-tags:module-tags:module-tag leaf 805 list for this module is removed."; 806 } 807 } 808 } 809 } 810 812 Figure 4: Non-NMDA Module Tags State Module 814 Authors' Addresses 816 Christian Hopps 817 LabN Consulting, L.L.C. 819 Email: chopps@chopps.org 821 Lou Berger 822 LabN Consulting, LLC. 824 Email: lberger@labn.net 826 Dean Bogdanovic 827 Volta Networks 829 Email: ivandean@gmail.com