< draft-ietf-core-yang-cbor-16.txt   draft-ietf-core-yang-cbor-17.txt >
Internet Engineering Task Force M. Veillette, Ed. Internet Engineering Task Force M. Veillette, Ed.
Internet-Draft Trilliant Networks Inc. Internet-Draft Trilliant Networks Inc.
Intended status: Standards Track I. Petrov, Ed. Intended status: Standards Track I. Petrov, Ed.
Expires: 27 December 2021 Google Switzerland GmbH Expires: 28 April 2022 Google Switzerland GmbH
A. Pelov A. Pelov
Acklio Acklio
C. Bormann C. Bormann
Universität Bremen TZI Universität Bremen TZI
25 June 2021 M. Richardson
Sandelman Software Works
25 October 2021
CBOR Encoding of Data Modeled with YANG CBOR Encoding of Data Modeled with YANG
draft-ietf-core-yang-cbor-16 draft-ietf-core-yang-cbor-17
Abstract Abstract
This document defines encoding rules for serializing configuration Based on the Concise Binary Object Representation (CBOR, RFC 8949),
data, state data, RPC input and RPC output, action input, action this document defines encoding rules for representing configuration
output, notifications and the yang-data extension defined within YANG data, state data, parameters and results of Remote Procedure Call
modules using the Concise Binary Object Representation (CBOR, RFC (RPC) operations or actions, and notifications, defined using YANG
8949). (RFC 7950).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 December 2021. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 21
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. Properties of the CBOR Encoding . . . . . . . . . . . . . . . 5 3. Properties of the CBOR Encoding . . . . . . . . . . . . . . . 5
3.1. CBOR diagnostic notation . . . . . . . . . . . . . . . . 6 3.1. CBOR diagnostic notation . . . . . . . . . . . . . . . . 6
3.2. YANG Schema Item iDentifier . . . . . . . . . . . . . . . 8 3.2. YANG Schema Item iDentifier . . . . . . . . . . . . . . . 8
3.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Encoding of YANG Schema Node Instances . . . . . . . . . . . 10 4. Encoding of YANG Schema Node Instances . . . . . . . . . . . 10
4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 10 4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 11
4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 11 4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 11
4.2. The 'container' and other nodes from the data tree . . . 11 4.2. The 'container' and other nodes from the data tree . . . 12
4.2.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 12 4.2.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 13
4.2.2. Using names in keys . . . . . . . . . . . . . . . . . 13 4.2.2. Using names in keys . . . . . . . . . . . . . . . . . 14
4.3. The 'leaf-list' . . . . . . . . . . . . . . . . . . . . . 14 4.3. The 'leaf-list' . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 14 4.3.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 15
4.3.2. Using names in keys . . . . . . . . . . . . . . . . . 15 4.3.2. Using names in keys . . . . . . . . . . . . . . . . . 16
4.4. The 'list' and 'list' entries . . . . . . . . . . . . . . 15 4.4. The 'list' and 'list' entries . . . . . . . . . . . . . . 16
4.4.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 16 4.4.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 17
4.4.2. Using names in keys . . . . . . . . . . . . . . . . . 18 4.4.2. Using names in keys . . . . . . . . . . . . . . . . . 19
4.5. The 'anydata' . . . . . . . . . . . . . . . . . . . . . . 20 4.5. The 'anydata' . . . . . . . . . . . . . . . . . . . . . . 21
4.5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 21 4.5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 22
4.5.2. Using names in keys . . . . . . . . . . . . . . . . . 22 4.5.2. Using names in keys . . . . . . . . . . . . . . . . . 23
4.6. The 'anyxml' . . . . . . . . . . . . . . . . . . . . . . 23 4.6. The 'anyxml' . . . . . . . . . . . . . . . . . . . . . . 24
4.6.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 23 4.6.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 24
4.6.2. Using names in keys . . . . . . . . . . . . . . . . . 24 4.6.2. Using names in keys . . . . . . . . . . . . . . . . . 25
5. Encoding of 'yang-data' extension . . . . . . . . . . . . . . 24 5. Encoding of 'yang-data' extension . . . . . . . . . . . . . . 25
5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . . . 25 5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . . . 26
5.2. Using names in keys . . . . . . . . . . . . . . . . . . . 26 5.2. Using names in keys . . . . . . . . . . . . . . . . . . . 27
6. Representing YANG Data Types in CBOR . . . . . . . . . . . . 27 6. Representing YANG Data Types in CBOR . . . . . . . . . . . . 28
6.1. The unsigned integer Types . . . . . . . . . . . . . . . 27 6.1. The unsigned integer Types . . . . . . . . . . . . . . . 28
6.2. The integer Types . . . . . . . . . . . . . . . . . . . . 28 6.2. The integer Types . . . . . . . . . . . . . . . . . . . . 29
6.3. The 'decimal64' Type . . . . . . . . . . . . . . . . . . 28 6.3. The 'decimal64' Type . . . . . . . . . . . . . . . . . . 29
6.4. The 'string' Type . . . . . . . . . . . . . . . . . . . . 29 6.4. The 'string' Type . . . . . . . . . . . . . . . . . . . . 30
6.5. The 'boolean' Type . . . . . . . . . . . . . . . . . . . 29 6.5. The 'boolean' Type . . . . . . . . . . . . . . . . . . . 30
6.6. The 'enumeration' Type . . . . . . . . . . . . . . . . . 30 6.6. The 'enumeration' Type . . . . . . . . . . . . . . . . . 31
6.7. The 'bits' Type . . . . . . . . . . . . . . . . . . . . . 31 6.7. The 'bits' Type . . . . . . . . . . . . . . . . . . . . . 32
6.8. The 'binary' Type . . . . . . . . . . . . . . . . . . . . 33 6.8. The 'binary' Type . . . . . . . . . . . . . . . . . . . . 34
6.9. The 'leafref' Type . . . . . . . . . . . . . . . . . . . 33 6.9. The 'leafref' Type . . . . . . . . . . . . . . . . . . . 34
6.10. The 'identityref' Type . . . . . . . . . . . . . . . . . 34 6.10. The 'identityref' Type . . . . . . . . . . . . . . . . . 35
6.10.1. SIDs as identityref . . . . . . . . . . . . . . . . 34 6.10.1. SIDs as identityref . . . . . . . . . . . . . . . . 35
6.10.2. Name as identityref . . . . . . . . . . . . . . . . 35 6.10.2. Name as identityref . . . . . . . . . . . . . . . . 36
6.11. The 'empty' Type . . . . . . . . . . . . . . . . . . . . 36
6.11. The 'empty' Type . . . . . . . . . . . . . . . . . . . . 35 6.12. The 'union' Type . . . . . . . . . . . . . . . . . . . . 37
6.12. The 'union' Type . . . . . . . . . . . . . . . . . . . . 36 6.13. The 'instance-identifier' Type . . . . . . . . . . . . . 38
6.13. The 'instance-identifier' Type . . . . . . . . . . . . . 37 6.13.1. SIDs as instance-identifier . . . . . . . . . . . . 38
6.13.1. SIDs as instance-identifier . . . . . . . . . . . . 37 6.13.2. Names as instance-identifier . . . . . . . . . . . . 41
6.13.2. Names as instance-identifier . . . . . . . . . . . . 40 7. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 9.1. Media-Types Registry . . . . . . . . . . . . . . . . . . 44
9.1. Media-Types Registry . . . . . . . . . . . . . . . . . . 42 9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 45
9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43 9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 45
9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 10.2. Informative References . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . 45 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
The specification of the YANG 1.1 data modeling language [RFC7950] The specification of the YANG 1.1 data modeling language [RFC7950]
defines an XML encoding for data instances, i.e., contents of defines an XML encoding for data instances, i.e., contents of
configuration datastores, state data, RPC inputs and outputs, action configuration datastores, state data, RPC inputs and outputs, action
inputs and outputs, and event notifications. inputs and outputs, and event notifications.
An additional set of encoding rules has been defined in [RFC7951] An additional set of encoding rules has been defined in [RFC7951]
based on the JavaScript Object Notation (JSON) Data Interchange based on the JavaScript Object Notation (JSON) Data Interchange
Format [RFC8259]. Format [RFC8259].
The aim of this document is to define a set of encoding rules for the The aim of this document is to define a set of encoding rules for the
Concise Binary Object Representation (CBOR) [RFC8949]. The resulting Concise Binary Object Representation (CBOR) [RFC8949], collectively
encoding is more compact compared to XML and JSON and more suitable called _YANG-CBOR_. The resulting encoding is more compact compared
for Constrained Nodes and/or Constrained Networks as defined by to XML and JSON and more suitable for Constrained Nodes and/or
[RFC7228]. Constrained Networks as defined by [RFC7228].
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
skipping to change at page 4, line 4 skipping to change at page 4, line 8
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
* action * action
* anydata * anydata
* anyxml * anyxml
* data node * data node
* data tree * data tree
* datastore * datastore
* feature * feature
* identity * identity
* module * module
* notification * notification
* RPC * RPC
* schema node * schema node
* schema tree
* submodule * submodule
The following terms are defined in [RFC8040]: The following terms are defined in [RFC8040]:
* yang-data extension * yang-data extension
This specification also makes use of the following terminology: This specification also makes use of the following terminology:
* child: A schema node defined as a child node of a container, a * child: A schema node defined as a child node of a container, a
list, a case, a notification, an RPC input, an RPC output, an list, a case, a notification, an RPC input, an RPC output, an
action input, or an action output. action input, or an action output.
* YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned * YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned
integer used to identify different YANG items. integer used to identify different YANG items.
* delta: Difference between the current YANG SID and a reference * delta: Difference between the current YANG SID and a reference
YANG SID. A reference YANG SID is defined for each context for YANG SID. A reference YANG SID is defined for each context for
which deltas are used. which deltas are used.
* item: A schema node, an identity, a module, a submodule, or a * absolute SID: YANG SID not encoded as a delta. This is usually
feature defined using the YANG modeling language. called out explicitly only in positions where normally a delta
would be found.
* item: A schema node, an identity, a module, or a feature defined
using the YANG modeling language.
* list entry: the data associated with a single element of a list. * list entry: the data associated with a single element of a list.
* parent: The container, list, case, notification, RPC input, RPC * parent: The container, list, case, notification, RPC input, RPC
output, action input or action output node in which a schema node output, action input or action output node in which a schema node
is defined. is defined.
3. Properties of the CBOR Encoding 3. Properties of the CBOR Encoding
This document defines CBOR encoding rules for YANG data trees and This document defines CBOR encoding rules for YANG data trees and
skipping to change at page 5, line 25 skipping to change at page 5, line 30
RPC input, RPC output, action input, or action output is serialized RPC input, RPC output, action input, or action output is serialized
using a CBOR map in which each child schema node is encoded using a using a CBOR map in which each child schema node is encoded using a
key and a value. This specification supports two types of CBOR keys; key and a value. This specification supports two types of CBOR keys;
YANG Schema Item iDentifier (YANG SID) as defined in Section 3.2 and YANG Schema Item iDentifier (YANG SID) as defined in Section 3.2 and
names as defined in Section 3.3. Each of these key types is encoded names as defined in Section 3.3. Each of these key types is encoded
using a specific CBOR type which allows their interpretation during using a specific CBOR type which allows their interpretation during
the deserialization process. Protocols or mechanisms implementing the deserialization process. Protocols or mechanisms implementing
this specification can mandate the use of a specific key type. this specification can mandate the use of a specific key type.
In order to minimize the size of the encoded data, the proposed In order to minimize the size of the encoded data, the proposed
mapping avoids any unnecessary meta-information beyond those natively mapping avoids any unnecessary meta-information beyond that directly
supported by CBOR. For instance, CBOR tags are used solely in the provided by the CBOR basic generic data model (Section 2 of
case of a SID not encoded as delta, anyxml schema nodes, or the union [RFC8949]). For instance, CBOR tags are used solely in the case of
datatype, to distinguish explicitly the use of different YANG an absolute SID, anyxml schema nodes, or the union datatype, to
datatypes encoded using the same CBOR major type. distinguish explicitly the use of different YANG datatypes encoded
using the same CBOR major type.
Unless specified otherwise by the protocol or mechanism implementing Unless specified otherwise by the protocol or mechanism implementing
this specification, the indefinite lengths encoding as defined in this specification, the indefinite length encoding as defined in
Section 3.2 of [RFC8949] SHALL be supported by CBOR decoders. Section 3.2 of [RFC8949] SHALL 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.)
Data nodes implemented using a CBOR array, map, byte string, or text Data nodes implemented using a CBOR array, map, byte string, or text
string can be instantiated but empty. In this case, they are encoded string can be instantiated but empty. In this case, they are encoded
with a length of zero. with a length of zero.
When schema nodes are serialized using the rules defined by this When schema nodes are serialized using the rules defined by this
specification as part of an application payload, the payload SHOULD specification as part of an application payload, the payload SHOULD
include information that would allow a stateless way to identify each include information that would allow a stateless way to identify each
node, such as the SID number associated with the node, SID delta from node, such as the SID number associated with the node, SID delta from
another SID in the application payload, the namespace qualified name, another SID in the application payload, the namespace qualified name,
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Note: CBOR binary contents shown in this specification are annotated Note: CBOR binary contents shown in this specification are annotated
with comments. These comments are delimited by slashes ("/") as with comments. These comments are delimited by slashes ("/") as
defined in [RFC8610] Appendix G.6. defined in [RFC8610] Appendix G.6.
3.2. YANG Schema Item iDentifier 3.2. YANG Schema Item iDentifier
Some of the items defined in YANG [RFC7950] require the use of a Some of the items defined in YANG [RFC7950] require the use of a
unique identifier. In both Network Configuration Protocol (NETCONF) unique identifier. In both Network Configuration Protocol (NETCONF)
[RFC6241] and RESTCONF [RFC8040], these identifiers are implemented [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented
using strings. To allow the implementation of data models defined in using text strings. To allow the implementation of data models
YANG in constrained devices and constrained networks, a more compact defined in YANG in constrained devices and constrained networks, a
method to identify YANG items is required. This compact identifier, more compact method to identify YANG items is required. This compact
called YANG Schema Item iDentifier, is an unsigned integer. The identifier, called YANG Schema Item iDentifier, is an unsigned
following items are identified using YANG SIDs (often shortened to integer. The following items are identified using YANG SIDs (often
SIDs): shortened to SIDs):
* identities * identities
* data nodes * data nodes
* RPCs and associated input(s) and output(s) * RPCs and associated input(s) and output(s)
* actions and associated input(s) and output(s) * actions and associated input(s) and output(s)
* notifications and associated information * notifications and associated information
* YANG modules, submodules, and features * YANG modules and features
To minimize their size, SIDs used as keys in inner CBOR maps are Note that any structuring of modules into submodules is transparent
typically encoded using deltas. Conversion from SIDs to deltas and to YANG-CBOR: SIDs are not allocated for the names of submodules, and
back to SIDs are stateless processes solely based on the data any items within a submodule are effectively allocated SIDs as part
serialized or deserialized. These SIDs may also be encoded as of processing the module that includes them.
absolute number when enclosed by CBOR tag 47.
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 may be encoded using CBOR tag 47 (as defined in Section 9.3).
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.
Mechanisms and processes used to assign SIDs to YANG items and to Mechanisms and processes used to assign SIDs to YANG items and to
guarantee their uniqueness are outside the scope of the present guarantee their uniqueness are outside the scope of the present
specification. If SIDs are to be used, the present specification is specification. If SIDs are to be used, the present specification is
used in conjunction with a specification defining this management. used in conjunction with a specification defining this management.
One example for such a specification is [I-D.ietf-core-sid]. [I-D.ietf-core-sid] is the definitive way to assign SID values for
YANG modules managed by the IETF. With YANG modules managed by non-
IETF entities, use of [I-D.ietf-core-sid] is RECOMMENDED. The
present specification has been designed to allow different methods of
assignment to be used within separate domains.
3.3. Name 3.3. Name
This specification also supports the encoding of YANG item This specification also supports the encoding of YANG item
identifiers as strings, similar to those used by the JSON Encoding of identifiers as text strings, similar to those used by the JSON
Data Modeled with YANG [RFC7951]. This approach can be used to avoid Encoding of Data Modeled with YANG [RFC7951]. This approach can be
the management overhead associated with SID allocation. The main used to avoid the management overhead associated with SID allocation.
drawback is the significant increase in size of the encoded data. The main drawback is the significant increase in size of the encoded
data.
YANG item identifiers implemented using names MUST be in one of the YANG item identifiers implemented using names MUST be in one of the
following forms: following forms:
* simple - the identifier of the YANG item (i.e., schema node or * simple - the identifier of the YANG item (i.e., schema node or
identity). identity).
* namespace qualified - the identifier of the YANG item is prefixed * namespace qualified - the identifier of the YANG item is prefixed
with the name of the module in which this item is defined, with the name of the module in which this item is defined,
separated by the colon character (":"). separated by the colon character (":").
skipping to change at page 10, line 29 skipping to change at page 11, line 5
Schema node instances defined using the YANG modeling language are Schema node instances defined using the YANG modeling language are
encoded using CBOR [RFC8949] based on the rules defined in this encoded using CBOR [RFC8949] based on the rules defined in this
section. We assume that the reader is already familiar with both section. We assume that the reader is already familiar with both
YANG [RFC7950] and CBOR [RFC8949]. YANG [RFC7950] and CBOR [RFC8949].
4.1. The 'leaf' 4.1. The 'leaf'
A 'leaf' MUST be encoded accordingly to its datatype using one of the A 'leaf' MUST be encoded accordingly to its datatype using one of the
encoding rules specified in Section 6. encoding rules specified in Section 6.
The following examples shows the encoding of a 'hostname' leaf using The following examples show the encoding of a 'hostname' leaf using a
a SID or a name. SID or a name.
Definition example from [RFC7317]: Definition example from [RFC7317]:
typedef domain-name { typedef domain-name {
type string { type string {
length "1..253"; length "1..253";
pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9].) pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9].)
*([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.? *([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?
)|\.'; )|\.';
} }
skipping to change at page 11, line 34 skipping to change at page 12, line 13
CBOR encoding: CBOR encoding:
A1 # map(1) A1 # map(1)
74 # text(20) 74 # text(20)
696574662D73797374656D3A686F73746E616D65 696574662D73797374656D3A686F73746E616D65
72 # text(18) 72 # text(18)
6D79686F73742E6578616D706C652E636F6D 6D79686F73742E6578616D706C652E636F6D
4.2. The 'container' and other nodes from the data tree 4.2. The 'container' and other nodes from the data tree
Instances of containers, lists, notification contents, RPC inputs, Instances of containers, notification contents, RPC inputs, RPC
RPC outputs, action inputs, and action outputs schema nodes MUST be outputs, action inputs, and action outputs schema nodes MUST be
encoded using a CBOR map data item (major type 5). A map is encoded using a CBOR map data item (major type 5). The same encoding
comprised of pairs of data items, with each pair consisting of a key is also used for the list entries in a list (Section 4.4). 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 and a value. Each key within the CBOR map is set to a schema node
identifier, each value is set to the value of this schema node identifier, each value is set to the value of this schema node
instance according to the instance datatype. instance according to the instance datatype.
This specification supports two types of CBOR keys; SID as defined in This specification supports two types of CBOR map keys; SID as
Section 3.2 and names as defined in Section 3.3. defined in Section 3.2 and names as defined in Section 3.3.
The following examples shows the encoding of a 'system-state' The following examples show the encoding of a 'system-state'
container schema node instance using SIDs or names. container schema node instance using SIDs or names.
Definition example from [RFC7317]: Definition example from [RFC7317]:
typedef date-and-time { typedef date-and-time {
type string { type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[\+\-] pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[\+\-]
\d{2}:\d{2})'; \d{2}:\d{2})';
} }
} }
skipping to change at page 12, line 28 skipping to change at page 13, line 8
leaf boot-datetime { leaf boot-datetime {
type date-and-time; type date-and-time;
} }
} }
} }
4.2.1. Using SIDs in keys 4.2.1. Using SIDs in keys
In the context of containers and other nodes from the data tree, CBOR In the context of containers and other nodes from the data tree, CBOR
map keys within inner CBOR maps can be encoded using deltas or SIDs. map keys within inner CBOR maps can be encoded using deltas or
In the case of deltas, they MUST be encoded using a CBOR unsigned absolute SIDs (tag 47).
integer (major type 0) or CBOR negative integer (major type 1),
depending on the actual delta value. In the case of SID, they are
encoded using the SID value enclosed by CBOR tag 47 as defined in
Section 9.3.
Delta values are computed as follows: Delta values are computed as follows:
* In the case of a 'container', deltas are equal to the SID of the * In the case of a 'container', deltas are equal to the SID of the
current schema node minus the SID of the parent 'container'. current schema node minus the SID of the parent 'container'.
* In the case of a 'list', deltas are equal to the SID of the * In the case of a 'list', deltas are equal to the SID of the
current schema node minus the SID of the parent 'list'. current schema node minus the SID of the parent 'list'.
* In the case of an 'RPC input' or 'RPC output', deltas are equal to * In the case of an 'RPC input' or 'RPC output', deltas are equal to
skipping to change at page 16, line 45 skipping to change at page 17, line 45
} }
leaf prefer { leaf prefer {
type boolean; type boolean;
default false; default false;
} }
} }
4.4.1. Using SIDs in keys 4.4.1. Using SIDs in keys
The encoding rules of each 'list' entry are defined in Section 4.2.1. The encoding rules of each 'list' entry are defined in Section 4.2.1.
Deltas of list members are equal to the SID of the current schema
node minus the SID of the 'list'.
CBOR diagnostic notation: CBOR diagnostic notation:
{ {
1756 : [ / server (SID 1756) / 1756 : [ / server (SID 1756) /
{ {
3 : "NRC TIC server", / name (SID 1759) / 3 : "NRC TIC server", / name (SID 1759) /
5 : { / udp (SID 1761) / 5 : { / udp (SID 1761) /
1 : "tic.nrc.ca", / address (SID 1762) / 1 : "tic.nrc.ca", / address (SID 1762) /
2 : 123 / port (SID 1763) / 2 : 123 / port (SID 1763) /
skipping to change at page 22, line 29 skipping to change at page 23, line 29
18 4D # unsigned(77) 18 4D # unsigned(77)
A2 # map(2) A2 # map(2)
18 4E # unsigned(78) 18 4E # unsigned(78)
66 # text(6) 66 # text(6)
302F342F3231 # "0/4/21" 302F342F3231 # "0/4/21"
18 4F # unsigned(79) 18 4F # unsigned(79)
6A # text(10) 6A # text(10)
4F70656E2070696E2032 # "Open pin 2" 4F70656E2070696E2032 # "Open pin 2"
In some implementations, it might be simpler to use the absolute SID In some implementations, it might be simpler to use the absolute SID
tag encoding for the anydata root element. The resulting encoding is encoding (tag 47) for the anydata root element. CBOR diagnostic
as follows: notation:
{ {
60123 : { / last-event (SID 60123) / 60123 : { / last-event (SID 60123) /
47(60200) : { / event-port-fault (SID 60200) / 47(60200) : { / event-port-fault (SID 60200) /
1 : "0/4/21", / port-name (SID 60201) / 1 : "0/4/21", / port-name (SID 60201) /
2 : "Open pin 2" / port-fault (SID 60202) / 2 : "Open pin 2" / port-fault (SID 60202) /
} }
} }
} }
skipping to change at page 23, line 26 skipping to change at page 24, line 26
66 # text(6) 66 # text(6)
302F342F3231 # "0/4/21" 302F342F3231 # "0/4/21"
6A # text(10) 6A # text(10)
706F72742D6661756C74 # "port-fault" 706F72742D6661756C74 # "port-fault"
6A # text(10) 6A # text(10)
4F70656E2070696E2032 # "Open pin 2" 4F70656E2070696E2032 # "Open pin 2"
4.6. The 'anyxml' 4.6. The 'anyxml'
An anyxml schema node is used to serialize an arbitrary CBOR content, An anyxml schema node is used to serialize an arbitrary CBOR content,
i.e., its value can be any CBOR binary object. anyxml value MAY i.e., its value can be any CBOR binary object. An anyxml value MAY
contain CBOR data items tagged with one of the tags listed in contain CBOR data items tagged with one of the tags listed in
Section 9.3. The tags listed in Section 9.3 SHALL be supported. Section 9.3. The tags listed in Section 9.3 SHALL be supported.
The following example shows a valid CBOR encoded anyxml schema node The following example shows a valid CBOR encoded anyxml schema node
instance consisting of a CBOR array containing the CBOR simple values instance consisting of a CBOR array containing the CBOR simple values
'true', 'null' and 'true'. 'true', 'null' and 'true'.
Definition example from [RFC7951]: Definition example from [RFC7951]:
module bar-module { module bar-module {
skipping to change at page 31, line 29 skipping to change at page 32, line 29
next byte string, or a byte string (major type 2) that carries the next byte string, or a byte string (major type 2) that carries the
information whether certain bits are set or not. The initial offset information whether certain bits are set or not. The initial offset
value is 0 and each unsigned integer modifies the offset value of the value is 0 and each unsigned integer modifies the offset value of the
next byte string by the integer value multiplied by 8. For example, 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 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 first byte of the byte string that follows will represent bit
positions 40 to 47 both ends included. If the byte string has a positions 40 to 47 both ends included. If the byte string has a
second byte, it will carry information about bits 48 to 55 and so on. second byte, it will carry information about bits 48 to 55 and so on.
Within each byte, bits are assigned from least to most significant. Within each byte, bits are assigned from least to most significant.
After the byte string, the offset is modified by the number of bytes 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 at the in the byte string multiplied by 8. Bytes with no bits set (zero
end of the byte string are removed. An example follows. bytes) at the end of the byte string are never generated: If they
would occur at the end of the array, the zero bytes are simply
omitted; if they occur at the end of a byte string preceding an
integer, the zero bytes are removed and the integer adjusted upwards
by the number of zero bytes removed. An example follows.
The following example shows the encoding of an 'alarm-state' leaf The following example shows the encoding of an 'alarm-state' leaf
schema node instance with the 'critical' (position 3), 'warning' schema node instance with the 'critical' (position 3), 'warning'
(position 8) and 'indeterminate' (position 128) flags set. (position 8) and 'indeterminate' (position 128) flags set.
typedef alarm-state { typedef alarm-state {
type bits { type bits {
bit unknown; bit unknown;
bit under-repair; bit under-repair;
bit critical; bit critical;
skipping to change at page 32, line 30 skipping to change at page 33, line 30
leaf alarm-state { leaf alarm-state {
type alarm-state; type alarm-state;
} }
CBOR diagnostic notation: [h'0401', 14, h'01'] CBOR diagnostic notation: [h'0401', 14, h'01']
CBOR encoding: 83 42 0401 0E 41 01 CBOR encoding: 83 42 0401 0E 41 01
In a number of cases the array would only need to have one element - In a number of cases the array would only need to have one element -
a byte string with a small number of bytes inside. For this case, it a byte string with a few bytes inside. For this case, it is expected
is expected to omit the array element and have only the byte array to omit the array element and have only the byte array that would
that would have been inside. To illustrate this, let us consider the have been inside. To illustrate this, let us consider the same
same example YANG definition, but this time encoding only 'under- example YANG definition, but this time encoding only 'under-repair'
repair' and 'critical' flags. The result would be and 'critical' flags. The result would be
CBOR diagnostic notation: h'06' CBOR diagnostic notation: h'06'
CBOR encoding: 41 06 CBOR encoding: 41 06
Elements in the array MUST be either byte strings or positive Elements in the array MUST be either byte strings that do not end in
unsigned integers, where byte strings and integers MUST alternate, a zero byte, or positive unsigned integers, where byte strings and
i.e., adjacent byte strings or adjacent integers are an error. An integers MUST alternate, i.e., adjacent byte strings or adjacent
array with a single byte string MUST instead be encoded as just that integers are an error. An array with a single byte string MUST
byte string. An array with a single positive integer is an error. instead be encoded as just that byte string. An array with a single
positive integer is an error.
Values of 'bits' types defined in a 'union' type MUST be encoded To maintain compatibility with the encoding of overlapping unions in
XML, values of 'bits' types defined in a 'union' type MUST be encoded
using a CBOR text string data item (major type 3) and MUST contain a using a CBOR text string data item (major type 3) and MUST contain a
space-separated sequence of names of 'bits' that are set. The space-separated sequence of names of 'bits' that are set. The
encoding MUST be enclosed by the bits CBOR tag as specified in encoding MUST be enclosed by the bits CBOR tag as specified in
Section 9.3. Section 9.3.
The following example shows the encoding of an 'alarm-state' leaf The following example shows the encoding of an 'alarm-state' leaf
schema node instance defined using a union type with the 'under- schema node instance defined using a union type with the 'under-
repair' and 'critical' flags set. repair' and 'critical' flags set.
Definition example: Definition example:
skipping to change at page 34, line 37 skipping to change at page 35, line 37
6.10. The 'identityref' Type 6.10. The 'identityref' Type
This specification supports two approaches for encoding identityref: This specification supports two approaches for encoding identityref:
as a YANG Schema Item iDentifier as defined in Section 3.2, or as a as a YANG Schema Item iDentifier as defined in Section 3.2, or as a
name as defined in Section 6.8 of [RFC7951]. name as defined in Section 6.8 of [RFC7951].
6.10.1. SIDs as identityref 6.10.1. SIDs as identityref
When schema nodes of type identityref are implemented using SIDs, When schema nodes of type identityref are implemented using SIDs,
they MUST be encoded using a CBOR unsigned integer data item (major they MUST be encoded using a CBOR unsigned integer data item (major
type 0). (Note that no delta mechanism is employed for SIDs used for 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.) identityref.)
The following example shows the encoding of a 'type' leaf schema node The following example shows the encoding of a 'type' leaf schema node
instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880). instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880).
Definition example from [RFC7317]: Definition example from [RFC7317]:
identity interface-type { identity interface-type {
} }
skipping to change at page 37, line 50 skipping to change at page 38, line 50
This specification supports two approaches for encoding an instance- This specification supports two approaches for encoding an instance-
identifier, one based on YANG Schema Item iDentifier as defined in identifier, one based on YANG Schema Item iDentifier as defined in
Section 3.2 and one based on names as defined in Section 3.3. Section 3.2 and one based on names as defined in Section 3.3.
6.13.1. SIDs as instance-identifier 6.13.1. SIDs as instance-identifier
SIDs uniquely identify a schema node. In the case of a single 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 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, YANG module or submodule or schema nodes defined within a container,
the SID is sufficient to identify this instance. the SID is sufficient to identify this instance. (Note that no delta
mechanism is employed for SIDs used for identityref, see
Section 6.10.1.)
In the case of a schema node member of a YANG list, a SID is combined In the case of a schema node member of a YANG list, a SID is combined
with the list key(s) to identify each instance within the YANG with the list key(s) to identify each instance within the YANG
list(s). list(s).
Single instance schema nodes MUST be encoded using a CBOR unsigned Single instance schema nodes MUST be encoded using a CBOR unsigned
integer data item (major type 0) and set to the targeted schema node integer data item (major type 0) and set to the targeted schema node
SID. SID.
Schema node members of a YANG list MUST be encoded using a CBOR array Schema node members of a YANG list MUST be encoded using a CBOR array
data item (major type 4) containing the following entries: data item (major type 4) containing the following entries:
skipping to change at page 39, line 10 skipping to change at page 40, line 10
leaf hostname { leaf hostname {
type inet:domain-name; type inet:domain-name;
} }
} }
CBOR diagnostic notation: 1741 CBOR diagnostic notation: 1741
CBOR encoding: 19 06CD CBOR encoding: 19 06CD
*Second example:* *Second example:*
This example aims to show how a schema node member of a YANG list is
identified. It uses a somewhat arbitrarily modified YANG module
version from [RFC7317] by adding country to the leafs and keys of
authorized-key.
The following example shows the encoding of the 'reporting-entity' The following example shows the encoding of the 'reporting-entity'
value referencing list instance "/system/authentication/user/ value referencing list instance "/system/authentication/user/
authorized-key/key-data" (SID 1734) for user name "bob" and authorized-key/key-data" (which is assumed to have SID 1734) for user
authorized-key "admin". name "bob" and authorized-key with name "admin" and country "france".
Definition example from [RFC7317]:
list user { list user {
key name country; key name;
leaf name { leaf name {
type string; type string;
} }
leaf password { leaf password {
type ianach:crypt-hash; type ianach:crypt-hash;
} }
list authorized-key { list authorized-key {
key name country; key "name country";
leaf country { leaf country {
type string; type string;
} }
leaf name { leaf name {
type string; type string;
} }
leaf algorithm { leaf algorithm {
skipping to change at page 40, line 31 skipping to change at page 41, line 34
CBOR encoding: CBOR encoding:
82 # array(2) 82 # array(2)
19 06C2 # unsigned(1730) 19 06C2 # unsigned(1730)
64 # text(4) 64 # text(4)
6A61636B # "jack" 6A61636B # "jack"
6.13.2. Names as instance-identifier 6.13.2. Names as instance-identifier
An "instance-identifier" value is encoded as a string that is An "instance-identifier" value is encoded as a text string that is
analogous to the lexical representation in XML encoding; see analogous to the lexical representation in XML encoding; see
Section 9.13.2 of [RFC7950]. However, the encoding of namespaces in Section 9.13.2 of [RFC7950]. However, the encoding of namespaces in
instance-identifier values follows the rules stated in Section 3.3, instance-identifier values follows the rules stated in Section 3.3,
namely: namely:
* The leftmost (top-level) data node name is always in the namespace * The leftmost (top-level) data node name is always in the namespace
qualified form. qualified form.
* Any subsequent data node name is in the namespace qualified form * Any subsequent data node name is in the namespace qualified form
if the node is defined in a module other than its parent node, and if the node is defined in a module other than its parent node, and
skipping to change at page 41, line 26 skipping to change at page 42, line 29
78 1c 2F696574662D73797374656D3A73797374656D2F636F6E74616374 78 1c 2F696574662D73797374656D3A73797374656D2F636F6E74616374
*Second example:* *Second example:*
This example is described in Section 6.13.1. This example is described in Section 6.13.1.
CBOR diagnostic notation (the line break is inserted for exposition CBOR diagnostic notation (the line break is inserted for exposition
only): only):
"/ietf-system:system/authentication/user[name='bob']/ "/ietf-system:system/authentication/user[name='bob']/
authorized-key[name='admin']/key-data" authorized-key[name='admin'][country='france']/key-data"
CBOR encoding: CBOR encoding:
78 59 78 6B
2F696574662D73797374656D3A73797374656D2F61757468656E74696361 2F696574662D73797374656D3A73797374656D2F61757468656E74696361
74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A 74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A
65642D6B65795B6E616D653D2761646D696E275D2F6B65792D64617461 65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27
6672616E6365275D2F6B65792D64617461
*Third example:* *Third example:*
This example is described in Section 6.13.1. This example is described in Section 6.13.1.
CBOR diagnostic notation: CBOR diagnostic notation:
"/ietf-system:system/authentication/user[name='jack']" "/ietf-system:system/authentication/user[name='jack']"
CBOR encoding: CBOR encoding:
78 33 78 33
2F696574662D73797374656D3A73797374656D2F61757468656E74696361 2F696574662D73797374656D3A73797374656D2F61757468656E74696361
74696F6E2F757365725B6E616D653D27626F62275D 74696F6E2F757365725B6E616D653D27626F62275D
7. Content-Types 7. Content-Types
This specification defines the media-type "application/yang- This specification defines the media-type application/yang-data+cbor,
data+cbor", which can be used without parameters or with the which can be used without parameters or with the parameter id=name or
parameter "id=name" or "id=sid". id=sid.
This media-type represents a CBOR YANG document containing one or This media-type represents a CBOR YANG document containing one or
multiple data node values. Depending on the presence and value of multiple data node values. If the media-type parameter id is
the media-type parameter "id", each data node is identified by its present, depending its value, each data node is identified by its
associated namespace qualified name as defined in Section 3.3 associated namespace qualified name as defined in Section 3.3
("id=name"), by its associated YANG SID (represented as a SID delta (id=name), by its associated YANG SID (represented as a SID delta or
or via tag 47) as defined in Section 3.2 ("id=sid"), or either of via tag 47) as defined in Section 3.2 (id=sid). If no id parameter
these (no "id" parameter given). is given, both forms may be present.
The format of an "application/yang-data+cbor" representation is that The format of an application/yang-data+cbor representation is that of
of a CBOR map, mapping names and/or SIDs (as defined above) into a CBOR map, mapping names and/or SIDs (as defined above) into
instance values (using the rules defined in Section 4). instance values (using the rules defined in Section 4).
It is not foreseen at this point that the valid set of values for the It is not foreseen at this point that the valid set of values for the
"id" parameter will extend beyond "name", "sid", or being unset; if id parameter will extend beyond name, sid, or being unset; if that
that does happen, any new value is foreseen to be of the form does happen, any new value is foreseen to be of the form
"[a-z][a-z0-9]*(-[a-z0-9]+)*". [a-z][a-z0-9]*(-[a-z0-9]+)*.
In summary, this document defines three content-types, which are
intended for use by different classes of applications:
* application/yang-data+cbor; id=sid -- for use by applications that
need to be frugal with encoding space and text string processing
(e.g., applications running on constrained nodes [RFC7228], or
applications with particular performance requirements);
* application/yang-data+cbor; id=name -- for use by applications
that do not want to engage in SID management, and that have ample
resources to manage text-string based item identifiers (e.g.,
applications that directly want to substitute application/
yang.data+json with a more efficient representation without any
other changes);
* application/yang-data+cbor -- 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.
All three content-types are based on the same representation
mechanisms, parts of which are simply not used in the first and
second case.
8. Security Considerations 8. Security Considerations
The security considerations of [RFC8949] and [RFC7950] apply. The security considerations of [RFC8949] and [RFC7950] apply.
This document defines an alternative encoding for data modeled in the This document defines an alternative encoding for data modeled in the
YANG data modeling language. As such, this encoding does not YANG data modeling language. As such, this encoding does not
contribute any new security issues in addition to those identified contribute any new security issues in addition to those identified
for the specific protocol or context for which it is used. for the specific protocol or context for which it is used.
To minimize security risks, software on the receiving side SHOULD To minimize security risks, software on the receiving side SHOULD
reject all messages that do not comply to the rules of this document reject all messages that do not comply to the rules of this document
and reply with an appropriate error message to the sender. and reply with an appropriate error message to the sender.
When SIDs are in use, the interpretation of encoded data not only
relies on having the right YANG modules, but also on having the right
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
[I-D.ietf-core-sid] are RECOMMENDED for this purpose.
9. IANA Considerations 9. IANA Considerations
9.1. Media-Types Registry 9.1. Media-Types Registry
This document adds the following Media-Type to the "Media Types" This document adds the following Media-Type to the "Media Types"
registry. registry.
+================+============================+===========+ +================+============================+===========+
| Name | Template | Reference | | Name | Template | Reference |
+================+============================+===========+ +================+============================+===========+
| yang-data+cbor | application/yang-data+cbor | RFC XXXX | | yang-data+cbor | application/yang-data+cbor | RFC XXXX |
+----------------+----------------------------+-----------+ +----------------+----------------------------+-----------+
Table 2 Table 2
// RFC Ed.: please replace RFC XXXX with this RFC number and remove // RFC Ed.: please replace RFC XXXX with this RFC number and remove
this note. this note.
Type name: application Type name: application
Subtype name: yang-data+cbor Subtype name: yang-data+cbor
Required parameters: none Required parameters: N/A
Optional parameters: id (see Section 7 of RFC XXXX) Optional parameters: id (see Section 7 of RFC XXXX)
Encoding considerations: binary (CBOR) Encoding considerations: binary (CBOR)
Security considerations: see Section 8 of RFC XXXX Security considerations: see Section 8 of RFC XXXX
Published specification: RFC XXXX Published specification: RFC XXXX
Person & email address to contact for further information: CORE WG Person & email address to contact for further information: CORE WG
mailing list (core@ietf.org), or IETF Applications and Real-Time mailing list (core@ietf.org), or IETF Applications and Real-Time
Area (art@ietf.org) Area (art@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
9.2. CoAP Content-Formats Registry 9.2. CoAP Content-Formats Registry
This document adds the following Content-Format to the "CoAP Content- This document adds the following Content-Format to the "CoAP Content-
Formats", within the "Constrained RESTful Environments (CoRE) Formats", within the "Constrained RESTful Environments (CoRE)
Parameters" registry, where TBD3 comes from the "Expert Review" 0-255 Parameters" registry, where TBD3 comes from the "Expert Review" 0-255
range and TBD1 and TBD2 come from the "IETF Review" 256-9999 range. range and TBD1 and TBD2 come from the "IETF Review" 256-9999 range.
skipping to change at page 44, line 12 skipping to change at page 45, line 37
Table 3 Table 3
// RFC Ed.: please replace TBDx with assigned IDs, remove the // RFC Ed.: please replace TBDx with assigned IDs, remove the
requested ranges, and remove this note. requested ranges, and remove this note.
// RFC Ed.: please replace RFC XXXX with this RFC number and remove // RFC Ed.: please replace RFC XXXX with this RFC number and remove
this note. this note.
9.3. CBOR Tags Registry 9.3. CBOR Tags Registry
This specification requires the assignment of CBOR tags for the In the registry "CBOR Tags" [IANA.cbor-tags], as per Section 9.2 of
following YANG datatypes. These tags are added to the CBOR Tags [RFC8949], IANA has allocated the CBOR tags in Table 4 for the YANG
Registry as defined in Section 9.2 of [RFC8949]. datatypes listed.
+=====+==================+=============================+===========+ +=====+==================+============================+===========+
| Tag | Data Item | Semantics | Reference | | Tag | Data Item | Semantics | Reference |
+=====+==================+=============================+===========+ +=====+==================+============================+===========+
| 43 | text string | YANG bits datatype | RFC XXXX | | 43 | text string | YANG bits datatype; see | RFC XXXX |
+-----+------------------+-----------------------------+-----------+ | | | Section 6.7 | |
| | | ; see Section 6.7. | | +-----+------------------+----------------------------+-----------+
+-----+------------------+-----------------------------+-----------+ | 44 | text string | YANG enumeration datatype; | RFC XXXX |
| 44 | text string | YANG enumeration datatype | RFC XXXX | | | | see Section 6.6. | |
+-----+------------------+-----------------------------+-----------+ +-----+------------------+----------------------------+-----------+
| | | ; see Section 6.6. | | | 45 | unsigned integer | YANG identityref datatype; | RFC XXXX |
+-----+------------------+-----------------------------+-----------+ | | or text string | see Section 6.10. | |
| 45 | unsigned integer | YANG identityref datatype | RFC XXXX | +-----+------------------+----------------------------+-----------+
+-----+------------------+-----------------------------+-----------+ | 46 | unsigned integer | YANG instance-identifier | RFC XXXX |
| | or text string | ; see Section 6.10 | | | | or text string | datatype; see | |
+-----+------------------+-----------------------------+-----------+ | | or array | Section 6.13. | |
| 46 | unsigned integer | YANG instance-identifier | RFC XXXX | +-----+------------------+----------------------------+-----------+
+-----+------------------+-----------------------------+-----------+ | 47 | unsigned integer | YANG Schema Item | RFC XXXX |
| | or text string | datatype; see Section 6.13. | RFC XXXX | | | | iDentifier (SID); see | |
+-----+------------------+-----------------------------+-----------+ | | | Section 3.2. | |
| | or array | | | +-----+------------------+----------------------------+-----------+
+-----+------------------+-----------------------------+-----------+
| 47 | unsigned integer | YANG Schema Item iDentifier | |
+-----+------------------+-----------------------------+-----------+
| | | (SID); see Section 3.2. | RFC XXXX |
+-----+------------------+-----------------------------+-----------+
Table 4 Table 4: CBOR tags defined by this specification
// RFC Ed.: please replace RFC XXXX with RFC number and remove this // RFC Ed.: please replace RFC XXXX with RFC number and remove this
note note
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 46, line 6 skipping to change at page 47, line 34
10.2. Informative References 10.2. Informative References
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
I. Petrov, "CoAP Management Interface (CORECONF)", Work in I. Petrov, "CoAP Management Interface (CORECONF)", Work in
Progress, Internet-Draft, draft-ietf-core-comi-11, 17 Progress, Internet-Draft, draft-ietf-core-comi-11, 17
January 2021, <https://www.ietf.org/archive/id/draft-ietf- January 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-comi-11.txt>. core-comi-11.txt>.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item Veillette, M., Pelov, A., Petrov, I., and C. Bormann,
iDentifier (YANG SID)", Work in Progress, Internet-Draft, "YANG Schema Item iDentifier (YANG SID)", Work in
draft-ietf-core-sid-15, 17 January 2021, Progress, Internet-Draft, draft-ietf-core-sid-16, 24 June
<https://www.ietf.org/archive/id/draft-ietf-core-sid- 2021, <https://www.ietf.org/archive/id/draft-ietf-core-
15.txt>. sid-16.txt>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
skipping to change at page 47, line 22 skipping to change at page 49, line 4
Email: michel.veillette@trilliantinc.com Email: michel.veillette@trilliantinc.com
Ivaylo Petrov (editor) Ivaylo Petrov (editor)
Google Switzerland GmbH Google Switzerland GmbH
Brandschenkestrasse 110 Brandschenkestrasse 110
CH-8002 Zurich CH-8002 Zurich
Switzerland Switzerland
Email: ivaylopetrov@google.com Email: ivaylopetrov@google.com
Alexander Pelov Alexander Pelov
Acklio Acklio
1137A avenue des Champs Blancs 1137A avenue des Champs Blancs
35510 Cesson-Sevigne 35510 Cesson-Sevigne
France France
Email: a@ackl.io Email: a@ackl.io
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
 End of changes. 56 change blocks. 
186 lines changed or deleted 257 lines changed or added

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