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