idnits 2.17.1 draft-ietf-netmod-module-tags-08.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 (May 3, 2019) is 1820 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: November 4, 2019 D. Bogdanovic 7 Volta Networks 8 May 3, 2019 10 YANG Module Tags 11 draft-ietf-netmod-module-tags-08 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 November 4, 2019. 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 . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 9.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 85 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The use of tags for classification and organization is fairly 91 ubiquitous not only within IETF protocols, but in the internet itself 92 (e.g., "#hashtags"). One benefit of using tags for organization over 93 a rigid structure is that it is more flexible and can more easily 94 adapt over time as technologies evolve. Tags can be usefully 95 registered, but they can also serve as a non-registered mechanism 96 available for users to define themselves. This document provides a 97 mechanism to define tags and associate them with YANG modules in a 98 flexible manner. In particular, tags may be registered as well as 99 assigned during module definition; assigned by implementations; or 100 dynamically defined and set by users. 102 This document defines a YANG module [RFC7950] which provides a list 103 of module entries to allow for adding or removing of tags as well as 104 viewing the set of tags associated with a module. 106 This document defines an extension statement to be used to indicate 107 tags that SHOULD be added by the module implementation automatically 108 (i.e., outside of configuration). 110 This document also defines an IANA registry for tag prefixes as well 111 as a set of globally assigned tags. 113 Section 6 provides guidelines for authors of YANG data models. 115 This document updates [RFC8407]. 117 The YANG data model in this document conforms to the Network 118 Management Datastore Architecture defined in [RFC8342]. 120 1.1. Some possible use cases for YANG module tags 122 During this documents's development there were requests for example 123 uses of module tags. The following are a few example use cases for 124 tags. This list is certainly not exhaustive. 126 One example use of tags would be to help filter different discrete 127 categories of YANG modules supported by a device. For example, if 128 modules are suitably tagged, then an XPath query can be used to list 129 all of the vendor modules supported by a device. 131 Tags can also be used to help coordination when multiple semi- 132 independent clients are interacting with the same devices. For 133 example, one management client could mark that some modules should 134 not be used because they have not been verified to behave correctly, 135 so that other management clients avoid querying the data associated 136 with those modules. 138 Tag classification is useful for users searching module repositories 139 (e.g., YANG catalog). A query restricted to the 'ietf:routing' 140 module tag could be used to return only the IETF YANG modules 141 associated with routing. Without tags, a user would need to know the 142 name of all the IETF routing protocol YANG modules. 144 Future management protocol extensions could allow for filtering 145 queries of configuration or operational state on a server based on 146 tags. For example, return all operational state related to system- 147 management. 149 1.2. Conventions Used in This Document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 155 as shown here. 157 2. Tag Values 159 All tags SHOULD begin with a prefix indicating who owns their 160 definition. An IANA registry (Section 7.1) is used to support 161 registering tag prefixes. Currently 3 prefixes are defined. No 162 further structure is imposed by this document on the value following 163 the registered prefix, and the value can contain any YANG type 164 'string' characters except carriage-returns, newlines and tabs. 166 Again, except for the conflict-avoiding prefix, this document is not 167 specifying any structure on (i.e., restricting) the tag values on 168 purpose. The intent is to avoid arbitrarily restricting the values 169 that designers, implementers and users can use. As a result of this 170 choice, designers, implementers, and users are free to add or not add 171 any structure they may require to their own tag values. 173 2.1. IETF Tags 175 An IETF tag is a tag that has the prefix "ietf:". All IETF tags are 176 registered with IANA in a registry defined later in this document 177 (Section 7.2). 179 2.2. Vendor Tags 181 A vendor tag is a tag that has the prefix "vendor:". These tags are 182 defined by the vendor that implements the module, and are not 183 registered; however, it is RECOMMENDED that the vendor include extra 184 identification in the tag to avoid collisions such as using the 185 enterpise or organization name following the "vendor:" prefix (e.g., 186 vendor:example.com:vendor-defined-classifier). 188 2.3. User Tags 190 A user tag is any tag that has the prefix "user:". These tags are 191 defined by the user/administrator and are not meant to be registered. 192 Users are not required to use the "user:" prefix; however, doing so 193 is RECOMMENDED as it helps avoid collisions. 195 2.4. Reserved Tags 197 Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is 198 reserved for future use. These tag values are not invalid, but 199 simply reserved in the context of specifications (e.g., RFCs). 201 3. Tag Management 203 Tags can become associated with a module in a number of ways. Tags 204 may be defined and associated at module design time, at 205 implementation time, or via user administrative control. As the main 206 consumer of tags are users, users may also remove any tag, no matter 207 how the tag became associated with a module. 209 3.1. Module Definition Tagging 211 A module definition MAY indicate a set of tags to be added by the 212 module implementer. These design time tags are indicated using the 213 module-tag extension statement. 215 If the module is defined in an IETF standards track document, the 216 tags MUST be IETF Tags (2.1). Thus, new modules can drive the 217 addition of new IETF tags to the IANA registry defined in 218 Section 7.2, and the IANA registry can serve as a check against 219 duplication. 221 3.2. Implementation Tagging 223 An implementation MAY include additional tags associated with a 224 module. These tags SHOULD be IETF Tags (i.e., registered) or vendor 225 specific tags. 227 3.3. User Tagging 229 Tags of any kind, with or without a prefix, can be assigned and 230 removed by the user using normal configuration mechanisms. In order 231 to remove a tag from the operational datastore the user adds a 232 matching "masked-tag" entry for a given module. 234 4. Tags Module Structure 236 4.1. Tags Module Tree 238 The tree associated with the "ietf-module-tags" module follows. The 239 meaning of the symbols can be found in [RFC8340]. 241 module: ietf-module-tags 242 +--rw module-tags 243 +--rw module* [name] 244 +--rw name yang:yang-identifier 245 +--rw tag* tag 246 +--rw masked-tag* tag 248 4.2. YANG Module 250 file "ietf-module-tags@2019-05-03.yang" 251 module ietf-module-tags { 252 yang-version 1.1; 253 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; 254 prefix tags; 256 import ietf-yang-types { 257 prefix yang; 258 } 260 organization 261 "IETF NetMod Working Group (NetMod)"; 262 contact 263 "WG Web: 264 WG List: 266 Author: Christian Hopps 267 269 Author: Lou Berger 270 272 Author: Dean Bogdanovic 273 "; 275 // RFC Ed.: replace XXXX with actual RFC number and 276 // remove this note. 278 description 279 "This module describes a mechanism associating tags with YANG 280 modules. Tags may be IANA assigned or privately defined. 282 Copyright (c) 2018 IETF Trust and the persons identified as 283 authors of the code. All rights reserved. 285 Redistribution and use in source and binary forms, with or 286 without modification, is permitted pursuant to, and subject to 287 the license terms contained in, the Simplified BSD License set 288 forth in Section 4.c of the IETF Trust's Legal Provisions 289 Relating to IETF Documents 290 (https://trustee.ietf.org/license-info). 292 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 293 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 294 'MAY', and 'OPTIONAL' in this document are to be interpreted as 295 described in BCP 14 [RFC2119] [RFC8174] when, and only when, 296 they appear in all capitals, as shown here. 298 This version of this YANG module is part of RFC XXXX 299 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 300 full legal notices."; 302 // RFC Ed.: update the date below with the date of RFC publication 303 // and RFC number and remove this note. 305 revision 2019-05-03 { 306 description 307 "Initial revision."; 308 reference "RFC XXXX: YANG Module Tags"; 309 } 311 typedef tag { 312 type string { 313 length "1..max"; 314 pattern '[\S ]+'; 315 } 316 description 317 "A tag is a type 'string' value that does not include carriage 318 return, newline or tab characters. It SHOULD begin with a 319 registered prefix; however, tags without a registered prefix 320 SHOULD NOT be treated as invalid."; 321 } 323 extension module-tag { 324 argument tag; 325 description 326 "The argument 'tag' is of type 'tag'. This extension statement 327 is used by module authors to indicate the tags that SHOULD be 328 added automatically by the system. As such the origin of the 329 value for the pre-defined tags should be set to 'system' 330 [RFC8342]."; 331 } 333 container module-tags { 334 description 335 "Contains the list of modules and their associated tags"; 336 list module { 337 key "name"; 338 description 339 "A list of modules and their associated tags"; 340 leaf name { 341 type yang:yang-identifier; 342 mandatory true; 343 description 344 "The YANG module name."; 345 } 346 leaf-list tag { 347 type tag; 348 description 349 "Tags associated with the module. See the IANA 'YANG Module 350 Tag Prefixes' registry for reserved prefixes and the IANA 351 'IETF YANG Module Tags' registry for IETF tags. 353 The 'operational' state [RFC8342] view of this list is 354 constructed using the following steps: 356 1) System tags (i.e., tags of 'system' origin) are added. 357 2) User configured tags (i.e., tags of 'intended' origin) 358 are added. 359 3) Any tag that is equal to a masked-tag is removed."; 360 } 361 leaf-list masked-tag { 362 type tag; 363 description 364 "The list of tags that should not be associated with this 365 module. The user can remove (mask) tags from the 366 operational state datastore [RFC8342] by adding them to 367 this list. It is not an error to add tags to this list 368 that are not associated with the module, but they have no 369 operational effect."; 370 } 371 } 372 } 373 } 374 376 Figure 1: Module Tags Module 378 5. Other Classifications 380 It is worth noting that a different YANG module classification 381 document exists [RFC8199]. That document only classifies modules in 382 a logical manner and does not define tagging or any other mechanisms. 383 It divides YANG modules into two categories (service or element) and 384 then into one of three origins: standard, vendor or user. It does 385 provide a good way to discuss and identify modules in general. This 386 document defines IETF tags to support [RFC8199] style classification. 388 6. Guidelines to Model Writers 390 This section updates [RFC8407]. 392 6.1. Define Standard Tags 394 A module MAY indicate, using module-tag extension statements, a set 395 of tags that are to be automatically associated with it (i.e., not 396 added through configuration). 398 module example-module { 399 //... 400 import module-tags { prefix tags; } 402 tags:module-tag "ietf:some-new-tag"; 403 tags:module-tag "ietf:some-other-tag"; 404 // ... 405 } 407 The module writer can use existing standard tags, or use new tags 408 defined in the model definition, as appropriate. For IETF 409 standardized modules new tags MUST be assigned in the IANA registry 410 defined below, see Section 7.2. 412 7. IANA Considerations 414 7.1. YANG Module Tag Prefixes Registry 416 IANA is asked to create a new registry "YANG Module Tag Prefixes" 417 grouped under a new "Protocol" category named "YANG Module Tags". 419 This registry allocates tag prefixes. All YANG module tags SHOULD 420 begin with one of the prefixes in this registry. 422 Prefix entries in this registry should be short strings consisting of 423 lowercase ASCII alpha-numeric characters and a final ":" character. 425 The allocation policy for this registry is Specification Required 426 [RFC8126]. The Reference and Assignee values should be sufficient to 427 identify and contact the organization that has been allocated the 428 prefix. 430 The initial values for this registry are as follows. 432 +---------+----------------------------------+-----------+----------+ 433 | Prefix | Description | Reference | Assignee | 434 +---------+----------------------------------+-----------+----------+ 435 | ietf: | IETF Tags allocated in the IANA | [This | IETF | 436 | | IETF YANG Module Tags registry. | document] | | 437 | | | | | 438 | vendor: | Non-registered tags allocated by | [This | IETF | 439 | | the module implementer. | document] | | 440 | | | | | 441 | user: | Non-registered tags allocated by | [This | IETF | 442 | | and for the user. | document] | | 443 +---------+----------------------------------+-----------+----------+ 445 Other standards organizations (SDOs) wishing to allocate their own 446 set of tags should allocate a prefix from this registry. 448 7.2. IETF YANG Module Tags Registry 450 IANA is asked to create a new registry "IETF YANG Module Tags" 451 grouped under a new "Protocol" category "IETF YANG Module Tags". 452 This registry should be included below "YANG Module Tag Prefixes" 453 when listed on the same page. 455 This registry allocates tags that have the registered prefix "ietf:". 456 New values should be well considered and not achievable through a 457 combination of already existing IETF tags. 459 The allocation policy for this registry is IETF Review [RFC8126]. 461 The initial values for this registry are as follows. 463 +----------------------------+--------------------------+-----------+ 464 | Tag | Description | Reference | 465 +----------------------------+--------------------------+-----------+ 466 | ietf:network-element-class | [RFC8199] network | [RFC8199] | 467 | | element. | | 468 | | | | 469 | ietf:network-service-class | [RFC8199] network | [RFC8199] | 470 | | service. | | 471 | | | | 472 | ietf:sdo-defined-class | Module is defined by a | [RFC8199] | 473 | | standards organization. | | 474 | | | | 475 | ietf:vendor-defined-class | Module is defined by a | [RFC8199] | 476 | | vendor. | | 477 | | | | 478 | ietf:user-defined-class | Module is defined by the | [RFC8199] | 479 | | user. | | 480 | | | | 481 | ietf:hardware | Relates to hardware | [This | 482 | | (e.g., inventory). | document] | 483 | | | | 484 | ietf:software | Relates to software | [This | 485 | | (e.g., installed OS). | document] | 486 | | | | 487 | ietf:protocol | Represents a protocol | [This | 488 | | (often combined with | document] | 489 | | another tag to refine). | | 490 | | | | 491 | ietf:qos | Relates to quality of | [This | 492 | | service. | document] | 493 | | | | 494 | ietf:network-service-app | Relates to a network | [This | 495 | | service application | document] | 496 | | (e.g., an NTP server, | | 497 | | DNS server, DHCP server, | | 498 | | etc). | | 499 | | | | 500 | ietf:system-management | Relates to system | [This | 501 | | management (e.g., a | document] | 502 | | system management | | 503 | | protocol such as syslog, | | 504 | | TACAC+, SNMP, netconf, | | 505 | | ...). | | 506 | | | | 507 | ietf:oam | Relates to Operations, | [This | 508 | | Administration, and | document] | 509 | | Maintenance (e.g., BFD). | | 510 | | | | 511 | ietf:routing | Relates to routing. | [This | 512 | | | document] | 513 | | | | 514 | ietf:security | Related to security. | [This | 515 | | | document] | 516 | | | | 517 | ietf:signaling | Relates to control plane | [This | 518 | | signaling. | document] | 519 | | | | 520 | ietf:link-management | Relates to link | [This | 521 | | management. | document] | 522 +----------------------------+--------------------------+-----------+ 524 7.3. Updates to the IETF XML Registry 526 This document registers a URI in the "IETF XML Registry" [RFC3688]. 527 Following the format in [RFC3688], the following registration has 528 been made: 530 URI: 531 urn:ietf:params:xml:ns:yang:ietf-module-tags 533 Registrant Contact: 534 The IESG. 536 XML: 537 N/A; the requested URI is an XML namespace. 539 7.4. Updates to the YANG Module Names Registry 541 This document registers one YANG module in the "YANG Module Names" 542 registry [RFC6020]. Following the format in [RFC6020], the following 543 registration has been made: 545 name: 546 ietf-module-tags 548 namespace: 549 urn:ietf:params:xml:ns:yang:ietf-module-tags 551 prefix: 552 tags 554 reference: 555 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 556 this note.) 558 8. Security Considerations 560 The YANG module defined in this memo is designed to be accessed via 561 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 562 secure transport layer and the mandatory-to-implement secure 563 transport is SSH [RFC6242]. 565 This document adds the ability to associate tag meta-data with YANG 566 modules. This document does not define any actions based on these 567 associations, and none are yet defined, and therefore it does not by 568 itself introduce any new security considerations. 570 Users of the tag-meta data may define various actions to be taken 571 based on the tag meta-data. These actions and their definitions are 572 outside the scope of this document. Users will need to consider the 573 security implications of any actions they choose to define. 575 9. References 577 9.1. Normative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 585 RFC 7950, DOI 10.17487/RFC7950, August 2016, 586 . 588 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 589 Writing an IANA Considerations Section in RFCs", BCP 26, 590 RFC 8126, DOI 10.17487/RFC8126, June 2017, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 595 May 2017, . 597 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 598 Classification", RFC 8199, DOI 10.17487/RFC8199, July 599 2017, . 601 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 602 and R. Wilton, "Network Management Datastore Architecture 603 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 604 . 606 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 607 Documents Containing YANG Data Models", BCP 216, RFC 8407, 608 DOI 10.17487/RFC8407, October 2018, 609 . 611 9.2. Informative References 613 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 614 DOI 10.17487/RFC3688, January 2004, 615 . 617 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 618 the Network Configuration Protocol (NETCONF)", RFC 6020, 619 DOI 10.17487/RFC6020, October 2010, 620 . 622 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 623 and A. Bierman, Ed., "Network Configuration Protocol 624 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 625 . 627 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 628 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 629 . 631 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 632 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 633 . 635 Appendix A. Examples 637 The following is a fictional NETCONF example result from a query of 638 the module tags list. For the sake of brevity only a few module 639 results are imagined. 641 642 643 644 ietf-bfd 645 ietf:network-element-class 646 ietf:oam 647 ietf:protocol 648 ietf:sdo-defined-class 649 650 651 ietf-isis 652 ietf:network-element-class 653 ietf:protocol 654 ietf:sdo-defined-class 655 ietf:routing 656 657 658 ietf-ssh-server 659 ietf:network-element-class 660 ietf:protocol 661 ietf:sdo-defined-class 662 ietf:system-management 663 664 665 667 Appendix B. Acknowledgements 669 Special thanks to Robert Wilton for his help improving the 670 introduction and providing the example use cases. 672 Authors' Addresses 674 Christian Hopps 675 LabN Consulting, L.L.C. 677 Email: chopps@chopps.org 679 Lou Berger 680 LabN Consulting, LLC. 682 Email: lberger@labn.net 683 Dean Bogdanovic 684 Volta Networks 686 Email: ivandean@gmail.com