rfc9595v4.txt | rfc9595.txt | |||
---|---|---|---|---|
skipping to change at line 14 ¶ | skipping to change at line 14 ¶ | |||
Category: Standards Track A. Pelov, Ed. | Category: Standards Track A. Pelov, Ed. | |||
ISSN: 2070-1721 IMT Atlantique | ISSN: 2070-1721 IMT Atlantique | |||
I. Petrov, Ed. | I. Petrov, Ed. | |||
Google Switzerland GmbH | Google Switzerland GmbH | |||
C. Bormann | C. Bormann | |||
Universität Bremen TZI | Universität Bremen TZI | |||
M. Richardson | M. Richardson | |||
Sandelman Software Works | Sandelman Software Works | |||
June 2024 | June 2024 | |||
YANG Data Model for YANG Schema Item iDentifiers (YANG-SIDs) | Encoding of Data Modeled with YANG Schema Item iDentifiers (YANG-SIDs) | |||
Abstract | Abstract | |||
YANG Schema Item iDentifiers (YANG-SIDs) are globally unique 63-bit | YANG Schema Item iDentifiers (YANG-SIDs) are globally unique 63-bit | |||
unsigned integers used to identify YANG items. SIDs provide a more | unsigned integers used to identify YANG items. SIDs provide a more | |||
compact method for identifying those YANG items that can be used | compact method for identifying those YANG items that can be used | |||
efficiently, particularly in constrained environments (RFC 7228). | efficiently, particularly in constrained environments (RFC 7228). | |||
This document defines the semantics, registration processes, and | This document defines the semantics, registration processes, and | |||
assignment processes for YANG-SIDs for IETF-managed YANG modules. To | assignment processes for YANG-SIDs for IETF-managed YANG modules. To | |||
enable the implementation of these processes, this document also | enable the implementation of these processes, this document also | |||
skipping to change at line 86 ¶ | skipping to change at line 86 ¶ | |||
7.3.2.2. Consecutive Allocations | 7.3.2.2. Consecutive Allocations | |||
7.3.3. Initial Contents of the Registry | 7.3.3. Initial Contents of the Registry | |||
7.4. New IANA Registry: IETF YANG-SID Ranges | 7.4. New IANA Registry: IETF YANG-SID Ranges | |||
7.4.1. Structure | 7.4.1. Structure | |||
7.4.2. Allocation Policy | 7.4.2. Allocation Policy | |||
7.4.3. Publication of the ".sid" File | 7.4.3. Publication of the ".sid" File | |||
7.4.4. Initial Contents of the Registry | 7.4.4. Initial Contents of the Registry | |||
7.5. New IANA Registry: IETF YANG-SID Modules | 7.5. New IANA Registry: IETF YANG-SID Modules | |||
7.5.1. Structure | 7.5.1. Structure | |||
7.5.2. Allocation Policy | 7.5.2. Allocation Policy | |||
7.5.3. Recursive Allocation of YANG-SID Range at Document | 7.5.3. Recursive Allocation of YANG-SIDs at Document Adoption | |||
Adoption | ||||
7.5.4. Initial Contents of the Registry | 7.5.4. Initial Contents of the Registry | |||
7.6. Media Type and Content-Format Registration | 7.6. Media Type and Content-Format Registration | |||
7.6.1. Media Type application/yang-sid+json | 7.6.1. Media Type application/yang-sid+json | |||
7.6.2. CoAP Content-Format | 7.6.2. CoAP Content-Format | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
8.2. Informative References | 8.2. Informative References | |||
Appendix A. ".sid" File Example | Appendix A. ".sid" File Example | |||
Appendix B. SID Autogeneration | Appendix B. SID Autogeneration | |||
Appendix C. ".sid" File Lifecycle | Appendix C. ".sid" File Lifecycle | |||
skipping to change at line 139 ¶ | skipping to change at line 138 ¶ | |||
* remote procedure calls (RPCs) and associated input(s) and | * remote procedure calls (RPCs) and associated input(s) and | |||
output(s) | output(s) | |||
* actions and associated input(s) and output(s) | * actions and associated input(s) and output(s) | |||
* notifications and associated information | * notifications and associated information | |||
* YANG modules and features | * YANG modules and features | |||
It is possible that some protocols will use only a subset of the | It is possible that some protocols will use only a subset of the | |||
assigned SIDs; for example, for protocols that provide extensions to | assigned SIDs; for example, for protocols other than NETCONF | |||
NETCONF [RFC6241], such as [CORE-COMI], the transport of YANG module | [RFC6241] that provide access to YANG-modeled data, such as | |||
SIDs might be unnecessary. Other protocols might need to be able to | [CORE-COMI], the transport of YANG module SIDs might be unnecessary. | |||
transport this information -- for example, protocols related to | Other protocols might need to be able to transport this information | |||
discovery such as the Constrained YANG Module Library [YANG-LIBRARY]. | -- for example, protocols related to discovery such as the | |||
Constrained YANG Module Library [YANG-LIBRARY]. | ||||
SIDs are globally unique integers. A registration system is used in | SIDs are globally unique integers. A registration system is used in | |||
order to guarantee their uniqueness. SIDs are registered in blocks | order to guarantee their uniqueness. SIDs are registered in blocks | |||
called "SID ranges". Once they are considered "stable", SIDs are | called "SID ranges". Once they are considered "stable", SIDs are | |||
assigned permanently. Items introduced by a new revision of a YANG | assigned permanently. Items introduced by a new revision of a YANG | |||
module are added to the list of SIDs already assigned. This is | module are added to the list of SIDs already assigned. This is | |||
discussed in more detail in Section 2. | discussed in more detail in Section 2. | |||
The assignment of SIDs to YANG items is usually automated as | The assignment of SIDs to YANG items is usually automated as | |||
discussed in Appendix B, which also discusses some cases where manual | discussed in Appendix B, which also discusses some cases where manual | |||
interventions may be appropriate. | interventions may be appropriate. | |||
Section 3 provides more details about the registration processes for | Section 3 provides more details about the registration processes for | |||
YANG modules and associated SIDs. To enable the implementation of | YANG modules and associated SIDs. To enable the implementation of | |||
these processes, Section 4 defines a standard file format used to | these processes, Section 4 defines a standard file format used to | |||
store and publish SIDs. | store and publish SIDs. | |||
IETF-managed YANG modules that need to allocate SIDs will use the | IETF-managed YANG modules that need to allocate SIDs will use the | |||
IANA mechanisms (e.g., allocation mechanisms) specified in this | IANA mechanisms specified in this document. See Section 7 for | |||
document. See Section 7 for details. YANG modules created by other | details. YANG modules created by other parties allocate SID ranges | |||
parties allocate SID ranges using the IANA allocation mechanisms via | using the IANA allocation mechanisms via Mega-Ranges (see | |||
Mega-Ranges (see Section 7.3); within the Mega-Range allocation, | Section 7.3); within the Mega-Range allocation, those other parties | |||
those other parties are free to make up their own mechanism. | are free to make up their own mechanism. | |||
Among other uses, YANG-SIDs are particularly useful for obtaining a | Among other uses, YANG-SIDs are particularly useful for obtaining a | |||
compact encoding for YANG-CBOR [RFC9254]. At the time of writing, a | compact encoding for YANG-CBOR [RFC9254]. At the time of writing, a | |||
tool for automated ".sid" file generation is available as part of the | tool for automated ".sid" file generation is available as part of the | |||
open-source project PYANG [PYANG]. | open-source project PYANG [PYANG]. | |||
1.1. Terminology and Notation | 1.1. Terminology and Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
skipping to change at line 215 ¶ | skipping to change at line 215 ¶ | |||
integer used to identify different YANG items (cf. Section 3.2 of | integer used to identify different YANG items (cf. Section 3.2 of | |||
[RFC9254]). | [RFC9254]). | |||
YANG name: Text string used to identify different YANG items | YANG name: Text string used to identify different YANG items | |||
(cf. Section 3.3 of [RFC9254]). | (cf. Section 3.3 of [RFC9254]). | |||
2. Objectives | 2. Objectives | |||
The overriding objective of the SID assignment and registration | The overriding objective of the SID assignment and registration | |||
system is to ensure global interoperability of protocols that employ | system is to ensure global interoperability of protocols that employ | |||
SIDs in order to communicate about data modeled in YANG [RFC7950]. | SIDs in order to communicate about data modeled in YANG. This | |||
This objective poses certain requirements on the stability of SIDs | objective poses certain requirements on the stability of SIDs while | |||
while at the same time not hindering active evolution of the YANG | at the same time not hindering active evolution of the YANG modules | |||
modules the SIDs are intended to support. | the SIDs are intended to support. | |||
Additional objectives include: | Additional objectives include: | |||
* enabling the developer of a YANG module to also be the originating | * enabling the developer of a YANG module to also be the originating | |||
entity for the SIDs pertaining to that module. | entity for the SIDs pertaining to that module. | |||
* making it easy for YANG developers to obtain SIDs. | * making it easy for YANG developers to obtain SIDs. | |||
* enabling other developers to define SIDs for a module where the | * enabling other developers to define SIDs for a module where the | |||
developer of the module is not interested in assigning the SIDs. | developer of the module is not interested in assigning the SIDs. | |||
skipping to change at line 241 ¶ | skipping to change at line 241 ¶ | |||
readily available for the applications that would benefit from | readily available for the applications that would benefit from | |||
them while at the same time employing the vast 63-bit SID space to | them while at the same time employing the vast 63-bit SID space to | |||
facilitate permissionless actions. | facilitate permissionless actions. | |||
* enabling multiple entities to provide services that support the | * enabling multiple entities to provide services that support the | |||
assignment of SIDs. | assignment of SIDs. | |||
* maintaining some locality in the assignment of SIDs so the | * maintaining some locality in the assignment of SIDs so the | |||
efficiencies of the SID delta mechanism can be fully employed. | efficiencies of the SID delta mechanism can be fully employed. | |||
* enabling various software components to deal in terms of SIDs | * enabling various software components to operate in terms of SIDs | |||
without having complete information about other parties in the | without having complete information about other parties in the | |||
communication process. | communication process. | |||
While IANA ultimately maintains the registries that govern SIDs for | While IANA ultimately maintains the registries that govern SIDs for | |||
IETF-defined modules, various support tools (such as, at the time of | IETF-defined modules, various support tools (such as, at the time of | |||
writing, the YANG Catalog [yangcatalog]) need to provide the support | writing, the YANG Catalog [yangcatalog]) need to provide the support | |||
to enable SID assignment and use for modules still in IETF | to enable SID assignment and use for modules still in IETF | |||
development. Developers of open-source or proprietary YANG modules | development. Developers of open-source or proprietary YANG modules | |||
also need to be able to serve as such entities autonomously, possibly | also need to be able to serve as such entities autonomously, possibly | |||
forming alliances independent of the IETF, while still fitting in the | forming alliances independent of the IETF, while still fitting in the | |||
skipping to change at line 331 ¶ | skipping to change at line 331 ¶ | |||
Items introduced by a new revision of a YANG module are added to the | Items introduced by a new revision of a YANG module are added to the | |||
list of SIDs already assigned. | list of SIDs already assigned. | |||
2.4. Parties and Roles | 2.4. Parties and Roles | |||
In the YANG development process, we can discern a number of parties | In the YANG development process, we can discern a number of parties | |||
that are concerned with a YANG module: | that are concerned with a YANG module: | |||
module controller: | module controller: | |||
The owner of the YANG module, i.e., the controller about its | The owner of the YANG module, i.e., the controller of the module's | |||
evolution. | evolution. | |||
registration entity: | registration entity: | |||
The controller of the module namespace, specifically also of the | The controller of the module namespace, specifically also of the | |||
prefixes that are in common use. (This is not a required party.) | prefixes that are in common use. (This is not a required party.) | |||
module repository: | module repository: | |||
An entity that supplies modules to module users. This can be an | An entity that supplies modules to module users. This can be an | |||
"official" entity (e.g., IANA for IETF modules) or an "unofficial" | "official" entity (e.g., IANA for IETF modules) or an "unofficial" | |||
entity (e.g., the YANG Catalog [yangcatalog]). Not all | entity (e.g., the YANG Catalog [yangcatalog]). Not all | |||
skipping to change at line 375 ¶ | skipping to change at line 375 ¶ | |||
SID repository: | SID repository: | |||
An entity that supplies SID assignments to SID users, usually in | An entity that supplies SID assignments to SID users, usually in | |||
the form of a ".sid" file. | the form of a ".sid" file. | |||
SID user: | SID user: | |||
The module user that uses the SIDs provided by a SID assigner for | The module user that uses the SIDs provided by a SID assigner for | |||
a YANG module. SID users need to find SID assigners (or at least | a YANG module. SID users need to find SID assigners (or at least | |||
their SID assignments). | their SID assignments). | |||
As new SIDs are introduced, the distribution of the SID roles to the | As the use of SIDs with YANG data models is introduced, the | |||
existing parties for a YANG module will evolve. | distribution of the SID roles to the existing parties for a YANG | |||
module will evolve. | ||||
The desirable end state of this evolution is shown in Table 1. | The desirable end state of this evolution is shown in Table 1. | |||
+====================+======================================+ | +====================+======================================+ | |||
| Role | Party | | | Role | Party | | |||
+====================+======================================+ | +====================+======================================+ | |||
| SID assigner | module developer | | | SID assigner | module developer | | |||
+--------------------+--------------------------------------+ | +--------------------+--------------------------------------+ | |||
| SID range registry | (as discussed in this specification) | | | SID range registry | (as discussed in this specification) | | |||
+--------------------+--------------------------------------+ | +--------------------+--------------------------------------+ | |||
skipping to change at line 412 ¶ | skipping to change at line 413 ¶ | |||
state. | state. | |||
For existing modules, there is no ".sid" file. The entity that | For existing modules, there is no ".sid" file. The entity that | |||
stands in as the SID assigner is not specified. This situation has | stands in as the SID assigner is not specified. This situation has | |||
the highest potential for conflict with Objective 2. | the highest potential for conflict with Objective 2. | |||
Similarly, for new module development, the module owner may not have | Similarly, for new module development, the module owner may not have | |||
heard about SIDs or may not be interested in assigning them (e.g., | heard about SIDs or may not be interested in assigning them (e.g., | |||
because of lack of software or procedures within their organization). | because of lack of software or procedures within their organization). | |||
For these two cases (which we will call "type-3", "SID-oblivious" | For these two cases (which we will collectively call "type-3", "SID- | |||
module controllers), module repositories can act as a mediator, | oblivious" module controller), module repositories can act as a | |||
giving SID users access to a SID assigner that is carefully chosen to | mediator, giving SID users access to a SID assigner that is carefully | |||
be a likely choice by other module repositories as well, maximizing | chosen to be a likely choice by other module repositories as well, | |||
the likelihood of achieving Objective 2. | maximizing the likelihood of achieving Objective 2. | |||
If a module controller has heard about SIDs but is not assigning them | If a module controller has heard about SIDs but is not assigning them | |||
yet, it can designate a SID assigner instead. This can lead to a | yet, it can designate a SID assigner instead. This can lead to a | |||
stable, unique set of SID assignments being provided indirectly by a | stable, unique set of SID assignments being provided indirectly by a | |||
("type-2", "SID-aware") module developer. Entities offering | ("type-2", "SID-aware") module developer. Entities offering | |||
designated SID assigner services could make these available in an | designated SID assigner services could make these available in an | |||
easy-to-use way, e.g., via a web interface. | easy-to-use way, e.g., via a web interface. | |||
The entity acting as a SID assigner minimally needs to record the SID | The entity acting as a SID assigner minimally needs to record the SID | |||
range it uses for the SID assignment. If the SID range registry can | range it uses for the SID assignment. If the SID range registry | |||
record the module name and revision and if the assignment processes | employed can record the module name and revision and if the | |||
(including the software used) are stable, the SID assigner can | assignment processes (including the software used) are stable, the | |||
theoretically reconstruct its assignments, but this could invite | SID assigner can theoretically reconstruct its assignments, but this | |||
implementation bugs. | could invite implementation bugs. | |||
SID assigners attending to a module in development (not yet stable) | SID assigners attending to a module in development (not yet stable) | |||
need to decide whether SIDs for a new revision are reassigned from | need to decide whether SIDs for a new revision are reassigned from | |||
scratch ("clean slate") or use existing assignments from a previous | scratch ("clean slate") or use existing assignments from a previous | |||
revision as a base, only assigning new SIDs for new names. Once a | revision as a base, only assigning new SIDs for new names. Once a | |||
module is declared stable, its SID assignments SHOULD be declared | module is declared stable, its SID assignments SHOULD be declared | |||
stable as well (except that, for existing YANG modules, some review | stable as well (except that, for existing YANG modules, some review | |||
may be needed before this is done). | may be needed before this is done). | |||
This specification does not further discuss how mediating entities | This specification does not further discuss how mediating entities | |||
skipping to change at line 481 ¶ | skipping to change at line 482 ¶ | |||
specification is advanced to a final document, the assignment is | specification is advanced to a final document, the assignment is | |||
marked with a status of "stable". During a period of development | marked with a status of "stable". During a period of development | |||
starting from a published specification, two variants of the ".sid" | starting from a published specification, two variants of the ".sid" | |||
file should be made available by the tooling involved in that | file should be made available by the tooling involved in that | |||
development: (1) a "published" ".sid" file with the existing stable | development: (1) a "published" ".sid" file with the existing stable | |||
SID assignments only (which the development effort should keep | SID assignments only (which the development effort should keep | |||
stable), as well as (2) an "unpublished" ".sid" file that also | stable), as well as (2) an "unpublished" ".sid" file that also | |||
contains the unstable SID assignments. | contains the unstable SID assignments. | |||
Registration of the ".sid" file associated with a YANG module is | Registration of the ".sid" file associated with a YANG module is | |||
optional but recommended, in order to promote interoperability | optional but recommended; doing so would promote interoperability | |||
between devices and to avoid duplicate allocation of SIDs to a single | between devices and avoid duplicate allocation of SIDs to a single | |||
YANG module. Different registries might have different requirements | YANG module. Different registries might have different requirements | |||
for the registration and publication of the ".sid" files. For a | for the registration and publication of the ".sid" files. For a | |||
diagram of one possible scenario, please refer to the activity | diagram of one possible scenario, please refer to the activity | |||
diagram shown in Figure 4 in Appendix C. | diagram shown in Figure 4 in Appendix C. | |||
Each time a YANG module, one or more of its imported modules, or one | Each time a YANG module, one or more of its imported modules, or one | |||
or more of its included submodules are updated, a new ".sid" file MAY | or more of its included submodules are updated, a new ".sid" file MAY | |||
be created if the new or updated items will need SIDs. All the SIDs | be created if the new or updated items will need SIDs. All the SIDs | |||
present in the previous version of the ".sid" file MUST be present in | present in the previous version of the ".sid" file MUST be present in | |||
the new version as well. The creation of this new version of the | the new version as well. The creation of this new version of the | |||
skipping to change at line 534 ¶ | skipping to change at line 535 ¶ | |||
+-- item* [namespace identifier] | +-- item* [namespace identifier] | |||
+-- status? enumeration | +-- status? enumeration | |||
+-- namespace enumeration | +-- namespace enumeration | |||
+-- identifier union | +-- identifier union | |||
+-- sid sid | +-- sid sid | |||
Figure 1: YANG Tree for 'ietf-sid-file' | Figure 1: YANG Tree for 'ietf-sid-file' | |||
5. ".sid" File YANG Module | 5. ".sid" File YANG Module | |||
The following YANG module defines the structure of this file. | The following YANG module defines the structure of ".sid" files. | |||
Encoding is performed in JSON [RFC8259] using the rules defined in | Encoding is performed in JSON [RFC8259] using the rules defined in | |||
[RFC7951]. This module imports 'ietf-yang-types' [RFC6991] and | [RFC7951]. This module imports 'ietf-yang-types' [RFC6991] and | |||
'ietf-yang-structure-ext' [RFC8791]. It also references [RFC7950] | 'ietf-yang-structure-ext' [RFC8791]. It also references [STD68], | |||
and [RFC8407]. | [RFC7950], and [RFC8407]. | |||
<CODE BEGINS> file "ietf-sid-file@2024-06-17.yang" | <CODE BEGINS> file "ietf-sid-file@2024-06-17.yang" | |||
module ietf-sid-file { | module ietf-sid-file { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; | namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; | |||
prefix sid; | prefix sid; | |||
import ietf-yang-types { | import ietf-yang-types { | |||
prefix yang; | prefix yang; | |||
reference | reference | |||
skipping to change at line 572 ¶ | skipping to change at line 573 ¶ | |||
WG List: <mailto:core@ietf.org> | WG List: <mailto:core@ietf.org> | |||
Editor: Michel Veillette | Editor: Michel Veillette | |||
<mailto:michel.veillette@trilliant.com> | <mailto:michel.veillette@trilliant.com> | |||
Editor: Andy Bierman | Editor: Andy Bierman | |||
<mailto:andy@yumaworks.com> | <mailto:andy@yumaworks.com> | |||
Editor: Alexander Pelov | Editor: Alexander Pelov | |||
<mailto:a@ackl.io> | <mailto:alexander.pelov@imt-atlantique.fr> | |||
Editor: Ivaylo Petrov | Editor: Ivaylo Petrov | |||
<mailto:ivaylopetrov@google.com>"; | <mailto:ivaylopetrov@google.com>"; | |||
description | description | |||
"This module defines the structure of the '.sid' files. | "This module defines the structure of the '.sid' files. | |||
Each '.sid' file contains the mapping between each | Each '.sid' file contains the mapping between each | |||
string identifier defined by a YANG module and a | string identifier defined by a YANG module and a | |||
corresponding numeric value called a YANG-SID. | corresponding numeric value called a YANG-SID. | |||
skipping to change at line 598 ¶ | skipping to change at line 599 ¶ | |||
they appear in all capitals, as shown here. | they appear in all capitals, as shown here. | |||
Copyright (c) 2024 IETF Trust and the persons identified as | Copyright (c) 2024 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Revised BSD License set | the license terms contained in, the Revised BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info)."; | (https://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC 9595; see | ||||
the RFC itself for full legal notices."; | ||||
revision 2024-06-17 { | revision 2024-06-17 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC 9595: YANG Data Model for YANG Schema Item iDentifiers | "RFC 9595: YANG Data Model for YANG Schema Item iDentifiers | |||
(YANG-SIDs)"; | (YANG-SIDs)"; | |||
} | } | |||
typedef revision-identifier { | typedef revision-identifier { | |||
skipping to change at line 654 ¶ | skipping to change at line 658 ¶ | |||
This string additionally follows the following rules: | This string additionally follows the following rules: | |||
- The leftmost (top-level) data node name is always in the | - The leftmost (top-level) data node name is always in the | |||
namespace-qualified form. | namespace-qualified form. | |||
- Any subsequent schema-node name is in the | - Any subsequent schema-node name is in the | |||
namespace-qualified form if the node is defined in a | namespace-qualified form if the node is defined in a | |||
module other than its parent node. Otherwise, the | module other than its parent node. Otherwise, the | |||
simple form is used. No predicates are allowed."; | simple form is used. No predicates are allowed."; | |||
reference | reference | |||
"RFC 7950: The YANG 1.1 Data Modeling Language, | "RFC 5234 (STD 68): Augmented BNF for Syntax Specifications: | |||
ABNF | ||||
RFC 7950: The YANG 1.1 Data Modeling Language, | ||||
Section 6.5: Schema Node Identifier"; | Section 6.5: Schema Node Identifier"; | |||
} | } | |||
sx:structure sid-file { | sx:structure sid-file { | |||
uses sid-file-contents; | uses sid-file-contents; | |||
} | } | |||
grouping sid-file { | grouping sid-file { | |||
description | description | |||
"A grouping that contains a YANG container | "A grouping that contains a YANG container | |||
skipping to change at line 709 ¶ | skipping to change at line 715 ¶ | |||
leaf sid-file-version { | leaf sid-file-version { | |||
type sid-file-version-identifier; | type sid-file-version-identifier; | |||
default "0"; | default "0"; | |||
description | description | |||
"Optional leaf that specifies the version number of the | "Optional leaf that specifies the version number of the | |||
'.sid' file. '.sid' files and the version sequence are | '.sid' file. '.sid' files and the version sequence are | |||
specific to a given YANG module revision. This number | specific to a given YANG module revision. This number | |||
starts at zero when there is a new YANG module revision | starts at zero when there is a new YANG module revision | |||
and increases monotonically. This number can distinguish | and increases monotonically. This number can distinguish | |||
updates to the '.sid' file that are the result of new | updates to the '.sid' file - for instance, as the result | |||
processing or reported errata."; | of new processing or reported errata."; | |||
} | } | |||
leaf sid-file-status { | leaf sid-file-status { | |||
type enumeration { | type enumeration { | |||
enum unpublished { | enum unpublished { | |||
description | description | |||
"This '.sid' file is unpublished (RFC 8407) and is | "This '.sid' file is unpublished (RFC 8407) and is | |||
also called a work-in-progress or workfile. | also called a work-in-progress or workfile. | |||
This may be when it accompanies an unpublished YANG | This may be when it accompanies an unpublished YANG | |||
module or when only the '.sid' file itself is | module or when only the '.sid' file itself is | |||
unpublished. | unpublished. | |||
The 'item' list MAY contain entries with a status | The 'item' list MAY contain entries with a status | |||
value of 'unstable'."; | value of 'unstable'."; | |||
reference | reference | |||
"RFC 8407: Guidelines for Authors and Reviewers of | "RFC 8407: Guidelines for Authors and Reviewers of | |||
Documents Containing YANG Data Models"; | Documents Containing YANG Data Models"; | |||
} | } | |||
enum published { | enum published { | |||
description | description | |||
"This '.sid' file is published, for a published YANG | "This '.sid' file is published. This status | |||
module. The 'item' list MUST NOT contain entries | applies to '.sid' files for published YANG modules. | |||
with a status value of 'unstable'."; | The 'item' list MUST NOT contain entries with a | |||
status value of 'unstable'."; | ||||
} | } | |||
} | } | |||
default "published"; | default "published"; | |||
description | description | |||
"Optional leaf that specifies the status of the | "Optional leaf that specifies the status of the | |||
'.sid' file."; | '.sid' file."; | |||
} | } | |||
leaf description { | leaf description { | |||
type string; | type string; | |||
skipping to change at line 754 ¶ | skipping to change at line 761 ¶ | |||
"Free-form meta-information about the generated file. It | "Free-form meta-information about the generated file. It | |||
might include a '.sid' file generation tool and time, | might include a '.sid' file generation tool and time, | |||
among other things."; | among other things."; | |||
} | } | |||
list dependency-revision { | list dependency-revision { | |||
key "module-name"; | key "module-name"; | |||
description | description | |||
"Information about the revision used during the | "Information about the revision used during the | |||
'.sid' file generation of each YANG module that the | '.sid' file generation of each dependency, i.e., each | |||
module in 'module-name' imported."; | YANG module that the YANG module associated with this | |||
'.sid' file imported."; | ||||
leaf module-name { | leaf module-name { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
description | description | |||
"Name of the YANG module, dependency of 'module-name', | "YANG module name of this dependency."; | |||
for which revision information is provided."; | ||||
} | } | |||
leaf module-revision { | leaf module-revision { | |||
type revision-identifier; | type revision-identifier; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"Revision of the YANG module, dependency of | "Revision of the YANG module of this dependency."; | |||
'module-name', for which revision information is | ||||
provided."; | ||||
} | } | |||
} | } | |||
list assignment-range { | list assignment-range { | |||
key "entry-point"; | key "entry-point"; | |||
description | description | |||
"YANG-SID Range(s) allocated to the YANG module | "YANG-SID Range(s) allocated to the YANG module | |||
identified by 'module-name' and 'module-revision'. | identified by 'module-name' and 'module-revision'. | |||
- The first available value in the YANG-SID Range is | - The first available value in the YANG-SID Range is | |||
skipping to change at line 868 ¶ | skipping to change at line 873 ¶ | |||
description | description | |||
"All feature names defined in a module and its | "All feature names defined in a module and its | |||
submodules share the same feature identifier | submodules share the same feature identifier | |||
namespace."; | namespace."; | |||
} | } | |||
enum data { | enum data { | |||
value 3; | value 3; | |||
description | description | |||
"The namespace for all data nodes, as defined in | "The namespace for all data nodes, as defined in | |||
YANG."; | YANG."; | |||
reference | ||||
"RFC 7950: The YANG 1.1 Data Modeling Language"; | ||||
} | } | |||
} | } | |||
description | description | |||
"Namespace of the YANG item for this mapping entry."; | "Namespace of the YANG item for this mapping entry."; | |||
} | } | |||
leaf identifier { | leaf identifier { | |||
type union { | type union { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
type schema-node-path; | type schema-node-path; | |||
skipping to change at line 1005 ¶ | skipping to change at line 1008 ¶ | |||
A registry of YANG-SID Ranges MUST provide the following | A registry of YANG-SID Ranges MUST provide the following | |||
information for all YANG-SID Ranges allocated by the registry: | information for all YANG-SID Ranges allocated by the registry: | |||
- The entry point of the allocated YANG-SID Range. | - The entry point of the allocated YANG-SID Range. | |||
- The size of the allocated YANG-SID Range. | - The size of the allocated YANG-SID Range. | |||
- Type: Public or Private. | - Type: Public or Private. | |||
o Public ranges MUST include at least a reference to the YANG | o Public ranges MUST include at least a reference to the YANG | |||
module and ".sid" files for that YANG-SID Range (e.g., | module and ".sid" files for that YANG-SID Range (e.g., see | |||
compare Section 7.4.3 for the "IETF YANG-SID Modules" | Section 7.4.3 as an example for how this is handled for the | |||
registry). | "IETF YANG-SID Ranges" registry). | |||
o Private ranges MUST be marked as "Private". | o Private ranges MUST be marked as "Private". | |||
* A policy of allocation, which clearly identifies whether the YANG- | * A policy of allocation, which clearly identifies whether the YANG- | |||
SID Range allocations would be Private, Public, or both. | SID Range allocations would be Private, Public, or both. | |||
* Technical capacity to provide or refer to ".sid" files in a way | * Technical capacity to provide or refer to ".sid" files in a way | |||
that meets the security objective of data integrity for these | that meets the security objective of data integrity for these | |||
files (see also Section 6). | files (see also Section 6). | |||
skipping to change at line 1061 ¶ | skipping to change at line 1064 ¶ | |||
|Entry|Size |Allocation|Organization| URL | | |Entry|Size |Allocation|Organization| URL | | |||
|Point| | |Name | | | |Point| | |Name | | | |||
+=====+=========+==========+============+=========================+ | +=====+=========+==========+============+=========================+ | |||
|0 |1,000,000|Public |IANA | <https://www.iana.org/> | | |0 |1,000,000|Public |IANA | <https://www.iana.org/> | | |||
+-----+---------+----------+------------+-------------------------+ | +-----+---------+----------+------------+-------------------------+ | |||
Table 2: YANG-SID Mega-Ranges Registry: Initial Assignment | Table 2: YANG-SID Mega-Ranges Registry: Initial Assignment | |||
7.4. New IANA Registry: IETF YANG-SID Ranges | 7.4. New IANA Registry: IETF YANG-SID Ranges | |||
The name of this registry is "IETF YANG-SID Ranges". This registry | ||||
is used to record information related to the assignment of SID Ranges | ||||
(e.g., entry point and size) to YANG modules identified by module | ||||
name. | ||||
7.4.1. Structure | 7.4.1. Structure | |||
Each entry in this registry must include: | Each entry in this registry must include: | |||
* The SID range entry point. | * The SID range entry point. | |||
* The SID range size. | * The SID range size. | |||
* The YANG module name. | * The YANG module name. | |||
* A document reference (the document making the registration). | * A document reference (the document making the registration). | |||
7.4.2. Allocation Policy | 7.4.2. Allocation Policy | |||
The first million SIDs assigned to IANA is subdivided as follows: | The first million SIDs assigned to IANA are subdivided as follows: | |||
* The range of 0 to 999 (size 1,000) is subject to "IESG Approval" | * The range of 0 to 999 (size 1,000) is subject to "IESG Approval" | |||
as defined in [RFC8126]; of these, SID value 0 has been reserved | as defined in [RFC8126]; of these, SID value 0 has been reserved | |||
for implementations to internally signify the absence of a SID | for implementations to internally signify the absence of a SID | |||
number and does not occur in interchange. | number and does not occur in interchange. | |||
* The ranges of 1,000 to 59,999 (size 59,000) and 100,000 to 299,999 | * The ranges of 1,000 to 59,999 (size 59,000) and 100,000 to 299,999 | |||
(size 200,000) are designated for YANG modules defined in RFCs. | (size 200,000) are designated for YANG modules defined in RFCs. | |||
- The IANA policy for additions to this registry is: | - The IANA policy for additions to this registry is: | |||
o "Expert Review" [RFC8126] if the ".sid" file comes from a | 1. "Expert Review" [RFC8126] if the ".sid" file comes from a | |||
YANG module from an existing RFC. | YANG module from an existing RFC. | |||
o "RFC Required" [RFC8126] otherwise. | 2. "RFC Required" [RFC8126] otherwise. | |||
- The expert MUST verify that the YANG module for which this | - The expert MUST verify that the YANG module for which this | |||
allocation is made has an RFC (existing RFC) OR is on track to | allocation is made has an RFC (existing RFC) OR is on track to | |||
become an RFC (Early Allocation with a request from the working | become an RFC (Early Allocation with a request from the working | |||
group chairs as defined by [BCP100]). | group chairs as defined by [BCP100]). | |||
* The range of 60,000 to 99,999 (size 40,000) is reserved for | * The range of 60,000 to 99,999 (size 40,000) is reserved for | |||
experimental YANG modules. This range MUST NOT be used in | experimental YANG modules. This range MUST NOT be used in | |||
operational deployments, since these SIDs are not globally unique | operational deployments, since these SIDs are not globally unique | |||
and their interoperability is therefore limited. The IANA policy | and their interoperability is therefore limited. The IANA policy | |||
for this range is "Experimental Use" [RFC8126]. | for this range is "Experimental Use" [RFC8126]. | |||
* The range of 300,000 to 999,999 (size 700,000) is "Reserved" as | * The range of 300,000 to 999,999 (size 700,000) is "Reserved" as | |||
defined in [RFC8126]. | defined in [RFC8126]. | |||
+=============+=========+==========================+ | +=============+=========+=================================+ | |||
| Entry Point | Size | IANA Policy | | | Entry Point | Size | IANA Policy | | |||
+=============+=========+==========================+ | +=============+=========+=================================+ | |||
| 0 | 1,000 | IESG Approval | | | 0 | 1,000 | IESG Approval | | |||
+-------------+---------+--------------------------+ | +-------------+---------+---------------------------------+ | |||
| 1,000 | 59,000 | RFC Required | | | 1,000 | 59,000 | RFC Required (see item 2 above) | | |||
+-------------+---------+--------------------------+ | +-------------+---------+---------------------------------+ | |||
| 60,000 | 40,000 | Experimental/Private Use | | | 60,000 | 40,000 | Reserved for Experimental Use | | |||
+-------------+---------+--------------------------+ | +-------------+---------+---------------------------------+ | |||
| 100,000 | 200,000 | RFC Required | | | 100,000 | 200,000 | RFC Required (see item 2 above) | | |||
+-------------+---------+--------------------------+ | +-------------+---------+---------------------------------+ | |||
| 300,000 | 700,000 | Reserved | | | 300,000 | 700,000 | Reserved | | |||
+-------------+---------+--------------------------+ | +-------------+---------+---------------------------------+ | |||
Table 3: IETF YANG-SID Ranges Registry: Ranges | Table 3: IETF YANG-SID Ranges Registry: Policies for | |||
IETF Ranges | ||||
The size of the SID range allocated for a YANG module is recommended | The size of the SID range allocated for a YANG module is recommended | |||
to be a multiple of 50 and to be at least 33% above the current | to be a multiple of 50 and to be at least 33% above the current | |||
number of YANG items. This headroom allows assignments within the | number of YANG items. This headroom allows assignments within the | |||
same range of new YANG items introduced by subsequent revisions. The | same range of new YANG items introduced by subsequent revisions. The | |||
SID range size SHOULD NOT exceed 1,000; a larger size may be | SID range size SHOULD NOT exceed 1,000; a larger size may be | |||
requested by the authors if this recommendation is considered | requested by the authors if this recommendation is considered | |||
insufficient. It is important to note that an additional SID range | insufficient. It is important to note that an additional SID range | |||
can be allocated to an existing YANG module if the initial range is | can be allocated to an existing YANG module if the initial range is | |||
exhausted; this then just leads to a slightly less efficient | exhausted; this then just leads to a slightly less efficient | |||
skipping to change at line 1200 ¶ | skipping to change at line 1209 ¶ | |||
7.4.4. Initial Contents of the Registry | 7.4.4. Initial Contents of the Registry | |||
Initial entries in this registry are as follows: | Initial entries in this registry are as follows: | |||
+=====+====+================================+=====================+ | +=====+====+================================+=====================+ | |||
|Entry|Size|Module Name |Reference | | |Entry|Size|Module Name |Reference | | |||
|Point| | | | | |Point| | | | | |||
+=====+====+================================+=====================+ | +=====+====+================================+=====================+ | |||
| 0| 1|(Reserved: not a valid SID) |RFC 9595 | | | 0| 1|(Reserved: not a valid SID) |RFC 9595 | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,000| 100|ietf-coreconf |[CORE-COMI] | | |1,000| 100|ietf-coreconf |RFC 9595, [CORE-COMI]| | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,100| 50|ietf-yang-types |[RFC6991] | | |1,100| 50|ietf-yang-types |[RFC6991] | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,150| 50|ietf-inet-types |[RFC6991] | | |1,150| 50|ietf-inet-types |[RFC6991] | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,200| 50|iana-crypt-hash |[RFC7317] | | |1,200| 50|iana-crypt-hash |[RFC7317] | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,250| 50|ietf-netconf-acm |[RFC8341] | | |1,250| 50|ietf-netconf-acm |[RFC8341] | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|1,300| 50|ietf-sid-file |RFC 9595 | | |1,300| 50|ietf-sid-file |RFC 9595 | | |||
skipping to change at line 1230 ¶ | skipping to change at line 1239 ¶ | |||
|2,400| 50|ietf-voucher |[RFC8366] | | |2,400| 50|ietf-voucher |[RFC8366] | | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|2,450| 50|ietf-constrained-voucher |[CONSTRAINED-VOUCHER]| | |2,450| 50|ietf-constrained-voucher |[CONSTRAINED-VOUCHER]| | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
|2,500| 50|ietf-constrained-voucher-request|[CONSTRAINED-VOUCHER]| | |2,500| 50|ietf-constrained-voucher-request|[CONSTRAINED-VOUCHER]| | |||
+-----+----+--------------------------------+---------------------+ | +-----+----+--------------------------------+---------------------+ | |||
Table 4: IETF YANG-SID Ranges Registry: Initial Range Assignments | Table 4: IETF YANG-SID Ranges Registry: Initial Range Assignments | |||
For allocation, RFC publication of the YANG module is required as per | For allocation, RFC publication of the YANG module is required as per | |||
[RFC8126]. The YANG module must be registered in the "YANG Module | the "RFC Required" policy defined in Section 4.7 of [RFC8126]. The | |||
Names" registry according to the rules specified in Section 14 of | YANG module must be registered in the "YANG Module Names" registry | |||
[RFC6020]. | according to the rules specified in Section 14 of [RFC6020]. | |||
7.5. New IANA Registry: IETF YANG-SID Modules | 7.5. New IANA Registry: IETF YANG-SID Modules | |||
The name of this registry is "IETF YANG-SID Modules". This registry | The name of this registry is "IETF YANG-SID Modules". This registry | |||
is used to record the allocation of SIDs for individual YANG module | is used to record the allocation of SIDs for individual YANG module | |||
items. | items. | |||
7.5.1. Structure | 7.5.1. Structure | |||
Each entry in this registry must include: | Each entry in this registry must include: | |||
skipping to change at line 1282 ¶ | skipping to change at line 1291 ¶ | |||
* If another ".sid" file has already allocated SIDs for this YANG | * If another ".sid" file has already allocated SIDs for this YANG | |||
module (e.g., for older or newer versions of the YANG module), the | module (e.g., for older or newer versions of the YANG module), the | |||
YANG items are assigned the same SIDs as those in the other ".sid" | YANG items are assigned the same SIDs as those in the other ".sid" | |||
file. | file. | |||
* If there is an older version of the ".sid" file, all allocated | * If there is an older version of the ".sid" file, all allocated | |||
SIDs from that version are still present in the current version of | SIDs from that version are still present in the current version of | |||
the ".sid" file. | the ".sid" file. | |||
7.5.3. Recursive Allocation of YANG-SID Range at Document Adoption | 7.5.3. Recursive Allocation of YANG-SIDs at Document Adoption | |||
Due to the difficulty in changing SID values during IETF document | Due to the difficulty in changing SID values during IETF document | |||
processing, it is expected that most documents will ask for SID range | processing, it is expected that most documents will ask for SID range | |||
allocations using Early Allocations [BCP100]. The details of the | allocations using Early Allocations [BCP100]. The details of the | |||
Early Allocation to be requested, including the timeline envisioned, | Early Allocation to be requested, including the timeline envisioned, | |||
should be included in any working group adoption call. Prior to | should be included in any working group adoption call. Prior to | |||
working group adoption, an Internet-Draft author can use the | working group adoption, an Internet-Draft author can use the | |||
experimental SID range (as per Section 7.4.2) for their SID | experimental SID range (as per Section 7.4.2) for their SID | |||
allocations or other values that do not create ambiguity with other | allocations or other values that do not create ambiguity with other | |||
SID uses (for example, they can use a range that comes from a non- | SID uses (for example, they can use ranges and SIDs registered in a | |||
IANA-managed registry of YANG-SID Mega-Ranges). | non-IANA-managed registry that is based on a YANG-SID mega-range | |||
assignment). | ||||
After working group adoption, any modification of a ".sid" file is | After working group adoption, any modification of a ".sid" file is | |||
expected to be discussed on the mailing lists of the appropriate | expected to be discussed on the mailing lists of the appropriate | |||
working groups. Specific attention should be paid to implementers' | working groups. Specific attention should be paid to implementers' | |||
opinions after Working Group Last Call if a SID value is to change | opinions after Working Group Last Call if a SID value is to change | |||
its meaning. In all cases, a ".sid" file and the SIDs associated | its meaning. In all cases, a ".sid" file and the SIDs associated | |||
with it are subject to change before the publication of an Internet- | with it are subject to change before the publication of an Internet- | |||
Draft as an RFC. | Draft as an RFC. | |||
As new SIDs are first used, many existing, previously published YANG | As the concept of SIDs is first used, many existing, previously | |||
modules will not have SID allocations. For an allocation to be | published YANG modules will not have SID allocations. For an | |||
useful, the included YANG modules may also need to have SID | allocation to be useful, the included YANG modules may also need to | |||
allocations made, in a process that will generally be analogous to | have SID allocations made, in a process that will generally be | |||
that in Section 7.4.3 for the type-3 (SID-oblivious) case. | analogous to that in Section 7.4.3 for the type-3 (SID-oblivious) | |||
case. | ||||
The expert reviewer who performs the (Early) Allocation analysis will | The expert reviewer who performs the (Early) Allocation analysis will | |||
need to go through the list of included YANG modules and perform SID | need to go through the list of included YANG modules and perform SID | |||
allocations for those modules as well. | allocations for those modules as well. | |||
* If the document is a published RFC, then the allocation of SIDs | * If the document is a published RFC, then the allocation of SIDs | |||
for its referenced YANG modules is permanent. The expert reviewer | for its referenced YANG modules is permanent. The expert reviewer | |||
provides the generated ".sid" file to IANA for registration. | provides the generated ".sid" file to IANA for registration. | |||
* If the document is an unprocessed Internet-Draft adopted in a | * If the document is an unprocessed Internet-Draft adopted in a | |||
working group, then an Early Allocation is performed for this | working group, then an Early Allocation is performed for this | |||
document as well. Early Allocations require approval by an IESG | document as well. Early Allocations require approval by an IESG | |||
area director. An Early Allocation that requires additional | area director. An Early Allocation that requires additional | |||
allocations will list the other allocations in its description and | allocations will list the other allocations in its description and | |||
will be cross-posted to the mailing lists of any other working | will be cross-posted to the mailing lists of any other working | |||
groups concerned. | groups concerned. | |||
* A YANG module that references a module in a document that has not | * A YANG module that references a module in a document that has not | |||
yet been adopted by any working group will be unable to perform an | yet been adopted by any working group will be unable to perform an | |||
Early Allocation for that other document until it is adopted by a | Early Allocation for that other document until it is adopted by a | |||
working group. As described in [BCP100], an AD-sponsored document | working group. As described in Section 3 of RFC 7120 [BCP100], a | |||
acts as if it had a working group. The approving AD may also | shepherding AD will stand in for the working group chairs if the | |||
exempt a document from this policy by agreeing to AD-sponsor the | document is not the product of an IETF working group, effectively | |||
document. | allowing the AD to exempt a document from this policy. | |||
At the end of the IETF process, all the dependencies of a given | At the end of the IETF process, all the dependencies of a given | |||
module for which SIDs are assigned should also have SIDs assigned. | module for which SIDs are assigned should also have SIDs assigned. | |||
Those dependencies' assignments should be permanent (not Early | Those dependencies' assignments should be permanent (not Early | |||
Allocation). | Allocation). | |||
A previously SID-allocated YANG module that changes its references to | A previously SID-allocated YANG module that changes its references to | |||
include a YANG module for which there is no SID allocation needs to | include a YANG module for which there is no SID allocation needs to | |||
repeat the Early Allocation process. | repeat the Early Allocation process. | |||
skipping to change at line 1447 ¶ | skipping to change at line 1458 ¶ | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, | DOI 10.17487/RFC3688, January 2004, | |||
<https://www.rfc-editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
and A. Bierman, Ed., "Network Configuration Protocol | ||||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
<https://www.rfc-editor.org/info/rfc6241>. | ||||
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | |||
RFC 6991, DOI 10.17487/RFC6991, July 2013, | RFC 6991, DOI 10.17487/RFC6991, July 2013, | |||
<https://www.rfc-editor.org/info/rfc6991>. | <https://www.rfc-editor.org/info/rfc6991>. | |||
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | |||
RFC 7950, DOI 10.17487/RFC7950, August 2016, | RFC 7950, DOI 10.17487/RFC7950, August 2016, | |||
<https://www.rfc-editor.org/info/rfc7950>. | <https://www.rfc-editor.org/info/rfc7950>. | |||
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", | [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", | |||
RFC 7951, DOI 10.17487/RFC7951, August 2016, | RFC 7951, DOI 10.17487/RFC7951, August 2016, | |||
skipping to change at line 1477 ¶ | skipping to change at line 1483 ¶ | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", STD 90, RFC 8259, | Interchange Format", STD 90, RFC 8259, | |||
DOI 10.17487/RFC8259, December 2017, | DOI 10.17487/RFC8259, December 2017, | |||
<https://www.rfc-editor.org/info/rfc8259>. | <https://www.rfc-editor.org/info/rfc8259>. | |||
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
Access Control Model", STD 91, RFC 8341, | ||||
DOI 10.17487/RFC8341, March 2018, | ||||
<https://www.rfc-editor.org/info/rfc8341>. | ||||
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data | [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data | |||
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | |||
June 2020, <https://www.rfc-editor.org/info/rfc8791>. | June 2020, <https://www.rfc-editor.org/info/rfc8791>. | |||
[STD68] Internet Standard 68, | ||||
<https://www.rfc-editor.org/info/std68>. | ||||
At the time of writing, this STD comprises the following: | ||||
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | ||||
Specifications: ABNF", STD 68, RFC 5234, | ||||
DOI 10.17487/RFC5234, January 2008, | ||||
<https://www.rfc-editor.org/info/rfc5234>. | ||||
8.2. Informative References | 8.2. Informative References | |||
[CONSTRAINED-VOUCHER] | [CONSTRAINED-VOUCHER] | |||
Richardson, M., van der Stok, P., Kampanakis, P., and E. | Richardson, M., van der Stok, P., Kampanakis, P., and E. | |||
Dijk, "Constrained Bootstrapping Remote Secure Key | Dijk, "Constrained Bootstrapping Remote Secure Key | |||
Infrastructure (cBRSKI)", Work in Progress, Internet- | Infrastructure (cBRSKI)", Work in Progress, Internet- | |||
Draft, draft-ietf-anima-constrained-voucher-24, 3 March | Draft, draft-ietf-anima-constrained-voucher-24, 3 March | |||
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
anima-constrained-voucher-24>. | anima-constrained-voucher-24>. | |||
skipping to change at line 1519 ¶ | skipping to change at line 1529 ¶ | |||
[PYANG] Björklund, M., "An extensible YANG validator and converter | [PYANG] Björklund, M., "An extensible YANG validator and converter | |||
in python", commit 25f69e8, March 2024, | in python", commit 25f69e8, March 2024, | |||
<https://github.com/mbj4668/pyang>. | <https://github.com/mbj4668/pyang>. | |||
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
the Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
DOI 10.17487/RFC6020, October 2010, | DOI 10.17487/RFC6020, October 2010, | |||
<https://www.rfc-editor.org/info/rfc6020>. | <https://www.rfc-editor.org/info/rfc6020>. | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
and A. Bierman, Ed., "Network Configuration Protocol | ||||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
<https://www.rfc-editor.org/info/rfc6241>. | ||||
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", | [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", | |||
RFC 7224, DOI 10.17487/RFC7224, May 2014, | RFC 7224, DOI 10.17487/RFC7224, May 2014, | |||
<https://www.rfc-editor.org/info/rfc7224>. | <https://www.rfc-editor.org/info/rfc7224>. | |||
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
Constrained-Node Networks", RFC 7228, | Constrained-Node Networks", RFC 7228, | |||
DOI 10.17487/RFC7228, May 2014, | DOI 10.17487/RFC7228, May 2014, | |||
<https://www.rfc-editor.org/info/rfc7228>. | <https://www.rfc-editor.org/info/rfc7228>. | |||
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for | [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for | |||
skipping to change at line 1541 ¶ | skipping to change at line 1556 ¶ | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | |||
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8340>. | <https://www.rfc-editor.org/info/rfc8340>. | |||
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
Access Control Model", STD 91, RFC 8341, | ||||
DOI 10.17487/RFC8341, March 2018, | ||||
<https://www.rfc-editor.org/info/rfc8341>. | ||||
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface | [RFC8343] Bjorklund, M., "A YANG Data Model for Interface | |||
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, | Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8343>. | <https://www.rfc-editor.org/info/rfc8343>. | |||
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", | [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", | |||
RFC 8344, DOI 10.17487/RFC8344, March 2018, | RFC 8344, DOI 10.17487/RFC8344, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8344>. | <https://www.rfc-editor.org/info/rfc8344>. | |||
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, | [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, | |||
"A Voucher Artifact for Bootstrapping Protocols", | "A Voucher Artifact for Bootstrapping Protocols", | |||
skipping to change at line 2094 ¶ | skipping to change at line 2114 ¶ | |||
the discretion of the YANG module author, who should decide if the | the discretion of the YANG module author, who should decide if the | |||
benefits of a manual intervention are worth the deviation from | benefits of a manual intervention are worth the deviation from | |||
automatic assignment. | automatic assignment. | |||
In the case of an update to an existing ".sid" file, an additional | In the case of an update to an existing ".sid" file, an additional | |||
step is needed that increments the ".sid" file version number. If | step is needed that increments the ".sid" file version number. If | |||
there was no version number in the previous version of the ".sid" | there was no version number in the previous version of the ".sid" | |||
file, 0 is assumed to be the version number of the old version of the | file, 0 is assumed to be the version number of the old version of the | |||
".sid" file and the version number is 1 for the new ".sid" file. | ".sid" file and the version number is 1 for the new ".sid" file. | |||
Apart from that, changes to ".sid" files can also be automated using | Apart from that, changes to ".sid" files can also be automated using | |||
the same method as that described above, except that in step #3, only | the same method as that described above, except that in step #3, | |||
unassigned YANG items are processed. Already-existing items in the | previous SID assignments are kept, only previously unassigned YANG | |||
".sid" file should not be given new SIDs. | items are processed, and these are assigned previously unassigned | |||
SIDs. Already-existing items in the ".sid" file should not be given | ||||
new SIDs. | ||||
Note that ".sid" file versions are specific to a YANG module | Note that ".sid" file versions are specific to a YANG module | |||
revision. For each new YANG module or each new revision of an | revision. For each new YANG module or each new revision of an | |||
existing YANG module, the version number of the initial ".sid" file | existing YANG module, the version number of the initial ".sid" file | |||
either (1) should be 0 or (2) should not be present. | either (1) should be 0 or (2) should not be present. | |||
Note also that RPC or action "input" and "output" YANG items MUST | Note also that RPC or action "input" and "output" YANG items MUST | |||
always be assigned SIDs even if they don't contain further YANG | always be assigned SIDs even if they don't contain further YANG | |||
items. The reason for this requirement is that other modules can | items. The reason for this requirement is that other modules can | |||
augment the given module and those SIDs might be necessary. | augment the given module and those SIDs might be necessary. | |||
skipping to change at line 2188 ¶ | skipping to change at line 2210 ¶ | |||
v | v | |||
[DONE] | [DONE] | |||
Figure 4: SID Lifecycle | Figure 4: SID Lifecycle | |||
C.2. ".sid" File Update | C.2. ".sid" File Update | |||
The following activity diagram summarizes the update of a YANG module | The following activity diagram summarizes the update of a YANG module | |||
and its associated ".sid" file. | and its associated ".sid" file. | |||
+---------------+ | +------------------+ | |||
o | Update of the | | o | Update of the | | |||
-+- -->| YANG module | | -+- -->| YANG module, | | |||
/ \ | or include(s) | | / \ | its include(s), | | |||
| or import(s) | | | or its import(s) | | |||
+------+--------+ | +------+-----------+ | |||
| | | | |||
v | v | |||
.-------------. | .-------------. | |||
/ New items \ yes | / New items \ yes | |||
\ created? /------+ | \ created? /------+ | |||
'------+------' | | '------+------' | | |||
| no v | | no v | |||
| .-------------. +----------------+ | | .-------------. +----------------+ | |||
| / SID range \ yes | Extra subrange | | | / SID range \ yes | Extra subrange | | |||
| \ exhausted? /---->| assignment | | | \ exhausted? /---->| assignment | | |||
End of changes. 42 change blocks. | ||||
109 lines changed or deleted | 131 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |