idnits 2.17.00 (12 Aug 2021) /tmp/idnits46060/draft-ietf-core-sid-16.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 259 has weird spacing: '...evision rev...' == Line 261 has weird spacing: '...y-point sid...' == Line 265 has weird spacing: '...ntifier uni...' -- The document date (25 June 2021) is 330 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) == Missing Reference: 'DONE' is mentioned on line 1710, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-15 == Outdated reference: A later version (-17) exists of draft-ietf-anima-constrained-voucher-11 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M.V. Veillette, Ed. 3 Internet-Draft Trilliant Networks Inc. 4 Intended status: Standards Track A.P. Pelov, Ed. 5 Expires: 27 December 2021 Acklio 6 I. Petrov, Ed. 7 Google Switzerland GmbH 8 C. Bormann 9 Universität Bremen TZI 10 25 June 2021 12 YANG Schema Item iDentifier (YANG SID) 13 draft-ietf-core-sid-16 15 Abstract 17 YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit 18 unsigned integers used to identify YANG items. This document defines 19 the semantics, the registration, and assignment processes of YANG 20 SIDs. To enable the implementation of these processes, this document 21 also defines a file format used to persist and publish assigned YANG 22 SIDs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 27 December 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 59 3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5 60 4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6 61 5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 12 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13 65 7.2. Register ".sid" File Format Module . . . . . . . . . . . 13 66 7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 14 67 7.4. Create new IANA Registry: "YANG SID Mega-Range" 68 registry . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14 70 7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14 71 7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15 72 7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15 73 7.4.3. Initial contents of the Registry . . . . . . . . . . 15 74 7.5. Create a new IANA Registry: IETF YANG SID Range Registry 75 (managed by IANA) . . . . . . . . . . . . . . . . . . . . 16 76 7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16 77 7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16 78 7.5.3. Initial contents of the registry . . . . . . . . . . 18 79 7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 19 80 7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 19 81 7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 19 82 7.6.3. Recursive Allocation of YANG SID Range at Document 83 Adoption . . . . . . . . . . . . . . . . . . . . . . 20 84 7.6.4. Initial contents of the registry . . . . . . . . . . 21 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 8.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 24 89 Appendix B. SID auto generation . . . . . . . . . . . . . . . . 33 90 Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 34 91 C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 34 92 C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 36 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 96 1. Introduction 98 Some of the items defined in YANG [RFC7950] require the use of a 99 unique identifier. In both Network Configuration Protocol(NETCONF) 100 [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented 101 using names. To allow the implementation of data models defined in 102 YANG in constrained devices and constrained networks, a more compact 103 method to identify YANG items is required. This compact identifier, 104 called YANG SID or simply SID in this document and when the context 105 is clear, is encoded using a 63-bit unsigned integer. The limitation 106 to 63-bit unsigned integers allows SIDs to be manipulated more easily 107 on platforms that might otherwise lack native 64-bit unsigned 108 arithmetic. The loss of a single bit of range is not significant 109 given the size of the remaining space. 111 The following items are identified using SIDs: 113 * identities 115 * data nodes (Note: including those nodes defined by the 'yang-data' 116 extension.) 118 * remote procedure calls (RPCs) and associated input(s) and 119 output(s) 121 * actions and associated input(s) and output(s) 123 * notifications and associated information 125 * YANG modules, submodules and features 127 It is possible that some protocols use only a subset of the assigned 128 SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like 129 [I-D.ietf-core-comi] the transportation of YANG module SIDs might be 130 unnecessary. Other protocols might need to be able to transport this 131 information, for example protocols related to discovery such as 132 Constrained YANG Module Library [I-D.ietf-core-yang-library]. 134 SIDs are globally unique integers. A registration system is used in 135 order to guarantee their uniqueness. SIDs are registered in blocks 136 called "SID ranges". 138 Assignment of SIDs to YANG items can be automated. For more details 139 how this can be achieved, please consult Appendix B. 141 SIDs are assigned permanently, items introduced by a new revision of 142 a YANG module are added to the list of SIDs already assigned. If the 143 meaning of an item changes, for example as a result from a non- 144 backward compatible update of the YANG module, a new SID SHOULD be 145 assigned to it. A new SID MUST always be assigned if the new meaning 146 of the item is going to be referenced using a SID. 148 Section 3 provides more details about the registration process of 149 YANG modules and associated SIDs. To enable the implementation of 150 this registry, Section 4 defines a standard file format used to store 151 and publish SIDs. 153 2. Terminology and Notation 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 The following terms are defined in [RFC7950]: 163 * action 165 * feature 167 * module 169 * notification 171 * RPC 173 * schema node 175 * schema tree 177 * submodule 179 The following term is defined in [RFC8040]: 181 * yang-data extension 183 This specification also makes use of the following terminology: 185 * item: A schema node, an identity, a module, a submodule or a 186 feature defined using the YANG modeling language. 188 * schema-node path: A schema-node path is a string that identifies a 189 schema node within the schema tree. A path consists of the list 190 of consecutive schema node identifier(s) separated by slashes 191 ("/"). Schema node identifier(s) are always listed from the top- 192 level schema node up to the targeted schema node and could contain 193 namespace information. (e.g. "/ietf-system:system-state/clock/ 194 current-datetime") 196 * Namespace-qualified form - a schema node identifier is prefixed 197 with the name of the module in which the schema node is defined, 198 separated from the schema node identifier by the colon character 199 (":"). 201 * YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned 202 integer used to identify different YANG items. 204 3. ".sid" file lifecycle 206 YANG is a language designed to model data accessed using one of the 207 compatible protocols (e.g. NETCONF [RFC6241], RESTCONF [RFC8040] and 208 CORECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of 209 data, including configuration, state data, RPCs, actions and 210 notifications. 212 Many YANG modules are not created in the context of constrained 213 applications. YANG modules can be implemented using NETCONF 214 [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs. 216 As needed, authors of YANG modules can assign SIDs to their YANG 217 modules. In order to do that, they should first obtain a SID range 218 from a registry and use that range to assign or generate SIDs to 219 items of their YANG module. The assignments can then be stored in a 220 ".sid" file. For example on how this could be achieved, please refer 221 to Appendix C. 223 Registration of the ".sid" file associated to a YANG module is 224 optional but recommended to promote interoperability between devices 225 and to avoid duplicate allocation of SIDs to a single YANG module. 226 Different registries might have different requirements for the 227 registration and publication of the ".sid" files. For a diagram of 228 one of the possibilities, please refer to the activity diagram on 229 Figure 1 in Appendix C. 231 Each time a YANG module or one of its imported module(s) or included 232 sub-module(s) is updated, a new ".sid" file MAY be created if the new 233 or updated items will need SIDs. All the SIDs present in the 234 previous version of the ".sid" file MUST be present in the new 235 version as well. The creation of this new version of the ".sid" file 236 SHOULD be performed using an automated tool. 238 If a new revision requires more SIDs than initially allocated, a new 239 SID range MUST be added to the 'assignment-range' as defined in 240 Section 4. These extra SIDs are used for subsequent assignments. 242 For an example of this update process, see activity diagram Figure 2 243 in Appendix C. 245 4. ".sid" file format 247 ".sid" files are used to persist and publish SIDs assigned to the 248 different YANG items of a specific YANG module. It has the following 249 structure. 251 module: ietf-sid-file 252 +-- sid-file 253 +-- module-name? yang:yang-identifier 254 +-- module-revision? revision-identifier 255 +-- sid-file-version? sid-file-version-identifier 256 +-- description? string 257 +-- dependency-revision* [module-name] 258 | +-- module-name yang:yang-identifier 259 | +-- module-revision revision-identifier 260 +-- assignment-range* [entry-point] 261 | +-- entry-point sid 262 | +-- size uint64 263 +-- item* [namespace identifier] 264 +-- namespace enumeration 265 +-- identifier union 266 +-- sid sid 268 The following YANG module defined the structure of this file, 269 encoding is performed using the rules defined in [RFC7951]. It 270 references ietf-yang-types defined in [RFC6991] and ietf-restconf 271 defined in [RFC8040]. 273 RFC Ed.: please update the date of the module and Copyright if needed 274 and remove this note. 276 file "ietf-sid-file@2020-02-05.yang" 277 module ietf-sid-file { 278 yang-version 1.1; 279 namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; 280 prefix sid; 282 import ietf-yang-types { 283 prefix yang; 284 reference "RFC 6991: Common YANG Data Types."; 285 } 286 import ietf-restconf { 287 prefix rc; 288 reference "RFC 8040: RESTCONF Protocol."; 289 } 291 organization 292 "IETF Core Working Group"; 294 contact 295 "WG Web: 297 WG List: 299 Editor: Michel Veillette 300 302 Editor: Andy Bierman 303 305 Editor: Alexander Pelov 306 308 Editor: Ivaylo Petrov 309 "; 311 description 312 "Copyright (c) 2021 IETF Trust and the persons identified as 313 authors of the code. All rights reserved. 315 Redistribution and use in source and binary forms, with or 316 without modification, is permitted pursuant to, and subject to 317 the license terms contained in, the Simplified BSD License set 318 forth in Section 4.c of the IETF Trust's Legal Provisions 319 Relating to IETF Documents 320 (https://trustee.ietf.org/license-info). 322 This version of this YANG module is part of RFC XXXX 323 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 324 for full legal notices. 326 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 327 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 328 'MAY', and 'OPTIONAL' in this document are to be interpreted as 329 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 330 they appear in all capitals, as shown here. 332 This module defines the structure of the .sid files. 334 Each .sid file contains the mapping between the different 335 string identifiers defined by a YANG module and a 336 corresponding numeric value called YANG SID."; 338 revision 2020-02-05 { 339 description 340 "Initial revision."; 341 reference 342 "[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)"; 343 } 345 typedef revision-identifier { 346 type string { 347 pattern '\d{4}-\d{2}-\d{2}'; 348 } 349 description 350 "Represents a date in YYYY-MM-DD format."; 351 } 353 typedef sid-file-version-identifier { 354 type uint64; 355 description 356 "Represents the version of a .sid file."; 357 } 359 typedef sid { 360 type uint64 { 361 range "0..9223372036854775807"; 362 } 363 description 364 "YANG Schema Item iDentifier"; 365 reference 366 "[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)"; 367 } 369 typedef schema-node-path { 370 type string { 371 pattern 372 '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' + 373 '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*'; 374 } 375 description 376 "A schema-node path is an absolute YANG schema node identifier 377 as defined by the YANG ABNF rule absolute-schema-nodeid, 378 except that module names are used instead of prefixes. 380 This string additionally follows the following rules: 382 o The leftmost (top-level) data node name is always in the 383 namespace-qualified form. 384 o Any subsequent schema node name is in the 385 namespace-qualified form if the node is defined in a module 386 other than its parent node, and the simple form is used 387 otherwise. No predicates are allowed."; 388 reference 389 "RFC 7950, The YANG 1.1 Data Modeling Language; 390 Section 6.5: Schema Node Identifier;"; 391 } 393 rc:yang-data sid-file { 394 uses sid-file; 395 } 397 grouping sid-file { 398 description "A grouping that contains a YANG container 399 representing the file structure of a .sid files."; 401 container sid-file { 402 description 403 "A Wrapper container that together with the rc:yang-data 404 extension marks the YANG data structures inside as not being 405 intended to be implemented as part of a configuration 406 datastore or as an operational state within the server."; 407 leaf module-name { 408 type yang:yang-identifier; 409 description 410 "Name of the YANG module associated with this .sid file."; 411 } 413 leaf module-revision { 414 type revision-identifier; 415 description 416 "Revision of the YANG module associated with this .sid 417 file. 418 This leaf is not present if no revision statement is 419 defined in the YANG module."; 420 } 422 leaf sid-file-version { 423 type sid-file-version-identifier; 424 default 0; 425 description 426 "Optional leaf that specifies the version number of the 427 .sid file. .sid files and the version sequence are 428 specific to a given YANG module revision. This number 429 starts at zero when there is a new YANG module revision and 430 increases monotonically. This number can distinguish 431 updates to the .sid file which are the result of new 432 processing, or the result of reported errata."; 433 } 435 leaf description { 436 type string; 437 description 438 "Free-form meta information about the generated file. It 439 might include .sid file generation tool and time among 440 other things."; 441 } 443 list dependency-revision { 444 key "module-name"; 446 description 447 "Information about the used revision during the .sid file 448 generation of each YANG module that the module in 449 'module-name' imported."; 451 leaf module-name { 452 type yang:yang-identifier; 453 description 454 "Name of the YANG module, dependency of 'module-name', 455 for which revision information is provided."; 456 } 457 leaf module-revision { 458 type revision-identifier; 459 mandatory true; 460 description 461 "Revision of the YANG module, dependency of 462 'module-name', for which revision information is 463 provided."; 464 } 465 } 467 list assignment-range { 468 key "entry-point"; 469 description 470 "YANG SID range(s) allocated to the YANG module identified 471 by 'module-name' and 'module-revision'. 473 - The YANG SID range first available value is entry-point 474 and the the last available value in the range is 475 (entry-point + size - 1). 476 - The YANG SID ranges specified by all assignment-rages 477 MUST NOT overlap."; 479 leaf entry-point { 480 type sid; 481 description 482 "Lowest YANG SID available for assignment."; 483 } 485 leaf size { 486 type uint64; 487 mandatory true; 488 description 489 "Number of YANG SIDs available for assignment."; 490 } 491 } 493 list item { 494 key "namespace identifier"; 495 unique "sid"; 497 description 498 "Each entry within this list defined the mapping between 499 a YANG item string identifier and a YANG SID. This list 500 MUST include a mapping entry for each YANG item defined by 501 the YANG module identified by 'module-name' and 502 'module-revision'."; 504 leaf namespace { 505 type enumeration { 506 enum module { 507 value 0; 508 description 509 "All module and submodule names share the same 510 global module identifier namespace."; 511 } 512 enum identity { 513 value 1; 514 description 515 "All identity names defined in a module and its 516 submodules share the same identity identifier 517 namespace."; 518 } 519 enum feature { 520 value 2; 521 description 522 "All feature names defined in a module and its 523 submodules share the same feature identifier 524 namespace."; 525 } 526 enum data { 527 value 3; 528 description 529 "The namespace for all data nodes, as defined in 530 YANG."; 531 } 532 } 533 description 534 "Namespace of the YANG item for this mapping entry."; 535 } 537 leaf identifier { 538 type union { 539 type yang:yang-identifier; 540 type schema-node-path; 541 } 542 description 543 "String identifier of the YANG item for this mapping 544 entry. 546 If the corresponding 'namespace' field is 'module', 547 'feature', or 'identity', then this field MUST 548 contain a valid YANG identifier string. 550 If the corresponding 'namespace' field is 'data', 551 then this field MUST contain a valid schema node 552 path."; 553 } 555 leaf sid { 556 type sid; 557 mandatory true; 558 description 559 "YANG SID assigned to the YANG item for this mapping 560 entry."; 561 } 562 } 563 } 564 } 565 } 566 568 5. Content-Types 570 The following Content-Type has been defined in 571 [I-D.ietf-core-yang-cbor]: 573 application/yang-data+cbor; id=sid: This Content-Type represents a 574 CBOR YANG document containing one or multiple data node values. 575 Each data node is identified by its associated SID. 577 FORMAT: CBOR map of SID, instance-value 579 The message payload of Content-Type 'application/yang-data+cbor' 580 is encoded using a CBOR map. Each entry within the CBOR map 581 contains the data node identifier (i.e. SID) and the associated 582 instance-value. Instance-values are encoded using the rules 583 defined in Section 4 of [I-D.ietf-core-yang-cbor]. 585 6. Security Considerations 587 This document defines a new type of identifier used to encode data 588 models defined in YANG [RFC7950]. As such, this identifier does not 589 contribute to any new security issues in addition of those identified 590 for the specific protocols or contexts for which it is used. 592 7. IANA Considerations 594 7.1. YANG Namespace Registration 596 This document registers the following XML namespace URN in the "IETF 597 XML Registry", following the format defined in [RFC3688]: 599 URI: please assign urn:ietf:params:xml:ns:yang:ietf-sid-file 601 Registrant Contact: The IESG. 603 XML: N/A, the requested URI is an XML namespace. 605 Reference: RFC XXXX 607 // RFC Ed.: please replace XXXX with RFC number and remove this note 609 7.2. Register ".sid" File Format Module 611 This document registers one YANG module in the "YANG Module Names" 612 registry [RFC6020]: 614 * name: ietf-sid-file 616 * namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file 618 * prefix: sid 620 * reference: [[RFC XXXX]] 621 // RFC Ed.: please replace XXXX with RFC number and remove this note 623 7.3. CoAP Content-Formats Registry 625 A Content-Format for "application/yang-data+cbor; id=sid" has been 626 added to the "CoAP Content-Formats" within the "Constrained RESTful 627 Environments (CoRE) Parameters" registry, in 628 [I-D.ietf-core-yang-cbor]. 630 7.4. Create new IANA Registry: "YANG SID Mega-Range" registry 632 The name of this registry is "YANG SID Mega-Range". This registry is 633 used to record the delegation of the management of a block of SIDs to 634 third parties (such as SDOs or registrars). 636 7.4.1. Structure 638 Each entry in this registry must include: 640 * The entry point (first SID) of the registered SID block. 642 * The size of the registered SID block. The size MUST be one 643 million (1 000 000) SIDs. 645 * The contact information of the requesting organization including: 647 - The policy of SID range allocations: Public, Private or Both. 649 - Organization name 651 - URL 653 The information associated to the Organization name should not be 654 publicly visible in the registry, but should be available. This 655 information includes contact email and phone number and change 656 controller email and phone number. 658 7.4.2. Allocation policy 660 The IANA policy for future additions to this registry is "Expert 661 Review" [RFC8126]. 663 An organization requesting to manage a YANG SID Range (and thus have 664 an entry in the YANG SID Mega-Range Registry), must ensure the 665 following capacities: 667 * The capacity to manage and operate a YANG SID Range Registry. A 668 YANG SID Range Registry MUST provide the following information for 669 all YANG SID Ranges allocated by the Registry: 671 - Entry Point of allocated YANG SID Range 673 - Size of allocated YANG SID Range 675 - Type: Public or Private 677 o Public Ranges MUST include at least a reference to the YANG 678 module and ".sid" files for that YANG SID Range. 680 o Private Ranges MUST be marked as "Private" 682 * A Policy of allocation, which clearly identifies if the YANG SID 683 Range allocations would be Private, Public or Both. 685 * Technical capacity to ensure the sustained operation of the 686 registry for a period of at least 5 years. If Private 687 Registrations are allowed, the period must be of at least 10 688 years. 690 7.4.2.1. First allocation 692 For a first allocation to be provided, the requesting organization 693 must demonstrate a functional registry infrastructure. 695 7.4.2.2. Consecutive allocations 697 On subsequent allocation request(s), the organization must 698 demonstrate the exhaustion of the prior range. These conditions need 699 to be asserted by the assigned expert(s). 701 If that extra-allocation is done within 3 years from the last 702 allocation, the experts need to discuss this request on the CORE 703 working group mailing list and consensus needs to be obtained before 704 allocating a new Mega-Range. 706 7.4.3. Initial contents of the Registry 708 The initial entry in this registry is allocated to IANA: 710 +=============+=========+============+===================+==========+ 711 | Entry Point | Size | Allocation | Organization | URL | 712 | | | | name | | 713 +=============+=========+============+===================+==========+ 714 | 0 | 1000000 | Public | IANA | iana.org | 715 +-------------+---------+------------+-------------------+----------+ 717 Table 1 719 7.5. Create a new IANA Registry: IETF YANG SID Range Registry (managed 720 by IANA) 722 7.5.1. Structure 724 Each entry in this registry must include: 726 * The SID range entry point. 728 * The SID range size. 730 * The YANG module name. 732 * Document reference. 734 7.5.2. Allocation policy 736 The first million SIDs assigned to IANA is sub-divided as follows: 738 * The range of 0 to 999 (size 1000) is "Reserved" as defined in 739 [RFC8126]. 741 * The range of 1000 to 59,999 (size 59,000) is reserved for YANG 742 modules defined in RFCs. 744 - The IANA policy for additions to this registry is either: 746 o "Expert Review" [RFC8126] in case the ".sid" file comes from 747 a YANG module from an existing RFC, or 749 o "RFC Required" [RFC8126] otherwise. 751 - The Expert MUST verify that the YANG module for which this 752 allocation is made has an RFC (existing RFC) OR is on track to 753 become RFC (early allocation with a request from the WG chairs 754 as defined by [BCP100]). 756 * The range of 60,000 to 99,999 (size 40,000) is reserved for 757 experimental YANG modules. This range MUST NOT be used in 758 operational deployments since these SIDs are not globally unique 759 which limit their interoperability. The IANA policy for this 760 range is "Experimental use" [RFC8126]. 762 * The range of 100,000 to 999,999 (size 900,000) is "Reserved" as 763 defined in [RFC8126]. 765 +=============+=========+===============================+ 766 | Entry Point | Size | IANA policy | 767 +=============+=========+===============================+ 768 | 0 | 1,000 | Reserved | 769 +-------------+---------+-------------------------------+ 770 | 1,000 | 59,000 | Expert Review or RFC Required | 771 +-------------+---------+-------------------------------+ 772 | 60,000 | 40,000 | Experimental use | 773 +-------------+---------+-------------------------------+ 774 | 100,000 | 900,000 | Reserved | 775 +-------------+---------+-------------------------------+ 777 Table 2 779 The size of the SID range allocated for a YANG module is recommended 780 to be a multiple of 50 and to be at least 33% above the current 781 number of YANG items. This headroom allows assignment within the 782 same range of new YANG items introduced by subsequent revisions. The 783 maximum SID range size is 1000. A larger size may be requested by 784 the authors if this recommendation is considered insufficient. It is 785 important to note that an additional SID range can be allocated to an 786 existing YANG module if the initial range is exhausted. 788 In case a SID range is allocated for an existing RFC through the 789 "Expert Review" policy, the Document reference field for the given 790 allocation should point to the RFC that the YANG module is defined 791 in. 793 In case a SID range is required before publishing the RFC due to 794 implementations needing stable SID values, early allocation as 795 defined in [BCP100] can be employed. As specified in Section 4.6 of 796 [RFC8126], RFCs and by extension documents that are expected to 797 become an RFC fulfill the requirement for "Specification Required" 798 stated in Section 2 of [BCP100], which allows for the early 799 allocation process to be employed. 801 7.5.3. Initial contents of the registry 803 Initial entries in this registry are as follows: 805 +=======+=====+==============+======================================+ 806 | Entry | Size|Module name | Document reference | 807 | Point | | | | 808 +=======+=====+==============+======================================+ 809 | 1000 | 100|ietf-coreconf | [I-D.ietf-core-comi] | 810 +-------+-----+--------------+--------------------------------------+ 811 | 1100 | 50|ietf-yang- | [RFC6991] | 812 | | |types | | 813 +-------+-----+--------------+--------------------------------------+ 814 | 1150 | 50|ietf-inet- | [RFC6991] | 815 | | |types | | 816 +-------+-----+--------------+--------------------------------------+ 817 | 1200 | 50|iana-crypt- | [RFC7317] | 818 | | |hash | | 819 +-------+-----+--------------+--------------------------------------+ 820 | 1250 | 50|ietf-netconf- | [RFC8341] | 821 | | |acm | | 822 +-------+-----+--------------+--------------------------------------+ 823 | 1300 | 50|ietf-sid-file | RFCXXXX | 824 +-------+-----+--------------+--------------------------------------+ 825 | 1500 | 100|ietf- | [RFC8343] | 826 | | |interfaces | | 827 +-------+-----+--------------+--------------------------------------+ 828 | 1600 | 100|ietf-ip | [RFC8344] | 829 +-------+-----+--------------+--------------------------------------+ 830 | 1700 | 100|ietf-system | [RFC7317] | 831 +-------+-----+--------------+--------------------------------------+ 832 | 1800 | 400|iana-if-type | [RFC7224] | 833 +-------+-----+--------------+--------------------------------------+ 834 | 2400 | 50|ietf-voucher | [RFC8366] | 835 +-------+-----+--------------+--------------------------------------+ 836 | 2450 | 50|ietf- | [I-D.ietf-anima-constrained-voucher] | 837 | | |constrained- | | 838 | | |voucher | | 839 +-------+-----+--------------+--------------------------------------+ 840 | 2500 | 50|ietf- | [I-D.ietf-anima-constrained-voucher] | 841 | | |constrained- | | 842 | | |voucher- | | 843 | | |request | | 844 +-------+-----+--------------+--------------------------------------+ 846 Table 3 848 // RFC Ed.: replace XXXX with RFC number assigned to this draft. 850 For allocation, RFC publication of the YANG module is required as per 851 [RFC8126]. The YANG module must be registered in the "YANG module 852 Name" registry according to the rules specified in Section 14 of 853 [RFC6020]. 855 7.6. Create new IANA Registry: "IETF YANG SID Registry" 857 The name of this registry is "IETF YANG SID Registry". This registry 858 is used to record the allocation of SIDs for individual YANG module 859 items. 861 7.6.1. Structure 863 Each entry in this registry must include: 865 * The YANG module name. This module name must be present in the 866 "Name" column of the "YANG Module Names" registry. 868 * A link to the associated ".yang" file. This file link must be 869 present in the "File" column of the "YANG Module Names" registry. 871 * The link to the ".sid" file which defines the allocation. The 872 ".sid" file is stored by IANA. 874 * The number of actually allocated SIDs in the ".sid" file. 876 7.6.2. Allocation policy 878 The allocation policy is Expert review. The Expert MUST ensure that 879 the following conditions are met: 881 * The ".sid" file has a valid structure: 883 - The ".sid" file MUST be a valid JSON file following the 884 structure of the module defined in RFCXXXX (RFC Ed: replace XXX 885 with RFC number assigned to this draft). 887 * The ".sid" file allocates individual SIDs ONLY in the YANG SID 888 Ranges for this YANG module (as allocated in the IETF YANG SID 889 Range Registry): 891 - All SIDs in this ".sid" file MUST be within the ranges 892 allocated to this YANG module in the "IETF YANG SID Range 893 Registry". 895 * If another ".sid" file has already allocated SIDs for this YANG 896 module (e.g. for older or newer versions of the YANG module), the 897 YANG items are assigned the same SIDs as in the other ".sid" file. 899 * If there is an older version of the ".sid" file, all allocated 900 SIDs from that version are still present in the current version of 901 the ".sid" file. 903 7.6.3. Recursive Allocation of YANG SID Range at Document Adoption 905 Due to the difficulty in changing SID values during IETF document 906 processing, it is expected that most documents will ask for SID 907 allocations using Early Allocations [BCP100]. The details of the 908 Early Allocation should be included in any Working Group Adoption 909 call. Prior to Working Group Adoption, an internet draft authors can 910 use the experimental SID range (as per Section 7.5.2) for their SIDs 911 allocations or other values that do not create ambiguity with other 912 SID uses (for example they can use a range that comes from a non-IANA 913 managed "YANG SID Mega-Range" registry). 915 After Working Group Adoption, any modification of a ".sid" file is 916 expected to be discussed on the mailing list of the appropriate 917 Working Groups. Specific attention should be paid to implementers' 918 opinion after Working Group Last Call if a SID value is to change its 919 meaning. In all cases, a ".sid" file and the SIDs associated with it 920 are subject to change before the publication of an internet draft as 921 an RFC. 923 During the early use of SIDs, many existing, previously published 924 YANG modules will not have SID allocations. For an allocation to be 925 useful the included YANG modules may also need to have SID 926 allocations made. 928 The Expert Reviewer who performs the (Early) Allocation analysis will 929 need to go through the list of included YANG modules and perform SID 930 allocations for those modules as well. 932 * If the document is a published RFC, then the allocation of SIDs 933 for its referenced YANG modules is permanent. The Expert Reviewer 934 provides the generated SID file to IANA for registration. This 935 process may be time consuming during a bootstrap period (there are 936 over 100 YANG modules to date, none of which have SID 937 allocations), but should quiet down once needed entries are 938 allocated. 940 * If the document is an unprocessed Internet-Draft adopted in a WG, 941 then an Early Allocation is performed for this document as well. 942 Early Allocations require approval by an IESG Area Director. An 943 early allocation which requires additional allocations will list 944 the other allocations in it's description, and will be cross- 945 posted to the any other working group mailing lists. 947 * A YANG module which references a module in an document which has 948 not yet been adopted by any working group will be unable to 949 perform an Early Allocation for that other document until it is 950 adopted by a working group. As described in [BCP100], an AD 951 Sponsored document acts as if it had a working group. The 952 approving AD may also exempt a document from this policy by 953 agreeing to AD Sponsor the document. 955 At the end of the IETF process all the dependencies of a given module 956 for which SIDs are assigned, should also have SIDs assigned. Those 957 dependencies' assignments should be permanent (not Early Allocation). 959 A previously SID-allocated YANG module which changes its references 960 to include a YANG module for which there is no SID allocation needs 961 to repeat the Early Allocation process. 963 Early Allocations are made with a one-year period, after which they 964 are expired. [BCP100] indicates that at most one renewal may be 965 made. For the SID allocation a far more lenient stance is desired. 967 1. An extension of a referencing documents Early Allocation should 968 update any referenced Early Allocations to expire no sooner than 969 the referencing document. 971 2. The [BCP100] mechanism allows the IESG to provide a second 972 renewal, and such an event may prompt some thought about how the 973 collection of documents are being processed. 975 This is driven by the very generous size of the SID space and the 976 often complex and deep dependencies of YANG modules. Often a core 977 module with many dependencies will undergo extensive review, delaying 978 the publication of other documents. 980 [BCP100] also says: 982 Note that if a document is submitted for review to the IESG and at 983 the time of submission some early allocations are valid (not 984 expired), these allocations should not be expired while the document 985 is under IESG consideration or waiting in the RFC Editor's queue 986 after approval by the IESG. 988 7.6.4. Initial contents of the registry 990 None. 992 8. References 994 8.1. Normative References 996 [BCP100] Cotton, M., "Early IANA Allocation of Standards Track Code 997 Points", BCP 100, RFC 7120, January 2014. 999 1001 [I-D.ietf-core-yang-cbor] 1002 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1003 Data Modeled with YANG", Work in Progress, Internet-Draft, 1004 draft-ietf-core-yang-cbor-15, 25 January 2021, 1005 . 1008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1009 Requirement Levels", BCP 14, RFC 2119, 1010 DOI 10.17487/RFC2119, March 1997, 1011 . 1013 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1014 DOI 10.17487/RFC3688, January 2004, 1015 . 1017 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1018 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1019 . 1021 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1022 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1023 . 1025 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1026 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1027 . 1029 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1030 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1031 . 1033 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1034 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1035 May 2017, . 1037 8.2. Informative References 1039 [I-D.ietf-anima-constrained-voucher] 1040 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 1041 Dijk, "Constrained Voucher Artifacts for Bootstrapping 1042 Protocols", Work in Progress, Internet-Draft, draft-ietf- 1043 anima-constrained-voucher-11, 11 June 2021, 1044 . 1047 [I-D.ietf-core-comi] 1048 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 1049 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 1050 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 1051 January 2021, . 1054 [I-D.ietf-core-yang-library] 1055 Veillette, M. and I. Petrov, "Constrained YANG Module 1056 Library", Work in Progress, Internet-Draft, draft-ietf- 1057 core-yang-library-03, 11 January 2021, 1058 . 1061 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1062 the Network Configuration Protocol (NETCONF)", RFC 6020, 1063 DOI 10.17487/RFC6020, October 2010, 1064 . 1066 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1067 and A. Bierman, Ed., "Network Configuration Protocol 1068 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1069 . 1071 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1072 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1073 . 1075 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1076 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1077 2014, . 1079 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1080 Writing an IANA Considerations Section in RFCs", BCP 26, 1081 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1082 . 1084 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1085 Access Control Model", STD 91, RFC 8341, 1086 DOI 10.17487/RFC8341, March 2018, 1087 . 1089 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1090 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1091 . 1093 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1094 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1095 . 1097 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1098 "A Voucher Artifact for Bootstrapping Protocols", 1099 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1100 . 1102 Appendix A. ".sid" file example 1104 The following ".sid" file (ietf-system@2014-08-06.sid) have been 1105 generated using the following yang modules: 1107 * ietf-system@2014-08-06.yang (defined in [RFC7317]) 1109 * ietf-yang-types@2013-07-15.yang (defined in [RFC6991]) 1111 * ietf-inet-types@2013-07-15.yang (defined in [RFC6991]) 1113 * ietf-netconf-acm@2018-02-14.yang (defined in [RFC8341]) 1115 * iana-crypt-hash@2014-08-06.yang (defined in [RFC7317]) 1117 { 1118 "ietf-sid-file:sid-file" : { 1119 "module-name": "ietf-system", 1120 "module-revision": "2020-02-05", 1121 "dependency-revision": [ 1122 { 1123 "module-name": "ietf-yang-types", 1124 "module-revision": "2013-07-15" 1125 }, 1126 { 1127 "module-name": "ietf-inet-types", 1128 "module-revision": "2013-07-15" 1129 }, 1130 { 1131 "module-name": "ietf-netconf-acm", 1132 "module-revision": "2018-02-14" 1133 }, 1134 { 1135 "module-name": "iana-crypt-hash", 1136 "module-revision": "2014-08-06" 1137 } 1138 ], 1139 "description": "Example sid file", 1140 "assignment-range": [ 1141 { 1142 "entry-point": 1700, 1143 "size": 100 1144 } 1145 ], 1146 "item": [ 1147 { 1148 "namespace": "module", 1149 "identifier": "ietf-system", 1150 "sid": 1700 1151 }, 1152 { 1153 "namespace": "identity", 1154 "identifier": "authentication-method", 1155 "sid": 1701 1156 }, 1157 { 1158 "namespace": "identity", 1159 "identifier": "local-users", 1160 "sid": 1702 1161 }, 1162 { 1163 "namespace": "identity", 1164 "identifier": "radius", 1165 "sid": 1703 1166 }, 1167 { 1168 "namespace": "identity", 1169 "identifier": "radius-authentication-type", 1170 "sid": 1704 1171 }, 1172 { 1173 "namespace": "identity", 1174 "identifier": "radius-chap", 1175 "sid": 1705 1176 }, 1177 { 1178 "namespace": "identity", 1179 "identifier": "radius-pap", 1180 "sid": 1706 1181 }, 1182 { 1183 "namespace": "feature", 1184 "identifier": "authentication", 1185 "sid": 1707 1186 }, 1187 { 1188 "namespace": "feature", 1189 "identifier": "dns-udp-tcp-port", 1190 "sid": 1708 1191 }, 1192 { 1193 "namespace": "feature", 1194 "identifier": "local-users", 1195 "sid": 1709 1196 }, 1197 { 1198 "namespace": "feature", 1199 "identifier": "ntp", 1200 "sid": 1710 1201 }, 1202 { 1203 "namespace": "feature", 1204 "identifier": "ntp-udp-port", 1205 "sid": 1711 1206 }, 1207 { 1208 "namespace": "feature", 1209 "identifier": "radius", 1210 "sid": 1712 1211 }, 1212 { 1213 "namespace": "feature", 1214 "identifier": "radius-authentication", 1215 "sid": 1713 1216 }, 1217 { 1218 "namespace": "feature", 1219 "identifier": "timezone-name", 1220 "sid": 1714 1221 }, 1222 { 1223 "namespace": "data", 1224 "identifier": "/ietf-system:set-current-datetime", 1225 "sid": 1715 1226 }, 1227 { 1228 "namespace": "data", 1229 "identifier": "/ietf-system:set-current-datetime/ 1230 current-datetime", 1231 "sid": 1716 1232 }, 1233 { 1234 "namespace": "data", 1235 "identifier": "/ietf-system:system", 1236 "sid": 1717 1237 }, 1238 { 1239 "namespace": "data", 1240 "identifier": "/ietf-system:system-restart", 1241 "sid": 1718 1242 }, 1243 { 1244 "namespace": "data", 1245 "identifier": "/ietf-system:system-shutdown", 1246 "sid": 1719 1247 }, 1248 { 1249 "namespace": "data", 1250 "identifier": "/ietf-system:system-state", 1251 "sid": 1720 1252 }, 1253 { 1254 "namespace": "data", 1255 "identifier": "/ietf-system:system-state/clock", 1256 "sid": 1721 1257 }, 1258 { 1259 "namespace": "data", 1260 "identifier": "/ietf-system:system-state/clock/boot-datetime", 1261 "sid": 1722 1262 }, 1263 { 1264 "namespace": "data", 1265 "identifier": "/ietf-system:system-state/clock/ 1266 current-datetime", 1267 "sid": 1723 1268 }, 1269 { 1270 "namespace": "data", 1271 "identifier": "/ietf-system:system-state/platform", 1272 "sid": 1724 1273 }, 1274 { 1275 "namespace": "data", 1276 "identifier": "/ietf-system:system-state/platform/machine", 1277 "sid": 1725 1278 }, 1279 { 1280 "namespace": "data", 1281 "identifier": "/ietf-system:system-state/platform/os-name", 1282 "sid": 1726 1283 }, 1284 { 1285 "namespace": "data", 1286 "identifier": "/ietf-system:system-state/platform/os-release", 1287 "sid": 1727 1288 }, 1289 { 1290 "namespace": "data", 1291 "identifier": "/ietf-system:system-state/platform/os-version", 1292 "sid": 1728 1293 }, 1294 { 1295 "namespace": "data", 1296 "identifier": "/ietf-system:system/authentication", 1297 "sid": 1729 1298 }, 1299 { 1300 "namespace": "data", 1301 "identifier": "/ietf-system:system/authentication/user", 1302 "sid": 1730 1303 }, 1304 { 1305 "namespace": "data", 1306 "identifier": "/ietf-system:system/authentication/ 1307 user-authentication-order", 1308 "sid": 1731 1309 }, 1310 { 1311 "namespace": "data", 1312 "identifier": "/ietf-system:system/authentication/user/ 1313 authorized-key", 1314 "sid": 1732 1315 }, 1316 { 1317 "namespace": "data", 1318 "identifier": "/ietf-system:system/authentication/user/ 1319 authorized-key/algorithm", 1320 "sid": 1733 1321 }, 1322 { 1323 "namespace": "data", 1324 "identifier": "/ietf-system:system/authentication/user/ 1325 authorized-key/key-data", 1326 "sid": 1734 1327 }, 1328 { 1329 "namespace": "data", 1330 "identifier": "/ietf-system:system/authentication/user/ 1331 authorized-key/name", 1332 "sid": 1735 1333 }, 1334 { 1335 "namespace": "data", 1336 "identifier": "/ietf-system:system/authentication/user/ 1337 name", 1338 "sid": 1736 1339 }, 1340 { 1341 "namespace": "data", 1342 "identifier": "/ietf-system:system/authentication/user/ 1343 password", 1344 "sid": 1737 1345 }, 1346 { 1347 "namespace": "data", 1348 "identifier": "/ietf-system:system/clock", 1349 "sid": 1738 1350 }, 1351 { 1352 "namespace": "data", 1353 "identifier": "/ietf-system:system/clock/timezone-name", 1354 "sid": 1739 1355 }, 1356 { 1357 "namespace": "data", 1358 "identifier": "/ietf-system:system/clock/timezone-utc-offset", 1359 "sid": 1740 1360 }, 1361 { 1362 "namespace": "data", 1363 "identifier": "/ietf-system:system/contact", 1364 "sid": 1741 1365 }, 1366 { 1367 "namespace": "data", 1368 "identifier": "/ietf-system:system/dns-resolver", 1369 "sid": 1742 1370 }, 1371 { 1372 "namespace": "data", 1373 "identifier": "/ietf-system:system/dns-resolver/options", 1374 "sid": 1743 1375 }, 1376 { 1377 "namespace": "data", 1378 "identifier": "/ietf-system:system/dns-resolver/options/ 1379 attempts", 1380 "sid": 1744 1381 }, 1382 { 1383 "namespace": "data", 1384 "identifier": "/ietf-system:system/dns-resolver/options/ 1385 timeout", 1386 "sid": 1745 1387 }, 1388 { 1389 "namespace": "data", 1390 "identifier": "/ietf-system:system/dns-resolver/search", 1391 "sid": 1746 1392 }, 1393 { 1394 "namespace": "data", 1395 "identifier": "/ietf-system:system/dns-resolver/server", 1396 "sid": 1747 1397 }, 1398 { 1399 "namespace": "data", 1400 "identifier": "/ietf-system:system/dns-resolver/server/name", 1401 "sid": 1748 1402 }, 1403 { 1404 "namespace": "data", 1405 "identifier": "/ietf-system:system/dns-resolver/server/ 1406 udp-and-tcp", 1407 "sid": 1749 1408 }, 1409 { 1410 "namespace": "data", 1411 "identifier": "/ietf-system:system/dns-resolver/server/ 1412 udp-and-tcp/address", 1413 "sid": 1750 1414 }, 1415 { 1416 "namespace": "data", 1417 "identifier": "/ietf-system:system/dns-resolver/server/ 1418 udp-and-tcp/port", 1419 "sid": 1751 1421 }, 1422 { 1423 "namespace": "data", 1424 "identifier": "/ietf-system:system/hostname", 1425 "sid": 1752 1426 }, 1427 { 1428 "namespace": "data", 1429 "identifier": "/ietf-system:system/location", 1430 "sid": 1753 1431 }, 1432 { 1433 "namespace": "data", 1434 "identifier": "/ietf-system:system/ntp", 1435 "sid": 1754 1436 }, 1437 { 1438 "namespace": "data", 1439 "identifier": "/ietf-system:system/ntp/enabled", 1440 "sid": 1755 1441 }, 1442 { 1443 "namespace": "data", 1444 "identifier": "/ietf-system:system/ntp/server", 1445 "sid": 1756 1446 }, 1447 { 1448 "namespace": "data", 1449 "identifier": "/ietf-system:system/ntp/server/ 1450 association-type", 1451 "sid": 1757 1452 }, 1453 { 1454 "namespace": "data", 1455 "identifier": "/ietf-system:system/ntp/server/iburst", 1456 "sid": 1758 1457 }, 1458 { 1459 "namespace": "data", 1460 "identifier": "/ietf-system:system/ntp/server/name", 1461 "sid": 1759 1462 }, 1463 { 1464 "namespace": "data", 1465 "identifier": "/ietf-system:system/ntp/server/prefer", 1466 "sid": 1760 1467 }, 1468 { 1469 "namespace": "data", 1470 "identifier": "/ietf-system:system/ntp/server/udp", 1471 "sid": 1761 1472 }, 1473 { 1474 "namespace": "data", 1475 "identifier": "/ietf-system:system/ntp/server/udp/address", 1476 "sid": 1762 1477 }, 1478 { 1479 "namespace": "data", 1480 "identifier": "/ietf-system:system/ntp/server/udp/port", 1481 "sid": 1763 1482 }, 1483 { 1484 "namespace": "data", 1485 "identifier": "/ietf-system:system/radius", 1486 "sid": 1764 1487 }, 1488 { 1489 "namespace": "data", 1490 "identifier": "/ietf-system:system/radius/options", 1491 "sid": 1765 1492 }, 1493 { 1494 "namespace": "data", 1495 "identifier": "/ietf-system:system/radius/options/attempts", 1496 "sid": 1766 1497 }, 1498 { 1499 "namespace": "data", 1500 "identifier": "/ietf-system:system/radius/options/timeout", 1501 "sid": 1767 1502 }, 1503 { 1504 "namespace": "data", 1505 "identifier": "/ietf-system:system/radius/server", 1506 "sid": 1768 1507 }, 1508 { 1509 "namespace": "data", 1510 "identifier": "/ietf-system:system/radius/server/ 1511 authentication-type", 1512 "sid": 1769 1513 }, 1514 { 1515 "namespace": "data", 1516 "identifier": "/ietf-system:system/radius/server/name", 1517 "sid": 1770 1518 }, 1519 { 1520 "namespace": "data", 1521 "identifier": "/ietf-system:system/radius/server/udp", 1522 "sid": 1771 1523 }, 1524 { 1525 "namespace": "data", 1526 "identifier": "/ietf-system:system/radius/server/udp/ 1527 address", 1528 "sid": 1772 1529 }, 1530 { 1531 "namespace": "data", 1532 "identifier": "/ietf-system:system/radius/server/udp/ 1533 authentication-port", 1534 "sid": 1773 1535 }, 1536 { 1537 "namespace": "data", 1538 "identifier": "/ietf-system:system/radius/server/udp/ 1539 shared-secret", 1540 "sid": 1774 1541 } 1542 ] 1543 } 1544 } 1546 Appendix B. SID auto generation 1548 Assignment of SIDs to YANG items can be automated, the recommended 1549 process to assign SIDs is as follows: 1551 1. A tool extracts the different items defined for a specific YANG 1552 module. 1554 2. The list of items is sorted in alphabetical order, 'namespace' in 1555 descending order, 'identifier' in ascending order. The 1556 'namespace' and 'identifier' formats are described in the YANG 1557 module 'ietf-sid-file' defined in Section 4. 1559 3. SIDs are assigned sequentially from the entry point up to the 1560 size of the registered SID range. This approach is recommended 1561 to minimize the serialization overhead, especially when delta 1562 between a reference SID and the current SID is used by protocols 1563 aiming to reduce message size. 1565 4. If the number of items exceeds the SID range(s) allocated to a 1566 YANG module, an extra range is added for subsequent assignments. 1568 5. The "dependency-revision" should reflect the revision numbers of 1569 each YANG module that the YANG module imports at the moment of 1570 the generation. 1572 In case of an update to an existing ".sid" file, an additional step 1573 is needed that increments the ".sid" file version number. If there 1574 was no version number in the previous version of the ".sid" file, 0 1575 is assumed as the version number of the old version of the ".sid" 1576 file and the version number is 1 for the new ".sid" file. Apart from 1577 that, changes of ".sid" files can also be automated using the same 1578 method described above, only unassigned YANG items are processed at 1579 step #3. Already existing items in the ".sid" file should not be 1580 given new SIDs. 1582 Note that ".sid" file versions are specific to a YANG module 1583 revision. For each new YANG module or each new revision of an 1584 existing YANG module, the version number of the initial ".sid" file 1585 should either be 0 or should not be present. 1587 Note also that RPC or action "input" and "output" data nodes MUST 1588 always be assigned SID even if they don't contain data nodes. The 1589 reason for this requirement is that other modules can augment the 1590 given module and those SIDs might be necessary. 1592 Appendix C. ".sid" file lifecycle 1594 Before assigning SIDs to their YANG modules, YANG module authors must 1595 acquire a SID range from a "YANG SID Range Registry". If the YANG 1596 module is part of an IETF draft or RFC, the SID range need to be 1597 acquired from the "IETF YANG SID Range Registry" as defined in 1598 Section 7.5. For the other YANG modules, the authors can acquire a 1599 SID range from any "YANG SID Range Registry" of their choice. 1601 Once the SID range is acquired, the owner can use it to generate 1602 ".sid" file/s for his YANG module/s. It is recommended to leave some 1603 unallocated SIDs following the allocated range in each ".sid" file in 1604 order to allow better evolution of the YANG module in the future. 1605 Generation of ".sid" files should be performed using an automated 1606 tool. Note that ".sid" files can only be generated for YANG modules 1607 and not for submodules. 1609 C.1. ".sid" File Creation 1611 The following activity diagram summarizes the creation of a YANG 1612 module and its associated ".sid" file. 1614 +---------------+ 1615 o | Creation of a | 1616 -+- -->| YANG module | 1617 / \ +------+--------+ 1618 | 1619 v 1620 .-------------. 1621 / Standardized \ yes 1622 \ YANG module ? /------------+ 1623 '-----+-------' | 1624 | no | 1625 v v 1626 .-------------. +---------------+ 1627 +--> / Constrained \ yes | SID range | 1628 | \ application ? /---->| registration |<---------+ 1629 | '-----+-------' +------+--------+ | 1630 | | no | | 1631 | v v | 1632 | +---------------+ +---------------+ | 1633 +----+ YANG module | | SID sub-range | | 1634 | update | | assignment |<----------+ 1635 +---------------+ +-------+-------+ | 1636 | | 1637 v | 1638 +---------------+ +------+------+ 1639 | ".sid" file | | Rework YANG | 1640 | generation | | model | 1641 +-------+-------+ +-------------+ 1642 | ^ 1643 v | 1644 .----------. yes | 1645 / Work in \ -----------+ 1646 \ progress / 1647 '----+-----' 1648 | no 1649 v 1650 .-------------. .-------------. 1651 / RFC \ no / Open \ no 1652 \ publication? /---> \ specification?/---+ 1653 '------+------' '------+------' | 1654 yes | | yes | 1655 | .------------' | 1656 | / | 1657 v v v 1658 +---------------+ +---------------+ 1659 | IANA | | Third party | 1660 | registration | | registration | 1661 +-------+-------+ +---------+-----+ 1662 | | 1663 +---------------------------------+ 1664 v 1665 [DONE] 1667 Figure 1: SID Lifecycle 1669 C.2. ".sid" File Update 1671 The following Activity diagram summarizes the update of a YANG module 1672 and its associated ".sid" file. 1674 +---------------+ 1675 o | Update of the | 1676 -+- -->| YANG module | 1677 / \ | or include(s) | 1678 | or import(s) | 1679 +------+--------+ 1680 | 1681 v 1682 .-------------. 1683 / New items \ yes 1684 \ created ? /------+ 1685 '------+------' | 1686 | no v 1687 | .-------------. +----------------+ 1688 | / SID range \ yes | Extra sub-range| 1689 | \ exhausted ? /---->| assignment | 1690 | '------+------' +-------+--------+ 1691 | | no | 1692 | +---------------------+ 1693 | | 1694 | v 1695 | +---------------+ 1696 | | ".sid" file | 1697 | | update based | 1698 | | on previous | 1699 | | ".sid" file | 1700 | +-------+-------+ 1701 | | 1702 | v 1703 | .-------------. +---------------+ 1704 | / Publicly \ yes | YANG module | 1705 | \ available ? /---->| registration | 1706 | '------+------' +-------+-------+ 1707 | | no | 1708 +--------------+---------------------+ 1709 | 1710 [DONE] 1712 Figure 2: YANG and ".sid" file update 1714 Acknowledgments 1716 The authors would like to thank Andy Bierman, Michael Richardson, 1717 Abhinav Somaraju, Peter van der Stok, Laurent Toutain and Randy 1718 Turner for their help during the development of this document and 1719 their useful comments during the review process. 1721 Authors' Addresses 1723 Michel Veillette (editor) 1724 Trilliant Networks Inc. 1725 610 Rue du Luxembourg 1726 Granby Quebec J2J 2V2 1727 Canada 1729 Phone: +14503750556 1730 Email: michel.veillette@trilliant.com 1732 Alexander Pelov (editor) 1733 Acklio 1734 1137A avenue des Champs Blancs 1735 35510 Cesson-Sevigne 1736 France 1738 Email: a@ackl.io 1740 Ivaylo Petrov (editor) 1741 Google Switzerland GmbH 1742 Brandschenkestrasse 110 1743 CH-8002 Zurich 1744 Switzerland 1746 Email: ivaylopetrov@google.com 1748 Carsten Bormann 1749 Universität Bremen TZI 1750 Postfach 330440 1751 D-28359 Bremen 1752 Germany 1754 Phone: +49-421-218-63921 1755 Email: cabo@tzi.org