rfc9254.original.xml   rfc9254.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 3 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
.1.1) --> -ietf-core-yang-cbor-20" number="9254" submissionType="IETF" category="std"
<?rfc strict="yes"?> consensus="true" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" u
<?rfc compact="yes"?> pdates="" obsoletes="" xml:lang="en" version="3">
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-core-yang-cbor-20" category="std" consensus="true" submissionType="IETF" t
ocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.3 --> <!-- xml2rfc v2v3 conversion 3.12.3 -->
<front> <front>
<title>CBOR Encoding of Data Modeled with YANG</title> <title abbrev="CBOR Encoding of Data Modeled with YANG">Encoding of Data Mod
<seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-cbor-20"/> eled with YANG in the Concise Binary Object Representation (CBOR) </title>
<seriesInfo name="RFC" value="9254"/>
<author initials="M." surname="Veillette" fullname="Michel Veillette" role=" editor"> <author initials="M." surname="Veillette" fullname="Michel Veillette" role=" 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>
skipping to change at line 48 skipping to change at line 46
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>ivaylopetrov@google.com</email> <email>ivaylopetrov@google.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Pelov" fullname="Alexander Pelov"> <author initials="A." surname="Pelov" fullname="Alexander Pelov">
<organization>Acklio</organization> <organization>Acklio</organization>
<address> <address>
<postal> <postal>
<street>1137A avenue des Champs Blancs</street> <street>1137A avenue des Champs Blancs</street>
<city>Cesson-Sevigne</city> <city>Cesson-Sevigne Cedex</city>
<code>35510</code> <code>35510</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>a@ackl.io</email> <email>a@ackl.io</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>
<code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</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="2022" month="April" day="11"/> <date year="2022" month="July"/>
<area>Applications and Real-Time Area (art)</area> <area>art</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>core</workgroup>
<keyword>CBOR</keyword> <keyword>CBOR</keyword>
<abstract> <abstract>
<t>Based on the Concise Binary Object Representation (CBOR, RFC 8949), <t>YANG (RFC 7950) is a data modeling language used to model configuration
this document defines encoding rules for representing configuration data,
data, state data, parameters and results of Remote Procedure Call (RPC) state data, parameters and results of Remote Procedure Call (RPC) operations or
operations or actions, and notifications, defined using YANG (RFC 7950).</t> actions, and notifications.</t>
<t>This document defines encoding rules for YANG in the Concise Binary Object
Representation (CBOR) (RFC 8949).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The specification of the YANG 1.1 data modeling language <xref target=" RFC7950"/> defines an XML encoding for data instances, i.e., contents of configu ration datastores, state data, RPC inputs and outputs, action inputs and outputs , and event notifications.</t> <t>The specification of the YANG 1.1 data modeling language <xref target=" RFC7950"/> defines an XML encoding for data instances, i.e., contents of configu ration datastores, state data, RPC inputs and outputs, action inputs and outputs , and event notifications.</t>
<t>An additional set of encoding rules has been defined in <xref target="R FC7951"/> based on <t>An additional set of encoding rules has been defined in <xref target="R FC7951"/> based on
the JavaScript Object Notation (JSON) Data Interchange Format <xref target="RFC8 "The JavaScript Object Notation (JSON) Data Interchange Format" <xref targ
259"/>.</t> et="RFC8259"/>.</t>
<t>The aim of this document is to define a set of encoding rules for the C
oncise Binary Object Representation (CBOR) <xref target="RFC8949"/>, collectivel <t>The aim of this document is to define a set of encoding rules for the C
y called <em>YANG-CBOR</em>. The resulting encoding is more compact compared to oncise Binary Object Representation (CBOR) <xref target="RFC8949"/>, collectivel
XML and JSON and more suitable for Constrained Nodes and/or Constrained Networks y called "YANG-CBOR". The resulting encoding is more compact compared to XML and
as defined by <xref target="RFC7228"/>.</t> JSON and more suitable for constrained nodes and/or constrained networks, as de
fined by <xref target="RFC7228"/>.</t>
</section> </section>
<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>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>SID values (and the SID deltas computed from them) shown in the exampl
es are example values; these examples do not allocate the SIDs shown for specifi
c items in the modules.</t>
<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>action</li> <li>action</li>
<li>anydata</li> <li>anydata</li>
<li>anyxml</li> <li>anyxml</li>
<li>data node</li> <li>data node</li>
<li>data tree</li> <li>data tree</li>
<li>datastore</li> <li>datastore</li>
<li>feature</li> <li>feature</li>
<li>identity</li> <li>identity</li>
skipping to change at line 127 skipping to change at line 130
</ul> </ul>
<t>The following term is defined in <xref target="RFC8040"/>:</t> <t>The following term is defined in <xref target="RFC8040"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>yang-data extension</li> <li>yang-data extension</li>
</ul> </ul>
<t>The following term is defined in <xref target="RFC8791"/>:</t> <t>The following term is defined in <xref target="RFC8791"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>YANG data structure</li> <li>YANG data structure</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 newline="true" spacing="normal">
<li>YANG Schema Item iDentifier (YANG SID or simply SID): 63-bit unsigne <dt>YANG Schema Item iDentifier (or "YANG SID" or simply "SID"):</dt><dd
d integer used to identify different YANG items.</li> > 63-bit unsigned integer used to identify different YANG items.</dd>
<li>delta: Difference between the current YANG SID and a reference YANG <dt>delta:</dt><dd> Difference between the current YANG SID and a refere
SID. A reference YANG SID is defined for each context for which deltas are used. nce YANG SID. A reference YANG SID is defined for each context for which deltas
</li> are used.</dd>
<li>absolute SID: YANG SID not encoded as a delta. This is usually <dt>absolute SID:</dt><dd>A YANG SID that is not encoded as a delta. Th
is is usually
called out explicitly only in positions where normally a delta would called out explicitly only in positions where normally a delta would
be found.</li> be found.</dd>
<li>representation tree: a YANG data tree, possibly enclosed by a <dt>representation tree:</dt><dd> A YANG data tree, possibly enclosed by
representation of a schema node such as a YANG data structure, a notification, a a
n RPC, or representation of a schema node, such as a YANG data structure, a notification,
an action.</li> an RPC, or
<li>representation node: a node in a representation tree, i.e., a data an action.</dd>
tree node, or a representation of a schema node such as a YANG data structure, a <dt>representation node:</dt><dd> A node in a representation tree, i.e.,
notification, an RPC, or an action.</li> a data
<li>item: A schema node, an identity, a module, or a feature defined usi tree node, or a representation of a schema node, such as a YANG data structure,
ng the YANG modeling language.</li> a
<li>list entry: the data associated with a single entry of a list (see notification, an RPC, or an action.</dd>
<xref section="7.8" sectionFormat="of" target="RFC7950"/>).</li> <dt>item:</dt><dd> A schema node, an identity, a module, or a feature de
<li>parent (of a representation node): the schema node of the closest fined using the YANG modeling language.</dd>
<dt>list entry:</dt><dd> The data associated with a single entry of a li
st (see
<xref section="7.8" sectionFormat="of" target="RFC7950"/>).</dd>
<dt>container-like instance:</dt><dd> An instance of a container,
a YANG data structure, notification contents, RPC input, RPC output,
action input, or action output (<xref target="container"/>); a list entry
in a list (<xref target="list"/>); or an anydata node (<xref target="the-anydat
a"/>).</dd>
<dt>parent (of a representation node):</dt><dd> The schema node of the c
losest
enclosing representation node in which a given representation node enclosing representation node in which a given representation node
is defined.</li> is defined.</dd>
</ul> </dl>
</section> </section>
<section anchor="properties-of-cbor-encoding"> <section anchor="properties-of-cbor-encoding">
<name>Properties of the CBOR Encoding</name> <name>Properties of the CBOR Encoding</name>
<t>This document defines CBOR encoding rules for YANG data trees and their subtrees.</t> <t>This document defines CBOR encoding rules for YANG data trees and their subtrees.</t>
<t>A YANG data tree can be enclosed by a representation of a schema node s <t>A YANG data tree can be enclosed by a representation of a schema node,
uch as a YANG data structure, a notification, an RPC, or an action; this is call such as a YANG data structure, a notification, an RPC, or an action; this is cal
ed a representation tree. The data tree nodes and the enclosing schema node rep led a representation tree. The data tree nodes and the enclosing schema node re
resentation, if any, are collectively called the representation nodes.</t> presentation, if any, are collectively called the representation nodes.</t>
<t>A representation node such as container, list entry, YANG data structur <t>A representation node, such as a container, list entry, YANG data struc
e, notification, RPC input, RPC output, action input, or action output is serial ture, notification, RPC input, RPC output, action input, action output, or anyda
ized using a CBOR map in which each schema node defined within is encoded using ta node, is serialized using a CBOR map in which each schema node defined within
a key and a value. is encoded using a key and a value.
This specification supports two types of CBOR keys; YANG Schema Item iDentifier This specification supports two types of CBOR keys: YANG Schema Item iDentifier
(YANG SID) as defined in <xref target="sid"/> and names as defined in <xref targ (YANG SID), as defined in <xref target="sid"/>, and names, as defined in <xref t
et="name"/>. Each of these key types is encoded using a specific CBOR type which arget="name"/>. Each of these key types is encoded using a specific CBOR type th
allows their interpretation during the deserialization process. Protocols or me at allows their interpretation during the deserialization process. Protocols or
chanisms implementing this specification can mandate the use of a specific key t mechanisms implementing this specification can mandate the use of a specific key
ype or allow the generator to choose freely per key.</t> type or allow the generator to choose freely per key.</t>
<t>In order to minimize the size of the encoded data, the <t>In order to minimize the size of the encoded data, the
mapping avoids any unnecessary meta-information beyond that directly mapping avoids any unnecessary meta-information beyond that directly
provided by the CBOR basic generic data model (<xref section="2" sectionFormat=" provided by the CBOR basic generic data model (<xref section="2" sectionFormat="
of" target="RFC8949"/>). For instance, CBOR tags are used solely in the case of of" target="RFC8949"/>). For instance, CBOR tags are used solely in the case of
an absolute SID, anyxml data nodes, or the union datatype, to distinguish explic an absolute SID, anyxml data nodes, or the union datatype to explicitly distingu
itly the use of different YANG datatypes encoded using the same CBOR major type. ish the use of different YANG datatypes encoded using the same CBOR major type.<
</t> /t>
<t>Unless specified otherwise by the protocol or mechanism implementing th <t>Unless specified otherwise by the protocol or mechanism implementing th
is specification, the indefinite length encoding as defined in <xref section="3. is specification, the indefinite length encoding, as defined in <xref section="3
2" sectionFormat="of" target="RFC8949"/> <bcp14>SHALL</bcp14> be supported by th .2" sectionFormat="of" target="RFC8949"/>, <bcp14>SHALL</bcp14> be supported by
e CBOR decoders employed with YANG-CBOR. the CBOR decoders employed with YANG-CBOR.
(This enables an implementation to begin emitting an array or map (This enables an implementation to begin emitting an array or map
before the number of entries in that structure is known, possibly also before the number of entries in that structure is known, possibly also
avoiding excessive locking or race conditions. avoiding excessive locking or race conditions.
On the other hand, it deprives the receiver of the encoded data from On the other hand, it deprives the receiver of the encoded data from
advance announcement about some size information, so a generator advance announcement about some size information, so a generator
should choose indefinite length encoding only when these benefits do should choose indefinite length encoding only when these benefits do
accrue.)</t> accrue.)</t>
<t>Data nodes implemented using a CBOR array, map, byte string, or text st ring can be instantiated but empty. In this case, they are encoded with a length of zero.</t> <t>Data nodes implemented using a CBOR array, map, byte string, or text st ring can be instantiated but empty. In this case, they are encoded with a length of zero.</t>
<t>When representation nodes are serialized using the rules defined by thi <t>When representation nodes are serialized using the rules defined by thi
s specification as part of an application payload, the payload <bcp14>SHOULD</bc s specification as part of an application payload, the payload <bcp14>SHOULD</bc
p14> include information that would allow a stateless way to identify each node, p14> include information that would allow each node to be identified in a statel
such as the SID number associated with the node, SID delta from another SID in ess way, for instance, the SID number associated with the node, the SID delta fr
the application payload, the namespace qualified name, or the instance-identifie om another SID in the application payload, the namespace-qualified name, or the
r.</t> instance-identifier.</t>
<t>Examples in <xref target="instance-encoding"/> include a root CBOR map <t>Examples in <xref target="instance-encoding"/> include a root CBOR map
with a single entry having a key set to either a namespace qualified name or a S with a single entry having a key set to either a namespace-qualified name or a S
ID. This root CBOR map is provided only as a typical usage example and is not pa ID. This root CBOR map is provided only as a typical usage example and is not pa
rt of the present encoding rules. Only the value within this CBOR map is compuls rt of the present encoding rules. Only the value within this CBOR map is compuls
ory.</t> ory.</t>
<section anchor="cbor-diagnostic-notation"> <section anchor="cbor-diagnostic-notation">
<name>CBOR diagnostic notation</name> <name>CBOR Diagnostic Notation</name>
<t>Within this document, CBOR binary contents are represented using an e <t>Within this document, CBOR binary contents are represented using an e
quivalent textual form called CBOR diagnostic notation as defined in <xref secti quivalent textual form called CBOR diagnostic notation, as defined in <xref sect
on="8" sectionFormat="of" target="RFC8949"/>. This notation is used strictly for ion="8" sectionFormat="of" target="RFC8949"/>. This notation is used strictly fo
documentation purposes and is never used in the data serialization. <xref targe r documentation purposes and is never used in the data serialization. <xref targ
t="diagnostic-notation-summary"/> below provides a summary of this notation.</t> et="diagnostic-notation-summary"/> below provides a summary of this notation.</t
>
<table anchor="diagnostic-notation-summary"> <table anchor="diagnostic-notation-summary">
<name>CBOR diagnostic notation summary</name> <name>CBOR Diagnostic Notation Summary</name>
<thead> <thead>
<tr> <tr>
<th align="left">CBOR content</th> <th align="left">CBOR Content</th>
<th align="left">CBOR type</th> <th align="left">CBOR Type</th>
<th align="left">Diagnostic notation</th> <th align="left">Diagnostic Notation</th>
<th align="left">Example</th> <th align="left">Example</th>
<th align="left">CBOR encoding</th> <th align="left">CBOR Encoding</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Unsigned integer</td> <td align="left">Unsigned integer</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Decimal digits</td> <td align="left">Decimal digits</td>
<td align="left">123</td> <td align="left">123</td>
<td align="left">18 7B</td> <td align="left">18 7B</td>
</tr> </tr>
skipping to change at line 254 skipping to change at line 260
</tr> </tr>
<tr> <tr>
<td align="left">Not assigned</td> <td align="left">Not assigned</td>
<td align="left">7/23</td> <td align="left">7/23</td>
<td align="left">undefined</td> <td align="left">undefined</td>
<td align="left">undefined</td> <td align="left">undefined</td>
<td align="left">F7</td> <td align="left">F7</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note: CBOR binary contents shown in this specification are annotated with comments. These comments are delimited by slashes ("/") as defined in <xref target="RFC8610"/> Appendix G.6.</t> <t>Note: CBOR binary contents shown in this specification are annotated with comments. These comments are delimited by slashes ("/"), as defined in <xre f target="RFC8610" sectionFormat="of" section="G.6"/>.</t>
</section> </section>
<section anchor="sid"> <section anchor="sid">
<name>YANG Schema Item iDentifier</name> <name>YANG Schema Item iDentifier</name>
<t>Some of the items defined in YANG <xref target="RFC7950"/> require th e use of a unique identifier. In both Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>, these identifier s are implemented using text strings. To allow the implementation of data model s defined in YANG in constrained devices and constrained networks, a more compac t method to identify YANG items is required. This compact identifier, called YAN G Schema Item iDentifier, is an unsigned integer limited to 63 bits of range (i. e., 0..9223372036854775807 or 0..0x7fffffffffffffff). The following items are id entified using YANG SIDs (often shortened to SIDs):</t> <t>Some of the items defined in YANG <xref target="RFC7950"/> require th e use of a unique identifier. In both the Network Configuration Protocol (NETCO NF) <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>, these identi fiers are implemented using text strings. To allow the implementation of data m odels defined in YANG in constrained devices and constrained networks, a more co mpact method to identify YANG items is required. This compact identifier, called "YANG Schema Item iDentifier", is an unsigned integer limited to 63 bits of ran ge (i.e., 0..9223372036854775807 or 0..0x7fffffffffffffff). The following items are identified using YANG SIDs (often shortened to SIDs):</t>
<ul spacing="normal"> <ul spacing="normal">
<li>identities</li> <li>identities</li>
<li>data nodes</li> <li>data nodes</li>
<li>RPCs and associated input(s) and output(s)</li> <li>RPCs and associated input(s) and output(s)</li>
<li>actions and associated input(s) and output(s)</li> <li>actions and associated input(s) and output(s)</li>
<li>YANG data structures</li> <li>YANG data structures</li>
<li>notifications and associated information</li> <li>notifications and associated information</li>
<li>YANG modules and features</li> <li>YANG modules and features</li>
</ul> </ul>
<t>Note that any structuring of modules into submodules is transparent t o YANG-CBOR: <aside><t>Note that any structuring of modules into submodules is transp arent to YANG-CBOR:
SIDs are not allocated for the names of submodules, and any SIDs are not allocated for the names of submodules, and any
items within a submodule are effectively allocated SIDs as part of items within a submodule are effectively allocated SIDs as part of
processing the module that includes them.</t> processing the module that includes them.</t></aside>
<t>To minimize their size, SIDs used as keys in CBOR maps are encoded <t>To minimize their size, SIDs used as keys in CBOR maps are encoded
using deltas, i.e., signed (negative or unsigned) integers that are using deltas, i.e., signed (negative or unsigned) integers that are
added to the reference SID applying to the map. added to the reference SID applying to the map.
The reference SID of an outermost map is zero, unless a different The reference SID of an outermost map is zero, unless a different
reference SID is unambiguously conferred from the environment in which reference SID is unambiguously conferred from the environment in which
the outermost map is used. the outermost map is used.
The reference SID of a map that is most directly embedded in a map entry The reference SID of a map that is most directly embedded in a map entry
with a name-based key is zero. with a name-based key is zero.
For all other maps, the reference SID is the SID computed for the map For all other maps, the reference SID is the SID computed for the map
entry it is most directly embedded in. entry it is most directly embedded in.
(The embedding may be indirect if an array intervenes, e.g., in a YANG list.) (The embedding may be indirect if an array intervenes, e.g., in a YANG list.)
Where absolute SIDs are desired in map key positions (where a bare Where absolute SIDs are desired in map key positions (where a bare
integer implies a delta), they need to be identified as absolute SID values by u sing CBOR tag number 47 (as defined in <xref target="container-with-sid"/>).</t> integer implies a delta), they need to be identified as absolute SID values by u sing CBOR tag number 47 (as defined in <xref target="container-with-sid"/>).</t>
<t>Thus, conversion from SIDs to deltas and back to SIDs is a stateless <t>Thus, conversion from SIDs to deltas and back to SIDs is a stateless
process solely based on the data serialized or deserialized combined process solely based on the data serialized or deserialized combined
with, potentially, an outermost reference SID unambiguously conferred with, potentially, an outermost reference SID unambiguously conferred
by the environment.</t> by the environment.</t>
<t>Mechanisms and processes used to assign SIDs to YANG items and to gua rantee their uniqueness are outside the scope of the present specification. <t>Mechanisms and processes used to assign SIDs to YANG items and to gua rantee their uniqueness are outside the scope of the present specification.
If SIDs are to be used, the present specification is used in conjunction with a specification defining this management. If SIDs are to be used, the present specification is used in conjunction with a specification defining this management.
A related document, <xref target="I-D.ietf-core-sid"/>, is intended to serve as the definitive way to assign SID values for YANG modules managed by the IETF, an d recommends itself for YANG modules managed by non-IETF entities, as well. A related document, i.e., <xref target="I-D.ietf-core-sid"/>, is intended to ser ve as the definitive way to assign SID values for YANG modules managed by the IE TF and recommends itself for YANG modules managed by non-IETF entities, as well.
The present specification has been designed to allow different methods of assign ment to be used within separate domains.</t> The present specification has been designed to allow different methods of assign ment to be used within separate domains.</t>
<t>To provide implementations with a way to internally indicate the <t>To provide implementations with a way to internally indicate the
absence of a SID, the SID value 0 is reserved and will not be absence of a SID, the SID value 0 is reserved and will not be
allocated; it is not used in interchange.</t> allocated; it is not used in interchange.</t>
</section> </section>
<section anchor="name"> <section anchor="name">
<name>Name</name> <name>Name</name>
<t>This specification also supports the encoding of YANG item identifier s as text strings, similar to those used by the JSON Encoding of Data Modeled wi th YANG <xref target="RFC7951"/>. This approach can be used to avoid the managem ent overhead associated with SID allocation. The main drawback is the significan t increase in size of the encoded data.</t> <t>This specification also supports the encoding of YANG item identifier s as text strings, similar to those used by the JSON encoding of data modeled wi th YANG <xref target="RFC7951"/>. This approach can be used to avoid the managem ent overhead associated with SID allocation. The main drawback is the significan t increase in size of the encoded data.</t>
<t>YANG item identifiers implemented using names <bcp14>MUST</bcp14> be in one of the following forms:</t> <t>YANG item identifiers implemented using names <bcp14>MUST</bcp14> be in one of the following forms:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>simple -- the identifier of the YANG item (i.e., schema node or id entity).</li> <li>simple -- the identifier of the YANG item (i.e., schema node or id entity).</li>
<li>namespace qualified -- the identifier of the YANG item is prefixed with the name of the module in which this item is defined, separated by the col on character (":").</li> <li>namespace-qualified -- the identifier of the YANG item is prefixed with the name of the module in which this item is defined, separated by the col on character (":").</li>
</ul> </ul>
<t>The name of a module determines the namespace of all YANG items defin ed in that module. If an item is defined in a submodule, then the namespace qual ified name uses the name of the main module to which the submodule belongs.</t> <t>The name of a module determines the namespace of all YANG items defin ed in that module. If an item is defined in a submodule, then the namespace-qual ified name uses the name of the main module to which the submodule belongs.</t>
<t>ABNF syntax <xref target="RFC5234"/> of a name is shown in <xref targ et="namesyntax"/>, where the production for "identifier" is defined in <xref sec tion="14" sectionFormat="of" target="RFC7950"/>.</t> <t>ABNF syntax <xref target="RFC5234"/> of a name is shown in <xref targ et="namesyntax"/>, where the production for "identifier" is defined in <xref sec tion="14" sectionFormat="of" target="RFC7950"/>.</t>
<figure anchor="namesyntax"> <figure anchor="namesyntax">
<name>ABNF Production for a simple or namespace qualified name</name> <name>ABNF Production for a Simple or Namespace-Qualified Name</name>
<artwork type="abnf" align="center"><![CDATA[ <sourcecode type="abnf"><![CDATA[
name = [identifier ":"] identifier name = [identifier ":"] identifier
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A namespace qualified name <bcp14>MUST</bcp14> be used for all member s of a top-level CBOR map and then also whenever the namespaces of the represent ation node and its parent node are different. In all other cases, the simple for m of the name <bcp14>MUST</bcp14> be used.</t> <t>A namespace-qualified name <bcp14>MUST</bcp14> be used for all member s of a top-level CBOR map and then also whenever the namespaces of the represent ation node and its parent node are different. In all other cases, the simple for m of the name <bcp14>MUST</bcp14> be used.</t>
<t>Definition example:</t> <t>Definition example:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
module example-foomod { module example-foomod {
container top { container top {
leaf foo { leaf foo {
type uint8; type uint8;
} }
} }
} }
module example-barmod { module example-barmod {
import example-foomod { import example-foomod {
skipping to change at line 337 skipping to change at line 343
} }
augment "/foomod:top" { augment "/foomod:top" {
leaf bar { leaf bar {
type boolean; type boolean;
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>A valid CBOR encoding of the 'top' container is as follows.</t> <t>A valid CBOR encoding of the 'top' container is as follows.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"example-foomod:top": { "example-foomod:top": {
"foo": 54, "foo": 54,
"example-barmod:bar": true "example-barmod:bar": true
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>Both the 'top' container and the 'bar' leaf defined in a different YA NG module as its parent container are encoded as namespace qualified names. The 'foo' leaf defined in the same YANG module as its parent container is encoded as simple name.</t> <t>Both the 'top' container and the 'bar' leaf defined in a different YA NG module as its parent container are encoded as namespace-qualified names. The 'foo' leaf defined in the same YANG module as its parent container is encoded as a simple name.</t>
</section> </section>
</section> </section>
<section anchor="instance-encoding"> <section anchor="instance-encoding">
<name>Encoding of Representation Nodes</name> <name>Encoding of Representation Nodes</name>
<t>Representation nodes defined using the YANG modeling language are encod ed using CBOR <xref target="RFC8949"/> based on the rules defined in this sectio n. We assume that the reader is <t>Representation nodes defined using the YANG modeling language are encod ed using CBOR <xref target="RFC8949"/>, based on the rules defined in this secti on. We assume that the reader is
already familiar with both YANG <xref target="RFC7950"/> and CBOR <xref target=" RFC8949"/>.</t> already familiar with both YANG <xref target="RFC7950"/> and CBOR <xref target=" RFC8949"/>.</t>
<section anchor="the-leaf"> <section anchor="the-leaf">
<name>The 'leaf'</name> <name>The 'leaf'</name>
<t>A 'leaf' <bcp14>MUST</bcp14> be encoded accordingly to its datatype u sing one of the encoding rules specified in <xref target="data-types-mapping"/>. </t> <t>A 'leaf' <bcp14>MUST</bcp14> be encoded accordingly to its datatype u sing one of the encoding rules specified in <xref target="data-types-mapping"/>. </t>
<t>The following examples show the encoding of a 'hostname' leaf using a SID or a name.</t> <t>The following examples show the encoding of a 'hostname' leaf using a SID or a name.</t>
<t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef domain-name { typedef domain-name {
type string { type string {
pattern pattern
'((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.'; + '|\.';
length "1..253"; length "1..253";
} }
} }
leaf hostname { leaf hostname {
type inet:domain-name; type inet:domain-name;
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="using-sids-in-keys"> <section anchor="using-sids-in-keys">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>As with all examples below, the delta in the outermost map assumes a reference YANG SID (current schema node) of 0.</t> <t>As with all examples below, the delta in the outermost map assumes a reference YANG SID (current schema node) of 0.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
1752 : "myhost.example.com" / hostname (SID 1752) / 1752 : "myhost.example.com" / hostname (SID 1752) /
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 06D8 # unsigned(1752) 19 06D8 # unsigned(1752)
72 # text(18) 72 # text(18)
6D79686F73742E6578616D706C652E636F6D # "myhost.example.com" 6D79686F73742E6578616D706C652E636F6D # "myhost.example.com"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys"> <section anchor="using-names-in-keys">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"ietf-system:hostname" : "myhost.example.com" "ietf-system:hostname" : "myhost.example.com"
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
74 # text(20) 74 # text(20)
696574662D73797374656D3A686F73746E616D65 696574662D73797374656D3A686F73746E616D65
72 # text(18) 72 # text(18)
6D79686F73742E6578616D706C652E636F6D 6D79686F73742E6578616D706C652E636F6D
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="container"> <section anchor="container">
<name>The 'container' and other nodes from the data tree</name> <name>The 'container' and Other Nodes from the Data Tree</name>
<t>Instances of containers, YANG data structures, notification contents, RPC inputs, RPC outputs, action inputs, and action outputs <bcp14>MUST</bcp14> be encoded using a CBOR map data item (major type 5). <t>Instances of containers, YANG data structures, notification contents, RPC inputs, RPC outputs, action inputs, and action outputs <bcp14>MUST</bcp14> be encoded using a CBOR map data item (major type 5).
The same encoding is also used for the list entries in a list (<xref target="lis The same encoding is also used for the list entries in a list (<xref targ
t"/>). et="list"/>) and for anydata nodes (<xref target="the-anydata"/>).
A map consists of pairs of data items, with each pair consisting of a key and a Collectively, we speak of these instances as "container-like instances".<
value. Each key within the CBOR map is set to a schema node identifier, each val /t>
ue is set to the value of this representation node according to the instance dat <t>A map consists of pairs of data items, with each pair consisting of a
atype.</t> key and a value. Each key within the CBOR map is set to a schema node identifie
<t>This specification supports two types of CBOR map keys; SID as define r, and each value is set to the value of this representation node according to t
d in <xref target="sid"/> and names as defined in <xref target="name"/>.</t> he instance datatype.</t>
<t>This specification supports two types of CBOR map keys: SID, as defin
ed in <xref target="sid"/>, and names, as defined in <xref target="name"/>.</t>
<t>The following examples show the encoding of a 'system-state' containe r representation instance using SIDs or names.</t> <t>The following examples show the encoding of a 'system-state' containe r representation instance using SIDs or names.</t>
<t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef date-and-time { typedef date-and-time {
type string { type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
+ '(Z|[\+\-]\d{2}:\d{2})'; + '(Z|[\+\-]\d{2}:\d{2})';
} }
} }
skipping to change at line 437 skipping to change at line 444
type date-and-time; type date-and-time;
} }
leaf boot-datetime { leaf boot-datetime {
type date-and-time; type date-and-time;
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="container-with-sid"> <section anchor="container-with-sid">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>In the context of containers and other nodes from the data tree, CB OR map keys within inner CBOR maps can be encoded using deltas (bare integers) o r absolute SIDs (tagged with tag number 47).</t> <t>In the context of containers and other nodes from the data tree, CB OR map keys within inner CBOR maps can be encoded using deltas (bare integers) o r absolute SIDs (tagged with tag number 47).</t>
<t>Delta values are computed as follows:</t> <t>Delta values are computed as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In the case of a 'container', deltas are equal to the SID of the current representation node minus the SID of the parent 'container'.</li> <li>In the case of a 'container', deltas are equal to the SID of the current representation node minus the SID of the parent 'container'.</li>
<li>In the case of a 'list', deltas are equal to the SID of the curr ent representation node minus the SID of the parent 'list'.</li> <li>In the case of a 'list', deltas are equal to the SID of the curr ent representation node minus the SID of the parent 'list'.</li>
<li>In the case of an 'RPC input' or 'RPC output', deltas are equal to the SID of the current representation node minus the SID of the 'RPC'.</li> <li>In the case of an 'RPC input' or 'RPC output', deltas are equal to the SID of the current representation node minus the SID of the 'RPC'.</li>
<li>In the case of an 'action input' or 'action output', deltas are equal to the SID of the current representation node minus the SID of the 'action '.</li> <li>In the case of an 'action input' or 'action output', deltas are equal to the SID of the current representation node minus the SID of the 'action '.</li>
<li>In the case of a 'notification content', deltas are equal to the SID of the current representation node minus the SID of the 'notification'.</li > <li>In the case of a 'notification content', deltas are equal to the SID of the current representation node minus the SID of the 'notification'.</li >
</ul> </ul>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
skipping to change at line 460 skipping to change at line 467
1720 : { / system-state (SID 1720) / 1720 : { / system-state (SID 1720) /
1 : { / clock (SID 1721) / 1 : { / clock (SID 1721) /
2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/ 2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) / 1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) /
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<figure anchor="Fig-system-clock"> <figure anchor="Fig-system-clock">
<name>System state clock encoding</name> <name>System State Clock Encoding</name>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 06B8 # unsigned(1720) 19 06B8 # unsigned(1720)
A1 # map(1) A1 # map(1)
01 # unsigned(1) 01 # unsigned(1)
A2 # map(2) A2 # map(2)
02 # unsigned(2) 02 # unsigned(2)
78 1A # text(26) 78 1A # text(26)
323031352D31302D30325431343A34373A32345A2D30353A3030 323031352D31302D30325431343A34373A32345A2D30353A3030
01 # unsigned(1) 01 # unsigned(1)
78 1A # text(26) 78 1A # text(26)
323031352D30392D31355430393A31323A35385A2D30353A3030 323031352D30392D31355430393A31323A35385A2D30353A3030
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="container-with-name"> <section anchor="container-with-name">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>CBOR map keys implemented using names <bcp14>MUST</bcp14> be encode d using a CBOR <t>CBOR map keys implemented using names <bcp14>MUST</bcp14> be encode d using a CBOR
text string data item (major type 3). A namespace-qualified name <bcp14>MUST</bc p14> text string data item (major type 3). A namespace-qualified name <bcp14>MUST</bc p14>
be used each time the namespace of a representation node and its parent be used each time the namespace of a representation node and its parent
differ. In all other cases, the simple form of the name <bcp14>MUST</bcp14> be differ. In all other cases, the simple form of the name <bcp14>MUST</bcp14> be
used. Names and namespaces are defined in <xref section="4" sectionFormat="of" t arget="RFC7951"/>.</t> used. Names and namespaces are defined in <xref section="4" sectionFormat="of" t arget="RFC7951"/>.</t>
<t>The following example shows the encoding of a 'system' container re presentation node instance using names.</t> <t>The following example shows the encoding of a 'system' container re presentation node instance using names.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"ietf-system:system-state" : { "ietf-system:system-state" : {
"clock" : { "clock" : {
"current-datetime" : "2015-10-02T14:47:24Z-05:00", "current-datetime" : "2015-10-02T14:47:24Z-05:00",
"boot-datetime" : "2015-09-15T09:12:58Z-05:00" "boot-datetime" : "2015-09-15T09:12:58Z-05:00"
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
78 18 # text(24) 78 18 # text(24)
696574662D73797374656D3A73797374656D2D7374617465 696574662D73797374656D3A73797374656D2D7374617465
A1 # map(1) A1 # map(1)
65 # text(5) 65 # text(5)
636C6F636B # "clock" 636C6F636B # "clock"
A2 # map(2) A2 # map(2)
70 # text(16) 70 # text(16)
63757272656E742D6461746574696D65 63757272656E742D6461746574696D65
skipping to change at line 518 skipping to change at line 525
6D # text(13) 6D # text(13)
626F6F742D6461746574696D65 626F6F742D6461746574696D65
78 1A # text(26) 78 1A # text(26)
323031352D30392D31355430393A31323A35385A2D30353A3030 323031352D30392D31355430393A31323A35385A2D30353A3030
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="leaf-list"> <section anchor="leaf-list">
<name>The 'leaf-list'</name> <name>The 'leaf-list'</name>
<t>A leaf-list <bcp14>MUST</bcp14> be encoded using a CBOR array data it em (major type 4). Each entry of this array <bcp14>MUST</bcp14> be encoded accor dingly to its datatype using one of the encoding rules specified in <xref target ="data-types-mapping"/>.</t> <t>A leaf-list <bcp14>MUST</bcp14> be encoded using a CBOR array data it em (major type 4). Each entry of this array <bcp14>MUST</bcp14> be encoded accor dingly to its datatype using one of the encoding rules specified in <xref target ="data-types-mapping"/>.</t>
<t>The following example shows the encoding of the 'search' leaf-list re presentation node instance containing two entries, "ietf.org" and "ieee.org".</t > <t>The following example shows the encoding of the 'search' leaf-list re presentation node instance containing two entries: "ietf.org" and "ieee.org".</t >
<t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC6991"/> and <xref ta rget="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef domain-name { typedef domain-name {
type string { type string {
pattern pattern
'((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.'; + '|\.';
length "1..253"; length "1..253";
} }
} }
leaf-list search { leaf-list search {
type domain-name; type domain-name;
ordered-by user; ordered-by user;
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="using-sids-in-keys-1"> <section anchor="using-sids-in-keys-1">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>CBOR diagnostic notation:</t> <t keepWithNext="true">CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
1746 : [ "ietf.org", "ieee.org" ] / search (SID 1746) / 1746 : [ "ietf.org", "ieee.org" ] / search (SID 1746) /
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 06D2 # unsigned(1746) 19 06D2 # unsigned(1746)
82 # array(2) 82 # array(2)
68 # text(8) 68 # text(8)
696574662E6F7267 # "ietf.org" 696574662E6F7267 # "ietf.org"
68 # text(8) 68 # text(8)
696565652E6F7267 # "ieee.org" 696565652E6F7267 # "ieee.org"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys-1"> <section anchor="using-names-in-keys-1">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"ietf-system:search" : [ "ietf.org", "ieee.org" ] "ietf-system:search" : [ "ietf.org", "ieee.org" ]
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
72 # text(18) 72 # text(18)
696574662D73797374656D3A736561726368 # "ietf-system:search" 696574662D73797374656D3A736561726368 # "ietf-system:search"
82 # array(2) 82 # array(2)
68 # text(8) 68 # text(8)
696574662E6F7267 # "ietf.org" 696574662E6F7267 # "ietf.org"
68 # text(8) 68 # text(8)
696565652E6F7267 # "ieee.org" 696565652E6F7267 # "ieee.org"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="list"> <section anchor="list">
<name>The 'list' and 'list' entries</name> <name>The 'list' and the 'list' Entries</name>
<t>A list or a subset of a list <bcp14>MUST</bcp14> be encoded using a C <t>A list or a subset of a list <bcp14>MUST</bcp14> be encoded using a C
BOR array data item (major type 4). Each list entry within this CBOR array is en BOR array data item (major type 4). Each list entry within this CBOR array is en
coded using a CBOR map data item (major type 5) based on the encoding rules of a coded using a CBOR map data item (major type 5) based on the encoding rules of a
collection as defined in <xref target="container"/>.</t> container-like instance, as defined in <xref target="container"/>.</t>
<t>It is important to note that this encoding rule also applies to a 'li st' representation node instance that has a single entry.</t> <t>It is important to note that this encoding rule also applies to a 'li st' representation node instance that has a single entry.</t>
<t>The following examples show the encoding of a 'server' list using SID s or names.</t> <t>The following examples show the encoding of a 'server' list using SID s or names.</t>
<t>Definition example simplified from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
list server { list server {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
choice transport { choice transport {
case udp { case udp {
container udp { container udp {
skipping to change at line 621 skipping to change at line 628
type boolean; type boolean;
default false; default false;
} }
leaf prefer { leaf prefer {
type boolean; type boolean;
default false; default false;
} }
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="list-with-sid"> <section anchor="list-with-sid">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>The encoding rules of each 'list' entry are defined in <xref target ="container-with-sid"/>.</t> <t>The encoding rules of each 'list' entry are defined in <xref target ="container-with-sid"/>.</t>
<t>CBOR diagnostic notation:</t> <t keepWithNext="true">CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
1756 : [ / server (SID 1756) / 1756 : [ / server (SID 1756) /
{ {
3 : "NRC TIC server", / name (SID 1759) / 3 : "NRC TIC server", / name (SID 1759) /
5 : { / udp (SID 1761) / 5 : { / udp (SID 1761) /
1 : "tic.nrc.ca", / address (SID 1762) / 1 : "tic.nrc.ca", / address (SID 1762) /
2 : 123 / port (SID 1763) / 2 : 123 / port (SID 1763) /
}, },
1 : 0, / association-type (SID 1757) / 1 : 0, / association-type (SID 1757) /
skipping to change at line 680 skipping to change at line 687
6E # text(14) 6E # text(14)
4E52432054414320736572766572 # "NRC TAC server" 4E52432054414320736572766572 # "NRC TAC server"
05 # unsigned(5) 05 # unsigned(5)
A1 # map(1) A1 # map(1)
01 # unsigned(1) 01 # unsigned(1)
6A # text(10) 6A # text(10)
7461632E6E72632E6361 # "tac.nrc.ca" 7461632E6E72632E6361 # "tac.nrc.ca"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys-2"> <section anchor="using-names-in-keys-2">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>The encoding rules of each 'list' entry are defined in <xref target ="container-with-name"/>.</t> <t>The encoding rules of each 'list' entry are defined in <xref target ="container-with-name"/>.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"ietf-system:server" : [ "ietf-system:server" : [
{ {
"name" : "NRC TIC server", "name" : "NRC TIC server",
"udp" : { "udp" : {
"address" : "tic.nrc.ca", "address" : "tic.nrc.ca",
"port" : 123 "port" : 123
skipping to change at line 705 skipping to change at line 712
}, },
{ {
"name" : "NRC TAC server", "name" : "NRC TAC server",
"udp" : { "udp" : {
"address" : "tac.nrc.ca" "address" : "tac.nrc.ca"
} }
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
72 # text(18) 72 # text(18)
696574662D73797374656D3A736572766572 696574662D73797374656D3A736572766572
82 # array(2) 82 # array(2)
A5 # map(5) A5 # map(5)
64 # text(4) 64 # text(4)
6E616D65 # "name" 6E616D65 # "name"
6E # text(14) 6E # text(14)
4E52432054494320736572766572 4E52432054494320736572766572
skipping to change at line 752 skipping to change at line 759
A1 # map(1) A1 # map(1)
67 # text(7) 67 # text(7)
61646472657373 # "address" 61646472657373 # "address"
6A # text(10) 6A # text(10)
7461632E6E72632E6361 # "tac.nrc.ca" 7461632E6E72632E6361 # "tac.nrc.ca"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="the-anydata"> <section anchor="the-anydata">
<name>The 'anydata'</name> <name>The 'anydata'</name>
<t>An anydata serves as a container for an arbitrary set of representati <t>An anydata node serves as a container for an arbitrary set of represen
on nodes that otherwise appear as normal YANG-modeled data. An anydata represent tation nodes that otherwise appear as normal YANG-modeled data. An anydata repre
ation node instance is encoded using the same rules as a container, i.e., CBOR m sentation node instance is encoded using the same rules as a container, i.e., us
ap. The requirement that anydata content can be modeled by YANG implies the foll ing a CBOR map data item (major type 5) based on the encoding rules of a contain
owing:</t> er-like instance, as defined in <xref target="container"/>.</t>
<ul spacing="normal"> <t>The following example shows a possible use of an anydata node. In thi
<li>CBOR map keys of any inner representation nodes <bcp14>MUST</bcp14 s example, an anydata node is used to define a representation node containing a
> be set to valid deltas or names.</li> notification event; this representation node can be part of a YANG list to creat
<li>CBOR arrays <bcp14>MUST</bcp14> contain either unique scalar value e an event logger.</t>
s (as a leaf-list, see <xref target="leaf-list"/>), or maps (as a list, see <xre
f target="list"/>).</li>
<li>CBOR map values <bcp14>MUST</bcp14> follow the encoding rules of o
ne of the datatypes listed in <xref target="instance-encoding"/>.</li>
</ul>
<t>The following example shows a possible use of an anydata. In this exa
mple, an anydata is used to define a representation node containing a notificati
on event; this representation node can be part of a YANG list to create an event
logger.</t>
<t>Definition example:</t> <t>Definition example:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
module event-log { module event-log {
... ...
anydata last-event; # SID 60123 anydata last-event; // SID 60123
} }
]]></sourcecode> ]]></sourcecode>
<t>This example also assumes the assistance of the following notificatio n.</t> <t>This example also assumes the assistance of the following notificatio n.</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
module example-port { module example-port {
... ...
notification example-port-fault { # SID 60200 notification example-port-fault { // SID 60200
leaf port-name { # SID 60201 leaf port-name { // SID 60201
type string; type string;
} }
leaf port-fault { # SID 60202 leaf port-fault { // SID 60202
type string; type string;
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="using-sids-in-keys-2"> <section anchor="using-sids-in-keys-2">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
60123 : { / last-event (SID 60123) / 60123 : { / last-event (SID 60123) /
77 : { / example-port-fault (SID 60200) / 77 : { / example-port-fault (SID 60200) /
1 : "0/4/21", / port-name (SID 60201) / 1 : "0/4/21", / port-name (SID 60201) /
2 : "Open pin 2" / port-fault (SID 60202) / 2 : "Open pin 2" / port-fault (SID 60202) /
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 EADB # unsigned(60123) 19 EADB # unsigned(60123)
A1 # map(1) A1 # map(1)
18 4D # unsigned(77) 18 4D # unsigned(77)
A2 # map(2) A2 # map(2)
01 # unsigned(1) 01 # unsigned(1)
66 # text(6) 66 # text(6)
302F342F3231 # "0/4/21" 302F342F3231 # "0/4/21"
02 # unsigned(2) 02 # unsigned(2)
skipping to change at line 822 skipping to change at line 824
60123 : { / last-event (SID 60123) / 60123 : { / last-event (SID 60123) /
47(60200) : { / event-port-fault (SID 60200) / 47(60200) : { / event-port-fault (SID 60200) /
1 : "0/4/21", / port-name (SID 60201) / 1 : "0/4/21", / port-name (SID 60201) /
2 : "Open pin 2" / port-fault (SID 60202) / 2 : "Open pin 2" / port-fault (SID 60202) /
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys-3"> <section anchor="using-names-in-keys-3">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"event-log:last-event" : { "event-log:last-event" : {
"example-port:example-port-fault" : { "example-port:example-port-fault" : {
"port-name" : "0/4/21", "port-name" : "0/4/21",
"port-fault" : "Open pin 2" "port-fault" : "Open pin 2"
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
74 # text(20) 74 # text(20)
6576656E742D6C6F673A6C6173742D6576656E74 6576656E742D6C6F673A6C6173742D6576656E74
A1 # map(1) A1 # map(1)
78 1F # text(31) 78 1F # text(31)
6578616D706C652D706F72743A 6578616D706C652D706F72743A
6578616D706C652D706F72742D6661756C74 6578616D706C652D706F72742D6661756C74
A2 # map(2) A2 # map(2)
69 # text(9) 69 # text(9)
skipping to change at line 860 skipping to change at line 862
6A # text(10) 6A # text(10)
4F70656E2070696E2032 # "Open pin 2" 4F70656E2070696E2032 # "Open pin 2"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="the-anyxml"> <section anchor="the-anyxml">
<name>The 'anyxml'</name> <name>The 'anyxml'</name>
<t>An anyxml representation node is used to serialize an arbitrary CBOR content, i.e., its value can be any CBOR binary object. <t>An anyxml representation node is used to serialize an arbitrary CBOR content, i.e., its value can be any CBOR binary object.
(The "xml" in the name is a misnomer that only applied to YANG-XML <xref target= "RFC7950"/>.) (The "xml" in the name is a misnomer that only applied to YANG-XML <xref target= "RFC7950"/>.)
An anyxml value <bcp14>MAY</bcp14> contain CBOR data items tagged with one of th e tags listed in <xref target="tag-registry"/>. The tags listed in <xref target= "tag-registry"/> <bcp14>SHALL</bcp14> be supported.</t> An anyxml value <bcp14>MAY</bcp14> contain CBOR data items tagged with one of th e tags listed in <xref target="tag-registry"/>. The tags listed in <xref target= "tag-registry"/> <bcp14>SHALL</bcp14> be supported.</t>
<t>The following example shows a valid CBOR encoded anyxml representatio <t>The following example shows a valid CBOR-encoded anyxml representatio
n node instance consisting of a CBOR array containing the CBOR simple values 'tr n node instance consisting of a CBOR array containing the CBOR simple values 'tr
ue', 'null' and 'true'.</t> ue', 'null', and 'true'.</t>
<t>Definition example from <xref target="RFC7951"/>:</t> <t>Definition example adapted from <xref target="RFC7951"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
module bar-module { module bar-module {
... ...
anyxml bar; # SID 60000 anyxml bar; // SID 60000
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="using-sids-in-keys-3"> <section anchor="using-sids-in-keys-3">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
60000 : [true, null, true] / bar (SID 60000) / 60000 : [true, null, true] / bar (SID 60000) /
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 EA60 # unsigned(60000) 19 EA60 # unsigned(60000)
83 # array(3) 83 # array(3)
F5 # primitive(21) F5 # primitive(21)
F6 # primitive(22) F6 # primitive(22)
F5 # primitive(21) F5 # primitive(21)
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys-4"> <section anchor="using-names-in-keys-4">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"bar-module:bar" : [true, null, true] / bar (SID 60000) / "bar-module:bar" : [true, null, true] / bar (SID 60000) /
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
6E # text(14) 6E # text(14)
6261722D6D6F64756C653A626172 # "bar-module:bar" 6261722D6D6F64756C653A626172 # "bar-module:bar"
83 # array(3) 83 # array(3)
F5 # primitive(21) F5 # primitive(21)
F6 # primitive(22) F6 # primitive(22)
F5 # primitive(21) F5 # primitive(21)
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="encoding-of-yang-data-extension"> <section anchor="encoding-of-yang-data-extension">
<name>Encoding of 'yang-data' extension</name> <name>Encoding of the 'yang-data' Extension</name>
<t>The yang-data extension <xref target="RFC8040"/> is used to define data structures in YANG <t>The yang-data extension <xref target="RFC8040"/> is used to define data structures in YANG
that are not intended to be implemented as part of a datastore.</t> that are not intended to be implemented as part of a datastore.</t>
<t>The yang-data extension will specify a container that <bcp14>MUST</bcp1 4> be encoded using the encoding rules of nodes of data trees as defined in <xre f target="container"/>.</t> <t>The yang-data extension will specify a container that <bcp14>MUST</bcp1 4> be encoded using the encoding rules of nodes of data trees, as defined in <xr ef target="container"/>.</t>
<t>Just like YANG containers, the yang-data extension can be encoded using either SIDs or names.</t> <t>Just like YANG containers, the yang-data extension can be encoded using either SIDs or names.</t>
<t>Definition example from <xref target="I-D.ietf-core-comi"/> Appendix A: </t> <t>Definition example adapted from <xref target="I-D.ietf-core-comi" secti onFormat="of" section="A"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
module ietf-coreconf { module ietf-coreconf {
... ...
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
} }
rc:yang-data yang-errors { rc:yang-data yang-errors {
container error { container error {
skipping to change at line 945 skipping to change at line 947
type instance-identifier; type instance-identifier;
} }
leaf error-message { leaf error-message {
type string; type string;
} }
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<section anchor="using-sids-in-keys-4"> <section anchor="using-sids-in-keys-4">
<name>Using SIDs in keys</name> <name>Using SIDs in Keys</name>
<t>The yang-data extensions encoded using SIDs are carried in a CBOR map <t>The yang-data extensions encoded using SIDs are carried in a CBOR map
containing a single item pair. The key of this item is set to the SID assigned containing a single item pair. The key of this item is set to the SID assigned
to the yang-data extension container; the value is set to the CBOR encoding of t to the yang-data extension container; the value is set to the CBOR encoding of t
his container as defined in <xref target="container"/>.</t> his container, as defined in <xref target="container"/>.</t>
<t>This example shows a serialization example of the yang-errors yang-da <t>This example shows a serialization example of the yang-errors yang-da
ta extension as defined in <xref target="I-D.ietf-core-comi"/> using SIDs as def ta extension, as defined in <xref target="I-D.ietf-core-comi"/>, using SIDs, as
ined in <xref target="sid"/>.</t> defined in <xref target="sid"/>.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
1024 : { / error (SID 1024) / 1024 : { / error (SID 1024) /
4 : 1011, / error-tag (SID 1028) / 4 : 1011, / error-tag (SID 1028) /
/ = invalid-value (SID 1011) / / = invalid-value (SID 1011) /
1 : 1018, / error-app-tag (SID 1025) / 1 : 1018, / error-app-tag (SID 1025) /
/ = not-in-range (SID 1018) / / = not-in-range (SID 1018) /
2 : 1740, / error-data-node (SID 1026) / 2 : 1740, / error-data-node (SID 1026) /
/ = timezone-utc-offset (SID 1740) / / = timezone-utc-offset (SID 1740) /
3 : "Maximum exceeded" / error-message (SID 1027) / 3 : "Maximum exceeded" / error-message (SID 1027) /
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
19 0400 # unsigned(1024) 19 0400 # unsigned(1024)
A4 # map(4) A4 # map(4)
04 # unsigned(4) 04 # unsigned(4)
19 03F3 # unsigned(1011) 19 03F3 # unsigned(1011)
01 # unsigned(1) 01 # unsigned(1)
19 03FA # unsigned(1018) 19 03FA # unsigned(1018)
02 # unsigned(2) 02 # unsigned(2)
19 06CC # unsigned(1740) 19 06CC # unsigned(1740)
03 # unsigned(3) 03 # unsigned(3)
70 # text(16) 70 # text(16)
4D6178696D756D206578636565646564 # "Maximum exceeded" 4D6178696D756D206578636565646564 # "Maximum exceeded"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="using-names-in-keys-5"> <section anchor="using-names-in-keys-5">
<name>Using names in keys</name> <name>Using Names in Keys</name>
<t>The yang-data extensions encoded using names are carried in a CBOR ma <t>The yang-data extensions encoded using names are carried in a CBOR ma
p containing a single item pair. The key of this item is set to the namespace qu p containing a single item pair. The key of this item is set to the namespace-qu
alified name of the yang-data extension container; the value is set to the CBOR alified name of the yang-data extension container; the value is set to the CBOR
encoding of this container as defined in <xref target="container"/>.</t> encoding of this container, as defined in <xref target="container"/>.</t>
<t>This example shows a serialization example of the yang-errors yang-da <t>This example shows a serialization example of the yang-errors yang-da
ta extension as defined in <xref target="I-D.ietf-core-comi"/> using names as de ta extension, as defined in <xref target="I-D.ietf-core-comi"/>, using names, as
fined <xref target="name"/>.</t> defined <xref target="name"/>.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ {
"ietf-coreconf:error" : { "ietf-coreconf:error" : {
"error-tag" : "invalid-value", "error-tag" : "invalid-value",
"error-app-tag" : "not-in-range", "error-app-tag" : "not-in-range",
"error-data-node" : "timezone-utc-offset", "error-data-node" : "timezone-utc-offset",
"error-message" : "Maximum exceeded" "error-message" : "Maximum exceeded"
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
A1 # map(1) A1 # map(1)
73 # text(19) 73 # text(19)
696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error" 696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error"
A4 # map(4) A4 # map(4)
69 # text(9) 69 # text(9)
6572726F722D746167 # "error-tag" 6572726F722D746167 # "error-tag"
6D # text(13) 6D # text(13)
696E76616C69642D76616C7565 # "invalid-value" 696E76616C69642D76616C7565 # "invalid-value"
6D # text(13) 6D # text(13)
skipping to change at line 1023 skipping to change at line 1025
6572726F722D6D657373616765 # "error-message" 6572726F722D6D657373616765 # "error-message"
70 # text(16) 70 # text(16)
4D6178696D756D206578636565646564 # "Maximum exceeded" 4D6178696D756D206578636565646564 # "Maximum exceeded"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="data-types-mapping"> <section anchor="data-types-mapping">
<name>Representing YANG Data Types in CBOR</name> <name>Representing YANG Data Types in CBOR</name>
<t>The CBOR encoding of an instance of a leaf or leaf-list representation node <t>The CBOR encoding of an instance of a leaf or leaf-list representation node
depends on the built-in type of that representation node. The following depends on the built-in type of that representation node. The following
sub-section defines the CBOR encoding of each built-in type supported subsection defines the CBOR encoding of each built-in type supported
by YANG as listed in <xref section="4.2.4" sectionFormat="of" target="RFC7950"/> by YANG, as listed in <xref section="4.2.4" sectionFormat="of" target="RFC7950"/
. Each subsection shows an example value assigned to a representation node insta >. Each subsection shows an example value assigned to a representation node inst
nce of the discussed built-in type.</t> ance of the discussed built-in type.</t>
<section anchor="the-unsigned-integer-types"> <section anchor="the-unsigned-integer-types">
<name>The unsigned integer Types</name> <name>The Unsigned Integer Types</name>
<t>Leafs of type uint8, uint16, uint32 and uint64 <bcp14>MUST</bcp14> be <t>Leafs of type uint8, uint16, uint32, and uint64 <bcp14>MUST</bcp14> b
encoded using a CBOR e encoded using a CBOR
unsigned integer data item (major type 0).</t> unsigned integer data item (major type 0).</t>
<t>The following example shows the encoding of an 'mtu' leaf representat ion node instance set to 1280 bytes.</t> <t>The following example shows the encoding of an 'mtu' leaf representat ion node instance set to 1280 bytes.</t>
<t>Definition example from <xref target="RFC8344"/>:</t> <t>Definition example adapted from <xref target="RFC8344"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf mtu { leaf mtu {
type uint16 { type uint16 {
range "68..max"; range "68..max";
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 1280</t> <t>CBOR diagnostic notation: 1280</t>
<t>CBOR encoding: 19 0500</t> <t>CBOR encoding: 19 0500</t>
</section> </section>
<section anchor="the-integer-types"> <section anchor="the-integer-types">
<name>The integer Types</name> <name>The Integer Types</name>
<t>Leafs of type int8, int16, int32 and int64 <bcp14>MUST</bcp14> be enc <t>Leafs of type int8, int16, int32, and int64 <bcp14>MUST</bcp14> be en
oded using either CBOR coded using either a CBOR
unsigned integer (major type 0) or CBOR negative integer (major type 1), dependi unsigned integer (major type 0) or a CBOR negative integer (major type 1), depen
ng ding
on the actual value.</t> on the actual value.</t>
<t>The following example shows the encoding of a 'timezone-utc-offset' l eaf representation node instance set to -300 minutes.</t> <t>The following example shows the encoding of a 'timezone-utc-offset' l eaf representation node instance set to -300 minutes.</t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf timezone-utc-offset { leaf timezone-utc-offset {
type int16 { type int16 {
range "-1500 .. 1500"; range "-1500 .. 1500";
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: -300</t> <t>CBOR diagnostic notation: -300</t>
<t>CBOR encoding: 39 012B</t> <t>CBOR encoding: 39 012B</t>
</section> </section>
<section anchor="the-decimal64-type"> <section anchor="the-decimal64-type">
<name>The 'decimal64' Type</name> <name>The 'decimal64' Type</name>
<t>Leafs of type decimal64 <bcp14>MUST</bcp14> be encoded using a decima l fraction as defined in <xref section="3.4.4" sectionFormat="of" target="RFC894 9"/>.</t> <t>Leafs of type decimal64 <bcp14>MUST</bcp14> be encoded using a decima l fraction, as defined in <xref section="3.4.4" sectionFormat="of" target="RFC89 49"/>.</t>
<t>The following example shows the encoding of a 'my-decimal' leaf repre sentation node instance set to 2.57.</t> <t>The following example shows the encoding of a 'my-decimal' leaf repre sentation node instance set to 2.57.</t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf my-decimal { leaf my-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max"; range "1 .. 3.14 | 10 | 20..max";
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 4([-2, 257])</t> <t>CBOR diagnostic notation: 4([-2, 257])</t>
<t>CBOR encoding: C4 82 21 19 0101</t> <t>CBOR encoding: C4 82 21 19 0101</t>
</section> </section>
<section anchor="the-string-type"> <section anchor="the-string-type">
<name>The 'string' Type</name> <name>The 'string' Type</name>
<t>Leafs of type string <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major <t>Leafs of type string <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major
type 3).</t> type 3).</t>
<t>The following example shows the encoding of a 'name' leaf representat ion node instance set to "eth0".</t> <t>The following example shows the encoding of a 'name' leaf representat ion node instance set to "eth0".</t>
<t>Definition example from <xref target="RFC8343"/>:</t> <t>Definition example adapted from <xref target="RFC8343"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf name { leaf name {
type string; type string;
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: "eth0"</t> <t>CBOR diagnostic notation: "eth0"</t>
<t>CBOR encoding: 64 65746830</t> <t>CBOR encoding: 64 65746830</t>
</section> </section>
<section anchor="the-boolean-type"> <section anchor="the-boolean-type">
<name>The 'boolean' Type</name> <name>The 'boolean' Type</name>
<t>Leafs of type boolean <bcp14>MUST</bcp14> be encoded using a CBOR sim ple value 'true' (major type 7, additional information 21) or 'false' (major typ e 7, additional information 20).</t> <t>Leafs of type boolean <bcp14>MUST</bcp14> be encoded using a CBOR sim ple value 'true' (major type 7, additional information 21) or 'false' (major typ e 7, additional information 20).</t>
<t>The following example shows the encoding of an 'enabled' leaf represe ntation node instance set to 'true'.</t> <t>The following example shows the encoding of an 'enabled' leaf represe ntation node instance set to 'true'.</t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf enabled { leaf enabled {
type boolean; type boolean;
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: true</t> <t>CBOR diagnostic notation: true</t>
<t>CBOR encoding: F5</t> <t>CBOR encoding: F5</t>
</section> </section>
<section anchor="enumeration"> <section anchor="enumeration">
<name>The 'enumeration' Type</name> <name>The 'enumeration' Type</name>
<t>Leafs of type enumeration <bcp14>MUST</bcp14> be encoded using a CBOR unsigned <t>Leafs of type enumeration <bcp14>MUST</bcp14> be encoded using a CBOR unsigned
integer (major type 0) or CBOR negative integer (major type 1), integer (major type 0) or CBOR negative integer (major type 1),
depending on the actual value, or exceptionally as a tagged text string (see bel ow). depending on the actual value, or exceptionally as a tagged text string (see bel ow).
Enumeration values are either Enumeration values are either
explicitly assigned using the YANG statement 'value' or automatically explicitly assigned using the YANG statement 'value' or automatically
assigned based on the algorithm defined in <xref section="9.6.4.2" sectionFormat ="of" target="RFC7950"/>.</t> assigned based on the algorithm defined in <xref section="9.6.4.2" sectionFormat ="of" target="RFC7950"/>.</t>
<t>The following example shows the encoding of an 'oper-status' leaf rep resentation node instance set to 'testing'.</t> <t>The following example shows the encoding of an 'oper-status' leaf rep resentation node instance set to 'testing'.</t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t keepWithNext="true">Definition example adapted from <xref target="RFC 7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf oper-status { leaf oper-status {
type enumeration { type enumeration {
enum up { value 1; } enum up { value 1; }
enum down { value 2; } enum down { value 2; }
enum testing { value 3; } enum testing { value 3; }
enum unknown { value 4; } enum unknown { value 4; }
enum dormant { value 5; } enum dormant { value 5; }
enum not-present { value 6; } enum not-present { value 6; }
enum lower-layer-down { value 7; } enum lower-layer-down { value 7; }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 3</t> <t>CBOR diagnostic notation: 3</t>
<t>CBOR encoding: 03</t> <t>CBOR encoding: 03</t>
<t>Values of 'enumeration' types defined in a 'union' type <bcp14>MUST</ bcp14> be encoded using a <t>Values of 'enumeration' types defined in a 'union' type <bcp14>MUST</ bcp14> be encoded using a
CBOR text string data item (major type 3) and <bcp14>MUST</bcp14> contain one of the names CBOR text string data item (major type 3) and <bcp14>MUST</bcp14> contain one of the names
assigned by 'enum' statements in YANG (see also <xref target="union"/>). assigned by 'enum' statements in YANG (see also <xref target="union"/>).
The encoding <bcp14>MUST</bcp14> be enclosed by the The encoding <bcp14>MUST</bcp14> be enclosed by the
enumeration CBOR tag as specified in <xref target="tag-registry"/>.</t> enumeration CBOR tag, as specified in <xref target="tag-registry"/>.</t>
<t>Definition example from <xref target="RFC7950"/>:</t> <t>Definition example adapted from <xref target="RFC7950"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum unbounded; enum unbounded;
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 44("unbounded")</t> <t>CBOR diagnostic notation: 44("unbounded")</t>
<t>CBOR encoding: D8 2C 69 756E626F756E646564</t> <t>CBOR encoding: D8 2C 69 756E626F756E646564</t>
</section> </section>
<section anchor="bits"> <section anchor="bits">
<name>The 'bits' Type</name> <name>The 'bits' Type</name>
<t>Keeping in mind that bit positions are either explicitly assigned usi ng the <t>Keeping in mind that bit positions are either explicitly assigned usi ng the
YANG statement 'position' or automatically assigned based on the algorithm YANG statement 'position' or automatically assigned based on the algorithm
defined in <xref section="9.7.4.2" sectionFormat="of" target="RFC7950"/>, each e lement of type bits could be seen defined in <xref section="9.7.4.2" sectionFormat="of" target="RFC7950"/>, each e lement of type bits could be seen
as a set of bit positions (or offsets from position 0), that have a value of as a set of bit positions (or offsets from position 0) that have a value of
either 1, which represents the bit being set or 0, which represents that the bit either 1, which represents the bit being set, or 0, which represents that the bi
t
is not set.</t> is not set.</t>
<t>Leafs of type bits <bcp14>MUST</bcp14> be encoded either using a CBOR <t>Leafs of type bits <bcp14>MUST</bcp14> be encoded either using a CBOR
array or byte string array (major type 4) or byte string
(major type 2), or exceptionally as a tagged text string (see below). In case CB (major type 2) or exceptionally as a tagged text string (see below). In case CBO
OR array representation is used, each element is R array representation is used, each element is
either a positive integer (major type 0 with value 0 being either (1) a positive integer (major type 0 with value 0 being
disallowed) that can be used to calculate the offset of the next byte string, or disallowed) that can be used to calculate the offset of the next byte string or
a byte (2) a byte
string (major type 2) that carries the information whether certain bits are set string (major type 2) that carries the information regarding whether certain bit
or not. The initial offset value is 0 and each unsigned integer modifies the s are set
or not. The initial offset value is 0, and each unsigned integer modifies the
offset value of the next byte string by the integer value multiplied by 8. For offset value of the next byte string by the integer value multiplied by 8. For
example, if the bit offset is 0 and there is an integer with value 5, the first example, if the bit offset is 0 and there is an integer with value 5, the first
byte of the byte string that follows will represent bit positions 40 to 47 both byte of the byte string that follows will represent bit positions 40 to 47, with both
ends included. If the byte string has a second byte, it will carry information ends included. If the byte string has a second byte, it will carry information
about bits 48 to 55 and so on. Within each byte, bits are assigned from least about bits 48 to 55, and so on. Within each byte, bits are assigned from least
to most significant. After the byte string, the offset is modified by the number to most significant. After the byte string, the offset is modified by the number
of bytes in the byte string multiplied by 8. of bytes in the byte string multiplied by 8.
Bytes with no bits set (zero bytes) at the end of the byte string are never gene Bytes with no bits set (zero bytes) at the end of the byte string are never gene
rated: rated.
If they would occur at the end of the array, the zero bytes are simply omitted; If they occur at the end of the array, the zero bytes are simply omitted;
if they occur at the end of a byte string preceding an integer, the if they occur at the end of a byte string preceding an integer, the
zero bytes are removed and the integer adjusted upwards by the number zero bytes are removed and the integer is adjusted upwards by the number
of zero bytes removed. of zero bytes that were removed.
An example follows.</t> An example follows.</t>
<t>The following example shows the encoding of an 'alarm-state' leaf rep resentation node <t>The following example shows the encoding of an 'alarm-state' leaf rep resentation node
instance with the 'critical' (position 2), 'warning' (position 8) and instance with the 'critical' (position 2), 'warning' (position 8), and
'indeterminate' (position 128) flags set.</t> 'indeterminate' (position 128) flags set.</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef alarm-state { typedef alarm-state {
type bits { type bits {
bit unknown; bit unknown;
bit under-repair; bit under-repair;
bit critical; bit critical;
bit major; bit major;
bit minor; bit minor;
bit warning { bit warning {
skipping to change at line 1196 skipping to change at line 1198
} }
} }
} }
leaf alarm-state { leaf alarm-state {
type alarm-state; type alarm-state;
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: [h'0401', 14, h'01']</t> <t>CBOR diagnostic notation: [h'0401', 14, h'01']</t>
<t>CBOR encoding: 83 42 0401 0E 41 01</t> <t>CBOR encoding: 83 42 0401 0E 41 01</t>
<t>In a number of cases the array would only need to have one element -- a byte string with a few bytes inside. <t>In a number of cases, the array would only need to have one element - - a byte string with a few bytes inside.
For this case, it is <bcp14>REQUIRED</bcp14> to omit the array element and have only the byte array that would have been inside. For this case, it is <bcp14>REQUIRED</bcp14> to omit the array element and have only the byte array that would have been inside.
To illustrate this, let us consider the same example YANG definition, but this t ime encoding only 'under-repair' and 'critical' flags. To illustrate this, let us consider the same example YANG definition but this ti me encoding only 'under-repair' and 'critical' flags.
The result would be</t> The result would be</t>
<t>CBOR diagnostic notation: h'06'</t> <t>CBOR diagnostic notation: h'06'</t>
<t>CBOR encoding: 41 06</t> <t>CBOR encoding: 41 06</t>
<t>Elements in the array <bcp14>MUST</bcp14> be either byte strings that do not end in <t>Elements in the array <bcp14>MUST</bcp14> be either byte strings that do not end in
a zero byte, or positive unsigned a zero byte or positive unsigned
integers, where byte strings and integers <bcp14>MUST</bcp14> alternate, i.e., a djacent byte integers, where byte strings and integers <bcp14>MUST</bcp14> alternate, i.e., a djacent byte
strings or adjacent integers are an error. An array with a single byte string strings or adjacent integers are an error. An array with a single byte string
<bcp14>MUST</bcp14> instead be encoded as just that byte string. An array with a single <bcp14>MUST</bcp14> instead be encoded as just that byte string. An array with a single
positive integer is an error. positive integer is an error.
Note that a recipient can handle trailing zero bytes in the byte strings using t he normal Note that a recipient can handle trailing zero bytes in the byte strings using t he normal
rules without any issue, so an implementation <bcp14>MAY</bcp14> silently accept them.</t> rules without any issue, so an implementation <bcp14>MAY</bcp14> silently accept them.</t>
<t>Values of 'bits' types defined in a 'union' type <bcp14>MUST</bcp14> be encoded using a <t>Values of 'bits' types defined in a 'union' type <bcp14>MUST</bcp14> be encoded using a
CBOR text string data item (major type 3) and <bcp14>MUST</bcp14> contain a spac e-separated CBOR text string data item (major type 3) and <bcp14>MUST</bcp14> contain a spac e-separated
sequence of names of 'bits' that are set (see also <xref target="union"/>). sequence of names of 'bits' that are set (see also <xref target="union"/>).
The encoding <bcp14>MUST</bcp14> be enclosed by the The encoding <bcp14>MUST</bcp14> be enclosed by the
bits CBOR tag as specified in <xref target="tag-registry"/>.</t> bits CBOR tag, as specified in <xref target="tag-registry"/>.</t>
<t>The following example shows the encoding of an 'alarm-state' leaf rep resentation node <t>The following example shows the encoding of an 'alarm-state' leaf rep resentation node
instance defined using a union type with the 'under-repair' and 'critical' instance defined using a union type with the 'under-repair' and 'critical'
flags set.</t> flags set.</t>
<t>Definition example:</t> <t>Definition example:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf alarm-state-2 { leaf alarm-state-2 {
type union { type union {
type alarm-state; type alarm-state;
type bits { type bits {
bit extra-flag; bit extra-flag;
skipping to change at line 1254 skipping to change at line 1256
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E'</t> <t>CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E'</t>
<t>CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E</t> <t>CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E</t>
</section> </section>
<section anchor="the-leafref-type"> <section anchor="the-leafref-type">
<name>The 'leafref' Type</name> <name>The 'leafref' Type</name>
<t>Leafs of type leafref <bcp14>MUST</bcp14> be encoded using the rules of the representation node referenced <t>Leafs of type leafref <bcp14>MUST</bcp14> be encoded using the rules of the representation node referenced
by the 'path' YANG statement.</t> by the 'path' YANG statement.</t>
<t>The following example shows the encoding of an 'interface-state-ref' leaf representation node instance set to "eth1".</t> <t>The following example shows the encoding of an 'interface-state-ref' leaf representation node instance set to "eth1".</t>
<t>Definition example from <xref target="RFC8343"/>:</t> <t>Definition example adapted from <xref target="RFC8343"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef interface-state-ref { typedef interface-state-ref {
type leafref { type leafref {
path "/interfaces-state/interface/name"; path "/interfaces-state/interface/name";
} }
} }
container interfaces-state { container interfaces-state {
list interface { list interface {
key "name"; key "name";
skipping to change at line 1280 skipping to change at line 1282
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: "eth1"</t> <t>CBOR diagnostic notation: "eth1"</t>
<t>CBOR encoding: 64 65746831</t> <t>CBOR encoding: 64 65746831</t>
</section> </section>
<section anchor="identityref"> <section anchor="identityref">
<name>The 'identityref' Type</name> <name>The 'identityref' Type</name>
<t>This specification supports two approaches for encoding identityref: <t>This specification supports two approaches for encoding identityref:
as a YANG Schema Item iDentifier as defined in <xref target="sid"/>, or as a nam e as a YANG Schema Item iDentifier, as defined in <xref target="sid"/>, or as a na me,
as defined in <xref section="6.8" sectionFormat="of" target="RFC7951"/>. as defined in <xref section="6.8" sectionFormat="of" target="RFC7951"/>.
See <xref target="union"/> for an exceptional case when this representation need s to be tagged.</t> See <xref target="union"/> for an exceptional case when this representation need s to be tagged.</t>
<section anchor="identityref-with-sid"> <section anchor="identityref-with-sid">
<name>SIDs as identityref</name> <name>SIDs as 'identityref'</name>
<t>When representation nodes of type identityref are implemented using <t>When representation nodes of type identityref are implemented using
SIDs, they <bcp14>MUST</bcp14> be encoded using a CBOR unsigned integer data it SIDs, they <bcp14>MUST</bcp14> be encoded using a CBOR unsigned integer data it
em (major type 0). (Note that, as they are not used in the position of CBOR map em (major type 0).
keys, no delta mechanism is employed for SIDs used for identityref.)</t> (Note that, as they are not used in the position of CBOR map keys, no d
elta mechanism is employed for SIDs used for identityref.)</t>
<t>The following example shows the encoding of a 'type' leaf represent ation node instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880).</ t> <t>The following example shows the encoding of a 'type' leaf represent ation node instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880).</ t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
identity interface-type { identity interface-type {
} }
identity iana-interface-type { identity iana-interface-type {
base interface-type; base interface-type;
} }
identity ethernetCsmacd { identity ethernetCsmacd {
base iana-interface-type; base iana-interface-type;
skipping to change at line 1310 skipping to change at line 1313
leaf type { leaf type {
type identityref { type identityref {
base interface-type; base interface-type;
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 1880</t> <t>CBOR diagnostic notation: 1880</t>
<t>CBOR encoding: 19 0758</t> <t>CBOR encoding: 19 0758</t>
</section> </section>
<section anchor="name-as-identityref"> <section anchor="name-as-identityref">
<name>Name as identityref</name> <name>Name as 'identityref'</name>
<t>Alternatively, an identityref <bcp14>MAY</bcp14> be encoded using a <t>Alternatively, an identityref <bcp14>MAY</bcp14> be encoded using a
name as defined in <xref target="name"/>. When names are used, identityref <bc name, as defined in <xref target="name"/>. When names are used, identityref <b
p14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3). I cp14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3).
f the identity is defined in different module than the leaf node containing the If the identity is defined in a different module than the leaf node containing t
identityref data node, the namespace qualified form <bcp14>MUST</bcp14> be used. he identityref data node, the namespace-qualified form <bcp14>MUST</bcp14> be us
Otherwise, both the simple and namespace qualified forms are permitted. Names a ed. Otherwise, both the simple and namespace-qualified forms are permitted. Name
nd namespaces are defined in <xref target="name"/>.</t> s and namespaces are defined in <xref target="name"/>.</t>
<t>The following example shows the encoding of the identity 'iana-if-t <t>The following example shows the encoding of the identity 'iana-if-t
ype:ethernetCsmacd' using its namespace qualified name. This example is describe ype:ethernetCsmacd' using its namespace-qualified name. This example is describe
d in <xref target="identityref-with-sid"/>.</t> d in <xref target="identityref-with-sid"/>.</t>
<t>CBOR diagnostic notation: "iana-if-type:ethernetCsmacd"</t> <t>CBOR diagnostic notation: "iana-if-type:ethernetCsmacd"</t>
<t>CBOR encoding: 78 1b 69616E612D69662D747970653A65746865726E65744373 6D616364</t> <t>CBOR encoding: 78 1B 69616E612D69662D747970653A65746865726E65744373 6D616364</t>
</section> </section>
</section> </section>
<section anchor="the-empty-type"> <section anchor="the-empty-type">
<name>The 'empty' Type</name> <name>The 'empty' Type</name>
<t>Leafs of type empty <bcp14>MUST</bcp14> be encoded using the CBOR nul l value (major type <t>Leafs of type empty <bcp14>MUST</bcp14> be encoded using the CBOR nul l value (major type
7, additional information 22).</t> 7, additional information 22).</t>
<t>The following example shows the encoding of an 'is-router' leaf repre sentation node instance when present.</t> <t>The following example shows the encoding of an 'is-router' leaf repre sentation node instance when present.</t>
<t>Definition example from <xref target="RFC8344"/>:</t> <t>Definition example adapted from <xref target="RFC8344"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
leaf is-router { leaf is-router {
type empty; type empty;
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: null</t> <t>CBOR diagnostic notation: null</t>
<t>CBOR encoding: F6</t> <t>CBOR encoding: F6</t>
</section> </section>
<section anchor="union"> <section anchor="union">
<name>The 'union' Type</name> <name>The 'union' Type</name>
<t>Leafs of type union <bcp14>MUST</bcp14> be encoded using the rules as sociated with one of the types listed. <t>Leafs of type union <bcp14>MUST</bcp14> be encoded using the rules as sociated with one of the types listed.
When used in a union, the following YANG datatypes are enclosed by a CBOR tag to avoid confusion When used in a union, the following YANG datatypes are enclosed by a CBOR tag to avoid confusion
between different YANG datatypes encoded using the same CBOR major type.</t> between different YANG datatypes encoded using the same CBOR major type.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>bits</li> <li>bits</li>
<li>enumeration</li> <li>enumeration</li>
<li>identityref</li> <li>identityref</li>
<li>instance-identifier</li> <li>instance-identifier</li>
</ul> </ul>
<t>See <xref target="tag-registry"/> for the assigned value of these CBO R tags.</t> <t>See <xref target="tag-registry"/> for the assigned value of these CBO R tags.</t>
<t>As mentioned in <xref target="enumeration"/> and in <xref target="bit <t>As mentioned in Sections <xref target="enumeration" format="counter"/
s"/>, 'enumeration' and 'bits' are encoded as a CBOR text string data item (majo > and in <xref target="bits" format="counter"/>, 'enumeration' and 'bits' are en
r type 3) when defined within a 'union' type. coded as a CBOR text string data item (major type 3) when defined within a 'unio
(This adds considerable complexity, but is necessary because of an n' type.
idiosyncrasy of the YANG data model for unions; the workaround allows (This adds considerable complexity but is necessary because of an
idiosyncrasy of the YANG data model for unions; the work-around allows
compatibility to be maintained with the encoding of overlapping unions compatibility to be maintained with the encoding of overlapping unions
in XML and JSON. in XML and JSON.
See also <xref section="9.12" sectionFormat="of" target="RFC7950"/>.)</t> See also <xref section="9.12" sectionFormat="of" target="RFC7950"/>.)</t>
<t>The following example shows the encoding of an 'ip-address' leaf repr esentation node instance when set to "2001:db8:a0b:12f0::1".</t> <t>The following example shows the encoding of an 'ip-address' leaf repr esentation node instance when set to "2001:db8:a0b:12f0::1".</t>
<t>Definition example (adapted from <xref target="RFC6991"/>):</t> <t keepWithNext="true">Definition example adapted from <xref target="RFC 6991"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
typedef ipv4-address { typedef ipv4-address {
type string { type string {
pattern pattern
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ '(%[\p{N}\p{L}]+)?'; + '(%[\p{N}\p{L}]+)?';
} }
} }
skipping to change at line 1390 skipping to change at line 1393
leaf address { leaf address {
type ip-address; type ip-address;
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: "2001:db8:a0b:12f0::1"</t> <t>CBOR diagnostic notation: "2001:db8:a0b:12f0::1"</t>
<t>CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31</t> <t>CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31</t>
</section> </section>
<section anchor="instance-id"> <section anchor="instance-id">
<name>The 'instance-identifier' Type</name> <name>The 'instance-identifier' Type</name>
<t>This specification supports two approaches for encoding an instance-i dentifier, one based on YANG Schema Item iDentifier as defined in <xref target=" sid"/> and one based on names as defined in <xref target="name"/>. <t>This specification supports two approaches for encoding an instance-i dentifier: one based on YANG Schema Item iDentifier, as defined in <xref target= "sid"/>, and one based on names, as defined in <xref target="name"/>.
See <xref target="union"/> for an exceptional case when this representation need s to be tagged.</t> See <xref target="union"/> for an exceptional case when this representation need s to be tagged.</t>
<section anchor="instance-identifier-with-sid"> <section anchor="instance-identifier-with-sid">
<name>SIDs as instance-identifier</name> <name>SIDs as 'instance-identifier'</name>
<t>SIDs uniquely identify a schema node. In the case of a single insta nce schema node, i.e., a schema node defined at the root of a YANG module or sub module or schema nodes defined within a container, the SID is sufficient to iden tify this instance (representation node). <t>SIDs uniquely identify a schema node. In the case of a single insta nce schema node, i.e., a schema node defined at the root of a YANG module or sub module or schema nodes defined within a container, the SID is sufficient to iden tify this instance (representation node).
(Note that no delta mechanism is employed for SIDs used for identityref, see <xr (Note that no delta mechanism is employed for SIDs used for identityref
ef target="identityref-with-sid"/>.) , see <xref target="identityref-with-sid"/>.)
<!-- Is this clear enough? -->
</t> </t>
<t>In the case of a representation node that is an entry of a YANG lis t, a SID is combined with the list key(s) to identify each instance within the Y ANG list(s).</t> <t>In the case of a representation node that is an entry of a YANG lis t, a SID is combined with the list key(s) to identify each instance within the Y ANG list(s).</t>
<t>Instance identifiers of single instance schema nodes <bcp14>MUST</b <t>Instance-identifiers of single instance schema nodes <bcp14>MUST</b
cp14> be encoded using a CBOR unsigned integer data item (major type 0) and set cp14> be encoded using a CBOR unsigned integer data item (major type 0) and set
to the targeted schema node SID.</t> to the targeted schema node SID.</t>
<t>Instance identifiers of representation node entries of a YANG list <t>Instance-identifiers of representation node entries of a YANG list
<bcp14>MUST</bcp14> be encoded using a CBOR array data item (major type 4) conta <bcp14>MUST</bcp14> be encoded using a CBOR array data item (major type 4) conta
ining the following entries:</t> ining the following entries:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The first entry <bcp14>MUST</bcp14> be encoded as a CBOR unsigne d integer data item (major type 0) and set to the targeted schema node SID.</li> <li>The first entry <bcp14>MUST</bcp14> be encoded as a CBOR unsigne d integer data item (major type 0) and set to the targeted schema node SID.</li>
<li>The following entries <bcp14>MUST</bcp14> contain the value of e ach key required to identify the instance of the targeted schema node. These key s <bcp14>MUST</bcp14> be ordered as defined in the 'key' YANG statement, startin g from the top level list, and followed by each of the subordinate list(s).</li> <li>The following entries <bcp14>MUST</bcp14> contain the value of e ach key required to identify the instance of the targeted schema node. These key s <bcp14>MUST</bcp14> be ordered as defined in the 'key' YANG statement, startin g from the top-level list, and followed by each subordinate list(s).</li>
</ul> </ul>
<t>Examples within this section assume the definition of a schema node of type 'instance-identifier':</t> <t>Examples within this section assume the definition of a schema node of type 'instance-identifier':</t>
<t>Definition example from <xref target="RFC7950"/>:</t> <t>Definition example adapted from <xref target="RFC7950"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
container system { container system {
... ...
leaf reporting-entity { leaf reporting-entity {
type instance-identifier; type instance-identifier;
} }
]]></sourcecode> ]]></sourcecode>
<t><strong>First example:</strong></t> <t><strong>First example:</strong></t>
<t>The following example shows the encoding of the 'reporting-entity' value referencing data node instance "/system/contact" (SID 1741).</t> <t>The following example shows the encoding of the 'reporting-entity' value referencing data node instance "/system/contact" (SID 1741).</t>
<t>Definition example from <xref target="RFC7317"/>:</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
container system { container system {
leaf contact { leaf contact {
type string; type string;
} }
leaf hostname { leaf hostname {
type inet:domain-name; type inet:domain-name;
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: 1741</t> <t>CBOR diagnostic notation: 1741</t>
<t>CBOR encoding: 19 06CD</t> <t>CBOR encoding: 19 06CD</t>
<t><strong>Second example:</strong></t> <t keepWithNext="true"><strong>Second example:</strong></t>
<t>This example aims to show how a representation node entry of a YANG list is identified. <t>This example aims to show how a representation node entry of a YANG list is identified.
It uses a somewhat arbitrarily modified YANG module version from <xref target="R FC7317"/> by It uses a somewhat arbitrarily modified YANG module version from <xref target="R FC7317"/> by
adding <tt>country</tt> to the leafs and keys of <tt>authorized-key</tt>.</t> adding <tt>country</tt> to the leafs and keys of <tt>authorized-key</tt>.</t>
<t>The following example shows the encoding of the 'reporting-entity' value referencing list instance "/system/authentication/user/authorized-key/key- data" (which is assumed to have SID 1734) for username "bob" and authorized-key with name "admin" and country "france".</t> <t>The following example shows the encoding of the 'reporting-entity' value referencing list instance "/system/authentication/user/authorized-key/key- data" (which is assumed to have SID 1734) for username "bob" and authorized-key with name "admin" and country "france".</t>
<sourcecode type="yang"><![CDATA[ <sourcecode type="yang"><![CDATA[
list user { list user {
key name; key name;
leaf name { leaf name {
type string; type string;
skipping to change at line 1470 skipping to change at line 1472
type string; type string;
} }
leaf key-data { leaf key-data {
type binary; type binary;
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
<t>CBOR diagnostic notation: [1734, "bob", "admin", "france"]</t> <t>CBOR diagnostic notation: [1734, "bob", "admin", "france"]</t>
<t>CBOR encoding:</t> <t keepWithNext="true">CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
84 # array(4) 84 # array(4)
19 06C6 # unsigned(1734) 19 06C6 # unsigned(1734)
63 # text(3) 63 # text(3)
626F62 # "bob" 626F62 # "bob"
65 # text(5) 65 # text(5)
61646D696E # "admin" 61646D696E # "admin"
66 # text(6) 66 # text(6)
6672616E6365 # "france" 6672616E6365 # "france"
]]></sourcecode> ]]></sourcecode>
<t><strong>Third example:</strong></t> <t><strong>Third example:</strong></t>
<t>The following example shows the encoding of the 'reporting-entity' value referencing the list instance "/system/authentication/user" (SID 1730) cor responding to username "jack".</t> <t>The following example shows the encoding of the 'reporting-entity' value referencing the list instance "/system/authentication/user" (SID 1730), co rresponding to username "jack".</t>
<t>CBOR diagnostic notation: [1730, "jack"]</t> <t>CBOR diagnostic notation: [1730, "jack"]</t>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
82 # array(2) 82 # array(2)
19 06C2 # unsigned(1730) 19 06C2 # unsigned(1730)
64 # text(4) 64 # text(4)
6A61636B # "jack" 6A61636B # "jack"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="names-as-instance-identifier"> <section anchor="names-as-instance-identifier">
<name>Names as instance-identifier</name> <name>Names as 'instance-identifier'</name>
<t>An "instance-identifier" value is encoded as a text string that is <t>An 'instance-identifier' value is encoded as a text string that is
analogous to the lexical representation in XML encoding; see <xref section="9.13 .2" sectionFormat="of" target="RFC7950"/>. However, the encoding of namespaces i n instance-identifier values follows the rules stated in <xref target="name"/>, namely:</t> analogous to the lexical representation in XML encoding; see <xref section="9.13 .2" sectionFormat="of" target="RFC7950"/>. However, the encoding of namespaces i n instance-identifier values follows the rules stated in <xref target="name"/>, namely:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The leftmost (top-level) data node name is always in the namespa <li>The leftmost (top-level) data node name is always in the namespa
ce qualified form.</li> ce-qualified form.</li>
<li>Any subsequent data node name is in the namespace qualified form <li>Any subsequent data node name is in the namespace-qualified form
if the node is defined in a module other than its parent node, and the simple f if the node is defined in a module other than its parent node; otherwise, the s
orm is used otherwise. This rule also holds for node names appearing in predicat imple form is used. This rule also holds for node names appearing in predicates.
es.</li> </li>
</ul> </ul>
<t>For example,</t> <t>For example,</t>
<t>/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip< /t> <t>/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip< /t>
<t>is a valid instance-identifier value because the data nodes "interf aces", "interface", and "name" are defined in the module "ietf-interfaces", wher eas "ipv4" and "ip" are defined in "ietf-ip".</t> <t>is a valid instance-identifier value because the data nodes "interf aces", "interface", and "name" are defined in the module "ietf-interfaces", wher eas "ipv4" and "ip" are defined in "ietf-ip".</t>
<t>The resulting xpath <bcp14>MUST</bcp14> be encoded using a CBOR tex t string data item (major type 3).</t> <t>The resulting XML Path Language (XPath) <bcp14>MUST</bcp14> be enco ded using a CBOR text string data item (major type 3).</t>
<t><strong>First example:</strong></t> <t><strong>First example:</strong></t>
<t>This example is described in <xref target="instance-identifier-with -sid"/>.</t> <t>This example is described in <xref target="instance-identifier-with -sid"/>.</t>
<t>CBOR diagnostic notation: "/ietf-system:system/contact"</t> <t>CBOR diagnostic notation: "/ietf-system:system/contact"</t>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
78 1c 2F696574662D73797374656D3A73797374656D2F636F6E74616374 78 1B 2F696574662D73797374656D3A73797374656D2F636F6E74616374
]]></sourcecode> ]]></sourcecode>
<t><strong>Second example:</strong></t> <t><strong>Second example:</strong></t>
<t>This example is described in <xref target="instance-identifier-with -sid"/>.</t> <t>This example is described in <xref target="instance-identifier-with -sid"/>.</t>
<t>CBOR diagnostic notation (the line break is inserted for exposition only):</t> <t>CBOR diagnostic notation (the line break is inserted for exposition only):</t>
<!-- http://cbor.me/?diag=%22/ietf-system:system/authentication/user[n
ame=%27bob%27]/authorized-key[name=%27admin%27][country=%27france%27]/key-data%2
2 -->
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
"/ietf-system:system/authentication/user[name='bob']/ "/ietf-system:system/authentication/user[name='bob']/
authorized-key[name='admin'][country='france']/key-data" authorized-key[name='admin'][country='france']/key-data"
]]></sourcecode> ]]></sourcecode>
<t>CBOR encoding:</t> <t>CBOR encoding:</t>
<!-- http://cbor.me/?bytes=78.6B(2F696574662D73797374656D3A73797374656
D2F61757468656E7469636174696F6E2F757365725B6E616D653D27626F62275D2F617574686F726
97A65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D276672616E6365275D2
F6B65792D64617461) -->
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
78 6B 78 6B
2F696574662D73797374656D3A73797374656D2F61757468656E74696361 2F696574662D73797374656D3A73797374656D2F61757468656E74696361
74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A 74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A
65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27 65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27
6672616E6365275D2F6B65792D64617461 6672616E6365275D2F6B65792D64617461
]]></sourcecode> ]]></sourcecode>
<t><strong>Third example:</strong></t> <t><strong>Third example:</strong></t>
<t>This example is described in <xref target="instance-identifier-with -sid"/>.</t> <t>This example is described in <xref target="instance-identifier-with -sid"/>.</t>
<t>CBOR diagnostic notation:</t> <t>CBOR diagnostic notation:</t>
skipping to change at line 1547 skipping to change at line 1545
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
78 34 # text(52) 78 34 # text(52)
2F696574662D73797374656D3A73797374656D2F61757468656E74696361 2F696574662D73797374656D3A73797374656D2F61757468656E74696361
74696F6E2F757365725B6E616D653D276A61636B275D 74696F6E2F757365725B6E616D653D276A61636B275D
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="content-type"> <section anchor="content-type">
<name>Content-Types</name> <name>Content-Types</name>
<t>This specification defines the media-type <t>This specification defines the media type
<tt>application/yang-data+cbor</tt>, which can be used without parameters or <tt>application/yang-data+cbor</tt>, which can be used without parameters or
with the <tt>id</tt> parameter set to either <tt>name</tt> or <tt>sid</tt>.</t> with the <tt>id</tt> parameter set to either <tt>name</tt> or <tt>sid</tt>.</t>
<t>This media-type represents a YANG-CBOR document containing a representa <t>This media type represents a YANG-CBOR document containing a representa
tion tree. tion tree.
If the media-type parameter <tt>id</tt> is present, If the media type parameter <tt>id</tt> is present,
depending on its value, depending on its value,
each representation node is identified by its associated namespace qualified each representation node is identified by its associated namespace-qualified
name as defined in <xref target="name"/> (<tt>id=name</tt>), or by its associate name, as defined in <xref target="name"/> (<tt>id=name</tt>), or by its associat
d YANG SID ed YANG SID
(represented, e.g., in CBOR map keys as a SID delta or via tag number 47) as def (represented, e.g., in CBOR map keys as a SID delta or via tag number 47), as de
ined in <xref target="sid"/> fined in <xref target="sid"/>
(<tt>id=sid</tt>), respectively. (<tt>id=sid</tt>), respectively.
If no <tt>id</tt> parameter is given, both forms may be present.</t> If no <tt>id</tt> parameter is given, both forms may be present.</t>
<t>The format of an <tt>application/yang-data+cbor</tt> representation is that <t>The format of an <tt>application/yang-data+cbor</tt> representation is that
of a CBOR map, mapping names and/or SIDs (as defined above) into of a CBOR map, mapping names, and/or SIDs (as defined above) into
instance values (using the rules defined in <xref target="instance-encoding"/>). </t> instance values (using the rules defined in <xref target="instance-encoding"/>). </t>
<t>It is not foreseen at this point that the valid set of values for the <t>It is not foreseen at this point that the valid set of values for the
<tt>id</tt> parameter will extend beyond <tt>name</tt>, <tt>sid</tt>, or being u nset; if <tt>id</tt> parameter will extend beyond <tt>name</tt>, <tt>sid</tt>, or being u nset; if
that does happen, any new value is foreseen to be of the form that does happen, any new value is foreseen to be of the form
<tt>[a-z][a-z0-9]*(-[a-z0-9]+)*</tt>.</t> <tt>[a-z][a-z0-9]*(-[a-z0-9]+)*</tt>.</t>
<t>In summary, this document defines three content-types, which are <t>In summary, this document defines three content-types, which are
intended for use by different classes of applications:</t> intended for use by different classes of applications:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><tt>application/yang-data+cbor; id=sid</tt> -- for use by applicatio
<tt>application/yang-data+cbor; id=sid</tt> -- for use by applications ns that
that
need to be frugal with encoding space and text string processing need to be frugal with encoding space and text string processing
(e.g., applications running on constrained nodes <xref target="RFC7228"/>, or (e.g., applications running on constrained nodes <xref target="RFC7228"/> or
applications with particular performance requirements);</li> applications with particular performance requirements);</li>
<li> <li><tt>application/yang-data+cbor; id=name</tt> -- for use by applicati
<tt>application/yang-data+cbor; id=name</tt> -- for use by application ons that
s that do not want to engage in SID management and that have ample
do not want to engage in SID management, and that have ample resources to manage text-string-based item identifiers (e.g.,
resources to manage text-string based item identifiers (e.g.,
applications that directly want to substitute applications that directly want to substitute
<tt>application/yang.data+json</tt> with a more efficient representation <tt>application/yang.data+json</tt> with a more efficient representation
without any other changes);</li> without any other changes); and</li>
<li> <li><tt>application/yang-data+cbor</tt> -- for use by more complex appli
<tt>application/yang-data+cbor</tt> -- for use by more complex applica cations
tions
that can benefit from the increased efficiency of SID identifiers that can benefit from the increased efficiency of SID identifiers
but also need to integrate databases of YANG modules before SID but also need to integrate databases of YANG modules before SID
mappings are defined for them.</li> mappings are defined for them.</li>
</ul> </ul>
<t>All three content-types are based on the same representation <t>All three content-types are based on the same representation
mechanisms, parts of which are simply not used in the first and second mechanisms, parts of which are simply not used in the first and second
case.</t> cases.</t>
<t>How the use of one of these content types is selected in a transfer <t>How the use of one of these content-types is selected in a transfer
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
The last paragraph of <xref section="5.2" sectionFormat="of" target="RFC8040"/> discusses how to The last paragraph of <xref section="5.2" sectionFormat="of" target="RFC8040"/> discusses how to
indicate and request the usage of specific content-types in RESTCONF. indicate and request the usage of specific content-types in RESTCONF.
Similar mechanisms are available in CoAP <xref target="RFC7252"/> using the Similar mechanisms are available in the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> using the
Content-Format and Accept Options; <xref target="I-D.ietf-core-comi"/> demonstra tes specifics on Content-Format and Accept Options; <xref target="I-D.ietf-core-comi"/> demonstra tes specifics on
how Content-Format may be used to indicate the <tt>id=sid</tt> case.</t> how Content-Format may be used to indicate the <tt>id=sid</tt> case.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations of <xref target="RFC8949"/> and <xref targe t="RFC7950"/> apply.</t> <t>The security considerations of <xref target="RFC8949"/> and <xref targe t="RFC7950"/> apply.</t>
<t>This document defines an alternative encoding for data modeled in the Y ANG data modeling language. As such, this encoding does not contribute any new s ecurity issues in addition to those identified for the specific protocol or cont ext for which it is used.</t> <t>This document defines an alternative encoding for data modeled in the Y ANG data modeling language. As such, this encoding does not contribute any new s ecurity issues in addition to those identified for the specific protocol or cont ext for which it is used.</t>
<t>To minimize security risks, software on the receiving side <bcp14>SHOUL D</bcp14> reject all messages that do not comply to the rules of this document a nd reply with an appropriate error message to the sender.</t> <t>To minimize security risks, software on the receiving side <bcp14>SHOUL D</bcp14> reject all messages that do not comply to the rules of this document a nd reply with an appropriate error message to the sender.</t>
<t>For instance, when the 'id' parameter to the media type is used, it is <t>For instance, when the <tt>id</tt> parameter to the media type is used,
important to properly reject identifiers of the other type, to avoid it is
important to properly reject identifiers of the other type to avoid
scenarios where different implementations interpret a given content in scenarios where different implementations interpret a given content in
different ways.</t> different ways.</t>
<t>When SIDs are in use, the interpretation of encoded data not only <t>When SIDs are in use, the interpretation of encoded data not only
relies on having the right YANG modules, but also on having the right relies on having the right YANG modules but also on having the right
SID mapping information. Management and evolution of that mapping SID mapping information. Management and evolution of that mapping
information therefore requires the same care as the management and information therefore requires the same care as the management and
evolution of the YANG modules themselves. The procedures in evolution of the YANG modules themselves. The procedures in
<xref target="I-D.ietf-core-sid"/> are being defined with this in mind.</t> <xref target="I-D.ietf-core-sid"/> are being defined with this in mind.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="media-types-registry"> <section anchor="media-types-registry">
<name>Media-Types Registry</name> <name>Media Types Registry</name>
<t>This document adds the following Media-Type to the "Media Types" regi <t>IANA has added the following media type to the "<xref section="Media
stry.</t> Types" relative="#media-types" sectionFormat="bare" target="IANA.media-types"/>"
registry <xref target="IANA.media-types"/>.</t>
<table align="left"> <table align="left">
<name>Media Types Registry</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-data+cbor</td> <td align="left">yang-data+cbor</td>
<td align="left">application/yang-data+cbor</td> <td align="left">application/yang-data+cbor</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>// RFC Ed.: please replace RFC XXXX with this RFC number and remove t <dl newline="false" spacing="normal">
his note.</t>
<dl spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>application</dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>yang-data+cbor</dd>
<t>yang-data+cbor</t>
</dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>id (see <xref target="content-type"/> of RFC 9254)</dd>
<t>id (see <xref target="content-type"/> of RFC XXXX)</t>
</dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>binary (CBOR)</dd>
<t>binary (CBOR)</t>
</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>see <xref target="security-considerations"/> of RFC 9254</dd>
<t>see <xref target="security-considerations"/> of RFC XXXX</t> <dt>Interoperability considerations:</dt>
</dd> <dd>N/A</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>RFC 9254</dd>
<t>RFC XXXX</t> <dt>Applications that use this media type:</dt>
</dd> <dd>applications that need a
concise and efficient representation of YANG-modeled data</dd>
<dt>Fragment identifier considerations:</dt>
<dd>The syntax and semantics of
fragment identifiers specified for "application/yang-data+cbor" is
as specified for "application/cbor". (At publication of this
document, there is no fragment identification syntax defined for
"application/cbor”.)</dd>
<dt>Additional information:</dt>
<dd></dd>
<dt>Magic number(s):</dt>
<dd>N/A</dd>
<dt>File extension(s):</dt>
<dd>N/A</dd>
<dt>Macintosh file type code(s):</dt>
<dd>N/A</dd>
<dt>Person &amp; email address to contact for further information:</dt > <dt>Person &amp; email address to contact for further information:</dt >
<dd> <dd>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)</dd>
or IETF Applications and Real-Time Area (art@ietf.org)</t>
</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>COMMON</dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>N/A</dd>
<t>none</t> <dt>Author:</dt>
</dd> <dd>CoRE WG</dd>
<dt>Author/Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>IETF</dd>
<t>IETF</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="coap-content-formats-registry"> <section anchor="coap-content-formats-registry">
<name>CoAP Content-Formats Registry</name> <name>CoAP Content-Formats Registry</name>
<t>This document adds the following Content-Format to the "CoAP Content- <t>IANA has added the following Content-Formats to the "<xref section="C
Formats", oAP Content-Formats" relative="#content-formats" sectionFormat="bare" target="IA
within the "Constrained RESTful Environments (CoRE) Parameters" NA.core-parameters"/>" subregistry,
registry, where TBD3 comes from the "Expert Review" 0-255 range and within the "<xref section="Constrained RESTful Environments (CoRE) Parameters" r
TBD1 and TBD2 come from the "IETF Review" 256-9999 range.</t> elative="#coap-content-format" sectionFormat="bare" target="IANA.core-parameters
"/>"
registry <xref target="IANA.core-parameters"/>. The registration procedure is "E
xpert Review" for the 0-255 range and
"IETF Review" for the 256-9999 range.</t>
<table align="left"> <table align="left">
<name>CoAP Content-Format Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Content Type</th> <th align="left">Media Type</th>
<th align="left">Content Coding</th> <th align="left">Encoding</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-data+cbor</td> <td align="left">application/yang-data+cbor</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">TBD1</td> <td align="left">340</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">application/yang-data+cbor; id=name</td> <td align="left">application/yang-data+cbor; id=name</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">TBD2</td> <td align="left">341</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">application/yang-data+cbor; id=sid</td> <td align="left">application/yang-data+cbor; id=sid</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">TBD3</td> <td align="left">140</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>// RFC Ed.: please replace TBDx with assigned IDs, remove the
requested ranges, and remove this note.<br/>
// RFC Ed.: please replace RFC XXXX with this RFC number and remove this note.</
t>
</section> </section>
<section anchor="tag-registry"> <section anchor="tag-registry">
<name>CBOR Tags Registry</name> <name>CBOR Tags Registry</name>
<t>In the registry "<xref section="CBOR Tags" relative="#cbor-tags" sect <t>IANA has allocated the following CBOR tag numbers in the "<xref secti
ionFormat="bare" target="IANA.cbor-tags"/>" <xref target="IANA.cbor-tags"/>, on="CBOR Tags" relative="#tags" sectionFormat="bare" target="IANA.cbor-tags"/>"
as per <xref section="9.2" sectionFormat="of" target="RFC8949"/>, IANA has alloc registry <xref target="IANA.cbor-tags"/> defined in <xref section="9.2" section
ated the CBOR tags in Format="of" target="RFC8949"/>.</t>
<xref target="tab-tag-values"/> for the YANG datatypes listed.</t>
<table anchor="tab-tag-values"> <table anchor="tab-tag-values">
<name>CBOR tags defined by this specification</name> <name>CBOR Tags Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Tag</th> <th align="left">Tag</th>
<th align="left">Data Item</th> <th align="left">Data Item</th>
<th align="left">Semantics</th> <th align="left">Semantics</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">43</td> <td align="left">43</td>
<td align="left">text string</td> <td align="left">text string</td>
<td align="left">YANG bits datatype; see <xref target="bits"/></td <td align="left">YANG bits datatype; see <xref target="bits"/>.</t
> d>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">44</td> <td align="left">44</td>
<td align="left">text string</td> <td align="left">text string</td>
<td align="left">YANG enumeration datatype; see <xref target="enum eration"/>.</td> <td align="left">YANG enumeration datatype; see <xref target="enum eration"/>.</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">45</td> <td align="left">45</td>
<td align="left">unsigned integer or text string</td> <td align="left">unsigned integer or text string</td>
<td align="left">YANG identityref datatype; see <xref target="iden tityref"/>.</td> <td align="left">YANG identityref datatype; see <xref target="iden tityref"/>.</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">46</td> <td align="left">46</td>
<td align="left">unsigned integer or text string or array</td> <td align="left">unsigned integer or text string or array</td>
<td align="left">YANG instance-identifier datatype; see <xref targ et="instance-id"/>.</td> <td align="left">YANG instance-identifier datatype; see <xref targ et="instance-id"/>.</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
<tr> <tr>
<td align="left">47</td> <td align="left">47</td>
<td align="left">unsigned integer</td> <td align="left">unsigned integer</td>
<td align="left">YANG Schema Item iDentifier (SID); see <xref targ et="sid"/>.</td> <td align="left">YANG Schema Item iDentifier (SID); see <xref targ et="sid"/>.</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9254</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>// RFC Ed.: please replace RFC XXXX with RFC number and remove this n ote</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-core-sid" to="CORE-SID"/>
<displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.
<front> xml"/>
<title>The YANG 1.1 Data Modeling Language</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.
<author fullname="M. Bjorklund" initials="M." role="editor" surname= xml"/>
"Bjorklund"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.
<date month="August" year="2016"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.
<t>YANG is a data modeling language used to model configuration da xml"/>
ta, state data, Remote Procedure Calls, and notifications for network management <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
protocols. This document describes the syntax and semantics of version 1.1 of xml"/>
the YANG language. YANG version 1.1 is a maintenance release of the YANG langua <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
ge, addressing ambiguities and defects in the original specification. There are xml"/>
a small number of backward incompatibilities from YANG version 1. This documen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
t also specifies the YANG mappings to the Network Configuration Protocol (NETCON xml"/>
F).</t>
</abstract> <reference anchor="IANA.media-types" target="https://www.iana.org/assign
</front> ments/media-types/">
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7
951">
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author fullname="L. Lhotka" initials="L." surname="Lhotka">
<organization/>
</author>
<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" target="https://www.rfc-editor.org/info/rfc8
040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization/>
</author>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<author fullname="K. Watsen" initials="K." surname="Watsen">
<organization/>
</author>
<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" target="https://www.rfc-editor.org/info/rfc8
259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray
">
<organization/>
</author>
<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 ECMAScri
pt Programming Language Standard. JSON defines a small set of formatting rules
for 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" target="https://www.rfc-editor.org/info/rfc8
791">
<front>
<title>YANG Data Structure Extensions</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization/>
</author>
<author fullname="M. Björklund" initials="M." surname="Björklund">
<organization/>
</author>
<author fullname="K. Watsen" initials="K." surname="Watsen">
<organization/>
</author>
<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="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8
949">
<front> <front>
<title>Concise Binary Object Representation (CBOR)</title> <title>Media Types</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"> <author>
<organization/> <organization>IANA</organization>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author> </author>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front> </front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference> </reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610"> <reference anchor="IANA.core-parameters" target="https://www.iana.org/as
signments/core-parameters/">
<front> <front>
<title>Concise Data Definition Language (CDDL): A Notational Convent <title>Constrained RESTful Environments (CoRE) Parameters</title>
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu <author>
res</title> <organization>IANA</organization>
<author fullname="H. Birkholz" initials="H." surname="Birkholz">
<organization/>
</author>
<author fullname="C. Vigano" initials="C." surname="Vigano">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author> </author>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages and data formats that use CBOR or JSON.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference> </reference>
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme
nts/cbor-tags"> <reference anchor="IANA.cbor-tags" target="https://www.iana.org/a
ssignments/cbor-tags">
<front> <front>
<title>Concise Binary Object Representation (CBOR) Tags</title> <title>Concise Binary Object Representation (CBOR) Tags</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
le> xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<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.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, 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" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<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 tha
t 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> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-core-sid" target="https://www.ietf.org/archi
ve/id/draft-ietf-core-sid-18.txt">
<front>
<title>YANG Schema Item iDentifier (YANG SID)</title>
<author fullname="Michel Veillette">
<organization>Trilliant Networks Inc.</organization>
</author>
<author fullname="Alexander Pelov">
<organization>Acklio</organization>
</author>
<author fullname="Ivaylo Petrov">
<organization>Google Switzerland GmbH</organization>
</author>
<author fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<author fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
</author>
<date day="18" month="November" year="2021"/>
<abstract>
<t> YANG Schema Item iDentifiers (YANG SID) 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, the registration, and assignment processes of YANG SIDs
for IETF managed YANG modules. To enable the implementation of these
processes, this document also defines a file format used to persist
and publish assigned YANG SIDs.
</t> <reference anchor="I-D.ietf-core-sid">
</abstract> <front>
</front> <title>YANG Schema Item iDentifier (YANG SID)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-18"/> <author initials='M' surname='Veillette' fullname='Michel Veillette' role='edito
</reference> r'>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7 <organization/>
252"> </author>
<front> <author initials='A' surname='Pelov' fullname='Alexander Pelov' role='editor'>
<title>The Constrained Application Protocol (CoAP)</title> <organization/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"> </author>
<organization/> <author initials='I' surname='Petrov' fullname='Ivaylo Petrov' role='editor'>
</author> <organization/>
<author fullname="K. Hartke" initials="K." surname="Hartke"> </author>
<organization/> <author initials='C' surname='Bormann' fullname='Carsten Bormann'>
</author> <organization/>
<author fullname="C. Bormann" initials="C." surname="Bormann"> </author>
<organization/> <author initials='M' surname='Richardson' fullname='Michael Richardson'>
</author> <organization/>
<date month="June" year="2014"/> </author>
<abstract> <date month="November" day="18" year="2021" />
<t>The Constrained Application Protocol (CoAP) is a specialized we </front>
b transfer protocol for use with constrained nodes and constrained (e.g., low-po <seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-18" />
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am </reference>
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless Personal Area Networks (6LoWPANs) often have high packet error rates and a <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
typical throughput of 10s of kbit/s. The protocol is designed for machine- to- xml"/>
machine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl <reference anchor="I-D.ietf-core-comi">
ication endpoints, supports built-in discovery of services and resources, and in <front>
cludes key concepts of the Web such as URIs and Internet media types. CoAP is d <title>CoAP Management Interface (CORECONF)</title>
esigned to easily interface with HTTP for integration with the Web while meeting <author initials='M' surname='Veillette' fullname='Michel Veillette' role='edito
specialized requirements such as multicast support, very low overhead, and simp r'>
licity for constrained environments.</t> <organization/>
</abstract> </author>
</front> <author initials='P' surname='van der Stok' fullname='Peter van der Stok' role='
<seriesInfo name="RFC" value="7252"/> editor'>
<seriesInfo name="DOI" value="10.17487/RFC7252"/> <organization/>
</reference> </author>
<reference anchor="I-D.ietf-core-comi" target="https://www.ietf.org/arch <author initials='A' surname='Pelov' fullname='Alexander Pelov'>
ive/id/draft-ietf-core-comi-11.txt"> <organization/>
<front> </author>
<title>CoAP Management Interface (CORECONF)</title> <author initials='A' surname='Bierman' fullname='Andy Bierman'>
<author fullname="Michel Veillette"> <organization/>
<organization>Trilliant Networks Inc.</organization> </author>
</author> <author initials='I' surname='Petrov' fullname='Ivaylo Petrov' role='editor'>
<author fullname="Peter van der Stok"> <organization/>
<organization>consultant</organization> </author>
</author> <date month="January" day="17" year="2021" />
<author fullname="Alexander Pelov"> </front>
<organization>Acklio</organization> <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-11" />
</author> </reference>
<author fullname="Andy Bierman">
<organization>YumaWorks</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
</author> xml"/>
<author fullname="Ivaylo Petrov"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
<organization>Acklio</organization> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.
<date day="17" month="January" year="2021"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7317.
<t> This document describes a network management interface for xml"/>
constrained devices and networks, called CoAP Management Interface <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.
(CORECONF). The Constrained Application Protocol (CoAP) is used to xml"/>
access datastore and data node resources specified in YANG, or SMIv2 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8344.
converted to YANG. CORECONF uses the YANG to CBOR mapping and xml"/>
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>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-11"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
">
<organization/>
</author>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund">
<organization/>
</author>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder">
<organization/>
</author>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman">
<organization/>
</author>
<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 enco
ding for the configuration data as well as the protocol messages. The NETCONF p
rotocol operations are realized as remote procedure calls (RPCs). This document
obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
991">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder">
<organization/>
</author>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7
228">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="M. Ersue" initials="M." surname="Ersue">
<organization/>
</author>
<author fullname="A. Keranen" initials="A." surname="Keranen">
<organization/>
</author>
<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
have 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" target="https://www.rfc-editor.org/info/rfc7
317">
<front>
<title>A YANG Data Model for System Management</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization/>
</author>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<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 da
ta node definitions for system identification, time-of-day management, user mana
gement, DNS resolver configuration, and some protocol operations for system mana
gement.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7317"/>
<seriesInfo name="DOI" value="10.17487/RFC7317"/>
</reference>
<reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8
343">
<front>
<title>A YANG Data Model for Interface Management</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<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 augm
ent the generic interfaces data model defined in this document. The data model i
ncludes definitions for configuration and system state (status information and c
ounters 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" target="https://www.rfc-editor.org/info/rfc8
344">
<front>
<title>A YANG Data Model for IP Management</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<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>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document has been largely inspired by the extensive works done by <contact fullname="Andy Bierman"/> and <contact fullname="Peter van der Stok"/> on <xref target="I-D.ietf-core-comi"/>. <xref target="RFC7951"/> has also been a critical input to this work. The authors would like to thank the authors and co ntributors to these two drafts.</t> <t>This document has been largely inspired by the extensive work done by < contact fullname="Andy Bierman"/> and <contact fullname="Peter van der Stok"/> o n <xref target="I-D.ietf-core-comi"/>. <xref target="RFC7951"/> has also been a critical input to this work. The authors would like to thank the authors and con tributors of these two documents.</t>
<t>The authors would also like to acknowledge the review, feedback, and <t>The authors would also like to acknowledge the review, feedback, and
comments from <contact fullname="Ladislav Lhotka"/> and <contact fullname="Jürge comments from <contact fullname="Ladislav Lhotka"/> and <contact fullname="Jürge
n Schönwälder"/>, and from the n Schönwälder"/> and from the
document shepherd <contact fullname="Marco Tiloca"/>. Document Shepherd <contact fullname="Marco Tiloca"/>.
Extensive comments helped us further improve the document in the IESG Extensive comments helped us further improve the document in the IESG
review process; the authors would like to call out specifically the review process; the authors would like to call out specifically the
feedback and guidance by the responsible AD <contact fullname="Francesca Palombi ni"/> and feedback and guidance by the responsible AD <contact fullname="Francesca Palombi ni"/> and
the significant improvements suggested by IESG members <contact fullname="Benjam in Kaduk"/> the significant improvements suggested by IESG members <contact fullname="Benjam in Kaduk"/>
and <contact fullname="Rob Wilton"/>.</t> and <contact fullname="Rob Wilton"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1923bbSJLgO74CQ59Zii6S4k2kRE9NNa1Lt3vKdo3tmp5p
l3cKJCEJbRJgA6Bklaw9+xH7Afsw37BP+7TzJ/slG7e8ASBFyeXu2bPL7rJI
IC+RkZFxy8jIVqvlXY39vufNk1kcLMOxP0+D87wVhfl5a5akYesmiC9as2mS
thZBHma5l0f5AsodP3/9xj+NZ8k8ii/85Nw/CfLAf5nMw0U496+j/NL/l8mr
33pBGgZjf7JaLaJZkEdJnPlBPPffhMGi9S5ahv4ECvh7QZo3vOuLsf8izsM0
DnNo+yKKwzDF5t8F2Uf/LElnoffxmvv2oLWxn+VzbwZthnG2zsZ+nq5DL1tP
l1GWQVf5zQogfXH67szzVtHY86F8Gs2gXv0mzOrwO09mzo95uMov4ckAf2c3
yzQ8z0yBLElz98ksWa4Cu0Ho3DyLk7oXrPPLJB17LT9NEG/hPMqTFEpGMbTz
su3/UxgtFmGeh/CMp+BlNLsMF86LJAXUvEvhQRTEuf8qzK+T9GMG2Jq1eVhh
CD0Oux3/zTr052v/+/WncDlN1ukFgTmHdn/f+73f+6ce/o7ym7H/2zSIpzfw
Mw0vAFtj/x/X4TScUfl1nKdQ5DiIg3kAT8JlEC3G/pJAa18p0H6TK5gigARG
vmGcL9r+D2GeJld6kC+ugptFYp7SCH+bJBeL0H8L5PNLmC6QUH67nP7OGuFz
gHmeARDxRyDGNMiy0O92O3qMh52OGeAf1zDbl94TM0J5Yo3Q6ssMMyLgVgTb
by4IKBkcjWaCo1lYg5kswk/QQJjq5zScyezjIkos6Lvd/mjiB1dhjJMUZv7x
ZbBcZf5z6H6W6UHU+wcH3U5dj+M4zLIkbr0Nr6KLOLTH8zwN8wCfWSM6AxTN
QjOY4DcBwNEGQAT847b/PEmXQRzrARwHaZaHsfWcBvBjHF2FaRbl//5vOfa1
hCLv/vjCGtEPSZafB7NLv9/vDAYdDfJJq3fYPziSSjZ4vw2xCyS71WUSQ9+1
bwZHrUGv2+p1D1vD/lGvWzPAz4Jp8pv8l6gN8HgwALNCAlgib/BvOgfkKIjf
4jQsoAP/bXKeXwP38f+AK8Ui4Vn6DbK332SqaHsWVNC8FyMuckAAMo43Z8ej
o4PO2Ed+qH93+XfrTwwBPDzsDKBQCrQJbOlcnvUOjsa+VWZ0pCoCGtezfJ2G
/Oag1x/AhE11zaMB1ETuK79hgcPv+XwBv19MXk3axJmBBLKx50XxuQ3yi9ZJ
2/DxLJpDTfkmA+gd9PBZsCqVBmKP8NUy4qLD3gBABrZsRjU80qNAPpupNnuH
Cl/97ki+HvYHffN1ALC2Wi0YJ67gWe55z4MMhEYS+/ll6B8n8SyCZf08ioP0
xn89/VM4y0FgrACrYZyTEPH3UAY0sUEfkdRoevlllPkgxtZAbzksrnOQHpkf
KgmVrhfwExAEkyMt4WMcT3SxTqlVbw4yrAm0DZLO5++rIAWKA5HEYgsqrhd5
hvLuTbhMoNgPaTIL5zCDQDeLhb/35ofjhgesIxVhBx3CEPFrk1qIkzw6V6Kw
KXDO/XWG0KDEhCZgUEhsjTbjaRnBhIcerHsQjmkyX1N7nvcOkJWtwpluD8FC
DFIz3XaXxuAvUSZj68BkLtbBRejf3go5391pRMGK+eeX3xt8IaaoOrCMHBkK
ABu1w3YTUQasgpHgoI/KZ8D1sayNRMAJNLNa54zEZJ3j96YgpvoV/AivcCYd
hAFGJrEfzEG4wM9g4WegKQAchWm+DDJ/GgKzUuiNYj3oLgx6KvTmIbZ+H1wF
b2dptMoVrb1KFJX9/u3rVw1WbUgxAXYTAwLPaJ1xk7i67+7aPB1BtORJsGkR
vueJgOIHG0BGfD+M+hvSP5D/3R1OC4jkGS7+xQ2wzQWqYU+RElpY+GnbR/iY
frFX3T1At4QpU6oM/02hMsCMFIEzgWigL1QyW0d5MAU5jTADvLiKCcuvkjlR
0ny/+ELpKzAvakqmNzIlwDEIf0/8dyAaojhZJBc31JuaB8btx/DGh1bmmV97
+ePbd7Um//Vfvabvb07/8ccXb05P8Pvb302+/15/8aTE29+9/vH7E/PN1Dx+
/fLl6asTrgxPfeeRV3s5+Zca02Tt9Q/vXrx+Nfm+hjTlzjMKG0DaNIRXQCsw
YzmMM8g8wArQ15Tp8PnxD//rv3cHMPi/gdH3ul2YPflx2B0N4Mc1aDfcWxLD
XPJPoI0bL1itwiDFVpDXzIIVTMQCV0vmZ5fJdexfhmkIqHz6HjHzYez/3XS2
6g7+Xh7ggJ2HCmfOQ8JZ+UmpMiOx4lFFNxqbzvMCpl14J//i/FZ4tx4yWZwD
3SfXSMmA82VGs1Cx7IHXgdh5KjyHvsU3yJ7k66flAr8Ry4uBjvUPVHTUD2Ju
+OM8DEhqw9dojqIkv8HvwGrXC3pqcy38DSwQ/6DmujQdoKkiVcpDwZVZHAiq
FzIQkrwEYfgJ+HGm18kOrYACIq2QqKBWjCoCrUAlV7IAmSX+MgClG0RVqASN
25UsXdPuWx7tizwEME4QTecR6Mh7/PLFCQrHLFqugMjhVwPsl35rGuX+GkZz
wQDn4QXUWGfMjxjX5zf+PDo/B1KHRUdtRdADygaYpXCRg715Iu9nISzH/BpF
AcI7W6emEgKAiywArqgKqxdtf1Lx1MYl8r4QFV8Sh59yenB9CQopw8CEiIAT
XKDrJIs1SERoZmwaBDJhTkyMAkChum3fpymIENlrWOqoLQtLBwkJE47WNNjh
N8whYF5XSRaxwnGNPMAn5RUqqiaBc64XqPdNcdbWMUOVumIFSR3UT4so8EkT
G8+iKTQGoC6SjJl3QIajUx+oIrBJHOgb0EHjqqAzYFvOMkGWh+uk6ZO6Cz94
rVZBGpOdJL0gO6wailJYAuoYDXx4SFWapJZ9MfhoPm0YQAF8JFCwB+3WqbRi
HggkcwIBTRhMQT/Uyl1Jp6NeFlGG5ERWDBYlgMFETmZRkCuvDAwBKoL0poI8
aKq4l4Vohtzevg1ZLxu1D0nRVfyzQZ2gcgBLaI8qVkxLg/u28Sjcgmgny9EU
Izoi5afcAM4nL6TAvwB1Jq4qhI4FvRhJeQBFHLTuPAoz1Z/rorp9stIlWsk5
+7SUFnQnTK9kP1AbFaqau0RYeYU+oxR5Oj1CVbVQDNZwjAvQWUZfbxEZGnzG
mgr8X7hI5XohthNa4MZKnyN0mkmzoXPbgSV3jtK0SdyvSiXNL4t1uBtCVxU1
qOEjn0VtMm1adN6sxomLEW1+8Fe2MVzro2nsNHmPyMrCNAoW0S96/QVMD8tg
ZYiUhICNEbVkcbVBqSjTHF41gposS56rYLGGtVshcLP1apWkYBaB5uyTgY2U
Qd1D9ezZbhK2YWvcJP7B+gcVkyxRMGyz0nt8Cuq4f4rD4oWUse7NQFQMRwHO
0GExtX5RO8hkXWidWGzFdao4Gsy+IJpfrdCkzrI2Luk8ASIiK3oZovEVZaDi
ocqAbqWcWyjhDpfZEoaIFih2IBqLBakaD007QknlLsIY7Xa0xBJ/dpnAGvXP
YSEA9QLjwEpApS+AQlJ09UEZUHmiJdAHczz8IqxHoYjtX3jiAc2sCF1XSTTH
RXUDak4c4kDRzlsCXlragZMgm7hJaOGBnTmPUlhGoAUAZq6iOTMOzeHAmIUR
Eezw15j8/p5h5T1h5GwsNtpowWrLvikTF1wYpcUHdSVk1YJYdyAojB1Npima
s1GbM1pJhPRYuQQQ0U0ygWHdAg7WUXZp6zDWFBX0OlW7SHOEbiBUtRz/hH1C
OZieH2Ng0ZogUGGCwuk1mtSCtJVQlUNU99EUTSJgg9YKSHN/EcYXIE21aCiu
I4X5ftvFvc/G1DRUK7wwm/MQB5rCiAGg5MbeSyFDvu3tEbcIYzTByW+jQRdW
jiboBQARLqOchoOzlqbBDY04WHnT8BzteOwzXi+nQMvkj8hTFJ4040B0mp3i
kv8Yg3VpKYJoDnhEyuRL+IRkDGzeXySzj7QflPppMEMJELOrBvj7ayYlmg8f
sD4HYYGCdpVCzUwEwyxEj3PVMoKVmCy9YH6FJAtDikGLnYVseE9RK86SpSxC
ax014THqEWple2AngyKsVveWCdW2t7DAKTRxHuWoI3jBbJYC32543okmfDMN
RXFBuG8i5psw1dAV7kLFF7xS0HTg30o74GWZs8o2RXV/ucpv2v4L8TfgWmR/
AK1WhSNR7mQYgMBfwjSBBfGHy2oNitd6ScTRNJCaYzlqKngs0DtogrliCmZ/
Dx7fLJJgzitGfvjiGYhAh1jPnRliaiPzRFhxwM5DWsfXQLW24UfSltVnpRhg
N2RLMSkX9V2icqqAhdgYQlICsJkUybBj2tw4DJKVK6ToP4M9xowFn2lup3hp
SyAFKQy4P/0UIFFkzBJ0Ga113mmEgEKWgC2o1YsqVf0yuDL6A3oRATFhRGMI
NkLI5gSZtMQ33G7ggZYpRPCkZwIrBSwsgCLQWxzyIEhngPJosqqZZ3ZKhFVQ
ktv+61hYO+k4ShsiSrK7R3fjGrhJirL1yRNhglFwEScgLGbYnThR/mC1oPR0
EV1TdpZqzzRStiZ5sxyBJf55HQE8CC+uPMAUavNLpZxu6nwjdz90eLugWNci
+x1lKe06AzrIqS6gC5Wt0xVaRRq74ZXydwhNsm5rK0htAMAA2VLdtbL1cglo
QP92iOtIZhZnVF5p37SqAzj/zKMW3Pn4+Wxpcp/9kwp8PObz2Zfl4D50LSx+
6H1ulT7fbPj+ZZ/KliofAlD+j0XH1Gc9kA5iChjkEkhqHl2goHj057Pf7fUr
Hh76o+eFhwDUq/CC9vwqgOqWgYJFcR59UrYnKLBr4OwwqB2AapWh+uz3AahJ
GajnRs6pkurTg++/A6YyF8CYPxibWPx1wvr+vE5yWR4O6LFfv6xDS5f1s+7B
cd0FatDz8WkRqHeWsC0A1Yfvb/kNrJEf4wiFqo+7y2AVkjpWhG+erKcGPrf/
Wv4prxUxNez7o8HocDRwgZqQZuaUVJ8BLo8EVm4rC3EjElkZ2b4AImEtU2w1
A6YPPG8K0H4MK0nvs//e7zYB+R+ch4c9v9P1O70Cpl4Ccy5UV5+DLUChYBrL
hK6CKNXwzdYpsD8Ez8HVZ//W746R2gGysT84GPp38HCCQHUPgdg7ve5Rp3t8
yDSVgE0SxCWgRvs9XH3noJQ6vOWRn8qWPvtng3JJ73PpmQUUrj6MSPoVYKpu
CYA6qATq1Xqx2AAUrr64+PrRQFW0BEANq4ECxQGUM2agLlC4+taxkrBfClRF
SwDUqAKo27H/ZIsk9SnW7dvaRrVAytXuPA9Gp6LiitoIb80p1aWgRqdsy+RG
YQWNCPWDjHZss1D/lp2tRQRmHTPBbBFkUMTfq+3Xyp4eiRcBdWCyWoVgh33y
f9sespa1zXl0+wR9RJ73Fu0pUfJog8Vunhqw4whSVK3Sgr9lHUd/Bqq1dGIf
zZgpKN5qTxj3ia0QAuXy8fdenb47fv3qTHa5MQBF/FZvTt/SG3tHrClGmumJ
0VW2ySyDK0OHZ2L5fwqGNPojtDelPHpka9Ye9zy8imYiqeznsex9s4vf2mhf
hvll4m5rmc0s1AUFpXNRK1U9M8am0lu3TGcTWwKmWdpTU3QE/YNkmkYc0JFS
fMMeb5x02u2jXq/fH/U6/eHhwWA0OjjsjNCigDedT6Nz99PgGAOzKcgjoXlQ
MDuRLmCVZLiRgJFnsEhS+MsA4YvG2NpdjcLM2Z3NZE+V0W2ZfOTN3csaVjQJ
/DIbvw+oUOFZzopbuxXNacNWt8EbO1xU9nUyZhhs+6IvUHUhCoiqApOVmF1i
ogqgqziTTRh4qR1DY4/QGdDmX05UPSOQVGQJ+3uhcdMeRxlgNB5PlUjrwBRh
F8P5uXbjm3a5O+0G8MRtq5wIUp9GKFYu2epLDJVxXae4awJfm9wkGT/QLrq5
cZEpazGz3R0ekxFvtaqNPqHwvVhpxDByRfcNRfiZID0NvWA+Z3pj35Pa7qWN
4dVqcUND4bfQf9t7VyrG3g8gmzBdgmxQRi26XprQNbkwAuPV9NzaaB/CrEyB
/SXrbEEiA95j8A15KNgFdhWlScyBRLLnQGFLpU55r7kaRirDU4HhPpnxKfvh
choSHmjisRx5GzzxQCDVtDheCrU7GVzbO2PPubjzcHqaFWiMjHuGDH2bHtET
yY6NaDtY5PIM5QnOyRIUZnKUcWnecxIXJ20zXAEjAXjC9gVQBY2LFiKqqe0G
esRQ6lp+bCVbM2S3WAHRgMM12+p7vK8e+FOkHMVEUWJEod64b4hfLg6ZrqYO
50PfitWpUuFBkDMxKy+88mQNRv5eUajrXbAWzk+LdnMaFHy2zig0j+J1QXgR
AdHQKPaMIxJgsU/BQlAslkSDcbapFax8/1M7KtNxQ+Dj1Nq3CVHkAR0DmEQ3
6ClG3SfCEISmu0RcAtlA/564xC3qh0G+NFtAbA8SuGGm40NYvdTDtsQpbWIm
/gWYSQHMnWI7rKDEtExTWlOAUdnOmSWrsOjkcpS3tvfi3FAPTzdC0txcRbuE
WHn40zpmP5Jy9zll2TWttiOWQRxchIwJ3CldEBM2jrDbWx3oi/pQRMID1D7G
TIaLQnlLxeeNHFL8qwZxiir1JrcSPdy/3qzAUxVNiYllDXUOPeZZuDjfWjcG
9Rrr+kquU/TadbhYMO+qRpsV0ClMPleKm9kyYoWKRByPZykyUuZFG8titwLy
lrCWMhZI4i0rKIGZmhrliKbjKRRZg+xnJluMHixsomlitrQzpvgeW8MdVuho
GuaEtusIuCdK6inUVkL1mfBCfK7oJDKBp6y8v0K37u0T2qndHKxlNpDVRoro
FnpVuNpy5qjGKEyX0SJIWQDiXsk6M7NPAaH3n/6xg25FiwXBmiYUN8W7HXrp
4maSyAVF6H4C3OwyDOYlpz6JaEYaOUTfUT1A1jwNronFieRBMiDEkPicpWFA
uz4bN2sBw9X4KVsSrE9RXCUJI+CUFYFxqA5mpMpSpFvo/+//+t/Y2NCNO2Hb
1LHo304MTaqDhTgOp8rhv0vbkeUDNBskgbH1RHHTAQ4cOiJVRRg1feP8EZIA
ow233pXHDIzSca0hYdGqeRXkBM1wwKDs+5mxYCFYFxbntsQfKTDcQtt/QUK/
AJfvaq+0CuOtOzhIgFkZB0hLSoNNNCJCSzFGHzvakJ43eQ7GaHYDHOMTEzwe
4wBjlQZMrUaWE4BDLLg4MmrWK2RjWmL7iYPWzCzWSlGcagOiO3BCtACa/wIf
PkJCXX/rv7eoAebkg0UdVJi8IAYmcXrUaVQ/uCAFiojh+yaE1kEaksXbgqcX
8be1GS6aFH0kk82zoJYRsYNz0S2XqPKlzNBhGlatRQg2iNk+ksgkYXi4V0u7
J85062iwqtgi2nTJMxXTxs9QE1QyhXZdjZqLW6+i5woiaPdIeigNBGbjREQt
9Cj7aGOZIjpIJLQkr1rnSQJP/Fs6jiSKHg6cnvj+IgxQuCby0+cdmjUIiMNn
9OTOw/8A04V2QWdV7QLYIBWqevSFL/g1flh75nGLwfqCuHFtn1+MAaKaDRI0
74I0ZU+tCxTRGtAACMRoXtj2EQzWoeW6NfSI5BIzU1xpmxxxCqcU04fvPQSn
5g6SwB4LoDhG+HEwaPJPF1Nj+FOT46Q28M8T4ZdFQFWMXB0q1hkpDkcqxLUo
2zqzqc9qzdrWhzKbFg17CP06DKXcpw6R2aVDK6gLjxIwaWMXgHPviSPoCydR
+MiHD+pIeXfb895UhR3sGtLqoMGykKxTL66J4oYtaH8rc8q2/wccfwbaMssR
5gnBnIYPGhh+v/HPA9B6IqBnEo3kqCy5OnGyi5CwZkbTgTNRR0Lnb5ojaAzP
QE9HBC1Yo8SQEolzkmFaikQh9NSENZEUwHp8+q4l8WX6JJLRQEIVhIAiqKQN
Bn4dtLucOTcRkYpdkQD9QBFCmZX5wTxY5cpbwX7aoyPlp2WU9bsjOmpgeB7C
C5Mk2neLuCYuSkKA7M4JPwpy1LaFs9T39vbeB61fJq0/dlpH//rB+vFT618/
NG47zWH3rvGdefzhp3bjaZ2qfwPVH1z5u4au/Pmndv2ZcDwKsKl12+3eQV+Y
JNA64U6h0gwIaDEfW0N9ppnJEyCYHwnXbIvH5PECwlE2B4gdPXe0o98U621B
x/L8sheI6TurPNLg76nTD5Za2UAS6DyYs3ZHBz1/7NeWNzjgtkCJR6R513Pf
IGIPu8byDX9fD91h/k4XGCCa33iT7s77PU9w5HvdBk5O98jvDE8Od6ij3IJ7
BBrWHfXurSZ10U7a6x42hC6HJ6Oj4eHwbNQfDXqnw4PR4bALzzrD4+EB/O4P
z4YnUKsKWSVKYJtCk8ID5R2d381uMjxsoCagtmGevvpcjMr7pdvw2etofB4B
DgfDYe8EMHqEWB0eDE/6E4Xj4Snid3jw1SdNzw7zdS0u67xXQBohizTtrTWx
87dPdPk7DBqWQ7RyaJZfZJXh65kbv673Ee1ztHYke/EgrTj17WD2rCSESvHs
fNaXjE8TT+sfNNgrQ5qEfWSUNG6trOPQdVC+BJGqUyW3t/iXvJQT6gk3x+AJ
oYKDBNRGGxl8TeZ+FOiHr1V5La+K0fMcqk6nQ1WEWOiEmEmonHuqwt5Fo77Y
T2OKm9A1FTRVaUEoYa6qKDVIy/R2pYtmS3i/+J6zZ+zleFz8/oOVAGYbLXIG
25ptYdB6eGsjuZQx+DV0BICmBQVbeXSfluDXf5rfDu5a8G9P/n1H/46tf/d+
av80/6bxXd0zvAFVgz9+fv/TNz+1PlhFG3Ut2g02bCxB946dNsPgZ9ssEnmL
hzRDDT9+aAzO0JSlZNlUSfKgmraZUq1Z2CzJ7B7QgQb23/A5RodB7cDpmi7V
6mMvMeLE7N2Zo08W/5F9ib0p7RHL/lyDtE5nd2YvDy4utL/K3iFpENGhQiR+
60B22Nd89loZj+SBe1E4zGDz9KZ9bDNEQ0utaNlDy63zo1WcgEPpChXE0rL6
aVcDgjzyK8NAXVR2D2tHi5Y6Yr9upMtXAgp72AiMLc4YHkeafS2QuJNNM1Ql
k78WJHZf9Udo570OaH2321WifZeZiZ4Oahjo6fi+e38T0AYzPV27q2pjmCco
nr1O96DV7bQ6vXfdwXgwGvcGf2x1DsadTq2JtQscUjXTb6hWurqVzlGre/Cu
czTu9sYHh6oVhMFllaqNngLF5Y2/mrpbsjue32N3OEaHqLs7dWb3BJ/OvXXs
nlStyb2aMnfTaxjR2Nlex+rGrjU69LuTbbVY3x9aVeDT7/U7/W7/oHcC/3bg
306/dzCA74P+BP4bwb+9/uBgQm8O4Fen37Eg3Y6TKoT8GpB2+kcE7wFACt8B
qi68nQB8hwVItaP9LLoQE63Fa0fc7W/pmaTN4TeKSut3G03EskyXXUFXJt+3
eVVlFXj20aRq66DfwDwJ2j3ZqvDpe8qnTzo2LdDyhs8OvnmPPaiP9sd75I+n
rdPMaM+8QVDKGKI2V6y9le5mnZpU6vI2q9apt2jTctzdUamVKv0Ftr/N2NH+
F5c3UZX5jU8K/Ld2H89WFR2WW7uHR/+luDAu53t9P2pRD+5zN9i/6N1g2MVf
j2Xbw3KodjVoBxa7GfaHx8Mz+Pf5hhoyqV/A5EedXYDqFpjgsD86GPVGPcDO
6WjQOxkKduC/I+Wckfb/CuJgeLLTmPqFMfUA1WdfeTQPFBnOrkKLVHjg+foH
barqX9u9PBwfV83JBw1xo+ikIOTx4Cr/QTYwNvBZUpizMEhnl3ULFVs5rTBk
cttcJ8pr1WQuiqkma5zsKwrDkH7+/+2PXbY/GPM8F2ZMzuaHz8kTwnmLwh7D
9P79kIcaP4MhyKP31lw2rYmU40/7CkqxFgbDX2l7orwbUWLJjh0wYE5xWM24
n/AKNPx6WCHfhOcc2mJDybRT4Ge94QgFhUbHw5vC/7lNCTa/4v4Fz09t61R+
/T2MR28vbFQq4C9YfyDRD9WkFEa8hRwq+t2BPjZBu5VgKirtREG7duaQVHVn
RRoTOUgiEBmsfFVbDiAVtUCk44gpR4JJuk3ZjvhyCWmSD5XPtEsIejlFzr3b
LG4kQ0FoEvgqmVLFaXSz04TC8wVFkHKcT8ABsLE+a5JfRoWkuLyVQ5kPwoz3
SQSzW0UotXZJ6QLsJAWP2HjAkFgMmkG87ryrQOYeKxJG+lZIW5FI2AVJJNwm
YknkiaNdC2BHBKvYp9llEuFo6dANBk5xSfILrucrbUoZE89+Kl0E83mKIebm
sfSFu7LPrIectCjBk4fpOjRv7tz2LECsxvBpix3j5Zp3lhGmoJKYWjzwSA1Y
SAihHUlhrDvCZ4LKZ/ajVVh8kCQLsy3hI60G60Vu1dUwRNN1muV2z07omKpJ
B3KdiisKcHhIxXs3R5BU7H2Rd5ULkfwYFuu5KbsPqs5oPCbEgvWYys++omkV
XjFU3k41W300yl+9OfbfvTiWwiA9ua4TmHFkXLYHG12++0TWUmVoeXnFQwvj
acfprD0LpBOsosheVevZ1dA9XJHlAKoRdas6fVPnTnkfsMdOs1ST+ywStRrm
yPVME2GU2thXBKlqHZpaA3+84TT3vqJGBbT2oQvI5TmZ/CXmJNBzYuFn85wY
FvEVFKuyXnx8XwU7RGerllysWNCJJjs4XhA42+/SKRPmBuBsH8Lw9J5arCUO
XOfA4PSgN+j3OgeDwRH+RR1x1BsN8V/UhAqL2AJy+8AsIO2h3eMjKjuI/O3u
9Q2+dfgM73eUdDtuFR/jhkA/7INueIpqMsXidKWKzWZc+LaMacMuBXwq8qlU
jqpnz/Hjdho69znZdC0bIY/bf6lIVOHWWqV49Du6Cq2gK+ztvnq6N5uAKzJQ
bOztyzaj/jpLsrtxSU5+vSV5H005jmTp6S+7JLsbl6SRMvd5A34thUqHOH2R
e4FmDjUsR0TXdMxkUXdSBUDo2nso8ERkaq2oCJkSqNLUWOEpKjO1osZSI+1G
vWV9pKY1FvWcNY6arw8plJSNwkgmDx5JUOS1fzEFYSe3y4N8Lmrx/mW1iOF9
HJVGUOA9Kry1ugbP6tdUOay27+O41HZhEwV0tcGmLaUnTHNfpotU+YsKII1K
HAxQOgC4ejDA/qjv1NBE/1fSXbYRSTWFYEcddJ1VhFg/EWbz5YrOI/cFu4hg
2rI8oj20I/h+CktyAEuyY++kPU4lGpZzS1VAVQTqaNij7cp+GWNPNI/9cg3q
UcCNOrSLyrpFGThh9H8Fhev/Bu5V0s7+otzrEWrbf3Du9SA1jx3yco1OnW/m
4h+samScTda4Rs/lToJ0GuUppkgT33xldmJyMJvk3XL1ER6HpKtNOPHRUjIO
0NF93wJgq++65KDXhyVZK3XBVtmFlA9f3aRFybk4xYRkcaKeVSJVCXhWEE5V
di/JGONkCaDoZDdki0JhbySMuhJBaitDzivwsVoJR7Wc50+trQmpJENTyYMl
S1s2CzDfg8RR7xES9K4uHvjHi+NM5MFdoyn5xHVhu5w682EPTJomGHjsG3Y7
rPgBkwIem1QWQUUq5XvCBgKVvNykp9PUYnJrS52m9VKnbLHvcKsiLyuowL2T
gy+ye7b5EImQis6nbbIV0UUEaYgxgYG04y+SiwvKLr3j2XKs1IJKpOi323hf
rBraIsjylkBXYhPoIRx20GRRyv47C0WybSQHDnGmMOeKLLBSFgwbHe0tB+D1
zgbC6fkFNFqFWuzfvzWA9jocAKR3SCS0ooIBqgpd4YCFfR9l6ZiWdGebWupt
a+m+vYeHGrI0KRvcwvvWnLKTl0orL+9otMmdvF+F3j2NWuMmJt9yZ3+w3+vW
mk4DBum6XjEe/PUqjP0VjLtXK9QrdPjVorcLjujTyckOmjHjEKtsb78g8kHv
HmyIRLMaH4120NIq/GEbINng/Nmkm1Yrpf1O76w/gP96/a5VVM37/S7KDb7J
TYrJBqVkcIY2A9gPHfh7hH/75H+zyEgIAxg43f9QyN5EV0wso4vLnCQlvaWU
RigDiGnZCdm0INpzzxjpM45au8Ak+uFCsnH9xVbvYLQni7FYfV/Y/H/ktftr
RQlpgTY2yLKinG02Ni7zNCf+WY+6ZiPGeasrOURXHt3XcYTtcoa6fID6AG0h
icvF8OFRfwJ/u3TW+cS8vZ+fVYDkcwzs2S4g9R0G5J6xPlEujP7k/jIA9XCI
24DHDLX/SIv2aBeoj4r2uYahZNs+sUnoC/0AlSzX9FPivNtsPH8jR63CaHE0
TPJf2lMl7zY9lVm4ZVB+Wi60PYnXS1Vac0Yt12koXevSvtdCGXEYrMynukXp
RiPLztqd0IXLknK0Bp3XVKoNlckLb03IYhA2qdiodG8KxU/NdUZevDnZyhnT
blij4f5fTv5FG2LMAfUReN8+7mrZQnRDl20GwYNWGl7AE7z2gw3TewpV3D91
r+VUzNhEGQw3T4wVZe0c3LdC5OwAbHVaX07wiJFYx32NetOvY4p5CfijR9Xx
YFYQGB3WqbKEpkHakq+OKYQDgXfPFG2yHIPPr663wwd3nHAcTcqd36TtG4xJ
3qcsWnu678fGI5f022HH1WSxbdoG6asKvNOhPWHkYKx2I1Jmf+dVb2utX1fw
m/mj/FxfG5Ob+Z3B8D0OzLIHc9jD8F/gvicglwfIf4cHIJ3pKbLFwhjtidrc
R9UEbi69cWJ3qtJ7VC9CCE4msbq+wbpevMK64m5rO9t/hUumkEJFJen3VK5v
yqhqJ8SdupcD2NeZmau+25vBofStfJrlxnFyUo/VYcbVzi725qkcKHKd7NYI
39+vsxxY/EdJ7mTnk8k3gFuZfkH8fzuE2wp7bc2SZWRfKDGp4rO0z465iDGd
s+3NkdyD9B4mKdfvderBdMbBmvBPOhubgdC3ME2TVEXRGoTTY63Tk9OGHrXQ
iDOb25yNS1KoQm9OAC1GX5tam8JnndZB4j+yB6m5Uy90QIrEarGf8oVzzzY3
s8RrRi9KjdieKjdG2Ei+SsG3YVUU/eo6OfYMWFSkkiFqf7DjMZUocoqNx7w/
rM1gvLY6jaZyvVoJejhDjkkJvZH8FbU8s/L6uE1VJKSMMjsp49Yl6bhGld7k
Xmur3ooyZ5N0FcjF/tTaszFblRvo4ZHGnd5gc66HfVlfEjEKZbU3AgNaOt1u
VSTuvrUEVcVDO0J102ff/xbGQgpni2dJqne7dmIK+H24rV+1OFXfB7v2Dahq
RXFLrkGRrjXkFLQ8GlQGH++XVqzqfLhr53iY+hfQ91vrfNZKzs+ROtUBNe3F
oSDil8GnaLle0s2rIay3mguDWu4KgpEd5fvVY3sH92ztOy7KjpzEnuzm6sCe
tDJ1T8Si25OuhSD2z7YpVQ583S9MvMHdbTOh3e50PNM90Z9uxZ7d3fB4W3C1
e/5QW+33xFe6FbWueU+UiF8dKDI4AX33EM9Wj/B0fYf8Pn06FYZBWwPUhEsk
XpRIFdGFO4gkyZr2FWXS5ptYz//fkU+l5HRWZrrHhG0qdXJMENnuXiVnyEfr
iI5a0y4iIoGK2VzeLaW5t0RzlhiyW1wYba2SJ38d/7AsKstJfO/CLS5F7eE0
IZOY8ZLikDB263Q4BJuU8zucsV1aNQk7s20LZCvtxkNAPnIdyQIYhpUNuxsO
kBrCUD1uTwpR6NFJDoH+y9EQujqGbwPolr4D73J9wS71/QrdWiMFhtkZdcoj
flKkb9XtPedrCt06bvJTyYJxRJF7PejwdDhyY7qeFBaR6nX7vkCx14NNg+X8
G13yuZ+hTCgM1ixTJYd2WwSlFeBL0CZui0yI9HHbARdFv4cuGvhQeNnA29Jq
VT+VvONXJokTDghDgihQosuddpbVTrcPEtjc7UaZbdLG68v/6MaYdxTZozzg
t08q8oGwZC9Jv8DKRcrHu9HaBUNlawoQbx6u6KYiOWg9XUcLpGI2h0nyBZUV
C1cbetl62pLM8iLismopTccb3G60491TQWGB67HX+afavXbhfg8+g07H2rmM
yHIjvll3sI3ie6LhVKBVlM3WGd3xY0NrEtuXbpCkyfO87wHhfMuGvo2iSX+6
Q/7b75H7Hr8CpWzNOVbqo/q8fKfx0GRcsV9f5mvJcL8VHaJydXuHHX96k9/j
EUOfZH8wKJ46x16gP5MEhfEhSgtbl7XhYbu9DD7pHCqWolClHRFIRUWC9P2D
TkfP0tbJ4bmRqTEzs21ixEdYPTvunODqI+ji4o3kdrluA5Nmkv8QMCXrMJjl
a3UV+MPzrFWw2gfMdKsP9irm4dxhrqsyDGA/VZa7dQVAaepbXZgzv9328e/O
BICQlgigDwTQ7T03+6dyr/pwUCciKJCAfrtxIap72c/ToDrdhGJP/fZAsyd9
C8YDp25505L+HjBjvfbB6LEzZTq0MhRpnPAkqZGDEXKBG8a9Z/bcdXHe+u0u
3s7exYvHe52HrePB3vtWr+n3DkYfGqXpPB7gAaVelxZ2t9M188rOWpnUwqxK
3qit2U225XP0VD7HB0+gdXHILlNXC/PLzoZ0Wg5L7VdNXlWyrGc7YJx7LeEa
Jpzsn8O+4Z91ySNRjWd5uR3R9ka2bFo7HHDUxGP4NHagQuvGYB/z52K6Yzrr
t3OlR0nDMA6mi3D+gKnbcft9w7qT/szs6Xwd908fHXEsTt7ZgZkzK10Jzxuo
ktazu+I02ulNtk6lknjeF0o8T0s8v0LiUSA96swrnl6MJ0H/jISB2At3D8Pr
6TIYmPRTaxhW+nMW2V74abWIZlFOrYngLty5RBlC6QhDnepTsu1gnSdIWni3
+I2nqzoJioLFRZJCN8tqyXDUHoJs6BWvpnsojSarMKUspuvsQXQaUtDJo0nV
6taQazkjDuW6Wa/8W1np3Weyg0Yv5njdn3rVc14JfPpt33m7jj/Gdt1BoVlY
9nGu3x44b9EkVxeoqhJDpwTgHga3CG7gXwfE0bOqgMbK5dgvrcUOPPonJkDc
2HeWIx/ecG5Dq69j/WrT+vPulVkqBzGpsM65FitkivyQFhHfMHR1Q/o6VoDX
Fh1ruL0lCOkAi3Nq3QJ2kZj7UD2bOvQ1zkEp3WUhXuv+SKZORfJIn2Bz1Ms+
aShb6TSeJmuMfdhZSRns1XSlWllPOTn0e8foxRsdDE8xcyr9JWeAJUtBe9IM
GX8AJ/6HMES7nm7ZjujaPLC44Z1117ZhYv5WJuYVmZhqoszH/Hv4mLeBj41K
fEyui5Hob6MZoKI4S9aLOZ/JCmOPk6PxETd3gHsJXsyKVoLcqKFegUxpqtRq
eF+zvoHGE3x0m3IZqeaEzDqx/WmIeKEOU0yQVFFQ7r2D0p7cMgzF2yUtJ6q4
MUgdFisnzIPe0FCWderZq7PXeKRswxNZlGTN6qd4FU0mt2078xFlClWBYHWD
VO5weKW6npmQ582jjG6VDucNxlbhlmKgpdl6IZc+yxRqVoNDsRDR5BSE+MRT
I3RQo3pIU3Ug0Fbrri9DznEepsTUaFJwZUCXHkbrJHlbLP4IL1pX0Oi9ow4x
RkJOyXBfwio+l149p+KGwahbflUDXHi5XuQRB77C+8O2f5ag3iFn6KJzTZrS
hYYqp0tvo4zdeNykNR0HHMh0HqVZ7hEUApYNEWFPrnfhcCxNIIXlNujg3A1G
dJ+jxzeVAwNfzzEl/Ityy5LWEPc65vSCjpFQFzhbN/Y8eQHwyJxnZ3CI/Rwc
0BBBjNCtk5wjkt2A1JSeSM2SiAWA6gGDhfp0m591b3Xbn5zncq2tQ14WCeL9
8Dyl+j5mPr7iIe9BL5aKYrbHWZw+7zmVpImIEwaUYhB+CdOEmwFpm4uuNq+a
FAq1o1t4L8I4pAuixx6j+Ma/JvaYzGbrtKIZWuQ8KtMfUzwaVMBnllGOd6R7
kbRX1VLggAP0MAtJchtCoy68QhdpuEzUzew2nQfzP63JMbteXQcpEE4Ju1ZD
0kgbY721ONeX1z5U+8XTuPpCrk3ar6e1X32Xd30GEg2lHhiQWq4gI67DCGJy
IZjnh6Q+eXWQxHIlN3VnCnQxbud8gUHlLCoqUllbkFr2HVIPayC4GkWtfWY9
mIMOCkMKotQ8VbCbJ8QyrZ9RbP+UIenANjMw+yQnlnRGWC4P4yzcocxJMquG
Zj3cxXx9f1nvDDrdetPvDpo+/OjWP5T0qcO+P+hh7EzX75z6A/i3S6faAnUO
De/lCtRd5SwQZT3h+YM4ZAFFagPqv0oe4pXw7prgy0X98/Bac4Ysmodt74xO
uWFQQZAxy4Pvb07/8ccXb05PsHFcgFb3qgtcM9Lv4sZwBC5EXJoBpTJT0Ix0
j+8SH5gqLLCURWqUNYHSMQ0sHx6YC9vj6wdlxfCViVpxBoa6lry2dL2IWUYI
Td0mMzlGYNYH0TWr+LCw8BDbtWhw2+YTZnBYL00gTtnQ804XxqowqNLKFKsm
1nSIVjanJL3ExCKQKYarkBahFZmiPyJT98c7LYpPnwpw18ECM8kHJMnoHAzw
tWBGktKoJxQErF/oBkhUxRxZxjkWmPiYjCRExlYAqUfkS2Ewd+4NyHxkpqLx
mwqbGvVK+hsrDAyJ90onNcYNrlm0ilTahUtAwIKS9kZ0o7TFostSMLOcIpxa
wuPQbIQFRTulYcgydNPgife4cMaUDvJk0QJ+o247Q00XG1u2HZuYTaG/gjEM
2KTLeTJYAiSPvSz88zqUnT+O07EAVPHyJPcfbxAT93+IJfyVpaN76XggNjQh
zQjObbzCs2XgPZkXipKj1bM2AmNjmZeFiX5qSU8WXzD3adBCIKoSC2yx4/to
x5txaQm7waZ/Dga9r2x5CrHBtDOdYXd4BL86wz78PuI8VxgDY9v6eH5ug9uc
z9ZtdbXaIqp6e6L3GD93EGYg2lsfw5tdyERciJ1P3fPuLBwG/fNBbzjszA8P
D+dHvWAwP+z0O4PRsPo+9Aoi0L3bihEhQ10UStdpdIe7+mUu692z7vHpcNI/
I9BOALSTo95kcCKgnZZF00HHv6+Se9FMGp5XT6S83HK+RR9roR8V7lp9MzmF
P9C6WwX5Zb3gkX7EVKOUSM+J19Gqo1E8aGeq+5idKaUFV3RvJl0hTt/scunX
9nWNjKuYB/t0orjiAtpiFWqQol30G+kDaa6mmyknu9+a9oQDaC6ji0vtLY7O
3YoVw30YZ2KEb9mUs/Y+rVM12p9oPbu7/47lYLVKEzDC8Q5b9Ejpu6xNK2P2
2BEdvuWrol9QeO+JOmFTfeKCHT1YFdHrbdouH7YPC/fJvaVUSSJZVXYsy1fG
HjBQ8OLq3EGg82dylo3daW0+bKkOhzhnkWx82Wnu/4DNVyaY0lEjVjN0UW/p
NkHssMk2+U7bafeH9/h7Wr1r4lCobXWOj7xxoslpA654fTbeos7psPxlOAOV
MMooUjsE6JMbubicMKWvMbcG2m48PAoFQH8AvzFx3vUoiANYXxT4NiavXxzm
x9kymM3rcobj8LDTeMR+lhqRtVrlqgeYefOS+i+WkDNr7vNnTkUXVqtOucFn
2qTWzW84L1fZ644RUocbIqRGB4e8NPACyMLS8LyJWEdgaixuKPeXDRXq9xUE
HUtLVbev+z6tKnPWgB3VTquPDdUwV2+K59JMowMMX5iJJpEcy4S1xEuGJUEh
ZZndUhrKYVQs1Nx4qIHu2lTj4Ps1X+eSr69JvlY23jkcwrl0s9AKI2mF3hn0
8O16T+f2u+633BenUbZ96fGcoCa+6UwHeuCtgxU0Axlo2FOdqK6K6W49BOHX
tsBUFpeYjGWKAeoYpN2loO2hSbdKYfwgS1GVx9jm0QDvThyeYKJHe6MOmGK+
QXenV1sUPo5/WC9UXguLSr0tQSuPUuajrJWCSU7XBd3LZ0luyvvHxnDqDq1A
AMTHLm4/xEk5amVokC6Gv6gzrAaUwmnjzTEqRt1WOcSrcoZYuRPbLOyV+BQr
uFnI1cf+NZ12kTZjLes+MGY9xhZfJdEc+cj5mo7vT8P8Gj18hvsUmtuQeFNE
t6IcyhuJNjD+tba08afDup9WHYT2RLMqZD7RWbzUvou946W2GnPyCHqTzEcN
B7pUK9mOJ7oTFxs8pl1tUAHdoAfyHbBHRfCnPGAP4PBMwYrjyWVjrsOI8tSg
V2w+Ny5TDLSCH0jinwBP7CDF7d5whgcCwPachrNAZ8EEcR4l2U08S4PsRpGN
njVOYEq4o34zPqF2naQfgxSjA3zaMM087BBGP40WyFhZK8WLH8lwmRsvi72m
k6swXXCcv7QOpriPuXMQgb9/+/oVK8nigzLb8t1CbNFDtTXkJauW5M7dmZko
S7HX6XTH8+nhOOhMx93eeWc83mQ57m26I7RRbUOurgYt+7qwHW4FfY+3dX5+
34V/+WuX/vD3HvwZqO8H8PfgQ+OnduO2f6fu9sSbQR/agrlU9G/f/7S6fXUH
/3x/9+Gbxnd1bbNaQxruNiQczPgz9hS0zietsw+3neYAENXYKz4b44WlBzIE
/nzDF6SWCn5X1WTjc7mqjM0Z7/tO98N39JX/dVBnKu9UtdEoVqvEnYON9/95
/OEbGOzwTn2nfxuf99pPf2q3nzYqRyK1nnLZ78bj0qMyKO0Nc1eeuZID06bZ
Z87jof3Y2lMrNmm62SmYt3L5lRWjAV+7jBcvT4aDYa9/CH+7/c6wx5cuD4fw
boLfLT9DWZgYf4N59wX+BuvcktVJk0S2Dk16sAuC+KXTROkArqMxf3XPQ3mI
LgbVU9sTwcY4JaNe3IiYp+Q6GWOCz2G9YCOGACTDWx3S1va1Ka13u+yHGiMS
OEDJPE3aZbGWACXZemr9MA1kZZlsJQvPJS0Jksf6HIiDtqXwnmw1ID44rsDd
q5A7oBsb/8cX+TFUPu4NdkjD+7u/abX8F5ls/C4wx3oYJ+uLy+/8VuvvaQva
RXeVmCQwZXNOXSBuZbHGCRCUgJYwdfUB8jR+DG/2soaDJYqYcaIbxOOjm4Ua
eN2pzuquiYrU5y1kUQ5ue5yXiuN8jDsnD9KLEIW9TW0w8C1QVmFT3WhbSAX+
BVfXFg19S0/ivigB/TsVciWTWLr3PfuaGHrqv6uCzN3MNE4zdbQS3dySi39e
WGXlM45V3VMQXRZy1n01ZLmkvMA/abOCdpLcvYomfk0pppvUPOoqWYFaeQWq
s6yAeC6DYzOKgBewgNFAhxyYYgj7VN2ca18znOkrgDHxOh/cNFon80MLtcqM
rBRs44fHH5uNCL5Hy0qkqHTohBDREgeLrSdUZ6xSAv/p0zOmPdlLe/r04X6d
erH/ulCL2nTS5par3df2eTj7NL5ZXtNpd7qP8bpWYEkhSDrYdOGwKoYXAxcv
JoYG8/E8QZuqxVcY7+gUhVFUOkWHxyeI9rcc5+ji3U70Hy1J1tMFzvhftQyo
Yvx0EbWabdARXpDvnoIrk2V4zbEGnK41ApGvQxhtQQwmIuUbKWIcFpGHziWY
0Z9nYIhC7z8rNrMgHwouOXWXxs/BOr9M0uiXcI67sT8/wmm4E3HJVlyRrrB3
rMSa4j4gId13IdqH/yitAdAeB25HmaxyE9jFRNkfcEZybIWIpDZNpjUartum
RHJSkWC+jGIuJNjya+cpQllzLmSQa7gfdV22KrMCuK+BoznUG8TA8caz9GaV
ty6D7NJUwR4LgBe2MBXINYJDLyUexpbtzN03Pk1Jc7Rpp+Jq2tzSvMf/sP3Q
9zizTZ7Mppqwpp6lUshgRQ6Zw6oLwTg76MBcvXs8tN5auaD6XKZ4cVLxpiQ8
7DHs6ZcEL9U7qKync3zQLUaUVMSXm4twgFRzWFlTJ6AYDiUJSR/6eKIxogUH
sKu0yMC+wtrW2upO61vLkH4H9a8UGOYq4SOAfP+ArN0/BbOPta0bAkgYnaaU
3IkMegV02ncZMgn0KqafU4HZ134V7/gaTmjj4DlOAkFjZfh9pQzOSofsJMb0
OKUXNXNcwdEybfeoGBceMJBFcpGsM8PlP2EgU+lcCHsQFYKeiQUkzkPvqN3t
F48m+r8DtexKWW82cVjbT1Gl5a4OXqqDCMYpT+qhY3c3qbnFjda2F+F5TuH+
e6AutkhdbFj6ic44vrjGu5usPORVm2ikQ0/iG84OgiF+eUVb9zSiDm2oFOtO
qKKyhimGlbYTcW9sFZCfn+1tFT8vm37cpJim+jIv2TVDNLFr9zJZzNlPomHN
5MYvOSoGMzzH1UUpGs7oSBGfMvG8fcpNZQJjxuarCah5j21+W8dz4PUPUmM1
RtfVfrTyvMikOd84x9prTkq3QmyGdK36Q3atf9UYG3IPa2HzEtsQdNYK8Nck
pjfApgFAFtrwtdSI1FzVRJvhGGbE2CeKMPryPeZNavn2Pc9tbp579j73nUt6
XaV8B86Hu6Ezv3e2+S5Y86t3xsnO+Nq70UCLk/sU4l9xxLDwSaig5w5m/COv
UJANubhywk8mwCVe3OCuAXlsLvN8Nd7fx7G3l+H+d9j2t3/b61Xhr0I48XL4
294IhDf8+6GgjOrXJKOxwHvRtvAhi1+qprQf6JndRYUEfpXzuRGeOkADq9Or
AqZOoNQNIHUGo26AqNkqlkUllQijcPBvR4ft4fO9nemlO5LddKIaCoHVV5ye
wTu6iPLguboopH/SG7G21Bsd2PXPKIh2godleyfD51DrqFBL60pYE971+YDt
aDDqjY6ohKUTSevUjkme1ijOiFkjw+co0L9k2Fj/S4bOCuPjh+8V1MJqFGzV
EL8SD/vSNYB6Vf3DJlqums3+A24JOmAl8KtPvSiKOC06B9wxX8XS4qRvt0/k
ahaKc6neUbEzq4EdHHFuOO9num1FUKdzk36DaPlZHXu2D+6qkxx4AGKJh8Dw
pIunPdA/R/OfzTvlrpSjOj/jrPyMOwA/w9T/rFKpGmjsA9bs+mgxbSSzNR2P
cjLKFnRVzPbflvORdpsGGgIOOpRqhUwi+jqbpkcOxQ0X5RgfDLoe6fypiRip
UAW9LcFt/h6A9C1hhQ93l1vk7asXJ57Z26Bz2u0LvIEnLtx0Sgo/mkq8yQEt
XkV0Pty+ga1y18sjUHBaABK0r1DFxxg+QmmcFGcWMHEB72MJTuPIs2VwQ5dv
6kAhth0xUElCBbaRW8WhdLRXPHPhDYyz6UsyQ6XZxvN9tWmzZ40smCZXYQOd
6ok5kqDuYy3G/DjoqLgPlfZGOO4jwXPSCGUY86YX0lMSqZtrxakezVWyAm3S
ULyMV8AinYOmPMB4uusGVSVeJE1eIkwUIcd0QIvPwKbw5JAbtHqJen3cpGNV
cXhtDEANIu8r6jtE06X38/ug9csH/Ae30p/utdTXbxpPf27z7X/r5TJI6fww
cnO1+AwHgZXm2xwnU5wClGpP3wwifjUkahPCNFsAccuGjCEF3jTZQhwwcKZO
OoRptWw3wuTi6wOcU/Qtry/ArCX+pG1RXqFkXlmK+ypNMKYHT935/h4vMKf1
dB3HwiswPAiPxCHRsOXC3tRe75Bj2KEJpy4BgLeiRJjzIMX4TFoXSJXW9cdZ
49kOeGA2ugMi5CTkdcC7pmF8gZnsgcqRRUDn8Iv3XAKVPIRTZaAgh+pAQ8k6
RXsdj9JTccJYS+UxoA1yTtttbcUx7ooYYKqFcc7wbJ8CCe3rPMrXOfZXGneb
xv2nLIl/VscZlwnGgOm9YJdlQBv2SUM2rnGf9yK8F7MlhFJPEvrlDAVDLUw+
ixhWRW72qqIY7xhGvCggZ+TJpz1bgySM7kYo0WJX5EobgHR6F4GaBrJMLAd+
Bv3h0iaB4CtO6EbzCqdBF8YEmEvFYqXiTuoWvq/bRaXeIIfFjYRLsOhVrvII
FI8Q8J4n71Si5efhZjeA8ju5n1oi5UxQZaaBk/BK2phbAJUoTwmsszgD7uHB
As2TWbLAIjDFGJ/H0M8SlXC2qPXwCUu825KYLmB3RTuFJv7tQPuv5D4klbs1
o/0Zkh7sLaFR4VoNs1zGggsCt8elywKaAfo3p2/fHb9+ddb23kbLCBe+QSsf
Br4K4PGUNtdBqZv8wNnfg5XO/o5SQ2l7ZyxKEZAJH459TUEm2TMrafw8XDJ3
wjO6CjTM0uvhgApNicRWOVn0WEWXY5Yrc/jEB6StU9yKPFbhkbwgCMuZejlz
XjK6dVpLAt7aEqWVdaNUwZKswUsIzYkCw8KRyk1IpaG/QqwlbSPBMl/DTLX9
CYaRzC5Frum2SJQiIeP0gd2yzkMtUfWg6NQyzamKwmbXaZKFtkqo4mI1SWii
hRdEHp9IgZCVxHkBKN7fwxP8YJYDnfxiITONso8ZnpY+z6+RYGTFYi6O6IqE
GS6Dt797/eP3J/AUL1zEKFJf8lW7R+KJm90on691vNBGPZM5lmOWG3P81SpF
hVRusFGXokhLGQr8VLyJSn9qqpgnOnNWt7QeqUU6uuxoqfxDhBCPL7cSEYF9
h+niRo2uEPWBLYkXFVpq6kBqL5uFcZBGSSbH+o0OUrjYmA/IoA0I3IaUWs2S
otgz1dBx3JZDXvo2pohiwJvC+6WdQEUQKG+huDj5gksvBcIMKW82iFutidLN
yjazbxoRUVHUYxm+kgRg+jhA2/dfasnOaYuu8FpmgYjIQap59ikCRCELF9FH
MiMaZpxih2fNadwrNB664goFEXDzqzADsJBJkJI1l2vlPGJaadiSuDsUS6Tr
2jFhKsSLMpwRF3oxeTUpcaAnT/yXZPOxRfxGQtWLfIWCu92wHVNNEWaNHnHa
55qvot6h78985qn0+ey/wxAyXB8Vn88AjZzT9T9DG67eYUpt1k2ojbNj/5/h
A9+92zGQRXQRf1vDXY8aGPz7+1TgdN4e+ytMf0TyfIF6rq5osImPxCDk1Y65
dvgVECnyeugBtWTAz7c1ikafYTeEJNQ+x97YBtfz3q6nuf3Shd/z3qiwIuM3
wGKv9iee91oFSrrvwIba4+0mx7lxJ+KaxtTwPH0Noit2sAU5Hb6HtmMDDzJU
Cigsyf0opttyC7hdet4P6+kiyi4x9MnWNbAdqxCMAhbFf/LDJUh4HaeLec8k
bAWlwPk6JdZlLURs5vj1m1P/D7/FmP+FjoTYw6XyG/R/tZP0ooEKNrTw4vTd
Gd4haBRtnNE3YbBovcMULhPQRsEwTnNTE208MdFIheEeX758/QrnCXX7mUju
2BSIQWUDjZK8yfvHpFKzvIR1FKZYAiHxaCGSHuMqGg9akQUdRa3KqmZrTc8K
Z6wdW3YZ6l7n64V/Gl9FaRJzJpm94+TNacP/QVNazVPrW6V/eff8pI+SMsyM
Vl87/QQyKIdBXEXhdc3vtHoHB5LEGrkg1OkS4uFLjypbdWmKVM3ewbB1BB+u
TDxFhsSx0Rs+ptQxU/tn/8VJBW/ZxkNMW60S+0L4XR6zrS1thW5oq/fQtmC1
bYKr/yW8D+p/EjVGHVSi49Wa44WeaPTwhmYka1azxJ9++tV5LKwUdmu9w2wo
an34t0+cs1Y6bFg98WvAEad8H0/GzI1aaPwdCsa2fnV3VwOeVnzWxDP1KwxJ
so4AaROIVPQmS1jK3AdLckZ+SH08kXol2Q02KjbKV/Rk1qGwwjE1dWAOyADg
hOmk60ooFv+ez2ewODBFL9ovD/oUlkULP9+0dv48oOjmikj2/gDJ1/Yy3QM2
oY4S1ij8qZgLPhy3bcTOgvMHg0f0bGe8LQLgHNprb+n4AJ6VopqRNKqAkY6L
x6Xtju3kFFs7Hu7QMR7PoPhu1XFFiEIJAOu0CgBQ7nhU1fE9qN5wJAUDnRqq
Y94g2zBiYIRP3CXoA5YW4bc1s06VIj29qXCOPEhvvIedeR5QvD8NZh9RQ5/M
MEEhmOUXJHURVK4bzr+tUUL+2l1RD0B2QwntFhhYjodW4mxFKqOktpHr8q74
wCTWjMlPd3t7O4nnN/5zQB8wizvtY7j9gazNqwA3v1L/bZ58xJeJdcNe277n
XjheljAcgU7vBKCs1qKHAMjYPaeL5c31TDLd0S3SVCiIP/LpWHnPkaLiXMAH
rNJg/Mt14s/T4DxXWS3dJgka1W6gsRqKQECVoumfh+EcMU+SC8+OsqojQb63
3wfzKFsEV/73l0n+MbDw8/t//5+A6hhJ8d//R3z97/+2mOMVh3cSYS8KjKen
CHTeFahIVPdlkM4S/12E8uEOd3FP9fRoCC7DxYqUTKPnLsEAvJKwH9WsKG8v
Tt/+1uMxKV/8MweLLpYxFTW6AQ1NLzhjoqfwQaO4WEdz8rILFXHoYBahy21y
giM5o9iHbBaAVrigIzWR4Mjj6CudPVaBz6PL1hcXrDhA0wi8vwyRxnEv4PZ5
GP8pAIvV/4dgvkay8wTnb5Kp/4dokSMTBaz9H5vUs+Q2BgEA
</rfc> </rfc>
 End of changes. 180 change blocks. 
1295 lines changed or deleted 528 lines changed or added

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