draft-ietf-core-sid-08.txt   draft-ietf-core-sid-09.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: July 11, 2020 I. Petrov, Ed. Expires: July 26, 2020 I. Petrov, Ed.
Acklio Acklio
January 08, 2020 January 23, 2020
YANG Schema Item iDentifier (SID) YANG Schema Item iDentifier (SID)
draft-ietf-core-sid-08 draft-ietf-core-sid-09
Abstract Abstract
YANG Schema Item iDentifiers (SID) are globally unique 63-bit YANG Schema Item iDentifiers (SID) are globally unique 63-bit
unsigned integers 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 July 11, 2020. This Internet-Draft will expire on July 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10 6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10
6.2.2.1. First allocation . . . . . . . . . . . . . . . . 10 6.2.2.1. First allocation . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 11 6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 11
6.3.3. Initial contents of the registry . . . . . . . . . . 12 6.3.3. Initial contents of the registry . . . . . . . . . . 13
6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 13 6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 14
6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 13 6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14
6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14 6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14
6.4.3. Initial contents of the registry . . . . . . . . . . 14 6.4.3. Recursive Allocation of SID Range at Document
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 Adoption . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4.4. Initial contents of the registry . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix B. SID auto generation . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 25 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 18
C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 26 Appendix B. SID auto generation . . . . . . . . . . . . . . . . 27
C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 27 Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 28
C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 63-bit unsigned integer. The reason not to use 64-bit using a 63-bit unsigned integer. The limitation to 63-bit unsigned
unsigned integers is that otherwise protocols doing arithmetical integers allows SIDs to be manipulated more easily on platforms that
operations with the SIDs could be very difficult to implement. might otherwise lack native 64-bit unsigned arithmetic. The loss of
a single bit of range is not significant given the size of the
remaining space.
The following items are identified using SIDs: The following items are identified using SIDs:
o identities o identities
o data nodes (Note: including those parts 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)
skipping to change at page 13, line 5 skipping to change at page 13, line 9
| 0 | 1,000 | Reserved | | 0 | 1,000 | Reserved |
| 1,000 | 59,000 | Expert Review | | 1,000 | 59,000 | Expert Review |
| 60,000 | 40,000 | Experimental use | | 60,000 | 40,000 | Experimental use |
| 100,000 | 900,000 | Reserved | | 100,000 | 900,000 | Reserved |
+-------------+---------+------------------+ +-------------+---------+------------------+
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 | | Ent | Siz | Module name | Document reference |
+-------------+------+------------------+----------------------+ | ry | e | | |
| 1000 | 100 | ietf-comi | [I-D.ietf-core-comi] | | Poi | | | |
| 1100 | 50 | ietf-yang-types | [RFC6991] | | nt | | | |
| 1150 | 50 | ietf-inet-types | [RFC6991] | +-----+-----+--------------------------+----------------------------+
| 1200 | 50 | iana-crypt-hash | [RFC7317] | | 100 | 100 | ietf-comi | [I-D.ietf-core-comi] |
| 1250 | 50 | ietf-netconf-acm | [RFC8341] | | 0 | | | |
| 1300 | 50 | ietf-sid-file | RFCXXXX | | 110 | 50 | ietf-yang-types | [RFC6991] |
| 1500 | 100 | ietf-interfaces | [RFC8343] | | 0 | | | |
| 1600 | 100 | ietf-ip | [RFC8344] | | 115 | 50 | ietf-inet-types | [RFC6991] |
| 1700 | 100 | ietf-system | [RFC7317] | | 0 | | | |
| 1800 | 400 | iana-if-type | [RFC7224] | | 120 | 50 | iana-crypt-hash | [RFC7317] |
+-------------+------+------------------+----------------------+ | 0 | | | |
| 125 | 50 | ietf-netconf-acm | [RFC8341] |
| 0 | | | |
| 130 | 50 | ietf-sid-file | RFCXXXX |
| 0 | | | |
| 150 | 100 | ietf-interfaces | [RFC8343] |
| 0 | | | |
| 160 | 100 | ietf-ip | [RFC8344] |
| 0 | | | |
| 170 | 100 | ietf-system | [RFC7317] |
| 0 | | | |
| 180 | 400 | iana-if-type | [RFC7224] |
| 0 | | | |
| 240 | 50 | ietf-voucher | [RFC8366] |
| 0 | | | |
| 245 | 50 | ietf-constrained-voucher | [I-D.ietf-anima-constraine |
| 0 | | | d-voucher] |
| 250 | 50 | ietf-constrained- | [I-D.ietf-anima-constraine |
| 0 | | voucher-request | d-voucher] |
+-----+-----+--------------------------+----------------------------+
// 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"
skipping to change at page 13, line 43 skipping to change at page 14, line 21
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.
o The link to the ".sid" file which defines the allocation. o The link to the ".sid" file which defines the allocation. The
".sid" file is stored by IANA.
o The number of actually allocated SIDs in the ".sid" file. o The number of actually allocated SIDs in the ".sid" file.
The ".sid" file is stored by IANA.
6.4.2. Allocation policy 6.4.2. Allocation policy
The allocation policy is Expert review. The Expert MUST ensure that The allocation policy is Expert review. The Expert MUST ensure that
the following conditions are met: the following conditions are met:
o The ".sid" file has a valid structure: o The ".sid" file has a valid structure:
* The ".sid" file MUST be a valid JSON file following the * The ".sid" file MUST be a valid JSON file following the
structure of the module defined in RFCXXXX (RFC Ed: replace XXX structure of the module defined in RFCXXXX (RFC Ed: replace XXX
with RFC number assigned to this draft). with RFC number assigned to this draft).
skipping to change at page 14, line 30 skipping to change at page 15, line 5
* All SIDs in this ".sid" file MUST be within the ranges * All SIDs in this ".sid" file MUST be within the ranges
allocated to this YANG module in the "IETF SID Range Registry". allocated to this YANG module in the "IETF SID Range Registry".
o If another ".sid" file has already allocated SIDs for this YANG o 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 in the the other ".sid" YANG items are assigned the same SIDs as in the the other ".sid"
file. file.
o SIDs never change. o SIDs never change.
6.4.3. Initial contents of the registry 6.4.3. Recursive Allocation of SID Range at Document Adoption
Due to the difficulty in changing SID values during IETF document
processing, it is expected that most documents will ask for SID
allocations using Early Allocations [RFC7120]. The details of the
Early Allocation should be included in any Working Group Adoption
call. Prior to Working Group Adoption, an internet draft authors can
use the experimental SID range (as per Section 6.3.2) for their SIDs
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-IANA
managed "SID Mega-Range" registry).
After Working Group Adoption, any modification of a .sid file is
expected to be discussed on the mailing list of the appropriate
Working Groups. Specific attention should be paid to implementers'
opinion after Working Group Last Call if a SID value is to change its
meaning. In all cases, a .sid file and the SIDs associated with it
are subject to change before the publication of an internet draft as
an RFC.
During the early use of SIDs, many existing, previously published
YANG modules will not have SID allocations. For an allocation to be
useful the included YANG modules may also need to have SID
allocations made.
The Expert Reviewer who performs the (Early) Allocation analysis will
need to go through the list of included YANG modules and perform SID
allocations for those modules as well.
o If the document is a published RFC, then the allocation of SIDs
for its referenced YANG modules is permanent. The Expert Reviewer
provides the generated SID file to IANA for registration. This
process may be time consuming during a bootstrap period (there are
over 100 YANG modules to date, none of which have SID
allocations), but should quiet down once needed entries are
allocated.
o If the document is an unprocessed Internet-Draft adopted in a WG,
then an Early Allocation is performed for this document as well.
Early Allocations require approval by an IESG Area Director. An
early allocation which requires additional allocations will list
the other allocations in it's description, and will be cross-
posted to the any other working group mailing lists.
o A YANG module which references a module in an document which has
not 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 working group. As described in [RFC7120], an AD
Sponsored document acts as if it had a working group. The
approving AD may also exempt a document from this policy by
agreeing to AD Sponsor the document.
Critically, the original document should never get through the IETF
process and then be surprised to be referencing a document whose
progress is not certain.
A previously SID-allocated YANG module which changes its references
to include a YANG module for which there is no SID allocation needs
to repeat the Early Allocation process.
Early Allocations are made with a one-year period, after which they
are expired. [RFC7120] indicates that at most one renewal may be
made. For the SID allocation a far more lenient stance is desired.
1. An extension of a referencing documents Early Allocation should
update any referenced Early Allocations to expire no sooner than
the referencing document.
2. The [RFC7120] mechanism allows the IESG to provide a second
renewal, and such an event may prompt some thought about how the
collection of documents are being processed.
This is driven by the very generous size of the SID space and the
often complex and deep dependencies of YANG modules. Often a core
module with many dependencies will undergo extensive review, delaying
the publication of other documents.
[RFC7120] also says
Note that if a document is submitted for review to the IESG and at
the time of submission some early allocations are valid (not
expired), these allocations should not be expired while the document
is under IESG consideration or waiting in the RFC Editor's queue
after approval by the IESG.
6.4.4. Initial contents of the registry
None. None.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Andy Bierman, Carsten Bormann, The authors would like to thank Andy Bierman, Carsten Bormann,
Abhinav Somaraju, Laurent Toutain, Randy Turner and Peter van der Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent
Stok for their help during the development of this document and their Toutain and Randy Turner for their help during the development of
useful comments during the review process. this document and their useful comments during the review process.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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>.
skipping to change at page 15, line 19 skipping to change at page 17, line 32
[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 [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>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-07 (work in progress),
January 2020.
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
Petrov, "CoAP Management Interface", draft-ietf-core- Petrov, "CoAP Management Interface", draft-ietf-core-
comi-08 (work in progress), September 2019. comi-08 (work in progress), September 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>.
skipping to change at page 16, line 23 skipping to change at page 18, line 39
<https://www.rfc-editor.org/info/rfc8341>. <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,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
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
o ietf-netconf-acm@2012-02-22.yang o ietf-netconf-acm@2012-02-22.yang
o iana-crypt-hash@2014-04-04.yang o iana-crypt-hash@2014-04-04.yang
{ {
"assignment-ranges": [ "assignment-ranges": [
{ {
"entry-point": 1700, "entry-point": 1700,
 End of changes. 16 change blocks. 
44 lines changed or deleted 161 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/