< draft-ietf-core-sid-06.txt   draft-ietf-core-sid-07.txt >
Internet Engineering Task Force M. Veillette, Ed. Internet Engineering Task Force M. Veillette, Ed.
Internet-Draft Trilliant Networks Inc. Internet-Draft Trilliant Networks Inc.
Intended status: Standards Track A. Pelov, Ed. Intended status: Standards Track A. Pelov, Ed.
Expires: September 29, 2019 I. Petrov, Ed. Expires: January 9, 2020 I. Petrov, Ed.
Acklio Acklio
March 28, 2019 July 08, 2019
YANG Schema Item iDentifier (SID) YANG Schema Item iDentifier (SID)
draft-ietf-core-sid-06 draft-ietf-core-sid-07
Abstract Abstract
YANG Schema Item iDentifiers (SID) are globally unique 64-bit YANG Schema Item iDentifiers (SID) are globally unique 64-bit
unsigned numbers used to identify YANG items. This document defines unsigned integers used to identify YANG items. This document defines
the semantics, the registration, and assignment processes of SIDs. the semantics, the registration, and assignment processes of SIDs.
To enable the implementation of these processes, this document also To enable the implementation of these processes, this document also
defines a file format used to persist and publish assigned SIDs. defines a file format used to persist and publish assigned SIDs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 4 3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 4
4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 5 4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Register SID File Format Module . . . . . . . . . . . . . 9 6.1. Register SID File Format Module . . . . . . . . . . . . . 9
6.2. Create new IANA Registry: "SID Mega-Range" registry . . . 9 6.2. Create new IANA Registry: "SID Mega-Range" registry . . . 9
6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10 6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10
6.2.2.1. First allocation . . . . . . . . . . . . . . . . 11 6.2.2.1. First allocation . . . . . . . . . . . . . . . . 10
6.2.2.2. Consecutive allocations . . . . . . . . . . . . . 11 6.2.2.2. Consecutive allocations . . . . . . . . . . . . . 11
6.2.3. Initial contents of the Registry . . . . . . . . . . 11 6.2.3. Initial contents of the Registry . . . . . . . . . . 11
6.3. Create a new IANA Registry: IETF SID Range Registry 6.3. Create a new IANA Registry: IETF SID Range Registry
(managed by IANA) . . . . . . . . . . . . . . . . . . . . 11 (managed by IANA) . . . . . . . . . . . . . . . . . . . . 11
6.3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 11
6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 12 6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 11
6.3.3. Initial contents of the registry . . . . . . . . . . 13 6.3.3. Initial contents of the registry . . . . . . . . . . 12
6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 13 6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 13
6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 13 6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 13
6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14 6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14
6.4.3. Initial contents of the registry . . . . . . . . . . 14 6.4.3. Initial contents of the registry . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 16 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 16
Appendix B. SID auto generation . . . . . . . . . . . . . . . . 25 Appendix B. SID auto generation . . . . . . . . . . . . . . . . 25
Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 26 Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 25
C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 26 C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 26
C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 27 C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Some of the items defined in YANG [RFC7950] require the use of a Some of the items defined in YANG [RFC7950] require the use of a
unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040], unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040],
these identifiers are implemented using names. To allow the these identifiers are implemented using names. To allow the
implementation of data models defined in YANG in constrained devices implementation of data models defined in YANG in constrained devices
and constrained networks, a more compact method to identify YANG and constrained networks, a more compact method to identify YANG
items is required. This compact identifier, called SID, is encoded items is required. This compact identifier, called SID, is encoded
using a 64-bit unsigned integer. The following items are identified using a 64-bit unsigned integer. The following items are identified
using SIDs: using SIDs:
o identities o identities
o data nodes (Note: including those part of a YANG template as o data nodes (Note: including those parts of a YANG template as
defined by the 'yang-data' extension.) defined by the 'yang-data' extension.)
o RPCs and associated input(s) and output(s) o RPCs and associated input(s) and output(s)
o actions and associated input(s) and output(s) o actions and associated input(s) and output(s)
o notifications and associated information o notifications and associated information
o YANG modules, submodules and features o YANG modules, submodules and features
To minimize their size, in certain positions, SIDs could be SIDs are globally unique integers, a registration system is used in
represented using a (signed) delta from a reference SID and the
current SID (for example during transmissions). Such difference is
itself called "delta", shorthand for "delta-encoded SID". Conversion
from SIDs to deltas and back to SIDs is a stateless process. Each
protocol implementing deltas must unambiguously define the reference
SID for each YANG item.
SIDs are globally unique numbers, 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". called "SID ranges".
Assignment of SIDs to YANG items can be automated. For more details Assignment of SIDs to YANG items can be automated. For more details
how this could be achieved, please consult Appendix B. how this could be achieved, please consult Appendix B.
SIDs are assigned permanently, items introduced by a new revision of SIDs are assigned permanently, items introduced by a new revision of
a YANG module are added to the list of SIDs already assigned. a YANG module are added to the list of SIDs already assigned.
Section 3 provides more details about the registration process of Section 3 provides more details about the registration process of
YANG modules and associated SIDs. To enable the implementation of YANG modules and associated SIDs. To enable the implementation of
this registry, Section 4 defines a standard file format used to store this registry, Section 4 defines a standard file format used to store
and publish SIDs. and publish SIDs.
2. Terminology and Notation 2. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
o action o action
o feature o feature
o module o module
o notification o notification
o RPC o RPC
o schema node o schema node
o schema tree o schema tree
o submodule o submodule
The following term is defined in [RFC8040]: The following term is defined in [RFC8040]:
o yang-data extension o yang-data extension
skipping to change at page 4, line 22 skipping to change at page 4, line 16
o schema tree o schema tree
o submodule o submodule
The following term is defined in [RFC8040]: The following term is defined in [RFC8040]:
o yang-data extension o yang-data extension
This specification also makes use of the following terminology: This specification also makes use of the following terminology:
o delta : Difference between the current SID and a reference SID.
Each protocol that uses delta encoded SIDs MUST define how the
reference SID is obtained.
o item: A schema node, an identity, a module, a submodule or a o item: A schema node, an identity, a module, a submodule or a
feature defined using the YANG modeling language. feature defined using the YANG modeling language.
o path: A path is a string that identifies a schema node within the o path: A path is a string that identifies a schema node within the
schema tree. A path consists of the list of schema node schema tree. A path consists of the list of schema node
identifier(s) separated by slashes ("/"). Schema node identifier(s) separated by slashes ("/"). Schema node
identifier(s) are always listed from the top-level schema node up identifier(s) are always listed from the top-level schema node up
to the targeted schema node. (e.g. "/ietf-system:system- to the targeted schema node. (e.g. "/ietf-system:system-
state/clock/current-datetime") state/clock/current-datetime")
o YANG Schema Item iDentifier (SID): Unsigned integer used to o YANG Schema Item iDentifier (SID): Unsigned integer used to
identify different YANG items. identify different YANG items.
3. ".sid" file lifecycle 3. ".sid" file lifecycle
YANG is a language designed to model data accessed using one of the YANG is a language designed to model data accessed using one of the
compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and
CoMI [I-D.ietf-core-comi]). A YANG module defines hierarchies of CoRECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of
data, including configuration, state data, RPCs, actions and data, including configuration, state data, RPCs, actions and
notifications. notifications.
YANG modules are not necessarily created in the context of Many YANG modules are not created in the context of constrained
constrained applications. YANG modules can be implemented using applications. YANG modules can be implemented using NETCONF
NETCONF [RFC6241] or RESTCONF [RFC8040] without the need to assign [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.
SIDs.
As needed, authors of YANG modules can assign SIDs to their YANG As needed, authors of YANG modules can assign SIDs to their YANG
modules. In order to do that, they should first obtain a SID range modules. In order to do that, they should first obtain a SID range
from a registry and use that range to assign or generate SIDs to from a registry and use that range to assign or generate SIDs to
items of their YANG module. For example how this could be achieved, items of their YANG module. For example how this could be achieved,
please refer to Appendix C. please refer to Appendix C.
Registration of the .sid file associated to a YANG module is optional Registration of the .sid file associated to a YANG module is optional
but recommended to promote interoperability between devices and to but recommended to promote interoperability between devices and to
avoid duplicate allocation of SIDs to a single YANG module. avoid duplicate allocation of SIDs to a single YANG module.
skipping to change at page 9, line 23 skipping to change at page 9, line 12
mandatory true; mandatory true;
description description
"SID assigned to the YANG item for this mapping entry."; "SID assigned to the YANG item for this mapping entry.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Security Considerations 5. Security Considerations
The security considerations of [RFC7049] and [RFC7950] apply.
This document defines a new type of identifier used to encode data This document defines a new type of identifier used to encode data
models defined in YANG [RFC7950]. As such, this identifier does not models defined in YANG [RFC7950]. As such, this identifier does not
contribute to any new security issues in addition of those identified contribute to any new security issues in addition of those identified
for the specific protocols or contexts for which it is used. for the specific protocols or contexts for which it is used.
6. IANA Considerations 6. IANA Considerations
6.1. Register SID File Format Module 6.1. Register SID File Format Module
This document registers one YANG modules in the "YANG Module Names" This document registers one YANG module in the "YANG Module Names"
registry [RFC6020]: registry [RFC6020]:
o name: ietf-sid-file o name: ietf-sid-file
o namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file o namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file
o prefix: sid o prefix: sid
o reference: [[THISRFC]] o reference: [[THISRFC]]
6.2. Create new IANA Registry: "SID Mega-Range" registry 6.2. Create new IANA Registry: "SID Mega-Range" registry
The name of this registry is "SID Mega-Range". This registry is used The name of this registry is "SID Mega-Range". This registry is used
to record the delegation of the management of a block of SIDs to to record the delegation of the management of a block of SIDs to
third parties (e.g. SDOs, registrars, etc). third parties (such as SDOs or registrars).
6.2.1. Structure 6.2.1. Structure
Each entry in this registry must include: Each entry in this registry must include:
o The entry point (first SID) of the registered SID block. o The entry point (first SID) of the registered SID block.
o The size of the registered SID block. The size MUST be one o The size of the registered SID block. The size MUST be one
million (1 000 000) SIDs. million (1 000 000) SIDs.
skipping to change at page 10, line 19 skipping to change at page 10, line 4
o The entry point (first SID) of the registered SID block. o The entry point (first SID) of the registered SID block.
o The size of the registered SID block. The size MUST be one o The size of the registered SID block. The size MUST be one
million (1 000 000) SIDs. million (1 000 000) SIDs.
o The contact information of the requesting organization including: o The contact information of the requesting organization including:
* The policy of SID range allocations: Public, Private or Both. * The policy of SID range allocations: Public, Private or Both.
* Organization name * Organization name
* URL * URL
The information associated to the Organization name should not be The information associated to the Organization name should not be
publicly visible in the registry, but should be available. This publicly visible in the registry, but should be available. This
information includes contact email and phone number and change information includes contact email and phone number and change
controller email and phone number. controller email and phone number.
6.2.2. Allocation policy 6.2.2. Allocation policy
The IANA policies for future additions to this registry are "Expert The IANA policy for future additions to this registry is "Expert
Review" [RFC8126]. Review" [RFC8126].
An organization requesting to manage a SID Range (and thus have an An organization requesting to manage a SID Range (and thus have an
entry in the SID Mega-Range Registry), must ensure the following entry in the SID Mega-Range Registry), must ensure the following
capacities: capacities:
o The capacity to manage and operate a SID Range Registry. A SID o The capacity to manage and operate a SID Range Registry. A SID
Range Registry MUST provide the following information for all SID Range Registry MUST provide the following information for all SID
Ranges allocated by the Registry: Ranges allocated by the Registry:
skipping to change at page 11, line 24 skipping to change at page 11, line 14
6.2.2.2. Consecutive allocations 6.2.2.2. Consecutive allocations
On subsequent allocation request(s), the organization must On subsequent allocation request(s), the organization must
demonstrate the exhaustion of the prior range. These conditions need demonstrate the exhaustion of the prior range. These conditions need
to be asserted by the assigned expert(s). to be asserted by the assigned expert(s).
If that extra-allocation is done within 3 years from the last If that extra-allocation is done within 3 years from the last
allocation, the experts need to discuss this request on the CORE allocation, the experts need to discuss this request on the CORE
working group mailing list and consensus needs to be obtained before working group mailing list and consensus needs to be obtained before
allocating new Mega-Range. allocating a new Mega-Range.
6.2.3. Initial contents of the Registry 6.2.3. Initial contents of the Registry
The initial entry in this registry is allocated to IANA: The initial entry in this registry is allocated to IANA:
+-------------+---------+------------+-------------------+----------+ +-------------+---------+------------+-------------------+----------+
| Entry Point | Size | Allocation | Organization name | URL | | Entry Point | Size | Allocation | Organization name | URL |
+-------------+---------+------------+-------------------+----------+ +-------------+---------+------------+-------------------+----------+
| 0 | 1000000 | Public | IANA | iana.org | | 0 | 1000000 | Public | IANA | iana.org |
+-------------+---------+------------+-------------------+----------+ +-------------+---------+------------+-------------------+----------+
skipping to change at page 13, line 22 skipping to change at page 13, line 9
+-------------+---------+------------------+ +-------------+---------+------------------+
6.3.3. Initial contents of the registry 6.3.3. Initial contents of the registry
Initial entries in this registry are as follows: Initial entries in this registry are as follows:
+-------------+------+------------------+----------------------+ +-------------+------+------------------+----------------------+
| Entry Point | Size | Module name | Document reference | | Entry Point | Size | Module name | Document reference |
+-------------+------+------------------+----------------------+ +-------------+------+------------------+----------------------+
| 1000 | 100 | ietf-comi | [I-D.ietf-core-comi] | | 1000 | 100 | ietf-comi | [I-D.ietf-core-comi] |
| 1100 | 50 | ietf-yang-types | [RFC6021] | | 1100 | 50 | ietf-yang-types | [RFC6991] |
| 1150 | 50 | ietf-inet-types | [RFC6021] | | 1150 | 50 | ietf-inet-types | [RFC6991] |
| 1200 | 50 | iana-crypt-hash | [RFC7317] | | 1200 | 50 | iana-crypt-hash | [RFC7317] |
| 1250 | 50 | ietf-netconf-acm | [RFC6536] | | 1250 | 50 | ietf-netconf-acm | [RFC8341] |
| 1300 | 50 | ietf-sid-file | RFCXXXX | | 1300 | 50 | ietf-sid-file | RFCXXXX |
| 1500 | 100 | ietf-interfaces | [RFC7223] | | 1500 | 100 | ietf-interfaces | [RFC8343] |
| 1600 | 100 | ietf-ip | [RFC7277] | | 1600 | 100 | ietf-ip | [RFC8344] |
| 1700 | 100 | ietf-system | [RFC7317] | | 1700 | 100 | ietf-system | [RFC7317] |
| 1800 | 400 | iana-if-type | [RFC7224] | | 1800 | 400 | iana-if-type | [RFC7224] |
+-------------+------+------------------+----------------------+ +-------------+------+------------------+----------------------+
// RFC Ed.: replace XXXX with RFC number assigned to this draft. // RFC Ed.: replace XXXX with RFC number assigned to this draft.
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 [RFC8126]. The YANG module must be registered in the "YANG module
Name" registry according to the rules specified in section 14 of Name" registry according to the rules specified in section 14 of
[RFC6020]. [RFC6020].
6.4. Create new IANA Registry: "IETF SID Registry" 6.4. Create new IANA Registry: "IETF SID Registry"
The name of this registry is "IETF SID Registry". This registry is The name of this registry is "IETF SID Registry". This registry is
used to record the allocation of individual SIDs YANG module items. used to record the allocation of SIDs for individual YANG module
items.
6.4.1. Structure 6.4.1. Structure
Each entry in this registry must include: Each entry in this registry must include:
o The YANG module name. This module name must be present in the o The YANG module name. This module name must be present in the
"Name" column of the "YANG Module Names" registry. "Name" column of the "YANG Module Names" registry.
o A link to the associated ".yang" file. This file link must be o A link to the associated ".yang" file. This file link must be
present in the "File" column of the "YANG Module Names" registry. present in the "File" column of the "YANG Module Names" registry.
skipping to change at page 15, line 30 skipping to change at page 15, line 17
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[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,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-04 (work in Management Interface", draft-ietf-core-comi-05 (work in
progress), November 2018. progress), May 2019.
[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>.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, DOI 10.17487/RFC6021, October 2010,
<https://www.rfc-editor.org/info/rfc6021>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
Protocol (NETCONF) Access Control Model", RFC 6536, RFC 6991, DOI 10.17487/RFC6991, July 2013,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-editor.org/info/rfc6991>.
<https://www.rfc-editor.org/info/rfc6536>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[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>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<https://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[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>.
[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
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
Appendix A. ".sid" file example Appendix A. ".sid" file example
The following .sid file (ietf-system@2014-08-06.sid) have been The following .sid file (ietf-system@2014-08-06.sid) have been
generated using the following yang modules: generated using the following yang modules:
o ietf-system@2014-08-06.yang o ietf-system@2014-08-06.yang
o ietf-yang-types@2013-07-15.yang o ietf-yang-types@2013-07-15.yang
o ietf-inet-types@2013-07-15.yang o ietf-inet-types@2013-07-15.yang
skipping to change at page 25, line 40 skipping to change at page 25, line 28
module. module.
2. The list of items is sorted in alphabetical order, 'namespace' in 2. The list of items is sorted in alphabetical order, 'namespace' in
descending order, 'identifier' in ascending order. The descending order, 'identifier' in ascending order. The
'namespace' and 'identifier' formats are described in the YANG 'namespace' and 'identifier' formats are described in the YANG
module 'ietf-sid-file' defined in Section 4. module 'ietf-sid-file' defined in Section 4.
3. SIDs are assigned sequentially from the entry point up to the 3. SIDs are assigned sequentially from the entry point up to the
size of the registered SID range. This approach is recommended size of the registered SID range. This approach is recommended
to minimize the serialization overhead, especially when delta to minimize the serialization overhead, especially when delta
encoding is implemented. between a reference SID and the current SID is used by protocols
aiming to reduce message size.
4. If the number of items exceeds the SID range(s) allocated to a 4. If the number of items exceeds the SID range(s) allocated to a
YANG module, an extra range is added for subsequent assignments. YANG module, an extra range is added for subsequent assignments.
Changes of SID files can also be automated using the same method Changes of SID files can also be automated using the same method
described above, only unassigned YANG items are processed at step #3. described above, only unassigned YANG items are processed at step #3.
Already existing items in the SID file should not be given new SIDs.
Appendix C. ".sid" file lifecycle Appendix C. ".sid" file lifecycle
Before assigning SIDs to their YANG modules, YANG module authors must Before assigning SIDs to their YANG modules, YANG module authors must
acquire a SID range from a "SID Range Registry". If the YANG module acquire a SID range from a "SID Range Registry". If the YANG module
is part of an IETF draft or RFC, the SID range need to be acquired is part of an IETF draft or RFC, the SID range need to be acquired
from the "IETF SID Range Registry" as defined in Section 6.3. For from the "IETF SID Range Registry" as defined in Section 6.3. For
the other YANG modules, the authors can acquire a SID range from any the other YANG modules, the authors can acquire a SID range from any
"SID Range Registry" of their choice. "SID Range Registry" of their choice.
 End of changes. 36 change blocks. 
66 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/