< draft-ietf-core-sid-16.txt   draft-ietf-core-sid-17.txt >
Internet Engineering Task Force M.V. Veillette, Ed. Internet Engineering Task Force M.V. Veillette, Ed.
Internet-Draft Trilliant Networks Inc. Internet-Draft Trilliant Networks Inc.
Intended status: Standards Track A.P. Pelov, Ed. Intended status: Standards Track A.P. Pelov, Ed.
Expires: 27 December 2021 Acklio Expires: 29 April 2022 Acklio
I. Petrov, Ed. I. Petrov, Ed.
Google Switzerland GmbH Google Switzerland GmbH
C. Bormann C. Bormann
Universität Bremen TZI Universität Bremen TZI
25 June 2021 M. Richardson
Sandelman Software Works
26 October 2021
YANG Schema Item iDentifier (YANG SID) YANG Schema Item iDentifier (YANG SID)
draft-ietf-core-sid-16 draft-ietf-core-sid-17
Abstract Abstract
YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
unsigned integers used to identify YANG items. This document defines unsigned integers used to identify YANG items, as a more compact
the semantics, the registration, and assignment processes of YANG method to identify YANG items that can be used for efficiency and in
SIDs. To enable the implementation of these processes, this document constrained environments (RFC 7228). This document defines the
also defines a file format used to persist and publish assigned YANG semantics, the registration, and assignment processes of YANG SIDs
SIDs. for IETF managed YANG modules. To enable the implementation of these
processes, this document also defines a file format used to persist
and publish assigned YANG 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 27 December 2021. This Internet-Draft will expire on 29 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5 3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5
4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6 4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6
5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13 7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13
7.2. Register ".sid" File Format Module . . . . . . . . . . . 13 7.2. Register ".sid" File Format Module . . . . . . . . . . . 14
7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 14 7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 14
7.4. Create new IANA Registry: "YANG SID Mega-Range" 7.4. Create new IANA Registry: "YANG SID Mega-Range"
registry . . . . . . . . . . . . . . . . . . . . . . . . 14 registry . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14 7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14
7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14 7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 15
7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15 7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15
7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15 7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15
7.4.3. Initial contents of the Registry . . . . . . . . . . 15 7.4.3. Initial contents of the Registry . . . . . . . . . . 16
7.5. Create a new IANA Registry: IETF YANG SID Range Registry 7.5. Create a new IANA Registry: IETF YANG SID Range Registry
(managed by IANA) . . . . . . . . . . . . . . . . . . . . 16 (managed by IANA) . . . . . . . . . . . . . . . . . . . . 16
7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16 7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16
7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16 7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16
7.5.3. Initial contents of the registry . . . . . . . . . . 18 7.5.3. Initial contents of the registry . . . . . . . . . . 18
7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 19 7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 20
7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 19 7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 20
7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 19 7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 20
7.6.3. Recursive Allocation of YANG SID Range at Document 7.6.3. Recursive Allocation of YANG SID Range at Document
Adoption . . . . . . . . . . . . . . . . . . . . . . 20 Adoption . . . . . . . . . . . . . . . . . . . . . . 21
7.6.4. Initial contents of the registry . . . . . . . . . . 21 7.6.4. Initial contents of the registry . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 24 Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 25
Appendix B. SID auto generation . . . . . . . . . . . . . . . . 33 Appendix B. SID auto generation . . . . . . . . . . . . . . . . 34
Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 34 Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 36
C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 34 C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 36
C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 36 C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 Network Configuration Protocol(NETCONF) unique identifier. In both Network Configuration Protocol (NETCONF)
[RFC6241] and RESTCONF [RFC8040], these identifiers are implemented [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented
using names. To allow the implementation of data models defined in using names. To allow the implementation of data models defined in
YANG in constrained devices and constrained networks, a more compact YANG in constrained devices [RFC7228] and constrained networks, a
method to identify YANG items is required. This compact identifier, more compact method to identify YANG items is required. This compact
called YANG SID or simply SID in this document and when the context identifier, called YANG Schema Item iDentifier or YANG SID (or simply
is clear, is encoded using a 63-bit unsigned integer. The limitation SID in this document and when the context is clear), is encoded using
to 63-bit unsigned integers allows SIDs to be manipulated more easily a 63-bit unsigned integer. The limitation to 63-bit unsigned
on platforms that might otherwise lack native 64-bit unsigned integers allows SIDs to be manipulated more easily on platforms that
arithmetic. The loss of a single bit of range is not significant might otherwise lack 64-bit unsigned arithmetic. The loss of a
given the size of the remaining space. 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:
* identities * identities
* data nodes (Note: including those nodes defined by the 'yang-data' * data nodes (Note: including those nodes defined by the 'yang-data'
extension.) extension.)
* 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, submodules and features * YANG modules and features
It is possible that some protocols use only a subset of the assigned It is possible that some protocols use only a subset of the assigned
SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like
[I-D.ietf-core-comi] the transportation of YANG module SIDs might be [I-D.ietf-core-comi] the transportation of YANG module SIDs might be
unnecessary. Other protocols might need to be able to transport this unnecessary. Other protocols might need to be able to transport this
information, for example protocols related to discovery such as information, for example protocols related to discovery such as
Constrained YANG Module Library [I-D.ietf-core-yang-library]. Constrained YANG Module Library [I-D.ietf-core-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". called "SID ranges".
Assignment of SIDs to YANG items can be automated. For more details SIDs are assigned permanently. Items introduced by a new revision of
how this can be achieved, please consult Appendix B. a YANG module are added to the list of SIDs already assigned.
Assignment of SIDs to YANG items SHOULD be automated. For more
SIDs are assigned permanently, items introduced by a new revision of details how this can be achieved, and when manual interventions may
a YANG module are added to the list of SIDs already assigned. If the be appropriate, see Appendix B.
meaning of an item changes, for example as a result from a non-
backward compatible update of the YANG module, a new SID SHOULD be
assigned to it. A new SID MUST always be assigned if the new meaning
of the item is going to be referenced using a SID.
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.
IETF managed YANG modules which need to allocate SIDs, MUST use the
IANA mechanism specified in this document. For YANG modules created
by other parties, the use of IANA allocation mechanisms via use of
Mega-Ranges (see Section 7.4) is RECOMMENDED. Within the Mega-Range
allocation, those other parties are free to make up their own
mechanism.
At the time of writing, a tool for automated SID file generation is
available as part of the open-source project PYANG [PYANG].
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
skipping to change at page 4, line 45 skipping to change at page 5, line 9
* schema tree * schema tree
* submodule * submodule
The following term is defined in [RFC8040]: The following term is defined in [RFC8040]:
* yang-data extension * yang-data extension
This specification also makes use of the following terminology: This specification also makes use of the following terminology:
* item: A schema node, an identity, a module, a submodule or a * item: A schema node, an identity, a module, or a feature defined
feature defined using the YANG modeling language. using the YANG modeling language.
* schema-node path: A schema-node path is a string that identifies a * schema-node path: A schema-node path is a string that identifies a
schema node within the schema tree. A path consists of the list schema node within the schema tree. A path consists of the list
of consecutive schema node identifier(s) separated by slashes of consecutive schema node identifier(s) separated by slashes
("/"). Schema node identifier(s) are always listed from the top- ("/"). Schema node identifier(s) are always listed from the top-
level schema node up to the targeted schema node and could contain level schema node up to the targeted schema node and could contain
namespace information. (e.g. "/ietf-system:system-state/clock/ namespace information. (e.g. "/ietf-system:system-state/clock/
current-datetime") current-datetime")
* Namespace-qualified form - a schema node identifier is prefixed * Namespace-qualified form - a schema node identifier is prefixed
skipping to change at page 6, line 35 skipping to change at page 7, line 5
| +-- module-name yang:yang-identifier | +-- module-name yang:yang-identifier
| +-- module-revision revision-identifier | +-- module-revision revision-identifier
+-- assignment-range* [entry-point] +-- assignment-range* [entry-point]
| +-- entry-point sid | +-- entry-point sid
| +-- size uint64 | +-- size uint64
+-- item* [namespace identifier] +-- item* [namespace identifier]
+-- namespace enumeration +-- namespace enumeration
+-- identifier union +-- identifier union
+-- sid sid +-- sid sid
The following YANG module defined the structure of this file, The following YANG module defines the structure of this file,
encoding is performed using the rules defined in [RFC7951]. It encoding is performed in JSON [RFC8259] using the rules defined in
references ietf-yang-types defined in [RFC6991] and ietf-restconf [RFC7951]. It references ietf-yang-types defined in [RFC6991] and
defined in [RFC8040]. ietf-restconf defined in [RFC8040].
RFC Ed.: please update the date of the module and Copyright if needed RFC Ed.: please update the date of the module and Copyright if needed
and remove this note. and remove this note.
<CODE BEGINS> file "ietf-sid-file@2020-02-05.yang" <CODE BEGINS> file "ietf-sid-file@2020-02-05.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;
skipping to change at page 7, line 13 skipping to change at page 7, line 32
} }
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
reference "RFC 8040: RESTCONF Protocol."; reference "RFC 8040: RESTCONF Protocol.";
} }
organization organization
"IETF Core Working Group"; "IETF Core Working Group";
contact contact
"WG Web: <http://datatracker.ietf.org/wg/core/> "WG Web: <https://datatracker.ietf.org/wg/core/>
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
skipping to change at page 8, line 5 skipping to change at page 8, line 22
for full legal notices. for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
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 the different Each .sid file contains the mapping between each
string identifiers defined by a YANG module and a string identifier defined by a YANG module and a
corresponding numeric value called YANG SID."; corresponding numeric value called YANG SID.";
revision 2020-02-05 { revision 2020-02-05 {
description description
"Initial revision."; "Initial revision.";
reference reference
"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)"; "[RFC XXXX] YANG Schema Item iDentifier (YANG SID)";
} }
typedef revision-identifier { typedef revision-identifier {
type string { type string {
pattern '\d{4}-\d{2}-\d{2}'; pattern '\d{4}-\d{2}-\d{2}';
} }
description description
"Represents a date in YYYY-MM-DD format."; "Represents a date in YYYY-MM-DD format.";
} }
typedef sid-file-version-identifier { typedef sid-file-version-identifier {
type uint64; type uint32;
description description
"Represents the version of a .sid file."; "Represents the version of a .sid file.";
} }
typedef sid { typedef sid {
type uint64 { type uint64 {
range "0..9223372036854775807"; range "0..9223372036854775807";
} }
description description
"YANG Schema Item iDentifier"; "YANG Schema Item iDentifier";
reference reference
"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)"; "[RFC XXXX] YANG Schema Item iDentifier (YANG SID)";
} }
typedef schema-node-path { typedef schema-node-path {
type string { type string {
pattern pattern
'/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' + '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
'(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*'; '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
} }
description description
"A schema-node path is an absolute YANG schema node identifier "A schema-node path is an absolute YANG schema node identifier
skipping to change at page 10, line 48 skipping to change at page 11, line 17
} }
} }
list assignment-range { list assignment-range {
key "entry-point"; key "entry-point";
description description
"YANG SID range(s) allocated to the YANG module identified "YANG SID range(s) allocated to the YANG module identified
by 'module-name' and 'module-revision'. by 'module-name' and 'module-revision'.
- The YANG SID range first available value is entry-point - The YANG SID range first available value is entry-point
and the the last available value in the range is and the last available value in the range is
(entry-point + size - 1). (entry-point + size - 1).
- The YANG SID ranges specified by all assignment-rages - The YANG SID ranges specified by all assignment-rages
MUST NOT overlap."; MUST NOT overlap.";
leaf entry-point { leaf entry-point {
type sid; type sid;
description description
"Lowest YANG SID available for assignment."; "Lowest YANG SID available for assignment.";
} }
skipping to change at page 13, line 18 skipping to change at page 13, line 35
The message payload of Content-Type 'application/yang-data+cbor' The message payload of Content-Type 'application/yang-data+cbor'
is encoded using a CBOR map. Each entry within the CBOR map is encoded using a CBOR map. Each entry within the CBOR map
contains the data node identifier (i.e. SID) and the associated contains the data node identifier (i.e. SID) and the associated
instance-value. Instance-values are encoded using the rules instance-value. Instance-values are encoded using the rules
defined in Section 4 of [I-D.ietf-core-yang-cbor]. defined in Section 4 of [I-D.ietf-core-yang-cbor].
6. Security Considerations 6. Security Considerations
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 that are modeled in YANG [RFC7950]. As such, this identifier does
contribute to any new security issues in addition of those identified not contribute to any new security issues in addition of those
for the specific protocols or contexts for which it is used. identified for the specific protocols or contexts for which it is
used.
7. IANA Considerations 7. IANA Considerations
7.1. YANG Namespace Registration 7.1. YANG Namespace Registration
This document registers the following XML namespace URN in the "IETF This document registers the following XML namespace URN in the "IETF
XML Registry", following the format defined in [RFC3688]: XML Registry", following the format defined in [RFC3688]:
URI: please assign urn:ietf:params:xml:ns:yang:ietf-sid-file URI: please assign urn:ietf:params:xml:ns:yang:ietf-sid-file
skipping to change at page 13, line 50 skipping to change at page 14, line 20
This document registers one YANG module in the "YANG Module Names" This document registers one YANG module in the "YANG Module Names"
registry [RFC6020]: registry [RFC6020]:
* name: ietf-sid-file * name: ietf-sid-file
* namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file * namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file
* prefix: sid * prefix: sid
* reference: [[RFC XXXX]] * reference: RFC XXXX
// RFC Ed.: please replace XXXX with RFC number and remove this note // RFC Ed.: please replace XXXX with RFC number and remove this note
7.3. CoAP Content-Formats Registry 7.3. CoAP Content-Formats Registry
A Content-Format for "application/yang-data+cbor; id=sid" has been A Content-Format for application/yang-data+cbor; id=sid has been
added to the "CoAP Content-Formats" within the "Constrained RESTful added to the "CoAP Content-Formats" within the "Constrained RESTful
Environments (CoRE) Parameters" registry, in Environments (CoRE) Parameters" registry, in
[I-D.ietf-core-yang-cbor]. [I-D.ietf-core-yang-cbor].
7.4. Create new IANA Registry: "YANG SID Mega-Range" registry 7.4. Create new IANA Registry: "YANG SID Mega-Range" registry
The name of this registry is "YANG SID Mega-Range". This registry is The name of this registry is "YANG SID Mega-Range". This registry is
used to record the delegation of the management of a block of SIDs to used to record the delegation of the management of a block of SIDs to
third parties (such as SDOs or registrars). third parties (such as SDOs or registrars).
skipping to change at page 17, line 32 skipping to change at page 17, line 39
+-------------+---------+-------------------------------+ +-------------+---------+-------------------------------+
| 100,000 | 900,000 | Reserved | | 100,000 | 900,000 | Reserved |
+-------------+---------+-------------------------------+ +-------------+---------+-------------------------------+
Table 2 Table 2
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 assignment within the number of YANG items. This headroom allows assignment within the
same range of new YANG items introduced by subsequent revisions. The same range of new YANG items introduced by subsequent revisions. The
maximum SID range size is 1000. A larger size may be requested by SID range size SHOULD NOT exceed 1000; a larger size may be requested
the authors if this recommendation is considered insufficient. It is by the authors if this recommendation is considered insufficient. It
important to note that an additional SID range can be allocated to an is important to note that an additional SID range can be allocated to
existing YANG module if the initial range is exhausted. an existing YANG module if the initial range is exhausted; this then
just leads to slightly less efficient representation.
In case a SID range is allocated for an existing RFC through the In case a SID range is allocated for an existing RFC through the
"Expert Review" policy, the Document reference field for the given "Expert Review" policy, the Document reference field for the given
allocation should point to the RFC that the YANG module is defined allocation should point to the RFC that the YANG module is defined
in. in.
In case a SID range is required before publishing the RFC due to In case a SID range is required before publishing the RFC due to
implementations needing stable SID values, early allocation as implementations needing stable SID values, early allocation as
defined in [BCP100] can be employed. As specified in Section 4.6 of defined in [BCP100] can be employed. As specified in Section 4.6 of
[RFC8126], RFCs and by extension documents that are expected to [RFC8126], RFCs and by extension documents that are expected to
become an RFC fulfill the requirement for "Specification Required" become an RFC fulfill the requirement for "Specification Required"
stated in Section 2 of [BCP100], which allows for the early stated in Section 2 of [BCP100], which allows for the early
allocation process to be employed. allocation process to be employed.
7.5.3. Initial contents of the registry 7.5.3. Initial contents of the registry
Initial entries in this registry are as follows: Initial entries in this registry are as follows:
+=======+=====+==============+======================================+ +=======+=====+==============+======================================+
skipping to change at page 20, line 41 skipping to change at page 21, line 41
useful the included YANG modules may also need to have SID useful the included YANG modules may also need to have SID
allocations made. allocations made.
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. This provides the generated SID file to IANA for registration. This
process may be time consuming during a bootstrap period (there are process may be time-consuming during a bootstrap period (there are
over 100 YANG modules to date, none of which have SID over 100 YANG modules to date, none of which have SID
allocations), but should quiet down once needed entries are allocations), but should quiet down once needed entries are
allocated. allocated.
* If the document is an unprocessed Internet-Draft adopted in a WG, * If the document is an unprocessed Internet-Draft adopted in a WG,
then an Early Allocation is performed for this document as well. then an Early Allocation is performed for this document as well.
Early Allocations require approval by an IESG Area Director. An Early Allocations require approval by an IESG Area Director. An
early allocation which requires additional allocations will list early allocation which requires additional allocations will list
the other allocations in it's description, and will be cross- the other allocations in its description, and will be cross-posted
posted to the any other working group mailing lists. to the any other working group mailing lists.
* A YANG module which references a module in an document which has * A YANG module which references a module in a document which has
not yet been adopted by any working group will be unable to not yet been adopted by any working group will be unable to
perform an Early Allocation for that other document until it is perform an Early Allocation for that other document until it is
adopted by a working group. As described in [BCP100], an AD adopted by a working group. As described in [BCP100], an AD
Sponsored document acts as if it had a working group. The Sponsored document acts as if it had a working group. The
approving AD may also exempt a document from this policy by approving AD may also exempt a document from this policy by
agreeing to AD Sponsor the document. agreeing to AD Sponsor the document.
At the end of the IETF process all the dependencies of a given module At the end of the IETF process all the dependencies of a given module
for which SIDs are assigned, should also have SIDs assigned. Those for which SIDs are assigned, should also have SIDs assigned. Those
dependencies' assignments should be permanent (not Early Allocation). dependencies' assignments should be permanent (not Early Allocation).
skipping to change at page 22, line 11 skipping to change at page 23, line 11
8. References 8. References
8.1. Normative References 8.1. Normative References
[BCP100] Cotton, M., "Early IANA Allocation of Standards Track Code [BCP100] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014. Points", BCP 100, RFC 7120, January 2014.
<https://www.rfc-editor.org/info/bcp100> <https://www.rfc-editor.org/info/bcp100>
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of Veillette, M., Petrov, I., Pelov, A., and C. Bormann,
Data Modeled with YANG", Work in Progress, Internet-Draft, "CBOR Encoding of Data Modeled with YANG", Work in
draft-ietf-core-yang-cbor-15, 25 January 2021, Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 24
<https://www.ietf.org/archive/id/draft-ietf-core-yang- June 2021, <https://www.ietf.org/archive/id/draft-ietf-
cbor-15.txt>. core-yang-cbor-16.txt>.
[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>.
skipping to change at page 22, line 46 skipping to change at page 23, line 46
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[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>.
[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
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-anima-constrained-voucher] [I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P. V. D., Kampanakis, P., and E. Richardson, M., Stok, P. V. D., Kampanakis, P., and E.
Dijk, "Constrained Voucher Artifacts for Bootstrapping Dijk, "Constrained Bootstrapping Remote Secure Key
Protocols", Work in Progress, Internet-Draft, draft-ietf- Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
anima-constrained-voucher-11, 11 June 2021, draft-ietf-anima-constrained-voucher-14, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-anima- <https://www.ietf.org/archive/id/draft-ietf-anima-
constrained-voucher-11.txt>. constrained-voucher-14.txt>.
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
I. Petrov, "CoAP Management Interface (CORECONF)", Work in I. Petrov, "CoAP Management Interface (CORECONF)", Work in
Progress, Internet-Draft, draft-ietf-core-comi-11, 17 Progress, Internet-Draft, draft-ietf-core-comi-11, 17
January 2021, <https://www.ietf.org/archive/id/draft-ietf- January 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-comi-11.txt>. core-comi-11.txt>.
[I-D.ietf-core-yang-library] [I-D.ietf-core-yang-library]
Veillette, M. and I. Petrov, "Constrained YANG Module Veillette, M. and I. Petrov, "Constrained YANG Module
Library", Work in Progress, Internet-Draft, draft-ietf- Library", Work in Progress, Internet-Draft, draft-ietf-
core-yang-library-03, 11 January 2021, core-yang-library-03, 11 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-yang- <https://www.ietf.org/archive/id/draft-ietf-core-yang-
library-03.txt>. library-03.txt>.
[PYANG] Bjorklund, M., "An extensible YANG validator and converter
in python", <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., [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>.
[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
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<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
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>.
[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 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
skipping to change at page 24, line 25 skipping to change at page 25, line 30
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",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <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) has been
generated using the following yang modules: generated using the following yang modules:
* ietf-system@2014-08-06.yang (defined in [RFC7317]) * ietf-system@2014-08-06.yang (defined in [RFC7317])
* ietf-yang-types@2013-07-15.yang (defined in [RFC6991]) * ietf-yang-types@2013-07-15.yang (defined in [RFC6991])
* ietf-inet-types@2013-07-15.yang (defined in [RFC6991]) * ietf-inet-types@2013-07-15.yang (defined in [RFC6991])
* ietf-netconf-acm@2018-02-14.yang (defined in [RFC8341]) * ietf-netconf-acm@2018-02-14.yang (defined in [RFC8341])
* iana-crypt-hash@2014-08-06.yang (defined in [RFC7317]) * iana-crypt-hash@2014-08-06.yang (defined in [RFC7317])
For purposes of exposition, line breaks have been introduced below in
some JSON strings that represent overly long identifiers. For
reconstructing the actual JSON file from this figure, all line breaks
that occur in what would be JSON strings need to be removed,
including any following blank space (indentation) on the line after
the line break; in each such case, a single identifier without any
embedded blank space results.
{ {
"ietf-sid-file:sid-file" : { "ietf-sid-file:sid-file" : {
"module-name": "ietf-system", "module-name": "ietf-system",
"module-revision": "2020-02-05", "module-revision": "2020-02-05",
"dependency-revision": [ "dependency-revision": [
{ {
"module-name": "ietf-yang-types", "module-name": "ietf-yang-types",
"module-revision": "2013-07-15" "module-revision": "2013-07-15"
}, },
{ {
skipping to change at page 33, line 35 skipping to change at page 34, line 51
"identifier": "/ietf-system:system/radius/server/udp/ "identifier": "/ietf-system:system/radius/server/udp/
shared-secret", shared-secret",
"sid": 1774 "sid": 1774
} }
] ]
} }
} }
Appendix B. SID auto generation Appendix B. SID auto generation
Assignment of SIDs to YANG items can be automated, the recommended Assignment of SIDs to YANG items SHOULD be automated. The
process to assign SIDs is as follows: recommended process to assign SIDs is as follows:
1. A tool extracts the different items defined for a specific YANG 1. A tool extracts the different items defined for a specific YANG
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
skipping to change at page 34, line 12 skipping to change at page 35, line 26
between a reference SID and the current SID is used by protocols between a reference SID and the current SID is used by protocols
aiming to reduce message size. 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.
5. The "dependency-revision" should reflect the revision numbers of 5. The "dependency-revision" should reflect the revision numbers of
each YANG module that the YANG module imports at the moment of each YANG module that the YANG module imports at the moment of
the generation. the generation.
When updating a YANG module that is in active use, the existing SID
assignments are maintained. (In contrast, when evolving an early
draft that has not yet been adopted by a community of developers, SID
assignments are often better done from scratch after a revision.) If
the name of a schema node changes, but the data remain structurally
and semantically similar to what was previously available under an
old name, the SID that was used for the old name MAY continue to be
used for the new name. If the meaning of an item changes, a new SID
MAY be assigned to it; this is particularly useful to allow the new
SID to identify the new structure or semantics of the item. If the
YANG data type changes in a new revision of a published module, such
that the resulting CBOR encoding is changed, then implementations
will be aided significantly if a new SID is assigned. Note that
these decisions are generally at the discretion of the YANG module
author, who should decide if the benefits of a manual intervention
are worth the deviation from automatic assignment.
In case of an update to an existing ".sid" file, an additional step In case of an update to an existing ".sid" file, an additional step
is needed that increments the ".sid" file version number. If there is needed that increments the ".sid" file version number. If there
was no version number in the previous version of the ".sid" file, 0 was no version number in the previous version of the ".sid" file, 0
is assumed as the version number of the old version of the ".sid" is assumed as the version number of the old version of the ".sid"
file and the version number is 1 for the new ".sid" file. Apart from file and the version number is 1 for the new ".sid" file. Apart from
that, changes of ".sid" files can also be automated using the same that, changes of ".sid" files can also be automated using the same
method described above, only unassigned YANG items are processed at method described above, only unassigned YANG items are processed at
step #3. Already existing items in the ".sid" file should not be step #3. Already existing items in the ".sid" file should not be
given new SIDs. given new SIDs.
skipping to change at page 34, line 41 skipping to change at page 36, line 24
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 "YANG SID Range Registry". If the YANG acquire a SID range from a "YANG SID Range Registry". If the YANG
module is part of an IETF draft or RFC, the SID range need to be module is part of an IETF draft or RFC, the SID range need to be
acquired from the "IETF YANG SID Range Registry" as defined in acquired from the "IETF YANG SID Range Registry" as defined in
Section 7.5. For the other YANG modules, the authors can acquire a Section 7.5. For the other YANG modules, the authors can acquire a
SID range from any "YANG SID Range Registry" of their choice. SID range from any "YANG SID Range Registry" of their choice.
Once the SID range is acquired, the owner can use it to generate Once the SID range is acquired, owners can use it to generate ".sid"
".sid" file/s for his YANG module/s. It is recommended to leave some file/s for their YANG module/s. It is recommended to leave some
unallocated SIDs following the allocated range in each ".sid" file in unallocated SIDs following the allocated range in each ".sid" file in
order to allow better evolution of the YANG module in the future. order to allow better evolution of the YANG module in the future.
Generation of ".sid" files should be performed using an automated Generation of ".sid" files should be performed using an automated
tool. Note that ".sid" files can only be generated for YANG modules tool. Note that ".sid" files can only be generated for YANG modules
and not for submodules. and not for submodules.
C.1. ".sid" File Creation C.1. ".sid" File Creation
The following activity diagram summarizes the creation of a YANG The following activity diagram summarizes the creation of a YANG
module and its associated ".sid" file. module and its associated ".sid" file.
skipping to change at page 35, line 31 skipping to change at page 37, line 14
| | no | | | | no | |
| v v | | v v |
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
+----+ YANG module | | SID sub-range | | +----+ YANG module | | SID sub-range | |
| update | | assignment |<----------+ | update | | assignment |<----------+
+---------------+ +-------+-------+ | +---------------+ +-------+-------+ |
| | | |
v | v |
+---------------+ +------+------+ +---------------+ +------+------+
| ".sid" file | | Rework YANG | | ".sid" file | | Rework YANG |
| generation | | model | | generation | | module |
+-------+-------+ +-------------+ +-------+-------+ +-------------+
| ^ | ^
v | v |
.----------. yes | .----------. yes |
/ Work in \ -----------+ / Work in \ -----------+
\ progress / \ progress /
'----+-----' '----+-----'
| no | no
v v
.-------------. .-------------. .-------------. .-------------.
skipping to change at page 38, line 5 skipping to change at page 39, line 5
Figure 2: YANG and ".sid" file update Figure 2: YANG and ".sid" file update
Acknowledgments Acknowledgments
The authors would like to thank Andy Bierman, Michael Richardson, The authors would like to thank Andy Bierman, Michael Richardson,
Abhinav Somaraju, Peter van der Stok, Laurent Toutain and Randy Abhinav Somaraju, Peter van der Stok, Laurent Toutain and Randy
Turner for their help during the development of this document and Turner for their help during the development of this document and
their useful comments during the review process. their useful comments during the review process.
Contributors
Andy Bierman
YumaWorks
685 Cochran St.
Suite #160
Simi Valley, CA 93065
United States of America
Email: andy@yumaworks.com
Authors' Addresses Authors' Addresses
Michel Veillette (editor) Michel Veillette (editor)
Trilliant Networks Inc. Trilliant Networks Inc.
610 Rue du Luxembourg 610 Rue du Luxembourg
Granby Quebec J2J 2V2 Granby Quebec J2J 2V2
Canada Canada
Phone: +14503750556 Phone: +14503750556
Email: michel.veillette@trilliant.com Email: michel.veillette@trilliant.com
skipping to change at page 38, line 37 skipping to change at page 40, line 4
CH-8002 Zurich CH-8002 Zurich
Switzerland Switzerland
Email: ivaylopetrov@google.com Email: ivaylopetrov@google.com
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
 End of changes. 48 change blocks. 
90 lines changed or deleted 153 lines changed or added

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