idnits 2.17.00 (12 Aug 2021) /tmp/idnits43188/draft-ietf-core-sid-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2020) is 829 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 1490, but not defined == Unused Reference: 'I-D.ietf-anima-constrained-voucher' is defined on line 850, 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-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: August 15, 2020 I. Petrov, Ed. 6 Acklio 7 February 12, 2020 9 YANG Schema Item iDentifier (SID) 10 draft-ietf-core-sid-10 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 August 15, 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 . . . . . . . . . . . . . . . . . . 3 56 3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 4 57 4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 6.1. Register SID File Format Module . . . . . . . . . . . . . 10 61 6.2. Create new IANA Registry: "SID Mega-Range" registry . . . 11 62 6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 11 63 6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 11 64 6.2.2.1. First allocation . . . . . . . . . . . . . . . . 12 65 6.2.2.2. Consecutive allocations . . . . . . . . . . . . . 12 66 6.2.3. Initial contents of the Registry . . . . . . . . . . 12 67 6.3. Create a new IANA Registry: IETF SID Range Registry 68 (managed by IANA) . . . . . . . . . . . . . . . . . . . . 12 69 6.3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 12 70 6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 13 71 6.3.3. Initial contents of the registry . . . . . . . . . . 14 72 6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 15 73 6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16 74 6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 16 75 6.4.3. Recursive Allocation of SID Range at Document 76 Adoption . . . . . . . . . . . . . . . . . . . . . . 16 77 6.4.4. Initial contents of the registry . . . . . . . . . . 18 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 8.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 20 83 Appendix B. SID auto generation . . . . . . . . . . . . . . . . 29 84 Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 30 85 C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 30 86 C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 32 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 89 1. Introduction 91 Some of the items defined in YANG [RFC7950] require the use of a 92 unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040], 93 these identifiers are implemented using names. To allow the 94 implementation of data models defined in YANG in constrained devices 95 and constrained networks, a more compact method to identify YANG 96 items is required. This compact identifier, called SID, is encoded 97 using a 63-bit unsigned integer. The limitation to 63-bit unsigned 98 integers allows SIDs to be manipulated more easily on platforms that 99 might otherwise lack native 64-bit unsigned arithmetic. The loss of 100 a single bit of range is not significant given the size of the 101 remaining space. 103 The following items are identified using SIDs: 105 o identities 107 o data nodes (Note: including those parts of a YANG template as 108 defined by the 'yang-data' extension.) 110 o RPCs and associated input(s) and output(s) 112 o actions and associated input(s) and output(s) 114 o notifications and associated information 116 o YANG modules, submodules and features 118 SIDs are globally unique integers, a registration system is used in 119 order to guarantee their uniqueness. SIDs are registered in blocks 120 called "SID ranges". 122 Assignment of SIDs to YANG items can be automated. For more details 123 how this could be achieved, please consult Appendix B. 125 SIDs are assigned permanently, items introduced by a new revision of 126 a YANG module are added to the list of SIDs already assigned. 128 Section 3 provides more details about the registration process of 129 YANG modules and associated SIDs. To enable the implementation of 130 this registry, Section 4 defines a standard file format used to store 131 and publish SIDs. 133 2. Terminology and Notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 The following terms are defined in [RFC7950]: 143 o action 144 o feature 146 o module 148 o notification 150 o RPC 152 o schema node 154 o schema tree 156 o submodule 158 The following term is defined in [RFC8040]: 160 o yang-data extension 162 This specification also makes use of the following terminology: 164 o item: A schema node, an identity, a module, a submodule or a 165 feature defined using the YANG modeling language. 167 o path: A path is a string that identifies a schema node within the 168 schema tree. A path consists of the list of schema node 169 identifier(s) separated by slashes ("/"). Schema node 170 identifier(s) are always listed from the top-level schema node up 171 to the targeted schema node. (e.g. "/ietf-system:system- 172 state/clock/current-datetime") 174 o YANG Schema Item iDentifier (SID): Unsigned integer used to 175 identify different YANG items. 177 3. ".sid" file lifecycle 179 YANG is a language designed to model data accessed using one of the 180 compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and 181 CoRECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of 182 data, including configuration, state data, RPCs, actions and 183 notifications. 185 Many YANG modules are not created in the context of constrained 186 applications. YANG modules can be implemented using NETCONF 187 [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs. 189 As needed, authors of YANG modules can assign SIDs to their YANG 190 modules. In order to do that, they should first obtain a SID range 191 from a registry and use that range to assign or generate SIDs to 192 items of their YANG module. The assignments can then be stored in a 193 ".sid" file. For example how this could be achieved, please refer to 194 Appendix C. 196 Registration of the ".sid" file associated to a YANG module is 197 optional but recommended to promote interoperability between devices 198 and to avoid duplicate allocation of SIDs to a single YANG module. 199 Different registries might have different requirements for the 200 registration and publication of the ".sid" files. For diagram of one 201 of the possibilities, please refer to the activity diagram on 202 Figure 1 in Appendix C. 204 Each time a YANG module or one of its imported module(s) or included 205 sub-module(s) is updated, a new ".sid" file MAY need to be created. 206 All the SIDs present in the previous version of the ".sid" file MUST 207 be present in the new version as well. The creation of this new 208 version of the ".sid" file SHOULD be performed using an automated 209 tool. 211 If a new revision requires more SIDs than initially allocated, a new 212 SID range MUST be added to the 'assignment-ranges' as defined in 213 Section 4. These extra SIDs are used for subsequent assignments. 215 For an example of this update process, see activity diagram Figure 2 216 in Appendix C. 218 4. ".sid" file format 220 ".sid" files are used to persist and publish SIDs assigned to the 221 different YANG items of a specific YANG module. The following YANG 222 module defined the structure of this file, encoding is performed 223 using the rules defined in [RFC7951]. 225 file "ietf-sid-file@2020-02-05.yang" 226 module ietf-sid-file { 227 namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; 228 prefix sid; 230 import ietf-yang-types { 231 prefix yang; 232 } 234 organization 235 "IETF Core Working Group"; 237 contact 238 "Michel Veillette 239 240 Andy Bierman 241 243 Alexander Pelov 244 "; 246 description 247 "Copyright (c) 2016 IETF Trust and the persons identified as 248 authors of the code. All rights reserved. 250 Redistribution and use in source and binary forms, with or 251 without modification, is permitted pursuant to, and subject to 252 the license terms contained in, the Simplified BSD License set 253 forth in Section 4.c of the IETF Trust's Legal Provisions 254 Relating to IETF Documents 255 (https://trustee.ietf.org/license-info). 257 This version of this YANG module is part of RFC XXXX 258 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 259 for full legal notices. 261 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 262 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 263 'MAY', and 'OPTIONAL' in this document are to be interpreted as 264 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 265 they appear in all capitals, as shown here. 267 This module defines the structure of the .sid files. 269 Each .sid file contains the mapping between the different 270 string identifiers defined by a YANG module and a 271 corresponding numeric value called SID."; 273 revision 2020-02-05 { 274 description 275 "Initial revision."; 276 reference 277 "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; 278 } 280 typedef revision-identifier { 281 type string { 282 pattern '\d{4}-\d{2}-\d{2}'; 283 } 284 description 285 "Represents a date in YYYY-MM-DD format."; 286 } 287 typedef sid-file-version-identifier { 288 type uint64; 289 description 290 "Optional attribute that gives information about the .sid file 291 version."; 292 } 294 typedef sid { 295 type uint64; 296 description 297 "YANG Schema Item iDentifier"; 298 reference 299 "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; 300 } 302 typedef schema-node-path { 303 type string { 304 pattern 305 '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' + 306 '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*'; 307 } 308 description 309 "Identifies a schema-node path string for use in the 310 SID registry. This string format follows the rules 311 for an instance-identifier, as defined in RFC 7959, 312 except that no predicates are allowed. 314 This format is intended to support the YANG 1.1 ABNF 315 for a schema node identifier, except module names 316 are used instead of prefixes, as specified in RFC 7951."; 317 reference 318 "RFC 7950, The YANG 1.1 Data Modeling Language; 319 Section 6.5: Schema Node Identifier; 320 RFC 7951, JSON Encoding of YANG Data; 321 Section 6.11: The instance-identifier type"; 322 } 324 leaf module-name { 325 type yang:yang-identifier; 326 description 327 "Name of the YANG module associated with this .sid file."; 328 } 330 leaf module-revision { 331 type revision-identifier; 332 description 333 "Revision of the YANG module associated with this .sid file. 334 This leaf is not present if no revision statement is 335 defined in the YANG module."; 336 } 338 leaf sid-file-version { 339 type sid-file-version-identifier; 340 description 341 "The version number of the .sid file. .sid files and the version 342 sequence are specific to a given YANG module revision. 343 This number starts at zero when there is a YANG module update. 344 This number can distinguish updates to the SID file which are the result of 345 new processing, or the result of reported errata."; 346 } 348 list dependencies-revisions { 349 key "module-name"; 351 description 352 "Information about the revision of each YANG module that the module in 353 'module-name' includes used during the .sid file generation."; 355 leaf module-name { 356 type yang:yang-identifier; 357 mandatory true; 358 description 359 "Name of the YANG module, dependency of 'module-name', for which 360 revision information is provided."; 361 } 362 leaf module-revision { 363 type revision-identifier; 364 mandatory true; 365 description 366 "Revision of the YANG module, dependency of 'module-name', for which 367 revision information is provided."; 368 } 369 } 371 list assigment-ranges { 372 key "entry-point"; 373 description 374 "SID range(s) allocated to the YANG module identified by 375 'module-name' and 'module-revision'."; 377 leaf entry-point { 378 type sid; 379 mandatory true; 380 description 381 "Lowest SID available for assignment."; 382 } 383 leaf size { 384 type uint64; 385 mandatory true; 386 description 387 "Number of SIDs available for assignment."; 388 } 389 } 391 list items { 392 key "namespace identifier"; 393 description 394 "Each entry within this list defined the mapping between 395 a YANG item string identifier and a SID. This list MUST 396 include a mapping entry for each YANG item defined by 397 the YANG module identified by 'module-name' and 398 'module-revision'."; 400 leaf namespace { 401 type enumeration { 402 enum module { 403 value 0; 404 description 405 "All module and submodule names share the same 406 global module identifier namespace."; 407 } 408 enum identity { 409 value 1; 410 description 411 "All identity names defined in a module and its 412 submodules share the same identity identifier 413 namespace."; 414 } 415 enum feature { 416 value 2; 417 description 418 "All feature names defined in a module and its 419 submodules share the same feature identifier 420 namespace."; 421 } 422 enum data { 423 value 3; 424 description 425 "The namespace for all data nodes, as defined in YANG."; 426 } 427 } 428 description 429 "Namespace of the YANG item for this mapping entry."; 430 } 431 leaf identifier { 432 type union { 433 type yang:yang-identifier; 434 type schema-node-path; 435 } 436 description 437 "String identifier of the YANG item for this mapping entry. 439 If the corresponding 'namespace' field is 'module', 440 'feature', or 'identity', then this field MUST 441 contain a valid YANG identifier string. 443 If the corresponding 'namespace' field is 'data', 444 then this field MUST contain a valid schema node 445 path."; 446 } 448 leaf sid { 449 type sid; 450 mandatory true; 451 description 452 "SID assigned to the YANG item for this mapping entry."; 453 } 454 } 455 } 456 458 5. Security Considerations 460 This document defines a new type of identifier used to encode data 461 models defined in YANG [RFC7950]. As such, this identifier does not 462 contribute to any new security issues in addition of those identified 463 for the specific protocols or contexts for which it is used. 465 6. IANA Considerations 467 6.1. Register SID File Format Module 469 This document registers one YANG module in the "YANG Module Names" 470 registry [RFC6020]: 472 o name: ietf-sid-file 474 o namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file 476 o prefix: sid 478 o reference: [[THISRFC]] 480 6.2. Create new IANA Registry: "SID Mega-Range" registry 482 The name of this registry is "SID Mega-Range". This registry is used 483 to record the delegation of the management of a block of SIDs to 484 third parties (such as SDOs or registrars). 486 6.2.1. Structure 488 Each entry in this registry must include: 490 o The entry point (first SID) of the registered SID block. 492 o The size of the registered SID block. The size MUST be one 493 million (1 000 000) SIDs. 495 o The contact information of the requesting organization including: 497 * The policy of SID range allocations: Public, Private or Both. 499 * Organization name 501 * URL 503 The information associated to the Organization name should not be 504 publicly visible in the registry, but should be available. This 505 information includes contact email and phone number and change 506 controller email and phone number. 508 6.2.2. Allocation policy 510 The IANA policy for future additions to this registry is "Expert 511 Review" [RFC8126]. 513 An organization requesting to manage a SID Range (and thus have an 514 entry in the SID Mega-Range Registry), must ensure the following 515 capacities: 517 o The capacity to manage and operate a SID Range Registry. A SID 518 Range Registry MUST provide the following information for all SID 519 Ranges allocated by the Registry: 521 * Entry Point of allocated SID Range 523 * Size of allocated SID Range 525 * Type: Public or Private 526 + Public Ranges MUST include at least a reference to the YANG 527 module and ".sid" files for that SID Range. 529 + Private Ranges MUST be marked as "Private" 531 o A Policy of allocation, which clearly identifies if the SID Range 532 allocations would be Private, Public or Both. 534 o Technical capacity to ensure the sustained operation of the 535 registry for a period of at least 5 years. If Private 536 Registrations are allowed, the period must be of at least 10 537 years. 539 6.2.2.1. First allocation 541 For a first allocation to be provided, the requesting organization 542 must demonstrate a functional registry infrastructure. 544 6.2.2.2. Consecutive allocations 546 On subsequent allocation request(s), the organization must 547 demonstrate the exhaustion of the prior range. These conditions need 548 to be asserted by the assigned expert(s). 550 If that extra-allocation is done within 3 years from the last 551 allocation, the experts need to discuss this request on the CORE 552 working group mailing list and consensus needs to be obtained before 553 allocating a new Mega-Range. 555 6.2.3. Initial contents of the Registry 557 The initial entry in this registry is allocated to IANA: 559 +-------------+---------+------------+-------------------+----------+ 560 | Entry Point | Size | Allocation | Organization name | URL | 561 +-------------+---------+------------+-------------------+----------+ 562 | 0 | 1000000 | Public | IANA | iana.org | 563 +-------------+---------+------------+-------------------+----------+ 565 6.3. Create a new IANA Registry: IETF SID Range Registry (managed by 566 IANA) 568 6.3.1. Structure 570 Each entry in this registry must include: 572 o The SID range entry point. 574 o The SID range size. 576 o The YANG module name. 578 o Document reference. 580 6.3.2. Allocation policy 582 The first million SIDs assigned to IANA is sub-divided as follows: 584 o The range of 0 to 999 (size 1000) is "Reserved" as defined in 585 [RFC8126]. 587 o The range of 1000 to 59,999 (size 59,000) is reserved for YANG 588 modules defined in RFCs. The IANA policy for additions to this 589 registry is "Expert Review" [RFC8126]. 591 * The Expert MUST verify that the YANG module for which this 592 allocation is made has an RFC (existing RFC) OR is on track to 593 become RFC (early allocation with a request from the WG chairs 594 as defined by [RFC7120]). 596 o The SID range allocated for a YANG module can follow in one of the 597 four categories: 599 * SMALL (50 SIDs) 601 * MEDIUM (100 SIDs) 603 * LARGE (250 SIDs) 605 * CUSTOM (requested by the YANG module author, with a maximum of 606 1000 SIDs). In all cases, the size of a SID range assigned to 607 a YANG module should be at least 33% above the current number 608 of YANG items. This headroom allows assignment within the same 609 range of new YANG items introduced by subsequent revisions. A 610 larger SID range size may be requested by the authors if this 611 recommendation is considered insufficient. It is important to 612 note that an additional SID range can be allocated to an 613 existing YANG module if the initial range is exhausted. 615 o The range of 60,000 to 99,999 (size 40,000)is reserved for 616 experimental YANG modules. This range MUST NOT be used in 617 operational deployments since these SIDs are not globally unique 618 which limit their interoperability. The IANA policy for this 619 range is "Experimental use" [RFC8126]. 621 o The range of 100,000 to 999,999 (size 900,000) is "Reserved" as 622 defined in [RFC8126]. 624 +-------------+---------+------------------+ 625 | Entry Point | Size | IANA policy | 626 +-------------+---------+------------------+ 627 | 0 | 1,000 | Reserved | 628 | 1,000 | 59,000 | Expert Review | 629 | 60,000 | 40,000 | Experimental use | 630 | 100,000 | 900,000 | Reserved | 631 +-------------+---------+------------------+ 633 6.3.3. Initial contents of the registry 635 Initial entries in this registry are as follows: 637 +-----+-----+--------------------------+----------------------------+ 638 | Ent | Siz | Module name | Document reference | 639 | ry | e | | | 640 | Poi | | | | 641 | nt | | | | 642 +-----+-----+--------------------------+----------------------------+ 643 | 100 | 100 | ietf-comi | [I-D.ietf-core-comi] | 644 | 0 | | | | 645 | 110 | 50 | ietf-yang-types | [RFC6991] | 646 | 0 | | | | 647 | 115 | 50 | ietf-inet-types | [RFC6991] | 648 | 0 | | | | 649 | 120 | 50 | iana-crypt-hash | [RFC7317] | 650 | 0 | | | | 651 | 125 | 50 | ietf-netconf-acm | [RFC8341] | 652 | 0 | | | | 653 | 130 | 50 | ietf-sid-file | RFCXXXX | 654 | 0 | | | | 655 | 150 | 100 | ietf-interfaces | [RFC8343] | 656 | 0 | | | | 657 | 160 | 100 | ietf-ip | [RFC8344] | 658 | 0 | | | | 659 | 170 | 100 | ietf-system | [RFC7317] | 660 | 0 | | | | 661 | 180 | 400 | iana-if-type | [RFC7224] | 662 | 0 | | | | 663 | 240 | 50 | ietf-voucher | [RFC8366] | 664 | 0 | | | | 665 | 245 | 50 | ietf-constrained-voucher | [I-D.ietf-anima-constraine | 666 | 0 | | | d-voucher] | 667 | 250 | 50 | ietf-constrained- | [I-D.ietf-anima-constraine | 668 | 0 | | voucher-request | d-voucher] | 669 +-----+-----+--------------------------+----------------------------+ 671 // RFC Ed.: replace XXXX with RFC number assigned to this draft. 673 For allocation, RFC publication of the YANG module is required as per 674 [RFC8126]. The YANG module must be registered in the "YANG module 675 Name" registry according to the rules specified in section 14 of 676 [RFC6020]. 678 6.4. Create new IANA Registry: "IETF SID Registry" 680 The name of this registry is "IETF SID Registry". This registry is 681 used to record the allocation of SIDs for individual YANG module 682 items. 684 6.4.1. Structure 686 Each entry in this registry must include: 688 o The YANG module name. This module name must be present in the 689 "Name" column of the "YANG Module Names" registry. 691 o A link to the associated ".yang" file. This file link must be 692 present in the "File" column of the "YANG Module Names" registry. 694 o The link to the ".sid" file which defines the allocation. The 695 ".sid" file is stored by IANA. 697 o The number of actually allocated SIDs in the ".sid" file. 699 6.4.2. Allocation policy 701 The allocation policy is Expert review. The Expert MUST ensure that 702 the following conditions are met: 704 o The ".sid" file has a valid structure: 706 * The ".sid" file MUST be a valid JSON file following the 707 structure of the module defined in RFCXXXX (RFC Ed: replace XXX 708 with RFC number assigned to this draft). 710 o The ".sid" file allocates individual SIDs ONLY in the SID Ranges 711 for this YANG module (as allocated in the IETF SID Range 712 Registry): 714 * All SIDs in this ".sid" file MUST be within the ranges 715 allocated to this YANG module in the "IETF SID Range Registry". 717 o If another ".sid" file has already allocated SIDs for this YANG 718 module (e.g. for older or newer versions of the YANG module), the 719 YANG items are assigned the same SIDs as in the other ".sid" file. 721 o If there is an older version of the ".sid" file, all allocated 722 SIDs from that version are still present in the current version of 723 the ".sid" file. 725 o SIDs never change. 727 6.4.3. Recursive Allocation of SID Range at Document Adoption 729 Due to the difficulty in changing SID values during IETF document 730 processing, it is expected that most documents will ask for SID 731 allocations using Early Allocations [RFC7120]. The details of the 732 Early Allocation should be included in any Working Group Adoption 733 call. Prior to Working Group Adoption, an internet draft authors can 734 use the experimental SID range (as per Section 6.3.2) for their SIDs 735 allocations or other values that do not create ambiguity with other 736 SID uses (for example they can use a range that comes from a non-IANA 737 managed "SID Mega-Range" registry). 739 After Working Group Adoption, any modification of a ".sid" file is 740 expected to be discussed on the mailing list of the appropriate 741 Working Groups. Specific attention should be paid to implementers' 742 opinion after Working Group Last Call if a SID value is to change its 743 meaning. In all cases, a ".sid" file and the SIDs associated with it 744 are subject to change before the publication of an internet draft as 745 an RFC. 747 During the early use of SIDs, many existing, previously published 748 YANG modules will not have SID allocations. For an allocation to be 749 useful the included YANG modules may also need to have SID 750 allocations made. 752 The Expert Reviewer who performs the (Early) Allocation analysis will 753 need to go through the list of included YANG modules and perform SID 754 allocations for those modules as well. 756 o If the document is a published RFC, then the allocation of SIDs 757 for its referenced YANG modules is permanent. The Expert Reviewer 758 provides the generated SID file to IANA for registration. This 759 process may be time consuming during a bootstrap period (there are 760 over 100 YANG modules to date, none of which have SID 761 allocations), but should quiet down once needed entries are 762 allocated. 764 o If the document is an unprocessed Internet-Draft adopted in a WG, 765 then an Early Allocation is performed for this document as well. 766 Early Allocations require approval by an IESG Area Director. An 767 early allocation which requires additional allocations will list 768 the other allocations in it's description, and will be cross- 769 posted to the any other working group mailing lists. 771 o A YANG module which references a module in an document which has 772 not yet been adopted by any working group will be unable to 773 perform an Early Allocation for that other document until it is 774 adopted by a working group. As described in [RFC7120], an AD 775 Sponsored document acts as if it had a working group. The 776 approving AD may also exempt a document from this policy by 777 agreeing to AD Sponsor the document. 779 Critically, the original document should never get through the IETF 780 process and then be surprised to be referencing a document whose 781 progress is not certain. 783 A previously SID-allocated YANG module which changes its references 784 to include a YANG module for which there is no SID allocation needs 785 to repeat the Early Allocation process. 787 Early Allocations are made with a one-year period, after which they 788 are expired. [RFC7120] indicates that at most one renewal may be 789 made. For the SID allocation a far more lenient stance is desired. 791 1. An extension of a referencing documents Early Allocation should 792 update any referenced Early Allocations to expire no sooner than 793 the referencing document. 795 2. The [RFC7120] mechanism allows the IESG to provide a second 796 renewal, and such an event may prompt some thought about how the 797 collection of documents are being processed. 799 This is driven by the very generous size of the SID space and the 800 often complex and deep dependencies of YANG modules. Often a core 801 module with many dependencies will undergo extensive review, delaying 802 the publication of other documents. 804 [RFC7120] also says 806 Note that if a document is submitted for review to the IESG and at 807 the time of submission some early allocations are valid (not 808 expired), these allocations should not be expired while the document 809 is under IESG consideration or waiting in the RFC Editor's queue 810 after approval by the IESG. 812 6.4.4. Initial contents of the registry 814 None. 816 7. Acknowledgments 818 The authors would like to thank Andy Bierman, Carsten Bormann, 819 Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent 820 Toutain and Randy Turner for their help during the development of 821 this document and their useful comments during the review process. 823 8. References 825 8.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 833 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 834 2014, . 836 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 837 RFC 7950, DOI 10.17487/RFC7950, August 2016, 838 . 840 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 841 RFC 7951, DOI 10.17487/RFC7951, August 2016, 842 . 844 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 845 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 846 May 2017, . 848 8.2. Informative References 850 [I-D.ietf-anima-constrained-voucher] 851 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 852 Voucher Artifacts for Bootstrapping Protocols", draft- 853 ietf-anima-constrained-voucher-07 (work in progress), 854 January 2020. 856 [I-D.ietf-core-comi] 857 Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. 858 Petrov, "CoAP Management Interface", draft-ietf-core- 859 comi-08 (work in progress), September 2019. 861 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 862 the Network Configuration Protocol (NETCONF)", RFC 6020, 863 DOI 10.17487/RFC6020, October 2010, 864 . 866 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 867 and A. Bierman, Ed., "Network Configuration Protocol 868 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 869 . 871 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 872 RFC 6991, DOI 10.17487/RFC6991, July 2013, 873 . 875 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 876 RFC 7224, DOI 10.17487/RFC7224, May 2014, 877 . 879 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 880 System Management", RFC 7317, DOI 10.17487/RFC7317, August 881 2014, . 883 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 884 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 885 . 887 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 888 Writing an IANA Considerations Section in RFCs", BCP 26, 889 RFC 8126, DOI 10.17487/RFC8126, June 2017, 890 . 892 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 893 Access Control Model", STD 91, RFC 8341, 894 DOI 10.17487/RFC8341, March 2018, 895 . 897 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 898 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 899 . 901 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 902 RFC 8344, DOI 10.17487/RFC8344, March 2018, 903 . 905 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 906 "A Voucher Artifact for Bootstrapping Protocols", 907 RFC 8366, DOI 10.17487/RFC8366, May 2018, 908 . 910 Appendix A. ".sid" file example 912 The following ".sid" file (ietf-system@2014-08-06.sid) have been 913 generated using the following yang modules: 915 o ietf-system@2014-08-06.yang 917 o ietf-yang-types@2013-07-15.yang 918 o ietf-inet-types@2013-07-15.yang 920 o ietf-netconf-acm@2012-02-22.yang 922 o iana-crypt-hash@2014-04-04.yang 924 { 925 "assignment-ranges": [ 926 { 927 "entry-point": 1700, 928 "size": 100 929 } 930 ], 931 "module-name": "ietf-system", 932 "module-revision": "2014-08-06", 933 "items": [ 934 { 935 "namespace": "module", 936 "identifier": "ietf-system", 937 "sid": 1700 938 }, 939 { 940 "namespace": "identity", 941 "identifier": "authentication-method", 942 "sid": 1701 943 }, 944 { 945 "namespace": "identity", 946 "identifier": "local-users", 947 "sid": 1702 948 }, 949 { 950 "namespace": "identity", 951 "identifier": "radius", 952 "sid": 1703 953 }, 954 { 955 "namespace": "identity", 956 "identifier": "radius-authentication-type", 957 "sid": 1704 958 }, 959 { 960 "namespace": "identity", 961 "identifier": "radius-chap", 962 "sid": 1705 963 }, 964 { 965 "namespace": "identity", 966 "identifier": "radius-pap", 967 "sid": 1706 968 }, 969 { 970 "namespace": "feature", 971 "identifier": "authentication", 972 "sid": 1707 973 }, 974 { 975 "namespace": "feature", 976 "identifier": "dns-udp-tcp-port", 977 "sid": 1708 978 }, 979 { 980 "namespace": "feature", 981 "identifier": "local-users", 982 "sid": 1709 983 }, 984 { 985 "namespace": "feature", 986 "identifier": "ntp", 987 "sid": 1710 988 }, 989 { 990 "namespace": "feature", 991 "identifier": "ntp-udp-port", 992 "sid": 1711 993 }, 994 { 995 "namespace": "feature", 996 "identifier": "radius", 997 "sid": 1712 998 }, 999 { 1000 "namespace": "feature", 1001 "identifier": "radius-authentication", 1002 "sid": 1713 1003 }, 1004 { 1005 "namespace": "feature", 1006 "identifier": "timezone-name", 1007 "sid": 1714 1008 }, 1009 { 1010 "namespace": "data", 1011 "identifier": "/ietf-system:set-current-datetime", 1012 "sid": 1715 1013 }, 1014 { 1015 "namespace": "data", 1016 "identifier": "/ietf-system:set-current-datetime/ 1017 current-datetime", 1018 "sid": 1716 1019 }, 1020 { 1021 "namespace": "data", 1022 "identifier": "/ietf-system:system", 1023 "sid": 1717 1024 }, 1025 { 1026 "namespace": "data", 1027 "identifier": "/ietf-system:system-restart", 1028 "sid": 1718 1029 }, 1030 { 1031 "namespace": "data", 1032 "identifier": "/ietf-system:system-shutdown", 1033 "sid": 1719 1034 }, 1035 { 1036 "namespace": "data", 1037 "identifier": "/ietf-system:system-state", 1038 "sid": 1720 1039 }, 1040 { 1041 "namespace": "data", 1042 "identifier": "/ietf-system:system-state/clock", 1043 "sid": 1721 1044 }, 1045 { 1046 "namespace": "data", 1047 "identifier": "/ietf-system:system-state/clock/boot-datetime", 1048 "sid": 1722 1049 }, 1050 { 1051 "namespace": "data", 1052 "identifier": "/ietf-system:system-state/clock/ 1053 current-datetime", 1054 "sid": 1723 1055 }, 1056 { 1057 "namespace": "data", 1058 "identifier": "/ietf-system:system-state/platform", 1059 "sid": 1724 1060 }, 1061 { 1062 "namespace": "data", 1063 "identifier": "/ietf-system:system-state/platform/machine", 1064 "sid": 1725 1065 }, 1066 { 1067 "namespace": "data", 1068 "identifier": "/ietf-system:system-state/platform/os-name", 1069 "sid": 1726 1070 }, 1071 { 1072 "namespace": "data", 1073 "identifier": "/ietf-system:system-state/platform/os-release", 1074 "sid": 1727 1075 }, 1076 { 1077 "namespace": "data", 1078 "identifier": "/ietf-system:system-state/platform/os-version", 1079 "sid": 1728 1080 }, 1081 { 1082 "namespace": "data", 1083 "identifier": "/ietf-system:system/authentication", 1084 "sid": 1729 1085 }, 1086 { 1087 "namespace": "data", 1088 "identifier": "/ietf-system:system/authentication/user", 1089 "sid": 1730 1090 }, 1091 { 1092 "namespace": "data", 1093 "identifier": "/ietf-system:system/authentication/ 1094 user-authentication-order", 1095 "sid": 1731 1096 }, 1097 { 1098 "namespace": "data", 1099 "identifier": "/ietf-system:system/authentication/user/ 1100 authorized-key", 1101 "sid": 1732 1102 }, 1103 { 1104 "namespace": "data", 1105 "identifier": "/ietf-system:system/authentication/user/ 1106 authorized-key/algorithm", 1107 "sid": 1733 1108 }, 1109 { 1110 "namespace": "data", 1111 "identifier": "/ietf-system:system/authentication/user/ 1112 authorized-key/key-data", 1113 "sid": 1734 1114 }, 1115 { 1116 "namespace": "data", 1117 "identifier": "/ietf-system:system/authentication/user/ 1118 authorized-key/name", 1119 "sid": 1735 1120 }, 1121 { 1122 "namespace": "data", 1123 "identifier": "/ietf-system:system/authentication/user/ 1124 name", 1125 "sid": 1736 1126 }, 1127 { 1128 "namespace": "data", 1129 "identifier": "/ietf-system:system/authentication/user/ 1130 password", 1131 "sid": 1737 1132 }, 1133 { 1134 "namespace": "data", 1135 "identifier": "/ietf-system:system/clock", 1136 "sid": 1738 1137 }, 1138 { 1139 "namespace": "data", 1140 "identifier": "/ietf-system:system/clock/timezone-name", 1141 "sid": 1739 1142 }, 1143 { 1144 "namespace": "data", 1145 "identifier": "/ietf-system:system/clock/timezone-utc-offset", 1146 "sid": 1740 1147 }, 1148 { 1149 "namespace": "data", 1150 "identifier": "/ietf-system:system/contact", 1151 "sid": 1741 1152 }, 1153 { 1154 "namespace": "data", 1155 "identifier": "/ietf-system:system/dns-resolver", 1156 "sid": 1742 1157 }, 1158 { 1159 "namespace": "data", 1160 "identifier": "/ietf-system:system/dns-resolver/options", 1161 "sid": 1743 1162 }, 1163 { 1164 "namespace": "data", 1165 "identifier": "/ietf-system:system/dns-resolver/options/ 1166 attempts", 1167 "sid": 1744 1168 }, 1169 { 1170 "namespace": "data", 1171 "identifier": "/ietf-system:system/dns-resolver/options/ 1172 timeout", 1173 "sid": 1745 1174 }, 1175 { 1176 "namespace": "data", 1177 "identifier": "/ietf-system:system/dns-resolver/search", 1178 "sid": 1746 1179 }, 1180 { 1181 "namespace": "data", 1182 "identifier": "/ietf-system:system/dns-resolver/server", 1183 "sid": 1747 1184 }, 1185 { 1186 "namespace": "data", 1187 "identifier": "/ietf-system:system/dns-resolver/server/name", 1188 "sid": 1748 1189 }, 1190 { 1191 "namespace": "data", 1192 "identifier": "/ietf-system:system/dns-resolver/server/ 1193 udp-and-tcp", 1194 "sid": 1749 1195 }, 1196 { 1197 "namespace": "data", 1198 "identifier": "/ietf-system:system/dns-resolver/server/ 1199 udp-and-tcp/address", 1200 "sid": 1750 1201 }, 1202 { 1203 "namespace": "data", 1204 "identifier": "/ietf-system:system/dns-resolver/server/ 1205 udp-and-tcp/port", 1207 "sid": 1751 1208 }, 1209 { 1210 "namespace": "data", 1211 "identifier": "/ietf-system:system/hostname", 1212 "sid": 1752 1213 }, 1214 { 1215 "namespace": "data", 1216 "identifier": "/ietf-system:system/location", 1217 "sid": 1753 1218 }, 1219 { 1220 "namespace": "data", 1221 "identifier": "/ietf-system:system/ntp", 1222 "sid": 1754 1223 }, 1224 { 1225 "namespace": "data", 1226 "identifier": "/ietf-system:system/ntp/enabled", 1227 "sid": 1755 1228 }, 1229 { 1230 "namespace": "data", 1231 "identifier": "/ietf-system:system/ntp/server", 1232 "sid": 1756 1233 }, 1234 { 1235 "namespace": "data", 1236 "identifier": "/ietf-system:system/ntp/server/ 1237 association-type", 1238 "sid": 1757 1239 }, 1240 { 1241 "namespace": "data", 1242 "identifier": "/ietf-system:system/ntp/server/iburst", 1243 "sid": 1758 1244 }, 1245 { 1246 "namespace": "data", 1247 "identifier": "/ietf-system:system/ntp/server/name", 1248 "sid": 1759 1249 }, 1250 { 1251 "namespace": "data", 1252 "identifier": "/ietf-system:system/ntp/server/prefer", 1253 "sid": 1760 1254 }, 1255 { 1256 "namespace": "data", 1257 "identifier": "/ietf-system:system/ntp/server/udp", 1258 "sid": 1761 1259 }, 1260 { 1261 "namespace": "data", 1262 "identifier": "/ietf-system:system/ntp/server/udp/address", 1263 "sid": 1762 1264 }, 1265 { 1266 "namespace": "data", 1267 "identifier": "/ietf-system:system/ntp/server/udp/port", 1268 "sid": 1763 1269 }, 1270 { 1271 "namespace": "data", 1272 "identifier": "/ietf-system:system/radius", 1273 "sid": 1764 1274 }, 1275 { 1276 "namespace": "data", 1277 "identifier": "/ietf-system:system/radius/options", 1278 "sid": 1765 1279 }, 1280 { 1281 "namespace": "data", 1282 "identifier": "/ietf-system:system/radius/options/attempts", 1283 "sid": 1766 1284 }, 1285 { 1286 "namespace": "data", 1287 "identifier": "/ietf-system:system/radius/options/timeout", 1288 "sid": 1767 1289 }, 1290 { 1291 "namespace": "data", 1292 "identifier": "/ietf-system:system/radius/server", 1293 "sid": 1768 1294 }, 1295 { 1296 "namespace": "data", 1297 "identifier": "/ietf-system:system/radius/server/ 1298 authentication-type", 1299 "sid": 1769 1300 }, 1301 { 1302 "namespace": "data", 1303 "identifier": "/ietf-system:system/radius/server/name", 1304 "sid": 1770 1305 }, 1306 { 1307 "namespace": "data", 1308 "identifier": "/ietf-system:system/radius/server/udp", 1309 "sid": 1771 1310 }, 1311 { 1312 "namespace": "data", 1313 "identifier": "/ietf-system:system/radius/server/udp/ 1314 address", 1315 "sid": 1772 1316 }, 1317 { 1318 "namespace": "data", 1319 "identifier": "/ietf-system:system/radius/server/udp/ 1320 authentication-port", 1321 "sid": 1773 1322 }, 1323 { 1324 "namespace": "data", 1325 "identifier": "/ietf-system:system/radius/server/udp/ 1326 shared-secret", 1327 "sid": 1774 1328 } 1329 ] 1330 } 1332 Appendix B. SID auto generation 1334 Assignment of SIDs to YANG items can be automated, the recommended 1335 process to assign SIDs is as follows: 1337 1. A tool extracts the different items defined for a specific YANG 1338 module. 1340 2. The list of items is sorted in alphabetical order, 'namespace' in 1341 descending order, 'identifier' in ascending order. The 1342 'namespace' and 'identifier' formats are described in the YANG 1343 module 'ietf-sid-file' defined in Section 4. 1345 3. SIDs are assigned sequentially from the entry point up to the 1346 size of the registered SID range. This approach is recommended 1347 to minimize the serialization overhead, especially when delta 1348 between a reference SID and the current SID is used by protocols 1349 aiming to reduce message size. 1351 4. If the number of items exceeds the SID range(s) allocated to a 1352 YANG module, an extra range is added for subsequent assignments. 1354 5. The "dependencies-revisions" should reflect the revision numbers 1355 of each YANG module that the YANG module imports at the moment of 1356 the generation. 1358 In case of an update to an existing ".sid" file, an additional step 1359 is needed that increments the ".sid" file version number. If there 1360 was no version number in the previous version of the ".sid" file, 0 1361 is assumed as the version number of the old version of the ".sid" 1362 file and the version number is 1 for the new ".sid" file. Apart from 1363 that, changes of SID files can also be automated using the same 1364 method described above, only unassigned YANG items are processed at 1365 step #3. Already existing items in the SID file should not be given 1366 new SIDs. 1368 Note that ".sid" file versions are specific to a YANG module 1369 revision. For each new YANG module or each new revision of an 1370 existing YANG module, the version number of the initial ".sid" file 1371 should either be 0 or should not be present. 1373 Appendix C. ".sid" file lifecycle 1375 Before assigning SIDs to their YANG modules, YANG module authors must 1376 acquire a SID range from a "SID Range Registry". If the YANG module 1377 is part of an IETF draft or RFC, the SID range need to be acquired 1378 from the "IETF SID Range Registry" as defined in Section 6.3. For 1379 the other YANG modules, the authors can acquire a SID range from any 1380 "SID Range Registry" of their choice. 1382 Once the SID range is acquired, the owner can use it to generate 1383 ".sid" file/s for his YANG module/s. It is recommended to leave some 1384 unallocated SIDs following the allocated range in each ".sid" file in 1385 order to allow better evolution of the YANG module in the future. 1386 Generation of ".sid" files should be performed using an automated 1387 tool. Note that ".sid" files can only be generated for YANG modules 1388 and not for submodules. 1390 C.1. SID File Creation 1392 The following activity diagram summarizes the creation of a YANG 1393 module and its associated ".sid" file. 1395 +---------------+ 1396 O | Creation of a | 1397 -|- ->| YANG module | 1398 / \ +---------------+ 1399 | 1400 V 1401 /-------------\ 1402 / Standardized \ yes 1403 \ YANG module ? /-------------+ 1404 \-------------/ | 1405 | no | 1406 V V 1407 /-------------\ +---------------+ 1408 / Constrained \ yes | SID range | 1409 +-->\ application ? /---->| registration |<----------+ 1410 | \-------------/ +---------------+ | 1411 | | no | | 1412 | V V | 1413 | +---------------+ +---------------+ | 1414 +---| YANG module | | SID sub-range | | 1415 | update | | assignment |<----------+ 1416 +---------------+ +---------------+ | 1417 | | 1418 V | 1419 +---------------+ +-------------+ 1420 | ".sid" file | | Rework YANG | 1421 | generation | | model | 1422 +---------------+ +-------------+ 1423 | ^ 1424 V | 1425 /----------\ yes | 1426 / Work in \ -----------+ 1427 \ progress / 1428 \----------/ 1429 | no 1430 V 1431 /-------------\ /-------------\ 1432 / RFC \ no / Open \ no 1433 \ publication? /---->\ specification?/---+ 1434 \-------------/ \-------------/ | 1435 | yes | yes | 1436 | +---------------+ | 1437 V V V 1438 +---------------+ +---------------+ 1439 | IANA | | Third party | 1440 | registration | | registration | 1441 +-------+-------+ +-------+-------+ 1442 | | 1443 +---------------------------------+ 1444 V 1445 [DONE] 1447 Figure 1: SID Lifecycle 1449 C.2. SID File Update 1451 The following Activity diagram summarizes the update of a YANG module 1452 and its associated ".sid" file. 1454 +---------------+ 1455 O | Update of the | 1456 -|- ->| YANG module | 1457 / \ | or include(s) | 1458 | or import(s) | 1459 +---------------+ 1460 | 1461 V 1462 /-------------\ 1463 / New items \ yes 1464 \ created ? /------+ 1465 \-------------/ | 1466 | no V 1467 | /-------------\ +----------------+ 1468 | / SID range \ yes | Extra sub-range| 1469 | \ exhausted ? /---->| assignment | 1470 | \-------------/ +----------------+ 1471 | | no | 1472 | +---------------------+ 1473 | | 1474 | V 1475 | +---------------+ 1476 | | ".sid" file | 1477 | | update based | 1478 | | on previous | 1479 | | ".sid" file | 1480 | +---------------+ 1481 | | 1482 | V 1483 | /-------------\ +---------------+ 1484 | / Publicly \ yes | YANG module | 1485 | \ available ? /---->| registration | 1486 | \-------------/ +---------------+ 1487 | | no | 1488 +--------------+---------------------+ 1489 | 1490 [DONE] 1492 Figure 2: YANG and SID file update 1494 Authors' Addresses 1496 Michel Veillette (editor) 1497 Trilliant Networks Inc. 1498 610 Rue du Luxembourg 1499 Granby, Quebec J2J 2V2 1500 Canada 1502 Phone: +14503750556 1503 Email: michel.veillette@trilliant.com 1505 Alexander Pelov (editor) 1506 Acklio 1507 1137A avenue des Champs Blancs 1508 Cesson-Sevigne, Bretagne 35510 1509 France 1511 Email: a@ackl.io 1513 Ivaylo Petrov (editor) 1514 Acklio 1515 1137A avenue des Champs Blancs 1516 Cesson-Sevigne, Bretagne 35510 1517 France 1519 Email: ivaylo@ackl.io