< draft-ietf-core-yang-cbor-14.txt		draft-ietf-core-yang-cbor-15.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: July 21, 2021 A. Pelov		Expires: 28 July 2021 Google Switzerland GmbH
			A. Pelov
	Acklio		Acklio
	January 17, 2021		24 January 2021
	CBOR Encoding of Data Modeled with YANG		CBOR Encoding of Data Modeled with YANG
	draft-ietf-core-yang-cbor-14		draft-ietf-core-yang-cbor-15
	Abstract		Abstract
	This document defines encoding rules for serializing configuration		This document defines encoding rules for serializing configuration
	data, state data, RPC input and RPC output, action input, action		data, state data, RPC input and RPC output, action input, action
	output, notifications and yang-data extension defined within YANG		output, notifications and yang-data extension defined within YANG
	modules using the Concise Binary Object Representation (CBOR, RFC		modules using the Concise Binary Object Representation (CBOR, RFC
	7049).		8949).
	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 July 21, 2021.		This Internet-Draft will expire on 28 July 2021.
	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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . 6		3.2. YANG Schema Item iDentifier . . . . . . . . . . . . . . . 8
	3.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Encoding of YANG Schema Node Instances . . . . . . . . . . . 9		4. Encoding of YANG Schema Node Instances . . . . . . . . . . . 10
	4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 9		4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 10
	4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 9		4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 11
	4.2. The 'container' and other nodes from the data tree . . . 10		4.2. The 'container' and other nodes from the data tree . . . 11
	4.2.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 11		4.2.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 12
	4.2.2. Using names in keys . . . . . . . . . . . . . . . . . 12		4.2.2. Using names in keys . . . . . . . . . . . . . . . . . 13
	4.3. The 'leaf-list' . . . . . . . . . . . . . . . . . . . . . 13		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 . . . . . . . . . . . . . . . . . 14		4.3.2. Using names in keys . . . . . . . . . . . . . . . . . 15
	4.4. The 'list' and 'list' instance(s) . . . . . . . . . . . . 15		4.4. The 'list' and 'list' instance(s) . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 35		6.11. The 'empty' Type . . . . . . . . . . . . . . . . . . . . 36
	6.12. The 'union' Type . . . . . . . . . . . . . . . . . . . . 36		6.12. The 'union' Type . . . . . . . . . . . . . . . . . . . . 37
	6.13. The 'instance-identifier' Type . . . . . . . . . . . . . 37		6.13. The 'instance-identifier' Type . . . . . . . . . . . . . 38
	6.13.1. SIDs as instance-identifier . . . . . . . . . . . . 37		6.13.1. SIDs as instance-identifier . . . . . . . . . . . . 38
	6.13.2. Names as instance-identifier . . . . . . . . . . . . 40		6.13.2. Names as instance-identifier . . . . . . . . . . . . 41
	7. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 42		7. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 43
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 42		8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	9.1. Media-Types Registry . . . . . . . . . . . . . . . . . . 42		9.1. Media-Types Registry . . . . . . . . . . . . . . . . . . 43
	9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43		9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 44
	9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 43		9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 44
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	11.1. Normative References . . . . . . . . . . . . . . . . . . 44		11.1. Normative References . . . . . . . . . . . . . . . . . . 45
	11.2. Informative References . . . . . . . . . . . . . . . . . 44		11.2. Informative References . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		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) [RFC7049]. The resulting		Concise Binary Object Representation (CBOR) [RFC8949]. The resulting
	encoding is more compact compared to XML and JSON and more suitable		encoding is more compact compared to XML and JSON and more suitable
	for Constrained Nodes and/or Constrained Networks as defined by		for Constrained Nodes and/or Constrained Networks as defined by
	[RFC7228].		[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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		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]:
	o action		* action
	o anydata		* anydata
	o anyxml		* anyxml
	o data node
	o data tree		* data node
	o datastore		* data tree
	o feature		* datastore
	o identity		* feature
	o module		* identity
	o notification		* module
	o RPC		* notification
	o schema node		* RPC
	o schema tree		* schema node
	o submodule		* schema tree
			* submodule
	The following terms are defined in [RFC8040]:		The following terms are defined in [RFC8040]:
	o yang-data extension		* yang-data extension
	This specification also makes use of the following terminology:		This specification also makes use of the following terminology:
	o 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, an action output.		action input, an action output.
	o 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.
	o item: A schema node, an identity, a module, a submodule or a		* item: A schema node, an identity, a module, a submodule or a
	feature defined using the YANG modeling language.		feature defined using the YANG modeling language.
	o 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.
	o 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.
	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
	their subtrees.		their subtrees.
	A node from the data tree such as container, list instance,		A node from the data tree such as container, list instance,
	notification, RPC input, RPC output, action input and action output		notification, RPC input, RPC output, action input and action output
	is serialized using a CBOR map in which each child schema node is		is serialized using a CBOR map in which each child schema node is
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 33 ¶
	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 those natively
	supported by CBOR. For instance, CBOR tags are used solely in the		supported by CBOR. For instance, CBOR tags are used solely in the
	case of SID not encoded as delta, anyxml schema nodes and the union		case of SID not encoded as delta, anyxml schema nodes and the union
	datatype to distinguish explicitly the use of different YANG		datatype to distinguish explicitly the use of different YANG
	datatypes encoded using the same CBOR major type.		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 lengths encoding as defined in
	[RFC7049] section 2.2 SHALL be supported by CBOR decoders.		Section 3.2 of [RFC8949] SHALL be supported by CBOR decoders.
	Data nodes implemented using a CBOR array, map, byte string, and text		Data nodes implemented using a CBOR array, map, byte string, and 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 node are serialized using the rules defined by this		When schema node 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 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	Examples in Section 4 include a root CBOR map with a single entry		Examples in Section 4 include a root CBOR map with a single entry
	having a key set to either a namespace qualified name or a SID. This		having a key set to either a namespace qualified name or a SID. This
	root CBOR map is provided only as a typical usage example and is not		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		part of the present encoding rules. Only the value within this CBOR
	map is compulsory.		map is compulsory.
	3.1. CBOR diagnostic notation		3.1. CBOR diagnostic notation
	Within this document, CBOR binary contents are represented using an		Within this document, CBOR binary contents are represented using an
	equivalent textual form called CBOR diagnostic notation as defined in		equivalent textual form called CBOR diagnostic notation as defined in
	[RFC7049] section 6. This notation is used strictly for		Section 8 of [RFC8949]. This notation is used strictly for
	documentation purposes and is never used in the data serialization.		documentation purposes and is never used in the data serialization.
	Table 1 below provides a summary of this notation.		Table 1 below provides a summary of this notation.
	+----------+------+--------------------------+-----------+----------+		+==========+======+====================+===========+==========+
	| CBOR | CBOR | Diagnostic notation | Example | CBOR |		| CBOR | CBOR | Diagnostic | Example | CBOR |
	| content | type | | | encoding |		| content | type | notation | | encoding |
	+----------+------+--------------------------+-----------+----------+		+==========+======+====================+===========+==========+
	| Unsigned | 0 | Decimal digits | 123 | 18 7B |		| Unsigned | 0 | Decimal digits | 123 | 18 7B |
	| integer | | | | |		| integer | | | | |
	| Negative | 1 | Decimal digits prefixed | -123 | 38 7A |		+----------+------+--------------------+-----------+----------+
	| integer | | by a minus sign | | |		| Negative | 1 | Decimal digits | -123 | 38 7A |
	| Byte | 2 | Hexadecimal value | h'F15C' | 42 F15C |		| integer | | prefixed by a | | |
	| string | | enclosed between single | | |		| | | minus sign | | |
	| | | quotes and prefixed by | | |		+----------+------+--------------------+-----------+----------+
	| | | an 'h' | | |		| Byte | 2 | Hexadecimal value | h'F15C' | 42 F15C |
	| Text | 3 | String of Unicode | "txt" | 63 |		| string | | enclosed between | | |
	| string | | characters enclosed | | 747874 |		| | | single quotes and | | |
	| | | between double quotes | | |		| | | prefixed by an 'h' | | |
	| Array | 4 | Comma-separated list of | [ 1, 2 ] | 82 01 02 |		+----------+------+--------------------+-----------+----------+
	| | | values within square | | |		| Text | 3 | String of Unicode | "txt" | 63 |
	| | | brackets | | |		| string | | characters | | 747874 |
	| Map | 5 | Comma-separated list of | { 1: 123, | A2 |		| | | enclosed between | | |
	| | | key : value pairs within | 2: 456 } | 01187B |		| | | double quotes | | |
	| | | curly braces | | 021901C8 |		+----------+------+--------------------+-----------+----------+
	| Boolean | 7/20 | false | false | F4 |		| Array | 4 | Comma-separated | [ 1, 2 ] | 82 01 02 |
	| | 7/21 | true | true | F5 |		| | | list of values | | |
	| Null | 7/22 | null | null | F6 |		| | | within square | | |
	| Not | 7/23 | undefined | undefined | F7 |		| | | brackets | | |
	| assigned | | | | |		+----------+------+--------------------+-----------+----------+
	+----------+------+--------------------------+-----------+----------+		| Map | 5 | Comma-separated | { 1: 123, | A2 |
			| | | list of key : | 2: 456 } | 01187B |
			| | | value pairs within | | 021901C8 |
			| | | curly braces | | |
			+----------+------+--------------------+-----------+----------+
			| Boolean | 7/20 | false | false | F4 |
			+----------+------+--------------------+-----------+----------+
			| | 7/21 | true | true | F5 |
			+----------+------+--------------------+-----------+----------+
			| Null | 7/22 | null | null | F6 |
			+----------+------+--------------------+-----------+----------+
			| Not | 7/23 | undefined | undefined | F7 |
			| assigned | | | | |
			+----------+------+--------------------+-----------+----------+
	Table 1: CBOR diagnostic notation summary		Table 1: CBOR diagnostic notation summary
	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 NETCONF [RFC6241] and RESTCONF [RFC8040],		unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040],
	these identifiers are implemented using strings. To allow the		these identifiers are implemented using strings. To allow the
	implementation of data models defined in YANG in constrained devices		implementation of data models defined in YANG in constrained devices
	and constrained networks, a more compact method to identify YANG		and constrained networks, a more compact method to identify YANG
	items is required. This compact identifier, called YANG Schema Item		items is required. This compact identifier, called YANG Schema Item
	iDentifier, is an unsigned integer. The following items are		iDentifier, is an unsigned integer. The following items are
	identified using YANG SIDs (often shortened to SIDs):		identified using YANG SIDs (often shortened to SIDs):
	o identities		* identities
	o data nodes		* data nodes
	o RPCs and associated input(s) and output(s)		* RPCs and associated input(s) and output(s)
	o actions and associated input(s) and output(s)		* actions and associated input(s) and output(s)
	o notifications and associated information		* notifications and associated information
	o YANG modules, submodules and features		* YANG modules, submodules and features
	To minimize their size, SIDs used as keys in inner CBOR maps are		To minimize their size, SIDs used as keys in inner CBOR maps are
	typically encoded using deltas. Conversion from SIDs to deltas and		typically encoded using deltas. Conversion from SIDs to deltas and
	back to SIDs are stateless processes solely based on the data		back to SIDs are stateless processes solely based on the data
	serialized or deserialized. These SIDs may also be encoded as		serialized or deserialized. These SIDs may also be encoded as
	absolute number when enclosed by CBOR tag 47.		absolute number when enclosed by CBOR tag 47.
	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
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 51 ¶
	This specification also supports the encoding of YANG item		This specification also supports the encoding of YANG item
	identifiers as string, similar as those used by the JSON Encoding of		identifiers as string, similar as those used by the JSON Encoding of
	Data Modeled with YANG [RFC7951]. This approach can be used to avoid		Data Modeled with YANG [RFC7951]. This approach can be used to avoid
	the management overhead associated to SIDs allocation. The main		the management overhead associated to SIDs allocation. The main
	drawback is the significant increase in size of the encoded data.		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:
	o 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).
	o 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 (":").
	The name of a module determines the namespace of all YANG items		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		defined in that module. If an item is defined in a submodule, then
	the namespace qualified name uses the name of the main module to		the namespace qualified name uses the name of the main module to
	which the submodule belongs.		which the submodule belongs.
	ABNF syntax [RFC5234] of a name is shown in Figure 1, where the		ABNF syntax [RFC5234] of a name is shown in Figure 1, where the
	production for "identifier" is defined in Section 14 of [RFC7950].		production for "identifier" is defined in Section 14 of [RFC7950].
	name = [identifier ":"] identifier		name = [identifier ":"] identifier
	Figure 1: ABNF Production for a simple or namespace qualified name		Figure 1: ABNF Production for a simple or namespace qualified name
	A namespace qualified name MUST be used for all members of a top-		A namespace qualified name MUST be used for all members of a top-
	level CBOR map and then also whenever the namespaces of the data node		level CBOR map and then also whenever the namespaces of the data node
	and its parent node are different. In all other cases, the simple		and its parent node are different. In all other cases, the simple
	form of the name SHOULD be used.		form of the name SHOULD be used.
	Definition example:		Definition example:
	module example-foomod {		module example-foomod {
	container top {		container top {
	skipping to change at page 9, line 4 ¶		skipping to change at page 10, line 11 ¶
	A valid CBOR encoding of the 'top' container is as follows.		A valid CBOR encoding of the 'top' container is as follows.
	CBOR diagnostic notation:		CBOR diagnostic notation:
	{		{
	"example-foomod:top": {		"example-foomod:top": {
	"foo": 54,		"foo": 54,
	"example-barmod:bar": true		"example-barmod:bar": true
	}		}
	}		}
	Both the 'top' container and the 'bar' leaf defined in a different		Both the 'top' container and the 'bar' leaf defined in a different
	YANG module as its parent container are encoded as namespace		YANG module as its parent container are encoded as namespace
	qualified names. The 'foo' leaf defined in the same YANG module as		qualified names. The 'foo' leaf defined in the same YANG module as
	its parent container is encoded as simple name.		its parent container is encoded as simple name.
	4. Encoding of YANG Schema Node Instances		4. Encoding of YANG Schema Node Instances
	Schema node instances defined using the YANG modeling language are		Schema node instances defined using the YANG modeling language are
	encoded using CBOR [RFC7049] 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 [RFC7049].		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 shows the encoding of a 'hostname' leaf using
	a SID or a name.		a SID or a name.
	Definition example from [RFC7317]:		Definition example from [RFC7317]:
	skipping to change at page 11, line 17 ¶		skipping to change at page 12, line 37 ¶
	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 SIDs.
	In the case of deltas, they MUST be encoded using a CBOR unsigned		In the case of deltas, they MUST be encoded using a CBOR unsigned
	integer (major type 0) or CBOR negative integer (major type 1),		integer (major type 0) or CBOR negative integer (major type 1),
	depending on the actual delta value. In the case of SID, they are		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		encoded using the SID value enclosed by CBOR tag 47 as defined in
	Section 9.3.		Section 9.3.
	Delta values are computed as follows:		Delta values are computed as follows:
	o 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'.
	o 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'.
	o In the case of an 'rpc input' or 'rcp output', deltas are equal to		* In the case of an 'rpc input' or 'rpc output', deltas are equal to
	the SID of the current schema node minus the SID of the 'rpc'.		the SID of the current schema node minus the SID of the 'rpc'.
	o In the case of an 'action input' or 'action output', deltas are		* In the case of an 'action input' or 'action output', deltas are
	equal to the SID of the current schema node minus the SID of the		equal to the SID of the current schema node minus the SID of the
	'action'.		'action'.
	o In the case of an 'notification content', deltas are equal to the		* In the case of an 'notification content', deltas are equal to the
	SID of the current schema node minus the SID of the		SID of the current schema node minus the SID of the
	'notification'.		'notification'.
	CBOR diagnostic notation:		CBOR diagnostic notation:
	{		{
	1720 : { / system-state (SID 1720) /		1720 : { / system-state (SID 1720) /
	1 : { / clock (SID 1721) /		1 : { / clock (SID 1721) /
	2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/		2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
	1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) /		1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) /
	skipping to change at page 21, line 5 ¶		skipping to change at page 22, line 5 ¶
	7461632E6E72632E6361 # "tac.nrc.ca"		7461632E6E72632E6361 # "tac.nrc.ca"
	4.5. The 'anydata'		4.5. The 'anydata'
	An anydata serves as a container for an arbitrary set of schema nodes		An anydata serves as a container for an arbitrary set of schema nodes
	that otherwise appear as normal YANG-modeled data. An anydata		that otherwise appear as normal YANG-modeled data. An anydata
	instance is encoded using the same rules as a container, i.e., CBOR		instance is encoded using the same rules as a container, i.e., CBOR
	map. The requirement that anydata content can be modeled by YANG		map. The requirement that anydata content can be modeled by YANG
	implies the following:		implies the following:
	o CBOR map keys of any inner schema nodes MUST be set to valid		* CBOR map keys of any inner schema nodes MUST be set to valid
	deltas or names.		deltas or names.
	o The CBOR array MUST contain either unique scalar values (as a		* The CBOR array MUST contain either unique scalar values (as a
	leaf-list, see Section 4.3), or maps (as a list, see Section 4.4).		leaf-list, see Section 4.3), or maps (as a list, see Section 4.4).
	o CBOR map values MUST follow the encoding rules of one of the		* CBOR map values MUST follow the encoding rules of one of the
	datatypes listed in Section 4.		datatypes listed in Section 4.
	The following example shows a possible use of an anydata. In this		The following example shows a possible use of an anydata. In this
	example, an anydata is used to define a schema node containing a		example, an anydata is used to define a schema node containing a
	notification event, this schema node can be part of a YANG list to		notification event, this schema node can be part of a YANG list to
	create an event logger.		create an event logger.
	Definition example:		Definition example:
	module event-log {		module event-log {
	skipping to change at page 28, line 44 ¶		skipping to change at page 29, line 44 ¶
	}		}
	}		}
	CBOR diagnostic notation: -300		CBOR diagnostic notation: -300
	CBOR encoding: 39 012B		CBOR encoding: 39 012B
	6.3. The 'decimal64' Type		6.3. The 'decimal64' Type
	Leafs of type decimal64 MUST be encoded using a decimal fraction as		Leafs of type decimal64 MUST be encoded using a decimal fraction as
	defined in [RFC7049] section 2.4.3.		defined in Section 3.4.4 of [RFC8949].
	The following example shows the encoding of a 'my-decimal' leaf		The following example shows the encoding of a 'my-decimal' leaf
	instance set to 2.57.		instance set to 2.57.
	Definition example from [RFC7317]:		Definition example from [RFC7317]:
	leaf my-decimal {		leaf my-decimal {
	type decimal64 {		type decimal64 {
	fraction-digits 2;		fraction-digits 2;
	range "1 .. 3.14 | 10 | 20..max";		range "1 .. 3.14 | 10 | 20..max";
	skipping to change at page 36, line 22 ¶		skipping to change at page 37, line 22 ¶
	CBOR encoding: F6		CBOR encoding: F6
	6.12. The 'union' Type		6.12. The 'union' Type
	Leafs of type union MUST be encoded using the rules associated with		Leafs of type union MUST be encoded using the rules associated with
	one of the types listed. When used in a union, the following YANG		one of the types listed. When used in a union, the following YANG
	datatypes are enclosed by a CBOR tag to avoid confusion between		datatypes are enclosed by a CBOR tag to avoid confusion between
	different YANG datatypes encoded using the same CBOR major type.		different YANG datatypes encoded using the same CBOR major type.
	o bits		* bits
	o enumeration		* enumeration
	o identityref		* identityref
	o instance-identifier		* instance-identifier
	See Section 9.3 for the assigned value of these CBOR tags.		See Section 9.3 for the assigned value of these CBOR tags.
	As mentioned in Section 6.6 and in Section 6.7, 'enumeration' and		As mentioned in Section 6.6 and in Section 6.7, 'enumeration' and
	'bits' are encoded as CBOR text string data item (major type 3) when		'bits' are encoded as CBOR text string data item (major type 3) when
	defined within a 'union' type.		defined within a 'union' type.
	The following example shows the encoding of an 'ip-address' leaf		The following example shows the encoding of an 'ip-address' leaf
	instance when set to "2001:db8:a0b:12f0::1".		instance when set to "2001:db8:a0b:12f0::1".
	skipping to change at page 38, line 16 ¶		skipping to change at page 39, line 16 ¶
	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 nodes member of a YANG list MUST be encoded using a CBOR array		Schema nodes member 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:
	o The first entry MUST be encoded as a CBOR unsigned integer data		* The first entry MUST be encoded as a CBOR unsigned integer data
	item (major type 0) and set to the targeted schema node SID.		item (major type 0) and set to the targeted schema node SID.
	o The following entries MUST contain the value of each key required		* The following entries MUST contain the value of each key required
	to identify the instance of the targeted schema node. These keys		to identify the instance of the targeted schema node. These keys
	MUST be ordered as defined in the 'key' YANG statement, starting		MUST be ordered as defined in the 'key' YANG statement, starting
	from top level list, and follow by each of the subordinate		from top level list, and follow by each of the subordinate
	list(s).		list(s).
	Examples within this section assume the definition of a schema node		Examples within this section assume the definition of a schema node
	of type 'instance-identifier':		of type 'instance-identifier':
	Definition example from [RFC7950]:		Definition example from [RFC7950]:
	skipping to change at page 40, line 38 ¶		skipping to change at page 41, line 38 ¶
	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 string that is
	analogical to the lexical representation in XML encoding; see		analogical to the lexical representation in XML encoding; see
	Section 9.13.2 in [RFC7950]. However, the encoding of namespaces in		Section 9.13.2 in [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:
	o 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.
	o 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
	the simple form is used otherwise. This rule also holds for node		the simple form is used otherwise. This rule also holds for node
	names appearing in predicates.		names appearing in predicates.
	For example,		For example,
	/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip		/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip
	is a valid instance-identifier value because the data nodes		is a valid instance-identifier value because the data nodes
	"interfaces", "interface", and "name" are defined in the module		"interfaces", "interface", and "name" are defined in the module
	"ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip".		"ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip".
	skipping to change at page 42, line 24 ¶		skipping to change at page 43, line 24 ¶
	FORMAT: CBOR map of name, instance-value		FORMAT: CBOR map of name, instance-value
	The message payload of Content-Type 'application/yang-data+cbor'		The message payload of Content-Type 'application/yang-data+cbor'
	is encoded using a CBOR map. Each entry within the CBOR map		is encoded using a CBOR map. Each entry within the CBOR map
	contains the data node identifier (i.e. its namespace qualified		contains the data node identifier (i.e. its namespace qualified
	name) and the associated instance-value. Instance-values are		name) and the associated instance-value. Instance-values are
	encoded using the rules defined in Section 4		encoded using the rules defined in Section 4
	8. Security Considerations		8. Security Considerations
	The security considerations of [RFC7049] 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 of those identified		contribute any new security issues in addition of 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.
	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 |
	+----------------+----------------------------+-----------+		+----------------+----------------------------+-----------+
	// RFC Ed.: replace RFC XXXX with this RFC number and remove this		Table 2
	note.
			// RFC Ed.: please replace RFC XXXX with this RFC number and remove
			this note.
			Type name: application
			Subtype name: yang-data+cbor
			Required parameters: none
			Optional parameters: none
			Encoding considerations: binary (CBOR)
			Security considerations: see Section 8 of RFC XXXX
			Published specification: RFC XXXX
			Person & email address to contact for further information: CORE WG
			mailing list (core@ietf.org), or IETF Applications and Real-Time
			Area (art@ietf.org)
			Intended usage: COMMON
			Restrictions on usage: none
			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.		Parameters" registry.
	+---------------------------------+--------------+------+-----------+		+====================+================+======+===========+
	| Media Type | Content | ID | Reference |		| Media Type | Content Coding | ID | Reference |
	| | Coding | | |		+====================+================+======+===========+
	+---------------------------------+--------------+------+-----------+		| application/yang- | | TBD1 | RFC XXXX |
	| application/yang-data+cbor; | | TBD1 | RFC XXXX |		| data+cbor; id=name | | | |
	| id=name | | | |		+--------------------+----------------+------+-----------+
	+---------------------------------+--------------+------+-----------+
	// RFC Ed.: replace TBD1 with assigned IDs and remove this note. //		Table 3
	RFC Ed.: replace RFC XXXX with this RFC number and remove this note.
			// RFC Ed.: please replace TBD1 with assigned IDs and remove this
			note. // RFC Ed.: please replace RFC XXXX with this RFC number and
			remove this note.
	9.3. CBOR Tags Registry		9.3. CBOR Tags Registry
	This specification requires the assignment of CBOR tags for the		This specification requires the assignment of CBOR tags for the
	following YANG datatypes. These tags are added to the CBOR Tags		following YANG datatypes. These tags are added to the CBOR Tags
	Registry as defined in section 7.2 of [RFC7049].		Registry as defined in Section 9.2 of [RFC8949].
	+-----+------------------+-----------------------------+-----------+		+=====+==================+=============================+===========+
	| Tag | Data Item | Semantics | Reference |		| Tag | Data Item | Semantics | Reference |
	+-----+------------------+-----------------------------+-----------+		+=====+==================+=============================+===========+
	| 43 | text string | YANG bits datatype | [this] |		| 43 | text string | YANG bits datatype | [this] |
			+-----+------------------+-----------------------------+-----------+
	| | | ; see Section 6.7. | |		| | | ; see Section 6.7. | |
			+-----+------------------+-----------------------------+-----------+
	| 44 | text string | YANG enumeration datatype | [this] |		| 44 | text string | YANG enumeration datatype | [this] |
			+-----+------------------+-----------------------------+-----------+
	| | | ; see Section 6.6. | |		| | | ; see Section 6.6. | |
			+-----+------------------+-----------------------------+-----------+
	| 45 | unsigned integer | YANG identityref datatype | [this] |		| 45 | unsigned integer | YANG identityref datatype | [this] |
			+-----+------------------+-----------------------------+-----------+
	| | or text string | ; see Section 6.10. | |		| | or text string | ; see Section 6.10. | |
			+-----+------------------+-----------------------------+-----------+
	| 46 | unsigned integer | YANG instance-identifier | [this] |		| 46 | unsigned integer | YANG instance-identifier | [this] |
			+-----+------------------+-----------------------------+-----------+
	| | or text string | datatype; see Section 6.13. | [this] |		| | or text string | datatype; see Section 6.13. | [this] |
			+-----+------------------+-----------------------------+-----------+
	| | or array | | |		| | or array | | |
			+-----+------------------+-----------------------------+-----------+
	| 47 | unsigned integer | YANG Schema Item iDentifier | |		| 47 | unsigned integer | YANG Schema Item iDentifier | |
			+-----+------------------+-----------------------------+-----------+
	| | | ; see Section 3.2. | [this] |		| | | ; see Section 3.2. | [this] |
	+-----+------------------+-----------------------------+-----------+		+-----+------------------+-----------------------------+-----------+
	// RFC Ed.: replace [this] with RFC number and remove this note		Table 4
			// RFC Ed.: please replace [this] with RFC number and remove this
			note
	10. Acknowledgments		10. Acknowledgments
	This document has been largely inspired by the extensive works done		This document has been largely inspired by the extensive works done
	by Andy Bierman and Peter van der Stok on [I-D.ietf-core-comi].		by Andy Bierman and Peter van der Stok on [I-D.ietf-core-comi].
	[RFC7951] has also been a critical input to this work. The authors		[RFC7951] has also been a critical input to this work. The authors
	would like to thank the authors and contributors to these two drafts.		would like to thank the authors and contributors to these two drafts.
	The authors would also like to acknowledge the review, feedback, and		The authors would also like to acknowledge the review, feedback, and
	comments from Ladislav Lhotka and Juergen Schoenwaelder.		comments from Ladislav Lhotka and Juergen Schoenwaelder.
	skipping to change at page 44, line 27 ¶		skipping to change at page 46, line 20 ¶
	[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>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
			[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", STD 94, RFC 8949,
			DOI 10.17487/RFC8949, December 2020,
			<https://www.rfc-editor.org/info/rfc8949>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-core-comi]		[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.		Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
	Petrov, "CoAP Management Interface (CORECONF)", draft-		Petrov, "CoAP Management Interface (CORECONF)", Work in
	ietf-core-comi-10 (work in progress), July 2020.		Progress, Internet-Draft, draft-ietf-core-comi-11, 17
			January 2021, <http://www.ietf.org/internet-drafts/draft-
			ietf-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., and I. Petrov, "YANG Schema Item
	iDentifier (YANG SID)", draft-ietf-core-sid-14 (work in		iDentifier (YANG SID)", Work in Progress, Internet-Draft,
	progress), July 2020.		draft-ietf-core-sid-15, 17 January 2021,
			<http://www.ietf.org/internet-drafts/draft-ietf-core-sid-
			15.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 45, line 45 ¶		skipping to change at page 47, line 47 ¶
	[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
	RFC 8344, DOI 10.17487/RFC8344, March 2018,		RFC 8344, DOI 10.17487/RFC8344, March 2018,
	<https://www.rfc-editor.org/info/rfc8344>.		<https://www.rfc-editor.org/info/rfc8344>.
	Authors' Addresses		Authors' Addresses
	Michel Veillette (editor)		Michel Veillette (editor)
	Trilliant Networks Inc.		Trilliant Networks Inc.
	610 Rue du Luxembourg		610 Rue du Luxembourg
	Granby, Quebec J2J 2V2		Granby Quebec J2J 2V2
	Canada		Canada
	Email: michel.veillette@trilliantinc.com		Email: michel.veillette@trilliantinc.com
	Ivaylo Petrov (editor)		Ivaylo Petrov (editor)
	Acklio		Google Switzerland GmbH
	1137A avenue des Champs Blancs		Brandschenkestrasse 110
	Cesson-Sevigne, Bretagne 35510		CH-8002 Zurich
	France		Switzerland
	Email: ivaylo@ackl.io		Email: ivaylopetrov@google.com
	Alexander Pelov		Alexander Pelov
	Acklio		Acklio
	1137A avenue des Champs Blancs		1137A avenue des Champs Blancs
	Cesson-Sevigne, Bretagne 35510		35510 Cesson-Sevigne
	France		France
	Email: a@ackl.io		Email: a@ackl.io
End of changes. 87 change blocks.
	177 lines changed or deleted		228 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/