idnits 2.17.1 draft-ietf-netmod-module-tags-07.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 (March 9, 2019) is 1872 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 10, 2019 D. Bogdanovic 7 Volta Networks 8 March 9, 2019 10 YANG Module Tags 11 draft-ietf-netmod-module-tags-07 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 standardized and assigned 19 during 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 10, 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 Standard 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. 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 standardized, but they can also serve as a non-standardized 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 standardized 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 standardizing tag prefixes. Currently 3 prefixes are defined. No 162 further structure is imposed by this document on the value following 163 the standard prefix, and the value can contain any YANG type 'string' 164 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 Standard Tags 175 An IETF standard tag is a tag that has the prefix "ietf:". All IETF 176 standard tags are registered with IANA in a registry defined later in 177 this document (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 standardized; however, it is RECOMMENDED that the vendor include 184 extra 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 will never be standardized. 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 standardization. These tag values are not 199 invalid, but simply reserved in the context of standardization. 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 Standard Tags (2.1). Thus, new modules can drive 217 the addition of new standard 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 Standard or vendor specific tags. 226 3.3. User Tagging 228 Tags of any kind, with or without a prefix, can be assigned and 229 removed by the user using normal configuration mechanisms. In order 230 to remove a tag from the operational datastore the user adds a 231 matching "masked-tag" entry for a given module. 233 4. Tags Module Structure 235 4.1. Tags Module Tree 237 The tree associated with the "ietf-module-tags" module follows. The 238 meaning of the symbols can be found in [RFC8340]. 240 module: ietf-module-tags 241 +--rw module-tags 242 +--rw module* [name] 243 +--rw name yang:yang-identifier 244 +--rw tag* tag 245 +--rw masked-tag* tag 247 4.2. YANG Module 249 file "ietf-module-tags@2019-03-09.yang" 250 module ietf-module-tags { 251 yang-version 1.1; 252 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; 253 prefix tags; 255 import ietf-yang-types { 256 prefix yang; 257 } 259 organization 260 "IETF NetMod Working Group (NetMod)"; 261 contact 262 "WG Web: 263 WG List: 265 Author: Christian Hopps 266 268 Author: Lou Berger 269 271 Author: Dean Bogdanovic 272 "; 274 // RFC Ed.: replace XXXX with actual RFC number and 275 // remove this note. 277 description 278 "This module describes a mechanism associating tags with YANG 279 modules. Tags may be IANA assigned or privately defined. 281 Copyright (c) 2018 IETF Trust and the persons identified as 282 authors of the code. All rights reserved. 284 Redistribution and use in source and binary forms, with or 285 without modification, is permitted pursuant to, and subject to 286 the license terms contained in, the Simplified BSD License set 287 forth in Section 4.c of the IETF Trust's Legal Provisions 288 Relating to IETF Documents 289 (https://trustee.ietf.org/license-info). 291 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 292 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 293 'MAY', and 'OPTIONAL' in this document are to be interpreted as 294 described in BCP 14 [RFC2119] [RFC8174] when, and only when, 295 they appear in all capitals, as shown here. 297 This version of this YANG module is part of RFC XXXX 298 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 299 full legal notices."; 301 // RFC Ed.: update the date below with the date of RFC publication 302 // and RFC number and remove this note. 304 revision 2019-03-09 { 305 description 306 "Initial revision."; 307 reference "RFC XXXX: YANG Module Tags"; 308 } 310 typedef tag { 311 type string { 312 length "1..max"; 313 pattern '[\S ]+'; 314 } 315 description 316 "A tag is a type 'string' value that does not include carriage 317 return, newline or tab characters. It SHOULD begin with a 318 standard prefix; however, tags without a standard prefix 319 SHOULD NOT be treated as invalid."; 320 } 322 extension module-tag { 323 argument tag; 324 description 325 "The argument 'tag' is of type 'tag'. This extension statement 326 is used by module authors to indicate the tags that SHOULD be 327 added automatically by the system. As such the origin of the 328 value for the pre-defined tags should be set to 'system' 329 [RFC8342]."; 330 } 332 container module-tags { 333 description 334 "Contains the list of modules and their associated tags"; 335 list module { 336 key "name"; 337 description 338 "A list of modules and their associated tags"; 339 leaf name { 340 type yang:yang-identifier; 341 mandatory true; 342 description 343 "The YANG module name."; 344 } 345 leaf-list tag { 346 type tag; 347 description 348 "Tags associated with the module. See the IANA 'YANG Module 349 Tag Prefixes' registry for reserved prefixes and the IANA 350 'YANG Module Tags' registry for IETF standard tags. 352 The 'operational' state [RFC8342] view of this list is 353 constructed using the following steps: 355 1) System tags (i.e., tags of 'system' origin) are added. 356 2) User configured tags (i.e., tags of 'intended' origin) 357 are added. 358 3) Any tag that is equal to a masked-tag is removed."; 359 } 360 leaf-list masked-tag { 361 type tag; 362 description 363 "The list of tags that should not be associated with this 364 module. The user can remove (mask) tags from the 365 operational state datastore [RFC8342] by adding them to 366 this list. It is not an error to add tags to this list 367 that are not associated with the module, but they have no 368 operational effect."; 369 } 370 } 371 } 372 } 373 375 5. Other Classifications 377 It is worth noting that a different YANG module classification 378 document exists [RFC8199]. That document only classifies modules in 379 a logical manner and does not define tagging or any other mechanisms. 380 It divides YANG modules into two categories (service or element) and 381 then into one of three origins: standard, vendor or user. It does 382 provide a good way to discuss and identify modules in general. This 383 document defines standard tags to support [RFC8199] style 384 classification. 386 6. Guidelines to Model Writers 388 This section updates [RFC8407]. 390 6.1. Define Standard Tags 392 A module MAY indicate, using module-tag extension statements, a set 393 of tags that are to be automatically associated with it (i.e., not 394 added through configuration). 396 module example-module { 397 //... 398 import module-tags { prefix tags; } 400 tags:module-tag "ietf:some-new-tag"; 401 tags:module-tag "ietf:some-other-tag"; 402 // ... 403 } 405 The module writer can use existing standard tags, or use new tags 406 defined in the model definition, as appropriate. For standardized 407 modules new tags MUST be assigned in the IANA registry defined below, 408 see Section 7.2. 410 7. IANA Considerations 412 7.1. YANG Module Tag Prefixes Registry 414 IANA is asked to create a new registry "YANG Module Tag Prefixes" 415 grouped under a new "Protocol" category named "YANG Module Tags". 417 This registry allocates tag prefixes. All YANG module tags SHOULD 418 begin with one of the prefixes in this registry. 420 Prefix entries in this registry should be short strings consisting of 421 lowercase ASCII alpha-numeric characters and a final ":" character. 423 The allocation policy for this registry is Specification Required 424 [RFC8126]. 426 The initial values for this registry are as follows. 428 +---------+---------------------------------------------------------+ 429 | Prefix | Description | 430 +---------+---------------------------------------------------------+ 431 | ietf: | IETF Standard Tag allocated in the IANA YANG Module | 432 | | Tags registry. | 433 | | | 434 | vendor: | Non-standardized tags allocated by the module | 435 | | implementer. | 436 | | | 437 | user: | Non-standardized tags allocated by and for the user. | 438 +---------+---------------------------------------------------------+ 440 Other standards organizations (SDOs) wishing to standardize their own 441 set of tags should allocate a prefix from this registry. 443 7.2. YANG Module Tags Registry 445 IANA is asked to create a new registry "YANG Module Tags" grouped 446 under a new "Protocol" category "YANG Module Tags". This registry 447 should be included below "YANG Module Tag Prefixes" when listed on 448 the same page. 450 This registry allocates prefixes that have the standard prefix 451 "ietf:". New values should be well considered and not achievable 452 through a combination of already existing standard tags. 454 The allocation policy for this registry is IETF Review [RFC8126]. 456 The initial values for this registry are as follows. 458 +----------------------------+--------------------------+-----------+ 459 | Tag | Description | Reference | 460 +----------------------------+--------------------------+-----------+ 461 | ietf:network-element-class | [RFC8199] network | [RFC8199] | 462 | | element. | | 463 | | | | 464 | ietf:network-service-class | [RFC8199] network | [RFC8199] | 465 | | service. | | 466 | | | | 467 | ietf:sdo-defined-class | Module is defined by a | [RFC8199] | 468 | | standards organization. | | 469 | | | | 470 | ietf:vendor-defined-class | Module is defined by a | [RFC8199] | 471 | | vendor. | | 472 | | | | 473 | ietf:user-defined-class | Module is defined by the | [RFC8199] | 474 | | user. | | 475 | | | | 476 | ietf:hardware | Relates to hardware | [This | 477 | | (e.g., inventory). | document] | 478 | | | | 479 | ietf:software | Relates to software | [This | 480 | | (e.g., installed OS). | document] | 481 | | | | 482 | ietf:protocol | Represents a protocol | [This | 483 | | (often combined with | document] | 484 | | another tag to refine). | | 485 | | | | 486 | ietf:qos | Relates to quality of | [This | 487 | | service. | document] | 488 | | | | 489 | ietf:network-service-app | Relates to a network | [This | 490 | | service application | document] | 491 | | (e.g., an NTP server, | | 492 | | DNS server, DHCP server, | | 493 | | etc). | | 494 | | | | 495 | ietf:system-management | Relates to system | [This | 496 | | management (e.g., a | document] | 497 | | system management | | 498 | | protocol such as syslog, | | 499 | | TACAC+, SNMP, netconf, | | 500 | | ...). | | 501 | | | | 502 | ietf:oam | Relates to Operations, | [This | 503 | | Administration, and | document] | 504 | | Maintenance (e.g., BFD). | | 505 | | | | 506 | ietf:routing | Relates to routing. | [This | 507 | | | document] | 508 | | | | 509 | ietf:security | Related to security. | [This | 510 | | | document] | 511 | | | | 512 | ietf:signaling | Relates to control plane | [This | 513 | | signaling. | document] | 514 | | | | 515 | ietf:link-management | Relates to link | [This | 516 | | management. | document] | 517 +----------------------------+--------------------------+-----------+ 519 7.3. Updates to the IETF XML Registry 521 This document registers a URI in the "IETF XML Registry" [RFC3688]. 522 Following the format in [RFC3688], the following registration has 523 been made: 525 URI: 526 urn:ietf:params:xml:ns:yang:ietf-module-tags 528 Registrant Contact: 529 The IESG. 531 XML: 532 N/A; the requested URI is an XML namespace. 534 7.4. Updates to the YANG Module Names Registry 536 This document registers one YANG module in the "YANG Module Names" 537 registry [RFC6020]. Following the format in [RFC6020], the following 538 registration has been made: 540 name: 541 ietf-module-tags 543 namespace: 544 urn:ietf:params:xml:ns:yang:ietf-module-tags 546 prefix: 547 tags 549 reference: 550 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 551 this note.) 553 8. Security Considerations 555 The YANG module defined in this memo is designed to be accessed via 556 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 557 secure transport layer and the mandatory-to-implement secure 558 transport is SSH [RFC6242]. 560 This document adds the ability to associate tag meta-data with YANG 561 modules. This document does not define any actions based on these 562 associations, and none are yet defined, and therefore it does not by 563 itself introduce any new security considerations. 565 Users of the tag-meta data may define various actions to be taken 566 based on the tag meta-data. These actions and their definitions are 567 outside the scope of this document. Users will need to consider the 568 security implications of any actions they choose to define. 570 9. References 572 9.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 580 RFC 7950, DOI 10.17487/RFC7950, August 2016, 581 . 583 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 584 Writing an IANA Considerations Section in RFCs", BCP 26, 585 RFC 8126, DOI 10.17487/RFC8126, June 2017, 586 . 588 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 589 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 590 May 2017, . 592 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 593 Classification", RFC 8199, DOI 10.17487/RFC8199, July 594 2017, . 596 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 597 and R. Wilton, "Network Management Datastore Architecture 598 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 599 . 601 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 602 Documents Containing YANG Data Models", BCP 216, RFC 8407, 603 DOI 10.17487/RFC8407, October 2018, 604 . 606 9.2. Informative References 608 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 609 DOI 10.17487/RFC3688, January 2004, 610 . 612 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 613 the Network Configuration Protocol (NETCONF)", RFC 6020, 614 DOI 10.17487/RFC6020, October 2010, 615 . 617 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 618 and A. Bierman, Ed., "Network Configuration Protocol 619 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 620 . 622 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 623 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 624 . 626 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 627 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 628 . 630 Appendix A. Examples 632 The following is a fictional example result from a query of the 633 module tags list. For the sake of brevity only a few module results 634 are imagined. 636 637 638 639 ietf-bfd 640 ietf:network-element-class 641 ietf:oam 642 ietf:protocol 643 ietf:sdo-defined-class 644 645 646 ietf-isis 647 ietf:network-element-class 648 ietf:protocol 649 ietf:sdo-defined-class 650 ietf:routing 651 652 653 ietf-ssh-server 654 ietf:network-element-class 655 ietf:protocol 656 ietf:sdo-defined-class 657 ietf:system-management 658 659 660 662 Appendix B. Acknowledgements 664 Special thanks to Robert Wilton for his help improving the 665 introduction and providing the example use cases. 667 Authors' Addresses 669 Christian Hopps 670 LabN Consulting, L.L.C. 672 Email: chopps@chopps.org 674 Lou Berger 675 LabN Consulting, LLC. 677 Email: lberger@labn.net 678 Dean Bogdanovic 679 Volta Networks 681 Email: ivandean@gmail.com