idnits 2.17.1 draft-ietf-netmod-module-tags-10.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 (February 29, 2020) is 1511 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: September 1, 2020 D. Bogdanovic 7 Volta Networks 8 February 29, 2020 10 YANG Module Tags 11 draft-ietf-netmod-module-tags-10 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 September 1, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . 15 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@2020-02-29.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 2020-02-29 { 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. IANA assigned tags must 460 conform to Net-Unicode as defined in [RFC5198] and they shall not 461 need normalization. 463 The allocation policy for this registry is IETF Review [RFC8126]. 465 The initial values for this registry are as follows. 467 +----------------------------+--------------------------+-----------+ 468 | Tag | Description | Reference | 469 +----------------------------+--------------------------+-----------+ 470 | ietf:network-element-class | [RFC8199] network | [RFC8199] | 471 | | element. | | 472 | | | | 473 | ietf:network-service-class | [RFC8199] network | [RFC8199] | 474 | | service. | | 475 | | | | 476 | ietf:sdo-defined-class | Module is defined by a | [RFC8199] | 477 | | standards organization. | | 478 | | | | 479 | ietf:vendor-defined-class | Module is defined by a | [RFC8199] | 480 | | vendor. | | 481 | | | | 482 | ietf:user-defined-class | Module is defined by the | [RFC8199] | 483 | | user. | | 484 | | | | 485 | ietf:hardware | Relates to hardware | [This | 486 | | (e.g., inventory). | document] | 487 | | | | 488 | ietf:software | Relates to software | [This | 489 | | (e.g., installed OS). | document] | 490 | | | | 491 | ietf:protocol | Represents a protocol | [This | 492 | | (often combined with | document] | 493 | | another tag to refine). | | 494 | | | | 495 | ietf:qos | Relates to quality of | [This | 496 | | service. | document] | 497 | | | | 498 | ietf:network-service-app | Relates to a network | [This | 499 | | service application | document] | 500 | | (e.g., an NTP server, | | 501 | | DNS server, DHCP server, | | 502 | | etc). | | 503 | | | | 504 | ietf:system-management | Relates to system | [This | 505 | | management (e.g., a | document] | 506 | | system management | | 507 | | protocol such as syslog, | | 508 | | TACAC+, SNMP, netconf, | | 509 | | ...). | | 510 | | | | 511 | ietf:oam | Relates to Operations, | [This | 512 | | Administration, and | document] | 513 | | Maintenance (e.g., BFD). | | 514 | | | | 515 | ietf:routing | Relates to routing. | [This | 516 | | | document] | 517 | | | | 518 | ietf:security | Related to security. | [This | 519 | | | document] | 520 | | | | 521 | ietf:signaling | Relates to control plane | [This | 522 | | signaling. | document] | 523 | | | | 524 | ietf:link-management | Relates to link | [This | 525 | | management. | document] | 526 +----------------------------+--------------------------+-----------+ 528 7.3. Updates to the IETF XML Registry 530 This document registers a URI in the "IETF XML Registry" [RFC3688]. 531 Following the format in [RFC3688], the following registrations have 532 been made: 534 URI: 535 urn:ietf:params:xml:ns:yang:ietf-module-tags 537 Registrant Contact: 538 The IESG. 540 XML: 541 N/A; the requested URI is an XML namespace. 543 URI: 544 urn:ietf:params:xml:ns:yang:ietf-module-tags-state 546 Registrant Contact: 547 The IESG. 549 XML: 550 N/A; the requested URI is an XML namespace. 552 7.4. Updates to the YANG Module Names Registry 554 This document registers two YANG modules in the "YANG Module Names" 555 registry [RFC6020]. Following the format in [RFC6020], the following 556 registration have been made: 558 name: 559 ietf-module-tags 561 namespace: 562 urn:ietf:params:xml:ns:yang:ietf-module-tags 564 prefix: 565 tags 567 reference: 568 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 569 this note.) 571 name: 572 ietf-module-tags-state 574 namespace: 575 urn:ietf:params:xml:ns:yang:ietf-module-tags-state 577 prefix: 578 tags 580 reference: 581 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 582 this note.) 584 8. Security Considerations 586 The YANG module defined in this memo is designed to be accessed via 587 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 588 secure transport layer and the mandatory-to-implement secure 589 transport is SSH [RFC6242]. 591 This document adds the ability to associate tag meta-data with YANG 592 modules. This document does not define any actions based on these 593 associations, and none are yet defined, and therefore it does not by 594 itself introduce any new security considerations directly. 596 Users of the tag-meta data may define various actions to be taken 597 based on the tag meta-data. These actions and their definitions are 598 outside the scope of this document. Users will need to consider the 599 security implications of any actions they choose to define, including 600 the potential for a tag to get 'masked' by another user. 602 9. References 604 9.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 612 RFC 7950, DOI 10.17487/RFC7950, August 2016, 613 . 615 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 616 Writing an IANA Considerations Section in RFCs", BCP 26, 617 RFC 8126, DOI 10.17487/RFC8126, June 2017, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 625 Classification", RFC 8199, DOI 10.17487/RFC8199, July 626 2017, . 628 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 629 and R. Wilton, "Network Management Datastore Architecture 630 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 631 . 633 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 634 Documents Containing YANG Data Models", BCP 216, RFC 8407, 635 DOI 10.17487/RFC8407, October 2018, 636 . 638 9.2. Informative References 640 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 641 DOI 10.17487/RFC3688, January 2004, 642 . 644 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 645 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 646 . 648 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 649 the Network Configuration Protocol (NETCONF)", RFC 6020, 650 DOI 10.17487/RFC6020, October 2010, 651 . 653 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 654 and A. Bierman, Ed., "Network Configuration Protocol 655 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 656 . 658 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 659 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 660 . 662 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 663 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 664 . 666 Appendix A. Examples 668 The following is a fictional NETCONF example result from a query of 669 the module tags list. For the sake of brevity only a few module 670 results are imagined. 672 673 674 675 ietf-bfd 676 ietf:network-element-class 677 ietf:oam 678 ietf:protocol 679 ietf:sdo-defined-class 680 681 682 ietf-isis 683 ietf:network-element-class 684 ietf:protocol 685 ietf:sdo-defined-class 686 ietf:routing 687 688 689 ietf-ssh-server 690 ietf:network-element-class 691 ietf:protocol 692 ietf:sdo-defined-class 693 ietf:system-management 694 695 696 698 Figure 3: Example NETCONF Query Output 700 Appendix B. Acknowledgements 702 Special thanks to Robert Wilton for his help improving the 703 introduction and providing the example use cases, as well as 704 generating the non-NMDA module. 706 Appendix C. Non-NMDA State Module. 708 As per [RFC8407] the following is a non-NMDA module to support 709 viewing the operational state for non-NMDA compliant servers. 711 file "ietf-module-tags-state@2020-02-29.yang" 712 module ietf-module-tags-state { 713 yang-version 1.1; 714 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; 715 prefix tags-s; 717 import ietf-yang-types { 718 prefix yang; 719 } 720 import ietf-module-tags { 721 prefix tags; 722 } 724 organization 725 "IETF NetMod Working Group (NetMod)"; 726 contact 727 "WG Web: 728 WG List: 730 Author: Christian Hopps 731 733 Author: Lou Berger 734 736 Author: Dean Bogdanovic 737 "; 739 // RFC Ed.: replace XXXX with actual RFC number and 740 // remove this note. 742 description 743 "This module describes a mechanism associating tags with YANG 744 modules. Tags may be IANA assigned or privately defined. 746 This is a temporary non-NMDA module that is for use by 747 implementations that don't yet support NMDA. 749 Copyright (c) 2019 IETF Trust and the persons identified as 750 authors of the code. All rights reserved. 752 Redistribution and use in source and binary forms, with or 753 without modification, is permitted pursuant to, and subject to 754 the license terms contained in, the Simplified BSD License set 755 forth in Section 4.c of the IETF Trust's Legal Provisions 756 Relating to IETF Documents 757 (https://trustee.ietf.org/license-info). 759 This version of this YANG module is part of RFC XXXX 760 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 761 for full legal notices. 763 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 764 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 765 'MAY', and 'OPTIONAL' in this document are to be interpreted as 766 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 767 they appear in all capitals, as shown here."; 769 // RFC Ed.: update the date below with the date of RFC publication 770 // and RFC number and remove this note. 772 revision 2020-02-29 { 773 description 774 "Initial revision."; 775 reference 776 "RFC XXXX: YANG Module Tags"; 777 } 779 container module-tags-state { 780 config false; 781 status deprecated; 782 description 783 "Contains the list of modules and their associated tags"; 784 list module { 785 key "name"; 786 status deprecated; 787 description 788 "A list of modules and their associated tags"; 789 leaf name { 790 type yang:yang-identifier; 791 mandatory true; 792 status deprecated; 793 description 794 "The YANG module name."; 795 } 796 leaf-list tag { 797 type tags:tag; 798 status deprecated; 799 description 800 "Tags associated with the module. See the IANA 'YANG Module 801 Tag Prefixes' registry for reserved prefixes and the IANA 802 'IETF YANG Module Tags' registry for IETF tags. 804 The contents of this list is constructed using the 805 following steps: 807 1) System tags (i.e., tags of added by the system) are added. 808 2) User configured tags (i.e., tags added by configuration) 809 are added. 810 3) Any tag that is equal to a masked-tag present in the 811 corresponding ietf-module-tags:module-tags:module-tag leaf 812 list for this module is removed."; 813 } 814 } 815 } 816 } 817 819 Figure 4: Non-NMDA Module Tags State Module 821 Authors' Addresses 823 Christian Hopps 824 LabN Consulting, L.L.C. 826 Email: chopps@chopps.org 828 Lou Berger 829 LabN Consulting, LLC. 831 Email: lberger@labn.net 833 Dean Bogdanovic 834 Volta Networks 836 Email: ivandean@gmail.com