idnits 2.17.1 draft-ietf-core-sid-05.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 11 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 -- The document date (December 19, 2018) is 1952 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 322, but not defined ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6021 (Obsoleted by RFC 6991) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 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: June 22, 2019 I. Petrov, Ed. 6 Acklio 7 December 19, 2018 9 YANG Schema Item iDentifier (SID) 10 draft-ietf-core-sid-05 12 Abstract 14 YANG Schema Item iDentifiers (SID) are globally unique 64-bit 15 unsigned numbers 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 June 22, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 7 58 5. Third party registries . . . . . . . . . . . . . . . . . . . 11 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 7.1. Module registration . . . . . . . . . . . . . . . . . . . 12 62 7.2. "SID mega-range" registry . . . . . . . . . . . . . . . . 12 63 7.2.1. "IANA SID Mega-Range" allocation . . . . . . . . . . 13 64 7.2.2. "RFC SID range assignment" sub-registry . . . . . . . 14 65 7.2.3. "Specification SID range assignment" sub-registry . . 14 66 7.3. "YANG module assignment" registry . . . . . . . . . . . . 15 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 70 9.2. Informative References . . . . . . . . . . . . . . . . . 16 71 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 74 1. Introduction 76 Some of the items defined in YANG [RFC7950] require the use of a 77 unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040], 78 these identifiers are implemented using names. To allow the 79 implementation of data models defined in YANG in constrained devices 80 and constrained networks, a more compact method to identify YANG 81 items is required. This compact identifier, called SID, is encoded 82 using a 64-bit unsigned integer. The following items are identified 83 using SIDs: 85 o identities 87 o data nodes (Note: including those part of a YANG template as 88 defined by the 'yang-data' extension.) 90 o RPCs and associated input(s) and output(s) 92 o actions and associated input(s) and output(s) 94 o notifications and associated information 96 o YANG modules, submodules and features 97 To minimize their size, SIDs are often represented as a difference 98 between the current SID and a reference SID. Such difference is 99 called "delta", shorthand for "delta-encoded SID". Conversion from 100 SIDs to deltas and back to SIDs is a stateless process. Each 101 protocol implementing deltas must unambiguously define the reference 102 SID for each YANG item. 104 SIDs are globally unique numbers, a registration system is used in 105 order to guarantee their uniqueness. SIDs are registered in blocks 106 called "SID ranges". 108 Assignment of SIDs to YANG items can be automated, the recommended 109 process to assign SIDs is as follows: 111 1. A tool extracts the different items defined for a specific YANG 112 module. 114 2. The list of items is sorted in alphabetical order, 'namespace' in 115 descending order, 'identifier' in ascending order. The 116 'namespace' and 'identifier' formats are described in the YANG 117 module 'ietf-sid-file' defined in Section 4. 119 3. SIDs are assigned sequentially from the entry point up to the 120 size of the registered SID range. This approach is recommended 121 to minimize the serialization overhead, especially when delta 122 encoding is implemented. 124 4. If the number of items exceeds the SID range(s) allocated to a 125 YANG module, an extra range is added for subsequent assignments. 127 SIDs are assigned permanently, items introduced by a new revision of 128 a YANG module are added to the list of SIDs already assigned. This 129 process can also be automated using the same method described above, 130 only unassigned YANG items are processed at step #3. 132 Section 3 provides more details about the registration process of 133 YANG modules and associated SIDs. To enable the implementation of 134 this registry, Section 4 defines a standard file format used to store 135 and publish SIDs. 137 2. Terminology and Notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The following terms are defined in [RFC7950]: 145 o action 147 o feature 149 o module 151 o notification 153 o RPC 155 o schema node 157 o schema tree 159 o submodule 161 The following term is defined in [RFC8040]: 163 o yang-data extension 165 This specification also makes use of the following terminology: 167 o delta : Difference between the current SID and a reference SID. 168 Each protocol that uses delta encoded SIDs MUST define how the 169 reference SID is obtained. 171 o item: A schema node, an identity, a module, a submodule or a 172 feature defined using the YANG modeling language. 174 o path: A path is a string that identifies a schema node within the 175 schema tree. A path consists of the list of schema node 176 identifier(s) separated by slashes ("/"). Schema node 177 identifier(s) are always listed from the top-level schema node up 178 to the targeted schema node. (e.g. "/ietf-system:system- 179 state/clock/current-datetime") 181 o YANG Schema Item iDentifier (SID): Unsigned integer used to 182 identify different YANG items. 184 3. ".sid" file lifecycle 186 YANG is a language designed to model data accessed using one of the 187 compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and 188 CoMI [I-D.ietf-core-comi]). A YANG module defines hierarchies of 189 data, including configuration, state data, RPCs, actions and 190 notifications. 192 YANG modules are not necessarily created in the context of 193 constrained applications. YANG modules can be implemented using 194 NETCONF [RFC6241] or RESTCONF [RFC8040] without the need to assign 195 SIDs. 197 As needed, authors of YANG modules can assign SIDs to their YANG 198 modules. In order to do that, they should first obtain a SID range 199 from a registry. It could be "RFC SID range assignment" sub-registry 200 as defined in Section Section 7.2.2, the "Specification SID range 201 assignment" sub-registry as defined in Section Section 7.2.3 or 202 another one, depending on the particular case. The minimal 203 information required for this would be a start SID number and a range 204 size, but might include additional details depending on the registry 205 policy, which is outside the scope of this document. Once a SID 206 range is registered, the owner can use it to generate ".sid" file/s 207 for his YANG module/s. It is recommended to leave some unallocated 208 SIDs following the allocated range in each ".sid" file in order to 209 allow better evolution of the YANG module in the future. Generation 210 of ".sid" files SHOULD be performed using an automated tool. Note 211 that ".sid" files can only be generated for YANG modules and not for 212 submodules. 214 Registration of the .sid file associated to a YANG module is optional 215 but recommended to promote interoperability between devices and to 216 avoid duplicate allocation of SIDs to a single YANG module. 217 Different registries might have different requirement for the 218 registration and publication of the ".sid" files. 220 The following activity diagram summarizes the creation of a YANG 221 module and its associated .sid file. 223 +---------------+ 224 O | Creation of a | 225 -|- ->| YANG module | 226 / \ +---------------+ 227 | 228 V 229 /-------------\ 230 / Standardized \ yes 231 \ YANG module ? /-------------+ 232 \-------------/ | 233 | no | 234 V V 235 /-------------\ +---------------+ 236 / Constrained \ yes | SID range | 237 +-->\ application ? /---->| registration |<----------+ 238 | \-------------/ +---------------+ | 239 | | no | | 240 | V V | 241 | +---------------+ +---------------+ | 242 +---| YANG module | | SID sub-range | | 243 | update | | assignment |<----------+ 244 +---------------+ +---------------+ | 245 | | 246 V | 247 +---------------+ +-------------+ 248 | .sid file | | Rework YANG | 249 | generation | | model | 250 +---------------+ +-------------+ 251 | ^ 252 V | 253 /----------\ yes | 254 / Work in \ -----------+ 255 \ progress / 256 \----------/ 257 | no 258 V 259 /-------------\ /-------------\ 260 / RFC \ no / Open \ no 261 \ publication? /---->\ specification?/---+ 262 \-------------/ \-------------/ | 263 | yes | yes | 264 | +---------------+ | 265 V V V 266 +---------------+ +---------------+ 267 | IANA | | Third party | 268 | registration | | registration | 269 +-------+-------+ +-------+-------+ 270 | | 271 +---------------------------------+ 272 V 273 [DONE] 275 Each time a YANG module or one of its imported module(s) or included 276 sub-module(s) is updated, the ".sid" file MAY need to be updated. 277 This update SHOULD also be performed using an automated tool. 279 If a new revision requires more SIDs than initially allocated, a new 280 SID range MUST be added to the 'assignment-ranges' as defined in 281 Section 4. These extra SIDs are used for subsequent assignments. 283 The following activity diagram summarizes the update of a YANG module 284 and its associated .sid file. 286 +---------------+ 287 O | Update of the | 288 -|- ->| YANG module | 289 / \ | or include(s) | 290 | or import(s) | 291 +---------------+ 292 | 293 V 294 /-------------\ 295 / New items \ yes 296 \ created ? /------+ 297 \-------------/ | 298 | no V 299 | /-------------\ +----------------+ 300 | / SID range \ yes | Extra sub-range| 301 | \ exhausted ? /---->| assignment | 302 | \-------------/ +----------------+ 303 | | no | 304 | +---------------------+ 305 | | 306 | V 307 | +---------------+ 308 | | .sid file | 309 | | update based | 310 | | on previous | 311 | | .sid file | 312 | +---------------+ 313 | | 314 | V 315 | /-------------\ +---------------+ 316 | / Publicly \ yes | YANG module | 317 | \ available ? /---->| registration | 318 | \-------------/ +---------------+ 319 | | no | 320 +--------------+---------------------+ 321 | 322 [DONE] 324 4. ".sid" file format 326 ".sid" files are used to persist and publish SIDs assigned to the 327 different YANG items of a specific YANG module. The following YANG 328 module defined the structure of this file, encoding is performed 329 using the rules defined in [RFC7951]. 331 file "ietf-sid-file@2017-11-26.yang" 332 module ietf-sid-file { 333 namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; 334 prefix sid; 336 import ietf-yang-types { 337 prefix yang; 338 } 340 import ietf-comi { 341 prefix comi; 342 } 344 organization 345 "IETF Core Working Group"; 347 contact 348 "Michel Veillette 349 351 Andy Bierman 352 354 Alexander Pelov 355 "; 357 description 358 "This module defines the structure of the .sid files. 360 Each .sid file contains the mapping between the different 361 string identifiers defined by a YANG module and a 362 corresponding numeric value called SID."; 364 revision 2017-11-26 { 365 description 366 "Initial revision."; 367 reference 368 "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; 369 } 371 typedef revision-identifier { 372 type string { 373 pattern '\d{4}-\d{2}-\d{2}'; 374 } 375 description 376 "Represents a date in YYYY-MM-DD format."; 377 } 379 typedef schema-node-path { 380 type string { 381 pattern 382 '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' + 383 '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*'; 384 } 385 description 386 "Identifies a schema-node path string for use in the 387 SID registry. This string format follows the rules 388 for an instance-identifier, as defined in RFC 7959, 389 except that no predicates are allowed. 391 This format is intended to support the YANG 1.1 ABNF 392 for a schema node identifier, except module names 393 are used instead of prefixes, as specified in RFC 7951."; 394 reference 395 "RFC 7950, The YANG 1.1 Data Modeling Language; 396 Section 6.5: Schema Node Identifier; 397 RFC 7951, JSON Encoding of YANG Data; 398 Section 6.11: The instance-identifier type"; 399 } 401 leaf module-name { 402 type yang:yang-identifier; 403 description 404 "Name of the YANG module associated with this .sid file."; 405 } 407 leaf module-revision { 408 type revision-identifier; 409 description 410 "Revision of the YANG module associated with this .sid file. 411 This leaf is not present if no revision statement is 412 defined in the YANG module."; 413 } 415 list assigment-ranges { 416 key "entry-point"; 417 description 418 "SID range(s) allocated to the YANG module identified by 419 'module-name' and 'module-revision'."; 421 leaf entry-point { 422 type comi:sid; 423 mandatory true; 424 description 425 "Lowest SID available for assignment."; 426 } 428 leaf size { 429 type uint64; 430 mandatory true; 431 description 432 "Number of SIDs available for assignment."; 433 } 434 } 436 list items { 437 key "namespace identifier"; 438 description 439 "Each entry within this list defined the mapping between 440 a YANG item string identifier and a SID. This list MUST 441 include a mapping entry for each YANG item defined by 442 the YANG module identified by 'module-name' and 443 'module-revision'."; 445 leaf namespace { 446 type enumeration { 447 enum module { 448 value 0; 449 description 450 "All module and submodule names share the same 451 global module identifier namespace."; 452 } 453 enum identity { 454 value 1; 455 description 456 "All identity names defined in a module and its 457 submodules share the same identity identifier 458 namespace."; 459 } 460 enum feature { 461 value 2; 462 description 463 "All feature names defined in a module and its 464 submodules share the same feature identifier 465 namespace."; 466 } 467 enum data { 468 value 3; 469 description 470 "The namespace for all data nodes, as defined in YANG."; 471 } 472 } 473 description 474 "Namespace of the YANG item for this mapping entry."; 475 } 476 leaf identifier { 477 type union { 478 type yang:yang-identifier; 479 type schema-node-path; 480 } 481 description 482 "String identifier of the YANG item for this mapping entry. 484 If the corresponding 'namespace' field is 'module', 485 'feature', or 'identity', then this field MUST 486 contain a valid YANG identifier string. 488 If the corresponding 'namespace' field is 'data', 489 then this field MUST contain a valid schema node 490 path."; 491 } 493 leaf sid { 494 type comi:sid; 495 mandatory true; 496 description 497 "SID assigned to the YANG item for this mapping entry."; 498 } 499 } 500 } 501 503 5. Third party registries 505 The organization and functioning of third party registries is outside 506 the scope of the current document. The only limitations connected to 507 those registries are listed in Section 7.2. 509 6. Security Considerations 511 The security considerations of [RFC7049] and [RFC7950] apply. 513 This document defines a new type of identifier used to encode data 514 models defined in YANG [RFC7950]. As such, this identifier does not 515 contribute to any new security issues in addition of those identified 516 for the specific protocols or contexts for which it is used. 518 7. IANA Considerations 520 In this section are given specifications for an entry into the module 521 registry and two new registries, a SID-range registry and a SID 522 module registry. 524 7.1. Module registration 526 This document registers one YANG modules in the "YANG Module Names" 527 registry [RFC6020]: 529 o name: ietf-sid-file 531 o namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file 533 o prefix: sid 535 o reference: [[THISRFC]] 537 7.2. "SID mega-range" registry 539 The name of this registry is "SID mega-range". This registry is used 540 to record the delegation of the management of a block of SIDs to 541 third parties (e.g. SDO, registrar). 543 Each entry in this registry must include: 545 o The entry point (first entry) of the registered SID range. 547 o The size of the registered SID range. 549 o The contact information of the requesting organization including: 551 o Organization name 553 o Primary contact name, email address, and phone number 555 o Secondary contact name, email address, and phone number 557 The initial entry in this registry is allocated to IANA: 559 +-------------+---------+-------------------+ 560 | Entry Point | Size | Organization name | 561 +-------------+---------+-------------------+ 562 | 0 | 1000000 | IANA | 563 +-------------+---------+-------------------+ 565 The IANA policies for future additions to this registry are 566 "Hierarchical Allocation, Expert Review" [RFC5226]. Prior to a first 567 allocation, the requesting organization must demonstrate a functional 568 registry infrastructure. On subsequent allocation request(s), the 569 organization must demonstrate the exhaustion of the prior range. 570 These conditions need to be asserted by the assigned expert(s). 572 7.2.1. "IANA SID Mega-Range" allocation 574 The first million SIDs assigned to IANA is sub-divided as follow: 576 o The range of 0 to 999 is reserved for future extensions. The IANA 577 policy for this range is "IETF review" [RFC5226]. This range is 578 reserved for a future uses and no sub-registries are currently 579 defined for it. 581 o The range of 1000 to 59,999 is reserved for YANG modules defined 582 in RFCs. The IANA policy for future additions to this sub- 583 registry is "RFC required" [RFC5226]. Allocation within this 584 range requires publishing of the associated ".yang" and ".sid" 585 files in the YANG module registry. The allocation within this 586 range is done during IESG review. 588 o The range of 60,000 to 99,999 is reserved for experimental YANG 589 modules. This range MUST NOT be used in operational deployments 590 since these SIDs are not globally unique which limit their 591 interoperability. The IANA policy for this range is "Experimental 592 use" [RFC5226]. 594 o The range of 100,000 to 999,999 is reserved for standardized YANG 595 modules. The IANA policy for future additions to this sub- 596 registry is "Specification Required" [RFC5226]. Allocation within 597 this range requires publishing of the associated ".yang" and 598 ".sid" files in the YANG module registry. 600 +-------------+---------+------------------------+ 601 | Entry Point | Size | IANA policy | 602 +-------------+---------+------------------------+ 603 | 0 | 1,000 | IETF review | 604 | 1,000 | 59,000 | RFC required | 605 | 60,000 | 40,000 | Experimental use | 606 | 100,000 | 900,000 | Specification Required | 607 +-------------+---------+------------------------+ 609 The size of a SID range assigned to a YANG module should be at least 610 33% above the current number of YANG items. This headroom allows 611 assignment within the same range of new YANG items introduced by 612 subsequent revisions. A larger SID range size may be requested by 613 the authors if this recommendation is considered insufficient. It is 614 important to note that an extra SID range can be allocated to an 615 existing YANG module if the initial range is exhausted. 617 7.2.2. "RFC SID range assignment" sub-registry 619 The name of this sub-registry is "RFC SID range assignment". This 620 sub-registry of "IANA SID Mega-Range" allocation Section 7.2.1 621 corresponds to the SID entry point 1000, size 59000. Each entry in 622 this sub-registry must include: 624 o The SID range entry point. 626 o The SID range size. 628 o The YANG module name. 630 o The RFC number. 632 Initial entries in this registry are as follows: 634 +-------------+------+------------------+----------------------+ 635 | Entry Point | Size | Module name | RFC number | 636 +-------------+------+------------------+----------------------+ 637 | 1000 | 100 | ietf-comi | [I-D.ietf-core-comi] | 638 | 1100 | 50 | ietf-yang-types | [RFC6021] | 639 | 1150 | 50 | ietf-inet-types | [RFC6021] | 640 | 1200 | 50 | iana-crypt-hash | [RFC7317] | 641 | 1250 | 50 | ietf-netconf-acm | [RFC6536] | 642 | 1300 | 50 | ietf-sid-file | RFCXXXX | 643 | 1500 | 100 | ietf-interfaces | [RFC7223] | 644 | 1600 | 100 | ietf-ip | [RFC7277] | 645 | 1700 | 100 | ietf-system | [RFC7317] | 646 | 1800 | 400 | iana-if-type | [RFC7224] | 647 +-------------+------+------------------+----------------------+ 649 // RFC Ed.: replace XXXX with RFC number assigned to this draft. 651 For allocation, RFC publication of the module is required as per 652 [RFC5226]. The YANG module must be registered in the "YANG module 653 Name" registry according to the rules specified in section 14 of 654 [RFC6020]. 656 7.2.3. "Specification SID range assignment" sub-registry 658 The name of this sub-registry is "Specification SID range 659 assignment". This sub-registry of "IANA SID Mega-Range" allocation 660 Section 7.2.1 corresponds to the SID entry point 100000, size 900000. 661 Each entry in this sub-registry must include: 663 o The SID range entry point. 665 o The SID range size. 667 o The YANG module name. 669 o The name of the standard organization 671 o The specification identifier or URI 673 7.3. "YANG module assignment" registry 675 The name of this registry is "YANG module assignment". This registry 676 is used to track which YANG modules have been assigned and the 677 specific YANG items assignment. Each entry in this registry must 678 include: 680 o The YANG module name. 682 o The associated ".yang" file(s) 684 o The associated ".sid" file 686 The validity of the ".yang" and ".sid" files added to this registry 687 MUST be verified. 689 o The syntax of the registered ".yang" and ".sid" files must be 690 valid. 692 o Each YANG item defined by the registered ".yang" file must have a 693 corresponding SID assigned in the ".sid" file. 695 o Each SID is assigned to a single YANG item, duplicate assignment 696 is not allowed. 698 o The SID range(s) defined in the ".sid" file must be unique, must 699 not conflict with any other SID ranges defined in already 700 registered ".sid" files. 702 o The ownership of the SID range(s) should be verified. 704 The IANA policy for future additions to this registry is "First Come 705 First Served" as described in [RFC5226]. 707 8. Acknowledgments 709 The authors would like to thank Andy Bierman, Carsten Bormann, 710 Abhinav Somaraju, Laurent Toutain, Randy Turner and Peter van der 711 Stok for their help during the development of this document and their 712 useful comments during the review process. 714 9. References 716 9.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, 720 DOI 10.17487/RFC2119, March 1997, 721 . 723 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 724 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 725 October 2013, . 727 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 728 RFC 7950, DOI 10.17487/RFC7950, August 2016, 729 . 731 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 732 RFC 7951, DOI 10.17487/RFC7951, August 2016, 733 . 735 9.2. Informative References 737 [I-D.ietf-core-comi] 738 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 739 Management Interface", draft-ietf-core-comi-04 (work in 740 progress), November 2018. 742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 743 IANA Considerations Section in RFCs", RFC 5226, 744 DOI 10.17487/RFC5226, May 2008, 745 . 747 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 748 the Network Configuration Protocol (NETCONF)", RFC 6020, 749 DOI 10.17487/RFC6020, October 2010, 750 . 752 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 753 RFC 6021, DOI 10.17487/RFC6021, October 2010, 754 . 756 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 757 and A. Bierman, Ed., "Network Configuration Protocol 758 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 759 . 761 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 762 Protocol (NETCONF) Access Control Model", RFC 6536, 763 DOI 10.17487/RFC6536, March 2012, 764 . 766 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 767 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 768 . 770 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 771 RFC 7224, DOI 10.17487/RFC7224, May 2014, 772 . 774 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 775 RFC 7277, DOI 10.17487/RFC7277, June 2014, 776 . 778 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 779 System Management", RFC 7317, DOI 10.17487/RFC7317, August 780 2014, . 782 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 783 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 784 . 786 Appendix A. ".sid" file example 788 The following .sid file (ietf-system@2014-08-06.sid) have been 789 generated using the following yang modules: 791 o ietf-system@2014-08-06.yang 793 o ietf-yang-types@2013-07-15.yang 795 o ietf-inet-types@2013-07-15.yang 797 o ietf-netconf-acm@2012-02-22.yang 799 o iana-crypt-hash@2014-04-04.yang 801 { 802 "assignment-ranges": [ 803 { 804 "entry-point": 1700, 805 "size": 100 806 } 807 ], 808 "module-name": "ietf-system", 809 "module-revision": "2014-08-06", 810 "items": [ 811 { 812 "namespace": "module", 813 "identifier": "ietf-system", 814 "sid": 1700 815 }, 816 { 817 "namespace": "identity", 818 "identifier": "authentication-method", 819 "sid": 1701 820 }, 821 { 822 "namespace": "identity", 823 "identifier": "local-users", 824 "sid": 1702 825 }, 826 { 827 "namespace": "identity", 828 "identifier": "radius", 829 "sid": 1703 830 }, 831 { 832 "namespace": "identity", 833 "identifier": "radius-authentication-type", 834 "sid": 1704 835 }, 836 { 837 "namespace": "identity", 838 "identifier": "radius-chap", 839 "sid": 1705 840 }, 841 { 842 "namespace": "identity", 843 "identifier": "radius-pap", 844 "sid": 1706 845 }, 846 { 847 "namespace": "feature", 848 "identifier": "authentication", 849 "sid": 1707 850 }, 851 { 852 "namespace": "feature", 853 "identifier": "dns-udp-tcp-port", 854 "sid": 1708 855 }, 856 { 857 "namespace": "feature", 858 "identifier": "local-users", 859 "sid": 1709 860 }, 861 { 862 "namespace": "feature", 863 "identifier": "ntp", 864 "sid": 1710 865 }, 866 { 867 "namespace": "feature", 868 "identifier": "ntp-udp-port", 869 "sid": 1711 870 }, 871 { 872 "namespace": "feature", 873 "identifier": "radius", 874 "sid": 1712 875 }, 876 { 877 "namespace": "feature", 878 "identifier": "radius-authentication", 879 "sid": 1713 880 }, 881 { 882 "namespace": "feature", 883 "identifier": "timezone-name", 884 "sid": 1714 885 }, 886 { 887 "namespace": "data", 888 "identifier": "/ietf-system:set-current-datetime", 889 "sid": 1715 890 }, 891 { 892 "namespace": "data", 893 "identifier": "/ietf-system:set-current-datetime/ 894 current-datetime", 895 "sid": 1716 896 }, 897 { 898 "namespace": "data", 899 "identifier": "/ietf-system:system", 900 "sid": 1717 901 }, 902 { 903 "namespace": "data", 904 "identifier": "/ietf-system:system-restart", 905 "sid": 1718 906 }, 907 { 908 "namespace": "data", 909 "identifier": "/ietf-system:system-shutdown", 910 "sid": 1719 911 }, 912 { 913 "namespace": "data", 914 "identifier": "/ietf-system:system-state", 915 "sid": 1720 916 }, 917 { 918 "namespace": "data", 919 "identifier": "/ietf-system:system-state/clock", 920 "sid": 1721 921 }, 922 { 923 "namespace": "data", 924 "identifier": "/ietf-system:system-state/clock/boot-datetime", 925 "sid": 1722 926 }, 927 { 928 "namespace": "data", 929 "identifier": "/ietf-system:system-state/clock/ 930 current-datetime", 931 "sid": 1723 932 }, 933 { 934 "namespace": "data", 935 "identifier": "/ietf-system:system-state/platform", 936 "sid": 1724 937 }, 938 { 939 "namespace": "data", 940 "identifier": "/ietf-system:system-state/platform/machine", 941 "sid": 1725 942 }, 943 { 944 "namespace": "data", 945 "identifier": "/ietf-system:system-state/platform/os-name", 946 "sid": 1726 947 }, 948 { 949 "namespace": "data", 950 "identifier": "/ietf-system:system-state/platform/os-release", 951 "sid": 1727 952 }, 953 { 954 "namespace": "data", 955 "identifier": "/ietf-system:system-state/platform/os-version", 956 "sid": 1728 957 }, 958 { 959 "namespace": "data", 960 "identifier": "/ietf-system:system/authentication", 961 "sid": 1729 962 }, 963 { 964 "namespace": "data", 965 "identifier": "/ietf-system:system/authentication/user", 966 "sid": 1730 967 }, 968 { 969 "namespace": "data", 970 "identifier": "/ietf-system:system/authentication/ 971 user-authentication-order", 972 "sid": 1731 973 }, 974 { 975 "namespace": "data", 976 "identifier": "/ietf-system:system/authentication/user/ 977 authorized-key", 978 "sid": 1732 979 }, 980 { 981 "namespace": "data", 982 "identifier": "/ietf-system:system/authentication/user/ 983 authorized-key/algorithm", 984 "sid": 1733 985 }, 986 { 987 "namespace": "data", 988 "identifier": "/ietf-system:system/authentication/user/ 989 authorized-key/key-data", 990 "sid": 1734 991 }, 992 { 993 "namespace": "data", 994 "identifier": "/ietf-system:system/authentication/user/ 995 authorized-key/name", 996 "sid": 1735 997 }, 998 { 999 "namespace": "data", 1000 "identifier": "/ietf-system:system/authentication/user/ 1001 name", 1002 "sid": 1736 1003 }, 1004 { 1005 "namespace": "data", 1006 "identifier": "/ietf-system:system/authentication/user/ 1007 password", 1008 "sid": 1737 1009 }, 1010 { 1011 "namespace": "data", 1012 "identifier": "/ietf-system:system/clock", 1013 "sid": 1738 1014 }, 1015 { 1016 "namespace": "data", 1017 "identifier": "/ietf-system:system/clock/timezone-name", 1018 "sid": 1739 1019 }, 1020 { 1021 "namespace": "data", 1022 "identifier": "/ietf-system:system/clock/timezone-utc-offset", 1023 "sid": 1740 1024 }, 1025 { 1026 "namespace": "data", 1027 "identifier": "/ietf-system:system/contact", 1028 "sid": 1741 1029 }, 1030 { 1031 "namespace": "data", 1032 "identifier": "/ietf-system:system/dns-resolver", 1033 "sid": 1742 1034 }, 1035 { 1036 "namespace": "data", 1037 "identifier": "/ietf-system:system/dns-resolver/options", 1038 "sid": 1743 1039 }, 1040 { 1041 "namespace": "data", 1042 "identifier": "/ietf-system:system/dns-resolver/options/ 1043 attempts", 1044 "sid": 1744 1045 }, 1046 { 1047 "namespace": "data", 1048 "identifier": "/ietf-system:system/dns-resolver/options/ 1049 timeout", 1050 "sid": 1745 1051 }, 1052 { 1053 "namespace": "data", 1054 "identifier": "/ietf-system:system/dns-resolver/search", 1055 "sid": 1746 1056 }, 1057 { 1058 "namespace": "data", 1059 "identifier": "/ietf-system:system/dns-resolver/server", 1060 "sid": 1747 1061 }, 1062 { 1063 "namespace": "data", 1064 "identifier": "/ietf-system:system/dns-resolver/server/name", 1065 "sid": 1748 1066 }, 1067 { 1068 "namespace": "data", 1069 "identifier": "/ietf-system:system/dns-resolver/server/ 1070 udp-and-tcp", 1071 "sid": 1749 1072 }, 1073 { 1074 "namespace": "data", 1075 "identifier": "/ietf-system:system/dns-resolver/server/ 1076 udp-and-tcp/address", 1077 "sid": 1750 1078 }, 1079 { 1080 "namespace": "data", 1081 "identifier": "/ietf-system:system/dns-resolver/server/ 1082 udp-and-tcp/port", 1083 "sid": 1751 1084 }, 1085 { 1086 "namespace": "data", 1087 "identifier": "/ietf-system:system/hostname", 1088 "sid": 1752 1089 }, 1090 { 1091 "namespace": "data", 1092 "identifier": "/ietf-system:system/location", 1093 "sid": 1753 1094 }, 1095 { 1096 "namespace": "data", 1097 "identifier": "/ietf-system:system/ntp", 1098 "sid": 1754 1099 }, 1100 { 1101 "namespace": "data", 1102 "identifier": "/ietf-system:system/ntp/enabled", 1103 "sid": 1755 1104 }, 1105 { 1106 "namespace": "data", 1107 "identifier": "/ietf-system:system/ntp/server", 1108 "sid": 1756 1109 }, 1110 { 1111 "namespace": "data", 1112 "identifier": "/ietf-system:system/ntp/server/ 1113 association-type", 1114 "sid": 1757 1115 }, 1116 { 1117 "namespace": "data", 1118 "identifier": "/ietf-system:system/ntp/server/iburst", 1119 "sid": 1758 1120 }, 1121 { 1122 "namespace": "data", 1123 "identifier": "/ietf-system:system/ntp/server/name", 1124 "sid": 1759 1125 }, 1126 { 1127 "namespace": "data", 1128 "identifier": "/ietf-system:system/ntp/server/prefer", 1129 "sid": 1760 1130 }, 1131 { 1132 "namespace": "data", 1133 "identifier": "/ietf-system:system/ntp/server/udp", 1134 "sid": 1761 1135 }, 1136 { 1137 "namespace": "data", 1138 "identifier": "/ietf-system:system/ntp/server/udp/address", 1139 "sid": 1762 1140 }, 1141 { 1142 "namespace": "data", 1143 "identifier": "/ietf-system:system/ntp/server/udp/port", 1144 "sid": 1763 1146 }, 1147 { 1148 "namespace": "data", 1149 "identifier": "/ietf-system:system/radius", 1150 "sid": 1764 1151 }, 1152 { 1153 "namespace": "data", 1154 "identifier": "/ietf-system:system/radius/options", 1155 "sid": 1765 1156 }, 1157 { 1158 "namespace": "data", 1159 "identifier": "/ietf-system:system/radius/options/attempts", 1160 "sid": 1766 1161 }, 1162 { 1163 "namespace": "data", 1164 "identifier": "/ietf-system:system/radius/options/timeout", 1165 "sid": 1767 1166 }, 1167 { 1168 "namespace": "data", 1169 "identifier": "/ietf-system:system/radius/server", 1170 "sid": 1768 1171 }, 1172 { 1173 "namespace": "data", 1174 "identifier": "/ietf-system:system/radius/server/ 1175 authentication-type", 1176 "sid": 1769 1177 }, 1178 { 1179 "namespace": "data", 1180 "identifier": "/ietf-system:system/radius/server/name", 1181 "sid": 1770 1182 }, 1183 { 1184 "namespace": "data", 1185 "identifier": "/ietf-system:system/radius/server/udp", 1186 "sid": 1771 1187 }, 1188 { 1189 "namespace": "data", 1190 "identifier": "/ietf-system:system/radius/server/udp/ 1191 address", 1192 "sid": 1772 1193 }, 1194 { 1195 "namespace": "data", 1196 "identifier": "/ietf-system:system/radius/server/udp/ 1197 authentication-port", 1198 "sid": 1773 1199 }, 1200 { 1201 "namespace": "data", 1202 "identifier": "/ietf-system:system/radius/server/udp/ 1203 shared-secret", 1204 "sid": 1774 1205 } 1206 ] 1207 } 1209 Authors' Addresses 1211 Michel Veillette (editor) 1212 Trilliant Networks Inc. 1213 610 Rue du Luxembourg 1214 Granby, Quebec J2J 2V2 1215 Canada 1217 Phone: +14503750556 1218 Email: michel.veillette@trilliant.com 1220 Alexander Pelov (editor) 1221 Acklio 1222 1137A avenue des Champs Blancs 1223 Cesson-Sevigne, Bretagne 35510 1224 France 1226 Email: a@ackl.io 1228 Ivaylo Petrov (editor) 1229 Acklio 1230 1137A avenue des Champs Blancs 1231 Cesson-Sevigne, Bretagne 35510 1232 France 1234 Email: ivaylo@ackl.io