rfc9595.original.xml | rfc9595.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!-- draft submitted in xml v3 --> | ||||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2 | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" | |||
) --> | ipr="trust200902" | |||
<?rfc strict="yes"?> | docName="draft-ietf-core-sid-24" | |||
<?rfc compact="yes"?> | number="9595" | |||
<?rfc subcompact="no"?> | category="std" | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | consensus="true" | |||
-ietf-core-sid-24" category="std" consensus="true" submissionType="IETF" tocDept | submissionType="IETF" | |||
h="4" tocInclude="true" sortRefs="true" symRefs="true" version="3"> | tocDepth="4" | |||
<!-- xml2rfc v2v3 conversion 3.19.0 --> | tocInclude="true" | |||
updates="" | ||||
obsoletes="" | ||||
sortRefs="true" | ||||
symRefs="true" | ||||
xml:lang="en" | ||||
version="3"> | ||||
<front> | <front> | |||
<title>YANG Schema Item iDentifier (YANG SID)</title> | <title>YANG Schema Item iDentifier (YANG SID)</title> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-24"/> | ||||
<!-- [rfced] The document title does not follow the typical style of | ||||
YANG RFCs. Would you like to update the title as suggested? | ||||
Original: | ||||
YANG Schema Item iDentifier (YANG SID) | ||||
Suggested: | ||||
YANG Data Model for YANG Schema Item iDentifiers (YANG SIDs) | ||||
Abbreviated (running) title: | ||||
YANG Data Model for YANG SIDs --> | ||||
<seriesInfo name="RFC" value="9595"/> | ||||
<!-- [rfced] Author names and addresses: | ||||
a) We see "M. V. Veillette" on the first page of this document and draft-ietf-co | ||||
re-comi, but we see "M. Veillette" in | ||||
draft-ietf-core-yang-library and RFC 9254. Michel, do you have a | ||||
preference as to how your initials should appear in this document and | ||||
upcoming RFCs? | ||||
b) Please note xml2rfc yields a warning because | ||||
Bretagne is listed as a region, and Bretagne does not appear | ||||
in the output files. Alexander, per post-6000 published RFCs that | ||||
list "2 rue de la Châtaigneraie", may we use "35510 Cesson-Sévigné | ||||
Cedex" (as also used in RFC 9254) or "35510 Cesson-Sévigné - Rennes" | ||||
instead? | ||||
The warning: | ||||
Warning: Postal address part filled in, but not used: <region>: Bretagne | ||||
Available elements for France are: <extaddr>, <street>, <code>, <city>, | ||||
<country> | ||||
Original: | ||||
M. V. Veillette, Ed. | ||||
... | ||||
Alexander Pelov (editor) | ||||
IMT Atlantique | ||||
2 rue de la Châtaigneraie | ||||
35510 Cesson-Sevigne | ||||
France | ||||
Email: alexander.pelov@imt-atlantique.fr --> | ||||
<author initials="M. V." surname="Veillette" fullname="Michel Veillette" rol e="editor"> | <author initials="M. V." surname="Veillette" fullname="Michel Veillette" rol e="editor"> | |||
<organization>Trilliant Networks Inc.</organization> | <organization>Trilliant Networks Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>610 Rue du Luxembourg</street> | <street>610 Rue du Luxembourg</street> | |||
<city>Granby</city> | <city>Granby</city> | |||
<region>Quebec</region> | <region>Quebec</region> | |||
<code>J2J 2V2</code> | <code>J2J 2V2</code> | |||
<country>Canada</country> | <country>Canada</country> | |||
</postal> | </postal> | |||
<phone>+14503750556</phone> | <phone>+1-450-375-0556</phone> | |||
<email>michel.veillette@trilliant.com</email> | <email>michel.veillette@trilliant.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="A." surname="Pelov" fullname="Alexander Pelov" role="edito r"> | <author initials="A." surname="Pelov" fullname="Alexander Pelov" role="edito r"> | |||
<organization>IMT Atlantique</organization> | <organization>IMT Atlantique</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>2 rue de la Châtaigneraie</street> | <street>2 rue de la Châtaigneraie</street> | |||
<city>Cesson-Sevigne</city> | <city>Cesson-Sévigné</city> | |||
<region>Bretagne</region> | <region>Bretagne</region> | |||
<code>35510</code> | <code>35510</code> | |||
<country>France</country> | <country>France</country> | |||
</postal> | </postal> | |||
<email>alexander.pelov@imt-atlantique.fr</email> | <email>alexander.pelov@imt-atlantique.fr</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor "> | <author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor "> | |||
<organization>Google Switzerland GmbH</organization> | <organization>Google Switzerland GmbH</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Brandschenkestrasse 110</street> | <street>Brandschenkestrasse 110</street> | |||
<city>Zurich</city> | <city>Zurich</city> | |||
<region>Zurich</region> | ||||
<code>8002</code> | <code>8002</code> | |||
<country>Switzerland</country> | <country>Switzerland</country> | |||
</postal> | </postal> | |||
<email>ivaylopetrov@google.com</email> | <email>ivaylopetrov@google.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> | <author initials="C." surname="Bormann" fullname="Carsten Bormann"> | |||
<organization>Universität Bremen TZI</organization> | <organization>Universität Bremen TZI</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Postfach 330440</street> | <street>Postfach 330440</street> | |||
<city>D-28359 Bremen</city> | <city>Bremen</city> | |||
<country>Germany</country> | <country>Germany</country> | |||
<code>D-28359</code> | ||||
</postal> | </postal> | |||
<phone>+49-421-218-63921</phone> | <phone>+49-421-218-63921</phone> | |||
<email>cabo@tzi.org</email> | <email>cabo@tzi.org</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="M." surname="Richardson" fullname="Michael Richardson"> | <author initials="M." surname="Richardson" fullname="Michael Richardson"> | |||
<organization>Sandelman Software Works</organization> | <organization>Sandelman Software Works</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<country>Canada</country> | <country>Canada</country> | |||
</postal> | </postal> | |||
<email>mcr+ietf@sandelman.ca</email> | <email>mcr+ietf@sandelman.ca</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2023" month="December" day="22"/> | ||||
<area>Applications and Real-Time Area (art)</area> | <date year="2024" month="June"/> | |||
<workgroup>Internet Engineering Task Force</workgroup> | ||||
<area>WIT</area> | ||||
<workgroup>core</workgroup> | ||||
<keyword>CBOR</keyword> | <keyword>CBOR</keyword> | |||
<abstract> | <abstract> | |||
<?line 123?> | <t>YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned | |||
integers used to identify YANG items, as a more compact method to identify YANG | ||||
items that can be used for efficiency and in constrained environments (RFC 7228) | ||||
. | ||||
This document defines the semantics, registration processes, and assignment proc | ||||
esses for YANG SIDs for IETF-managed YANG modules. | ||||
To enable the implementation of these processes, this document also defines a fi | ||||
le format used to persist and publish assigned YANG SIDs. | ||||
<t>YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned i | <!-- [rfced] Abstract: "used to identify YANG items, as a more | |||
ntegers used to identify YANG items, as a more compact method to identify YANG i | compact method to identify YANG items" reads a bit oddly. May we | |||
tems that can be used for efficiency and in constrained environments (RFC 7228). | update as suggested? | |||
This document defines the semantics, the registration, and assignment processes | ||||
of YANG SIDs for IETF managed YANG modules. | Original: | |||
To enable the implementation of these processes, this document also defines a fi | YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit | |||
le format used to persist and publish assigned YANG SIDs.</t> | unsigned integers used to identify YANG items, as a more compact | |||
<t><cref anchor="status">The present version (–24) is intended to address | method to identify YANG items that can be used for efficiency and in | |||
the remaining IESG comments.</cref></t> | constrained environments (RFC 7228). | |||
Suggested: | ||||
YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit | ||||
unsigned integers used to identify YANG items. SIDs provide a more | ||||
compact method for identifying those YANG items that can be used | ||||
efficiently, particularly in constrained environments (RFC 7228). --> | ||||
</t> | ||||
</abstract> | </abstract> | |||
<note removeInRFC="true"> | ||||
<name>About This Document</name> | ||||
<t> | ||||
Status information for this document may be found at <eref target="https | ||||
://datatracker.ietf.org/doc/draft-ietf-core-sid/"/>. | ||||
</t> | ||||
<t> | ||||
Discussion of this document takes place on the | ||||
Constrained RESTful Environments Working Group mailing list (<eref targe | ||||
t="mailto:core@ietf.org"/>), | ||||
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro | ||||
wse/core/"/>. | ||||
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/core/"/ | ||||
>. | ||||
</t> | ||||
<t>Source for this draft and an issue tracker can be found at | ||||
<eref target="https://github.com/core-wg/yang-cbor"/>.</t> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<?line 136?> | ||||
<section anchor="introduction"> | <section anchor="introduction"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>Some of the items defined in YANG <xref target="RFC7950"/> require the use of a | <t>Some of the items defined in YANG <xref target="RFC7950"/> require the use of a | |||
unique identifier. | unique identifier. | |||
In both Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and RE STCONF <xref target="RFC8040"/>, these identifiers are implemented using names. | In both the Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> an d RESTCONF <xref target="RFC8040"/>, these identifiers are implemented using nam es. | |||
To allow the implementation of data models defined in YANG in constrained device s <xref target="RFC7228"/> and constrained networks, a more compact method to id entify YANG items is required. | To allow the implementation of data models defined in YANG in constrained device s <xref target="RFC7228"/> and constrained networks, a more compact method to id entify YANG items is required. | |||
This compact identifier, called YANG Schema Item iDentifier or YANG SID (or simp ly SID in this document and when the context is clear), is encoded using a 63-bi t unsigned integer. | This compact identifier, called the YANG Schema Item iDentifier or YANG SID (or simply SID in this document and when the context is clear), is encoded using a 6 3-bit unsigned integer. | |||
The limitation to 63-bit unsigned integers allows SIDs to be manipulated more ea sily on platforms that might otherwise lack 64-bit unsigned arithmetic. | The limitation to 63-bit unsigned integers allows SIDs to be manipulated more ea sily on platforms that might otherwise lack 64-bit unsigned arithmetic. | |||
The loss of a single bit of range is not significant given the size of the remai ning space.</t> | The loss of a single bit of range is not significant, given the size of the rema ining space.</t> | |||
<t>The following items are identified using SIDs:</t> | <t>The following items are identified using SIDs:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>identities</t> | <t>identities</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>data nodes (Note: including those nodes defined by the | <t>data nodes (note: including those nodes defined by the | |||
'rc:yang-data' <xref target="RFC8040"/> and 'sx:structure' <xref target="RFC8791 | 'rc:yang-data' extension <xref target="RFC8040"/> and the 'sx:structure' extensi | |||
"/> extensions.)</t> | on <xref target="RFC8791"/>)</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>remote procedure calls (RPCs) and associated input(s) and output(s) </t> | <t>remote procedure calls (RPCs) and associated input(s) and output(s) </t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>actions and associated input(s) and output(s)</t> | <t>actions and associated input(s) and output(s)</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>notifications and associated information</t> | <t>notifications and associated information</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>YANG modules and features</t> | <t>YANG modules and features</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>It is possible that some protocols use only a subset of the assigned SI | <t>It is possible that some protocols will use only a subset of the assign | |||
Ds, for | ed SIDs; for | |||
example, for protocols equivalent to NETCONF <xref target="RFC6241"/> like <xref | example, for protocols equivalent to NETCONF <xref target="RFC6241"/> like <xref | |||
target="I-D.ietf-core-comi"/> the | target="CORE-COMI"/>, the | |||
transportation of YANG module SIDs might be unnecessary. Other protocols | transport of YANG module SIDs might be unnecessary. Other protocols | |||
might need to be able to transport this information, for example protocols | might need to be able to transport this information -- for example, protocols | |||
related to discovery such as Constrained YANG Module Library <xref target="I-D.i | related to discovery such as the Constrained YANG Module Library <xref target="Y | |||
etf-core-yang-library"/>.</t> | ANG-LIBRARY"/>. | |||
<!-- [rfced] Section 1: We found the use of "equivalent" in this | ||||
sentence confusing, as draft-ietf-core-comi says "CORECONF extends | ||||
the set of YANG based protocols, NETCONF and RESTCONF, with the | ||||
capability to manage constrained devices and networks". If the | ||||
suggested text is not correct, please provide clarifying text. | ||||
Original: | ||||
It is possible that some protocols use only a subset of the assigned | ||||
SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like | ||||
[I-D.ietf-core-comi] the transportation of YANG module SIDs might be | ||||
unnecessary. | ||||
Suggested: | ||||
It is possible that some protocols will use only a subset of the | ||||
assigned SIDs; for example, for protocols that provide extensions to | ||||
NETCONF [RFC6241], such as [CORE-COMI], the transport of YANG module | ||||
SIDs might be unnecessary. --> | ||||
</t> | ||||
<t>SIDs are globally unique integers. A registration system is used in or der to | <t>SIDs are globally unique integers. A registration system is used in or der to | |||
guarantee their uniqueness. SIDs are registered in blocks called "SID ranges". | guarantee their uniqueness. SIDs are registered in blocks called "SID ranges". | |||
Once considered "stable", SIDs are assigned permanently. | Once they are considered "stable", SIDs are assigned permanently. | |||
Items introduced by a new revision of a YANG | Items introduced by a new revision of a YANG | |||
module are added to the list of SIDs already assigned. | module are added to the list of SIDs already assigned. | |||
This is discussed in more detail in <xref target="objectives"/>.</t> | This is discussed in more detail in <xref target="objectives"/>.</t> | |||
<t>Assignment of SIDs to YANG items is usually automated as | <t>The assignment of SIDs to YANG items is usually automated as | |||
discussed in <xref target="sid-auto-generation"/>, which also discusses some cas es | discussed in <xref target="sid-auto-generation"/>, which also discusses some cas es | |||
where manual interventions may be appropriate.</t> | where manual interventions may be appropriate.</t> | |||
<t><xref target="sid-lifecycle"/> provides more details about the registra | <t><xref target="sid-lifecycle"/> provides more details about the registra | |||
tion process of YANG | tion processes for YANG | |||
modules and associated SIDs. To enable the implementation of this registry, | modules and associated SIDs. To enable the implementation of these processes, | |||
<xref target="sid-file-format"/> defines a standard file format used to store an d publish | <xref target="sid-file-format"/> defines a standard file format used to store an d publish | |||
SIDs.</t> | SIDs. | |||
<t>IETF managed YANG modules that need to allocate SIDs use the IANA mecha | ||||
nism specified in this document. | <!-- [rfced] Section 1: We found "this registry" odd in this | |||
YANG modules created by other parties allocate SID ranges using the IANA allocat | context. We updated this sentence as follows. If this is incorrect, | |||
ion mechanisms via Mega-Ranges (see <xref target="mega-range-registry"/>); withi | please provide text that clarifies what "this registry" means here. | |||
n the Mega-Range allocation, those other parties are free to make up their own m | ||||
echanism.</t> | Original (the previous sentence is included for context): | |||
<t>Among other uses, YANG SIDs are particularly useful to obtain a | Section 3 provides more details about the registration process of | |||
YANG modules and associated SIDs. To enable the implementation of | ||||
this registry, Section 4 defines a standard file format used to store | ||||
and publish SIDs. | ||||
Currently: | ||||
To enable the implementation of | ||||
these processes, Section 4 defines a standard file format used to | ||||
store and publish SIDs. --> | ||||
</t> | ||||
<t>IETF-managed YANG modules that need to allocate SIDs will use the IANA | ||||
mechanism specified in this document. | ||||
YANG modules created by other parties allocate SID ranges using the IANA allocat | ||||
ion mechanisms via Mega-Ranges (see <xref target="mega-range-registry"/>); withi | ||||
n the Mega-Range allocation, those other parties are free to make up their own m | ||||
echanism. | ||||
<!-- [rfced] Section 1: We had trouble following this sentence, as it | ||||
appears that several IANA-related mechanisms are specified in this | ||||
document. If the suggested text is not correct, please clarify the | ||||
meaning of "the IANA mechanism specified in this document". | ||||
Original: | ||||
IETF managed YANG modules that need to allocate SIDs use the IANA | ||||
mechanism specified in this document. | ||||
Suggested: | ||||
IETF-managed YANG modules that need to allocate SIDs will use the | ||||
IANA mechanisms (e.g., allocation mechanisms) specified in this | ||||
document. See Section 6 for details. --> | ||||
</t> | ||||
<t>Among other uses, YANG SIDs are particularly useful for obtaining a | ||||
compact encoding for YANG-CBOR <xref target="RFC9254"/>. | compact encoding for YANG-CBOR <xref target="RFC9254"/>. | |||
At the time of writing, a tool for automated ".sid" file generation is | At the time of writing, a tool for automated ".sid" file generation is | |||
available as part of the open-source project PYANG <xref target="PYANG"/>.</t> | available as part of the open-source project PYANG <xref target="PYANG"/>.</t> | |||
<section anchor="terminology-and-notation"> | <section anchor="terminology-and-notation"> | |||
<name>Terminology and Notation</name> | <name>Terminology and Notation</name> | |||
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp | <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", | |||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO | "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", | |||
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | "<bcp14>SHOULD NOT</bcp14>", | |||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
nterpreted as | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and | are to be interpreted as described in BCP 14 | |||
only when, they | <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only | |||
appear in all capitals, as shown here.</t> | when, they appear in all capitals, as shown here.</t> | |||
<?line -18?> | ||||
<t>The following terms are defined in <xref target="RFC7950"/>:</t> | <t>The following terms are defined in <xref target="RFC7950"/>:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>action</t> | <t>action</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>feature</t> | <t>feature</t> | |||
</li> | </li> | |||
<li> | <li> | |||
skipping to change at line 201 ¶ | skipping to change at line 317 ¶ | |||
<t>schema node</t> | <t>schema node</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>schema tree</t> | <t>schema tree</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>submodule</t> | <t>submodule</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>This specification also makes use of the following terminology:</t> | <t>This specification also makes use of the following terminology:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li> | <dt>item:</dt><dd>A schema node, an identity, a module, or a feature d | |||
<t>item: A schema node, an identity, a module, or a feature defined | efined using the YANG modeling language.</dd> | |||
using the YANG modeling language.</t> | <dt>YANG Schema Item iDentifier (YANG SID or simply SID):</dt><dd>Unsi | |||
</li> | gned | |||
<li> | integer used to identify different YANG items (cf. <xref section="3.2" sect | |||
<t>YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned | ionFormat="of" target="RFC9254"/>).</dd> | |||
integer used to identify different YANG items (cf. <xref section="3.2" sectionFo | <dt>YANG name:</dt><dd>Text string used to identify different YANG ite | |||
rmat="of" target="RFC9254"/>).</t> | ms | |||
</li> | (cf. <xref section="3.3" sectionFormat="of" target="RFC9254"/>).</dd> | |||
<li> | </dl> | |||
<t>YANG Name: Text string used to identify different YANG items | ||||
(cf. <xref section="3.3" sectionFormat="of" target="RFC9254"/>).</t> | ||||
</li> | ||||
</ul> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="objectives"> | <section anchor="objectives"> | |||
<name>Objectives</name> | <name>Objectives</name> | |||
<t>The overriding objective of the SID assignment and registration system is to | <t>The overriding objective of the SID assignment and registration system is to | |||
ensure global interoperability of protocols that employ SIDs in order | ensure global interoperability of protocols that employ SIDs in order | |||
to communicate about data modeled in YANG. | to communicate about data modeled in YANG. | |||
This objective poses certain requirements on the stability of SIDs | This objective poses certain requirements on the stability of SIDs | |||
while at the same time not hindering active evolution of the YANG | while at the same time not hindering active evolution of the YANG | |||
modules the SIDs are intended to support.</t> | modules the SIDs are intended to support. | |||
<!-- [rfced] Sections 2 and 4: As it appears that the "YANG" in | ||||
"in YANG" at the end of these sentences refers to RFC 7950, for | ||||
ease of the reader, may we update as suggested? | ||||
Original: | ||||
The overriding objective of the SID assignment and registration | ||||
system is to ensure global interoperability of protocols that employ | ||||
SIDs in order to communicate about data modeled in YANG. | ||||
... | ||||
description | ||||
"The namespace for all data nodes, as defined in | ||||
YANG."; | ||||
Suggested: | ||||
The overriding objective of the SID assignment and registration | ||||
system is to ensure global interoperability of protocols that employ | ||||
SIDs in order to communicate about data modeled in YANG [RFC7950]. | ||||
... | ||||
description | ||||
"The namespace for all data nodes, as defined in | ||||
YANG."; | ||||
reference "RFC 7950: The YANG 1.1 Data Modeling Language"; --> | ||||
</t> | ||||
<t>Additional objectives include:</t> | <t>Additional objectives include:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>enabling the developer of a YANG module to also be the originating | <t>enabling the developer of a YANG module to also be the originating | |||
entity for the SIDs pertaining to that module.</t> | entity for the SIDs pertaining to that module.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>making it easy for YANG developers to obtain SIDs.</t> | <t>making it easy for YANG developers to obtain SIDs.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>enabling other developers to define SIDs for a module where the | <t>enabling other developers to define SIDs for a module where the | |||
developer of the module is not interested in assigning the SIDs.</t> | developer of the module is not interested in assigning the SIDs.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>keeping an assignment regime that keeps short (2..4 byte) SIDs | <t>keeping an assignment regime that keeps short SIDs (2..4 bytes) | |||
readily available for the applications that would benefit from them | readily available for the applications that would benefit from them | |||
while at the same time employing the vast 63-bit SID space to | while at the same time employing the vast 63-bit SID space to | |||
facilitate permissionless actions.</t> | facilitate permissionless actions.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>enabling multiple entities to provide services that support the | <t>enabling multiple entities to provide services that support the | |||
assignment of SIDs.</t> | assignment of SIDs.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>maintaining some locality in the assignment of SIDs so the | <t>maintaining some locality in the assignment of SIDs so the | |||
efficiencies of the SID delta mechanism can be fully employed.</t> | efficiencies of the SID delta mechanism can be fully employed.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>enabling various software components to deal in terms of SIDs | <t>enabling various software components to deal in terms of SIDs | |||
without having complete information about other parties in the | without having complete information about other parties in the | |||
communication process.</t> | communication process. | |||
<!-- [rfced] Section 2: We could not follow the use of the word | ||||
"deal" in this sentence, even after looking at definitions in an | ||||
online dictionary (https://www.merriam-webster.com/dictionary/deal). | ||||
Are some words missing? If not, will "to deal in terms of" be clear | ||||
to readers? | ||||
Original: | ||||
* enabling various software components to deal in terms of SIDs | ||||
without having complete information about other parties in the | ||||
communication process. | ||||
Possibly ("operate" rather than "deal"): | ||||
* enabling various software components to operate in terms of SIDs | ||||
without having complete information about other parties in the | ||||
communication process. --> | ||||
</t> | ||||
</li> | </li> | |||
</ul> | </ul> | |||
<t>While IANA ultimately maintains the registries that govern SIDs for | <t>While IANA ultimately maintains the registries that govern SIDs for | |||
IETF-defined modules, various support tools (such as, at the time of | IETF-defined modules, various support tools (such as, at the time of | |||
writing, the YANG Catalog <xref target="yangcatalog"/>) | writing, the YANG Catalog <xref target="yangcatalog"/>) | |||
need to provide the support to enable SID assignment and use for | need to provide the support to enable SID assignment and use for | |||
modules still in IETF development. Developers of open-source or | modules still in IETF development. Developers of open-source or | |||
proprietary YANG modules also need to be able to serve as such | proprietary YANG modules also need to be able to serve as such | |||
entities autonomously, possibly forming alliances independent of the | entities autonomously, possibly forming alliances independent of the | |||
IETF, while still fitting in the overall SID number space managed by | IETF, while still fitting in the overall SID number space managed by | |||
IANA. Obviously, this process has a number of parallels to the | IANA. Obviously, this process has a number of parallels to the | |||
management of IP addresses, but also is very different.</t> | management of IP addresses but is also very different.</t> | |||
<section anchor="technical-objectives"> | <section anchor="technical-objectives"> | |||
<name>Technical Objectives</name> | <name>Technical Objectives</name> | |||
<t>As discussed in the introduction, SIDs are intended as globally uniqu e | <t>As discussed in <xref format="none" target="introduction">the Introdu ction</xref>, SIDs are intended as globally unique | |||
(unsigned) integers.</t> | (unsigned) integers.</t> | |||
<t>Specifically, this means that:</t> | <t>Specifically, this means that:</t> | |||
<dl> | <dl> | |||
<dt><strong>Objective 1</strong> (<bcp14>MUST</bcp14>):</dt> | <dt><strong>Objective 1</strong> (<bcp14>MUST</bcp14>):</dt> | |||
<dd> | <dd> | |||
<t>any 63-bit unsigned integer is either | <t>Any 63-bit unsigned integer either (1) is unassigned as a SI | |||
unassigned as a SID or immutably maps to EXACTLY one YANG name. | D or (2) immutably maps to EXACTLY one YANG name. | |||
Only the transition from unassigned to that immutable mapping is | Only the transition from unassigned to that immutable mapping is | |||
defined.</t> | defined.</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t>This enables a recipient of a data structure employing SIDs to | <t>This enables a recipient of a data structure employing SIDs to | |||
translate them into the globally meaningful YANG names that the | translate them into the globally meaningful YANG names that the | |||
existing encodings of YANG data such as YANG-XML <xref target="RFC7950"/> and | existing encodings of YANG data such as YANG-XML <xref target="RFC7950"/> and | |||
YANG-JSON <xref target="RFC7951"/> employ today.</t> | YANG-JSON <xref target="RFC7951"/> employ today.</t> | |||
<t>The term YANG name is not defined outside this document, and YANG has | <!-- [rfced] Please confirm that YANG-XML and YANG-JSON will be widely understoo | |||
d, as they are not commonly used in RFCs (YANG-XML appears once in RFC 9254 and | ||||
YANG-JSON has never been used). | ||||
Original: | ||||
This enables a recipient of a data structure employing SIDs to | ||||
translate them into the globally meaningful YANG names that the | ||||
existing encodings of YANG data such as YANG-XML [RFC7950] and YANG- | ||||
JSON [RFC7951] employ today. | ||||
--> | ||||
<t>The term "YANG name" is not defined outside this document, and YANG h | ||||
as | ||||
a complex system of names and entities that can have those names. | a complex system of names and entities that can have those names. | |||
Instead of defining the term technically, this set of objectives uses | Instead of defining the term technically, this set of objectives uses | |||
it in such a way that the overall objectives of YANG-SID can be | it in such a way that the overall objectives of YANG SID can be | |||
achieved.</t> | achieved.</t> | |||
<t>A desirable objective is that:</t> | <t>A desirable objective is that:</t> | |||
<dl> | <dl> | |||
<dt><strong>Objective 2</strong> (<bcp14>SHOULD</bcp14>):</dt> | <dt><strong>Objective 2</strong> (<bcp14>SHOULD</bcp14>):</dt> | |||
<dd> | <dd> | |||
<t>any YANG name in active use has one SID assigned.</t> | <t>Any YANG name in active use has one SID assigned.</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t>This means that:</t> | <t>This means that:</t> | |||
<ol spacing="normal" type="1"><li> | <ol spacing="normal" type="1"><li> | |||
<t>There should not be YANG names without SIDs assigned</t> | <t>There should not be YANG names without SIDs assigned.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>YANG names should not have multiple SIDs assigned</t> | <t>YANG names should not have multiple SIDs assigned.</t> | |||
</li> | </li> | |||
</ol> | </ol> | |||
<t>These objectives are unattainable in full, because YANG names are not | <t>These objectives are unattainable in full, because YANG names are not | |||
necessarily born with a SID assignment, and because entirely autonomous | necessarily born with a SID assignment and because entirely autonomous | |||
entities might decide to assign SIDs for the same YANG name without | entities might decide to assign SIDs for the same YANG name without | |||
communicating ("like ships in the night"). | communicating ("like ships in the night"). | |||
Note that as long as this autonomy is maintained, any single observer | Note that as long as this autonomy is maintained, any single observer | |||
will have the impression that Objective 2 is attained. | will have the impression that Objective 2 is attained. | |||
Only when entities that have acted autonomously start communicating, a | Only when entities that have acted autonomously start communicating will a | |||
deviation is observed.</t> | deviation be observed.</t> | |||
</section> | </section> | |||
<section anchor="module-evolution-versioning"> | <section anchor="module-evolution-versioning"> | |||
<name>Module evolution, versioning</name> | <name>Module Evolution and Versioning</name> | |||
<t>YANG modules evolve (see <xref section="11" sectionFormat="of" target | <t>YANG modules evolve (see <xref section="11" sectionFormat="of" target | |||
="RFC7950"/>, <xref section="4.27" sectionFormat="of" target="RFC8407"/>). | ="RFC7950"/> and <xref section="4.27" sectionFormat="of" target="RFC8407"/>). | |||
The technical objectives listed above are states in terms that are | The technical objectives listed above are states in terms that are | |||
independent of this evolution.</t> | independent of this evolution.</t> | |||
<t>However, some modules are still in a very fluid state, and the | <t>However, some modules are still in a very fluid state, and the | |||
assignment of permanent SIDs to the YANG names created in them is less | assignment of permanent SIDs to the YANG names created in them is less | |||
desirable. This is not only true for new modules, but also for | desirable. This is true not only for new modules but also for | |||
emerging new revisions of existing stable modules.</t> | emerging new revisions of existing stable modules.</t> | |||
<dl> | <dl> | |||
<dt><strong>Objective 3</strong> (<bcp14>MUST</bcp14>):</dt> | <dt><strong>Objective 3</strong> (<bcp14>MUST</bcp14>):</dt> | |||
<dd> | <dd> | |||
<t>the SID management system is independent of any module versioning .</t> | <t>The SID management system is independent of any module versioning .</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
</section> | </section> | |||
<section anchor="solution-components-and-derived-objectives"> | <section anchor="solution-components-and-derived-objectives"> | |||
<name>Solution Components and Derived Objectives</name> | <name>Solution Components and Derived Objectives</name> | |||
<t>A registration system is used in order to guarantee the uniqueness of | <t>A registration system is used in order to guarantee the uniqueness of | |||
SIDs. | SIDs. | |||
To be able to provide some autonomy in allocation (and avoid | To be able to provide some autonomy in allocation (and avoid | |||
information disclosure where it is not desirable), SIDs are registered | information disclosure where it is not desirable), SIDs are registered | |||
in blocks called "SID ranges".</t> | in blocks called "SID ranges".</t> | |||
skipping to change at line 350 ¶ | skipping to change at line 511 ¶ | |||
</section> | </section> | |||
<section anchor="parties-roles"> | <section anchor="parties-roles"> | |||
<name>Parties and Roles</name> | <name>Parties and Roles</name> | |||
<t>In the YANG development process, we can discern a number of parties | <t>In the YANG development process, we can discern a number of parties | |||
that are concerned with a YANG module:</t> | that are concerned with a YANG module:</t> | |||
<dl newline="true"> | <dl newline="true"> | |||
<dt>module controller:</dt> | <dt>module controller:</dt> | |||
<dd> | <dd> | |||
<t>The owner of the YANG module, i.e., the controller | <t>The owner of the YANG module, i.e., the controller | |||
about its evolution.</t> | about its evolution.</t> | |||
<!-- [rfced] Section 2.4: Please clarify the meaning of "the | ||||
controller about its evolution". Are some words missing? | ||||
Original: | ||||
module controller: | ||||
The owner of the YANG module, i.e., the controller about its | ||||
evolution. | ||||
Possibly: | ||||
module controller: | ||||
The owner of the YANG module, i.e., the controller of the | ||||
module's evolution. --> | ||||
</dd> | </dd> | |||
<dt>registration entity:</dt> | <dt>registration entity:</dt> | |||
<dd> | <dd> | |||
<t>The controller of the module namespace, specifically also of the | <t>The controller of the module namespace, specifically also of the | |||
prefixes that are in common use. (This is not a required party.)</t> | prefixes that are in common use. (This is not a required party.)</t> | |||
</dd> | </dd> | |||
<dt>module repository:</dt> | <dt>module repository:</dt> | |||
<dd> | <dd> | |||
<t>An entity that supplies modules to module users. This can be | <t>An entity that supplies modules to module users. This can be an | |||
"official" (e.g., IANA for IETF modules) or unofficial (e.g., the | "official" entity (e.g., IANA for IETF modules) or an "unofficial" entity (e.g., | |||
the | ||||
YANG Catalog <xref target="yangcatalog"/>). Not all repositories are in a posit ion to act as | YANG Catalog <xref target="yangcatalog"/>). Not all repositories are in a posit ion to act as | |||
a registry, i.e., as a permanent record for the information they | a registry, i.e., as a permanent record for the information they | |||
supply; these repositories need to recur to module owners as a | supply; these repositories need to recur to module owners as a | |||
stable source.</t> | stable source. | |||
<!-- [rfced] Section 2.4: We had trouble following the use of | ||||
"recur" in this sentence. Will this text be clear to readers? | ||||
Original: | ||||
Not all repositories are in a | ||||
position to act as a registry, i.e., as a permanent record for the | ||||
information they supply; these repositories need to recur to | ||||
module owners as a stable source. --> | ||||
</t> | ||||
</dd> | </dd> | |||
<dt>module user:</dt> | <dt>module user:</dt> | |||
<dd> | <dd> | |||
<t>An entity that uses a module, after obtaining it from the module | <t>An entity that uses a module, after obtaining it from the module | |||
controller or a module repository.</t> | controller or a module repository.</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t>This set of parties needs to evolve to take on the additional roles | <t>This set of parties needs to evolve to take on the additional roles | |||
that the SID assignment process requires:</t> | that the SID assignment process requires:</t> | |||
<dl newline="true"> | <dl newline="true"> | |||
<dt>SID assigner:</dt> | <dt>SID assigner:</dt> | |||
<dd> | <dd> | |||
<t>An entity that assigns SIDs for a module. Objective 2 aims at | <t>An entity that assigns SIDs for a module. Objective 2 aims at | |||
having only one SID assigner for each module. SID assigners | having only one SID assigner for each module. SID assigners | |||
preferably stay the same over a module development process; however | preferably stay the same over a module development process; however, | |||
this specification provides SID files to ensure an organized handover.</t> | this specification provides SID files to ensure an organized handover.</t> | |||
</dd> | </dd> | |||
<dt>SID range registries:</dt> | <dt>SID range registry:</dt> | |||
<dd> | <dd> | |||
<t>The entities that supply a SID assigner with SID ranges that they can | <t>An entity that supplies a SID assigner with SID ranges that it ca n | |||
use in assigning SIDs for a module. (In this specification, there | use in assigning SIDs for a module. (In this specification, there | |||
is a structure with mega-ranges and individual SID ranges; this is | is a structure with mega-ranges and individual SID ranges; this is | |||
not relevant here.)</t> | not relevant here.)</t> | |||
</dd> | </dd> | |||
<dt>SID repository:</dt> | <dt>SID repository:</dt> | |||
<dd> | <dd> | |||
<t>An entity that supplies SID assignments to SID users, usually in the | <t>An entity that supplies SID assignments to SID users, usually in the | |||
form of a SID file.</t> | form of a SID file.</t> | |||
</dd> | </dd> | |||
<dt>SID users:</dt> | <dt>SID user:</dt> | |||
<dd> | <dd> | |||
<t>The module user that uses the SIDs provided by a SID assigner for a YANG | <t>The module user that uses the SIDs provided by a SID assigner for a YANG | |||
module. SID users need to find SID assigners (or at least their SID | module. SID users need to find SID assigners (or at least their SID | |||
assignments).</t> | assignments).</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t>During the introduction of SIDs, the distribution of the SID roles to | <t>During the introduction of SIDs, the distribution of the SID roles to | |||
the existing parties for a YANG module will evolve.</t> | the existing parties for a YANG module will evolve.</t> | |||
<t>The desirable end state of this evolution is shown in <xref target="r | <t>The desirable end state of this evolution is shown in <xref target="r | |||
oles-parties"/>.</t> | oles-parties"/>. | |||
<!-- [rfced] Sections 2.4 and 6.5.3: We found the "During ..." | ||||
clauses in these sentences confusing. If the suggested text is not | ||||
correct, please provide clarifying text. | ||||
Original: | ||||
During the introduction of SIDs, the distribution of the SID roles to | ||||
the existing parties for a YANG module will evolve. | ||||
... | ||||
During the early use of SIDs, many existing, previously published | ||||
YANG modules will not have SID allocations. | ||||
Suggested: | ||||
As new SIDs are introduced, the distribution of the SID roles to | ||||
the existing parties for a YANG module will evolve. | ||||
... | ||||
As new SIDs are first used, many existing, previously published | ||||
YANG modules will not have SID allocations. --> | ||||
</t> | ||||
<table anchor="roles-parties"> | <table anchor="roles-parties"> | |||
<name>Roles and Parties: Desired End State</name> | <name>Roles and Parties: Desired End State</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Role</th> | <th align="left">Role</th> | |||
<th align="left">Party</th> | <th align="left">Party</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
skipping to change at line 430 ¶ | skipping to change at line 636 ¶ | |||
<tr> | <tr> | |||
<td align="left">SID repository</td> | <td align="left">SID repository</td> | |||
<td align="left">module repository</td> | <td align="left">module repository</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">SID user</td> | <td align="left">SID user</td> | |||
<td align="left">module user (naturally)</td> | <td align="left">module user (naturally)</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>This grouping of roles and parties puts the module developer into a | <t>This grouping of roles and parties puts the module developer in a | |||
position where it can achieve the objectives laid out in this section | position where it can achieve the objectives laid out in this section | |||
(a "type-1", "SID-guiding" module controller). | (a "type-1", "SID-guiding" module controller). | |||
(While a third party might theoretically assign additional SIDs and | (While a third party might theoretically assign additional SIDs and | |||
conflict with objective 2, there is very little reason to do so if SID | conflict with Objective 2, there is very little reason to do so if SID | |||
files are always provided by the module developer with the module.)</t> | files are always provided by the module developer with the module.)</t> | |||
<t>The rest of this section is concerned with the transition to this end | <t>The rest of this section is concerned with the transition to this end | |||
state.</t> | state.</t> | |||
<t>For existing modules, there is no SID file. The entity that stands i n | <t>For existing modules, there is no SID file. The entity that stands i n | |||
as the SID assigner is not specified. This situation has the highest | as the SID assigner is not specified. This situation has the highest | |||
potential of a conflict with objective 2.</t> | potential for conflict with Objective 2.</t> | |||
<t>Similarly, for new module development, the module owner may not have | <t>Similarly, for new module development, the module owner may not have | |||
heard about SIDs or not be interested in assigning them (e.g., because | heard about SIDs or may not be interested in assigning them (e.g., because | |||
of lack of software or procedures within their organization).</t> | of lack of software or procedures within their organization).</t> | |||
<t>For these two cases (which we will call type-3, "SID-oblivious" modul | <t>For these two cases (which we will call "type-3", "SID-oblivious" mod | |||
e | ule | |||
controller), module repositories can act as a mediator, giving SID | controllers), module repositories can act as a mediator, giving SID | |||
users access to a SID assigner that is carefully chosen to be a likely | users access to a SID assigner that is carefully chosen to be a likely | |||
choice by other module repositories as well, maximizing the likelihood | choice by other module repositories as well, maximizing the likelihood | |||
of achieving objective 2.</t> | of achieving Objective 2. | |||
<t>If the module controller has heard about SIDs, but is not assigning | ||||
<!-- [rfced] Section 2.4: Because this sentence mentions two cases, | ||||
we changed "module controller" to "module controllers". If this is | ||||
incorrect, please clarify what "two cases" refers to. | ||||
Original: | ||||
For these two cases (which we will call type-3, "SID-oblivious" | ||||
module controller), module repositories can act as a mediator, giving | ||||
SID users access to a SID assigner that is carefully chosen to be a | ||||
likely choice by other module repositories as well, maximizing the | ||||
likelihood of achieving objective 2. | ||||
Currently: | ||||
For these two cases (which we will call "type-3", "SID-oblivious" | ||||
module controllers), module repositories can act as a mediator, | ||||
giving SID users access to a SID assigner that is carefully chosen to | ||||
be a likely choice by other module repositories as well, maximizing | ||||
the likelihood of achieving Objective 2. --> | ||||
</t> | ||||
<t>If a module controller has heard about SIDs but is not assigning | ||||
them yet, it can designate a SID assigner instead. This can lead to a | them yet, it can designate a SID assigner instead. This can lead to a | |||
stable, unique set of SID assignments being provided indirectly by a | stable, unique set of SID assignments being provided indirectly by a | |||
(type-2, "SID-aware") module developer. Entities offering designated | ("type-2", "SID-aware") module developer. Entities offering designated | |||
SID assigner services could make these available in an easy-to-use | SID assigner services could make these available in an easy-to-use | |||
way, e.g., via a Web interface.</t> | way, e.g., via a web interface.</t> | |||
<t>The entity acting as a SID assigner minimally needs to record the SID | <t>The entity acting as a SID assigner minimally needs to record the SID | |||
range it uses for the SID assignment. If the SID range registry can | range it uses for the SID assignment. If the SID range registry can | |||
record the module name and revision, and the assignment processes | record the module name and revision and if the assignment processes | |||
(including the software used) are stable, the SID assigner can | (including the software used) are stable, the SID assigner can | |||
theoretically reconstruct its assignments, but this is an invitation | theoretically reconstruct its assignments, but this could invite | |||
for implementation bugs.</t> | implementation bugs.</t> | |||
<t>SID assigners attending to a module in development (not yet stable) | <t>SID assigners attending to a module in development (not yet stable) | |||
need to decide whether SIDs for a new revision are re-assigned from | need to decide whether SIDs for a new revision are reassigned from | |||
scratch ("clean-slate") or use existing assignments from a previous | scratch ("clean slate") or use existing assignments from a previous | |||
revision as a base, only assigning new SIDs for new names. | revision as a base, only assigning new SIDs for new names. | |||
Once a module is declared stable, its SID assignments <bcp14>SHOULD</bcp14> be | Once a module is declared stable, its SID assignments <bcp14>SHOULD</bcp14> be | |||
declared stable as well (the exception being that, for existing YANG | declared stable as well (except that, for existing YANG | |||
modules, some review may be needed before this is done).</t> | modules, some review may be needed before this is done).</t> | |||
<t>This specification does not further discuss how mediating entities | <t>This specification does not further discuss how mediating entities | |||
such as designated SID assigners or SID repositories could operate; | such as designated SID assigners or SID repositories could operate; | |||
instead, it supplies objectives for their operation.</t> | instead, it supplies objectives for their operation.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sid-lifecycle"> | <section anchor="sid-lifecycle"> | |||
<name>".sid" file lifecycle</name> | <name>".sid" File Lifecycle</name> | |||
<t>YANG is a language designed to model data accessed using one of the com patible | <t>YANG is a language designed to model data accessed using one of the com patible | |||
protocols (e.g. NETCONF <xref target="RFC6241"/>, RESTCONF <xref target="RFC8040 "/> and CORECONF <xref target="I-D.ietf-core-comi"/>). A | protocols (e.g., NETCONF <xref target="RFC6241"/>, RESTCONF <xref target="RFC804 0"/>, and the CoAP Management Interface (CORECONF) <xref target="CORE-COMI"/>). A | |||
YANG module defines hierarchies of data, including configuration, state data, | YANG module defines hierarchies of data, including configuration, state data, | |||
RPCs, actions and notifications.</t> | RPCs, actions, and notifications.</t> | |||
<t>Many YANG modules are not created in the context of constrained | <t>Many YANG modules are not created in the context of constrained | |||
applications. YANG modules can be implemented using NETCONF <xref target="RFC624 1"/> or | applications. YANG modules can be implemented using NETCONF <xref target="RFC624 1"/> or | |||
RESTCONF <xref target="RFC8040"/> without the need to assign SIDs.</t> | RESTCONF <xref target="RFC8040"/> without the need to assign SIDs.</t> | |||
<t>As needed, authors of YANG modules can assign SIDs to their YANG module s. In | <t>As needed, authors of YANG modules can assign SIDs to their YANG module s. In | |||
order to do that, they should first obtain a SID range from a registry and use | order to do that, they should first obtain a SID range from a registry and use | |||
that range to assign or generate SIDs to items of their YANG module. The | that range to assign or generate SIDs to items in their YANG module. The | |||
assignments can then be stored in a ".sid" file. For | assignments can then be stored in a ".sid" file. For an | |||
example on how this could be achieved, please refer to <xref target="sid-lifecyc | example of how this could be achieved, please refer to <xref target="sid-lifecyc | |||
le-ex"/>.</t> | le-ex"/>.</t> | |||
<t>Items introduced by a new revision of a YANG module are added to the li st of SIDs already assigned. | <t>Items introduced by a new revision of a YANG module are added to the li st of SIDs already assigned. | |||
When this is done during development of a new protocol document, it may be neces | When this is done during the development of a new protocol document, it may be n | |||
sary to make provisional assignments. | ecessary to make provisional assignments. | |||
They may get changed, revised or withdrawn during the development of a new stand | They may get changed, revised, or withdrawn during the development of a new stan | |||
ard. | dard. | |||
These provisional assignments are marked with a status of "unstable", | These provisional assignments are marked with a status of "unstable", | |||
so that they can be removed and the SID number possibly be reassigned | so that they can be removed and the SID number possibly reassigned | |||
for a different YANG schema name/path later during development. | for a different YANG schema name/path later in the development process. | |||
When the specification is advanced to a final document, then | When the specification is advanced to a final document, | |||
the assignment is marked with a status of "stable". | the assignment is marked with a status of "stable". | |||
During a period of development starting from a published | During a period of development starting from a published | |||
specification, two variants of the SID file should | specification, two variants of the SID file should | |||
be made available by the tooling involved in that development: (1) a | be made available by the tooling involved in that development: (1) a | |||
"published" SID file with the existing stable SID assignments only | "published" SID file with the existing stable SID assignments only | |||
(which the development effort should keep stable), as | (which the development effort should keep stable), as | |||
well as (2) an "unpublished" SID file that also contains the unstable | well as (2) an "unpublished" SID file that also contains the unstable | |||
SID assignments.</t> | SID assignments.</t> | |||
<t>Registration of the ".sid" file associated to a YANG module is optional | <t>Registration of the ".sid" file associated with a YANG module is option | |||
but | al but | |||
recommended, <!-- sic. --> in order to promote interoperability between devices | recommended, in order to promote interoperability between devices and to avoid d | |||
and to avoid duplicate | uplicate | |||
allocation of SIDs to a single YANG module. Different registries might have | allocation of SIDs to a single YANG module. Different registries might have | |||
different requirements for the registration and publication of the ".sid" | different requirements for the registration and publication of the ".sid" | |||
files. For a diagram of one of the possibilities, please refer to the activity | files. For a diagram of one possible scenario, please refer to the activity | |||
diagram on <xref target="fig-sid-file-creation"/> in <xref target="sid-lifecycle | diagram shown in <xref target="fig-sid-file-creation"/> in <xref target="sid-lif | |||
-ex"/>.</t> | ecycle-ex"/>. | |||
<t>Each time a YANG module or one of its imported module(s) or included | ||||
submodule(s) is updated, a new ".sid" file <bcp14>MAY</bcp14> be created if the | <!-- [rfced] Section 3: We found the comment "sic." embedded in the | |||
new or | middle of this sentence in the provided XML file. We removed the | |||
comment. We do not see an issue with the text. Is any action needed | ||||
related to the comment? | ||||
Original (comment placed in square brackets): | ||||
Registration of the ".sid" file associated to a YANG module is | ||||
optional but recommended, [sic.] in order to promote | ||||
interoperability between devices and to avoid duplicate allocation | ||||
of SIDs to a single YANG module. | ||||
If you were thinking of rephrasing, perhaps: | ||||
Registration of the ".sid" file associated with a YANG module is | ||||
optional but recommended; doing so would promote interoperability | ||||
between devices and avoid duplicate allocation of SIDs to a single | ||||
YANG module. --> | ||||
</t> | ||||
<t>Each time a YANG module, one or more of its imported modules, or one or | ||||
more of its included | ||||
submodules are updated, a new ".sid" file <bcp14>MAY</bcp14> be created if the n | ||||
ew or | ||||
updated items will need SIDs. All the SIDs present in the previous version of | updated items will need SIDs. All the SIDs present in the previous version of | |||
the ".sid" file <bcp14>MUST</bcp14> be present in the new version as well. The c reation of | the ".sid" file <bcp14>MUST</bcp14> be present in the new version as well. The c reation of | |||
this new version of the ".sid" file <bcp14>SHOULD</bcp14> be performed using an automated | this new version of the ".sid" file <bcp14>SHOULD</bcp14> be performed using an automated | |||
tool.</t> | tool. | |||
<!-- [rfced] Section 3: This sentence was difficult to follow. We | ||||
updated it as noted below. If this is incorrect, please clarify the | ||||
text. | ||||
Original: | ||||
Each time a YANG module or one of its imported module(s) or included | ||||
submodule(s) is updated, a new ".sid" file MAY be created if the new | ||||
or updated items will need SIDs. | ||||
Currently: | ||||
Each time a YANG module, one or more of its imported modules, or one | ||||
or more of its included submodules are updated, a new ".sid" file MAY | ||||
be created if the new or updated items will need SIDs. --> | ||||
</t> | ||||
<t>If a new revision requires more SIDs than initially allocated, a new SI D range | <t>If a new revision requires more SIDs than initially allocated, a new SI D range | |||
<bcp14>MUST</bcp14> be added to the 'assignment-range' as defined in <xref targe t="sid-file-format"/>. | <bcp14>MUST</bcp14> be added to the 'assignment-range' item as defined in <xref target="sid-file-format"/>. | |||
These extra SIDs are used for subsequent assignments.</t> | These extra SIDs are used for subsequent assignments.</t> | |||
<t>For an example of this update process, see activity diagram | <t>For an example of this update process, see the activity diagram shown i n | |||
<xref target="fig-sid-file-update"/> in <xref target="sid-lifecycle-ex"/>.</t> | <xref target="fig-sid-file-update"/> in <xref target="sid-lifecycle-ex"/>.</t> | |||
</section> | </section> | |||
<section anchor="sid-file-format"> | <section anchor="sid-file-format"> | |||
<name>".sid" file format</name> | <name>".sid" File Format</name> | |||
<t>".sid" files are used to persist and publish SIDs assigned to the diffe rent | <t>".sid" files are used to persist and publish SIDs assigned to the diffe rent | |||
YANG items of a specific YANG module.</t> | YANG items in a specific YANG module.</t> | |||
<t>It has the following structure:</t> | <t>It has the following structure:</t> | |||
<figure> | <figure> | |||
<name>YANG tree for ietf-sid-file</name> | <name>YANG Tree for 'ietf-sid-file'</name> | |||
<!-- [rfced] Please review the "type" attribute of each sourcecode | ||||
element in the XML file to ensure correctness*. | ||||
If the current list of preferred values for "type" (https://www.rfc-editor.org/m | ||||
aterials/sourcecode-types.txt) | ||||
does not contain an applicable type, please let us know. Also, it is | ||||
acceptable to leave the "type" attribute not set. | ||||
* "<sourcecode type="yang-sid">" and | ||||
"<sourcecode type="yang-instance-data">" are not included on the | ||||
sourcecode-types page. Would you like us to request that they be | ||||
added? If not, please provide sourcecode types that are currently | ||||
valid. --> | ||||
<sourcecode type="yangtree"><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
module: ietf-sid-file | module: ietf-sid-file | |||
structure sid-file: | structure sid-file: | |||
+-- module-name yang:yang-identifier | +-- module-name yang:yang-identifier | |||
+-- module-revision? revision-identifier | +-- module-revision? revision-identifier | |||
+-- sid-file-version? sid-file-version-identifier | +-- sid-file-version? sid-file-version-identifier | |||
+-- sid-file-status? enumeration | +-- sid-file-status? enumeration | |||
+-- description? string | +-- description? string | |||
+-- dependency-revision* [module-name] | +-- dependency-revision* [module-name] | |||
skipping to change at line 549 ¶ | skipping to change at line 822 ¶ | |||
+-- assignment-range* [entry-point] | +-- assignment-range* [entry-point] | |||
| +-- entry-point sid | | +-- entry-point sid | |||
| +-- size uint64 | | +-- size uint64 | |||
+-- item* [namespace identifier] | +-- item* [namespace identifier] | |||
+-- status? enumeration | +-- status? enumeration | |||
+-- namespace enumeration | +-- namespace enumeration | |||
+-- identifier union | +-- identifier union | |||
+-- sid sid | +-- sid sid | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<t>The following YANG module defines the structure of this file, encoding | ||||
is | <!-- [rfced] Section 4: RFC 8340 ("YANG Tree Diagrams") is typically | |||
cited in YANG RFCs that include tree diagrams. May we make the | ||||
update suggested below and add RFC 8340 to the Informative References | ||||
section? | ||||
Also, would you like to align the right-hand entries in the tree | ||||
diagram? | ||||
Original (dashes are broken in order to avoid xml2rfc's | ||||
"Double hyphen within comment" error): | ||||
It has the following structure: | ||||
module: ietf-sid-file | ||||
structure sid-file: | ||||
+ - module-name yang:yang-identifier | ||||
+ - module-revision? revision-identifier | ||||
+ - sid-file-version? sid-file-version-identifier | ||||
+ - sid-file-status? enumeration | ||||
+ - description? string | ||||
+ - dependency-revision* [module-name] | ||||
| + - module-name yang:yang-identifier | ||||
| + - module-revision revision-identifier | ||||
+ - assignment-range* [entry-point] | ||||
| + - entry-point sid | ||||
| + - size uint64 | ||||
+ - item* [namespace identifier] | ||||
+ - status? enumeration | ||||
+ - namespace enumeration | ||||
+ - identifier union | ||||
+ - sid sid | ||||
Suggested: | ||||
The following tree diagram [RFC8340] provides an overview of the data | ||||
model: | ||||
module: ietf-sid-file | ||||
structure sid-file: | ||||
+ - module-name yang:yang-identifier | ||||
+ - module-revision? revision-identifier | ||||
+ - sid-file-version? sid-file-version-identifier | ||||
+ - sid-file-status? enumeration | ||||
+ - description? string | ||||
+ - dependency-revision* [module-name] | ||||
| + - module-name yang:yang-identifier | ||||
| + - module-revision revision-identifier | ||||
+ - assignment-range* [entry-point] | ||||
| + - entry-point sid | ||||
| + - size uint64 | ||||
+ - item* [namespace identifier] | ||||
+ - status? enumeration | ||||
+ - namespace enumeration | ||||
+ - identifier union | ||||
+ - sid sid | ||||
... | ||||
In the Informative References section: | ||||
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | ||||
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | ||||
<https://www.rfc-editor.org/info/rfc8340>. --> | ||||
<t>The following YANG module defines the structure of this file. Encoding | ||||
is | ||||
performed in JSON <xref target="RFC8259"/> using the rules defined in <xref targ et="RFC7951"/>. | performed in JSON <xref target="RFC8259"/> using the rules defined in <xref targ et="RFC7951"/>. | |||
It references ietf-yang-types defined in <xref target="RFC6991"/> and ietf-yang- | This module imports 'ietf-yang-types' <xref target="RFC6991"/> and 'ietf-yang-st | |||
structure-ext defined in <xref target="RFC8791"/>.</t> | ructure-ext' <xref target="RFC8791"/>. It also references <xref target="RFC7950 | |||
<t>RFC Ed.: please update the date of the module and Copyright if needed a | "/> and <xref target="RFC8407"/>. | |||
nd remove this note.</t> | ||||
<!-- [rfced] Section 4: We updated this paragraph to more closely | ||||
match comparable introductory paragraphs in other YANG RFCs (i.e., | ||||
all RFCs mentioned in the YANG module are listed in the introductory | ||||
paragraph). Please let us know any objections. | ||||
However, we still have two questions: | ||||
a) Does "structure of this file" mean "the 'ietf-sid-file' structure"? | ||||
If not, should the text be clarified? | ||||
b) YANG RFCs often have the introductory paragraph and YANG module in | ||||
a separate section. Would you like to follow this convention? For | ||||
example, possibly | ||||
4. YANG Tree Diagram: ".sid" File Format | ||||
... | ||||
5. SID File YANG Module | ||||
... | ||||
The following YANG module defines ... | ||||
... | ||||
6. Security Considerations | ||||
etc. | ||||
Original: | ||||
The following YANG module defines the structure of this file, | ||||
encoding is performed in JSON [RFC8259] using the rules defined in | ||||
[RFC7951]. It references ietf-yang-types defined in [RFC6991] and | ||||
ietf-yang-structure-ext defined in [RFC8791]. | ||||
Currently: | ||||
The following YANG module defines the structure of this file. | ||||
Encoding is performed in JSON [RFC8259] using the rules defined in | ||||
[RFC7951]. This module imports 'ietf-yang-types' [RFC6991] and | ||||
'ietf-yang-structure-ext' [RFC8791]. It also references [RFC7950] | ||||
and [RFC8407]. --> | ||||
</t> | ||||
<!-- [rfced] Note that the module parses successfully when the ietf option is no | ||||
t used. However, when the ietf option is used, we get the following warning (no | ||||
te that the double hyphen for ietf-help has been reduced to a single hyphen): | ||||
ietf-sid-file@2024-06-17.yang:56: warning: RFC 8407: Appendix B: The text abo | ||||
ut which RFC this module is part of seems to be missing or is not correct (see p | ||||
yang -ietf-help for details). | ||||
Please review and let us know if any updates are needed. | ||||
--> | ||||
<figure> | <figure> | |||
<name>YANG module ietf-sid-file</name> | <name>YANG Module 'ietf-sid-file'</name> | |||
<sourcecode type="yang" markers="true" name="ietf-sid-file@2023-10-27.ya | <sourcecode name="ietf-sid-file@2024-06-17.yang" type="yang" markers="tr | |||
ng"><![CDATA[ | ue"><![CDATA[ | |||
module ietf-sid-file { | module ietf-sid-file { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; | namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file"; | |||
prefix sid; | prefix sid; | |||
import ietf-yang-types { | import ietf-yang-types { | |||
prefix yang; | prefix yang; | |||
reference "RFC 6991: Common YANG Data Types."; | reference "RFC 6991: Common YANG Data Types"; | |||
} | } | |||
import ietf-yang-structure-ext { | import ietf-yang-structure-ext { | |||
prefix sx; | prefix sx; | |||
reference "RFC 8791: YANG Data Structure Extensions."; | reference "RFC 8791: YANG Data Structure Extensions"; | |||
} | } | |||
organization | organization | |||
"IETF Core Working Group"; | "IETF CORE Working Group"; | |||
contact | contact | |||
"WG Web: <https://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 | |||
<mailto:a@ackl.io> | <mailto:a@ackl.io> | |||
Editor: Ivaylo Petrov | Editor: Ivaylo Petrov | |||
<mailto:ivaylopetrov@google.com>"; | <mailto:ivaylopetrov@google.com>"; | |||
description | description | |||
"Copyright (c) 2023 IETF Trust and the persons identified as | "This module defines the structure of the .sid files. | |||
authors of the code. All rights reserved. | ||||
Redistribution and use in source and binary forms, with or | ||||
without modification, is permitted pursuant to, and subject to | ||||
the license terms contained in, the Revised BSD License set | ||||
forth in Section 4.c of the IETF Trust's Legal Provisions | ||||
Relating to IETF Documents | ||||
(https://trustee.ietf.org/license-info). | ||||
This version of this YANG module is part of RFC XXXX | Each .sid file contains the mapping between each | |||
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself | string identifier defined by a YANG module and a | |||
for full legal notices. | corresponding numeric value called a YANG SID. | |||
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. | Copyright (c) 2024 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | ||||
Each .sid file contains the mapping between each | Redistribution and use in source and binary forms, with or | |||
string identifier defined by a YANG module and a | without modification, is permitted pursuant to, and subject to | |||
corresponding numeric value called YANG SID."; | the license terms contained in, the Revised BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | ||||
Relating to IETF Documents | ||||
(https://trustee.ietf.org/license-info)."; | ||||
revision 2023-10-27 { | revision 2024-06-17 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference "RFC 9595: 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 '[0-9]{4}-[0-9]{2}-[0-9]{2}'; | pattern '[0-9]{4}-[0-9]{2}-[0-9]{2}'; | |||
} | } | |||
description | description | |||
"Represents a date in YYYY-MM-DD format."; | "Represents a date in YYYY-MM-DD format."; | |||
} | } | |||
skipping to change at line 643 ¶ | skipping to change at line 1017 ¶ | |||
type uint32; | 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 "RFC 9595: 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 | |||
as defined by the YANG ABNF rule absolute-schema-nodeid, | identifier as defined by the YANG ABNF rule | |||
except that module names are used instead of prefixes. | 'absolute-schema-nodeid', except that module names are used | |||
instead of prefixes. | ||||
This string additionally follows the following rules: | This string additionally follows the following rules: | |||
o The leftmost (top-level) data node name is always in the | - The leftmost (top-level) data node name is always in the | |||
namespace-qualified form. | namespace-qualified form. | |||
o Any subsequent schema node name is in the | - Any subsequent schema node name is in the | |||
namespace-qualified form if the node is defined in a module | namespace-qualified form if the node is defined in a | |||
other than its parent node, and the simple form is used | module other than its parent node. Otherwise, the | |||
otherwise. No predicates are allowed."; | simple form is used. No predicates are allowed."; | |||
reference | reference "RFC 7950: The YANG 1.1 Data Modeling Language, | |||
"RFC 7950, The YANG 1.1 Data Modeling Language; | Section 6.5: Schema Node Identifier"; | |||
Section 6.5: Schema Node Identifier;"; | ||||
} | } | |||
sx:structure sid-file { | sx:structure sid-file { | |||
uses sid-file-contents; | uses sid-file-contents; | |||
} | } | |||
grouping sid-file { | grouping sid-file { | |||
description "A grouping that contains a YANG container | description | |||
representing the file structure of a .sid files."; | "A grouping that contains a YANG container | |||
representing the file structure of a .sid files."; | ||||
container sid-file { | container sid-file { | |||
description | description | |||
"A wrapper container that together with the sx:structure | "A wrapper container that together with the 'sx:structure' | |||
extension marks the YANG data structures inside as not being | extension marks the YANG data structures inside as not | |||
intended to be implemented as part of a configuration | being intended to be implemented as part of a | |||
datastore or as an operational state within the server."; | configuration datastore or as an operational state within | |||
the server."; | ||||
uses sid-file-contents; | uses sid-file-contents; | |||
} | } | |||
} | } | |||
grouping sid-file-contents { | grouping sid-file-contents { | |||
description | description | |||
"A grouping that defines the contents of a container that | "A grouping that defines the contents of a container that | |||
represents the file structure of a .sid files."; | represents the file structure of a .sid files."; | |||
leaf module-name { | leaf module-name { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"Name of the YANG module associated with this .sid file."; | "Name of the YANG module associated with this .sid file."; | |||
} | } | |||
leaf module-revision { | leaf module-revision { | |||
type revision-identifier; | type revision-identifier; | |||
description | description | |||
"Revision of the YANG module associated with this .sid | "Revision of the YANG module associated with this .sid | |||
file. | file. | |||
This leaf is not present if no revision statement is | This leaf is not present if no revision statement is | |||
defined in the YANG module."; | defined in the YANG module."; | |||
} | } | |||
leaf sid-file-version { | leaf sid-file-version { | |||
type sid-file-version-identifier; | type sid-file-version-identifier; | |||
default 0; | default 0; | |||
description | description | |||
"Optional leaf that specifies the version number of the | "Optional leaf that specifies the version number of the | |||
.sid file. .sid files and the version sequence are | .sid file. .sid files and the version sequence are | |||
specific to a given YANG module revision. This number | specific to a given YANG module revision. This number | |||
starts at zero when there is a new YANG module revision and | starts at zero when there is a new YANG module revision | |||
increases monotonically. This number can distinguish | and increases monotonically. This number can distinguish | |||
updates to the .sid file which are the result of new | updates to the .sid file that are the result of new | |||
processing, or the result of reported errata."; | processing or reported errata."; | |||
} | } | |||
leaf sid-file-status { | leaf sid-file-status { | |||
type enumeration { | type enumeration { | |||
enum unpublished { | enum unpublished { | |||
description | description | |||
"This .sid file is unpublished [RFC8407], also called | "This .sid file is unpublished (RFC 8407) and is | |||
a work-in-progress or workfile. | also called a work in progress or workfile. | |||
This may be when it accompanies an unpublished YANG | This may be when it accompanies an unpublished YANG | |||
module, or when only the .sid file itself is | module or when only the .sid file itself is | |||
unpublished. | unpublished. | |||
The 'item' list MAY contain entries with a status | The 'item' list MAY contain entries with a status | |||
value of 'unstable'."; | value of 'unstable'."; | |||
reference "RFC 8407: Guidelines for Authors and | ||||
Reviewers of Documents Containing | ||||
YANG Data Models"; | ||||
} | } | |||
enum published { | enum published { | |||
description | description | |||
"This .sid file is published, for a published YANG | "This .sid file is published, for a published YANG | |||
module. The 'item' list MUST NOT contain entries with | module. The 'item' list MUST NOT contain entries | |||
a status value of 'unstable'."; | with a status value of 'unstable'."; | |||
} | } | |||
} | } | |||
default published; | default published; | |||
description | description | |||
"Optional leaf that specifies the status of the | "Optional leaf that specifies the status of the | |||
.sid file."; | .sid file."; | |||
} | } | |||
leaf description { | leaf description { | |||
type string; | type string; | |||
description | description | |||
"Free-form meta information about the generated file. It | "Free-form meta-information about the generated file. It | |||
might include .sid file generation tool and time among | might include a .sid file generation tool and time, among | |||
other things."; | other things."; | |||
} | } | |||
list dependency-revision { | list dependency-revision { | |||
key "module-name"; | key "module-name"; | |||
description | description | |||
"Information about the revision used during the .sid file | "Information about the revision used during the .sid file | |||
generation of each YANG module that the module in | generation of each YANG module that the module in | |||
'module-name' imported."; | 'module-name' imported."; | |||
leaf module-name { | leaf module-name { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
description | description | |||
"Name of the YANG module, dependency of 'module-name', | "Name of the YANG module, dependency of 'module-name', | |||
for which revision information is provided."; | for which revision information is provided."; | |||
} | } | |||
leaf module-revision { | leaf module-revision { | |||
type revision-identifier; | type revision-identifier; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"Revision of the YANG module, dependency of | "Revision of the YANG module, dependency of | |||
'module-name', for which revision information is | 'module-name', for which revision information is | |||
provided."; | provided."; | |||
} | } | |||
} | } | |||
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 | |||
by 'module-name' and 'module-revision'. | identified by 'module-name' and 'module-revision'. | |||
- The YANG SID range first available value is entry-point | - The first available value in the YANG SID range is | |||
and the last available value in the range is | 'entry-point', and the last available value in the | |||
(entry-point + size - 1). | range is ('entry-point' + size - 1). | |||
- The YANG SID ranges specified by all assignment-ranges | - The YANG SID ranges specified by all | |||
MUST NOT overlap."; | 'assignment-range' entries 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."; | |||
} | } | |||
leaf size { | leaf size { | |||
type uint64; | type uint64; | |||
mandatory true; | mandatory true; | |||
skipping to change at line 813 ¶ | skipping to change at line 1191 ¶ | |||
"Number of YANG SIDs available for assignment."; | "Number of YANG SIDs available for assignment."; | |||
} | } | |||
} | } | |||
list item { | list item { | |||
key "namespace identifier"; | key "namespace identifier"; | |||
unique "sid"; | unique "sid"; | |||
description | description | |||
"Each entry within this list defines the mapping between | "Each entry within this list defines the mapping between | |||
a YANG item string identifier and a YANG SID. This list | a YANG item string identifier and a YANG SID. This list | |||
MUST include a mapping entry for each YANG item defined by | MUST include a mapping entry for each YANG item defined | |||
the YANG module identified by 'module-name' and | by the YANG module identified by 'module-name' and | |||
'module-revision'."; | 'module-revision'."; | |||
leaf status { | leaf status { | |||
type enumeration { | type enumeration { | |||
enum stable { | enum stable { | |||
value 0; | value 0; | |||
description "This SID allocation has been published as | description | |||
the stable allocation for the given | "This SID allocation has been published as the | |||
namespace and identifier."; | stable allocation for the given namespace and | |||
identifier."; | ||||
} | } | |||
enum unstable { | enum unstable { | |||
value 1; | value 1; | |||
description "This SID allocation has been done during a | description | |||
development process; it is not yet stable."; | "This SID allocation has been done during a | |||
development process; it is not yet stable."; | ||||
} | } | |||
enum obsolete { | enum obsolete { | |||
value 2; | value 2; | |||
description "This SID allocation is no longer in use. | description | |||
It is recorded to avoid reallocation of | "This SID allocation is no longer in use. It is | |||
its SID value."; | recorded to avoid reallocation of its SID value."; | |||
} | } | |||
} | } | |||
default stable; | default stable; | |||
description | description | |||
"The status field contains information about the stability | "The status field contains information about the | |||
of the allocation. For each specific SID value, over time | stability of the allocation. For each specific SID | |||
it can only transition from unstable to stable, | value, over time it can only transition from | |||
and possibly from stable to obsolete."; | 'unstable' to 'stable', and possibly from 'stable' to | |||
'obsolete'."; | ||||
} | } | |||
leaf namespace { | leaf namespace { | |||
type enumeration { | type enumeration { | |||
enum module { | enum module { | |||
value 0; | value 0; | |||
description | description | |||
"All module and submodule names share the same | "All module and submodule names share the same | |||
global module identifier namespace."; | global module identifier namespace."; | |||
} | } | |||
enum identity { | enum identity { | |||
value 1; | value 1; | |||
description | description | |||
"All identity names defined in a module and its | "All identity names defined in a module and its | |||
submodules share the same identity identifier | submodules share the same identity identifier | |||
namespace."; | namespace."; | |||
} | } | |||
enum feature { | enum feature { | |||
value 2; | value 2; | |||
description | description | |||
"All feature names defined in a module and its | "All feature names defined in a module and its | |||
submodules share the same feature identifier | submodules share the same feature identifier | |||
namespace."; | namespace."; | |||
} | } | |||
enum data { | enum data { | |||
value 3; | value 3; | |||
description | description | |||
"The namespace for all data nodes, as defined in | "The namespace for all data nodes, as defined in | |||
YANG."; | YANG."; | |||
} | } | |||
} | } | |||
description | description | |||
"Namespace of the YANG item for this mapping entry."; | "Namespace of the YANG item for this mapping entry."; | |||
} | } | |||
leaf identifier { | leaf identifier { | |||
type union { | type union { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
type schema-node-path; | type schema-node-path; | |||
} | } | |||
description | description | |||
"String identifier of the YANG item for this mapping | "String identifier of the YANG item for this mapping | |||
entry. | entry. | |||
If the corresponding 'namespace' field is 'module', | If the corresponding 'namespace' field is 'module', | |||
'feature', or 'identity', then this field MUST | 'feature', or 'identity', then this field MUST | |||
contain a valid YANG identifier string. | contain a valid YANG identifier string. | |||
If the corresponding 'namespace' field is 'data', | If the corresponding 'namespace' field is 'data', | |||
then this field MUST contain a valid schema-node | then this field MUST contain a valid schema-node | |||
path."; | path."; | |||
} | } | |||
leaf sid { | leaf sid { | |||
type sid; | type sid; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"YANG SID assigned to the YANG item for this mapping | "YANG SID assigned to the YANG item for this mapping | |||
entry."; | entry."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<!-- [rfced] Section 4: We see Andy Bierman listed in the YANG | ||||
module as an editor of this document, but he is not listed as an | ||||
editor or author on the first page or in the Authors' Addresses | ||||
section. We see Andy listed in both the Acknowledgements and in Contributors se | ||||
ctions. Is his inclusion as an editor of the YANG module correct? | ||||
Also, the email address for Alexander Pelov in the YANG module | ||||
is different from the email address | ||||
(alexander.pelov@imt-atlantique.fr) shown in the Authors' Addresses | ||||
section. Should Alexander Pelov's email address be made to match in | ||||
both places? If yes, which address is preferred? | ||||
Original: | ||||
Editor: Michel Veillette | ||||
<mailto:michel.veillette@trilliant.com> | ||||
Editor: Andy Bierman | ||||
<mailto:andy@yumaworks.com> | ||||
Editor: Alexander Pelov | ||||
<mailto:a@ackl.io> | ||||
Editor: Ivaylo Petrov | ||||
<mailto:ivaylopetrov@google.com>"; | ||||
... | ||||
Contributors | ||||
Andy Bierman | ||||
YumaWorks | ||||
... | ||||
--> | ||||
<!-- [rfced] Section 4: | ||||
a) Should RFCs 5234 ("Augmented BNF for Syntax Specifications: ABNF") | ||||
and 6020 be cited here? | ||||
Original: | ||||
description | ||||
"A schema-node path is an absolute YANG schema node identifier | ||||
as defined by the YANG ABNF rule absolute-schema-nodeid, | ||||
except that module names are used instead of prefixes. | ||||
... | ||||
reference | ||||
"RFC 7950, The YANG 1.1 Data Modeling Language; | ||||
Section 6.5: Schema Node Identifier;"; | ||||
Possibly: | ||||
description | ||||
"A schema-node path is an absolute YANG schema node | ||||
identifier as defined by the YANG ABNF rule | ||||
'absolute-schema-nodeid' (RFC 5234, RFC 6020), except that | ||||
module names are used instead of prefixes. | ||||
... | ||||
reference "RFC 5234: Augmented BNF for Syntax Specifications: | ||||
ABNF | ||||
RFC 6020: YANG - A Data Modeling Language for | ||||
the Network Configuration Protocol | ||||
(NETCONF) | ||||
RFC 7950: The YANG 1.1 Data Modeling Language, | ||||
Section 6.5: Schema Node Identifier"; | ||||
If cited, the listing for RFC 5234 would be added to the | ||||
Normative References section. | ||||
b) Should "a .sid files" be "a .sid file" or ".sid files" in these | ||||
description clauses? | ||||
Original: | ||||
grouping sid-file { | ||||
description "A grouping that contains a YANG container | ||||
representing the file structure of a .sid files."; | ||||
... | ||||
grouping sid-file-contents { | ||||
description | ||||
"A grouping that defines the contents of a container that | ||||
represents the file structure of a .sid files."; | ||||
c) As it appears that updates to the .sid file are only sometimes | ||||
the result of new processing or reported errata, we updated this | ||||
sentence accordingly. If this is incorrect, please provide | ||||
clarifying text. | ||||
Original: | ||||
This number can distinguish | ||||
updates to the .sid file which are the result of new | ||||
processing, or the result of reported errata."; | ||||
Currently: | ||||
This number can distinguish | ||||
updates to the .sid file that are the result of new | ||||
processing or reported errata."; | ||||
d) This sentence is difficult to follow. Please clarify the | ||||
meaning of "is published, for a published YANG module". | ||||
Original: | ||||
enum published { | ||||
description | ||||
"This .sid file is published, for a published YANG | ||||
module. | ||||
Possibly: | ||||
enum published { | ||||
description | ||||
"This .sid file is published. This setting applies to | ||||
published YANG modules. | ||||
e) These sentences are difficult to follow. Does the first comma | ||||
indicate that "... of the YANG module" and "dependency of | ||||
'module-name'" mean the same thing, or are two items listed? | ||||
Original: | ||||
leaf module-name { | ||||
type yang:yang-identifier; | ||||
description | ||||
"Name of the YANG module, dependency of 'module-name', | ||||
for which revision information is provided."; | ||||
} | ||||
leaf module-revision { | ||||
type revision-identifier; | ||||
mandatory true; | ||||
description | ||||
"Revision of the YANG module, dependency of | ||||
'module-name', for which revision information is | ||||
provided."; | ||||
} | ||||
Possibly (if two items): | ||||
leaf module-name { | ||||
type yang:yang-identifier; | ||||
description | ||||
"Name of the YANG module and the dependency of | ||||
'module-name',for which revision information is | ||||
provided."; | ||||
} | ||||
leaf module-revision { | ||||
type revision-identifier; | ||||
mandatory true; | ||||
description | ||||
"Revision of the YANG module and the dependency of | ||||
'module-name', for which revision information is | ||||
provided."; | ||||
} --> | ||||
</section> | </section> | |||
<!-- [rfced] Security Considerations: Authors and *[AD]: | ||||
This section does not follow the template specified on the | ||||
"YANG module security considerations" page at | ||||
<https://wiki.ietf.org/group/ops/yang-security-guidelines>, which | ||||
says "Each specification that defines one or more YANG modules MUST | ||||
contain a section that discusses security considerations relevant to | ||||
those modules. This section MUST be patterned after the latest | ||||
approved template ...." | ||||
Please also note the following paragraph on the "YANG module security | ||||
considerations" page: | ||||
'Note: [RFC 8446], [RFC6241], [RFC6242], [RFC8341], and [RFC8040] must | ||||
be "normative references".' | ||||
Per this note, we moved [RFC6241] and [RFC8341] from the Informative | ||||
References section to the Normative References section. [RFC6242] | ||||
and [RFC8446] are neither cited nor listed; please let us know how | ||||
this should be resolved. | ||||
* We will need AD approval if (1) the Security Considerations section | ||||
is to be left "as is" and (2) RFCs 6242 and 8446 are not to be cited. | ||||
Please review the document and the "YANG module security | ||||
considerations" page, and advise. --> | ||||
<section anchor="security-considerations"> | <section anchor="security-considerations"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>This document defines a new type of identifier used to encode data that are modeled in YANG <xref target="RFC7950"/>. | <t>This document defines a new type of identifier used to encode data that are modeled in YANG <xref target="RFC7950"/>. | |||
This new identifier maps semantic concepts to integers, and if the | This new identifier maps semantic concepts to integers, and if the | |||
source of this mapping is not trusted, then new security risks might | source of this mapping is not trusted, then new security risks might | |||
occur if an attacker can control the mapping.</t> | occur if an attacker can control the mapping.</t> | |||
<t>At the time of writing, it is expected that the SID files will be | <t>At the time of writing, it is expected that the SID files will be | |||
processed by a software developer, within a software development | processed by a software developer, within a software development | |||
environment. Developers are advised to only import SID files from | environment. Developers are advised to only import SID files from | |||
authoritative sources. IANA is the authoritative source for IETF | authoritative sources. IANA is the authoritative source for IETF-managed | |||
managed YANG modules.</t> | YANG modules.</t> | |||
<t>Conceptually, SID files could be processed by less-constrained target | <t>Conceptually, SID files could be processed by less-constrained target | |||
systems such as network management systems. Such systems need to take | systems such as network management systems. Such systems need to take | |||
extra care to make sure that they are only processing SID files from | extra care to make sure that they are only processing SID files from | |||
authoritative sources, as authoritative as the YANG modules that they | authoritative sources that are as authoritative as the YANG modules that they | |||
are using.</t> | are using.</t> | |||
<t>SID files are identified with and can employ <em>dereferenceable | <t>SID files are identified with and can employ <em>dereferenceable | |||
identifiers</em>, i.e., identifiers that could lead implementations in | identifiers</em>, i.e., identifiers that could lead implementations in | |||
certain situations to automatically perform a remote access the target | certain situations to automatically perform remote access, the target | |||
of which is indicated at least partially by those identifiers. | of which is indicated at least partially by those identifiers. | |||
This can give an attacker information from and/or control over such | This can give an attacker information from and/or control over such | |||
accesses, which can have security and privacy implications. | accesses, which can have security and privacy implications. | |||
Please also see Sections <xref target="I-D.bormann-t2trg-deref-id" section="5" s | Please also see Sections <xref target="DEREF-ID" section="6" sectionFormat="bare | |||
ectionFormat="bare"/> and <xref target="I-D.bormann-t2trg-deref-id" section="6" | "/> and <xref target="DEREF-ID" section="7" sectionFormat="bare"/> of <xref targ | |||
sectionFormat="bare"/> of <xref target="I-D.bormann-t2trg-deref-id"/> | et="DEREF-ID"/> | |||
for further considerations that may be applicable.</t> | for further considerations that may be applicable. | |||
<!-- [rfced] Section 5: Because Section 5 of | ||||
draft-bormann-t2trg-deref-id is "IANA Considerations" and is only | ||||
one sentence long, and also because Sections 6 and 7 of | ||||
draft-bormann-t2trg-deref-id are "Security considerations" and | ||||
"Privacy considerations", respectively, we updated the section | ||||
numbers here accordingly. Please let us know any concerns. | ||||
Original: | ||||
Please | ||||
also see Sections 5 and 6 of [I-D.bormann-t2trg-deref-id] for further | ||||
considerations that may be applicable. | ||||
Currently: | ||||
Please | ||||
also see Sections 6 and 7 of [DEREF-ID] for further considerations | ||||
that may be applicable. --> | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="IANA"> | <section anchor="IANA"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<section anchor="yang-namespace-registration"> | <section anchor="yang-namespace-registration"> | |||
<name>YANG Namespace Registration</name> | <name>YANG Namespace Registration</name> | |||
<t>This document registers the following XML namespace URN in the "IETF XML | <t>This document registers the following XML namespace URN in the "IETF XML | |||
Registry", following the format defined in <xref target="RFC3688"/>:</t> | Registry", following the format defined in <xref target="RFC3688"/>:</t> | |||
<t>URI: please assign urn:ietf:params:xml:ns:yang:ietf-sid-file</t> | <dl spacing="compact"> | |||
<t>Registrant Contact: The IESG.</t> | <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-sid-file</dd> | |||
<t>XML: N/A, the requested URI is an XML namespace.</t> | <dt>Registrant Contact:</dt><dd>The IESG.</dd> | |||
<t>Reference: RFC XXXX</t> | <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd> | |||
<t>// RFC Ed.: please replace XXXX with RFC number and remove this note< | <dt>Reference:</dt><dd>RFC 9595</dd> | |||
/t> | </dl> | |||
</section> | </section> | |||
<section anchor="iana-module-registration"> | <section anchor="iana-module-registration"> | |||
<name>Register ".sid" File Format Module</name> | <name>".sid" File Format Module Registration</name> | |||
<t>This document registers one YANG module in the "YANG Module Names" re gistry <xref target="RFC6020"/>:</t> | <t>This document registers one YANG module in the "YANG Module Names" re gistry <xref target="RFC6020"/>:</t> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li> | <dt>Name:</dt><dd>ietf-sid-file</dd> | |||
<t>name: ietf-sid-file</t> | <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-sid-file</dd> | |||
</li> | <dt>Prefix:</dt><dd>sid</dd> | |||
<li> | <dt>Reference:</dt><dd>RFC 9595</dd> | |||
<t>namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file</t> | </dl> | |||
</li> | ||||
<li> | ||||
<t>prefix: sid</t> | ||||
</li> | ||||
<li> | ||||
<t>reference: RFC XXXX</t> | ||||
</li> | ||||
</ul> | ||||
<t>// RFC Ed.: please replace XXXX with RFC number and remove this note< | ||||
/t> | ||||
</section> | </section> | |||
<!-- [rfced] Section 6: Should the new registry names indicate the | ||||
plural rather than the singular? We ask because it appears that those | ||||
registries that don't already contain multiple entries eventually | ||||
will. | ||||
In addition, is IETF needed as part of the titles? | ||||
Please see <https://www.iana.org/assignments/yang-sid/>. | ||||
Original: | ||||
YANG SID | ||||
YANG SID Mega-Range | ||||
IETF YANG SID Range | ||||
IETF YANG SID | ||||
Suggested: | ||||
YANG SIDs | ||||
YANG SID Mega-Ranges | ||||
IETF YANG SID Ranges | ||||
IETF YANG SIDs --> | ||||
<section anchor="mega-range-registry"> | <section anchor="mega-range-registry"> | |||
<name>Create new IANA Registry: "YANG SID Mega-Range" registry</name> | <name>New IANA Registry: YANG SID Mega-Range</name> | |||
<t>The name of this registry is "YANG SID Mega-Range". This registry is | <t>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 third part | used to record the delegation of the management of a block of SIDs to third part | |||
ies (such as SDOs or registrars).</t> | ies (such as Standards Development Organizations (SDOs) or registrars).</t> | |||
<section anchor="structure"> | <section anchor="structure"> | |||
<name>Structure</name> | <name>Structure</name> | |||
<t>Each entry in this registry must include:</t> | <t>Each entry in this registry must include:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The entry point (first SID) of the registered SID block.</t> | <t>The entry point (first SID) of the registered SID block.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The size of the registered SID block. | <t>The size of the registered SID block. | |||
The size <bcp14>SHOULD</bcp14> be one million (1 000 000) SIDs, | The size <bcp14>SHOULD</bcp14> be one million (1 000 000) SIDs; | |||
it <bcp14>MAY</bcp14> exceptionally be a multiple of 1 000 000.</t> | it <bcp14>MAY</bcp14> exceptionally be a multiple of 1 000 000. | |||
<!-- [rfced] Section 6.3.1: We had trouble following this sentence. | ||||
If the suggested text is not correct, please clarify "exceptionally | ||||
be". | ||||
Original (the previous sentence is included for context): | ||||
* The size of the registered SID block. The size SHOULD be one | ||||
million (1 000 000) SIDs, it MAY exceptionally be a multiple of | ||||
1 000 000. | ||||
Suggested: | ||||
The size SHOULD be one | ||||
million (1000000) SIDs, but in exceptional cases, it MAY | ||||
be a multiple of 1000000. --> | ||||
</t> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>The policy of SID range allocations: Public, Private or Both.</ | <t>The policy of SID range allocations: Public, Private, or Both. | |||
t> | ||||
<!-- [rfced] Sections 6.3.1 and 6.3.2: Will "Both" be a new type of | ||||
designation (in which case the capitalization should be kept), or | ||||
does it mean "both Public and Private" (in which case it should be | ||||
written as "both" because future entries on the IANA page would be | ||||
- for example - "Public", "Private", or "Public and Private"? | ||||
Original: | ||||
* The policy of SID range allocations: Public, Private or Both. | ||||
... | ||||
* A Policy of allocation, which clearly identifies if the YANG SID | ||||
Range allocations would be Private, Public or Both. --> | ||||
</t> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>The contact information of the requesting organization includin g: | <t>The contact information of the requesting organization, includi ng the following: | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>Organization name</t> | <t>Organization name.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>URL</t> | <t>URL.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="allocation-policy"> | <section anchor="allocation-policy"> | |||
<name>Allocation policy</name> | <name>Allocation Policy</name> | |||
<t>The IANA policy for future additions to this registry is "Expert Re view" <xref target="RFC8126"/>.</t> | <t>The IANA policy for future additions to this registry is "Expert Re view" <xref target="RFC8126"/>.</t> | |||
<t>An organization requesting to manage a YANG SID Range (and thus hav e an entry in the YANG SID Mega-Range Registry), must ensure the following capac ities:</t> | <t>An organization requesting to manage a YANG SID Range (and thus hav e an entry in the "YANG SID Mega-Range" registry) must ensure the following capa cities:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The capacity to manage and operate a YANG SID Range Registry. A | <t>The capacity to manage and operate a registry of YANG SID range | |||
YANG SID Range Registry <bcp14>MUST</bcp14> provide the following information f | s. A registry of YANG SID ranges <bcp14>MUST</bcp14> provide the following infor | |||
or all YANG SID Ranges allocated by the Registry: | mation for all YANG SID Ranges allocated by the registry: | |||
<!-- [rfced] Section 6.3.2: Because this document currently defines | ||||
an IANA registry called "YANG SID Mega-Range" and this sentence | ||||
appears to make general mention of a registry that would not be | ||||
managed by IANA, we updated this sentence as follows. Please let us | ||||
know any concerns. (For example, could there be future | ||||
non-IANA-managed registries that would share the same names as the | ||||
registries defined by this document?) | ||||
Original: | ||||
* The capacity to manage and operate a YANG SID Range Registry. A | ||||
YANG SID Range Registry MUST provide the following information for | ||||
all YANG SID Ranges allocated by the Registry: | ||||
Currently (please note that in a subsequent question we ask whether | ||||
"YANG SID range(s)s" or "YANG SID Range(s)" should be used | ||||
generally in running text): | ||||
* The capacity to manage and operate a registry of YANG SID ranges. | ||||
A registry of YANG SID ranges MUST provide the following | ||||
information for all YANG SID Ranges allocated by the registry: --> | ||||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>Entry Point of allocated YANG SID Range</t> | <t>The entry point of the allocated YANG SID Range.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Size of allocated YANG SID Range</t> | <t>The size of the allocated YANG SID Range.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Type: Public or Private | <t>Type: Public or Private. | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>Public Ranges <bcp14>MUST</bcp14> include at least a re | <t>Public ranges <bcp14>MUST</bcp14> include at least a re | |||
ference to the YANG module and ".sid" files for that YANG SID Range (e.g., compa | ference to the YANG module and ".sid" files for that YANG SID Range (e.g., compa | |||
re <xref target="publink"/> for the IETF YANG SID registry).</t> | re <xref target="publink"/> for the "IETF YANG SID" registry). | |||
<!-- [rfced] Section 6.3.2: Please clarify the meaning of "compare | ||||
Section 6.4.3 for the IETF YANG SID registry". Does it mean | ||||
"compare with Section 6.4.3" or something else? Also, we find | ||||
"Section 6.4.3 for the IETF YANG SID registry" confusing, because | ||||
Section 6.4 defines and discusses the "IETF YANG SID Range" registry. | ||||
Original: | ||||
o Public Ranges MUST include at least a reference to the YANG | ||||
module and ".sid" files for that YANG SID Range (e.g., | ||||
compare Section 6.4.3 for the IETF YANG SID registry). | ||||
Possibly: | ||||
o Public ranges MUST include at least a reference to the YANG | ||||
module and ".sid" files for that YANG SID Range (e.g., | ||||
see Section 6.4.3 for a comparable scenario as related to the | ||||
"IETF YANG SID Range" registry). --> | ||||
</t> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Private Ranges <bcp14>MUST</bcp14> be marked as "Privat e"</t> | <t>Private ranges <bcp14>MUST</bcp14> be marked as "Privat e".</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>A Policy of allocation, which clearly identifies if the YANG SI D Range allocations would be Private, Public or Both.</t> | <t>A policy of allocation, which clearly identifies whether the YA NG SID Range allocations would be Private, Public, or Both.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Technical capacity to provide or refer to ".sid" files in a way that | <t>Technical capacity to provide or refer to ".sid" files in a way that | |||
meets the security objective of data integrity for these files (see | meets the security objective of data integrity for these files (see | |||
also <xref target="security-considerations"/>).</t> | also <xref target="security-considerations"/>).</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Technical capacity to ensure the sustained operation of the reg | <t>Technical capacity to ensure the sustained operation of the reg | |||
istry for a period of at least 5 years. If Private Registrations are allowed, th | istry for a period of at least 5 years. If Private Registrations are allowed, th | |||
e period must be of at least 10 years.</t> | e period must be at least 10 years. | |||
<!-- [rfced] Section 6.3.2: We could not find the | ||||
initial-capitalized term "Private Registration" or "Private | ||||
Registrations" in any published RFC. The only instance of | ||||
"private registration" that we found is in Section 5 of RFC 2655. | ||||
Would it help to update this sentence as suggested below? | ||||
Original: | ||||
If Private | ||||
Registrations are allowed, the period must be of at least 10 | ||||
years. | ||||
Suggested: | ||||
If registrations in the Private category | ||||
are allowed, the period must be at least 10 years. --> | ||||
</t> | ||||
</li> | </li> | |||
</ul> | </ul> | |||
<t>If a size of the allocation beyond 1 000 000 is desired, the | <t>If a size of the allocation beyond 1 000 000 is desired, the | |||
organization must demonstrate the sustainability of the technical | organization must demonstrate the sustainability of the technical | |||
approach for utilizing this size of allocation and how it does not | approach for utilizing this size of allocation and how it does not | |||
negatively impact the overall usability of the SID allocation | negatively impact the overall usability of the SID allocation | |||
mechanisms; such allocations are preferably placed in the space above | mechanisms; such allocations are preferably placed in the space above | |||
4 295 000 000 (64-bit space).</t> | 4 295 000 000 (64-bit space).</t> | |||
<section anchor="first-allocation"> | <section anchor="first-allocation"> | |||
<name>First allocation</name> | <name>First Allocation</name> | |||
<t>For a first allocation to be provided, the requesting organizatio n must demonstrate a functional registry infrastructure.</t> | <t>For a first allocation to be provided, the requesting organizatio n must demonstrate a functional registry infrastructure.</t> | |||
</section> | </section> | |||
<section anchor="consecutive-allocations"> | <section anchor="consecutive-allocations"> | |||
<name>Consecutive allocations</name> | <name>Consecutive Allocations</name> | |||
<t>On subsequent allocation request(s), the organization must demons | <t>On one or more subsequent allocation requests, the organization m | |||
trate the | ust demonstrate the | |||
exhaustion of the prior range. These conditions need to be asserted by the | exhaustion of the prior range. These conditions need to be asserted by the | |||
assigned expert(s).</t> | assigned expert(s).</t> | |||
<t>If that extra-allocation is done within 3 years from the last all | <t>If such a request for an additional allocation is made within 3 y | |||
ocation, the | ears of the last allocation, the | |||
experts need to discuss this request on the CORE working group mailing list and | experts need to discuss this request on the CORE Working Group mailing list and | |||
consensus needs to be obtained before allocating a new Mega-Range.</t> | consensus needs to be obtained before allocating a new Mega-Range. | |||
<!-- [rfced] Section 6.3.2.2: We could not find the term | ||||
"extra-allocation" in any published RFC. We updated this sentence as | ||||
noted below. If this is incorrect, please clarify the text. | ||||
Original: | ||||
If that extra-allocation is done within 3 years from the last | ||||
allocation, the experts need to discuss this request on the CORE | ||||
working group mailing list and consensus needs to be obtained before | ||||
allocating a new Mega-Range. | ||||
Currently: | ||||
If such a request for an additional allocation is made within 3 years | ||||
of the last allocation, the experts need to discuss this request on | ||||
the CORE Working Group mailing list and consensus needs to be | ||||
obtained before allocating a new Mega-Range. --> | ||||
</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="initial-contents-of-the-registry"> | <section anchor="initial-contents-of-the-registry"> | |||
<name>Initial contents of the Registry</name> | <name>Initial Contents of the Registry</name> | |||
<t>The initial entry in this registry is allocated to IANA:</t> | ||||
<t>This registry contains the following initial entry:</t> | ||||
<!-- [rfced] Tables 1, 5, and 6 have titles, but Tables 2, 3, and 4 | ||||
do not. If you would like all tables to have titles, please provide | ||||
titles for Tables 2, 3, and 4. | ||||
Perhaps: | ||||
Table 2: YANG SID Mega-Range Registry: Initial Assignment | ||||
Table 3: IETF YANG SID Range Registry: Ranges | ||||
Table 4: IETF YANG SID Range Registry: Initial Range Assignments --> | ||||
<table align="left"> | <table align="left"> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Entry Point</th> | <th align="left">Entry Point</th> | |||
<th align="left">Size</th> | <th align="left">Size</th> | |||
<th align="left">Allocation</th> | <th align="left">Allocation</th> | |||
<th align="left">Organization name</th> | <th align="left">Organization Name</th> | |||
<th align="left">URL</th> | <th align="left">URL</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">0</td> | <td align="left">0</td> | |||
<td align="left">1000000</td> | <td align="left">1000000</td> | |||
<td align="left">Public</td> | <td align="left">Public</td> | |||
<td align="left">IANA</td> | <td align="left">IANA</td> | |||
<td align="left">https://iana.org</td> | <td align="left"><eref brackets="angle" target="https://www.iana .org/"/></td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ietf-iana-sid-range-allocation"> | <section anchor="ietf-iana-sid-range-allocation"> | |||
<name>Create a new IANA Registry: IETF YANG SID Range Registry (managed | <name>New IANA Registry: IETF YANG SID Range</name> | |||
by IANA)</name> | ||||
<!-- [rfced] Section 6.4: Sections 6.3 and 6.5 have brief | ||||
introductory paragraphs listing the name of the new registry. | ||||
Would you like this section to do the same? | ||||
Original: | ||||
6.4. Create a new IANA Registry: IETF YANG SID Range Registry (managed | ||||
by IANA) | ||||
6.4.1. Structure | ||||
Possibly: | ||||
6.4. New IANA Registry: IETF YANG SID Range | ||||
The name of this registry is "IETF YANG SID Range". This | ||||
registry is used to record information related to a new SID | ||||
range (e.g., entry point and size). | ||||
6.4.1. Structure --> | ||||
<section anchor="ietf-iana-sid-range-structure"> | <section anchor="ietf-iana-sid-range-structure"> | |||
<name>Structure</name> | <name>Structure</name> | |||
<t>Each entry in this registry must include:</t> | <t>Each entry in this registry must include:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The SID range entry point.</t> | <t>The SID range entry point.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The SID range size.</t> | <t>The SID range size.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The YANG module name.</t> | <t>The YANG module name.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Document reference.</t> | <t>A document reference (the document making the registration).</t > | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="ietf-iana-sid-range-allocation-policy"> | <section anchor="ietf-iana-sid-range-allocation-policy"> | |||
<name>Allocation policy</name> | <name>Allocation Policy</name> | |||
<t>The first million SIDs assigned to IANA is subdivided as follows:</ | <t>The first million SIDs assigned to IANA is subdivided as follows: | |||
t> | ||||
<!-- [rfced] Section 6.4.2: This sentence has a subject-verb | ||||
disagreement as written. If neither suggestion below is correct, | ||||
please resolve the text. | ||||
Original: | ||||
The first million SIDs assigned to IANA is subdivided as follows: | ||||
Suggestion #1 (SIDs are): | ||||
The first million SIDs assigned to IANA are subdivided as follows: | ||||
Suggestion #2 (group is): | ||||
The first group of one million SIDs assigned to IANA is subdivided | ||||
as follows: --> | ||||
</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The range of 0 to 999 (size 1000) is subject to "IESG Approval" as defined in <xref target="RFC8126"/>; of these, SID value 0 has been reserved for implementations to internally signify the absence of a SID number and does not occur in interchange.</t> | <t>The range of 0 to 999 (size 1000) is subject to "IESG Approval" as defined in <xref target="RFC8126"/>; of these, SID value 0 has been reserved for implementations to internally signify the absence of a SID number and does not occur in interchange.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The ranges of 1000 to 59,999 (size 59,000) and 100,000 to 299,9 99 (size 200,000) are designated for YANG modules defined in RFCs. | <t>The ranges of 1000 to 59,999 (size 59,000) and 100,000 to 299,9 99 (size 200,000) are designated for YANG modules defined in RFCs. | |||
</t> | </t> | |||
<!-- [rfced] For the "IETF YANG SID Range" registry, IANA has listed the followi | ||||
ng registration procedures: | ||||
0 1000 IESG Approval | ||||
1000 59000 RFC Required | ||||
60000 40000 Reserved for Experimental/Private Use | ||||
100000 200000 RFC Required | ||||
300000 700000 Reserved | ||||
Section 6.4.2 indicates that the entry point 60000 is reserved for Experimental | ||||
Use. | ||||
Original: | ||||
* The range of 60,000 to 99,999 (size 40,000) is reserved for | ||||
experimental YANG modules. This range MUST NOT be used in | ||||
operational deployments since these SIDs are not globally unique | ||||
which limit their interoperability. The IANA policy for this | ||||
range is "Experimental use" [RFC8126]. | ||||
Should Private Use also be listed to align with what appears in the IANA registr | ||||
y and table 3? | ||||
--> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The IANA policy for additions to this registry is either: | <t>The IANA policy for additions to this registry is: | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>"Expert Review" <xref target="RFC8126"/> in case the ". sid" file comes from a YANG module from an existing RFC, or</t> | <t>"Expert Review" <xref target="RFC8126"/> if the ".sid" file comes from a YANG module from an existing RFC.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>"RFC Required" <xref target="RFC8126"/> otherwise.</t> | <t>"RFC Required" <xref target="RFC8126"/> otherwise.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The Expert <bcp14>MUST</bcp14> verify that the YANG module for which this allocation is made has an RFC (existing RFC) OR is on track to be come RFC (early allocation with a request from the WG chairs as defined by <xref target="BCP100"/>).</t> | <t>The expert <bcp14>MUST</bcp14> verify that the YANG module for which this allocation is made has an RFC (existing RFC) OR is on track to be come an RFC (early allocation with a request from the working group chairs as de fined by <xref target="BCP100"/>).</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The range of 60,000 to 99,999 (size 40,000) is reserved for exp | <t>The range of 60,000 to 99,999 (size 40,000) is reserved for exp | |||
erimental YANG modules. This range <bcp14>MUST NOT</bcp14> be used in operationa | erimental YANG modules. This range <bcp14>MUST NOT</bcp14> be used in operationa | |||
l deployments since these SIDs are not globally unique which limit their interop | l deployments, since these SIDs are not globally unique which limit their intero | |||
erability. The IANA policy for this range is "Experimental use" <xref target="RF | perability. The IANA policy for this range is "Experimental Use" <xref target="R | |||
C8126"/>.</t> | FC8126"/>. | |||
<!-- [rfced] Section 6.4.2: To what does "which limit" refer in this | ||||
sentence? If the suggested text is not correct, please provide | ||||
clarifying text. | ||||
Original: | ||||
This range MUST NOT be used in | ||||
operational deployments since these SIDs are not globally unique | ||||
which limit their interoperability. | ||||
Suggested: | ||||
This range MUST NOT be used in | ||||
operational deployments, since these SIDs are not globally unique | ||||
and their interoperability is therefore limited. --> | ||||
</t> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>The range of 300,000 to 999,999 (size 900,000) is "Reserved" as | <t>The range of 300,000 to 999,999 (size 700,000) is "Reserved" as | |||
defined in <xref target="RFC8126"/>.</t> | defined in <xref target="RFC8126"/>. | |||
<!-- [rfced] Section 6.4.2: We changed "(size 900,000)" to | ||||
"(size 700,000)" per Table 3. Please let us know any concerns. | ||||
Original: | ||||
* The range of 300,000 to 999,999 (size 900,000) is "Reserved" as | ||||
defined in [RFC8126]. | ||||
Currently: | ||||
* The range of 300,000 to 999,999 (size 700,000) is "Reserved" as | ||||
defined in [RFC8126]. --> | ||||
</t> | ||||
</li> | </li> | |||
</ul> | </ul> | |||
<table align="left"> | <table align="left"> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Entry Point</th> | <th align="left">Entry Point</th> | |||
<th align="left">Size</th> | <th align="left">Size</th> | |||
<th align="left">IANA policy</th> | <th align="left">IANA Policy</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">0</td> | <td align="left">0</td> | |||
<td align="left">1,000</td> | <td align="left">1,000</td> | |||
<td align="left">IESG Approval</td> | <td align="left">IESG Approval</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">1,000</td> | <td align="left">1,000</td> | |||
<td align="left">59,000</td> | <td align="left">59,000</td> | |||
<td align="left">RFC Required</td> | <td align="left">RFC Required</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">60,000</td> | <td align="left">60,000</td> | |||
<td align="left">40,000</td> | <td align="left">40,000</td> | |||
<td align="left">Experimental/Private use</td> | <td align="left">Experimental/Private Use</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">100,000</td> | <td align="left">100,000</td> | |||
<td align="left">200,000</td> | <td align="left">200,000</td> | |||
<td align="left">RFC Required</td> | <td align="left">RFC Required</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">300,000</td> | <td align="left">300,000</td> | |||
<td align="left">700,000</td> | <td align="left">700,000</td> | |||
<td align="left">Reserved</td> | <td align="left">Reserved</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>The size of the SID range allocated for a YANG module is recommende | ||||
d to be a multiple of 50 and to be at least 33% above the current number of YANG | <!-- [rfced] Section 6.4.2: The information under the second bullet | |||
items. This headroom allows assignment within the same range of new YANG items | item does not seem to match what is shown in Table 3. Please let us | |||
introduced by subsequent revisions. The SID range size <bcp14>SHOULD NOT</bcp14> | know if any updates to the table are needed. For example, should the | |||
exceed 1000; a larger size may be requested by the authors if this recommendati | "1,000" and "100,000" rows list "Expert Review or RFC Required" | |||
on is considered insufficient. It is important to note that an additional SID ra | instead of just "RFC Required"? | |||
nge can be allocated to an existing YANG module if the initial range is exhauste | ||||
d; this then just leads to slightly less efficient representation.</t> | Original (dashes are broken in order to avoid xml2rfc's | |||
<t>In case a SID range is allocated for an existing RFC through the "E | "Double hyphen within comment" error): | |||
xpert | * The ranges of 1000 to 59,999 (size 59,000) and 100,000 to 299,999 | |||
Review" policy, the Document reference field for the given allocation should | (size 200,000) are designated for YANG modules defined in RFCs. | |||
- The IANA policy for additions to this registry is either: | ||||
o "Expert Review" [RFC8126] in case the ".sid" file comes from | ||||
a YANG module from an existing RFC, or | ||||
o "RFC Required" [RFC8126] otherwise. | ||||
... | ||||
+=============+=========+==========================+ | ||||
| Entry Point | Size | IANA policy | | ||||
+=============+=========+==========================+ | ||||
| 0 | 1,000 | IESG Approval | | ||||
+- - - - - - -+- - - - -+- - - - - - - - - - - - - + | ||||
| 1,000 | 59,000 | RFC Required | | ||||
+- - - - - - -+- - - - -+- - - - - - - - - - - - - + | ||||
| 60,000 | 40,000 | Experimental/Private use | | ||||
+- - - - - - -+- - - - -+- - - - - - - - - - - - - + | ||||
| 100,000 | 200,000 | RFC Required | | ||||
+- - - - - - -+- - - - -+- - - - - - - - - - - - - + | ||||
| 300,000 | 700,000 | Reserved | | ||||
+- - - - - - -+- - - - -+- - - - - - - - - - - - - + --> | ||||
<t>The size of the SID range allocated for a YANG module is recommende | ||||
d to be a multiple of 50 and to be at least 33% above the current number of YANG | ||||
items. This headroom allows assignments within the same range of new YANG items | ||||
introduced by subsequent revisions. The SID range size <bcp14>SHOULD NOT</bcp14 | ||||
> exceed 1000; a larger size may be requested by the authors if this recommendat | ||||
ion is considered insufficient. It is important to note that an additional SID r | ||||
ange can be allocated to an existing YANG module if the initial range is exhaust | ||||
ed; this then just leads to a slightly less efficient representation.</t> | ||||
<t>If a SID range is allocated for an existing RFC through the "Expert | ||||
Review" policy, the Reference field for the given allocation should | ||||
point to the RFC that the YANG module is defined in.</t> | point to the RFC that the YANG module is defined in.</t> | |||
<t>In case a SID range is required before publishing the RFC due to | <!-- [rfced] Note that we have changed references to sections within BCP 100 to | |||
refer to the section within the relevant RFC. | ||||
Original: | ||||
In case a SID range is required before publishing the RFC due to | ||||
implementations needing stable SID values, early allocation as | ||||
defined in [BCP100] can be employed for the "RFC Required" range | ||||
(Section 2 of [BCP100]). | ||||
Current | ||||
If a SID range is required before publishing the RFC due to | ||||
implementations needing stable SID values, early allocation as | ||||
defined in [BCP100] can be employed for the "RFC Required" range | ||||
(Section 2 of RFC 7120 [BCP100]). | ||||
Original: | ||||
| - RFC7120 (BCP100), Section 3.3 | ||||
| https://www.rfc-editor.org/rfc/rfc7120.html#section-3.3 | ||||
Currently (moved to appear just prior to the quote): | ||||
Section 3.3 of RFC 7120 [BCP100] also says: | ||||
--> | ||||
<t>If a SID range is required before publishing the RFC due to | ||||
implementations needing stable SID values, early allocation as defined in | implementations needing stable SID values, early allocation as defined in | |||
<xref target="BCP100"/> can be employed for the "RFC Required" range (<xref sect ion="2" sectionFormat="of" target="BCP100"/>).</t> | <xref target="BCP100"/> can be employed for the "RFC Required" range (Section <x ref target="RFC7120" sectionFormat="bare" section="2"/> of RFC 7120 <xref target ="BCP100"/>).</t> | |||
</section> | </section> | |||
<section anchor="publink"> | <section anchor="publink"> | |||
<name>Publication of the ".sid" file</name> | <name>Publication of the ".sid" File</name> | |||
<t>During publication of an RFC, IANA contacts the designated expert t | <!-- [rfced] Does "approved draft" refer to the I-D that is approved for publica | |||
eam | tion as an RFC, or perhaps a draft of the edited AUTH48 file, or other? | |||
From Section 6.4.3 | ||||
Original: | ||||
For a type-2 (SID-aware) | ||||
developer, the team first obtains the existing draft SID file from a | ||||
stable reference in the approved draft; for a type-1 (SID-guiding) | ||||
developer, the team extracts the SID file from the approved draft. | ||||
Original: | ||||
Such RFCs cannot be produced by | ||||
type-3 (SID-oblivious) developers: the SIDs used in the text need to | ||||
be assigned in the existing draft SID file, and the designated expert | ||||
team needs to check that the assignments in the final SID file are | ||||
consistent with the usage in the RFC text or that the approved draft | ||||
test is changed appropriately. | ||||
--> | ||||
<t>During an RFC's publication process, IANA contacts the designated e | ||||
xpert team | ||||
("the team"), who are responsible for delivering a final SID file for | ("the team"), who are responsible for delivering a final SID file for | |||
each module defined by the RFC. | each module defined by the RFC. | |||
For a type-3 developer (SID-oblivious, see <xref target="parties-roles"/>), the | For a type-3 developer (SID-oblivious; see <xref target="parties-roles"/>), the | |||
team | team | |||
creates a new SID file from each YANG module, see below. | creates a new SID file from each YANG module; see below. | |||
For a type-2 (SID-aware) developer, the team first obtains the existing draft SI D | For a type-2 (SID-aware) developer, the team first obtains the existing draft SI D | |||
file from a stable reference in the approved draft; for a type-1 (SID-guiding) | file from a stable reference in the approved draft; for a type-1 (SID-guiding) | |||
developer, the team extracts the SID file from the approved draft.</t> | developer, the team extracts the SID file from the approved draft.</t> | |||
<!-- [rfced] Please remind us of the implications for publishing - is it correct | ||||
that a) the RPC should coordinate with IANA when AUTH48 is complete, so the tea | ||||
m can generate the final SID file from the most current YANG module, and b) IANA | ||||
will then provide the RPC with the link to the SID file to be included in the R | ||||
FC? | ||||
Based on the text in this document, we expect that a final link will not appear | ||||
in this RFC. We believe the example SID file in this document is final and does | ||||
not need to be rechecked by the team. Please confirm that this is correct. | ||||
--> | ||||
<t>The team uses a tool to generate a final SID file from each YANG | <t>The team uses a tool to generate a final SID file from each YANG | |||
module; the final SID file has all SID assignments set to "stable" and | module; the final SID file has all SID assignments set to "stable" and | |||
the SID file status set to "published". | the SID file status set to "published". | |||
A published ".sid" file <bcp14>MUST NOT</bcp14> contain SID assignments with an | A published ".sid" file <bcp14>MUST NOT</bcp14> contain SID assignments with a | |||
unstable status.</t> | status of "unstable". | |||
<!-- [rfced] Section 6.4.3: As it appears that 'an unstable status' | ||||
means 'a status of "unstable"', we updated this sentence accordingly. | ||||
If this is incorrect, please clarify "an unstable status" (e.g., does | ||||
it refer to more than one type of status?). | ||||
Original: | ||||
A published ".sid" file | ||||
MUST NOT contain SID assignments with an unstable status. | ||||
Currently: | ||||
A published ".sid" file | ||||
MUST NOT contain SID assignments with a status of "unstable". --> | ||||
</t> | ||||
<t>For the cases other than type-3 (SID-oblivious), the team feeds the existing draft SID | <t>For the cases other than type-3 (SID-oblivious), the team feeds the existing draft SID | |||
file as an input ("reference SID file") to the tool so that the changes resultin g from | file as an input ("reference SID file") to the tool so that the changes resultin g from | |||
re-generation are minimal. | regeneration are minimal. | |||
For YANG modules that are revisions of previously published modules, | For YANG modules that are revisions of previously published modules, | |||
any existing published SID file needs to serve as reference SID file | any existing published SID file needs to serve as a reference SID file | |||
for the tool, either during generation of the revised draft (type-1, | for the tool, during generation of either the revised draft SID file (type-1, | |||
type-2) or during generation of the final SID file (type-3).</t> | type-2) or the final SID file (type-3).</t> | |||
<t>In any case, the team checks the generated file, including for | <t>In any case, the team checks the generated file, including checking | |||
for | ||||
validity as a SID file, for consistency with the SID range | validity as a SID file, for consistency with the SID range | |||
allocations, for full coverage of the YANG items in YANG module, and | allocations, for full coverage of the YANG items in the YANG module, and | |||
for the best achievable consistency with the existing draft SID file.</t> | for the best achievable consistency with the existing draft SID file.</t> | |||
<t>The designated experts then give the SID file to IANA to publish in | <t>The designated experts then give the SID file to IANA to publish in | |||
to | the "IETF YANG SID" registry (<xref target="ietf-sid-registry"/>) along with the | |||
the YANG SID Registry (<xref target="ietf-sid-registry"/>) along with the YANG | YANG | |||
module.</t> | module.</t> | |||
<!-- [rfced] If the intention is to include a note in the body of the text to al | ||||
ert the RFC Editor that coordination/action is required, perhaps this could be u | ||||
pdated as follows: | ||||
Original: | ||||
RFCs that need | ||||
SIDs assigned to their new modules for use in the text of the | ||||
document, e.g., for examples, need to alert the RFC editor in the | ||||
draft text that this is the case. | ||||
Perhaps: | ||||
Drafts that need | ||||
SIDs assigned to their new modules for use in the text of the | ||||
RFC, e.g., for examples, need to include text in the draft to alert the RFC E | ||||
ditor that this is the case. | ||||
--> | ||||
<t>The ".sid" file <bcp14>MUST NOT</bcp14> be published as part of the RFC: the IANA | <t>The ".sid" file <bcp14>MUST NOT</bcp14> be published as part of the RFC: the IANA | |||
Registry is authoritative and a link to it is to be inserted in the RFC. | registry is authoritative, and a link to it is to be inserted in the RFC. | |||
(Note that the present RFC is an exception to this rule as the SID | (Note that the present RFC is an exception to this rule, as the SID | |||
file also serves as an example for exposition.) | file also serves as an example for exposition.) | |||
RFCs that need SIDs assigned to their new modules for use in the text | RFCs that need SIDs assigned to their new modules for use in the text | |||
of the document, e.g., for examples, need to alert the RFC editor in | of the document, e.g., for examples, need to alert the RFC Editor in | |||
the draft text that this is the case. | the draft text that this is the case. | |||
Such RFCs cannot be produced by type-3 (SID-oblivious) developers: | Such RFCs cannot be produced by type-3 (SID-oblivious) developers: | |||
the SIDs used in the text need to be assigned in the existing draft | the SIDs used in the text need to be assigned in the existing draft | |||
SID file, and the designated expert team needs to check that the | SID file, and the designated expert team needs to check that the | |||
assignments in the final SID file are consistent with the usage in the | assignments in the final SID file are consistent with the usage in the | |||
RFC text or that the approved draft test is changed appropriately.</t> | RFC text or that the approved draft text is changed appropriately.</t> | |||
</section> | </section> | |||
<section anchor="ietf-iana-sid-range-initial-contents"> | <section anchor="ietf-iana-sid-range-initial-contents"> | |||
<name>Initial contents of the registry</name> | <name>Initial Contents of the Registry</name> | |||
<t>Initial entries in this registry are as follows:</t> | <t>Initial entries in this registry are as follows:</t> | |||
<table align="left"> | <table align="left"> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="right">Entry Point</th> | <th align="right">Entry Point</th> | |||
<th align="right">Size</th> | <th align="right">Size</th> | |||
<th align="left">Module name</th> | <th align="left">Module Name</th> | |||
<th align="left">Document reference</th> | <th align="left">Reference</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="right">0</td> | <td align="right">0</td> | |||
<td align="right">1</td> | <td align="right">1</td> | |||
<td align="left">(Reserved: not a valid SID)</td> | <td align="left">(Reserved: not a valid SID)</td> | |||
<td align="left">RFCXXXX</td> | <td align="left">RFC 9595</td> | |||
</tr> | </tr> | |||
<!-- [rfced] Should this RFC be listed as a reference for the ietf-coreconf regi | ||||
stration, especially as the entry point is from the RFC Required range and draft | ||||
-ietf-core-comi has not yet been approved for publication (WG state is WG Docume | ||||
nt and the IESG state is I-D Exists)? | ||||
Table 4: | ||||
| 1000 | 100| ietf- | [I-D.ietf-core-comi] | | ||||
| | | coreconf | | | ||||
Note that "ietf-voucher" does not appear in the "IETF YANG SID Range" registry. | ||||
Please verify that the following should be registered. As needed, we will requ | ||||
est an update from IANA. | ||||
Original: | ||||
| 2400 | 50| ietf-voucher | [RFC8366] | | ||||
Also, we do not see "ietf-constrained-voucher" or "ietf-constrained-voucher-requ | ||||
est" in | ||||
draft-ietf-anima-constrained-voucher. However, we see "ietf-voucher" and | ||||
"ietf-voucher-request" in draft-ietf-anima-constrained-voucher, and we see "ietf | ||||
-voucher" | ||||
defined in RFC 8366. Please review. | ||||
In addition, should this RFC be listed as a reference for ietf-constrained-vouch | ||||
er and ietf-constrained-voucher-request, since the referenced document is draft- | ||||
ietf-anima-constrained-voucher, and we think the values are in the RFC Required | ||||
range? | ||||
+- - - -+- - +- - - - - - - +- - - - - - - - - - - - - - - - - - - + | ||||
| 2450 | 50| ietf- | [I-D.ietf-anima-constrained-voucher] | | ||||
| | | constrained- | | | ||||
| | | voucher | | | ||||
+- - - -+- - +- - - - - - - +- - - - - - - - - - - - - - - - - - - + | ||||
| 2500 | 50| ietf- | [I-D.ietf-anima-constrained-voucher] | | ||||
| | | constrained- | | | ||||
| | | voucher- | | | ||||
| | | request | | | ||||
--> | ||||
<tr> | <tr> | |||
<td align="right">1000</td> | <td align="right">1000</td> | |||
<td align="right">100</td> | <td align="right">100</td> | |||
<td align="left">ietf-coreconf</td> | <td align="left">ietf-coreconf</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="I-D.ietf-core-comi"/></td> | <xref target="CORE-COMI"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">1100</td> | <td align="right">1100</td> | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-yang-types</td> | <td align="left">ietf-yang-types</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="RFC6991"/></td> | <xref target="RFC6991"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">1150</td> | <td align="right">1150</td> | |||
skipping to change at line 1283 ¶ | skipping to change at line 2208 ¶ | |||
<td align="right">1250</td> | <td align="right">1250</td> | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-netconf-acm</td> | <td align="left">ietf-netconf-acm</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="RFC8341"/></td> | <xref target="RFC8341"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">1300</td> | <td align="right">1300</td> | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-sid-file</td> | <td align="left">ietf-sid-file</td> | |||
<td align="left">RFCXXXX</td> | <td align="left">RFC 9595</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">1500</td> | <td align="right">1500</td> | |||
<td align="right">100</td> | <td align="right">100</td> | |||
<td align="left">ietf-interfaces</td> | <td align="left">ietf-interfaces</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="RFC8343"/></td> | <xref target="RFC8343"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">1600</td> | <td align="right">1600</td> | |||
skipping to change at line 1325 ¶ | skipping to change at line 2250 ¶ | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-voucher</td> | <td align="left">ietf-voucher</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="RFC8366"/></td> | <xref target="RFC8366"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">2450</td> | <td align="right">2450</td> | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-constrained-voucher</td> | <td align="left">ietf-constrained-voucher</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="I-D.ietf-anima-constrained-voucher"/></td> | <xref target="CONSTRAINED-VOUCHER"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="right">2500</td> | <td align="right">2500</td> | |||
<td align="right">50</td> | <td align="right">50</td> | |||
<td align="left">ietf-constrained-voucher-request</td> | <td align="left">ietf-constrained-voucher-request</td> | |||
<td align="left"> | <td align="left"> | |||
<xref target="I-D.ietf-anima-constrained-voucher"/></td> | <xref target="CONSTRAINED-VOUCHER"/></td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>// RFC Ed.: replace XXXX with RFC number assigned to this draft.</t | ||||
> | <!-- [rfced] This sentence is a bit misleading, as RFC 8126 does not mention YAN | |||
<t>For allocation, RFC publication of the YANG module is required as p | G. Is another reference intended, or is RFC 8126 referred to because of "RFC Pu | |||
er <xref target="RFC8126"/>. The YANG module must be registered in the "YANG mod | blication", and should the text instead refer to "RFC Required"? | |||
ule Name" registry according to the rules specified in <xref section="14" sectio | ||||
nFormat="of" target="RFC6020"/>.</t> | Original: | |||
For allocation, RFC publication of the YANG module is required as per | ||||
[RFC8126]. | ||||
--> | ||||
<t>For allocation, RFC publication of the YANG module is required as p | ||||
er <xref target="RFC8126"/>. The YANG module must be registered in the "YANG Mod | ||||
ule Names" registry according to the rules specified in <xref section="14" secti | ||||
onFormat="of" target="RFC6020"/>.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ietf-sid-registry"> | <section anchor="ietf-sid-registry"> | |||
<name>Create new IANA Registry: "IETF YANG SID Registry"</name> | <name>New IANA Registry: IETF YANG SID</name> | |||
<t>The name of this registry is "IETF YANG SID Registry". This registry | <t>The name of this registry is "IETF YANG SID". This registry is used | |||
is used to | to | |||
record the allocation of SIDs for individual YANG module items.</t> | record the allocation of SIDs for individual YANG module items.</t> | |||
<section anchor="structure-1"> | <section anchor="structure-1"> | |||
<name>Structure</name> | <name>Structure</name> | |||
<t>Each entry in this registry must include:</t> | <t>Each entry in this registry must include:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The YANG module name. This module name must be present in the " Name" column of the "YANG Module Names" registry.</t> | <t>The YANG module name. This module name must be present in the " Name" column of the "YANG Module Names" registry.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>A URI for the associated ".yang" file. This file link must be present in the "File" column of the "YANG Module Names" registry.</t> | <t>A URI for the associated ".yang" file. This file link must be present in the "File" column of the "YANG Module Names" registry.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The URI for the ".sid" file which defines the allocation. The " .sid" file is stored by IANA.</t> | <t>The URI for the ".sid" file that defines the allocation. The ". sid" file is stored by IANA.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The number of actually allocated SIDs in the ".sid" file.</t> | <t>The number of actually allocated SIDs in the ".sid" file.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="allocation-policy-1"> | <section anchor="allocation-policy-1"> | |||
<name>Allocation policy</name> | <name>Allocation Policy</name> | |||
<t>The allocation policy is Expert review. The Expert <bcp14>MUST</bcp | <t>The allocation policy is "Expert Review" <xref target="RFC8126"/>. | |||
14> ensure that the following conditions are met:</t> | The expert <bcp14>MUST</bcp14> ensure that the following conditions are met:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The ".sid" file has a valid structure: | <t>The ".sid" file has a valid structure: | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The ".sid" file <bcp14>MUST</bcp14> be a valid JSON file fo llowing the structure of the | <t>The ".sid" file <bcp14>MUST</bcp14> be a valid JSON file fo llowing the structure of the | |||
module defined in RFCXXXX (RFC Ed: replace XXX with RFC number assigned | module defined in this document.</t> | |||
to this draft).</t> | ||||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The ".sid" file allocates individual SIDs ONLY in the YANG SID Ranges for this | <t>The ".sid" file allocates individual SIDs ONLY in the YANG SID Ranges for this | |||
YANG module (as allocated in the IETF YANG SID Range Registry): | YANG module (as allocated in the "IETF YANG SID Range" registry): | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>All SIDs in this ".sid" file <bcp14>MUST</bcp14> be within the ranges allocated to this | <t>All SIDs in this ".sid" file <bcp14>MUST</bcp14> be within the ranges allocated to this | |||
YANG module in the "IETF YANG SID Range Registry".</t> | YANG module in the "IETF YANG SID Range" registry.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If another ".sid" file has already allocated SIDs for this YANG module (e.g. | <t>If another ".sid" file has already allocated SIDs for this YANG module (e.g., | |||
for older or newer versions of the YANG module), the YANG items are assigned | for older or newer versions of the YANG module), the YANG items are assigned | |||
the same SIDs as in the other ".sid" file.</t> | the same SIDs as those in the other ".sid" file.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If there is an older version of the ".sid" file, all allocated SIDs from that | <t>If there is an older version of the ".sid" file, all allocated SIDs from that | |||
version are still present in the current version of the ".sid" file.</t> | version are still present in the current version of the ".sid" file.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<!-- [rfced] Please confirm that "YANG SID Range" is correct in the title for Se | ||||
ction 6.5.3: | ||||
6.5.3. Recursive Allocation of YANG SID Range at Document Adoption | ||||
Section 6.5 is about the IETF YANG SID registry. | ||||
--> | ||||
<section anchor="recursive-allocation-at-adoption"> | <section anchor="recursive-allocation-at-adoption"> | |||
<name>Recursive Allocation of YANG SID Range at Document Adoption</nam e> | <name>Recursive Allocation of YANG SID Range at Document Adoption</nam e> | |||
<t>Due to the difficulty in changing SID values during IETF document p rocessing, | <t>Due to the difficulty in changing SID values during IETF document p rocessing, | |||
it is expected that most documents will ask for SID range allocations using Earl | it is expected that most documents will ask for SID range allocations using earl | |||
y | y | |||
Allocations <xref target="BCP100"/>. The details of the Early Allocation to be | allocations <xref target="BCP100"/>. The details of the early allocation to be | |||
requested, including the timeline envisioned, should be included | requested, including the timeline envisioned, should be included | |||
in any Working Group Adoption call. Prior to Working Group Adoption, an internet | in any working group adoption call. Prior to working group adoption, an | |||
draft author can use the experimental SID range (as per | Internet-Draft author can use the experimental SID range (as per | |||
<xref target="ietf-iana-sid-range-allocation-policy"/>) for their SIDs allocatio | <xref target="ietf-iana-sid-range-allocation-policy"/>) for their SID allocation | |||
ns or | s or | |||
other values that do not create ambiguity with other SID uses (for example | 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 "YANG SID Mega-Range" | they can use a range that comes from a non-IANA-managed registry of YANG SID meg | |||
registry).</t> | a-ranges). | |||
<t>After Working Group Adoption, any modification of a ".sid" file is | ||||
expected to be | <!-- [rfced] Section 6.5.3: Because this document currently defines | |||
discussed on the mailing list of the appropriate Working Groups. Specific | an IANA registry called "YANG SID Mega-Range" and this sentence makes | |||
attention should be paid to implementers' opinion after Working Group Last Call | general mention of a registry that would not be managed by IANA, we | |||
updated this sentence as follows. Please let us know any concerns. | ||||
(For example, could there be future non-IANA-managed registries that | ||||
would share the same names as the registries defined by this document?) | ||||
Original: | ||||
Prior to | ||||
Working Group Adoption, an internet draft author can use the | ||||
experimental SID range (as per Section 6.4.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 "YANG SID Mega-Range" registry). | ||||
Currently: | ||||
Prior to | ||||
working group adoption, an Internet-Draft author can use the | ||||
experimental SID range (as per Section 6.4.2) for their SID | ||||
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 registry of YANG SID mega-ranges). --> | ||||
</t> | ||||
<t>After working group adoption, any modification of a ".sid" file is | ||||
expected to be | ||||
discussed on the mailing lists of the appropriate working groups. Specific | ||||
attention should be paid to implementers' opinions after Working Group Last Call | ||||
if a SID value is to change its meaning. In all cases, a ".sid" file and the SID s | if a SID value is to change its meaning. In all cases, a ".sid" file and the SID s | |||
associated with it are subject to change before the publication of an internet | associated with it are subject to change before the publication of an | |||
draft as an RFC.</t> | Internet-Draft as an RFC.</t> | |||
<t>During the early use of SIDs, many existing, previously published Y ANG modules | <t>During the early use of SIDs, many existing, previously published Y ANG modules | |||
will not have SID allocations. For an allocation to be useful the included | will not have SID allocations. For an allocation to be useful, the included | |||
YANG modules may also need to have SID allocations made, in a process | YANG modules may also need to have SID allocations made, in a process | |||
that will generally analogous to that in <xref target="publink"/> for the type-3 | that will generally be analogous to that in <xref target="publink"/> for the typ | |||
(SID-oblivious) case.</t> | e-3 (SID-oblivious) case.</t> | |||
<t>The Expert Reviewer who performs the (Early) Allocation analysis wi | <t>The expert reviewer who performs the (early) allocation analysis wi | |||
ll need to | ll need to | |||
go through the list of included YANG modules and perform SID allocations for | go through the list of included YANG modules and perform SID allocations for | |||
those modules as well.</t> | those modules as well.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>If the document is a published RFC, then the allocation of SIDs for its | <t>If the document is a published RFC, then the allocation of SIDs for its | |||
referenced YANG modules is permanent. The Expert Reviewer provides the | referenced YANG modules is permanent. The expert reviewer provides the | |||
generated ".sid" file to IANA for registration.</t> | generated ".sid" file to IANA for registration.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If the document is an unprocessed Internet-Draft adopted in a W | <!-- [rfced] In the following, is "for this document as well" needed? | |||
G, then an | ||||
Early Allocation is performed for this document as well. Early Allocations | Original: | |||
require approval by an IESG Area Director. An early allocation which | * If the document is an unprocessed Internet-Draft adopted in a WG, | |||
then an Early Allocation is performed for this document as well. | ||||
--> | ||||
<t>If the document is an unprocessed Internet-Draft adopted in a w | ||||
orking group, then an | ||||
early allocation is performed for this document as well. Early allocations | ||||
require approval by an IESG area director. An early allocation that | ||||
requires additional allocations will list the other allocations in its | requires additional allocations will list the other allocations in its | |||
description, and will be cross-posted to the mailing lists of any | description and will be cross-posted to the mailing lists of any | |||
other working groups concerned.</t> | other working groups concerned.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>A YANG module which references a module in a document which has | <t>A YANG module that references a module in a document that has n | |||
not yet been | ot yet been | |||
adopted by any working group will be unable to perform an Early Allocation | 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 | for that other document until it is adopted by a working group. As described | |||
in <xref target="BCP100"/>, an AD Sponsored document acts as if it had a working | in <xref target="BCP100"/>, an AD-sponsored document acts as if it had a working | |||
group. The | group. The | |||
approving AD may also exempt a document from this policy by agreeing to AD | approving AD may also exempt a document from this policy by agreeing to AD-spons | |||
Sponsor the document.</t> | or the document. | |||
<!-- [rfced] Section 6.5.3: We do not see the word "sponsor" in | ||||
[BCP100], and it appears that sponsoring and approving are two | ||||
distinct activities. Perhaps "Shepherding Area Director" is meant? Please revi | ||||
ew. | ||||
Original: | ||||
As described in [BCP100], 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. --> | ||||
</t> | ||||
</li> | </li> | |||
</ul> | </ul> | |||
<t>At the end of the IETF process all the dependencies of a given modu | <t>At the end of the IETF process, all the dependencies of a given mod | |||
le for which | ule for which | |||
SIDs are assigned, should also have SIDs assigned. Those dependencies' | SIDs are assigned should also have SIDs assigned. Those dependencies' | |||
assignments should be permanent (not Early Allocation).</t> | assignments should be permanent (not early allocation).</t> | |||
<t>A previously SID-allocated YANG module which changes its references | <t>A previously SID-allocated YANG module that changes its references | |||
to include | to include | |||
a YANG module for which there is no SID allocation needs to repeat the Early | a YANG module for which there is no SID allocation needs to repeat the early | |||
Allocation process.</t> | allocation process.</t> | |||
<t><xref target="BCP100"/> defines a time limit for the validity of Ea | <t><xref target="BCP100"/> defines a time limit for the validity of ea | |||
rly Allocations, | rly allocations, | |||
after which they expire unless they are renewed. <xref target="BCP100"/> also s | after which they expire unless they are renewed. Section <xref target="RFC7120" | |||
ays:</t> | sectionFormat="bare" section="3.3"/> of RFC 7120 <xref target="BCP100"/> also s | |||
<blockquote cite="https://www.rfc-editor.org/rfc/rfc7120.html#section- | ays:</t> | |||
3.3" quotedFrom="RFC7120 (BCP100), Section 3.3"> | ||||
<t>Note that if a document is submitted for review to the IESG and a | <!-- DNE; fixed and FYI-AQed --> | |||
t | <blockquote> | |||
the time of submission some early allocations are valid (not | <t>Note that if a document is submitted for review to the IESG, and | |||
expired), these allocations should not be expired while the document | at | |||
is under IESG consideration or waiting in the RFC Editor's queue | the time of submission some early allocations are valid (not | |||
after approval by the IESG.</t> | expired), these allocations must not be considered to have expired | |||
while the document is under IESG consideration or is awaiting | ||||
publication in the RFC Editor's queue after approval by the IESG. | ||||
<!-- [rfced] Section 6.5.3: The provided text did not match the text | ||||
we found in RFC 7120 [BCP100]. We updated the text accordingly so | ||||
that it would match. Please let us know any concerns. | ||||
Original: | ||||
[BCP100] defines a time limit for the validity of Early Allocations, | ||||
after which they expire unless they are renewed. [BCP100] 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. | ||||
| | ||||
| - RFC7120 (BCP100), Section 3.3 | ||||
| https://www.rfc-editor.org/rfc/rfc7120.html#section-3.3 | ||||
Currently: | ||||
[BCP100] defines a time limit for the validity of early allocations, | ||||
after which they expire unless they are renewed. Section 3.3 of RFC | ||||
7120 [BCP100] 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 must not be considered to have expired | ||||
| while the document is under IESG consideration or is awaiting | ||||
| publication in the RFC Editor's queue after approval by the IESG. --> | ||||
</t> | ||||
</blockquote> | </blockquote> | |||
</section> | </section> | |||
<section anchor="initial-contents-of-the-registry-1"> | <section anchor="initial-contents-of-the-registry-1"> | |||
<name>Initial contents of the registry</name> | <name>Initial Contents of the Registry</name> | |||
<t>None.</t> | <t>At the time of writing, this registry does not contain any entries. | |||
</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="register-media-type-and-content-format"> | <section anchor="register-media-type-and-content-format"> | |||
<name>Register Media Type and Content-Format</name> | <name>Media Type and Content-Format Registration</name> | |||
<section anchor="media-type-applicationyang-sidjson"> | <section anchor="media-type-applicationyang-sidjson"> | |||
<name>Media Type application/yang-sid+json</name> | <name>Media Type application/yang-sid+json</name> | |||
<t>This document adds the following Media-Type to the "Media Types" re gistry.</t> | <t>This document adds the following media type to the "Media Types" re gistry.</t> | |||
<table align="left"> | <table align="left"> | |||
<name>SID File Media-Type Registration</name> | <name>SID File Media Type Registration</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Name</th> | <th align="left">Name</th> | |||
<th align="left">Template</th> | <th align="left">Template</th> | |||
<th align="left">Reference</th> | <th align="left">Reference</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">yang-sid+json</td> | <td align="left">yang-sid+json</td> | |||
<td align="left">application/yang-sid+json</td> | <td align="left">application/yang-sid+json</td> | |||
<td align="left">RFC XXXX</td> | <td align="left">RFC 9595</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>// RFC Ed.: please replace RFC XXXX with this RFC number and remove | <dl spacing="normal"> | |||
this note.</t> | ||||
<dl spacing="compact"> | ||||
<dt>Type name:</dt> | <dt>Type name:</dt> | |||
<dd> | <dd> | |||
<t>application</t> | <t>application</t> | |||
</dd> | </dd> | |||
<dt>Subtype name:</dt> | <dt>Subtype name:</dt> | |||
<dd> | <dd> | |||
<t>yang-sid+json</t> | <t>yang-sid+json</t> | |||
</dd> | </dd> | |||
<dt>Required parameters:</dt> | <dt>Required parameters:</dt> | |||
<dd> | <dd> | |||
skipping to change at line 1514 ¶ | skipping to change at line 2528 ¶ | |||
<dt>Optional parameters:</dt> | <dt>Optional parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Encoding considerations:</dt> | <dt>Encoding considerations:</dt> | |||
<dd> | <dd> | |||
<t>binary (UTF-8)</t> | <t>binary (UTF-8)</t> | |||
</dd> | </dd> | |||
<dt>Security considerations:</dt> | <dt>Security considerations:</dt> | |||
<dd> | <dd> | |||
<t>see <xref target="security-considerations"/> of RFC XXXX</t> | <t>See <xref target="security-considerations"/> of RFC 9595.</t> | |||
</dd> | </dd> | |||
<dt>Published specification:</dt> | <dt>Published specification:</dt> | |||
<dd> | <dd> | |||
<t>RFC XXXX</t> | <t>RFC 9595</t> | |||
</dd> | </dd> | |||
<dt>Applications that use this media type:</dt> | <dt>Applications that use this media type:</dt> | |||
<dd> | <dd> | |||
<t>applications that need to obtain YANG SIDs to interchange | <t>Applications that need to obtain YANG SIDs to interchange | |||
YANG-modeled data in a concise and efficient representation</t> | YANG-modeled data in a concise and efficient representation.</t> | |||
</dd> | </dd> | |||
<dt>Fragment identifier considerations:</dt> | <dt>Fragment identifier considerations:</dt> | |||
<dd> | <dd> | |||
<t>The syntax and semantics of | <t>The syntax and semantics of | |||
fragment identifiers specified for "application/yang-sid+json" is | fragment identifiers specified for "application/yang-sid+json" is | |||
as specified for "application/json". (At publication of this | as specified for "application/json". (At publication of this | |||
document, there is no fragment identification syntax defined for | document, there is no fragment identification syntax defined for | |||
"application/json".)</t> | "application/json".)</t> | |||
</dd> | </dd> | |||
<dt>Additional information:</dt> | <dt>Additional information:</dt> | |||
<dd> | <dd><t><br/></t> | |||
<dl> | <dl spacing="compact"> | |||
<dt><br/></dt> | ||||
<dd> | ||||
<t/> | ||||
</dd> | ||||
<dt>Magic number(s):</dt> | <dt>Magic number(s):</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>File extension(s):</dt> | <dt>File extension(s):</dt> | |||
<dd> | <dd> | |||
<t>.sid</t> | <t>.sid</t> | |||
</dd> | </dd> | |||
<dt>Macintosh file type code(s):</dt> | <dt>Macintosh file type code(s):</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
</dd> | </dd> | |||
<dt>Person & email address to contact for further information:</ dt> | <dt>Person & email address to contact for further information:</ dt> | |||
<dd> | <dd> | |||
<t>CORE WG mailing list (core@ietf.org), | <t>CORE WG mailing list (core@ietf.org) | |||
or IETF Applications and Real-Time Area (art@ietf.org)</t> | or IETF Applications and Real-Time Area (art@ietf.org)</t> | |||
</dd> | </dd> | |||
<dt>Intended usage:</dt> | <dt>Intended usage:</dt> | |||
<dd> | <dd> | |||
<t>COMMON</t> | <t>COMMON</t> | |||
</dd> | </dd> | |||
<dt>Restrictions on usage:</dt> | <dt>Restrictions on usage:</dt> | |||
<dd> | <dd> | |||
<t>none</t> | <t>none</t> | |||
</dd> | </dd> | |||
<dt>Author/Change controller:</dt> | <dt>Author/Change controller:</dt> | |||
<dd> | <dd> | |||
<t>IETF</t> | <t>IETF</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
</section> | </section> | |||
<section anchor="coap-content-format"> | <section anchor="coap-content-format"> | |||
<name>CoAP Content-Format</name> | <name>CoAP Content-Format</name> | |||
<t>This document adds the following Content-Format to the "CoAP Conten | <t>This document adds the following Content-Format to the "CoAP Conten | |||
t-Formats", | t-Formats" registry | |||
within the "Constrained RESTful Environments (CoRE) Parameters" | within the "Constrained RESTful Environments (CoRE) Parameters" group of | |||
registry, where TBD1 comes from the "IETF Review" 256-999 range.</t> | registries, where 260 has been assigned from the "IETF Review" (256-9999) range. | |||
<!-- [rfced] Section 6.6.2: We changed "999" to "9999" per | ||||
<https://www.iana.org/assignments/core-parameters/>. Please let us | ||||
know any concerns. | ||||
Original: | ||||
This document adds the following Content-Format to the "CoAP Content- | ||||
Formats", within the "Constrained RESTful Environments (CoRE) | ||||
Parameters" registry, where TBD1 comes from the "IETF Review" 256-999 | ||||
range. | ||||
Currently: | ||||
This document adds the following Content-Format to the "CoAP Content- | ||||
Formats" registry within the "Constrained RESTful Environments (CoRE) | ||||
Parameters" group of registries, where 260 has been assigned from the "IETF | ||||
Review" (256-9999) range. | ||||
--> | ||||
</t> | ||||
<table align="left"> | <table align="left"> | |||
<name>SID File Content-format Registration</name> | <name>SID File Content-Format Registration</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Content Type</th> | <th align="left">Content Type</th> | |||
<th align="left">Content Coding</th> | <th align="left">Content Coding</th> | |||
<th align="left">ID</th> | <th align="left">ID</th> | |||
<th align="left">Reference</th> | <th align="left">Reference</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">application/yang-sid+json</td> | <td align="left">application/yang-sid+json</td> | |||
<td align="left">-</td> | <td align="left">-</td> | |||
<td align="left">TBD1</td> | <td align="left">260</td> | |||
<td align="left">RFC XXXX</td> | <td align="left">RFC 9595</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>// RFC Ed.: please replace TBD1 with the assigned ID, remove the | ||||
requested range, and remove this note.<br/> | ||||
// RFC Ed.: please replace RFC XXXX with this RFC number and remove this note.</ | ||||
t> | ||||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references anchor="sec-normative-references"> | <references anchor="sec-normative-references"> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="RFC3688"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36 | |||
<title>The IETF XML Registry</title> | 88.xml"/> | |||
<author fullname="M. Mealling" initials="M." surname="Mealling"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69 | |||
<date month="January" year="2004"/> | 91.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62 | |||
<t>This document describes an IANA maintained registry for IETF st | 41.xml"/> | |||
andards which use Extensible Markup Language (XML) related items such as Namespa | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew | 41.xml"/> | |||
ork (RDF) Schemas.</t> | ||||
</abstract> | <referencegroup anchor="BCP100" target="https://www.rfc-editor.org/info/b | |||
</front> | cp100"> | |||
<seriesInfo name="BCP" value="81"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC. | |||
<seriesInfo name="RFC" value="3688"/> | 7120.xml"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC3688"/> | </referencegroup> | |||
</reference> | ||||
<reference anchor="RFC6991"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79 | |||
<front> | 50.xml"/> | |||
<title>Common YANG Data Types</title> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79 | |||
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn | 51.xml"/> | |||
ame="Schoenwaelder"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80 | |||
<date month="July" year="2013"/> | 40.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82 | |||
<t>This document introduces a collection of common data types to b | 59.xml"/> | |||
e used with the YANG data modeling language. This document obsoletes RFC 6021.</ | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87 | |||
t> | 91.xml"/> | |||
</abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21 | |||
</front> | 19.xml"/> | |||
<seriesInfo name="RFC" value="6991"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
<seriesInfo name="DOI" value="10.17487/RFC6991"/> | 74.xml"/> | |||
</reference> | ||||
<reference anchor="BCP100"> | ||||
<front> | ||||
<title>Early IANA Allocation of Standards Track Code Points</title> | ||||
<author fullname="M. Cotton" initials="M." surname="Cotton"/> | ||||
<date month="January" year="2014"/> | ||||
<abstract> | ||||
<t>This memo describes the process for early allocation of code po | ||||
ints by IANA from registries for which "Specification Required", "RFC Required", | ||||
"IETF Review", or "Standards Action" policies apply. This process can be used t | ||||
o alleviate the problem where code point allocation is needed to facilitate desi | ||||
red or required implementation and deployment experience prior to publication of | ||||
an RFC, which would normally trigger code point allocation. The procedures in t | ||||
his document are intended to apply only to IETF Stream documents.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="100"/> | ||||
<seriesInfo name="RFC" value="7120"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7120"/> | ||||
</reference> | ||||
<reference anchor="RFC7950"> | ||||
<front> | ||||
<title>The YANG 1.1 Data Modeling Language</title> | ||||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | ||||
<date month="August" year="2016"/> | ||||
<abstract> | ||||
<t>YANG is a data modeling language used to model configuration da | ||||
ta, state data, Remote Procedure Calls, and notifications for network management | ||||
protocols. This document describes the syntax and semantics of version 1.1 of t | ||||
he YANG language. YANG version 1.1 is a maintenance release of the YANG language | ||||
, addressing ambiguities and defects in the original specification. There are a | ||||
small number of backward incompatibilities from YANG version 1. This document al | ||||
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).< | ||||
/t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7950"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7950"/> | ||||
</reference> | ||||
<reference anchor="RFC7951"> | ||||
<front> | ||||
<title>JSON Encoding of Data Modeled with YANG</title> | ||||
<author fullname="L. Lhotka" initials="L." surname="Lhotka"/> | ||||
<date month="August" year="2016"/> | ||||
<abstract> | ||||
<t>This document defines encoding rules for representing configura | ||||
tion data, state data, parameters of Remote Procedure Call (RPC) operations or a | ||||
ctions, and notifications defined using YANG as JavaScript Object Notation (JSON | ||||
) text.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7951"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7951"/> | ||||
</reference> | ||||
<reference anchor="RFC8040"> | ||||
<front> | ||||
<title>RESTCONF Protocol</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<author fullname="K. Watsen" initials="K." surname="Watsen"/> | ||||
<date month="January" year="2017"/> | ||||
<abstract> | ||||
<t>This document describes an HTTP-based protocol that provides a | ||||
programmatic interface for accessing data defined in YANG, using the datastore c | ||||
oncepts defined in the Network Configuration Protocol (NETCONF).</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8040"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8040"/> | ||||
</reference> | ||||
<reference anchor="RFC8259"> | ||||
<front> | ||||
<title>The JavaScript Object Notation (JSON) Data Interchange Format | ||||
</title> | ||||
<author fullname="T. Bray" initials="T." role="editor" surname="Bray | ||||
"/> | ||||
<date month="December" year="2017"/> | ||||
<abstract> | ||||
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, | ||||
language-independent data interchange format. It was derived from the ECMAScrip | ||||
t Programming Language Standard. JSON defines a small set of formatting rules fo | ||||
r the portable representation of structured data.</t> | ||||
<t>This document removes inconsistencies with other specifications | ||||
of JSON, repairs specification errors, and offers experience-based interoperabi | ||||
lity guidance.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="90"/> | ||||
<seriesInfo name="RFC" value="8259"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8259"/> | ||||
</reference> | ||||
<reference anchor="RFC8791"> | ||||
<front> | ||||
<title>YANG Data Structure Extensions</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<author fullname="M. Björklund" initials="M." surname="Björklund"/> | ||||
<author fullname="K. Watsen" initials="K." surname="Watsen"/> | ||||
<date month="June" year="2020"/> | ||||
<abstract> | ||||
<t>This document describes YANG mechanisms for defining abstract d | ||||
ata structures with YANG.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8791"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8791"/> | ||||
</reference> | ||||
<reference anchor="RFC2119"> | ||||
<front> | ||||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | ||||
le> | ||||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | ||||
<date month="March" year="1997"/> | ||||
<abstract> | ||||
<t>In many standards track documents several words are used to sig | ||||
nify the requirements in the specification. These words are often capitalized. T | ||||
his document defines these words as they should be interpreted in IETF documents | ||||
. This document specifies an Internet Best Current Practices for the Internet Co | ||||
mmunity, and requests discussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="2119"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | ||||
</reference> | ||||
<reference anchor="RFC8174"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti | ||||
tle> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t>RFC 2119 specifies common key words that may be used in protoco | ||||
l specifications. This document aims to reduce the ambiguity by clarifying that | ||||
only UPPERCASE usage of the key words have the defined special meanings.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
</references> | </references> | |||
<references anchor="sec-informative-references"> | <references anchor="sec-informative-references"> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="RFC6020"> | ||||
<front> | ||||
<title>YANG - A Data Modeling Language for the Network Configuration | ||||
Protocol (NETCONF)</title> | ||||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | ||||
<date month="October" year="2010"/> | ||||
<abstract> | ||||
<t>YANG is a data modeling language used to model configuration an | ||||
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON | ||||
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6020"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6020"/> | ||||
</reference> | ||||
<reference anchor="RFC6241"> | ||||
<front> | ||||
<title>Network Configuration Protocol (NETCONF)</title> | ||||
<author fullname="R. Enns" initials="R." role="editor" surname="Enns | ||||
"/> | ||||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | ||||
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn | ||||
ame="Schoenwaelder"/> | ||||
<author fullname="A. Bierman" initials="A." role="editor" surname="B | ||||
ierman"/> | ||||
<date month="June" year="2011"/> | ||||
<abstract> | ||||
<t>The Network Configuration Protocol (NETCONF) defined in this do | ||||
cument provides mechanisms to install, manipulate, and delete the configuration | ||||
of network devices. It uses an Extensible Markup Language (XML)-based data encod | ||||
ing for the configuration data as well as the protocol messages. The NETCONF pro | ||||
tocol operations are realized as remote procedure calls (RPCs). This document ob | ||||
soletes RFC 4741. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6241"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6241"/> | ||||
</reference> | ||||
<reference anchor="RFC7224"> | ||||
<front> | ||||
<title>IANA Interface Type YANG Module</title> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="May" year="2014"/> | ||||
<abstract> | ||||
<t>This document defines the initial version of the iana-if-type Y | ||||
ANG module.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7224"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7224"/> | ||||
</reference> | ||||
<reference anchor="RFC7228"> | ||||
<front> | ||||
<title>Terminology for Constrained-Node Networks</title> | ||||
<author fullname="C. Bormann" initials="C." surname="Bormann"/> | ||||
<author fullname="M. Ersue" initials="M." surname="Ersue"/> | ||||
<author fullname="A. Keranen" initials="A." surname="Keranen"/> | ||||
<date month="May" year="2014"/> | ||||
<abstract> | ||||
<t>The Internet Protocol Suite is increasingly used on small devic | ||||
es with severe constraints on power, memory, and processing resources, creating | ||||
constrained-node networks. This document provides a number of basic terms that h | ||||
ave been useful in the standardization work for constrained-node networks.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7228"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7228"/> | ||||
</reference> | ||||
<reference anchor="RFC7317"> | ||||
<front> | ||||
<title>A YANG Data Model for System Management</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="August" year="2014"/> | ||||
<abstract> | ||||
<t>This document defines a YANG data model for the configuration a | ||||
nd identification of some common system properties within a device containing a | ||||
Network Configuration Protocol (NETCONF) server. This document also includes dat | ||||
a node definitions for system identification, time-of-day management, user manag | ||||
ement, DNS resolver configuration, and some protocol operations for system manag | ||||
ement.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7317"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7317"/> | ||||
</reference> | ||||
<reference anchor="RFC8126"> | ||||
<front> | ||||
<title>Guidelines for Writing an IANA Considerations Section in RFCs | ||||
</title> | ||||
<author fullname="M. Cotton" initials="M." surname="Cotton"/> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<author fullname="T. Narten" initials="T." surname="Narten"/> | ||||
<date month="June" year="2017"/> | ||||
<abstract> | ||||
<t>Many protocols make use of points of extensibility that use con | ||||
stants to identify various protocol parameters. To ensure that the values in the | ||||
se fields do not have conflicting uses and to promote interoperability, their al | ||||
locations are often coordinated by a central record keeper. For IETF protocols, | ||||
that role is filled by the Internet Assigned Numbers Authority (IANA).</t> | ||||
<t>To make assignments in a given registry prudently, guidance des | ||||
cribing the conditions under which new values should be assigned, as well as whe | ||||
n and how modifications to existing values can be made, is needed. This document | ||||
defines a framework for the documentation of these guidelines by specification | ||||
authors, in order to assure that the provided guidance for the IANA Consideratio | ||||
ns is clear and addresses the various issues that are likely in the operation of | ||||
a registry.</t> | ||||
<t>This is the third edition of this document; it obsoletes RFC 52 | ||||
26.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="26"/> | ||||
<seriesInfo name="RFC" value="8126"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8126"/> | ||||
</reference> | ||||
<reference anchor="RFC8341"> | ||||
<front> | ||||
<title>Network Configuration Access Control Model</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="March" year="2018"/> | ||||
<abstract> | ||||
<t>The standardization of network configuration interfaces for use | ||||
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ | ||||
ires a structured and secure operating environment that promotes human usability | ||||
and multi-vendor interoperability. There is a need for standard mechanisms to r | ||||
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu | ||||
red subset of all available NETCONF or RESTCONF protocol operations and content. | ||||
This document defines such an access control model.</t> | ||||
<t>This document obsoletes RFC 6536.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="91"/> | ||||
<seriesInfo name="RFC" value="8341"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8341"/> | ||||
</reference> | ||||
<reference anchor="RFC8343"> | ||||
<front> | ||||
<title>A YANG Data Model for Interface Management</title> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="March" year="2018"/> | ||||
<abstract> | ||||
<t>This document defines a YANG data model for the management of n | ||||
etwork interfaces. It is expected that interface-type-specific data models augme | ||||
nt the generic interfaces data model defined in this document. The data model in | ||||
cludes definitions for configuration and system state (status information and co | ||||
unters for the collection of statistics).</t> | ||||
<t>The YANG data model in this document conforms to the Network Ma | ||||
nagement Datastore Architecture (NMDA) defined in RFC 8342.</t> | ||||
<t>This document obsoletes RFC 7223.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8343"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8343"/> | ||||
</reference> | ||||
<reference anchor="RFC8344"> | ||||
<front> | ||||
<title>A YANG Data Model for IP Management</title> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="March" year="2018"/> | ||||
<abstract> | ||||
<t>This document defines a YANG data model for management of IP im | ||||
plementations. The data model includes configuration and system state.</t> | ||||
<t>The YANG data model in this document conforms to the Network Ma | ||||
nagement Datastore Architecture defined in RFC 8342.</t> | ||||
<t>This document obsoletes RFC 7277.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8344"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8344"/> | ||||
</reference> | ||||
<reference anchor="RFC8366"> | ||||
<front> | ||||
<title>A Voucher Artifact for Bootstrapping Protocols</title> | ||||
<author fullname="K. Watsen" initials="K." surname="Watsen"/> | ||||
<author fullname="M. Richardson" initials="M." surname="Richardson"/ | ||||
> | ||||
<author fullname="M. Pritikin" initials="M." surname="Pritikin"/> | ||||
<author fullname="T. Eckert" initials="T." surname="Eckert"/> | ||||
<date month="May" year="2018"/> | ||||
<abstract> | ||||
<t>This document defines a strategy to securely assign a pledge to | ||||
an owner using an artifact signed, directly or indirectly, by the pledge's manu | ||||
facturer. This artifact is known as a "voucher".</t> | ||||
<t>This document defines an artifact format as a YANG-defined JSON | ||||
document that has been signed using a Cryptographic Message Syntax (CMS) struct | ||||
ure. Other YANG-derived formats are possible. The voucher artifact is normally g | ||||
enerated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing | ||||
Authority (MASA)).</t> | ||||
<t>This document only defines the voucher artifact, leaving it to | ||||
other documents to describe specialized protocols for accessing it.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8366"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8366"/> | ||||
</reference> | ||||
<reference anchor="RFC8407"> | ||||
<front> | ||||
<title>Guidelines for Authors and Reviewers of Documents Containing | ||||
YANG Data Models</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<date month="October" year="2018"/> | ||||
<abstract> | ||||
<t>This memo provides guidelines for authors and reviewers of spec | ||||
ifications containing YANG modules. Recommendations and procedures are defined, | ||||
which are intended to increase interoperability and usability of Network Configu | ||||
ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN | ||||
G modules. This document obsoletes RFC 6087.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="216"/> | ||||
<seriesInfo name="RFC" value="8407"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8407"/> | ||||
</reference> | ||||
<reference anchor="RFC8792"> | ||||
<front> | ||||
<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t | ||||
itle> | ||||
<author fullname="K. Watsen" initials="K." surname="Watsen"/> | ||||
<author fullname="E. Auerswald" initials="E." surname="Auerswald"/> | ||||
<author fullname="A. Farrel" initials="A." surname="Farrel"/> | ||||
<author fullname="Q. Wu" initials="Q." surname="Wu"/> | ||||
<date month="June" year="2020"/> | ||||
<abstract> | ||||
<t>This document defines two strategies for handling long lines in | ||||
width-bounded text content. One strategy, called the "single backslash" strateg | ||||
y, is based on the historical use of a single backslash ('\') character to indic | ||||
ate where line-folding has occurred, with the continuation occurring with the fi | ||||
rst character that is not a space character (' ') on the next line. The second s | ||||
trategy, called the "double backslash" strategy, extends the first strategy by a | ||||
dding a second backslash character to identify where the continuation begins and | ||||
is thereby able to handle cases not supported by the first strategy. Both strat | ||||
egies use a self-describing header enabling automated reconstitution of the orig | ||||
inal content.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8792"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8792"/> | ||||
</reference> | ||||
<reference anchor="I-D.ietf-core-comi"> | ||||
<front> | ||||
<title>CoAP Management Interface (CORECONF)</title> | ||||
<author fullname="Michel Veillette" initials="M." surname="Veillette | ||||
"> | ||||
<organization>Trilliant Networks Inc.</organization> | ||||
</author> | ||||
<author fullname="Peter Van der Stok" initials="P." surname="Van der | ||||
Stok"> | ||||
<organization>consultant</organization> | ||||
</author> | ||||
<author fullname="Alexander Pelov" initials="A." surname="Pelov"> | ||||
<organization>Acklio</organization> | ||||
</author> | ||||
<author fullname="Andy Bierman" initials="A." surname="Bierman"> | ||||
<organization>YumaWorks</organization> | ||||
</author> | ||||
<author fullname="Carsten Bormann" initials="C." surname="Bormann"> | ||||
<organization>Universität Bremen TZI</organization> | ||||
</author> | ||||
<date day="4" month="September" year="2023"/> | ||||
<abstract> | ||||
<t> This document describes a network management interface for | ||||
constrained devices and networks, called CoAP Management Interface | ||||
(CORECONF). The Constrained Application Protocol (CoAP) is used to | ||||
access datastore and data node resources specified in YANG, or SMIv2 | ||||
converted to YANG. CORECONF uses the YANG to CBOR mapping and | ||||
converts YANG identifier strings to numeric identifiers for payload | ||||
size reduction. CORECONF extends the set of YANG based protocols, | ||||
NETCONF and RESTCONF, with the capability to manage constrained | ||||
devices and networks. | ||||
</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60 | |||
</abstract> | 20.xml"/> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72 | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-16"/> | 24.xml"/> | |||
</reference> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72 | |||
<reference anchor="I-D.ietf-core-yang-library"> | 28.xml"/> | |||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73 | |||
<title>Constrained YANG Module Library</title> | 17.xml"/> | |||
<author fullname="Michel Veillette" initials="M." surname="Veillette | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
"> | 26.xml"/> | |||
<organization>Trilliant Networks Inc.</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
</author> | 43.xml"/> | |||
<author fullname="Ivaylo Petrov" initials="I." surname="Petrov"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
<organization>Acklio</organization> | 44.xml"/> | |||
</author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
<date day="11" month="January" year="2021"/> | 66.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84 | |||
<t> This document describes a constrained version of the YANG li | 07.xml"/> | |||
brary | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87 | |||
that provides information about the YANG modules, datastores, and | 92.xml"/> | |||
datastore schemas used by a constrained network management server | ||||
(e.g., a CORECONF server). | ||||
</t> | <!-- draft-ietf-core-comi (I-D Exists) | |||
</abstract> | "Long way" to fix initials, add surname, and add editor designations --> | |||
</front> | <reference anchor="CORE-COMI"> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-library- | <front> | |||
03"/> | <title>CoAP Management Interface (CORECONF)</title> | |||
</reference> | <author initials="M. V." surname="Veillette" fullname="Michel Veillette" r | |||
<reference anchor="I-D.ietf-anima-constrained-voucher"> | ole="editor"> | |||
<front> | <organization>Trilliant Networks Inc.</organization> | |||
<title>Constrained Bootstrapping Remote Secure Key Infrastructure (B | </author> | |||
RSKI)</title> | <author initials="P." surname="van der Stok" fullname="Peter van der Stok" | |||
<author fullname="Michael Richardson" initials="M." surname="Richard | role="editor"> | |||
son"> | <organization>consultant</organization> | |||
<organization>Sandelman Software Works</organization> | </author> | |||
</author> | <author initials="A." surname="Pelov" fullname="Alexander Pelov" role="edi | |||
<author fullname="Peter Van der Stok" initials="P." surname="Van der | tor"> | |||
Stok"> | <organization>IMT Atlantique</organization> | |||
<organization>vanderstok consultancy</organization> | </author> | |||
</author> | <author initials="A." surname="Bierman" fullname="Andy Bierman"> | |||
<author fullname="Panos Kampanakis" initials="P." surname="Kampanaki | <organization>YumaWorks</organization> | |||
s"> | </author> | |||
<organization>Cisco Systems</organization> | <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="e | |||
</author> | ditor"> | |||
<author fullname="Esko Dijk" initials="E." surname="Dijk"> | <organization>Universität Bremen TZI</organization> | |||
<organization>IoTconsultancy.nl</organization> | </author> | |||
</author> | <date month="March" day="4" year="2024" /> | |||
<date day="21" month="November" year="2023"/> | </front> | |||
<abstract> | <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-17" /> | |||
<t> This document defines the Constrained Bootstrapping Remote S | </reference> | |||
ecure Key | ||||
Infrastructure (Constrained BRSKI) protocol, which provides a | <!-- draft-ietf-core-yang-library (Expired) | |||
solution for secure zero-touch bootstrapping of resource-constrained | "Long way" to add editor designations --> | |||
(IoT) devices into the network of a domain owner. This protocol is | <reference anchor="YANG-LIBRARY"> | |||
designed for constrained networks, which may have limited data | <front> | |||
throughput or may experience frequent packet loss. Constrained BRSKI | <title>Constrained YANG Module Library</title> | |||
is a variant of the BRSKI protocol, which uses an artifact signed by | <author fullname="Michel Veillette" initials="M." surname="Veillette" role=" | |||
the device manufacturer called the "voucher" which enables a new | editor"> | |||
device and the owner's network to mutually authenticate. While the | <organization>Trilliant Networks Inc.</organization> | |||
BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a | </author> | |||
compact CBOR-encoded voucher. The BRSKI voucher definition is | <author fullname="Ivaylo Petrov" initials="I." surname="Petrov" role="editor | |||
extended with new data types that allow for smaller voucher sizes. | "> | |||
The Enrollment over Secure Transport (EST) protocol, used in BRSKI, | <organization>Acklio</organization> | |||
is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced | </author> | |||
with DTLS-secured CoAP (CoAPS). This document Updates RFC 8366 and | <date day="11" month="January" year="2021"/> | |||
RFC 8995. | </front> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-library-03"/> | ||||
</reference> | ||||
<!-- draft-ietf-anima-constrained-voucher (WG Last Call) | ||||
"Long way" to fix surname --> | ||||
<reference anchor="CONSTRAINED-VOUCHER"> | ||||
<front> | ||||
<title>Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)</ | ||||
title> | ||||
<author fullname="Michael Richardson" initials="M." surname="Richardson"> | ||||
<organization>Sandelman Software Works</organization> | ||||
</author> | ||||
<author fullname="Peter van der Stok" initials="P." surname="van der Stok"> | ||||
<organization>vanderstok consultancy</organization> | ||||
</author> | ||||
<author fullname="Panos Kampanakis" initials="P." surname="Kampanakis"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author fullname="Esko Dijk" initials="E." surname="Dijk"> | ||||
<organization>IoTconsultancy.nl</organization> | ||||
</author> | ||||
<date day="3" month="March" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher- | ||||
24"/> | ||||
</reference> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92 | ||||
54.xml"/> | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained- | ||||
voucher-22"/> | ||||
</reference> | ||||
<reference anchor="RFC9254"> | ||||
<front> | ||||
<title>Encoding of Data Modeled with YANG in the Concise Binary Obje | ||||
ct Representation (CBOR)</title> | ||||
<author fullname="M. Veillette" initials="M." role="editor" surname= | ||||
"Veillette"/> | ||||
<author fullname="I. Petrov" initials="I." role="editor" surname="Pe | ||||
trov"/> | ||||
<author fullname="A. Pelov" initials="A." surname="Pelov"/> | ||||
<author fullname="C. Bormann" initials="C." surname="Bormann"/> | ||||
<author fullname="M. Richardson" initials="M." surname="Richardson"/ | ||||
> | ||||
<date month="July" year="2022"/> | ||||
<abstract> | ||||
<t>YANG (RFC 7950) is a data modeling language used to model confi | ||||
guration data, state data, parameters and results of Remote Procedure Call (RPC) | ||||
operations or actions, and notifications.</t> | ||||
<t>This document defines encoding rules for YANG in the Concise Bi | ||||
nary Object Representation (CBOR) (RFC 8949).</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9254"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9254"/> | ||||
</reference> | ||||
<reference anchor="yangcatalog" target="https://yangcatalog.org"> | <reference anchor="yangcatalog" target="https://yangcatalog.org"> | |||
<front> | <front> | |||
<title>YANG Catalog</title> | <title>YANG Catalog</title> | |||
<author> | <author> | |||
<organization/> | <organization></organization> | |||
</author> | </author> | |||
<date/> | <date/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="PYANG" target="https://github.com/mbj4668/pyang"> | <reference anchor="PYANG" target="https://github.com/mbj4668/pyang"> | |||
<front> | <front> | |||
<title>An extensible YANG validator and converter in python</title> | <title>An extensible YANG validator and converter in python</title> | |||
<author initials="M." surname="Bjorklund" fullname="Martin Bjorklund "> | <author initials="M." surname="Björklund" fullname="Martin Björklund "> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date/> | <date month="March" year="2024"/> | |||
</front> | </front> | |||
<refcontent>commit 25f69e8</refcontent> | ||||
</reference> | </reference> | |||
<reference anchor="I-D.bormann-t2trg-deref-id"> | ||||
<front> | ||||
<title>The "dereferenceable identifier" pattern</title> | ||||
<author fullname="Carsten Bormann" initials="C." surname="Bormann"> | ||||
<organization>Universität Bremen TZI</organization> | ||||
</author> | ||||
<author fullname="Christian Amsüss" initials="C." surname="Amsüss"> | ||||
</author> | ||||
<date day="19" month="December" year="2023"/> | ||||
<abstract> | ||||
<t> In a protocol or an application environment, it is often imp | ||||
ortant to | ||||
be able to create unambiguous identifiers for some meaning (concept | ||||
or some entity). | ||||
Due to the simplicity of creating URIs, these have become popular for | <!-- draft-bormann-t2trg-deref-id (I-D Exists) | |||
this purpose. Beyond the purpose of identifiers to be uniquely | "Long way" to fix "double quotes within double quotes" in title --> | |||
associated with a meaning, some of these URIs are in principle | <reference anchor="DEREF-ID"> | |||
_dereferenceable_, so something can be placed that can be retrieved | <front> | |||
when encountering such a URI. | <title>The 'dereferenceable identifier' pattern</title> | |||
<author fullname="Carsten Bormann" initials="C." surname="Bormann"> | ||||
<organization>Universität Bremen TZI</organization> | ||||
</author> | ||||
<author fullname="Christian Amsüss" initials="C." surname="Amsüss"/> | ||||
<date day="2" month="March" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-deref-id-03"/> | ||||
</reference> | ||||
// The present -01 version is a stub to draw some attention to the | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91 | |||
// opportunity that this pattern would benefit from a common | 95.xml"/> | |||
// description, documenting its benefits and pitfalls, and some | ||||
// mitigations for the latter. | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-deref-id- | ||||
02"/> | ||||
</reference> | ||||
<reference anchor="RFC9195"> | ||||
<front> | ||||
<title>A File Format for YANG Instance Data</title> | ||||
<author fullname="B. Lengyel" initials="B." surname="Lengyel"/> | ||||
<author fullname="B. Claise" initials="B." surname="Claise"/> | ||||
<date month="February" year="2022"/> | ||||
<abstract> | ||||
<t>There is a need to document data defined in YANG models at desi | ||||
gn time, implementation time, or when a live server is unavailable. This documen | ||||
t specifies a standard file format for YANG instance data, which follows the syn | ||||
tax and semantics of existing YANG models and annotates it with metadata.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9195"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9195"/> | ||||
</reference> | ||||
</references> | </references> | |||
</references> | </references> | |||
<?line 1331?> | ||||
<section anchor="sid-file-example"> | <section anchor="sid-file-example"> | |||
<name>".sid" file example</name> | <name>".sid" File Example</name> | |||
<t>The following ".sid" file (ietf-system@2014-08-06.sid) has been generat | <t>The following ".sid" file ('ietf-system@2014-08-06.sid') has been gener | |||
ed using the following yang modules:</t> | ated using the following YANG modules:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>ietf-system@2014-08-06.yang (defined in <xref target="RFC7317"/>)</ t> | <t>'ietf-system@2014-08-06.yang' (defined in <xref target="RFC7317"/>) </t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>ietf-yang-types@2013-07-15.yang (defined in <xref target="RFC6991"/ >)</t> | <t>'ietf-yang-types@2013-07-15.yang' (defined in <xref target="RFC6991 "/>)</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>ietf-inet-types@2013-07-15.yang (defined in <xref target="RFC6991"/ >)</t> | <t>'ietf-inet-types@2013-07-15.yang' (defined in <xref target="RFC6991 "/>)</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>ietf-netconf-acm@2018-02-14.yang (defined in <xref target="RFC8341" />)</t> | <t>'ietf-netconf-acm@2018-02-14.yang' (defined in <xref target="RFC834 1"/>)</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>iana-crypt-hash@2014-08-06.yang (defined in <xref target="RFC7317"/ >)</t> | <t>'iana-crypt-hash@2014-08-06.yang' (defined in <xref target="RFC7317 "/>)</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>For purposes of exposition, line breaks have been introduced below in | <t>For purposes of exposition, per <xref target="RFC8792"/>, line breaks h ave been introduced below in | |||
some JSON strings that represent overly long identifiers.</t> | some JSON strings that represent overly long identifiers.</t> | |||
<!-- /^ *[^" ]+"/ --> | ||||
<figure anchor="sid-example-pretty"> | <figure anchor="sid-example-pretty"> | |||
<name>Example .sid file (ietf-system, with extra line-breaks)</name> | <name>Example .sid File ('ietf-system', with Extra Line Breaks)</name> | |||
<sourcecode type="yang-sid"><![CDATA[ | <sourcecode type="yang-sid"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
{ | { | |||
"ietf-sid-file:sid-file": { | "ietf-sid-file:sid-file": { | |||
"module-name": "ietf-system", | "module-name": "ietf-system", | |||
"module-revision": "2014-08-06", | "module-revision": "2014-08-06", | |||
"description": "Example sid file", | "description": "Example sid file", | |||
"dependency-revision": [ | "dependency-revision": [ | |||
{ | { | |||
skipping to change at line 2556 ¶ | skipping to change at line 3240 ¶ | |||
"namespace": "data", | "namespace": "data", | |||
"identifier": "/ietf-system:system/radius/server/udp/shared-\ | "identifier": "/ietf-system:system/radius/server/udp/shared-\ | |||
secret", | secret", | |||
"sid": "1774" | "sid": "1774" | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<!-- [rfced] Figure 3: Please confirm that the numbering between | ||||
"1715" and "1717" is correct here. We ask because (1) aside from the | ||||
two items between "1715" and "1717" (and "1716" seems to be missing), | ||||
all of the SID "17xx" numbers in the figure are in numerical order | ||||
and (2) we see "SIDs are assigned sequentially from the entry point | ||||
up to the size of the registered SID range" in Appendix B. | ||||
Original: | ||||
... | ||||
"namespace": "feature", | ||||
"identifier": "timezone-name", | ||||
"sid": "1714" | ||||
}, | ||||
{ | ||||
"namespace": "data", | ||||
"identifier": "/ietf-system:set-current-datetime", | ||||
"sid": "1715" | ||||
}, | ||||
{ | ||||
"namespace": "data", | ||||
"identifier": "/ietf-system:set-current-datetime/input", | ||||
"sid": "1775" | ||||
}, | ||||
{ | ||||
"namespace": "data", | ||||
"identifier": "/ietf-system:set-current-datetime/input/\ | ||||
current-datetime", | ||||
"sid": "1776" | ||||
}, | ||||
{ | ||||
"namespace": "data", | ||||
"identifier": "/ietf-system:system", | ||||
"sid": "1717" | ||||
}, | ||||
{ | ||||
"namespace": "data", | ||||
"identifier": "/ietf-system:system-restart", | ||||
"sid": "1718" | ||||
}, | ||||
... --> | ||||
</section> | </section> | |||
<section anchor="sid-auto-generation"> | <section anchor="sid-auto-generation"> | |||
<name>SID auto generation</name> | <name>SID Autogeneration</name> | |||
<t>Assignment of SIDs to YANG items <bcp14>SHOULD</bcp14> be automated. | <t>The assignment of SIDs to YANG items <bcp14>SHOULD</bcp14> be automated | |||
. | ||||
The recommended process to assign SIDs is as follows:</t> | The recommended process to assign SIDs is as follows:</t> | |||
<ol spacing="normal" type="1"><li> | <ol spacing="normal" type="1"><li> | |||
<t>A tool extracts the different items defined for a specific YANG mod ule.</t> | <t>A tool extracts the different items defined for a specific YANG mod ule.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The list of items is sorted in alphabetical order, 'namespace' in d escending order, 'identifier' in ascending order. The 'namespace' and 'identifie r' formats are described in the YANG module 'ietf-sid-file' defined in <xref tar get="sid-file-format"/>.</t> | <t>The list of items is sorted in alphabetical order. 'namespace' ent ries are sorted in descending order, and 'identifier' entries are sorted in asce nding order. The 'namespace' and 'identifier' formats are described in the YANG module 'ietf-sid-file' defined in <xref target="sid-file-format"/>.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>SIDs are assigned sequentially from the entry point up to the size of the registered SID range. This approach is recommended to minimize the serial ization overhead, especially when delta between a reference SID and the current SID is used by protocols aiming to reduce message size.</t> | <t>SIDs are assigned sequentially from the entry point up to the size of the registered SID range. This approach is recommended to minimize the serial ization overhead, especially when the delta between a reference SID and the curr ent SID is used by protocols aiming to reduce message size.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If the number of items exceeds the SID range(s) allocated to a YANG module, an extra range is added for subsequent assignments.</t> | <t>If the number of items exceeds the SID range(s) allocated to a YANG module, an extra range is added for subsequent assignments.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The "dependency-revision" should reflect the revision numbers of ea | <t>The 'dependency-revision' list item should reflect the revision num | |||
ch | bers of each | |||
YANG module that the YANG module imports at the moment of the generation.</t> | YANG module that the YANG module imports at the moment of file generation.</t> | |||
</li> | </li> | |||
</ol> | </ol> | |||
<!-- [rfced] Does "early draft" here refer to an early version of the Internet-D | ||||
raft (i.e., the I-D has not yet been adopted by a WG) or a draft of the .sid fil | ||||
e? Please consider specifying for clarity. | ||||
Original: | ||||
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.) | ||||
--> | ||||
<t>When updating a YANG module that is in active use, the existing SID ass ignments are maintained. | <t>When updating a YANG module that is in active use, the existing SID ass ignments are maintained. | |||
(In contrast, when evolving an early draft that has not yet been adopted by a co mmunity of developers, SID assignments are often better done from scratch after a revision.) | (In contrast, when evolving an early draft that has not yet been adopted by a co mmunity 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 seman | If the name of a schema node changes but the data remain structurally and semant | |||
tically similar to what was previously available under an old name, the SID that | ically similar to what was previously available under an old name, the SID that | |||
was used for the old name <bcp14>MAY</bcp14> continue to be used for the new na | was used for the old name <bcp14>MAY</bcp14> continue to be used for the new nam | |||
me. | e. | |||
If the meaning of an item changes, a new SID <bcp14>MAY</bcp14> be assigned to i | If the meaning of an item changes, a new SID <bcp14>MAY</bcp14> be assigned to i | |||
t; this is particularly useful to allow the new SID to identify the new structur | t; this is particularly useful for allowing the new SID to identify the new stru | |||
e or semantics of the item. | cture or semantics of the item. | |||
If the YANG data type changes in a new revision of a published module, | 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 a ided significantly if a new SID is assigned. | such that the resulting CBOR encoding is changed, then implementations will be a ided significantly if a new SID is assigned. | |||
Note that these decisions are generally at the discretion of the YANG module aut hor, who should decide if the benefits of a manual intervention are worth the de viation from automatic assignment.</t> | Note that these decisions are generally at the discretion of the YANG module aut hor, who should decide if the benefits of a manual intervention are worth the de viation from automatic assignment.</t> | |||
<t>In case of an update to an existing ".sid" file, an additional step is needed | <t>In the case of an update to an existing ".sid" file, an additional step is needed | |||
that increments the ".sid" file version number. If there was no version number | that increments the ".sid" file version number. If there was no version number | |||
in the previous version of the ".sid" file, 0 is assumed as the version number | in the previous version of the ".sid" file, 0 is assumed to be the version numbe r | |||
of the old version of the ".sid" file and the version number is 1 for the new | of the old version of the ".sid" file and the version number is 1 for the new | |||
".sid" file. Apart from that, changes of ".sid" files can also be automated usin | ".sid" file. Apart from that, changes to ".sid" files can also be automated usin | |||
g | g | |||
the same method described above, only unassigned YÀNG items are processed at | the same method as that described above, except that in step #3, only unassigned | |||
step #3. Already existing items in the ".sid" file should not be given new SIDs. | YANG items are processed. Already-existing items in the ".sid" file should not | |||
</t> | be given new SIDs. | |||
<!-- [rfced] Appendix B: This sentence did not parse. We updated it | ||||
as follows. If this is incorrect, please provide clarifying text. | ||||
Original (we removed the non-ASCII accent mark over the "A" in "YANG"): | ||||
Apart from | ||||
that, changes of ".sid" files can also be automated using the same | ||||
method described above, only unassigned YÀNG items are processed at | ||||
step #3. | ||||
Currently: | ||||
Apart from that, changes to ".sid" files can also be automated using | ||||
the same method as that described above, except that in step #3, only | ||||
unassigned YANG items are processed. --> | ||||
</t> | ||||
<t>Note that ".sid" file versions are specific to a YANG module revision. For each | <t>Note that ".sid" file versions are specific to a YANG module revision. For each | |||
new YANG module or each new revision of an existing YANG module, the version | new YANG module or each new revision of an existing YANG module, the version | |||
number of the initial ".sid" file should either be 0 or should not be present.</ t> | number of the initial ".sid" file either (1) should be 0 or (2) should not be present.</t> | |||
<t>Note also that RPC or action "input" and "output" YANG items <bcp14>MUS T</bcp14> always be | <t>Note also that RPC or action "input" and "output" YANG items <bcp14>MUS T</bcp14> always be | |||
assigned SID even if they don't contain further YANG items. The reason for this | assigned SIDs even if they don't contain further YANG items. The reason for this | |||
requirement is that other modules can augment the given module and those SIDs | requirement is that other modules can augment the given module and those SIDs | |||
might be necessary.</t> | might be necessary.</t> | |||
</section> | </section> | |||
<section anchor="sid-lifecycle-ex"> | <section anchor="sid-lifecycle-ex"> | |||
<name>".sid" file lifecycle</name> | <name>".sid" File Lifecycle</name> | |||
<t>Before assigning SIDs to their YANG modules, YANG module authors must a cquire a | <t>Before assigning SIDs to their YANG modules, YANG module authors must a cquire a | |||
SID range from a "YANG SID Range Registry". If the YANG module is part of an IET | SID range from a registry of YANG SID ranges. If the YANG module is part of an I | |||
F | ETF | |||
draft or RFC, the SID range need to be acquired from the "IETF YANG SID Range | Internet-Draft or RFC, the SID range needs to be acquired from the "IETF YANG SI | |||
Registry" as defined in <xref target="ietf-iana-sid-range-allocation"/>. For the | D Range" | |||
other YANG | registry as defined in <xref target="ietf-iana-sid-range-allocation"/>. For the | |||
modules, the authors can acquire a SID range from any "YANG SID Range Registry" | other YANG | |||
of | modules, the authors can choose to acquire a SID range from any registry of YANG | |||
their choice.</t> | SID ranges. | |||
<t>Once the SID range is acquired, owners can use it to generate ".sid" fi | ||||
le/s | <!-- [rfced] Appendix C: We found these quoted and capitalized | |||
for their YANG module/s. It is recommended to leave some unallocated SIDs | items confusing. Because they are used generally and appear to | |||
indicate a possible variety of registries other than those to be | ||||
managed by IANA, we updated these sentences accordingly. Please let | ||||
us know any concerns. (For example, could there be future | ||||
non-IANA-managed registries that would share the same names as the | ||||
registries defined by this document?) | ||||
We also see | ||||
* "SID range registry" (Table 1) | ||||
* "the SID range registry" (Section 2.4) | ||||
Original: | ||||
Before assigning SIDs to their YANG modules, YANG module authors must | ||||
acquire a SID range from a "YANG SID Range Registry". | ||||
... | ||||
For the other YANG modules, the authors can acquire a | ||||
SID range from any "YANG SID Range Registry" of their choice. | ||||
Currently: | ||||
Before assigning SIDs to their YANG modules, YANG module authors must | ||||
acquire a SID range from a registry of YANG SID ranges. | ||||
... | ||||
For the other YANG modules, the authors can choose to | ||||
acquire a SID range from any registry of YANG SID ranges. --> | ||||
</t> | ||||
<t>Once the SID range is acquired, owners can use it to generate one or mo | ||||
re ".sid" files for their YANG module or modules. It is recommended to leave so | ||||
me unallocated SIDs | ||||
following the allocated range in each ".sid" file in order to allow better | following the allocated range in each ".sid" file in order to allow better | |||
evolution of the YANG module in the future. Generation of ".sid" files should | evolution of the owners' YANG modules in the future. Generation of ".sid" files should | |||
be performed using an automated tool. Note that ".sid" files can only be | be performed using an automated tool. Note that ".sid" files can only be | |||
generated for YANG modules and not for submodules.</t> | generated for YANG modules and not for submodules.</t> | |||
<section anchor="sid-file-creation"> | <section anchor="sid-file-creation"> | |||
<name>".sid" File Creation</name> | <name>".sid" File Creation</name> | |||
<t>The following activity diagram summarizes the creation of a YANG modu le and its associated ".sid" file.</t> | <t>The following activity diagram summarizes the creation of a YANG modu le and its associated ".sid" file.</t> | |||
<!-- [rfced] Figures 4 and 5: These SVG figures have width or height | ||||
specified, which will make the artwork not scale. Please consider | ||||
whether scaling should be enabled. Scaling will allow the | ||||
figures to be resized when viewed on a mobile device; however, there | ||||
may be aesthetic trade-offs (e.g., a given image may appear too large | ||||
on a desktop screen, or different figures may scale differently based | ||||
on their relative sizes). Please review the HTML and PDF outputs, | ||||
noting that we will need you to update the edited copy of the XML and | ||||
specify the viewBox item where appropriate. | ||||
The warning (one for each figure): | ||||
Warning: Found SVG with width or height specified, which will make | ||||
the artwork not scale. Specify a viewBox only to let the artwork | ||||
scale. --> | ||||
<figure anchor="fig-sid-file-creation"> | <figure anchor="fig-sid-file-creation"> | |||
<name>SID Lifecycle</name> | <name>SID Lifecycle</name> | |||
<artset> | <artset> | |||
<artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="832" width="504" viewBox="0 0 504 832" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px"> | <artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="832" width="504" viewBox="0 0 504 832" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px"> | |||
<path d="M 8,240 L 8,336" fill="none" stroke="black"/> | <path d="M 8,240 L 8,336" fill="none" stroke="black"/> | |||
<path d="M 16,48 L 16,64" fill="none" stroke="black"/> | <path d="M 16,48 L 16,64" fill="none" stroke="black"/> | |||
<path d="M 48,320 L 48,368" fill="none" stroke="black"/> | <path d="M 48,320 L 48,368" fill="none" stroke="black"/> | |||
<path d="M 64,32 L 64,80" fill="none" stroke="black"/> | <path d="M 64,32 L 64,80" fill="none" stroke="black"/> | |||
<path d="M 104,272 L 104,312" fill="none" stroke="black"/> | <path d="M 104,272 L 104,312" fill="none" stroke="black"/> | |||
<path d="M 112,176 L 112,216" fill="none" stroke="black"/> | <path d="M 112,176 L 112,216" fill="none" stroke="black"/> | |||
skipping to change at line 2747 ¶ | skipping to change at line 3539 ¶ | |||
<text x="200" y="244">yes</text> | <text x="200" y="244">yes</text> | |||
<text x="248" y="244">SID</text> | <text x="248" y="244">SID</text> | |||
<text x="288" y="244">range</text> | <text x="288" y="244">range</text> | |||
<text x="104" y="260">application</text> | <text x="104" y="260">application</text> | |||
<text x="160" y="260">?</text> | <text x="160" y="260">?</text> | |||
<text x="284" y="260">registration</text> | <text x="284" y="260">registration</text> | |||
<text x="132" y="292">no</text> | <text x="132" y="292">no</text> | |||
<text x="76" y="340">YANG</text> | <text x="76" y="340">YANG</text> | |||
<text x="124" y="340">module</text> | <text x="124" y="340">module</text> | |||
<text x="240" y="340">SID</text> | <text x="240" y="340">SID</text> | |||
<text x="296" y="340">sub-range</text> | <text x="296" y="340">subrange</text> | |||
<text x="84" y="356">update</text> | <text x="84" y="356">update</text> | |||
<text x="268" y="356">assignment</text> | <text x="268" y="356">assignment</text> | |||
<text x="244" y="436">".sid"</text> | <text x="244" y="436">".sid"</text> | |||
<text x="292" y="436">file</text> | <text x="292" y="436">file</text> | |||
<text x="412" y="436">Rework</text> | <text x="412" y="436">Rework</text> | |||
<text x="460" y="436">YANG</text> | <text x="460" y="436">YANG</text> | |||
<text x="260" y="452">generation</text> | <text x="260" y="452">generation</text> | |||
<text x="436" y="452">module</text> | <text x="436" y="452">module</text> | |||
<text x="344" y="516">yes</text> | <text x="344" y="516">yes</text> | |||
<text x="252" y="532">Work</text> | <text x="252" y="532">Work</text> | |||
skipping to change at line 2783 ¶ | skipping to change at line 3575 ¶ | |||
</artwork> | </artwork> | |||
<artwork type="ascii-art"><![CDATA[ | <artwork type="ascii-art"><![CDATA[ | |||
+---------------+ | +---------------+ | |||
o | Creation of a | | o | Creation of a | | |||
-+- -->| YANG module | | -+- -->| YANG module | | |||
/ \ +------+--------+ | / \ +------+--------+ | |||
| | | | |||
v | v | |||
.-------------. | .-------------. | |||
/ Standardized \ yes | / Standardized \ yes | |||
\ YANG module ? /------------+ | \ YANG module? /------------+ | |||
'-----+-------' | | '-----+-------' | | |||
| no | | | no | | |||
v v | v v | |||
.-------------. +---------------+ | .-------------. +---------------+ | |||
+--> / Constrained \ yes | SID range | | +--> / Constrained \ yes | SID range | | |||
| \ application ? /---->| registration |<--------+ | | \ application? /---->| registration |<--------+ | |||
| '-----+-------' +------+--------+ | | | '-----+-------' +------+--------+ | | |||
| | no | | | | | no | | | |||
| v v | | | v v | | |||
| +---------------+ +---------------+ | | | +---------------+ +---------------+ | | |||
+----+ YANG module | | SID sub-range | | | +----+ YANG module | | SID subrange | | | |||
| update | | assignment |<---------+ | | update | | assignment |<---------+ | |||
+---------------+ +-------+-------+ | | +---------------+ +-------+-------+ | | |||
| | | | | | |||
v | | v | | |||
+---------------+ +------+------+ | +---------------+ +------+------+ | |||
| ".sid" file | | Rework YANG | | | ".sid" file | | Rework YANG | | |||
| generation | | module | | | generation | | module | | |||
+-------+-------+ +-------------+ | +-------+-------+ +-------------+ | |||
| ^ | | ^ | |||
v | | v | | |||
.----------. yes | | .----------. yes | | |||
/ Work in \ ------------+ | / Work in \ ------------+ | |||
\ progress / | \ progress? / | |||
'----+-----' | '----+-----' | |||
| no | | no | |||
v | v | |||
.-------------. | .-------------. | |||
/ RFC \ no | / RFC \ no | |||
\ publication? /--------------+ | \ publication? /--------------+ | |||
'------+------' | | '------+------' | | |||
yes | | | yes | | | |||
v v | v v | |||
+---------------+ +---------------+ | +---------------+ +---------------+ | |||
| IANA | | Third party | | | IANA | | Third-party | | |||
| registration | | registration | | | registration | | registration | | |||
+-------+-------+ +-------+-------+ | +-------+-------+ +-------+-------+ | |||
| | | | | | |||
+------------------------+ | +------------------------+ | |||
v | v | |||
[DONE] | [DONE] | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="sid-file-update"> | <section anchor="sid-file-update"> | |||
<name>".sid" File Update</name> | <name>".sid" File Update</name> | |||
<t>The following Activity diagram summarizes the update of a YANG module and its associated ".sid" file.</t> | <t>The following activity diagram summarizes the update of a YANG module and its associated ".sid" file.</t> | |||
<figure anchor="fig-sid-file-update"> | <figure anchor="fig-sid-file-update"> | |||
<name>YANG and ".sid" file update</name> | <name>YANG and ".sid" File Update</name> | |||
<artset> | <artset> | |||
<artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="672" width="520" viewBox="0 0 520 672" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px"> | <artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="672" width="520" viewBox="0 0 520 672" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px"> | |||
<path d="M 16,48 L 16,64" fill="none" stroke="black"/> | <path d="M 16,48 L 16,64" fill="none" stroke="black"/> | |||
<path d="M 64,32 L 64,112" fill="none" stroke="black"/> | <path d="M 64,32 L 64,112" fill="none" stroke="black"/> | |||
<path d="M 120,112 L 120,152" fill="none" stroke="black"/> | <path d="M 120,112 L 120,152" fill="none" stroke="black"/> | |||
<path d="M 144,208 L 144,576" fill="none" stroke="black"/> | <path d="M 144,208 L 144,576" fill="none" stroke="black"/> | |||
<path d="M 192,32 L 192,112" fill="none" stroke="black"/> | <path d="M 192,32 L 192,112" fill="none" stroke="black"/> | |||
<path d="M 200,368 L 200,448" fill="none" stroke="black"/> | <path d="M 200,368 L 200,448" fill="none" stroke="black"/> | |||
<path d="M 264,192 L 264,232" fill="none" stroke="black"/> | <path d="M 264,192 L 264,232" fill="none" stroke="black"/> | |||
<path d="M 264,288 L 264,360" fill="none" stroke="black"/> | <path d="M 264,288 L 264,360" fill="none" stroke="black"/> | |||
skipping to change at line 2917 ¶ | skipping to change at line 3709 ¶ | |||
<text x="112" y="180">New</text> | <text x="112" y="180">New</text> | |||
<text x="152" y="180">items</text> | <text x="152" y="180">items</text> | |||
<text x="232" y="180">yes</text> | <text x="232" y="180">yes</text> | |||
<text x="128" y="196">created</text> | <text x="128" y="196">created</text> | |||
<text x="176" y="196">?</text> | <text x="176" y="196">?</text> | |||
<text x="172" y="228">no</text> | <text x="172" y="228">no</text> | |||
<text x="232" y="260">SID</text> | <text x="232" y="260">SID</text> | |||
<text x="272" y="260">range</text> | <text x="272" y="260">range</text> | |||
<text x="352" y="260">yes</text> | <text x="352" y="260">yes</text> | |||
<text x="408" y="260">Extra</text> | <text x="408" y="260">Extra</text> | |||
<text x="472" y="260">sub-range</text> | <text x="472" y="260">subrange</text> | |||
<text x="256" y="276">exhausted</text> | <text x="256" y="276">exhausted</text> | |||
<text x="304" y="276">?</text> | <text x="304" y="276">?</text> | |||
<text x="428" y="276">assignment</text> | <text x="428" y="276">assignment</text> | |||
<text x="292" y="308">no</text> | <text x="292" y="308">no</text> | |||
<text x="236" y="388">".sid"</text> | <text x="236" y="388">".sid"</text> | |||
<text x="284" y="388">file</text> | <text x="284" y="388">file</text> | |||
<text x="236" y="404">update</text> | <text x="236" y="404">update</text> | |||
<text x="288" y="404">based</text> | <text x="288" y="404">based</text> | |||
<text x="220" y="420">on</text> | <text x="220" y="420">on</text> | |||
<text x="268" y="420">previous</text> | <text x="268" y="420">previous</text> | |||
skipping to change at line 2953 ¶ | skipping to change at line 3745 ¶ | |||
+---------------+ | +---------------+ | |||
o | Update of the | | o | Update of the | | |||
-+- -->| YANG module | | -+- -->| YANG module | | |||
/ \ | or include(s) | | / \ | or include(s) | | |||
| or import(s) | | | or import(s) | | |||
+------+--------+ | +------+--------+ | |||
| | | | |||
v | v | |||
.-------------. | .-------------. | |||
/ New items \ yes | / New items \ yes | |||
\ created ? /------+ | \ created? /------+ | |||
'------+------' | | '------+------' | | |||
| no v | | no v | |||
| .-------------. +----------------+ | | .-------------. +----------------+ | |||
| / SID range \ yes | Extra sub-range| | | / SID range \ yes | Extra subrange | | |||
| \ exhausted ? /---->| assignment | | | \ exhausted? /---->| assignment | | |||
| '------+------' +-------+--------+ | | '------+------' +-------+--------+ | |||
| | no | | | | no | | |||
| +---------------------+ | | +---------------------+ | |||
| | | | | | |||
| v | | v | |||
| +---------------+ | | +---------------+ | |||
| | ".sid" file | | | | ".sid" file | | |||
| | update based | | | | update based | | |||
| | on previous | | | | on previous | | |||
| | ".sid" file | | | | ".sid" file | | |||
| +-------+-------+ | | +-------+-------+ | |||
| | | | | | |||
| v | | v | |||
| .-------------. +---------------+ | | .-------------. +---------------+ | |||
| / Publicly \ yes | YANG module | | | / Publicly \ yes | YANG module | | |||
| \ available ? /---->| registration | | | \ available? /---->| registration | | |||
| '------+------' +-------+-------+ | | '------+------' +-------+-------+ | |||
| | no | | | | no | | |||
+--------------+---------------------+ | +--------------+---------------------+ | |||
| | | | |||
v | v | |||
[DONE] | [DONE] | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
<!-- [rfced] Figure 5: Does "Update of the YANG module or include(s) | ||||
or import(s)" mean "Update of a YANG module, its include(s), or its | ||||
import(s)", or something else? Please clarify. | ||||
Original: | ||||
... | ||||
| Update of the | | ||||
| YANG module | | ||||
| or include(s) | | ||||
| or import(s) | | ||||
... | ||||
Possibly (we would need you to also update the SVG): | ||||
| Update of a | | ||||
| YANG module, its | | ||||
| include(s), or | | ||||
| its import(s) | --> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="keeping-a-sid-file-in-a-yang-instance-data-file"> | <section anchor="keeping-a-sid-file-in-a-yang-instance-data-file"> | |||
<name>Keeping a SID File in a YANG Instance Data file</name> | <name>Keeping a SID File in a YANG Instance Data File</name> | |||
<t><xref target="RFC9195"/> defines a format for "YANG Instance Data". | <t><xref target="RFC9195"/> defines a format for "YANG instance data". | |||
This essentially leads to an encapsulation of the instance data within | This essentially leads to an encapsulation of the instance data within | |||
some metadata envelope.</t> | some metadata envelope.</t> | |||
<t>If a SID file needs to be stored in a YANG Instance Data file, this | <t>If a SID file needs to be stored in a YANG instance data file, this | |||
can be achieved by embedding the value of the SID file as the value of the | can be achieved by embedding the value of the SID file as the value of the | |||
<tt>content-data</tt> member in the following template, and copying over the | <tt>content-data</tt> member in the following template and copying over the | |||
second-level members as indicated with the angle brackets:</t> | second-level members as indicated with the angle brackets:</t> | |||
<sourcecode type="yang-instance-data"><![CDATA[ | <sourcecode type="yang-instance-data"><![CDATA[ | |||
{ | { | |||
"ietf-yang-instance-data:instance-data-set": { | "ietf-yang-instance-data:instance-data-set": { | |||
"name": "<module-name>@<module-revision>.sid", | "name": "<module-name>@<module-revision>.sid", | |||
"description": ["<description>"], | "description": ["<description>"], | |||
"content-schema": { | "content-schema": { | |||
"module": "ietf-sid-file@2023-10-27" | "module": "ietf-sid-file@2023-10-27" | |||
}, | }, | |||
"content-data": { <replace this object> | "content-data": { <replace this object> | |||
"ietf-sid-file:sid-file" : { | "ietf-sid-file:sid-file" : { | |||
"module-name": ... | "module-name": ... | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
]]></sourcecode> | ]]></sourcecode> | |||
<t><cref anchor="rfced">RFC editor: Please replace the module date by the | ||||
correct | ||||
one for the ietf-sid-file module.</cref></t> | ||||
</section> | </section> | |||
<section numbered="false" anchor="acknowledgments"> | <section numbered="false" anchor="acknowledgments"> | |||
<name>Acknowledgments</name> | <name>Acknowledgments</name> | |||
<t>The authors would like to thank <contact fullname="Andy Bierman"/>, | <t>The authors would like to thank <contact fullname="Andy Bierman"/>, | |||
<contact fullname="Abhinav Somaraju"/>, <contact fullname="Peter van der Stok"/> , <contact fullname="Laurent Toutain"/> and | <contact fullname="Abhinav Somaraju"/>, <contact fullname="Peter van der Stok"/> , <contact fullname="Laurent Toutain"/>, and | |||
<contact fullname="Randy Turner"/> for their help during the development of this document and | <contact fullname="Randy 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. | |||
Special thanks go to the IESG members who supplied very useful | Special thanks go to the IESG members who supplied very useful | |||
comments during the IESG processing phase, in particular to | comments during the IESG processing phase, in particular to | |||
<contact fullname="Benjamin Kaduk"/> and <contact fullname="Rob Wilton"/>, and t o <contact fullname="Francesca Palombini"/> as | <contact fullname="Benjamin Kaduk"/> and <contact fullname="Rob Wilton"/>, and t o <contact fullname="Francesca Palombini"/> as | |||
responsible AD.</t> | responsible AD.</t> | |||
</section> | </section> | |||
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> | <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> | |||
<name>Contributors</name> | <name>Contributors</name> | |||
<contact initials="A." surname="Bierman" fullname="Andy Bierman"> | <contact initials="A." surname="Bierman" fullname="Andy Bierman"> | |||
<organization>YumaWorks</organization> | <organization>YumaWorks</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>685 Cochran St.</street> | <street>685 Cochran St.</street> | |||
<street>Suite #160</street> | <street>Suite #160</street> | |||
<city>Simi Valley</city> | <city>Simi Valley</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>93065</code> | <code>93065</code> | |||
<country>USA</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>andy@yumaworks.com</email> | <email>andy@yumaworks.com</email> | |||
</address> | </address> | |||
</contact> | </contact> | |||
</section> | </section> | |||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA7296XYbR5og+j+fIho6MwRlACTBRRJlu0wtdrNH20h0u922 | ||||
qyYBJMgsAZmozAQpWOI98w73Bfrcc5+k+03uk9xvjSWRCVK2ODxVFglkRnwR | ||||
8cW3L/1+PyqrOJv8LZ7lWXJsqmKZROmioN/Kari7+2h3GE3ycRbP4etJEU+r | ||||
fppU0/44L5J+mU76s7hKyiqq0moGT/x88uoH8258kcxjc1olc5M+S7IqnaZJ | ||||
Ybr85emz7SgukvjYnCwWs3QcV2melQagMG+TeNY/S+eJOYEHTDcuqu3o6vzY | ||||
nGZVUmRJZZ5n52mWJEWanZuzuHxvvs+LcRK9vzo2T5+8fhvBaMemrCbRGMZM | ||||
snJZyqLK5WieliVMVa0WAOjp87Pvo0V6HBl4vEjH8NrWKim34O8qHwd/TJJF | ||||
dQGfHODf5WpeJNPSPVDmRRV+Ms7ni9gfEOZ2n2X5VhRdJtkywbnPi3y5ANgB | ||||
2qqIYWmwCc/fnU2XM1jqZVrk2Rz2r4Qn53E6Oza47d/hAQzy4hzfT6uL5Yg/ | ||||
71+d76zi7Lw/HuVFFMXL6iIvjqO+KXI8mmSSVvC5MWkGwL4cmH+F/yXpbJZU | ||||
VQIf8xG/TOHwZsEXMNOxOSvggzTOKvMqqa7y4n0JhzIe8PYlCazsaG/XvF0m | ||||
ZrI0L5YfkvkoXxKI43wC4/7L8F/M8F+H+HdarY7ND0WcjVbwZ5Gcw6Ecm/+5 | ||||
TEbJmJ5fZlUBjzyNs3gSwyeLC0LOzld7B4e7+w8Odw8PjzrwecJ7MieQB5cK | ||||
8neVwjqAbW9Z/8nAvElm+aVd+Mks+QA4CHiqn9O6T1+emZNqBoOl/4DFeesd | ||||
mgJXm5hZbJ5e/Nf/U8XpeZbAIdJTvOqt/cPDvd0tu+qnSVnmWf9dconPeqt/ | ||||
UiRVzB/Z9X8PWzRO3DpjhXCwQAi/S+dVP7agDabF+lJ5aaeX8WqWw7qqwi3s | ||||
hzw/nyXm3VVa/Z4UM7x+P8xH/+wt8AnMPylhb7P3CWJnWSZmb2/XLu7h7q47 | ||||
z39fwiW68FZkP7Dr8aZyi0oJtgWB9t05wSSnxrA/jYuySjLzJC/mcZYp9D9m | ||||
6WVSlGn1X/9vhZsHt8Sc/fupB/2bvKym8fjC7O/vHhzsWkCf9YcP9w8fyUs+ | ||||
fD8kOMXKR7iDR/2D4V5/uPewf7T/aLjnYd04HuXfVb+ndBEtuHh9Yrg/b/Hf | ||||
YgKHrRC/w6ObwQTmXT6troACmp/wGnl4PC6+wqv9XamPDsZxw4VA2gYoPlpW | ||||
fL0Ff7PJyjxJaQ0658/LeayTyL7Ab31z9PAQSM74okBoqgF9tvVumVaJubd3 | ||||
5OHru3Semn+N4V75V/XpiUPwR/u7R4dbPpQ/vjvxcBag+m4FYBDJoJONogzP | ||||
soIDRGjefv90/+jhQ/n16NGjPfz1ydM3e7u7x/jRg73hLn/54NEhfIQkzv69 | ||||
x3/3/847DR8+3D2Ah4qx/DU8fHRsvG8fwPim/BCl2bQGxdHucFd/HR7sya8P | ||||
hsMD9+tDpLSWVMvH+3sP5ImHe8Mj/XXfDgG/7rtfD+yvR/bZg90HcGkv89ll | ||||
sj7mg0fDYzMCfvgePjjtPxs4/gvbmSJE83TtK9qVWToqYjwT/y//0ThL53Hf | ||||
W1L/Ml/CjS+CdeqHDNCj4eGBjEiMxtDvwHhBhjhHoAGbjv3P6KMqLs7xWl5U | ||||
1aI83tnxvhdWBs94MsRT790JiBjHZhrPStyeN/j9ceOgzA0Ry3bmo78fHB09 | ||||
3FkIutjRTzKTfACKUqYjIH8012U8S2GOvCAhBBYOpAXkDWAUZrECJprR+8pP | ||||
Df3YCw8yCjz35O+A37MlUbY6wLjbIyZf/WpYFed9oOHJtJ9OQKKS34CC9Psm | ||||
HuGWj6so2iBHlZ4gZZCMnM/yEVzRlVlmxKOO9vujtIK/SmQyE1hGlZzje8sS | ||||
/qpyk05orBWvHm79vOyZGEQwMwfUUfnFzBNYcNsLprqIKyCCmRklPDDcJ5NM | ||||
p+k4TbLxirYSNsZDI5N4Eo3pAioZvFLbg+jsIi0NSJlL/Ar2ZAqP4wyJKWED | ||||
YOoxAIh/IgXC4VBk7NEUwJVglfTeosjHwF/hzXxqdItKggulPZCgsvgcwKCv | ||||
5vlkOUtKmDsHuGLEBZwgnS9myBcqmgIHgk+B79mxEQ4fWDjj3EIcm2kKAzFl | ||||
sdu9QEZVVgTuYjmapeWFgK3AIJwDIIzRL38Fcbxalr95vzLGnV0gEAAKzEmc | ||||
D6Dr/n//+/8eHmwbgAfPGJgGzRdPJvBgKRsGdDhDafn0+bsf8Ghp9weMb/N0 | ||||
MpklUXQPBewCdmSMq46idzmI4Lx2OW1eIZ0oQfzxo9Dj62uY4x/LtOD9gzXj | ||||
i3EkuCiYA2g7iE4BV/LqQgVIFHqn6fmST9O8KXKQtfOZ6b56fvb09avvt3kS | ||||
pMUwCakHIBnjN/wFEvrr654ckJuopEthDxKAXpa4AXhf+bzhsuRXLccNVxev | ||||
AfDf9UXX0HkCUhwghewFYLKA6T+TibDc+7zLBScquzqR26HvuXX24PYBY55s | ||||
1LkA9xXDTBf+KHHFK/oTVlNDZYD9CqQ92hmUMYBOIiTjWRIX2z38FW52PrE7 | ||||
GreRGoQZ5GIQHmRjYZmtVIlOo+S7Cs8BOYGLmi6WqFhOeNOSuEwBahhoAZ/i | ||||
9RL6M0/PLyoDSJUUV2mJovj4vTk6CGeKC2ALsN/pWODKSyIRscFVwH3Fp+Fv | ||||
kIbOE1xlllcG34UtHKPGcw5CAu9Kmf5uL4a7WiWcTAJXCgef5rgc/JRPknBR | ||||
z0w3Dtd6HEX35ZsqTUr8i3Avgw0G6vgqRxaSZuPZcoKvALbA+vhLxcvRCgEB | ||||
8rBVjI+JIeMIW4CQ/WIsyLhVfjgGbISbvSwS+qr8AF8JCwRMHWzj1LAYmJDJ | ||||
3GSJeArHgkT6zdNyWwltPk7pTNJssay68nm+rPgvHCYeO2X+Vi/AVtMut7wm | ||||
MhrSpPsB3aZHp0mMq4K9OyVEXcDBpkzJATdKJGILoSolU6YMsChGfbxMKj1H | ||||
S4rxVHpIvCPQs5Aw0B/eEHgjQVbAuwKIKmQqoFKz9H2Ce4wiGfyJpwOUICsX | ||||
eeFIjLcOxnrGYuSjWZYgmwEpbWBeI1a72SN+KkuYyMPTzLRyY2fg++ztGi9A | ||||
VuMNVSR8ueDlSVqOc2AoK9iVMfKlwBZBoL5kUF+w+IjL88XJ62vAfFpGkyyi | ||||
t3xgzEnAvU25KolWiVgC1CgvUPuu8uh8GcOSqoRYSlrIWMBgYRg7Ew8G4hO9 | ||||
O5rl4/elUsQO0je6zmVnEL0GLZqIcjqhxzvAWGHrOj03mMWBBelPcMKzFTAs | ||||
psXCGvnCwQVNrmDyy7SU44xplyI5UBptIpy4IipYEqrxXDOQ40FP0/mEuCMV | ||||
hnNYlrITRPQmSQUqFP758WM++nsyRl2lpO0+cUKPjgyzhfxjWS7pIEBszed0 | ||||
2nEZBbN8/Ij2O/y+f56g5QLPBTnq1UWKqECSjbxQ8nUax/BrBEyiICoNM9AJ | ||||
F5dIxvAGz+MVoeYCkG1R4DUGcHmiWTpNxitgJnAx4NvLFEmZt1LYnRHQhjU5 | ||||
T2UvvTqRTwI8akFClLlZnCPeSsOvegIaSm19vjUAnJPmyDYKanyjWFdWCLsn | ||||
1EUixrUKm0yX9AYj3wPCJzQAyRNCfHry6gSEg/EF8MByDqwlGTPnqLPrQRQM | ||||
PQbEqhhFcyYcqJgkZTCN3AnhQnY6eQR3yM5cmss0Ni+T87j/ll/qlgnStjl+ | ||||
ROP0dRuvr7cfmytgsilzSfeWN3RPWFgNOtjCaZEQHZvHQDyXC7n0+ZUHDeL8 | ||||
PAeY+e0lCeJOxMdRaMQxSA0FUp8yQRMqDJqPALcyEEhVgCIRBpc/Fdmoj4Zj | ||||
S9VQpcU7dsKIWKUsCV+BDAEvoRhX5SCk4svuZnUGgEUdxhJ3leAWRvElYDah | ||||
I1BWBFG5Tr5Isn6ZL4sxEWa83qzZAiT0L130e/fMGVCkNMtBF2adCgQD4Ygo | ||||
brxPVgYEzElpOi9/fHcGNI3+Na9e0+9vn//PH0/fPn+Gv7/755MXL+wvkTzx | ||||
7p9f//jimfvNvfn09cuXz18945fhUxN8FHVenvzcYR2s8/rN2enrVycvOg1C | ||||
ZZEIuyJCASqMkqKkHBfpiDH7ydM3//kfewew9n8CZjrc23sE95D/eLj34AD+ | ||||
QMGUZyMmzn/CRq4ioDUgn+IogGxAoRYgdM5YoS0vEIuQWsFe3v8Fd+a3Y/P1 | ||||
aLzYO/hWPsAFBx/qngUf0p6tf7L2Mm9iw0cN09jdDD6v7XQI78nPwd+6796H | ||||
X/9lBsTL9Pce/uXbqC6SwgGISOqpNp4qd+xkOPhFxCv4jYlMTVyDP0E6hP+W | ||||
rHqgbOr+Qmsj/rUcycvM6YSeCbUhFoPXvlTFsVqDV3CfxWVgbscoSXhTIlKo | ||||
HL1iNQvn66HqE+sa7Hod5VPqmczwkxnc/SUQ7IEVNG9yYplAm9pGkzTzdPIw | ||||
kNSzbnCZpNMpYCPcC49Zd8fTAZzCu4Q23uwPhrgTYmkD2upgekUmpzPUy9Bp | ||||
BXDfagaAaG2O/bU57pnXVspgxEG5sEiJWFoBRA8Jd8CzveDFbBHvQKBDR5wV | ||||
DpkQAP0r4lE6g0PDIZ2QTTwygX3NV0zcVTKMYJlovwBpkPgZSwtOX3eKukhV | ||||
DmZQDJBFJgXxAtGs2QyVi2JXecDgtCDkIDWPmQ2UsPHMC1A3BD43YRdkzOOj | ||||
6XbpGYxCOUW2S3RBz1BTLhcotiNzm0xSfB92x4l6ov0lhPok1CjuTpLLBJ0m | ||||
hZM/VaEgwaIkgktspkjP0yxG3oVGebokxLwsUAveFRo6F62ahhrgxY/fsyqL | ||||
KvjKskwHQOnxWBZ/PFCZWYfP8kV0ljm9r4aFStZng/UhpPKM6OaEQEnJKqJg | ||||
oW6NAvE+SRZ0QpmPpoiic9EP8QliEcCUu8PB4ABkpyrZ5tNHZ0c8QaOD4+C6 | ||||
bbHvtqahrvLlDEQv4PxT2Kppkc/xwTmM0oJFjN8K82UMKoLYR/BekT0B740x | ||||
03iMaIn4jqoJe7BnKA2Lqh1s+Hw5q1JU9dSqQOZHlrVNCWI62atYO2bckw2P | ||||
1xQKPn3YabVxoPiPshxdEhH01l+D52RIawpO2SCrRANuKt5YK+GKCRnENdhs | ||||
3hfUi7xVXcZFmi9xaPGboSiXZ3R9CaOIpghz0+trSCBFCnERX+Io+NIMhA9f | ||||
PxYaEoqkvDb24wux8bQQuKw/0ZmS5Iz7jSIggK6bpXZXooWpbvc50tLMoj3p | ||||
CH1lSkIoem6lejg5UsSuaOY9xSMRSiMrlFp+Jl4TlWbFwQL0PVKtQ7GB8NFO | ||||
ozpTA1VHxowQKzUrq3RG+01qjtxUUkiMeeauOpyDL+LCAKwRgqpXrGqmHKRX | ||||
DXYNRFiSm3H9kUVpFLuzfA77NAN+LzYfok1zuvDk+h/TQU6SBRLbTKVu2vae | ||||
XEpeCFzYikgcYzQeE4qRuBHZcj4CvODbqPrcaBXhycNiX48uUwGCRF5VUy/I | ||||
kyIvI2uLcUS0J7NFIOKh9NacvlGDPWLAaCkuBRiQrDKWn6s2ML5AlJwFzPqk | ||||
Zj8g1dez6Pca+A9AWTPWRF01mW47u00UvVORbWaXOk9iIX3Im+5bUMze/fum | ||||
i1L19nEEglqcrdrsvmRNTvHiRcvMml9o60S4SuH2oaEGr9aCNu/5v508PXvx | ||||
M/BsQXc06aN9Z7bie4GGMOKjTIO9gZW16aB4oAtiECmqInQPByKj8l1ASApY | ||||
+SKVg4pZ1rDGVI+IiwWGbX1oWiPyj0tlG5DdaNw4eAF1U7sAoRCIGckHIBo4 | ||||
oCqpzpXFc4uJjtTWf3v5InDDYFgFffEv716/st+gVVKkqSqfxCsxUyOxdCAo | ||||
Y1WCBESxZCLhqXKsfdE7gOJRLBT1g4p6ACkvBx9zDEjdhECGE7VisyfmNIP3 | ||||
4gl5XXBiZYcEW6WIbpFOTLaefIRmgChFeUB2xlzFK7ub9i57b8hu9hHFmPFE | ||||
8fgiBbKFp38CcJRpQejhhMe0EdOHiOms2hGuI6p7+5mpaIjkEylCnvnU1SFb | ||||
cJX2BujnA9QCqQQlCjyTUeKjijI1vs8yVjQc+M94L9OmW6kgfAnxoEz83UH6 | ||||
AHemQjZGmwDLQL4MZCkZx7gSbxZ8GKaI1GKNstIoBx6HIMotdqyEkUeHQewo | ||||
EjFOMi139J3t3BO4ehMWZ2kQJzFaScptt+xK5HFswKVuh8zx5UW6UK5uMhy8 | ||||
A+oO+lcYVeBwZmhaikvGM4FphQevTD2Z9OiExWGUj4g3FdEVshDBbLI2Ih0n | ||||
hxeO7GELDsYbi0f/Wk0YtXtCIwHiICX0uBxqJ8Cmg9UBPBE6INXSpDBNmE+I | ||||
zd4qJj11GqMiEFoOOe5EzXuqIe7t4WUhKQJNwu6Lg8HwAX3F75HuyBRFOZOH | ||||
UWj8xsWM8ks2jaNPW2SsxHrx4ItojVmnpYMe1vTP+RXc0qLHgqgVHYrECSQx | ||||
c8zpbJlOeCLGOqSsoaRqrfzWdm4lKEZutaYy1pAai0J3ZOnDAD3ybLnHe0Y2 | ||||
KYwzJQxFD4GV6SxHJ8fSPCnOyRntORGILFnSXwp70viEgOrsB/xVRWpPoHBq | ||||
d21DEXtFi3KYQDEHgC3vVH196iRr3LlnoOUCSoWyxm3dOCZw43hOHBRdWcU4 | ||||
C+Q9q6jgCbtbmPn26S4Z/S/zdBL5cjxKP7OcjAysR6aV42lyZNueFOScR9EN | ||||
ziPn2mr2Ef0fcRLhGb1RizkGQuSI/B/vicrSx6jP8jrCCAuLyJ5krqIpSL4J | ||||
sT3cLlRHamIq+aH1RqLHDB8CIIWie1QDeNXH40uSjK91URSVmMMWFoibZD+6 | ||||
ypwK773dM+kgGfRsnAG/hWooqWNpFV79AN/YhKEzuLdrlgK6xghez5kcyRuG | ||||
N1GUAYMBNdP0Q+LIEId4zOcwEaAzXPKuf8tjG5RBu7VC17nMVySgiGDQLYF2 | ||||
onA6XXtGrE0tQrnCCbOQc5RjPFgiMaaTk/IczzqmmwzOYatI23SRTDzONorJ | ||||
y0wf1md5bZv1QZjyFa4IKKcFXf0xRErpMwndQLdJjCp17DxncoQksDtyCgJz | ||||
Xkwsm/avKNnqDe/F6rFE7QRzqwoIgywLb48IjUqaiuJYiV6wXjmwB4Ab2bD1 | ||||
KCJ6NuF4inF9bK8Sw5Zaa9TIbQKk8gxU7ohVdhOJVA0HCD+drXBUvNvo0hIT | ||||
Y+xsfHRfIyuo1rRuVSQF2crgsnkyZNN6+aty3b5GCqsTR+IUHQEVrFbMI8TB | ||||
akJqweEDGERtB/G/LuUKoSWXpZSVk85Q+nab10CNHpsL5umYZbHuG7AuYpwR | ||||
PWu8tWxJjpHNnIMu9TugzAWQRJyNibWE8TgDjNKKUNRiPAzkVICXKJ3nKNUj | ||||
WuHdBDhReA1Mjk373D3NGhZE97JA/ErZtaxqJM3pvKqlRE5OUlg+OtgdOI8l | ||||
wAP3HekRiNDJJQYokYdrW5Z/K0oUohxtLX5E5KhnYwesKQyvMbMxPQ3ZbHpB | ||||
d9i7it7tc5ZmPlHhkGt4JizShLhGE1jSAFriJERBimqDqWYJGlHZdQwPBDbN | ||||
Et0bz5aFKpi+aUS5LnOjCeHMKLDl06bmjH8RfmBFNb34DnprzEaRlMmAKNxO | ||||
swSZjKXTdTkXUYN9luSXo1n7Mgv5gz8R6zfhzyeSDVbmhp9P8Haw6fp2eEXt | ||||
F81vB7drBW934zXjUx31t93bFjnDuWuft8xNiOWv20e4boaePkTb7frbH4/N | ||||
vWAvORb8mw7LUXjfRLo6BpG3JAb/HBENT6lzLdSeUrWIVE4FHyj2Q0ZcLKvS | ||||
F0DcbpIVKI4sQ7UCKrJ7sT6wvcLTm+KUrDBuP1n7irqx6WACW3+PXPanz/rn | ||||
S/LQdcyaGAZY32VbdYyDFCK1iIINM+YFBkWyXMRKtsejWBTNKJNuOktBBCBC | ||||
5ewiQ6Fo1lQ5S6uKzjIuWW6Y5OgOSOmCRUzCSfKdXcWrkBw0bhzN575BAndG | ||||
pvXSqYiyLxSmGsqrNYMgCdpk3JtEdPvgNn1PwXFyma3CZheV5Y7aGcdClJRi | ||||
bBAK/lFsaZy7WxpFquE7KuIBNEvmbxfy2gWcBiZQLvIKh0f9Gels664j4U3n | ||||
KcW59Grqps9me/6msiSOwVlqFYouEgxsYombzhpHYnvTBv/aXIVMMeVEACwF | ||||
3cK/1j/DQZMcSFp6gUEY1cNcm8mCHAGLgtVVzuFlpsvxZ1dCRhFBDeH8vqB8 | ||||
PpqlZHtXpI88pO+t0RS8nnzXKslySCYppnv0MLJXuHjEjCYek+iFNzY8ULYe | ||||
40BFwr6qMdoyM/VZUOjnbBXBp+k4cWFYTcAAEFcJmtXm8Qc4yt+VL9EQ6UWe | ||||
T3BbmTSEznc8/dNA0fGEVcSo+qmy/UH1Fz3JiE5ylQCSCB1C9nSekVu9hshs | ||||
pPVVlBkabYmmsSze02BPkYfrssUoIWap1x1FGxDxK7QXAuGJunS2QznbGDGo | ||||
s71GDQCA5yrA5egSwTEt1JNALnauzjFZQimwjLHMeXMRszNya/ervI+oDFSp | ||||
Zxi7MfYtNj8lI74LUxffLSQArbtsM6zt1zzFlCrED6sOiFIkNCKSMHORjjxf | ||||
vLdpsNpTT/oIeS6Kot6YnsYrYRhsdrDGr8Ycmajrx5Yn7vKiGWdbbXV0umvE | ||||
DQEI2QeCk7FIS+q7d/yMgSK4UqxOdilpAdGU3DxBiOZoeV6KbOlkvLhCp5WE | ||||
KFidIs0CtaKLKA44LXA7l6eYkoHv0o30RPbASsN2ob4186BiGJXjIq6AGHU7 | ||||
mAWR9cm702HFu/REQR/fSaOMUTMiIhW5GRBbRkDjehKJbikrAmLhwj/ERUKh | ||||
y27BGPo/BsqfTOzh4G7XL5xEnI2SqPa4Uh7TZTl2nCx40xNGg7jSiHFZlh/H | ||||
IqZXXA0yHA70xT1GFp5M8yKxpzwBRXJ70BjyNckTJkbTZcHhISw7ojIohJkd | ||||
YJIWoS4vd9Vr8n9ehJJlaq89hRhVyeNIaBgRO6sBedKW3EFkTwuJ3aR4KD+s | ||||
00YvG/PxXhjOLPZ0Uus0jkzgZQSk8CT24DF/sYFoqHCLmkHxqRWmL0QuGIqY | ||||
bVOmQa8xGYpu/NPXGD5IX0gewvbAnPg2fxvhDAymiAvkM6XmPvW8nJOxn6DV | ||||
E6WFHoowL6QXpHsEmRywfS+tR8w31uPJh8Z1m2kEAPi5tX6UzSAcSEJG1lO8 | ||||
mlIy8iJq3Cr1pJFXSEOynauJouwFvXuS++m8sT4kvn+KzblpEeYYmtMsslbx | ||||
SS4XjcwK4qubpgUKtRKr7BF9oSWW9ktEBtuO+BEHN6CxRB8nFhwOMWQcC+Ei | ||||
X2Pk0w1cTYVeqVHC0e0s//n3YIAFNzQ/Bi1bF5RJl+qdQ1FIHKo9s0ClHCnG | ||||
lJdeywPoJx9Iqf0cC7pi8Oda0H/ivDZHnsxkKSKE4yA0C86rF9DzfQPpsCRP | ||||
UnRszDqJNiWrTd5+kl9sRa+dA1vCgKdz3BZaFXrZWcWZFDEo/BNnnmgESVMR | ||||
BuK2bZmTNmYeF++d2Z7TSHGkzjLT1JeozEPjFq4Mk8DQ3aNygxcEY8NsRqzg | ||||
iQ+Z2Wgt5lSDc4GF7QBJuzDIM4uGDbfHktSYBJLSySVG8fC1RLtP7J8GYmlU | ||||
E23IXduycFn2QK1AZLNOc4k9cNtNjlZKDhAezpkdsNK6LQ+0FYzWiimG1Ilq | ||||
xCv4UkeUyTjxZU7RdDGsi2OOyEIklDCufFCOTXcPxLCoY0HouAmsglv3GtYl | ||||
ARQzItGn6qiVTKcY/CUUCKMhVXJCs35EcgIw3u4Q0/YQd5ogYaMzOlWQjNvw | ||||
N0W0qAYQ3Pa3vjdHds5ntF5GDx29f+vRzb0Q+wRIlSQFY0Iz0eiv/6nfB/16 | ||||
PDD9/reBIxLuCmU3rgUej5LqKkkym8lLiJ+zfxHwlRkQ0Ejnf/TSrWz6aEBT | ||||
n9m74IUAssWF1O6J970XhqxqQODrsrlF44bdYoMK0WO6gvF5EZON1pMp+Nbi | ||||
WlOU3+r0mC4QykCwF5EdAS2PwPb7NjGK+DWlhrmssTUi/hy9BBSYGB4ZQCcA | ||||
oaQKLBtwzoY8dtmFJXHOk8hmC+AX6FJeYCUF5L9EA300eXnyM9IiK0tMhZFf | ||||
IcOX94T5kRWBWDyniJ2gPcEZpTmnXoQRFdptjn0+jeoYSlkjo6T+Ks6tb4mc | ||||
PWAnpewfj4W6uPdkww2w4jsSKbS8u4TrzCUdRUhF2BxQY5bqN+LkOkbXC1K8 | ||||
UrQvkReUc8LszlqBI9LFBcx1y11hdlJssUju5ZCspdEpowLRroid592WiqAk | ||||
XIwIqGoEghA6s1mraunjM3WubAxXUeRV9I9qmMvvbMTbUMqXFD8R8f31RJH3 | ||||
nLeUlvoOQaiVbqO9+5GX/cGJ6MJdAlpCac1qJnRJMdZzdBxF/xf8UKkVSrcR | ||||
37yh0i66gIhr/4izST/lohJfYQ0IeqlP5gPvBwflnHJXcaD+jmLcX+Qd/bvp | ||||
FbufgvjyTv3jja8yQ9fZEhBNRFuzj3JSGbGIv3iL4WQZ7ykOjBmv7BLum1+8 | ||||
jfgtYv9C2wa1bs6nxv25aW/qtwuASbCWUn+RA8sKgPE+l+3zv6XyBO5nCU8d | ||||
HdhpEN9gaBsa4dWS+E2q2vAoG7dZHnKjbHjITUDgZLWvAXr/kGAtiM/oroln | ||||
sCHfdGbJtOqos4auBuI5kY8Ax9lH41+SJm2X5Ex7E5Su4Ps9lxWalpGjukA2 | ||||
JJiWCkwBIXH5YwUpgA15dHtIV04rZrMJR6IjsIQvaOtcfwurXon27h61oPZR | ||||
O66/goWsiIBhGZ3nk8Gxcnehk0RvrJPRWgnJQJAvVgVJJMA1xYDDhkMU/3lX | ||||
QE9HAmTpi4ZZBNtuPkrxJ729Zm+w91jKzjFydJZFdowvHWMY/Lw8/jCfHWcl | ||||
XZ7j8Awf24AcRIXHSLdYXFjbvo+ERPIsfv444ismG246uClUSgwj2jCah/Dh | ||||
GVpgznCIAc123TRFuO3BVOWHxom4ppib4Z3FseeuyoZMyJXZrAuEhutQTM/T | ||||
XCrCIYL9gL7GDu0BydXjip/86Qc0Sh/Dr19rzSu0x2DRqPdJMdDCkDtX5ztY | ||||
BWzn24jvG7z3AlgUvPg11mWr8uOgkKQ+9pzqBuLwDWUggx8dZnPtxfVxa1Xq | ||||
GsdcrxnXMM5atcbmob6DjZkN0nx9hHpRxMb3W6oTfstH43EbPh53s7rjbTPc | ||||
He5zvNYZFlO1ajXKC2g188rCUHSVMb6diU1jE3Q9osBKw2JMkI3ypRfeJkHI | ||||
gibsYEQ8J95Q2DVozwVnyGAMIDkUmftYKxhcb0+7TUvONqtQiF4si3IZU80T | ||||
dimA5Ebp6pSgZoyYX8aA6YlE9YouSOSK/Qdvxebx5N0zwER+tkwYqxEwAAkz | ||||
CG2M8Vi3wO3fVmleJOeg+b1R00epezBjozGIWfT4M7ETyPddvSpU0zZJ3DUR | ||||
qPsYp7atW0pG60A8T8u6FqqZ/Hj9/w1+ahNdXV0Nium4z3U4aSqcYgc+w6e3 | ||||
H5P0SvsCA4BilMymdiso5N7MaKloVB1TFLCA5mf8b6GsvtXjfzG/HH/X7HX8 | ||||
nVLU7S88hDzGOob7zb1uM8/xz1oy+laPB9kC7WuLkWFLc9C3PiP3nwapFwAw | ||||
ewdcFA7T/7f5V0z+327M/beotzK3LQDgTvdmwSAxKO2zsK+vkoprPw4NHppN | ||||
pBYFDJrjtyRR2xOFvPJNNaMmxjbzW0Ce4aovcvZ6kXQF2sFlPFsmYdmv02cD | ||||
JkZW2ESy09/b7Q8fCPeqkynkOKwK2peYPXmcTR/8RTH8t1uWdnZ8Dnk1LLVJ | ||||
8hXA8Andn48y4wJ9fUVmtn7Z7T/67ePBdZ9/GbpfthjW67bFvU1EMy85Z4vI | ||||
4c/w03/5sv/smSh5g3VINygjPsQoVu8PH99iesQMj5LEDnuaZ6/PcnRg94Vt | ||||
/Z3dweDRcLi//2C4u3/08PDgwYPDh7sPOjfsyIaju8ODZztwH4s09MkOfOOp | ||||
Wza8tfNL3P/9pP/vf/tNfoGz/7X/t8Fv949bv9kyX7kBuu0jdNuH2P7L9v2b | ||||
0OvEX5ihhbFjOx6VGMeXhFZwfKim8xnfeiI2YXrn5Mmr70mxsGP1vbnSiVA9 | ||||
8dwaL1nfS8qSPAybW6dB7krGJBCJD8AFfFEKLZfiC+0NpOgc68smZzaEqtk8 | ||||
B6mmW+WL/gztytuugJ3NKpRYLxtIqj9WQ+j/YwnKHglBeC8H3jQnmHDlrET+ | ||||
hurwtx7XGgjpOAINTN3r3igcusNGs4q4PQKg1UZYiqPaH4kMztkv9RGwJOHA | ||||
vEIDNEgCY8p84gA42FqQ4druHlVGfXS426OdJswAxYqVi5daseSFeJof66wq | ||||
PB0NDo/1ur7C5Z5a7HvsLqlfFtAECh3+UGiKMwCjhxbomX3ZhkLWXvRuC94T | ||||
+xgngSq/FKanQqLeiULppmrY7Evx+XLsc2Vme8aNs76M9dtL9/eqQJGh8N5k | ||||
V1h+zhEi1r3ib5IdwJZOJHdT6W5vmB6MyElJtHEpcXVqgsIfvwxIzZXtFYqK | ||||
Qxe8fRtn4vJjaCsl4mMjF4Crs6PeK8jF2YqKb5uOl+le8yHbB9vlivqZ+xKW | ||||
fVsX5u29rqwIeectMWCWxNPATKfnT6ymyVinGzFHpyqFHWPy3uNNaPMqdjVx | ||||
A6HN+asEb4Aa1Pi87GgIqRXYAmgbpKWNYL31XOS3Bs2+zpH8+hcxBgJRAgat | ||||
h2OKwbAWYMIv8bk6nHQUtQZH0x7URa1wEzYIYm4zpvFyVpndjbvzWr2FNCnH | ||||
7UpIbiiduTw4n5+4Y/R+Ly0L0JeZQ40pKsG+a0365CrkErL+4VjRm7edAXBv | ||||
oyMaA9/M70mR27K8HJjMPpumwUycTTwag56nkhxBcJq5pNNrKKcsWfIBkeou | ||||
sYihvs12RJsc6/QeqQ4pBZ8BQ/AYMPk/ubIvi5eG8pStZ1MfxFAtcgImBZCs | ||||
eCN6iA8/wA7P2Gy/MGyDNp6X2v+uGT0YR86CC0u83BvkF6nP/1tP3NykfNXs | ||||
RTFq5O/7adaHhZ9T8W0M7oDPwgvmXTMJJqGDTSuMC8P4r4wzPAMIJCvG//FK | ||||
nNEAuVbA8JZBRgX/gsqxupHX4UrMFjoJtjiaBl2sQqbJ75BKMLcNrai9z9op | ||||
HPCWuv+3HMsxKlG7s/oCJ2WH6ElE5y22bbC+ULGfNK527agFJW+72usawbIQ | ||||
/jnC5YJbmglWw6XypbOQ3JIusBGe74uEXaFYuDxuqKGEMGnwmdLMU8vXJQJC | ||||
HP3eGXrVMqmuJpFWiiLAcp/2dRXIsSRKfWl4gg0ePbtENJh1POlApYaWlZ42 | ||||
Ls2OStqVF6xll2JH8JaEef1oNAoKtGnWp41idkqrB+WWjZUYOIBbBZ1biDpt | ||||
F6tNsOl5m0po7gPX8waYEhVCnmA3yUeP1GX6uPtx3bCgtYO7WSJqE+Ba17pB | ||||
Wqqt13srXPnN6/VebVu5j7t172+IuJ7Dt7Pxhtq6lDQIFVvXKI+gwIWinXU+ | ||||
2CFGqxoGkn23djpb1oyAPVCsfupFrFIoq4t5YzpJmVd2Jd4OqSw1i5veYllS | ||||
C/N7r3V9R/hX7Pjum73twUbgSq+e8ojCYNZ235/E8gXMLp7Fi/pN9GGoIS15 | ||||
MG9Axhf5FaayWRDDSoNeMoiHPP70tOjavGw1/MP345UVg73iyrcAq47TyFxD | ||||
PG6KOnD6KOcPdTDAZjN1Jhs87bvTb9NSmYBTNmv2eDtA7MqiNljmyQDvDOui | ||||
EMHY9n1CCWVjsZ2GIbLZ8m4OZ+Vz59R6Extv4Bp3cDexho41WXmztMwimISN | ||||
BvKX3L3dx8GHgWmH9oVQ1kVGYqDSCF0fTgSL6xKi9yMyDCWluEE0DJLUpfaX | ||||
HTJRyITrMeMLYL68qcrBhvXu/dH1+tHkcTvMjRUQXJkal7h0wyJytAxjHcum | ||||
RQw/cxGc5Yrlr7jdFRY9aV8Cd9ng1LPEi5QFLdOPkG0fQJOVCNi2dbrfVGTm | ||||
fbmReJ05sRiQYTZxFsdmcdXW/PUB1qYgdkGgLn+v99rq9HYRPa5zgSKrP4pk | ||||
VUpZqHpVQsFC6iFAWVz+qxRFaIta4gvucT37No7g7sXnEAGhQ59HBGqH3MEY | ||||
Bc+NaSN5bU06NRhgcZDay1IXuk4PC7eeG+6Elv/+zIvdtAY7FMPd4CdgmlPV | ||||
aZtdcX2xbsg1N5D+3HadWs38865+0zJ1pC+3Sh3xTy+SzOhNK9y/9QqREri7 | ||||
QGLLbOa1V+qF4cu116mE+C2IU6s2xdP6KgbJAszcyPbjSQ1td3nN94w/LONl | ||||
9Wt8C+VP5dKaT/bx7Vf2bk1cunGFwdFWVDjJfXKqMU5+pMOWPbYtIeIwmkg+ | ||||
gda5Jfi2RVawLb1jW5wbpKGdOACKbN6LauOJue2jQO8WxVLhH4WUGnD5cDZB | ||||
swaDdyq+8gjn0y77TzaqHJ8p9zsdpBay/hlnu6YO4P+vm0N6OTgNw9v6lLNV | ||||
lN90ENDgG9zgbzpBkOh3LrhlgKgeBgc3xahiaPA99I2CgAYk+Km0geK80qil | ||||
8yQb2GlX8+Amasg/98FjimJrx9W6EPjFeaUjAY7qjUZ1jbXDJdcvWXAtJi2/ | ||||
zO5m9l1HWkp7GlIRESA5uG0i+E8pg7roIi3fSxJSlI+xuFo6pYCFqqK4UZJV | ||||
pJCErz1hDmxLGxwWXJMPIBCRgcEvZcZOEsq6GVEys6Q8U7yTrTNgKzv0VJNb | ||||
/xIPJfK6hoYlxjkHlOMKUThCYUvCeR0YlMXPYZVUdeBSS8dh1T2qqpeyxtj0 | ||||
jK24FzX3Do2e8pktuUyxm9UmwwarxxKifrNd6V8bcQ3N0pZ3lqaR63U9EeZ3 | ||||
+JC+oYnLWGcu4kybsUTdUWYqFUtzeZ5UnAW3yflnbrVVXOcv+CYu64qsVy0t | ||||
4jgURiE3Qa0XIvsSsGEmpvtwjeq/UUNcDoegBEKvr+fftOig3+tTQgtwu6ku | ||||
SVhOgurzaN8PW3uH0/c4kUoKWEjMP6VaU66gFoJB5OdTQvQnsx8XV03ZtGZL | ||||
j1EhKBqLInrysCepdvGElZ7T9nm3z9dOOO80m+zkhb2RpGFQDXypHlBqizZb | ||||
V9teddIeivQyHtNdcBn00RtODyAnVlDqtzSH9NoRVfXVhsTX1xHHonKVhnFA | ||||
NyXyyPZ6w2lGlLF0j+9USGYxnwo/vqZCpraTDYtJfj5onR5rmdZ6SBKWPnfy | ||||
3Y9vX6mlkEPp4WtNM111en4/oQub4lXPp8Ae5NQA6ce3pzaXQvLqb53D4LJb | ||||
AfinHLjPpfGw+y5sD0B2bF7tnGg3438sucwSTCpBZMHSKF1WbgPGrLt442hn | ||||
x9QzP4pkMcP9wAf4cuET4uZtSvCg43gre6x5cN+jW+Z73iSpIv3xXgqUqG/t | ||||
T+7ArttPzBbpd9Va6IT8lpKEBR1X3YCTYXaH2oqKW2zrT7jV99020SO3P6T7 | ||||
EhKnI2NAxH0XhXVXG/2UUlWJM9MdUQw99sQv1znP35V7TT33OOMps84br60h | ||||
olLjmGLR9J9TicYrKIRSzHmQcRx2rIi5YLKfC+3Ky6WJa1hi3j17TZ5wRZmC | ||||
KjHew4rTNqwq8ky6as61AM4xb8Jvg3TGJZjgKza7d9ndgAGori+vbQyKyydY | ||||
B/Jq2L+36TnjnnN5uIjLc8xrwQrUe//5H7u7u/QfbhaE4n7K7nJbUocZAZmI | ||||
tfo+TOu9qhAtciCe2nVKPB3O+FQemzeUAN4zb5CqVxTx9SQHxUDel/SggInY | ||||
BRJ5oTozXs6RK/CCSaD3zWv/u4ytM/eBIr3gkzpxpj2GlRGPUFiAZ0ZB2r/G | ||||
kypW1JDy+QdsN0XZIMlVRzLZ9oZH3NU0C+H04Cd5BnHQM88b7jDZZQ/SspTq | ||||
+ZmPS54DyGtKqTcPa8UhgklR2ZDHjGMgLZQ4bxFPPlr54GS2ztA6aDrPwJy0 | ||||
fcX6oN+Ux2sg7csFYsMIhyk9H5/EEVuqQkrYfSyaBrO8ocuCd9c+H44kT7+T | ||||
+3HDY5hDp5iJCCm4aVXC+/qdQBl6TVRiir1EugYPJXWW9HOuWQONqzUM4Jpt | ||||
FECDxrGP5IHI3l9fW38CiQXOF6jnP/AhlvvlgzyytVSAmHXkiQ5gwwnsqN5b | ||||
v8WpiGXYMH3m2ftKDT+uQe5ddNtDTAHpeftrL7ztseCjomIPEVop7RBsHOlW | ||||
2hoFljxPEgmwtHJj0N+P1FpSQQuvXVyZyHDYKQJGIUny40cdoh+KiNQXog1i | ||||
78KVcAFZGbIRrCGBFr+aX7HFYtChWcFOY4GlqTs/TzwJwq1Z5pJR6N6PkmC0 | ||||
vV0ZTooq+MzCc3CMklUOqOnRcg4op7qxXH09IGM01QQkAtL7qmDZXtNB0jR0 | ||||
tyJqoIyMEde+rOApqRJJNUSDS6p5f1iJCdiQFliLMmLilwlrxcgjcAptirMs | ||||
a3OHnqHINQJ+LHqph6vUb9cV/iZpyEZ+imMOW35EB//5H8NHh95OdY8OqB0U | ||||
PSTCwD2QOSlmwM3ORSA0lsCtk6OlNaqit5HNre07jLfMxhJX5dhSNi1iG2Os | ||||
EKECA4jNqq5beRS9zoLKFQ40AaNbbjNYN+IA6OsXMXzuYTxobniJkTZQlFpJ | ||||
/F05qt8iDbTAwlH9yJrtEmKwXZKzTiVwjOwC/dDrR05LsbvsM9q7SvgcixF0 | ||||
bkZocWQHhdbtEyZPi9dS91iCjsIf8VAoIhw76XCjVamUgSVbS6QDXt18vI8j | ||||
oQZSUVChoJpNKDo7Nj6IWEDRXDY/vtznhCyvSPGTNkEzLcNwGRRvjrHets8/ | ||||
PyGnIBb5yReLPq2LUPAZCFAm+PkUfer7P58afqv/0f4Z1sR2P7sw4d4u/WA5 | ||||
cGYcNCkLaiEgRvNUUa3D7FSuke1baK99lSVuUlpCllqTarquXR69t406JCph | ||||
pEiiJsbajEOy65pe0PKCvajXf0BxcBK2p0IM1r5E+qqf+gIJd5u7b9OLnfgy | ||||
aBGVb1x1n5/T8hVE7lTRWCsho9ZKoD/UHIDFEknasovkNcAd2MV3Hj16BPwa | ||||
UXaP9BV+XdK30Vzy7gdzgrzmEpuN1Iv6WOn8sVwqLF1qfd8wgw2C0Lx0s17S | ||||
1Rq0C9aKqObplKXVGChpNk5cawFPibaVQsVknfEgXEZv4K+WrjyuD2c6fNRz | ||||
i4Y/aNk4HjzQk2eGj/yHhvzFtjTGtnVGbbdbtW96ewM7Uw5UGm5QhzbrQdz4 | ||||
8NiTPjdoRtSTBs0OVa1OFAi8ia026yOqGBFddTgYq2dT/nk+tFi8lW424XQu | ||||
dc1bn4BHUjFIEHx+YvMPprbBkdxLLWA6VA3vgvOVcP6uD+C2ef2WCrxlhspZ | ||||
MEPANcqzJFJ7A0oourIey71++gFLLabcMcbLsvz48cnTN4AEKpn6d+XIokaA | ||||
GQeCGGkZIjjxwpQwfFYr9ckGFhrXhg+ObFJmkKY1SdDkzfXfypS0IGL5tlYW | ||||
In+tR6ds7iydp9rtol7VbtCIkJWDyyriugIArqaL17Znf9fbH3+DHu26Heq8 | ||||
lS3aQEcG6yz1ndQs+hSA/Ec45zqD3A243h6tgWbyyV5tJvsYv8QUBH/zb0wd | ||||
PEUgeelgV1/y93lHVRSs0EEz7bq3PikZummm/eClB+4lRdD6TxNvr9vC1mxP | ||||
guhr5Re9iou28r1v4Trc1SKKI0/T39//b9IDkPzoy4LzacNg05QdXHSBLpJ4 | ||||
UuRIxTgj2Svz6ac1oqRlkdTmRKUN9WQ9md223Rs08H3jymGQMS8hvrH7mEo7 | ||||
F+eUZPp7oq4PZ8AX64vWb0mtRVa2y9JA1ZI5R3spTbKrgQTXsf+Sq62Q6Vjc | ||||
y/XWHAKyFG4NRFef8Aenx0etgrClBaKGJBNpL0T+47+j/IQONWJg5Qx9xzP2 | ||||
YNrO3pVL19Sa2afCqvwSxoFoPdXifo7ww4SgIZxzxq3wwUj5IJMD1qjW5S6J | ||||
qQiiRn0WIYVY2VQsJiaesYF1BVnh7WuxLeBEQ5FwV3Uv4fCTJXVvr4tBqOfU | ||||
arWSHFX2zBpzC+OTHOvSE9dG6XbtNYbO4HZd284hBmZ6DJAl1jdt1UVZwvh4 | ||||
T01ptn9SrR4pc3LpTye26FK8CFaQYtXRVEk8j7odNnTE88422styqbuPcTUY | ||||
88giBOa4XyZSqpeL/9qSs9RH0/UkqxdSAHAGYj7gpiFeR5lu0D2kJ37QsIvi | ||||
tejvBC2XF9WAEAcCyhr1zB4ebgRTXQUADHlaamyx7Yc96CxB9W/ePHs/JkU8 | ||||
rWz/HBX2BIPcPRCCSFYj5AH02mMh4dwviKGQbkHbURMcZCjQ8wsXuz66bSQN | ||||
L0qXPcrgwsafWoR8/eyCjZOico/Z7h0+SWKiNGL3KxpjjxHUXKSiM5kSAnAl | ||||
Alifc0WLB9GJF5u+VtDVz/+rTyqRCpEN3eVJXP8a6Vzj1Y0Q3Asxbts/dLZ6 | ||||
bDjsWNplLJaV6XbcYetSO9tK02jjvYreUmu8lKRbLWgdFUnfy06jmCVuV8II | ||||
ux7MwXfTa1Or9XHR6mf3UhtERFjy33VHs9/bs7GWHhJVcIHrq4qUouGieqIq | ||||
aXx9mFtXaWKe4qThXjJ7vYhvHlUXbn21hnH87v42k35cyphaddgTG18kY6n3 | ||||
EGY6+j0TkDpRUB9FY2h7GH5qmksgBXBbzDKzdSZc+V3P1thzxcDGZLU9X48p | ||||
LW2wme1wmU3sDo5QL+Jy/IS1jXOvY5/29ztrouIiH1AQS3Dv1ECBDgkpgoud | ||||
z6LQ7WENRB8/Wqe8dWlfY84atuK2wHlUQgBqvLejJMg6sfUzhB9wp2SEzoaF | ||||
kFQSBjRR7g8yO26bQHFhUrxMjK1CZYnDdF0DcbbccqUEqudWsoij3VWsBYBr | ||||
Mui2ySXneJzikvtCeYWPRdGUtnGDbaz0KdfSFrOux2umQfNpdh6Ulj1gm41I | ||||
tsXV0mfvGc9GMwPm2YYYM2LcItdwOTsUSGgEwhdq3SHbwN0VlBwOIgpVI6hB | ||||
apHeYgtPKG+mkY5FlsdK2l13aV1HzRrOmyDfhygduQuoyYbNsokjT3TT7eEG | ||||
PTJkihrtkH7JfLsqh7/LEm+tVCkiyZM6nRQOcUKmCt+X3GaMm0Xw14sCi3hQ | ||||
t+mNFm8vYqTJ7CiSvy3jQg2jnVU8lb7sgbGKG197RsZG9f2TBvTUq0j76neD | ||||
+L5Bud+g2d+o/K/bxuFnD3tVqpJ8LP2cOfyaokcESjgkCutZU6LtkHusb+O/ | ||||
8A9tNBZTxUo9zQu3fXg2DcqjGVSgP60VvG0c1NUNbh/0sD4oSMrVnxx0GECK | ||||
KDYuVouqDxLbReugD/b3HmwcdA1SABS3tB+P522DPtw/2Ajp/tqe2gpRDT+3 | ||||
OvvDtbO3DeLadxTg3N8E59H6oIsmCOuDHmwa9MHaoBw0vHHQm47pIQ96sGvP | ||||
Pp0SOm0cdDjcBOnwYO2YLnPgHG2NaHX5R0cbB11DKC/wem0CuaRrD8AM/qCH | ||||
a5A2vNNXi/TGQesZEdju65vOYWEOCjM8mpnhcIaGOj/6cHPYYSAIoC1DlLTv | ||||
OXLI+nLxnYamImt2PrFyxFQKOLDhrjnGNJjCi6gLoj3nLtrTC2vEkjeFNvUj | ||||
9sVpZTZDn0zHar/YO5B6uxweOrgppLLmntRoYGWNgdx5Uyhly1haSKkhnNLv | ||||
z9jQPYacZK7Dd7D3ZAX980GSa47LoPItrVWPrdbHpMPnBAi5nDur0Iaw3QEF | ||||
RGEIsyoeXuGxjuTp2C66UnKfJe02EDAI+XNBwFX7QPiaAntN/AIBfoJvXa+g | ||||
8pjU/kzc1zq8s1jHY0768EybdLK6AK9j2sYwynjNZQyTi7ONOy0O1vxvNnpK | ||||
REgvZtEFi5Byn1QWH/z1kW1FU89cNxEkcesP24Yw8gI1RBBDnB9XXy+gLM7G | ||||
mpGOXadEwbpM2AK61krWZLSAuFk3XtA+Ss6j9C8YHc3rVy9+XosKlWg/9ZBF | ||||
Jrg43di3Xcu7mwIftnUXT2YzDyGQiDRsqefKKOrhnLJSWXdTIP0mODq4NRjE | ||||
lrFJau30tUFeiL3WURhsAiqIEdf5yWdYcp97lMIvUgCvbGAiYuryLBWsStjj | ||||
tA4c0WN1XWsAy1IqW/0uEzDaWyj1uLRLbXFsx6QISNunidrcYqZajQKpj6p9 | ||||
DrnXbzH8sUQDwklA5+uRnpXTf04muRThulfo235MSFz1Y3mE7O42Ohb7B6Xj | ||||
5awiJkAqomZwsSNBbV2EGjYnwyvGFzXl7VEZX31aEvfi8j0deGNQunRBeY5O | ||||
i+jE+9z5KZhqTZIqTmcWPegFf59IfY+sF823o5Gen86x1i2G67AJEh+RfnVk | ||||
l5G2YSmb64LmGW6XMcFrgOGhOUXGNj/VY1MrBqkkVcS6ONuHyOOylPCLwPHv | ||||
9qbLUlIkRq0bw32ut72es9Kx0u1iXkR8CeRQuZJq7vVONfF8lJ4v0cTI3Rwq | ||||
aWzMlviuZ8xBC8rKriHWnqGcNefFj2QAHclQGrnVmEASeaHT0ckU04ba93MV | ||||
dJXgGJ8am3WISJggMYUYDMzXMIga1FBcZxIJJy8H5p0U6IioY7TnAyQhI05p | ||||
Ildstyi3TL5IKZ8+bljNC3ReP4WziVINULLlrMhMJK28Qa5KYmzkjK1epQsB | ||||
pemFC/b6apZRvThrytZ2LzpLhre9lZMG51sdZTW2ZmAddoS2dPEQAUQCxdbz | ||||
nq2+12zX9/0BEXfRy7mNYS1auJQiKXHgfWXjHMw6Xc7E9SwXNnA0oC+drKBq | ||||
0WuagGKHehzJLvSMe+ASWGyOJ3Esi2f5OTbwq8QdQlrEekZAi+2RDZeRJ3Kx | ||||
JxqrQl/kmibKImSX6Nm2T9Bw+lWZ+j0HQRk4zwMftyKzbketSzJmcEo2an0T | ||||
0LnAqaX2aWk0GFkm6eg+VYp1p0l+2kobrrZpJVTxw1roarBJX5g441zspl2S | ||||
2OxSREDnKPEvgvoKpl5uGEcQNK+CCqLaTOpTwfn+M8Z5JDlavOSnH2SN1F5o | ||||
jeHwAqS7l5V2XMMSbdtYf5E3hVRisdhiB1JEN4klArJsnsG3Y+z3gqXr1136 | ||||
pIO4cUo/oiNIBEHUIRxx4pD/fZrJKXm1HNi0LSn3wCTysgReU3q1/3xKyiW4 | ||||
M6x7xMMHodolVyIoqG/yfU1dEmFQCx/a1maxJ5bGbif5uYvYFbcacRk2PS3a | ||||
vFUtSFwXsMy04pHNy87WzkREUrrkvAw7+xJI/0x8OP6E4XR4TqVrQ4NZfJkn | ||||
wpBIcPIMeArsOmmDDk/QSR5TmE+KBHHSMPQZ4T8jC34OI1lKl3xI5ovK3y8R | ||||
ThE/WQ1EcM+LJBH7yMkzGEwgCe6Hq9GQZJOgaZJcGGJH7PSQ8pbS7V2LUtcj | ||||
NyMbf6jSuhW6CHglz875hMIeEiV/hq3Aa+IxYaUfpouYUT9Ukit8bkShE2E2 | ||||
WoCK6ulOq9JHSwo5JvIa1WJjvQBVUSiyvF4WzTqCQDVNRMuuS7u6vwCwF57j | ||||
KohQyQyO01SeY/3CsPtrFKYXsQRigUP2vECCs8xmUopgJQ551L5g1z1kFT9i | ||||
vEIfzcfjfyzROzkGxeubzoamVPAn/v/B3nB3cFHNZ/dKtrb19wf7nYgGmSBm | ||||
foPRRfiU6fKEoN2pYQ4fvY6+BSXVeURJWvIpOJaN4m5iTPKRWShlIgJK3lcu | ||||
s6iSP+4SvVdykXWMBK4TVcZTNkwgPtEAvG0T1kDLUHMRRBRnpDyJez5LgmtF | ||||
A1EpcNQ0CcQgv41Kb8dUDMVzC0t7ua3SgEazZBMIn6rPNHTRg9t586LoFWg+ | ||||
gzBZ/yWcIvcylJaO9G6f8/Z5XP+Rha0EscNNDtPJV9jRsp6+DyypXmuBhunT | ||||
MHJgHTdyYIKLPpFZzjfVn2GcGgrqDWZ8W9mATOwBWPBtK8gSH8uOmnU7utQD | ||||
wgtNlQw88P3MwLptvZbZb2dwfRNuSPFHMnBMaW2wad90KBl1jLG2NDUVMoiO | ||||
/VVF0bvlqPK/rJ2MjQCmggZJRf5wqh4RRbY8eMN3z7WVaZiQid9LI8Duj2ff | ||||
9x9uAwSa/rn+KIfGtSZ3Bs3vojdWyNQKifQcjuMeOnFrF52WtWq0ShNC4WbU | ||||
NsmPd6D6hxSe5WrTamYJcwGx3vW1EJPksXK3kXFa8l1pC1+Nou+L+JwplqvR | ||||
tL4zKPWWK3jpA1c6lPpNpat8OV0fx/drIAnstOJ3xxU6jje+RQ8DE+ieVOsO | ||||
HTuGi/Pw+d0ahBowy+tSa+3U5ow0zAz4c+IkWC9ZHTfp61HxLbz6Mj5Px3Jt | ||||
uiVZRwVLDV9P20zHfkv9SejVMcYPlReiMuBNwaJb4TBvqJem+e8mQQEX6Rd1 | ||||
X0DtWQoj+FVsakBSmuJPP4RWhm7QGXUbiztIESgTYDCe/dsknvXPkFeRAtCN | ||||
i8q9idEV0uSHwkB4xpcvX7/Cu41l5qT8DlWVlwcyIPWwr2R52nnKBgCpAzTD | ||||
jCHOu5M4kKf5yZs10n8jQQ9fsES9YbCy04s8G3XnqVe66u3zd2eo1z931blK | ||||
032av32+bd5YouQMRhjri/h39uTZnm95cqZsDfkeHh71McOkkCTPTwoV87Ia | ||||
F9HvnjLN+2SA8K9zl03cpF8fkkD8PC6j+ybFhT6D09BkNl7IenFPn/Uci/FM | ||||
pLwrvWYW9OuvX5ynRf1+34zi8Xss7eSr8BqlZj7es81a5LO1Ztz+e10vFOG7 | ||||
4e7eQX/3YX/3CJ/YdumEzmzgGm678fAE1SZBDq6WMem57lqLbopx2LbvuTgb | ||||
fHe/v/ugv3fY8i7Hxrh3XTjN57/rBbjgywDxsL930PIyh7rwy2HIzWcsGE10 | ||||
i2WxyEvWAF10Yc+QnX0EVOy9FFKhc/CTaDCwHWP/SBAnLyCXyhQebZkpV8tf | ||||
UVXpsARa9PU/ATbt/NXc/+WvHfPbV50d0+9/63UZx2sZfRP+YIDn82Oz9esW | ||||
w0jN2yi+GLBW2m8PTe2lb0AaA8IdFo88tjUhj6V2ZtAW5FgfJzzq9IInNAga | ||||
n3Ibrg95lhh84LncDW0N4h5b61ICj/8iLNaV82wEy6Fpp7f2ZA08QcSOFuTs | ||||
3W4Kh813NoWH9DfPIVfic+YI78bNU+hBBqVLf5PzqveGaD4sv0MHDIqBV/68 | ||||
mC9Gn8PHjbOgd7R5ZFvgDN9n+P2RvUYKjbgr008sVBv2MZhKi+m2T4auMfxb | ||||
3FrA7C/ySfO0e19wWtTjZ31QG4qyebLhF5ysiCfpsmWe/S8+T7+2pXgNm+fe | ||||
eB/+2NygPi2aJ9t4wf/YZIu2uY5uPZfUfr4tfjZP9+DLTTfJyv5ysuhX40Uf | ||||
8zebJ3z45Sa88SI8+nJzZVXzee3dnqDcZg7awNbN27s9Gblxsg0Xe+/2BOSW | ||||
0/RvgYp7tycnN86KltPfQYlkltg42+0JCBpQ2qfa8VjOcQmigwTN9LFxJMLR | ||||
PP3tScqfnH6HUucagXjwfxiInV/tAJ/xc6v9fHB7svk5S2kXJPZuTzg/e0IQ | ||||
z6jzafPEtyegnz9xebGsJvlVywW9PTn9AzNjN93GaYe3p7B/cNqdMVY9bZ78 | ||||
9hT3T02+M8pzh+J/6J7Uf5rXc3vS/ufWo7f2Ty1l45Uf3p5f/NGloNcGjVnN | ||||
898NB2maf2eO+atZyz7cDRVvhCMv2znq8A5JcAMcRUKGvTu8KndJ4dfXIzG2 | ||||
d7ieO2QcO7eQ74Z3yD5q8++gTtAIxP4dMpMmID6f/tU0YGwy17KUO2RNTUv5 | ||||
Y9Kb0QTz35NJ/32yal7KHXKlP7+UcAE78ewc8+UvmrnC/h1ypS9wKrW1wP/7 | ||||
dTDcUu6QwX0hBKstp5U37d8hj2xcSjskd8glv+St5Z9FXJZXQIKal3KHDHKD | ||||
SL5/l3yMhdebzQf7d8nMakAsq3E/n05Br7474eDgLvmiBCE0T3yXXAwtkqBL | ||||
57PLFh56cJeMx599hxNCmu1tB3fJM5qg+HNEAbNK5ouqZS13yTS+/FooxjJv | ||||
sY8d3CXXCNZSJnExvmgG4i4ZRg2IovWe3CWpbwCinX8e3CX1b4IEDfJ/DsXi | ||||
bII+kebl3CUf+bLLkWXsSHRZ43IO75KNfPHT0RW1+lsO75I5XeRl1Yrmh3fJ | ||||
mDQQvHnmu2RGbV60w7vkGjDpTkK5NM1y7OFdknmcfANhPbxL6u7m3tE8SzQp | ||||
/GkpstUrf3iXbMJbTTpaFmXLlb1L/uCB0H5z75KiewBw55lGEI7ukgp7IADx | ||||
bZ7/LslmOP9GbnR0l0S0BkcrDzm6S3q6wYl/dJcklefdqNQc3SVVDeff2aiR | ||||
HN0lia0BskmbOLpL4ihwbOA0R3dJGIPp/6Ad7zZhX0d3SVzDRbQS+Ad3SV1D | ||||
GNoI7IO7JLBrICiNvTvr04O7JNTr6/nT+NlK7B/cPbH3F1JexEUy+bMCXZmM | ||||
i6RlPY6J0L+/RfjbNcWqYzoIZT1IwkMfJJIKOxtyVoiGfw80/jtIeuB291xr | ||||
nSLa+xx1v009tzgTeemKqHOdIJwMP/XKd8PTJ64rhteL1yu55DrYSrdzTOk/ | ||||
o9xS18ZD88Sx3C/3u+bCVWVY+HUPu5hSofGgTDzWJEqoVBJP6aWOYaF6SQf0 | ||||
U7AH0ZCrA9k6GPQiZgnnWmY5ni0u4lFC3dkNOQJ7Zssi0RY+gjH3sABu+8cP | ||||
OESiJ+LwAZ7UHwVzXoKXOH2n1EZQXBcgqBkmWeRbQWLBVtjtxubD8HBYrHB/ | ||||
YNay6o00JOGm8TYZKvG6Gy8Xmp61oXGxbReIJ6ZtI9dbtVCldxyFhksKmFY7 | ||||
1mHCBnZc6ZmEDowAusIqGpNkVsWAP9UVZoP4DVsJT6WejRbLws+0BuJohYhV | ||||
5VjX0sQwM9cxAKCXY6xMV1JlZG61djDQqh+uwB4jBbdgcQ0JaK3dcrvW8aRe | ||||
Al1ul+s/MpkISvq9G119gkF0KFUAm1I0NGkcFj9LpI2mfikQczpNTPU9AkRp | ||||
7jRCTV5KI1/Nc73ClSstT9VQop/wEJaLiXZAXBs65e6u3Lp1qeXqbQHseiMD | ||||
qgoYpxk3WRxEXWxygumFcVn1+MiTy3xGBStirWEilalxunpBj7C6BuLbMpMC | ||||
B66Kd68RjHxaJdjKpKqockcmzSHg0sUVthvltHm70YPtSHFE6nQCdRlfJHMs | ||||
XTWxHQ96ZrTkXaXk3wLTQjNbm1BKBLmkXWlIN09nMRUHu6KSQljNy1WgiC9j | ||||
+BrrkXAxAK4/R2D0LGJW+iIhvxZ80OeoNzjuc5pxNTftCKYPYgVTbi8oi5R6 | ||||
UlrlCS6DW6FrRoLD+vXPqXC9tPFJuQw+1ovT6k9Uhynnnkp2WoI+10Stlf3c | ||||
q+dYBEnOXMoJILLAElbSfnOWrpbkyARUe1no1Op9I3oR9Ze1N8X1rHj65PVb | ||||
oIeSzu6qokuJn3p/Ha0eE1NrRG4zCEecYeMiqkihy0290iVRUMefipiMpd0F | ||||
YqlXWUrQKi1RZmipnMteee5rI1QDx5vY7ksjGG+aSgUeLMK1pNzpCiWbzHbl | ||||
uALycCFFWy5T6QBOddqYjQNDddfJa1XE2EL0Iqm3ggrLIwb9pICZLCgxHGht | ||||
MomkbBYsk29rrfChrYnIpG/gijNeEXWofR8J+9QbtbFs466czXLOpYepako4 | ||||
nLyGV6t9JMuawpdx9D3/0kV+QUdzQn0jbJ3InsVkmCBoqD2mQmdlHkhWnKoa | ||||
2bqWnBTlyRHUAa1n8oy6+dlL+/N//e+gRqYrdBVXER3NPRAfTqRipz1P2/6j | ||||
vvSwxAnX+BHMxxxMh+8NZ8oQWKmtzlsdNaZyb8TwbNs1eUQ+X7/4zW3Jev4x | ||||
RY7/c704rozSsDppCzPCJqRIn4I1SyKqLpZOilb89s1TfDrmyjUdzg/gRvP5 | ||||
sqI/POmZyrTGs6t4hVnJrscykpAEd5Xv9Aq511ZlmwdpsYGwqR3uXYwJ57bU | ||||
rNQB0xI5Xh0rLbdGaLbkQg0kGvj1mhjDc+kXGc2xQxsuPksQe2IqyBKmbM/S | ||||
aTJejamvF8qo9m/QY0CbeCIdl2mZIjyUrq+IXwiu10D0Si7mHI+lSlrkymNK | ||||
iclOa7Fac9pYhFzbuFCVtbPvpcZhXthSdl4JTr8dyFgKp9QKDITTR64meL1d | ||||
5Q2diq8Z+111Nq9LTclw6ZbQCeqOmPqOZKv2PcFqIrzx44s8pRbDr6VFaK23 | ||||
nqwWCMtVlsic1PSlCnpxeZiwU2qLoPBcd7COI/chrCkPswRTwinze5mFdXWj | ||||
sAy0+1IgzJgcBIU/M9bInDDCYmCEsueytSq9dF5ZUp92Y34IGjoF9Fn6/nG5 | ||||
Man2x4UE6EYpwUZtduDXrVoj8kSr4e57/Z7qfbLwHiLdEe1CG8FSuSYZj0tE | ||||
YOXWlEsu+cUMSHZHmXmSxudFDBLwcj6PMbJPWunIeywxBPcOZk6pEJ1Xbd2v | ||||
T0x59XFcXp6rgeOrWqeUryKT0xefLHw8z6eo/1Ufs/M/BVNiLYwd86s31Ffe | ||||
UMHPp9rfl/r3IIBgIB/vmHcVLCguJhjTaHgO0DO0js2vARx/MTu1ZfDPVgDT | ||||
1iaAPhmUVeo/tYcu1x7wl1JbSdsWwyffwvr86im4Hlgb9s+xd5mn/8SL9QqW | ||||
6GLhKPxamfDw126OT+3LXzsob7F+n5yWDVlffvhayxa1vra2P60f6mtf8Sc1 | ||||
PGTgcPvg1jGR9oGVg/yk0rC/nE9+P1njb6Ri0kYgv2oCsnEXwvU3bcnNrzXu | ||||
ZOvTmwDXf9rf/hSQabtbbxMsbskHsGHuT77N0r1tjE89boT8qwbI+zdC7mBY | ||||
//nrza81IfHGw/Gu/oDI1K1e2zFUYBpZGV7y264NaCEoBedU2crsbAJry+3g | ||||
1o2rpgt/41OXbU800/H6zw7/g4Va6OfX9jlxma6OWY3Eb9ihrQBxtmrfbjgP | ||||
OrYmjNn8Gv00k72W3Wolbw38uAkW+i9VTPb+pl/OLtKCKgRWq1ag1/hG6xcb | ||||
gV8je2tfbNyyln2+aafrO3RLYtCKtfDzy7PXr57/5jw50/TcmvL7VtxiZ84W | ||||
MpgXqiht1fuo12S8H4nX1CW8kxskPOFQX0K+a0QolfB+tPPgrLDtrSKeERnv | ||||
k6FGRVRHF63u7qj4G7Jj4xfeNzfJhevnHZxVO1UBSvIquRLd3IgE5X0PEHN3 | ||||
BBCv/oLPN8zfTCqaMLAmDTXhk2L0rcTARnz9ZFcWiIEqGz4nL4YVb1rAlLXb | ||||
Nu64eBUYQzmnbaHtW1O/4ptW4f15s2Dd9GLzVb/NjDc/suH8bkODP+k/Nflo | ||||
06NyrUcxmvI2P0rVpMU8esOjtwbgNtT5i+7jbdWh1gHgGnA/+tmK/tZrsEad | ||||
2gaAW+CcNd4tuJnLfdYluNUdaLgCjTPX9uf2d+AWY9d+NvFE+hHG2MIZ1a3A | ||||
QQ50KMihfiWM/FVQkh/qrPFJ8z+SZME+TFs0k/xDNM4p9lVH69YzdCJRF/Do | ||||
48e/gND4aO/RYVBWXSpsUjXc9Xc7A65/ivZz9azPkpiLuaMFOhvHi3I5C1of | ||||
pjoCubC44ClXOZwnVUwfJhk7M9HXop1gwo7mo0R7xm1aVo9Nv2haIkMltuZm | ||||
72kyHyUT2/mIu8wIfK7LcLn2ZfS/pGw4JbP+L4CY/RxZrWRmJYW4uXLoOF+s | ||||
yLt4Se3qk6jE9rWT/gx9tjKG9OSapGPXo4YMfNn5DCtFxuP3SYWBIbZ4o+4j | ||||
geLVX1z/8jj4q18mWDlPSjJqKb+vvdJ+3373da1837dEBjlwp1Z+0fzS+dr7 | ||||
5NuOFtrTnWK3sZ3R2Np6x7WCkd8Nd4f7/b3dvhZEuK6NRJFMMI4xX2uVVfK9 | ||||
5tTD51sdvqUKpTn2Q6TCSoaDgYo+HH507cKPouiXvxbTcTL5zf127PXnPjZv | ||||
wsKvHGPAbfiII7GTd5wX2K+Ehif3u9i0w0a5tvk63OGT8fssv5olE3JJlEgi | ||||
2GGTTL7pTONZmXSk9qvav6/ILTNL30vx+Dh7bz5+/HiSTVbmSUqtIK6vYVfx | ||||
sxFcu/jSvMtBNo7/vsTP8dk3WEgYcB6DUQrzrsrf6zcv4iWFnZzlS3S8XGMX | ||||
hGyCY72NcYKzZZFht1Xb9CctzEUyW2iXNPGv4sV2ARhB8eRsIjZ4cZ6zTbwq | ||||
/RGkmYHtBvGOI2h4saXB3j9enwO9W+QgXqKRLyE/pvrno6Yp6E3Xxc0sLuKS | ||||
myE5Dz/2GYKVP0myv8dz+OZ/xJPle9kS3Ky3+cj8lM6qnDacvUc5fvF9gRex | ||||
HMfmTTzL56M0S+k1dFCV2HAkRW568mwQ/f8Xqn71LiQBAA== | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the | ||||
online Style Guide at | ||||
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, | ||||
and let us know if any changes are needed. | ||||
Note that our script did not flag any words in particular, but this | ||||
should still be reviewed as a best practice. --> | ||||
<!-- [rfced] Please let us know if any changes are needed for the | ||||
following: | ||||
a) The following terms were used inconsistently in this document. | ||||
We chose to use the latter forms. Please let us know any objections. | ||||
Early Allocation / early allocation (in text) (per post-6000 | ||||
published RFCs) | ||||
work-in-progress (Section 4) / work in progress (Figure 4) | ||||
YANG-SID (1 instance) / YANG SID (approx. 16 instances in text) | ||||
b) The following terms appear to be used inconsistently in this | ||||
document. Please let us know which form is preferred. | ||||
mega-range / Mega-Range (in running text) | ||||
schema node / schema-node (where used as an adjective, | ||||
e.g., "schema node name", "schema-node path") | ||||
Quotes, capitalization, leading periods: | ||||
.sid file (16 instances in the YANG module; | ||||
also the title of Figure 3) / | ||||
".sid" file (63 instances in running text) / | ||||
sid file ('"description": "Example sid file"' in Figure 3) / | ||||
SID file (32 instances in running text) | ||||
Suggested: For ".sid file", single quotes in the YANG module and | ||||
double quotes in the title of Figure 3. For "sid file" vs. | ||||
"SID file", if you don't want to use leading periods or quotes, | ||||
we suggest going with "SID file". | ||||
YANG SID Range / YANG SID range (used generally, e.g., | ||||
"a YANG SID Range", "The YANG SID range first available value") | ||||
c) Please let us know how/if the following should be made consistent: | ||||
Numbers with and without commas, with and without spaces. For example, | ||||
1000 to 59,999 | ||||
1,000 | ||||
1000000 | ||||
1 000 000 (please note that "multiple of 1 000 000" breaks across a | ||||
line in the text output) | ||||
4 295 000 000 | ||||
Note: IANA does not use spaces or commas in the registries created | ||||
by this document. --> | ||||
</rfc> | </rfc> | |||
End of changes. 292 change blocks. | ||||
1650 lines changed or deleted | 1978 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |