<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 3.1.1) --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-yang-cbor-20" number="9254" submissionType="IETF" category="std" consensus="true"submissionType="IETF"tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.12.3 --> <front><title>CBOR<title abbrev="CBOR Encoding of Data Modeled withYANG</title>YANG">Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) </title> <seriesInfoname="Internet-Draft" value="draft-ietf-core-yang-cbor-20"/>name="RFC" value="9254"/> <author initials="M." surname="Veillette" fullname="Michel Veillette" role="editor"> <organization>Trilliant Networks Inc.</organization> <address> <postal> <street>610 Rue du Luxembourg</street> <city>Granby</city> <region>Quebec</region> <code>J2J 2V2</code> <country>Canada</country> </postal> <email>michel.veillette@trilliantinc.com</email> </address> </author> <author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor"> <organization>Google Switzerland GmbH</organization> <address> <postal> <street>Brandschenkestrasse 110</street> <city>Zurich</city> <code>8002</code> <country>Switzerland</country> </postal> <email>ivaylopetrov@google.com</email> </address> </author> <author initials="A." surname="Pelov" fullname="Alexander Pelov"> <organization>Acklio</organization> <address> <postal> <street>1137A avenue des Champs Blancs</street><city>Cesson-Sevigne</city><city>Cesson-Sevigne Cedex</city> <code>35510</code> <country>France</country> </postal> <email>a@ackl.io</email> </address> </author> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization>Universität Bremen TZI</organization> <address> <postal> <street>Postfach 330440</street><city>D-28359 Bremen</city><city>Bremen</city> <code>D-28359</code> <country>Germany</country> </postal> <phone>+49-421-218-63921</phone> <email>cabo@tzi.org</email> </address> </author> <author initials="M." surname="Richardson" fullname="Michael Richardson"> <organization>Sandelman Software Works</organization> <address> <postal> <country>Canada</country> </postal> <email>mcr+ietf@sandelman.ca</email> </address> </author> <date year="2022"month="April" day="11"/> <area>Applications and Real-Time Area (art)</area> <workgroup>Internet Engineering Task Force</workgroup>month="July"/> <area>art</area> <workgroup>core</workgroup> <keyword>CBOR</keyword> <abstract><t>Based on the Concise Binary Object Representation (CBOR, RFC 8949), this document defines encoding rules for representing<t>YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, andnotifications, defined usingnotifications.</t> <t>This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC7950).</t>8949).</t> </abstract> </front> <middle> <section anchor="introduction"> <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 configuration 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="RFC7951"/> based onthe"The JavaScript Object Notation (JSON) Data InterchangeFormatFormat" <xref target="RFC8259"/>.</t> <t>The aim of this document is to define a set of encoding rules for the Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, collectively called<em>YANG-CBOR</em>."YANG-CBOR". The resulting encoding is more compact compared to XML and JSON and more suitable forConstrained Nodesconstrained nodes and/orConstrained Networksconstrained networks, as defined by <xref target="RFC7228"/>.</t> </section> <section anchor="terminology-and-notation"> <name>Terminology and Notation</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>SID values (and the SID deltas computed from them) shown in the examples are example values; these examples do not allocate the SIDs shown for specific items in the modules.</t> <t>The following terms are defined in <xref target="RFC7950"/>:</t> <ul spacing="normal"> <li>action</li> <li>anydata</li> <li>anyxml</li> <li>data node</li> <li>data tree</li> <li>datastore</li> <li>feature</li> <li>identity</li> <li>module</li> <li>notification</li> <li>RPC</li> <li>schema node</li> <li>submodule</li> </ul> <t>The following term is defined in <xref target="RFC8040"/>:</t> <ul spacing="normal"> <li>yang-data extension</li> </ul> <t>The following term is defined in <xref target="RFC8791"/>:</t> <ul spacing="normal"> <li>YANG data structure</li> </ul> <t>This specification also makes use of the following terminology:</t><ul<dl newline="true" spacing="normal"><li>YANG<dt>YANG Schema Item iDentifier(YANG SID(or "YANG SID" or simplySID):"SID"):</dt><dd> 63-bit unsigned integer used to identify different YANGitems.</li> <li>delta:items.</dd> <dt>delta:</dt><dd> Difference between the current YANG SID and a reference YANG SID. A reference YANG SID is defined for each context for which deltas areused.</li> <li>absolute SID:used.</dd> <dt>absolute SID:</dt><dd>A YANG SID that is not encoded as a delta. This is usually called out explicitly only in positions where normally a delta would befound.</li> <li>representation tree: afound.</dd> <dt>representation tree:</dt><dd> A YANG data tree, possibly enclosed by a representation of a schemanodenode, such as a YANG data structure, a notification, an RPC, or anaction.</li> <li>representation node: aaction.</dd> <dt>representation node:</dt><dd> A node in a representation tree, i.e., a data tree node, or a representation of a schemanodenode, such as a YANG data structure, a notification, an RPC, or anaction.</li> <li>item:action.</dd> <dt>item:</dt><dd> A schema node, an identity, a module, or a feature defined using the YANG modelinglanguage.</li> <li>list entry: thelanguage.</dd> <dt>list entry:</dt><dd> The data associated with a single entry of a list (see <xref section="7.8" sectionFormat="of"target="RFC7950"/>).</li> <li>parenttarget="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-anydata"/>).</dd> <dt>parent (of a representationnode): thenode):</dt><dd> The schema node of the closest enclosing representation node in which a given representation node isdefined.</li> </ul>defined.</dd> </dl> </section> <section anchor="properties-of-cbor-encoding"> <name>Properties of the CBOR Encoding</name> <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 schemanodenode, such as a YANG data structure, a notification, an RPC, or an action; this is called a representation tree. The data tree nodes and the enclosing schema node representation, if any, are collectively called the representation nodes.</t> <t>A representationnodenode, such as a container, list entry, YANG data structure, notification, RPC input, RPC output, action input,oractionoutputoutput, or anydata node, is serialized using a CBOR map in which each schema node defined within is encoded using a key and a value. This specification supports two types of CBORkeys;keys: YANG Schema Item iDentifier (YANGSID)SID), as defined in <xreftarget="sid"/>target="sid"/>, andnamesnames, as defined in <xref target="name"/>. Each of these key types is encoded using a specific CBOR typewhichthat allows their interpretation during the deserialization process. Protocols or mechanisms implementing this specification can mandate the use of a specific key type or allow the generator to choose freely per key.</t> <t>In order to minimize the size of the encoded data, the mapping avoids any unnecessary meta-information beyond that directly 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 an absolute SID, anyxml data nodes, or the uniondatatype,datatype todistinguishexplicitly distinguish the use of different YANG datatypes encoded using the same CBOR major type.</t> <t>Unless specified otherwise by the protocol or mechanism implementing this specification, the indefinite lengthencodingencoding, as defined in <xref section="3.2" sectionFormat="of"target="RFC8949"/>target="RFC8949"/>, <bcp14>SHALL</bcp14> be supported by the CBOR decoders employed with YANG-CBOR. (This enables an implementation to begin emitting an array or map before the number of entries in that structure is known, possibly also avoiding excessive locking or race conditions. On the other hand, it deprives the receiver of the encoded data from advance announcement about some size information, so a generator should choose indefinite length encoding only when these benefits do accrue.)</t> <t>Data nodes implemented using a CBOR array, map, byte string, or text string 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 this specification as part of an application payload, the payload <bcp14>SHOULD</bcp14> include information that would allow each node to be identified in a statelessway to identify each node, such asway, for instance, the SID number associated with the node, the SID delta from another SID in the application payload, thenamespace qualifiednamespace-qualified name, or the instance-identifier.</t> <t>Examples in <xref target="instance-encoding"/> include a root CBOR map with a single entry having a key set to either anamespace qualifiednamespace-qualified name or a SID. This root CBOR map is provided only as a typical usage example and is not part of the present encoding rules. Only the value within this CBOR map is compulsory.</t> <section anchor="cbor-diagnostic-notation"> <name>CBORdiagnostic notation</name>Diagnostic Notation</name> <t>Within this document, CBOR binary contents are represented using an equivalent textual form called CBOR diagnosticnotationnotation, as defined in <xref section="8" sectionFormat="of" target="RFC8949"/>. This notation is used strictly for documentation purposes and is never used in the data serialization. <xref target="diagnostic-notation-summary"/> below provides a summary of this notation.</t> <table anchor="diagnostic-notation-summary"> <name>CBORdiagnostic notation summary</name>Diagnostic Notation Summary</name> <thead> <tr> <th align="left">CBORcontent</th>Content</th> <th align="left">CBORtype</th>Type</th> <th align="left">Diagnosticnotation</th>Notation</th> <th align="left">Example</th> <th align="left">CBORencoding</th>Encoding</th> </tr> </thead> <tbody> <tr> <td align="left">Unsigned integer</td> <td align="left">0</td> <td align="left">Decimal digits</td> <td align="left">123</td> <td align="left">18 7B</td> </tr> <tr> <td align="left">Negative integer</td> <td align="left">1</td> <td align="left">Decimal digits prefixed by a minus sign</td> <td align="left">-123</td> <td align="left">38 7A</td> </tr> <tr> <td align="left">Byte string</td> <td align="left">2</td> <td align="left">Hexadecimal value enclosed between single quotes and prefixed by an 'h'</td> <td align="left">h'F15C'</td> <td align="left">42 F15C</td> </tr> <tr> <td align="left">Text string</td> <td align="left">3</td> <td align="left">String of Unicode characters enclosed between double quotes</td> <td align="left">"txt"</td> <td align="left">63 747874</td> </tr> <tr> <td align="left">Array</td> <td align="left">4</td> <td align="left">Comma-separated list of values within square brackets</td> <td align="left">[ 1, 2 ]</td> <td align="left">82 01 02</td> </tr> <tr> <td align="left">Map</td> <td align="left">5</td> <td align="left">Comma-separated list of key : value pairs within curly braces</td> <td align="left">{ 1: 123, 2: 456 }</td> <td align="left">A2 01187B 021901C8</td> </tr> <tr> <td align="left">Boolean</td> <td align="left">7/20</td> <td align="left">false</td> <td align="left">false</td> <td align="left">F4</td> </tr> <tr> <td align="left"> </td> <td align="left">7/21</td> <td align="left">true</td> <td align="left">true</td> <td align="left">F5</td> </tr> <tr> <td align="left">Null</td> <td align="left">7/22</td> <td align="left">null</td> <td align="left">null</td> <td align="left">F6</td> </tr> <tr> <td align="left">Not assigned</td> <td align="left">7/23</td> <td align="left">undefined</td> <td align="left">undefined</td> <td align="left">F7</td> </tr> </tbody> </table> <t>Note: CBOR binary contents shown in this specification are annotated with comments. These comments are delimited by slashes("/")("/"), as defined in <xreftarget="RFC8610"/> Appendix G.6.</t>target="RFC8610" sectionFormat="of" section="G.6"/>.</t> </section> <section anchor="sid"> <name>YANG Schema Item iDentifier</name> <t>Some of the items defined in YANG <xref target="RFC7950"/> require the use of a unique identifier. In both the Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>, these identifiers are implemented using text strings. To allow the implementation of data models defined in YANG in constrained devices and constrained networks, a more compact method to identify YANG items is required. This compact identifier, calledYANG"YANG Schema ItemiDentifier,iDentifier", is an unsigned integer limited to 63 bits of range (i.e., 0..9223372036854775807 or 0..0x7fffffffffffffff). The following items are identified using YANG SIDs (often shortened to SIDs):</t> <ul spacing="normal"> <li>identities</li> <li>data nodes</li> <li>RPCs and associated input(s) and output(s)</li> <li>actions and associated input(s) and output(s)</li> <li>YANG data structures</li> <li>notifications and associated information</li> <li>YANG modules and features</li> </ul><t>Note<aside><t>Note that any structuring of modules into submodules is transparent to YANG-CBOR: SIDs are not allocated for the names of submodules, and any items within a submodule are effectively allocated SIDs as part of processing the module that includesthem.</t>them.</t></aside> <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 added to the reference SID applying to the map. The reference SID of an outermost map is zero, unless a different reference SID is unambiguously conferred from the environment in which the outermost map is used. The reference SID of a map that is most directly embedded in a map entry with a name-based key is zero. For all other maps, the reference SID is the SID computed for the map entry it is most directly embedded in. (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 integer implies a delta), they need to be identified as absolute SID values by using 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 process solely based on the data serialized or deserialized combined with, potentially, an outermost reference SID unambiguously conferred by the environment.</t> <t>Mechanisms and processes used to assign SIDs to YANG items and to guarantee 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. A related document, i.e., <xref target="I-D.ietf-core-sid"/>, is intended to serve as the definitive way to assign SID values for YANG modules managed by theIETF,IETF and recommends itself for YANG modules managed by non-IETF entities, as well. The present specification has been designed to allow different methods of assignment to be used within separate domains.</t> <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 allocated; it is not used in interchange.</t> </section> <section anchor="name"> <name>Name</name> <t>This specification also supports the encoding of YANG item identifiers as text strings, similar to those used by the JSONEncodingencoding ofData Modeleddata modeled with YANG <xref target="RFC7951"/>. This approach can be used to avoid the management overhead associated with SID allocation. The main drawback is the significant 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> <ul spacing="normal"> <li>simple -- the identifier of the YANG item (i.e., schema node or identity).</li><li>namespace qualified<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 colon character (":").</li> </ul> <t>The name of a module determines the namespace of all YANG items defined in that module. If an item is defined in a submodule, then thenamespace qualifiednamespace-qualified 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 target="namesyntax"/>, where the production for "identifier" is defined in <xref section="14" sectionFormat="of" target="RFC7950"/>.</t> <figure anchor="namesyntax"> <name>ABNF Production for asimpleSimple ornamespace qualified name</name> <artwork type="abnf" align="center"><![CDATA[Namespace-Qualified Name</name> <sourcecode type="abnf"><![CDATA[ name = [identifier ":"] identifier]]></artwork>]]></sourcecode> </figure> <t>Anamespace qualifiednamespace-qualified name <bcp14>MUST</bcp14> be used for all members of a top-level CBOR map and then also whenever the namespaces of the representation node and its parent node are different. In all other cases, the simple form of the name <bcp14>MUST</bcp14> be used.</t> <t>Definition example:</t> <sourcecode type="yang"><![CDATA[ module example-foomod { container top { leaf foo { type uint8; } } } module example-barmod { import example-foomod { prefix "foomod"; } augment "/foomod:top" { leaf bar { type boolean; } } } ]]></sourcecode> <t>A valid CBOR encoding of the 'top' container is as follows.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "example-foomod:top": { "foo": 54, "example-barmod:bar": true } } ]]></sourcecode> <t>Both the 'top' container and the 'bar' leaf defined in a different YANG module as its parent container are encoded asnamespace qualifiednamespace-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 anchor="instance-encoding"> <name>Encoding of Representation Nodes</name> <t>Representation nodes defined using the YANG modeling language are encoded using CBOR <xreftarget="RFC8949"/>target="RFC8949"/>, based on the rules defined in this section. We assume that the reader is already familiar with both YANG <xref target="RFC7950"/> and CBOR <xref target="RFC8949"/>.</t> <section anchor="the-leaf"> <name>The 'leaf'</name> <t>A 'leaf' <bcp14>MUST</bcp14> be encoded accordingly to its datatype using 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>Definition example adapted from <xref target="RFC6991"/> and <xref target="RFC7317"/>:</t> <sourcecode type="yang"><{0,61})?[a-zA-Z0-9]\.)*' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '|\.'; length "1..253"; } } leaf hostname { type inet:domain-name; } ]]></sourcecode> <section anchor="using-sids-in-keys"> <name>Using SIDs inkeys</name>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>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 1752 : "myhost.example.com" / hostname (SID 1752) / } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 06D8 # unsigned(1752) 72 # text(18) 6D79686F73742E6578616D706C652E636F6D # "myhost.example.com" ]]></sourcecode> </section> <section anchor="using-names-in-keys"> <name>UsingnamesNames inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "ietf-system:hostname" : "myhost.example.com" } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 74 # text(20) 696574662D73797374656D3A686F73746E616D65 72 # text(18) 6D79686F73742E6578616D706C652E636F6D ]]></sourcecode> </section> </section> <section anchor="container"> <name>The 'container' andother nodesOther Nodes from thedata tree</name>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). The same encoding is also used for the list entries in a list (<xreftarget="list"/>). Atarget="list"/>) and for anydata nodes (<xref target="the-anydata"/>). Collectively, we speak of these instances as "container-like instances".</t> <t>A map consists of pairs of data items, with each pair consisting of a key and a value. Each key within the CBOR map is set to a schema node identifier, and each value is set to the value of this representation node according to the instance datatype.</t> <t>This specification supports two types of CBOR mapkeys; SIDkeys: SID, as defined in <xreftarget="sid"/>target="sid"/>, andnamesnames, as defined in <xref target="name"/>.</t> <t>The following examples show the encoding of a 'system-state' container representation instance using SIDs or names.</t> <t>Definition example adapted from <xref target="RFC6991"/> and <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\+\-]\d{2}:\d{2})'; } } container system-state { container clock { leaf current-datetime { type date-and-time; } leaf boot-datetime { type date-and-time; } } } ]]></sourcecode> <section anchor="container-with-sid"> <name>Using SIDs inkeys</name>Keys</name> <t>In the context of containers and other nodes from the data tree, CBOR map keys within inner CBOR maps can be encoded using deltas (bare integers) or absolute SIDs (tagged with tag number 47).</t> <t>Delta values are computed as follows:</t> <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 'list', deltas are equal to the SID of the current 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 '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> </ul> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 1720 : { / system-state (SID 1720) / 1 : { / clock (SID 1721) / 2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/ 1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) / } } } ]]></sourcecode> <t>CBOR encoding:</t> <figure anchor="Fig-system-clock"> <name>Systemstate clock encoding</name>State Clock Encoding</name> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 06B8 # unsigned(1720) A1 # map(1) 01 # unsigned(1) A2 # map(2) 02 # unsigned(2) 78 1A # text(26) 323031352D31302D30325431343A34373A32345A2D30353A3030 01 # unsigned(1) 78 1A # text(26) 323031352D30392D31355430393A31323A35385A2D30353A3030 ]]></sourcecode> </figure> </section> <section anchor="container-with-name"> <name>UsingnamesNames inkeys</name>Keys</name> <t>CBOR map keys implemented using names <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3). A namespace-qualified name <bcp14>MUST</bcp14> 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 used. Names and namespaces are defined in <xref section="4" sectionFormat="of" target="RFC7951"/>.</t> <t>The following example shows the encoding of a 'system' container representation node instance using names.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "ietf-system:system-state" : { "clock" : { "current-datetime" : "2015-10-02T14:47:24Z-05:00", "boot-datetime" : "2015-09-15T09:12:58Z-05:00" } } } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 78 18 # text(24) 696574662D73797374656D3A73797374656D2D7374617465 A1 # map(1) 65 # text(5) 636C6F636B # "clock" A2 # map(2) 70 # text(16) 63757272656E742D6461746574696D65 78 1A # text(26) 323031352D31302D30325431343A34373A32345A2D30353A3030 6D # text(13) 626F6F742D6461746574696D65 78 1A # text(26) 323031352D30392D31355430393A31323A35385A2D30353A3030 ]]></sourcecode> </section> </section> <section anchor="leaf-list"> <name>The 'leaf-list'</name> <t>A leaf-list <bcp14>MUST</bcp14> be encoded using a CBOR array data item (major type 4). Each entry of this array <bcp14>MUST</bcp14> be encoded accordingly 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 representation node instance containing twoentries,entries: "ietf.org" and "ieee.org".</t> <t>Definition example adapted from <xref target="RFC6991"/> and <xref target="RFC7317"/>:</t> <sourcecode type="yang"><{0,61})?[a-zA-Z0-9]\.)*' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '|\.'; length "1..253"; } } leaf-list search { type domain-name; ordered-by user; } ]]></sourcecode> <section anchor="using-sids-in-keys-1"> <name>Using SIDs inkeys</name> <t>CBORKeys</name> <t keepWithNext="true">CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 1746 : [ "ietf.org", "ieee.org" ] / search (SID 1746) / } ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 06D2 # unsigned(1746) 82 # array(2) 68 # text(8) 696574662E6F7267 # "ietf.org" 68 # text(8) 696565652E6F7267 # "ieee.org" ]]></sourcecode> </section> <section anchor="using-names-in-keys-1"> <name>UsingnamesNames inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "ietf-system:search" : [ "ietf.org", "ieee.org" ] } ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 72 # text(18) 696574662D73797374656D3A736561726368 # "ietf-system:search" 82 # array(2) 68 # text(8) 696574662E6F7267 # "ietf.org" 68 # text(8) 696565652E6F7267 # "ieee.org" ]]></sourcecode> </section> </section> <section anchor="list"> <name>The 'list' and the 'list'entries</name>Entries</name> <t>A list or a subset of a list <bcp14>MUST</bcp14> be encoded using a CBOR array data item (major type 4). Each list entry within this CBOR array is encoded using a CBOR map data item (major type 5) based on the encoding rules of acollectioncontainer-like instance, as defined in <xref target="container"/>.</t> <t>It is important to note that this encoding rule also applies to a 'list' representation node instance that has a single entry.</t> <t>The following examples show the encoding of a 'server' list using SIDs or names.</t> <t>Definition examplesimplifiedadapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ list server { key name; leaf name { type string; } choice transport { case udp { container udp { leaf address { type host; mandatory true; } leaf port { type port-number; } } } } leaf association-type { type enumeration { enum server; enum peer; enum pool; } default server; } leaf iburst { type boolean; default false; } leaf prefer { type boolean; default false; } } ]]></sourcecode> <section anchor="list-with-sid"> <name>Using SIDs inkeys</name>Keys</name> <t>The encoding rules of each 'list' entry are defined in <xref target="container-with-sid"/>.</t><t>CBOR<t keepWithNext="true">CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 1756 : [ / server (SID 1756) / { 3 : "NRC TIC server", / name (SID 1759) / 5 : { / udp (SID 1761) / 1 : "tic.nrc.ca", / address (SID 1762) / 2 : 123 / port (SID 1763) / }, 1 : 0, / association-type (SID 1757) / 2 : false, / iburst (SID 1758) / 4 : true / prefer (SID 1760) / }, { 3 : "NRC TAC server", / name (SID 1759) / 5 : { / udp (SID 1761) / 1 : "tac.nrc.ca" / address (SID 1762) / } } ] } ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 06DC # unsigned(1756) 82 # array(2) A5 # map(5) 03 # unsigned(3) 6E # text(14) 4E52432054494320736572766572 # "NRC TIC server" 05 # unsigned(5) A2 # map(2) 01 # unsigned(1) 6A # text(10) 7469632E6E72632E6361 # "tic.nrc.ca" 02 # unsigned(2) 18 7B # unsigned(123) 01 # unsigned(1) 00 # unsigned(0) 02 # unsigned(2) F4 # primitive(20) 04 # unsigned(4) F5 # primitive(21) A2 # map(2) 03 # unsigned(3) 6E # text(14) 4E52432054414320736572766572 # "NRC TAC server" 05 # unsigned(5) A1 # map(1) 01 # unsigned(1) 6A # text(10) 7461632E6E72632E6361 # "tac.nrc.ca" ]]></sourcecode> </section> <section anchor="using-names-in-keys-2"> <name>UsingnamesNames inkeys</name>Keys</name> <t>The encoding rules of each 'list' entry are defined in <xref target="container-with-name"/>.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "ietf-system:server" : [ { "name" : "NRC TIC server", "udp" : { "address" : "tic.nrc.ca", "port" : 123 }, "association-type" : 0, "iburst" : false, "prefer" : true }, { "name" : "NRC TAC server", "udp" : { "address" : "tac.nrc.ca" } } ] } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 72 # text(18) 696574662D73797374656D3A736572766572 82 # array(2) A5 # map(5) 64 # text(4) 6E616D65 # "name" 6E # text(14) 4E52432054494320736572766572 63 # text(3) 756470 # "udp" A2 # map(2) 67 # text(7) 61646472657373 # "address" 6A # text(10) 7469632E6E72632E6361 # "tic.nrc.ca" 64 # text(4) 706F7274 # "port" 18 7B # unsigned(123) 70 # text(16) 6173736F63696174696F6E2D74797065 00 # unsigned(0) 66 # text(6) 696275727374 # "iburst" F4 # primitive(20) 66 # text(6) 707265666572 # "prefer" F5 # primitive(21) A2 # map(2) 64 # text(4) 6E616D65 # "name" 6E # text(14) 4E52432054414320736572766572 63 # text(3) 756470 # "udp" A1 # map(1) 67 # text(7) 61646472657373 # "address" 6A # text(10) 7461632E6E72632E6361 # "tac.nrc.ca" ]]></sourcecode> </section> </section> <section anchor="the-anydata"> <name>The 'anydata'</name> <t>An anydata node serves as a container for an arbitrary set of representation nodes that otherwise appear as normal YANG-modeled data. An anydata representation node instance is encoded using the same rules as a container, i.e.,CBOR map. The requirement that anydata content can be modeled by YANG implies the following:</t> <ul spacing="normal"> <li>CBOR map keys of any inner representation nodes <bcp14>MUST</bcp14> be set to valid deltas or names.</li> <li>CBOR arrays <bcp14>MUST</bcp14> contain either unique scalar values (as a leaf-list, see <xref target="leaf-list"/>), or maps (asusing alist, see <xref target="list"/>).</li> <li>CBORCBOR mapvalues <bcp14>MUST</bcp14> followdata item (major type 5) based on the encoding rules ofone of the datatypes listeda container-like instance, as defined in <xreftarget="instance-encoding"/>.</li> </ul>target="container"/>.</t> <t>The following example shows a possible use of ananydata.anydata node. In this example, an anydata node is used to define a representation node containing a notification event; this representation node can be part of a YANG list to create an event logger.</t> <t>Definition example:</t> <sourcecode type="yang"><![CDATA[ module event-log { ... anydata last-event;#// SID 60123 } ]]></sourcecode> <t>This example also assumes the assistance of the following notification.</t> <sourcecode type="yang"><![CDATA[ module example-port { ... notification example-port-fault {#// SID 60200 leaf port-name {#// SID 60201 type string; } leaf port-fault {#// SID 60202 type string; } } } ]]></sourcecode> <section anchor="using-sids-in-keys-2"> <name>Using SIDs inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 60123 : { / last-event (SID 60123) / 77 : { / example-port-fault (SID 60200) / 1 : "0/4/21", / port-name (SID 60201) / 2 : "Open pin 2" / port-fault (SID 60202) / } } } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 EADB # unsigned(60123) A1 # map(1) 18 4D # unsigned(77) A2 # map(2) 01 # unsigned(1) 66 # text(6) 302F342F3231 # "0/4/21" 02 # unsigned(2) 6A # text(10) 4F70656E2070696E2032 # "Open pin 2" ]]></sourcecode> <t>In some implementations, it might be simpler to use the absolute SID encoding (tag number 47) for the anydata root element. CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 60123 : { / last-event (SID 60123) / 47(60200) : { / event-port-fault (SID 60200) / 1 : "0/4/21", / port-name (SID 60201) / 2 : "Open pin 2" / port-fault (SID 60202) / } } } ]]></sourcecode> </section> <section anchor="using-names-in-keys-3"> <name>UsingnamesNames inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "event-log:last-event" : { "example-port:example-port-fault" : { "port-name" : "0/4/21", "port-fault" : "Open pin 2" } } } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 74 # text(20) 6576656E742D6C6F673A6C6173742D6576656E74 A1 # map(1) 78 1F # text(31) 6578616D706C652D706F72743A 6578616D706C652D706F72742D6661756C74 A2 # map(2) 69 # text(9) 706F72742D6E616D65 # "port-name" 66 # text(6) 302F342F3231 # "0/4/21" 6A # text(10) 706F72742D6661756C74 # "port-fault" 6A # text(10) 4F70656E2070696E2032 # "Open pin 2" ]]></sourcecode> </section> </section> <section anchor="the-anyxml"> <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. (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 the 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 validCBOR encodedCBOR-encoded anyxml representation node instance consisting of a CBOR array containing the CBOR simple values 'true','null''null', and 'true'.</t> <t>Definition example adapted from <xref target="RFC7951"/>:</t> <sourcecode type="yang"><![CDATA[ module bar-module { ... anyxml bar;#// SID 60000 } ]]></sourcecode> <section anchor="using-sids-in-keys-3"> <name>Using SIDs inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 60000 : [true, null, true] / bar (SID 60000) / } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 EA60 # unsigned(60000) 83 # array(3) F5 # primitive(21) F6 # primitive(22) F5 # primitive(21) ]]></sourcecode> </section> <section anchor="using-names-in-keys-4"> <name>UsingnamesNames inkeys</name>Keys</name> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "bar-module:bar" : [true, null, true] / bar (SID 60000) / } ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 6E # text(14) 6261722D6D6F64756C653A626172 # "bar-module:bar" 83 # array(3) F5 # primitive(21) F6 # primitive(22) F5 # primitive(21) ]]></sourcecode> </section> </section> </section> <section anchor="encoding-of-yang-data-extension"> <name>Encoding of the 'yang-data'extension</name>Extension</name> <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> <t>The yang-data extension will specify a container that <bcp14>MUST</bcp14> be encoded using the encoding rules of nodes of datatreestrees, as defined in <xref target="container"/>.</t> <t>Just like YANG containers, the yang-data extension can be encoded using either SIDs or names.</t> <t>Definition example adapted from <xreftarget="I-D.ietf-core-comi"/> Appendix A:</t>target="I-D.ietf-core-comi" sectionFormat="of" section="A"/>:</t> <sourcecode type="yang"><![CDATA[ module ietf-coreconf { ... import ietf-restconf { prefix rc; } rc:yang-data yang-errors { container error { leaf error-tag { type identityref { base error-tag; } } leaf error-app-tag { type identityref { base error-app-tag; } } leaf error-data-node { type instance-identifier; } leaf error-message { type string; } } } } ]]></sourcecode> <section anchor="using-sids-in-keys-4"> <name>Using SIDs inkeys</name>Keys</name> <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 to the yang-data extension container; the value is set to the CBOR encoding of thiscontainercontainer, as defined in <xref target="container"/>.</t> <t>This example shows a serialization example of the yang-errors yang-dataextensionextension, as defined in <xreftarget="I-D.ietf-core-comi"/>target="I-D.ietf-core-comi"/>, usingSIDsSIDs, as defined in <xref target="sid"/>.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { 1024 : { / error (SID 1024) / 4 : 1011, / error-tag (SID 1028) / / = invalid-value (SID 1011) / 1 : 1018, / error-app-tag (SID 1025) / / = not-in-range (SID 1018) / 2 : 1740, / error-data-node (SID 1026) / / = timezone-utc-offset (SID 1740) / 3 : "Maximum exceeded" / error-message (SID 1027) / } } ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 19 0400 # unsigned(1024) A4 # map(4) 04 # unsigned(4) 19 03F3 # unsigned(1011) 01 # unsigned(1) 19 03FA # unsigned(1018) 02 # unsigned(2) 19 06CC # unsigned(1740) 03 # unsigned(3) 70 # text(16) 4D6178696D756D206578636565646564 # "Maximum exceeded" ]]></sourcecode> </section> <section anchor="using-names-in-keys-5"> <name>UsingnamesNames inkeys</name>Keys</name> <t>The yang-data extensions encoded using names are carried in a CBOR map containing a single item pair. The key of this item is set to thenamespace qualifiednamespace-qualified name of the yang-data extension container; the value is set to the CBOR encoding of thiscontainercontainer, as defined in <xref target="container"/>.</t> <t>This example shows a serialization example of the yang-errors yang-dataextensionextension, as defined in <xreftarget="I-D.ietf-core-comi"/>target="I-D.ietf-core-comi"/>, usingnamesnames, as defined <xref target="name"/>.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ { "ietf-coreconf:error" : { "error-tag" : "invalid-value", "error-app-tag" : "not-in-range", "error-data-node" : "timezone-utc-offset", "error-message" : "Maximum exceeded" } } ]]></sourcecode><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ A1 # map(1) 73 # text(19) 696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error" A4 # map(4) 69 # text(9) 6572726F722D746167 # "error-tag" 6D # text(13) 696E76616C69642D76616C7565 # "invalid-value" 6D # text(13) 6572726F722D6170702D746167 # "error-app-tag" 6C # text(12) 6E6F742D696E2D72616E6765 # "not-in-range" 6F # text(15) 6572726F722D646174612D6E6F6465 # "error-data-node" 73 # text(19) 74696D657A6F6E652D7574632D6F6666736574 # "timezone-utc-offset" 6D # text(13) 6572726F722D6D657373616765 # "error-message" 70 # text(16) 4D6178696D756D206578636565646564 # "Maximum exceeded" ]]></sourcecode> </section> </section> <section anchor="data-types-mapping"> <name>Representing YANG Data Types in CBOR</name> <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 followingsub-sectionsubsection defines the CBOR encoding of each built-in type supported byYANGYANG, as listed in <xref section="4.2.4" sectionFormat="of" target="RFC7950"/>. Each subsection shows an example value assigned to a representation node instance of the discussed built-in type.</t> <section anchor="the-unsigned-integer-types"> <name>Theunsigned integerUnsigned Integer Types</name> <t>Leafs of type uint8, uint16,uint32uint32, and uint64 <bcp14>MUST</bcp14> be encoded using a CBOR unsigned integer data item (major type 0).</t> <t>The following example shows the encoding of an 'mtu' leaf representation node instance set to 1280 bytes.</t> <t>Definition example adapted from <xref target="RFC8344"/>:</t> <sourcecode type="yang"><![CDATA[ leaf mtu { type uint16 { range "68..max"; } } ]]></sourcecode> <t>CBOR diagnostic notation: 1280</t> <t>CBOR encoding: 19 0500</t> </section> <section anchor="the-integer-types"> <name>TheintegerInteger Types</name> <t>Leafs of type int8, int16,int32int32, and int64 <bcp14>MUST</bcp14> be encoded using either a CBOR unsigned integer (major type 0) or a CBOR negative integer (major type 1), depending on the actual value.</t> <t>The following example shows the encoding of a 'timezone-utc-offset' leaf representation node instance set to -300 minutes.</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ leaf timezone-utc-offset { type int16 { range "-1500 .. 1500"; } } ]]></sourcecode> <t>CBOR diagnostic notation: -300</t> <t>CBOR encoding: 39 012B</t> </section> <section anchor="the-decimal64-type"> <name>The 'decimal64' Type</name> <t>Leafs of type decimal64 <bcp14>MUST</bcp14> be encoded using a decimalfractionfraction, as defined in <xref section="3.4.4" sectionFormat="of" target="RFC8949"/>.</t> <t>The following example shows the encoding of a 'my-decimal' leaf representation node instance set to 2.57.</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ leaf my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } ]]></sourcecode> <t>CBOR diagnostic notation: 4([-2, 257])</t> <t>CBOR encoding: C4 82 21 19 0101</t> </section> <section anchor="the-string-type"> <name>The 'string' Type</name> <t>Leafs of type string <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3).</t> <t>The following example shows the encoding of a 'name' leaf representation node instance set to "eth0".</t> <t>Definition example adapted from <xref target="RFC8343"/>:</t> <sourcecode type="yang"><![CDATA[ leaf name { type string; } ]]></sourcecode> <t>CBOR diagnostic notation: "eth0"</t> <t>CBOR encoding: 64 65746830</t> </section> <section anchor="the-boolean-type"> <name>The 'boolean' Type</name> <t>Leafs of type boolean <bcp14>MUST</bcp14> be encoded using a CBOR simple value 'true' (major type 7, additional information 21) or 'false' (major type 7, additional information 20).</t> <t>The following example shows the encoding of an 'enabled' leaf representation node instance set to 'true'.</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ leaf enabled { type boolean; } ]]></sourcecode> <t>CBOR diagnostic notation: true</t> <t>CBOR encoding: F5</t> </section> <section anchor="enumeration"> <name>The 'enumeration' Type</name> <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), depending on the actual value, or exceptionally as a tagged text string (see below). Enumeration values are either 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> <t>The following example shows the encoding of an 'oper-status' leaf representation node instance set to 'testing'.</t><t>Definition<t keepWithNext="true">Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ leaf oper-status { type enumeration { enum up { value 1; } enum down { value 2; } enum testing { value 3; } enum unknown { value 4; } enum dormant { value 5; } enum not-present { value 6; } enum lower-layer-down { value 7; } } } ]]></sourcecode> <t>CBOR diagnostic notation: 3</t> <t>CBOR encoding: 03</t> <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 assigned by 'enum' statements in YANG (see also <xref target="union"/>). The encoding <bcp14>MUST</bcp14> be enclosed by the enumeration CBORtagtag, as specified in <xref target="tag-registry"/>.</t> <t>Definition example adapted from <xref target="RFC7950"/>:</t> <sourcecode type="yang"><![CDATA[ type union { type int32; type enumeration { enum unbounded; } } ]]></sourcecode> <t>CBOR diagnostic notation: 44("unbounded")</t> <t>CBOR encoding: D8 2C 69 756E626F756E646564</t> </section> <section anchor="bits"> <name>The 'bits' Type</name> <t>Keeping in mind that bit positions are either explicitly assigned using the YANG statement 'position' or automatically assigned based on the algorithm defined in <xref section="9.7.4.2" sectionFormat="of" target="RFC7950"/>, each element of type bits could be seen as a set of bit positions (or offsets from position0),0) that have a value of either 1, which represents the bit beingsetset, or 0, which represents that the bit is not set.</t> <t>Leafs of type bits <bcp14>MUST</bcp14> be encoded either using a CBOR array (major type 4) or byte string (major type2),2) or exceptionally as a tagged text string (see below). In case CBOR array representation is used, each element is either (1) a positive integer (major type 0 with value 0 being disallowed) that can be used to calculate the offset of the next bytestring,string or (2) a byte string (major type 2) that carries the information regarding whether certain bits are set or not. The initial offset value is00, and each unsigned integer modifies the 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 byte of the byte string that follows will represent bit positions 40 to4747, with both ends included. If the byte string has a second byte, it will carry information about bits 48 to5555, 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 of bytes in the byte string multiplied by 8. Bytes with no bits set (zero bytes) at the end of the byte string are nevergenerated:generated. If theywouldoccur 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 zero bytes are removed and the integer is adjusted upwards by the number of zero bytes that were removed. An example follows.</t> <t>The following example shows the encoding of an 'alarm-state' leaf representation node instance with the 'critical' (position 2), 'warning' (position8)8), and 'indeterminate' (position 128) flags set.</t> <sourcecode type="yang"><![CDATA[ typedef alarm-state { type bits { bit unknown; bit under-repair; bit critical; bit major; bit minor; bit warning { position 8; } bit indeterminate { position 128; } } } leaf alarm-state { type alarm-state; } ]]></sourcecode> <t>CBOR diagnostic notation: [h'0401', 14, h'01']</t> <t>CBOR encoding: 83 42 0401 0E 41 01</t> <t>In a number ofcasescases, 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. To illustrate this, let us consider the same example YANGdefinition,definition but this time encoding only 'under-repair' and 'critical' flags. The result would be</t> <t>CBOR diagnostic notation: h'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 a zerobyte,byte or positive unsigned integers, where byte strings and integers <bcp14>MUST</bcp14> alternate, i.e., adjacent byte 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 positive integer is an error. Note that a recipient can handle trailing zero bytes in the byte strings using the normal 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 CBOR text string data item (major type 3) and <bcp14>MUST</bcp14> contain a space-separated sequence of names of 'bits' that are set (see also <xref target="union"/>). The encoding <bcp14>MUST</bcp14> be enclosed by the bits CBORtagtag, as specified in <xref target="tag-registry"/>.</t> <t>The following example shows the encoding of an 'alarm-state' leaf representation node instance defined using a union type with the 'under-repair' and 'critical' flags set.</t> <t>Definition example:</t> <sourcecode type="yang"><![CDATA[ leaf alarm-state-2 { type union { type alarm-state; type bits { bit extra-flag; } } } ]]></sourcecode> <t>CBOR diagnostic notation: 43("under-repair critical")</t> <t>CBOR encoding: D8 2B 75 756E6465722D72657061697220637269746963616C</t> </section> <section anchor="the-binary-type"> <name>The 'binary' Type</name> <t>Leafs of type binary <bcp14>MUST</bcp14> be encoded using a CBOR byte string data item (major type 2).</t> <t>The following example shows the encoding of an 'aes128-key' leaf representation node instance set to 0x1f1ce6a3f42660d888d92a4d8030476e.</t> <t>Definition example:</t> <sourcecode type="yang"><![CDATA[ leaf aes128-key { type binary { length 16; } } ]]></sourcecode> <t>CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E'</t> <t>CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E</t> </section> <section anchor="the-leafref-type"> <name>The 'leafref' Type</name> <t>Leafs of type leafref <bcp14>MUST</bcp14> be encoded using the rules of the representation node referenced 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>Definition example adapted from <xref target="RFC8343"/>:</t> <sourcecode type="yang"><![CDATA[ typedef interface-state-ref { type leafref { path "/interfaces-state/interface/name"; } } container interfaces-state { list interface { key "name"; leaf name { type string; } leaf-list higher-layer-if { type interface-state-ref; } } } ]]></sourcecode> <t>CBOR diagnostic notation: "eth1"</t> <t>CBOR encoding: 64 65746831</t> </section> <section anchor="identityref"> <name>The 'identityref' Type</name> <t>This specification supports two approaches for encoding identityref: as a YANG Schema ItemiDentifieriDentifier, as defined in <xref target="sid"/>, or as anamename, as defined in <xref section="6.8" sectionFormat="of" target="RFC7951"/>. See <xref target="union"/> for an exceptional case when this representation needs to be tagged.</t> <section anchor="identityref-with-sid"> <name>SIDs asidentityref</name>'identityref'</name> <t>When representation nodes of type identityref are implemented using SIDs, they <bcp14>MUST</bcp14> be encoded using a CBOR unsigned integer data item (major type 0). (Note that, as they are not used in the position of CBOR map keys, no delta mechanism is employed for SIDs used for identityref.)</t> <t>The following example shows the encoding of a 'type' leaf representation node instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880).</t> <t>Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ identity interface-type { } identity iana-interface-type { base interface-type; } identity ethernetCsmacd { base iana-interface-type; } leaf type { type identityref { base interface-type; } } ]]></sourcecode> <t>CBOR diagnostic notation: 1880</t> <t>CBOR encoding: 19 0758</t> </section> <section anchor="name-as-identityref"> <name>Name asidentityref</name>'identityref'</name> <t>Alternatively, an identityref <bcp14>MAY</bcp14> be encoded using anamename, as defined in <xref target="name"/>. When names are used, identityref <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3). If the identity is defined in a different module than the leaf node containing the identityref data node, thenamespace qualifiednamespace-qualified form <bcp14>MUST</bcp14> be used. Otherwise, both the simple andnamespace qualifiednamespace-qualified forms are permitted. Names and namespaces are defined in <xref target="name"/>.</t> <t>The following example shows the encoding of the identity 'iana-if-type:ethernetCsmacd' using itsnamespace qualifiednamespace-qualified name. This example is described in <xref target="identityref-with-sid"/>.</t> <t>CBOR diagnostic notation: "iana-if-type:ethernetCsmacd"</t> <t>CBOR encoding: 781b1B 69616E612D69662D747970653A65746865726E657443736D616364</t> </section> </section> <section anchor="the-empty-type"> <name>The 'empty' Type</name> <t>Leafs of type empty <bcp14>MUST</bcp14> be encoded using the CBOR null value (major type 7, additional information 22).</t> <t>The following example shows the encoding of an 'is-router' leaf representation node instance when present.</t> <t>Definition example adapted from <xref target="RFC8344"/>:</t> <sourcecode type="yang"><![CDATA[ leaf is-router { type empty; } ]]></sourcecode> <t>CBOR diagnostic notation: null</t> <t>CBOR encoding: F6</t> </section> <section anchor="union"> <name>The 'union' Type</name> <t>Leafs of type union <bcp14>MUST</bcp14> be encoded using the rules associated with one of the types listed. 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> <ul spacing="normal"> <li>bits</li> <li>enumeration</li> <li>identityref</li> <li>instance-identifier</li> </ul> <t>See <xref target="tag-registry"/> for the assigned value of these CBOR tags.</t> <t>As mentioned in Sections <xreftarget="enumeration"/>target="enumeration" format="counter"/> and in <xreftarget="bits"/>,target="bits" format="counter"/>, 'enumeration' and 'bits' are encoded as a CBOR text string data item (major type 3) when defined within a 'union' type. (This adds considerablecomplexity,complexity but is necessary because of an idiosyncrasy of the YANG data model for unions; theworkaroundwork-around allows compatibility to be maintained with the encoding of overlapping unions in XML and JSON. See also <xref section="9.12" sectionFormat="of" target="RFC7950"/>.)</t> <t>The following example shows the encoding of an 'ip-address' leaf representation node instance when set to "2001:db8:a0b:12f0::1".</t><t>Definition<t keepWithNext="true">Definition example(adaptedadapted from <xreftarget="RFC6991"/>):</t>target="RFC6991"/>:</t> <sourcecode type="yang"><![CDATA[ typedef ipv4-address { type string { 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])' + '(%[\p{N}\p{L}]+)?'; } } typedef ipv6-address { type string { pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + '(%[\p{N}\p{L}]+)?'; pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + '(%.+)?'; } } typedef ip-address { type union { type ipv4-address; type ipv6-address; } } leaf address { type ip-address; } ]]></sourcecode> <t>CBOR diagnostic notation: "2001:db8:a0b:12f0::1"</t> <t>CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31</t> </section> <section anchor="instance-id"> <name>The 'instance-identifier' Type</name> <t>This specification supports two approaches for encoding aninstance-identifier,instance-identifier: one based on YANG Schema ItemiDentifieriDentifier, as defined in <xreftarget="sid"/>target="sid"/>, and one based onnamesnames, as defined in <xref target="name"/>. See <xref target="union"/> for an exceptional case when this representation needs to be tagged.</t> <section anchor="instance-identifier-with-sid"> <name>SIDs asinstance-identifier</name>'instance-identifier'</name> <t>SIDs uniquely identify a schema node. In the case of a single instance schema node, i.e., a schema node defined at the root of a YANG module or submodule or schema nodes defined within a container, the SID is sufficient to identify this instance (representation node). (Note that no delta mechanism is employed for SIDs used for identityref, see <xref target="identityref-with-sid"/>.)<!-- Is this clear enough? --></t> <t>In the case of a representation node that is an entry of a YANG list, a SID is combined with the list key(s) to identify each instance within the YANG list(s).</t><t>Instance identifiers<t>Instance-identifiers of single instance schema nodes <bcp14>MUST</bcp14> be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted schema node SID.</t><t>Instance identifiers<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) containing the following entries:</t> <ul spacing="normal"> <li>The first entry <bcp14>MUST</bcp14> be encoded as a CBOR unsigned 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 each key required to identify the instance of the targeted schema node. These keys <bcp14>MUST</bcp14> be ordered as defined in the 'key' YANG statement, starting from thetop leveltop-level list, and followed by eachof thesubordinate list(s).</li> </ul> <t>Examples within this section assume the definition of a schema node of type 'instance-identifier':</t> <t>Definition example adapted from <xref target="RFC7950"/>:</t> <sourcecode type="yang"><![CDATA[ container system { ... leaf reporting-entity { type instance-identifier; } ]]></sourcecode> <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>Definition example adapted from <xref target="RFC7317"/>:</t> <sourcecode type="yang"><![CDATA[ container system { leaf contact { type string; } leaf hostname { type inet:domain-name; } } ]]></sourcecode> <t>CBOR diagnostic notation: 1741</t> <t>CBOR encoding: 19 06CD</t><t><strong>Second<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. It uses a somewhat arbitrarily modified YANG module version from <xref target="RFC7317"/> by 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> <sourcecode type="yang"><![CDATA[ list user { key name; leaf name { type string; } leaf password { type ianach:crypt-hash; } list authorized-key { key "name country"; leaf country { type string; } leaf name { type string; } leaf algorithm { type string; } leaf key-data { type binary; } } } ]]></sourcecode> <t>CBOR diagnostic notation: [1734, "bob", "admin", "france"]</t><t>CBOR<t keepWithNext="true">CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ 84 # array(4) 19 06C6 # unsigned(1734) 63 # text(3) 626F62 # "bob" 65 # text(5) 61646D696E # "admin" 66 # text(6) 6672616E6365 # "france" ]]></sourcecode> <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" (SID1730)1730), corresponding to username "jack".</t> <t>CBOR diagnostic notation: [1730, "jack"]</t> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ 82 # array(2) 19 06C2 # unsigned(1730) 64 # text(4) 6A61636B # "jack" ]]></sourcecode> </section> <section anchor="names-as-instance-identifier"> <name>Names asinstance-identifier</name>'instance-identifier'</name> <t>An"instance-identifier"'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 in instance-identifier values follows the rules stated in <xref target="name"/>, namely:</t> <ul spacing="normal"> <li>The leftmost (top-level) data node name is always in thenamespace qualifiednamespace-qualified form.</li> <li>Any subsequent data node name is in thenamespace qualifiednamespace-qualified form if the node is defined in a module other than its parentnode, andnode; otherwise, the simple form isused otherwise.used. This rule also holds for node names appearing in predicates.</li> </ul> <t>For example,</t> <t>/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip</t> <t>is a valid instance-identifier value because the data nodes "interfaces", "interface", and "name" are defined in the module "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip".</t> <t>The resultingxpathXML Path Language (XPath) <bcp14>MUST</bcp14> be encoded using a CBOR text string data item (major type 3).</t> <t><strong>First example:</strong></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 encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ 781c1B 2F696574662D73797374656D3A73797374656D2F636F6E74616374 ]]></sourcecode> <t><strong>Second example:</strong></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><!-- http://cbor.me/?diag=%22/ietf-system:system/authentication/user[name=%27bob%27]/authorized-key[name=%27admin%27][country=%27france%27]/key-data%22 --><sourcecode type="cbor-diag"><![CDATA[ "/ietf-system:system/authentication/user[name='bob']/ authorized-key[name='admin'][country='france']/key-data" ]]></sourcecode> <t>CBOR encoding:</t><!-- http://cbor.me/?bytes=78.6B(2F696574662D73797374656D3A73797374656D2F61757468656E7469636174696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D276672616E6365275D2F6B65792D64617461) --><sourcecode type="cbor-pretty"><![CDATA[ 78 6B 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A 65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27 6672616E6365275D2F6B65792D64617461 ]]></sourcecode> <t><strong>Third example:</strong></t> <t>This example is described in <xref target="instance-identifier-with-sid"/>.</t> <t>CBOR diagnostic notation:</t> <sourcecode type="cbor-diag"><![CDATA[ "/ietf-system:system/authentication/user[name='jack']" ]]></sourcecode> <t>CBOR encoding:</t> <sourcecode type="cbor-pretty"><![CDATA[ 78 34 # text(52) 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 74696F6E2F757365725B6E616D653D276A61636B275D ]]></sourcecode> </section> </section> </section> <section anchor="content-type"> <name>Content-Types</name> <t>This specification defines themedia-typemedia type <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> <t>Thismedia-typemedia type represents a YANG-CBOR document containing a representation tree. If themedia-typemedia type parameter <tt>id</tt> is present, depending on its value, each representation node is identified by its associatednamespace qualified namenamespace-qualified name, as defined in <xref target="name"/> (<tt>id=name</tt>), or by its associated YANG SID (represented, e.g., in CBOR map keys as a SID delta or via tag number47)47), as defined in <xref target="sid"/> (<tt>id=sid</tt>), respectively. 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 of a CBOR map, mappingnamesnames, and/or SIDs (as defined above) into 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 <tt>id</tt> parameter will extend beyond <tt>name</tt>, <tt>sid</tt>, or being unset; if that does happen, any new value is foreseen to be of the form <tt>[a-z][a-z0-9]*(-[a-z0-9]+)*</tt>.</t> <t>In summary, this document defines three content-types, which are intended for use by different classes of applications:</t> <ul spacing="normal"><li> <tt>application/yang-data+cbor;<li><tt>application/yang-data+cbor; id=sid</tt> -- for use by applications that need to be frugal with encoding space and text string processing (e.g., applications running on constrained nodes <xreftarget="RFC7228"/>,target="RFC7228"/> or applications with particular performance requirements);</li><li> <tt>application/yang-data+cbor;<li><tt>application/yang-data+cbor; id=name</tt> -- for use by applications that do not want to engage in SIDmanagement,management and that have ample resources to managetext-string basedtext-string-based item identifiers (e.g., applications that directly want to substitute <tt>application/yang.data+json</tt> with a more efficient representation without any otherchanges);</li> <li> <tt>application/yang-data+cbor</tt>changes); and</li> <li><tt>application/yang-data+cbor</tt> -- for use by more complex applications that can benefit from the increased efficiency of SID identifiers but also need to integrate databases of YANG modules before SID mappings are defined for them.</li> </ul> <t>All three content-types are based on the same representation mechanisms, parts of which are simply not used in the first and secondcase.</t>cases.</t> <t>How the use of one of thesecontent typescontent-types is selected in a transfer protocol is outside the scope of this specification. 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. Similar mechanisms are available inCoAPthe Constrained Application Protocol (CoAP) <xref target="RFC7252"/> using the Content-Format and Accept Options; <xref target="I-D.ietf-core-comi"/> demonstrates specifics on how Content-Format may be used to indicate the <tt>id=sid</tt> case.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>The security considerations of <xref target="RFC8949"/> and <xref target="RFC7950"/> apply.</t> <t>This document defines an alternative encoding for data modeled in the YANG data modeling language. As such, this encoding does not contribute any new security issues in addition to those identified for the specific protocol or context for which it is used.</t> <t>To minimize security risks, software on the receiving side <bcp14>SHOULD</bcp14> reject all messages that do not comply to the rules of this document and reply with an appropriate error message to the sender.</t> <t>For instance, when the'id'<tt>id</tt> parameter to the media type is used, it is important to properly reject identifiers of the othertype,type to avoid scenarios where different implementations interpret a given content in different ways.</t> <t>When SIDs are in use, the interpretation of encoded data not only relies on having the right YANGmodules,modules but also on having the right SID mapping information. Management and evolution of that mapping information therefore requires the same care as the management and evolution of the YANG modules themselves. The procedures in <xref target="I-D.ietf-core-sid"/> are being defined with this in mind.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="media-types-registry"><name>Media-Types<name>Media Types Registry</name><t>This document adds<t>IANA has added the followingMedia-Typemedia type to the"Media"<xref section="Media Types"registry.</t>relative="#media-types" sectionFormat="bare" target="IANA.media-types"/>" registry <xref target="IANA.media-types"/>.</t> <table align="left"> <name>Media Types Registry</name> <thead> <tr> <th align="left">Name</th> <th align="left">Template</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">yang-data+cbor</td> <td align="left">application/yang-data+cbor</td> <td align="left">RFCXXXX</td>9254</td> </tr> </tbody> </table><t>// RFC Ed.: please replace RFC XXXX with this RFC number and remove this note.</t><dlspacing="compact">newline="false" spacing="normal"> <dt>Type name:</dt><dd> <t>application</t> </dd><dd>application</dd> <dt>Subtype name:</dt><dd> <t>yang-data+cbor</t> </dd><dd>yang-data+cbor</dd> <dt>Required parameters:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Optional parameters:</dt><dd> <t>id<dd>id (see <xref target="content-type"/> of RFCXXXX)</t> </dd>9254)</dd> <dt>Encoding considerations:</dt><dd> <t>binary (CBOR)</t> </dd><dd>binary (CBOR)</dd> <dt>Security considerations:</dt><dd> <t>see<dd>see <xref target="security-considerations"/> of RFCXXXX</t> </dd>9254</dd> <dt>Interoperability considerations:</dt> <dd>N/A</dd> <dt>Published specification:</dt><dd> <t>RFC XXXX</t> </dd><dd>RFC 9254</dd> <dt>Applications that use this media type:</dt> <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 & email address to contact for further information:</dt><dd> <t>CORE<dd>CORE WG mailing list(core@ietf.org),(core@ietf.org) or IETF Applications and Real-Time Area(art@ietf.org)</t> </dd>(art@ietf.org)</dd> <dt>Intended usage:</dt><dd> <t>COMMON</t> </dd><dd>COMMON</dd> <dt>Restrictions on usage:</dt><dd> <t>none</t> </dd> <dt>Author/Change<dd>N/A</dd> <dt>Author:</dt> <dd>CoRE WG</dd> <dt>Change controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> </dl> </section> <section anchor="coap-content-formats-registry"> <name>CoAP Content-Formats Registry</name><t>This document adds<t>IANA has added the followingContent-FormatContent-Formats to the"CoAP Content-Formats","<xref section="CoAP Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/>" subregistry, within the"Constrained"<xref section="Constrained RESTful Environments (CoRE) Parameters"registry, where TBD3 comes from therelative="#coap-content-format" sectionFormat="bare" target="IANA.core-parameters"/>" registry <xref target="IANA.core-parameters"/>. The registration procedure is "Expert Review" for the 0-255 range andTBD1 and TBD2 come from the"IETF Review" for the 256-9999 range.</t> <table align="left"> <name>CoAP Content-Format Registry</name> <thead> <tr> <thalign="left">Contentalign="left">Media Type</th> <thalign="left">Content Coding</th>align="left">Encoding</th> <th align="left">ID</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">application/yang-data+cbor</td> <td align="left">-</td> <tdalign="left">TBD1</td>align="left">340</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">application/yang-data+cbor; id=name</td> <td align="left">-</td> <tdalign="left">TBD2</td>align="left">341</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">application/yang-data+cbor; id=sid</td> <td align="left">-</td> <tdalign="left">TBD3</td>align="left">140</td> <td align="left">RFCXXXX</td>9254</td> </tr> </tbody> </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 anchor="tag-registry"> <name>CBOR Tags Registry</name><t>In<t>IANA has allocated the following CBOR tag numbers in theregistry"<xref section="CBOR Tags"relative="#cbor-tags"relative="#tags" sectionFormat="bare" target="IANA.cbor-tags"/>" registry <xreftarget="IANA.cbor-tags"/>, as pertarget="IANA.cbor-tags"/> defined in <xref section="9.2" sectionFormat="of"target="RFC8949"/>, IANA has allocated the CBOR tags in <xref target="tab-tag-values"/> for the YANG datatypes listed.</t>target="RFC8949"/>.</t> <table anchor="tab-tag-values"> <name>CBORtags defined by this specification</name>Tags Registry</name> <thead> <tr> <th align="left">Tag</th> <th align="left">Data Item</th> <th align="left">Semantics</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">43</td> <td align="left">text string</td> <td align="left">YANG bits datatype; see <xreftarget="bits"/></td>target="bits"/>.</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">44</td> <td align="left">text string</td> <td align="left">YANG enumeration datatype; see <xref target="enumeration"/>.</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">45</td> <td align="left">unsigned integer or text string</td> <td align="left">YANG identityref datatype; see <xref target="identityref"/>.</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">46</td> <td align="left">unsigned integer or text string or array</td> <td align="left">YANG instance-identifier datatype; see <xref target="instance-id"/>.</td> <td align="left">RFCXXXX</td>9254</td> </tr> <tr> <td align="left">47</td> <td align="left">unsigned integer</td> <td align="left">YANG Schema Item iDentifier (SID); see <xref target="sid"/>.</td> <td align="left">RFCXXXX</td>9254</td> </tr> </tbody> </table><t>// RFC Ed.: please replace RFC XXXX with RFC number and remove this note</t></section> </section> </middle> <back> <displayreference target="I-D.ietf-core-sid" to="CORE-SID"/> <displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <referenceanchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950"> <front> <title>The YANG 1.1 Data Modeling Language</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"> <organization/> </author> <date month="August" year="2016"/> <abstract> <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="7950"/> <seriesInfo name="DOI" value="10.17487/RFC7950"/> </reference> <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951"> <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 configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, 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/rfc8040"> <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 concepts 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/rfc8259"> <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 ECMAScript 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 interoperability 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/rfc8791"> <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 data 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/rfc5234">anchor="IANA.media-types" target="https://www.iana.org/assignments/media-types/"> <front><title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"> <organization/> </author> <author fullname="P. Overell" initials="P." surname="Overell"> <organization/><title>Media Types</title> <author> <organization>IANA</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 Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract></front><seriesInfo name="STD" value="68"/> <seriesInfo name="RFC" value="5234"/> <seriesInfo name="DOI" value="10.17487/RFC5234"/></reference> <referenceanchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949">anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters/"> <front><title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/> </author> <author fullname="P. Hoffman" initials="P." surname="Hoffman"> <organization/> </author> <date month="December" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <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/><title>Constrained RESTful Environments (CoRE) Parameters</title> <author> <organization>IANA</organization> </author><date month="June" year="2019"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t> </abstract></front><seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/></reference> <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags"> <front> <title>Concise Binary Object Representation (CBOR) Tags</title> <author> <organization>IANA</organization> </author><date/></front> </reference><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name> <referenceanchor="I-D.ietf-core-sid" target="https://www.ietf.org/archive/id/draft-ietf-core-sid-18.txt">anchor="I-D.ietf-core-sid"> <front> <title>YANG Schema Item iDentifier (YANG SID)</title> <authorfullname="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>initials='M' surname='Veillette' fullname='Michel Veillette' role='editor'> <organization/> </author> <authorfullname="Michael Richardson"> <organization>Sandelman Software Works</organization>initials='A' surname='Pelov' fullname='Alexander Pelov' role='editor'> <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> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-18"/> </reference> <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252"> <front> <title>The Constrained Application Protocol (CoAP)</title><authorfullname="Z. Shelby" initials="Z." surname="Shelby">initials='I' surname='Petrov' fullname='Ivaylo Petrov' role='editor'> <organization/> </author> <authorfullname="K. Hartke" initials="K." surname="Hartke">initials='C' surname='Bormann' fullname='Carsten Bormann'> <organization/> </author> <authorfullname="C. Bormann" initials="C." surname="Bormann">initials='M' surname='Richardson' fullname='Michael Richardson'> <organization/> </author> <datemonth="June" year="2014"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t> </abstract>month="November" day="18" year="2021" /> </front> <seriesInfoname="RFC" value="7252"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/>name="Internet-Draft" value="draft-ietf-core-sid-18" /> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <referenceanchor="I-D.ietf-core-comi" target="https://www.ietf.org/archive/id/draft-ietf-core-comi-11.txt">anchor="I-D.ietf-core-comi"> <front> <title>CoAP Management Interface (CORECONF)</title> <authorfullname="Michel Veillette"> <organization>Trilliant Networks Inc.</organization>initials='M' surname='Veillette' fullname='Michel Veillette' role='editor'> <organization/> </author> <authorfullname="Peterinitials='P' surname='van der Stok' fullname='Peter van derStok"> <organization>consultant</organization> </author> <author fullname="Alexander Pelov"> <organization>Acklio</organization> </author> <author fullname="Andy Bierman"> <organization>YumaWorks</organization> </author> <author fullname="Ivaylo Petrov"> <organization>Acklio</organization> </author> <date day="17" month="January" year="2021"/> <abstract> <t> This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-11"/> </reference> <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241"> <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" surname="Schoenwaelder"> <organization/> </author> <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"> <organization/> </author> <date month="June" year="2011"/> <abstract> <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol 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/rfc6991"> <front> <title>Common YANG Data Types</title> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"> <organization/> </author> <date month="July" year="2013"/> <abstract> <t>This document introduces a collection of common data types to be 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/rfc7228"> <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">Stok' role='editor'> <organization/> </author><date month="May" year="2014"/> <abstract> <t>The Internet Protocol Suite is increasingly used on small devices 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/rfc7317"> <front> <title>A YANG Data Model for System Management</title><authorfullname="A. Bierman" initials="A." surname="Bierman">initials='A' surname='Pelov' fullname='Alexander Pelov'> <organization/> </author> <authorfullname="M. Bjorklund" initials="M." surname="Bjorklund">initials='A' surname='Bierman' fullname='Andy Bierman'> <organization/> </author><date month="August" year="2014"/> <abstract> <t>This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.</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/rfc8343"> <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 network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t> <t>The YANG data model in this document conforms to the Network Management 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/rfc8344"> <front> <title>A YANG Data Model for IP Management</title><authorfullname="M. Bjorklund" initials="M." surname="Bjorklund">initials='I' surname='Petrov' fullname='Ivaylo Petrov' role='editor'> <organization/> </author> <datemonth="March" year="2018"/> <abstract> <t>This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</t> <t>This document obsoletes RFC 7277.</t> </abstract>month="January" day="17" year="2021" /> </front> <seriesInfoname="RFC" value="8344"/> <seriesInfo name="DOI" value="10.17487/RFC8344"/>name="Internet-Draft" value="draft-ietf-core-comi-11" /> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8344.xml"/> </references> </references> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>This document has been largely inspired by the extensiveworkswork 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 contributorstoof these twodrafts.</t>documents.</t> <t>The authors would also like to acknowledge the review, feedback, and comments from <contact fullname="Ladislav Lhotka"/> and <contact fullname="JürgenSchönwälder"/>,Schönwälder"/> and from thedocument shepherdDocument Shepherd <contact fullname="Marco Tiloca"/>. Extensive comments helped us further improve the document in the IESG review process; the authors would like to call out specifically the feedback and guidance by the responsible AD <contact fullname="Francesca Palombini"/> and the significant improvements suggested by IESG members <contact fullname="Benjamin Kaduk"/> and <contact fullname="Rob Wilton"/>.</t> </section> </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>