< draft-ietf-core-comi-09.txt   draft-ietf-core-comi-10.txt >
CoRE M. Veillette, Ed. CoRE M. Veillette, Ed.
Internet-Draft Trilliant Networks Inc. Internet-Draft Trilliant Networks Inc.
Intended status: Standards Track P. van der Stok, Ed. Intended status: Standards Track P. van der Stok, Ed.
Expires: September 10, 2020 consultant Expires: January 5, 2021 consultant
A. Pelov A. Pelov
Acklio Acklio
A. Bierman A. Bierman
YumaWorks YumaWorks
I. Petrov, Ed. I. Petrov, Ed.
Acklio Acklio
March 09, 2020 July 04, 2020
CoAP Management Interface CoAP Management Interface (CORECONF)
draft-ietf-core-comi-09 draft-ietf-core-comi-10
Abstract Abstract
This document describes a network management interface for This document describes a network management interface for
constrained devices and networks, called CoAP Management Interface constrained devices and networks, called CoAP Management Interface
(CoMI). The Constrained Application Protocol (CoAP) is used to (CORECONF). The Constrained Application Protocol (CoAP) is used to
access datastore and data node resources specified in YANG, or SMIv2 access datastore and data node resources specified in YANG, or SMIv2
converted to YANG. CoMI uses the YANG to CBOR mapping and converts converted to YANG. CORECONF uses the YANG to CBOR mapping and
YANG identifier strings to numeric identifiers for payload size converts YANG identifier strings to numeric identifiers for payload
reduction. The complete solution composed of CoMI, size reduction. CORECONF extends the set of YANG based protocols,
[I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called CORECONF. NETCONF and RESTCONF, with the capability to manage constrained
CORECONF extends the set of YANG based protocols, NETCONF and devices and networks.
RESTCONF, with the capability to manage constrained devices and
networks.
Note Note
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to yot@ietf.org. be sent to yot@ietf.org.
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 January 5, 2021.
This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CoMI Architecture . . . . . . . . . . . . . . . . . . . . . . 5 2. CORECONF Architecture . . . . . . . . . . . . . . . . . . . . 5
2.1. Major differences between RESTCONF and CORECONF . . . . . 6 2.1. Major differences between RESTCONF and CORECONF . . . . . 6
2.1.1. Differences due to CoAP and its efficient usage . . . 6 2.1.1. Differences due to CoAP and its efficient usage . . . 6
2.1.2. Differences due to the use of CBOR . . . . . . . . . 7 2.1.2. Differences due to the use of CBOR . . . . . . . . . 7
2.2. Compression of YANG identifiers . . . . . . . . . . . . . 7 2.2. Compression of YANG identifiers . . . . . . . . . . . . . 7
2.3. Instance-identifier . . . . . . . . . . . . . . . . . . . 8 2.3. Instance-identifier . . . . . . . . . . . . . . . . . . . 8
2.4. Content-Formats . . . . . . . . . . . . . . . . . . . . . 8 2.4. Media-Types . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Unified datastore . . . . . . . . . . . . . . . . . . . . 10 2.5. Unified datastore . . . . . . . . . . . . . . . . . . . . 10
3. Example syntax . . . . . . . . . . . . . . . . . . . . . . . 11 3. Example syntax . . . . . . . . . . . . . . . . . . . . . . . 11
4. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 11 4. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Using the 'k' Uri-Query option . . . . . . . . . . . . . 13 4.1. Using the 'k' query parameter . . . . . . . . . . . . . . 13
4.2. Data Retrieval . . . . . . . . . . . . . . . . . . . . . 14 4.2. Data Retrieval . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Using the 'c' Uri-Query option . . . . . . . . . . . 14 4.2.1. Using the 'c' query parameter . . . . . . . . . . . . 15
4.2.2. Using the 'd' Uri-Query option . . . . . . . . . . . 15 4.2.2. Using the 'd' query parameter . . . . . . . . . . . . 16
4.2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Data Editing . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Data Editing . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. Data Ordering . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Data Ordering . . . . . . . . . . . . . . . . . . . . 20
4.3.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.4. iPATCH . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.4. iPATCH . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Full datastore access . . . . . . . . . . . . . . . . . . 23 4.4. Full datastore access . . . . . . . . . . . . . . . . . . 24
4.4.1. Full datastore examples . . . . . . . . . . . . . . . 24 4.4.1. Full datastore examples . . . . . . . . . . . . . . . 24
4.5. Event stream . . . . . . . . . . . . . . . . . . . . . . 25
4.5.1. Notify Examples . . . . . . . . . . . . . . . . . . . 26
4.5.2. The 'f' query parameter . . . . . . . . . . . . . . . 27
4.5. Event stream . . . . . . . . . . . . . . . . . . . . . . 24
4.5.1. Notify Examples . . . . . . . . . . . . . . . . . . . 25
4.5.2. The 'f' Uri-Query option . . . . . . . . . . . . . . 26
4.6. RPC statements . . . . . . . . . . . . . . . . . . . . . 27 4.6. RPC statements . . . . . . . . . . . . . . . . . . . . . 27
4.6.1. RPC Example . . . . . . . . . . . . . . . . . . . . . 27 4.6.1. RPC Example . . . . . . . . . . . . . . . . . . . . . 28
5. Use of Block-wise Transfers . . . . . . . . . . . . . . . . . 29 5. Use of Block-wise Transfers . . . . . . . . . . . . . . . . . 30
6. Application Discovery . . . . . . . . . . . . . . . . . . . . 29 6. Application Discovery . . . . . . . . . . . . . . . . . . . . 30
6.1. YANG library . . . . . . . . . . . . . . . . . . . . . . 29 6.1. YANG library . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 30 6.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 31
6.2.1. Datastore Resource Discovery . . . . . . . . . . . . 30 6.2.1. Datastore Resource Discovery . . . . . . . . . . . . 31
6.2.2. Data node Resource Discovery . . . . . . . . . . . . 31 6.2.2. Data node Resource Discovery . . . . . . . . . . . . 32
6.2.3. Event stream Resource Discovery . . . . . . . . . . . 31 6.2.3. Event stream Resource Discovery . . . . . . . . . . . 32
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9.1. Resource Type (rt=) Link Target Attribute Values Registry 35 9.1. Resource Type (rt=) Link Target Attribute Values Registry 37
9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 36 9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 37
9.3. Media Types Registry . . . . . . . . . . . . . . . . . . 36 9.3. Media Types Registry . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 9.4. YANG Namespace Registration . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
Appendix A. ietf-comi YANG module . . . . . . . . . . . . . . . 40 11.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix B. ietf-comi .sid file . . . . . . . . . . . . . . . . 46 Appendix A. ietf-coreconf YANG module . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix B. ietf-coreconf .sid file . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is designed for The Constrained Application Protocol (CoAP) [RFC7252] is designed for
Machine to Machine (M2M) applications such as smart energy, smart Machine to Machine (M2M) applications such as smart energy, smart
city and building control. Constrained devices need to be managed in city, and building control. Constrained devices need to be managed
an automatic fashion to handle the large quantities of devices that in an automatic fashion to handle the large quantities of devices
are expected in future installations. Messages between devices need that are expected in future installations. Messages between devices
to be as small and infrequent as possible. The implementation need to be as small and infrequent as possible. The implementation
complexity and runtime resources need to be as small as possible. complexity and runtime resources need to be as small as possible.
This draft describes the CoAP Management Interface which uses CoAP This draft describes the CoAP Management Interface which uses CoAP
methods to access structured data defined in YANG [RFC7950]. This methods to access structured data defined in YANG [RFC7950]. This
draft is complementary to [RFC8040] which describes a REST-like draft is complementary to [RFC8040] which describes a REST-like
interface called RESTCONF, which uses HTTP methods to access interface called RESTCONF, which uses HTTP methods to access
structured data defined in YANG. structured data defined in YANG.
The use of standardized data models specified in a standardized The use of standardized data models specified in a standardized
language, such as YANG, promotes interoperability between devices and language, such as YANG, promotes interoperability between devices and
skipping to change at page 4, line 21 skipping to change at page 4, line 17
to minimize CBOR payloads and URI length. to minimize CBOR payloads and URI length.
1.1. Terminology 1.1. Terminology
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 the YANG data modelling language The following terms are defined in the YANG data modeling language
[RFC7950]: action, anydata, anyxml, client, container, data model, [RFC7950]: action, anydata, anyxml, client, container, data model,
data node, identity, instance identifier, leaf, leaf-list, list, data node, identity, instance identifier, leaf, leaf-list, list,
module, RPC, schema node, server, submodule. module, RPC, schema node, server, submodule.
The following terms are defined in [RFC6241]: configuration data, The following terms are defined in [RFC6241]: configuration data,
datastore, state data datastore, state data
The following term is defined in [I-D.ietf-core-sid]: YANG schema The following term is defined in [I-D.ietf-core-sid]: YANG schema
item identifier (SID). item identifier (YANG SID, often shorten to simply SID).
The following terms are defined in the CoAP protocol [RFC7252]: The following terms are defined in the CoAP protocol [RFC7252]:
Confirmable Message, Content-Format, Endpoint. Confirmable Message, Content-Format, Endpoint.
The following terms are defined in this document: The following terms are defined in this document:
data node resource: a CoAP resource that models a YANG data node. data node resource: a CoAP resource that models a YANG data node.
datastore resource: a CoAP resource that models a YANG datastore. datastore resource: a CoAP resource that models a YANG datastore.
skipping to change at page 5, line 18 skipping to change at page 5, line 14
within a container. This excludes data nodes defined within a within a container. This excludes data nodes defined within a
list or any children of these data nodes. list or any children of these data nodes.
instance-identifier: List instance identifier or single instance instance-identifier: List instance identifier or single instance
identifier. identifier.
instance-value: The value assigned to a data node instance. instance-value: The value assigned to a data node instance.
Instance-values are serialized into the payload according to the Instance-values are serialized into the payload according to the
rules defined in section 4 of [I-D.ietf-core-yang-cbor]. rules defined in section 4 of [I-D.ietf-core-yang-cbor].
2. CoMI Architecture 2. CORECONF Architecture
This section describes the CoMI architecture to use CoAP for reading This section describes the CORECONF architecture to use CoAP for
and modifying the content of datastore(s) used for the management of reading and modifying the content of datastore(s) used for the
the instrumented node. management of the instrumented node.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| SMIv2 specification (optional) (2) | | SMIv2 specification (optional) (2) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| |
V V
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| YANG specification (1) | | YANG specification (1) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| | | |
skipping to change at page 5, line 46 skipping to change at page 5, line 42
| Confirm |<-- CoAP response(3)<--| Response (4) | | Confirm |<-- CoAP response(3)<--| Response (4) |
| | | | | | | |
| |<==== Security (7) ===>|+---------------------+| | |<==== Security (7) ===>|+---------------------+|
+----------------+ || Datastore(s) (5) || +----------------+ || Datastore(s) (5) ||
|+---------------------+| |+---------------------+|
|+---------------------+| |+---------------------+|
|| Event stream(s) (6) || || Event stream(s) (6) ||
|+---------------------+| |+---------------------+|
+-----------------------+ +-----------------------+
Figure 1: Abstract CoMI architecture Figure 1: Abstract CORECONF architecture
Figure 1 is a high-level representation of the main elements of the Figure 1 is a high-level representation of the main elements of the
CoMI management architecture. The different numbered components of CORECONF management architecture. The different numbered components
Figure 1 are discussed according to component number. of Figure 1 are discussed according to the component number.
(1) YANG specification: contains a set of named and versioned (1) YANG specification: contains a set of named and versioned
modules. modules.
(2) SMIv2 specification: Optional part that consists of a named (2) SMIv2 specification: Optional part that consists of a named
module which, specifies a set of variables and "conceptual module which, specifies a set of variables and "conceptual
tables". There is an algorithm to translate SMIv2 specifications tables". There is an algorithm to translate SMIv2 specifications
to YANG specifications. to YANG specifications.
(3) CoAP request/response messages: The CoMI client sends request (3) CoAP request/response messages: The CORECONF client sends
messages to and receives response messages from the CoMI server. request messages to and receives response messages from the
CORECONF server.
(4) Request, Indication, Response, Confirm: Processes performed by (4) Request, Indication, Response, Confirm: Processes performed by
the CoMI clients and servers. the CORECONF clients and servers.
(5) Datastore: A resource used to access configuration data, state (5) Datastore: A resource used to access configuration data, state
data, RPCs and actions. A CoMI server may support a single data, RPCs, and actions. A CORECONF server may support a single
unified datastore or multiple datastores as those defined by unified datastore or multiple datastores as those defined by
Network Management Datastore Architecture (NMDA) [RFC8342]. Network Management Datastore Architecture (NMDA) [RFC8342].
(6) Event stream: A resource used to get real time notifications. A (6) Event stream: A resource used to get real-time notifications. A
CoMI server may support multiple Event streams serving different CORECONF server may support multiple Event streams serving
purposes such as normal monitoring, diagnostic, syslog, security different purposes such as normal monitoring, diagnostic, syslog,
monitoring. security monitoring.
(7) Security: The server MUST prevent unauthorized users from (7) Security: The server MUST prevent unauthorized users from
reading or writing any CoMI resources. CoMI relies on security reading or writing any CORECONF resources. CORECONF relies on
protocols such as DTLS [RFC6347] or OSCOAP [RFC8613] to secure security protocols such as DTLS [RFC6347] or OSCORE [RFC8613] to
CoAP communications. secure CoAP communications.
2.1. Major differences between RESTCONF and CORECONF 2.1. Major differences between RESTCONF and CORECONF
CORECONF is a RESTful protocol for small devices where saving bytes CORECONF is a RESTful protocol for small devices where saving bytes
to transport counts. Contrary to RESTCONF, many design decisions are to transport a message is very important. Contrary to RESTCONF, many
motivated by the saving of bytes. Consequently, CORECONF is not a design decisions are motivated by the saving of bytes. Consequently,
RESTCONF over CoAP protocol, but differs more significantly from CORECONF is not a RESTCONF over CoAP protocol, but differs more
RESTCONF. significantly from RESTCONF.
2.1.1. Differences due to CoAP and its efficient usage 2.1.1. Differences due to CoAP and its efficient usage
o CORECONF uses CoAP/UDP as transport protocol and CBOR as payload o CORECONF uses CoAP/UDP as transport protocol and CBOR as payload
format [I-D.ietf-core-yang-cbor]. RESTCONF uses HTTP/TCP as format [I-D.ietf-core-yang-cbor]. RESTCONF uses HTTP/TCP as
transport protocol and JSON or XML as payload formats. transport protocol and JSON or XML as payload formats.
o CORECONF uses the methods FETCH and iPATCH to access multiple data o CORECONF uses the methods FETCH and iPATCH to access multiple data
nodes. RESTCONF uses instead the HTTP method PATCH and the HTTP nodes. RESTCONF uses instead the HTTP method PATCH and the HTTP
method GET with the "fields" Query parameter. method GET with the "fields" Query parameter.
skipping to change at page 7, line 27 skipping to change at page 7, line 24
o CORECONF encodes YANG identifier strings as numbers, where o CORECONF encodes YANG identifier strings as numbers, where
RESTCONF does not. RESTCONF does not.
o CORECONF also differ in the handling of default values, only o CORECONF also differ in the handling of default values, only
'report-all' and 'trim' options are supported. 'report-all' and 'trim' options are supported.
2.2. Compression of YANG identifiers 2.2. Compression of YANG identifiers
In the YANG specification, items are identified with a name string. In the YANG specification, items are identified with a name string.
In order to significantly reduce the size of identifiers used in In order to significantly reduce the size of identifiers used in
CoMI, numeric identifiers called YANG Schema Item iDentifier (SID) CORECONF, numeric identifiers called YANG Schema Item iDentifier
are used instead. (YANG SID or simply SID) are used instead.
When used in a URI, SIDs are encoded using base64 encoding of the SID When used in a URI, SIDs are encoded using base64 encoding of the SID
bytes. The base64 encoding is using the URL and Filename safe bytes. The base64 encoding is using the URL and Filename safe
alphabet as defined by [RFC4648] section 5, without padding. The alphabet as defined by [RFC4648] section 5, without padding. The
last 6 bits encoded is always aligned with the least significant 6 last 6 bits encoded is always aligned with the least significant 6
bits of the SID represented using an unsigned integer. 'A' bits of the SID represented using an unsigned integer. 'A'
characters (value 0) at the start of the resulting string are characters (value 0) at the start of the resulting string are
removed. See Figure 2 for complete illustration. removed. See Figure 2 for complete illustration.
SID in base64 = URLsafeChar[SID >> 60 & 0x3F] | SID in base64 = URLsafeChar[SID >> 60 & 0x3F] |
skipping to change at page 8, line 17 skipping to change at page 8, line 17
URLsafeChar[1721 >> 48 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 48 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 42 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 42 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 36 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 36 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 30 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 30 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 24 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 24 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 18 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 18 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 12 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 12 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 6 & 0x3F] = URLsafeChar[26] = 'a' URLsafeChar[1721 >> 6 & 0x3F] = URLsafeChar[26] = 'a'
URLsafeChar[1721 & 0x3F] = URLsafeChar[57] = '5' URLsafeChar[1721 & 0x3F] = URLsafeChar[57] = '5'
The resulting base64 representation of SID 1721 is "a5" The resulting base64 representation of SID 1721 is the two-character
string "a5".
2.3. Instance-identifier 2.3. Instance-identifier
Instance-identifiers are used to uniquely identify data node Instance-identifiers are used to uniquely identify data node
instances within a datastore. This YANG built-in type is defined in instances within a datastore. This YANG built-in type is defined in
[RFC7950] section 9.13. An instance-identifier is composed of the [RFC7950] section 9.13. An instance-identifier is composed of the
data node identifier (i.e. a SID) and for data nodes within list(s) data node identifier (i.e. a SID) and for data nodes within list(s)
the keys used to index within these list(s). the keys used to index within these list(s).
When part of a payload, instance-identifiers are encoded in CBOR When part of a payload, instance-identifiers are encoded in CBOR
based on the rules defined in [I-D.ietf-core-yang-cbor] section based on the rules defined in [I-D.ietf-core-yang-cbor] section
6.13.1. When part of a URI, the SID is appended to the URI of the 6.13.1. When part of a URI, the SID is appended to the URI of the
targeted datastore, the keys are specified using the 'k' URI-Query as targeted datastore, the keys are specified using the 'k' query
defined in Section 4.1. parameter as defined in Section 4.1.
2.4. Content-Formats 2.4. Media-Types
CoMI uses Content-Formats based on the YANG to CBOR mapping specified CORECONF uses Media-Types based on the YANG to CBOR mapping specified
in [I-D.ietf-core-yang-cbor]. in [I-D.ietf-core-yang-cbor].
The following Content-formats are defined: The following Media-Type is used as defined in [I-D.ietf-core-sid].
application/yang-data+cbor: This Content-Format represents a CBOR
YANG document containing one or multiple data node values. Each
data node is identified by its associated SID.
FORMAT: CBOR map of SID, instance-value o application/yang-data+cbor; id=sid
The message payload of Content-Format 'application/yang-data+cbor' The following new Media-Types are defined in this document:
is encoded using a CBOR map. Each entry within the CBOR map
contains the data node identifier (i.e. SID) and the associated
instance-value. Instance-values are encoded using the rules
defined in [I-D.ietf-core-yang-cbor] section 4.
application/yang-identifiers+cbor: This Content-Format represents a application/yang-identifiers+cbor: This Media-Type represents a CBOR
CBOR YANG document containing a list of instance-identifier used YANG document containing a list of instance-identifier used to
to target specific data node instances within a datastore. target specific data node instances within a datastore.
FORMAT: CBOR array of instance-identifier FORMAT: CBOR array of instance-identifier
The message payload of Content-Format 'application/yang- The message payload of Media-Type 'application/yang-
identifiers+cbor' is encoded using a CBOR array. Each entry of identifiers+cbor' is encoded using a CBOR array. Each entry of
this CBOR array contain an instance-identifier encoded as defined this CBOR array contain an instance-identifier encoded as defined
in [I-D.ietf-core-yang-cbor] section 6.13.1. in [I-D.ietf-core-yang-cbor] section 6.13.1.
application/yang-instances+cbor: This Content-Format represents a application/yang-instances+cbor: This Media-Type represents a CBOR
CBOR YANG document containing a list of data node instances. Each YANG document containing a list of data node instances. Each data
data node instance is identified by its associated instance- node instance is identified by its associated instance-identifier.
identifier.
FORMAT: CBOR array of CBOR map of instance-identifier, instance- FORMAT: CBOR array of CBOR map of instance-identifier, instance-
value value
The message payload of Content-Format 'application/yang- The message payload of Media-Type 'application/yang-
instances+cbor' is encoded using a CBOR array. Each entry within instances+cbor' is encoded using a CBOR array. Each entry within
this CBOR array contains a CBOR map carrying an instance- this CBOR array contains a CBOR map carrying an instance-
identifier and associated instance-value. Instance-identifiers identifier and associated instance-value. Instance-identifiers
are encoded using the rules defined in [I-D.ietf-core-yang-cbor] are encoded using the rules defined in [I-D.ietf-core-yang-cbor]
section 6.13.1, instance-values are encoded using the rules section 6.13.1, instance-values are encoded using the rules
defined in [I-D.ietf-core-yang-cbor] section 4. defined in [I-D.ietf-core-yang-cbor] section 4.
When present in an iPATCH request payload, this Content-Format When present in an iPATCH request payload, this Media-Type carry a
carry a list of data node instances to be replaced, created, or list of data node instances to be replaced, created, or deleted.
deleted. For each data node instance D, for which the instance- For each data node instance D, for which the instance-identifier
identifier is the same as a data node instance I, in the targeted is the same as a data node instance I, in the targeted datastore
datastore resource: the value of D replaces the value of I. When resource: the value of D replaces the value of I. When the value
the value of D is null, the data node instance I is removed. When of D is null, the data node instance I is removed. When the
the targeted datastore resource does not contain a data node targeted datastore resource does not contain a data node instance
instance with the same instance-identifier as D, a new instance is with the same instance-identifier as D, a new instance is created
created with the same instance-identifier and value as D. with the same instance-identifier and value as D.
The different Content-format usages are summarized in the table The different Media-Type usages are summarized in the table below:
below:
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
| Method | Resource | Content-Format | | Method | Resource | Media-Type |
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
| GET response | data node | /application/yang-data+cbor | | GET response | data node | application/yang-data+cbor; id=sid |
| | | | | | | |
| PUT request | data node | /application/yang-data+cbor | | PUT request | data node | application/yang-data+cbor; id=sid |
| | | | | | | |
| POST request | data node | /application/yang-data+cbor | | POST request | data node | application/yang-data+cbor; id=sid |
| | | | | | | |
| DELETE | data node | n/a | | DELETE | data node | n/a |
| | | | | | | |
| GET response | datastore | /application/yang-data+cbor | | GET response | datastore | application/yang-data+cbor; id=sid |
| | | | | | | |
| PUT request | datastore | /application/yang-data+cbor | | PUT request | datastore | application/yang-data+cbor; id=sid |
| | | | | | | |
| POST request | datastore | /application/yang-data+cbor | | POST request | datastore | application/yang-data+cbor; id=sid |
| | | | | | | |
| FETCH request | datastore | /application/yang-identifiers+cbor | | FETCH request | datastore | application/yang-identifiers+cbor |
| | | | | | | |
| FETCH | datastore | /application/yang-instances+cbor | | FETCH | datastore | application/yang-instances+cbor |
| response | | | | response | | |
| | | | | | | |
| iPATCH | datastore | /application/yang-instances+cbor | | iPATCH | datastore | application/yang-instances+cbor |
| request | | | | request | | |
| | | | | | | |
| GET response | event stream | /application/yang-instances+cbor | | GET response | event stream | application/yang-instances+cbor |
| | | | | | | |
| POST request | rpc, action | /application/yang-data+cbor | | POST request | rpc, action | application/yang-data+cbor; id=sid |
| | | | | | | |
| POST response | rpc, action | /application/yang-data+cbor | | POST response | rpc, action | application/yang-data+cbor; id=sid |
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
2.5. Unified datastore 2.5. Unified datastore
CoMI supports a simple datastore model consisting of a single unified CORECONF supports a simple datastore model consisting of a single
datastore. This datastore provides access to both configuration and unified datastore. This datastore provides access to both
operational data. Configuration updates performed on this datastore configuration and operational data. Configuration updates performed
are reflected immediately or with a minimal delay as operational on this datastore are reflected immediately or with a minimal delay
data. as operational data.
Alternatively, CoMI servers MAY implement a more complex datastore Alternatively, CORECONF servers MAY implement a more complex
model such as the Network Management Datastore Architecture (NMDA) as datastore model such as the Network Management Datastore Architecture
defined by [RFC8342]. Each datastore supported is implemented as a (NMDA) as defined by [RFC8342]. Each datastore supported is
datastore resource. implemented as a datastore resource.
Characteristics of the unified datastore are summarized in the table Characteristics of the unified datastore are summarized in the table
below: below:
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Name | Value | | Name | Value |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Name | unified | | Name | unified |
| | | | | |
| YANG | all modules | | YANG | all modules |
skipping to change at page 11, line 22 skipping to change at page 11, line 22
| | | | | |
| YANG nodes | all data nodes ("config true" and "config false") | | YANG nodes | all data nodes ("config true" and "config false") |
| | | | | |
| Access | read-write | | Access | read-write |
| | | | | |
| How applied | changes applied in place immediately or with a | | How applied | changes applied in place immediately or with a |
| | minimal delay | | | minimal delay |
| | | | | |
| Protocols | CORECONF | | Protocols | CORECONF |
| | | | | |
| Defined in | "ietf-comi" | | Defined in | "ietf-coreconf" |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
3. Example syntax 3. Example syntax
CBOR is used to encode CoMI request and response payloads. The CBOR CBOR is used to encode CORECONF request and response payloads. The
syntax of the YANG payloads is specified in [RFC7049]. The payload CBOR syntax of the YANG payloads is specified in [RFC7049]. The
examples are notated in Diagnostic notation (defined in section 6 of payload examples are notated in Diagnostic notation (defined in
[RFC7049]) that can be automatically converted to CBOR. section 6 of [RFC7049]) that can be automatically converted to CBOR.
SIDs in URIs are represented as a base64 number, SIDs in the payload SIDs in URIs are represented as a base64 number, SIDs in the payload
are represented as decimal numbers. are represented as decimal numbers.
4. CoAP Interface 4. CoAP Interface
This note specifies a Management Interface. CoAP endpoints that This note specifies a Management Interface. CoAP endpoints that
implement the CoMI management protocol, support at least one implement the CORECONF management protocol, support at least one
discoverable management resource of resource type (rt): core.c.ds, discoverable management resource of resource type (rt): core.c.ds.
with example path: /c, where c is short-hand for CoMI/CORECONF. The The path of the discoverable management resource is left to
path /c is recommended, but not compulsory (see Section 6). implementers to select (see Section 6).
The mapping of YANG data node instances to CoMI resources is as The mapping of YANG data node instances to CORECONF resources is as
follows. Every data node of the YANG modules loaded in the CoMI follows. Every data node of the YANG modules loaded in the CORECONF
server represents a sub-resource of the datastore resource (e.g. /c/ server represents a sub-resource of the datastore resource (e.g. /c/
sid). When multiple instances of a list exist, instance selection is YANGSID). When multiple instances of a list exist, instance
possible as described in Section 4.1, Section 4.2.3.1, and selection is possible as described in Section 4.1, Section 4.2.3.1,
Section 4.2.4. and Section 4.2.4.
CoMI also supports event stream resources used to observe CORECONF also supports event stream resources used to observe
notification instances. Event stream resources can be discovered notification instances. Event stream resources can be discovered
using resource type (rt): core.c.ev. using resource type (rt): core.c.ev.
The description of the CoMI management interface is shown in the The description of the CORECONF management interface is shown in the
table below: table below:
+----------------------+------------------+-----------+ +------------------------------+--------------+-----------+
| CoAP resource | Recommended path | rt | | CoAP resource | Example path | rt |
+----------------------+------------------+-----------+ +------------------------------+--------------+-----------+
| Datastore resource | /c | core.c.ds | | Datastore resource | /c | core.c.ds |
| | | | | | | |
| Data node resource | /c/SID | core.c.dn | | Data node resource | /c/YANGSID | core.c.dn |
| | | | | | | |
| Event steam resource | /s | core.c.ev | | Default event steam resource | /s | core.c.ev |
+----------------------+------------------+-----------+ +------------------------------+--------------+-----------+
The path values in the table are the recommended ones. On discovery, The path values in the table are example ones. On discovery, the
the server makes the actual path values known for these resources. server makes the actual path values known for these resources.
The methods used by CoMI are: The methods used by CORECONF are:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Operation | Description | | Operation | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| GET | Retrieve the datastore resource or a data node | | GET | Retrieve the datastore resource or a data node |
| | resource | | | resource |
| | | | | |
| FETCH | Retrieve specific data nodes within a datastore | | FETCH | Retrieve specific data nodes within a datastore |
| | resource | | | resource |
| | | | | |
skipping to change at page 12, line 44 skipping to change at page 12, line 44
| | | | | |
| PUT | Create or replace a datastore resource or a data node | | PUT | Create or replace a datastore resource or a data node |
| | resource | | | resource |
| | | | | |
| iPATCH | Idem-potently create, replace, and delete data node | | iPATCH | Idem-potently create, replace, and delete data node |
| | resource(s) within a datastore resource | | | resource(s) within a datastore resource |
| | | | | |
| DELETE | Delete a datastore resource or a data node resource | | DELETE | Delete a datastore resource or a data node resource |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
There is one Uri-Query option for the GET, PUT, POST, and DELETE There is at most one instance of the 'k' query parameter for YANG
methods. list element selection for the GET, PUT, POST, and DELETE methods.
Having multiple instances of that query parameter shall be treated as
an error.
+-----------------+----------------------------------------+
| Query parameter | Description |
+-----------------+----------------------------------------+
| k | Select an instance within YANG list(s) |
+-----------------+----------------------------------------+
+------------------+----------------------------------------+
| Uri-Query option | Description |
+------------------+----------------------------------------+
| k | Select an instance within YANG list(s) |
+------------------+----------------------------------------+
This parameter is not used for FETCH and iPATCH, because their This parameter is not used for FETCH and iPATCH, because their
request payloads support list instance selection. request payloads support list instance selection.
4.1. Using the 'k' Uri-Query option 4.1. Using the 'k' query parameter
The "k" (key) parameter specifies a specific instance of a data node. The 'k' (key) parameter specifies a specific instance of a data node.
The SID in the URI is followed by the (?k=key1,key2,...). Where SID The SID in the URI is followed by the (?k=key1,key2,...). Where SID
identifies a data node, and key1, key2 are the values of the key identifies a data node, and key1, key2 are the values of the key
leaves that specify an instance. Lists can have multiple keys, and leaves that specify an instance. Lists can have multiple keys, and
lists can be part of lists. The order of key value generation is lists can be part of lists. The order of key value generation is
given recursively by: given recursively by:
o For a given list, if a parent data node is a list, generate the o For a given list, if a parent data node is a list, generate the
keys for the parent list first. keys for the parent list first.
o For a given list, generate key values in the order specified in o For a given list, generate key values in the order specified in
skipping to change at page 14, line 6 skipping to change at page 14, line 34
| identityref | int2str(key) | | identityref | int2str(key) |
| | | | | |
| union | urlSafeBase64(CBORencode(key)) | | union | urlSafeBase64(CBORencode(key)) |
| | | | | |
| instance-identifier | urlSafeBase64(CBORencode(key)) | | instance-identifier | urlSafeBase64(CBORencode(key)) |
+-----------------------------+--------------------------------+ +-----------------------------+--------------------------------+
In this table: In this table:
o The method int2str() is used to convert an integer value to a o The method int2str() is used to convert an integer value to a
decimal string. For example, int2str(0x0123) return the string decimal string. For example, int2str(0x0123) return the three-
"291". character string "291".
o The boolean values false and true are represented as the single-
character strings "0" and "1" respectively.
o The method urlSafeBase64() is used to convert a binary string to o The method urlSafeBase64() is used to convert a binary string to
base64 using the URL and Filename safe alphabet as defined by base64 using the URL and Filename safe alphabet as defined by
[RFC4648] section 5, without padding. For example, [RFC4648] section 5, without padding. For example,
urlSafeBase64(\xF9\x56\xA1\x3C) return the string "-VahPA". urlSafeBase64(0xF956A13C) return the six-character string
"-VahPA".
o The method CBORencode() is used to convert a YANG value to CBOR as o The method CBORencode() is used to convert a YANG value to CBOR as
specified in [I-D.ietf-core-yang-cbor] section 6. specified in [I-D.ietf-core-yang-cbor] section 6.
The resulting key string is encoded in a Uri-Query as specified in The resulting key strings are joined using commas between every two
[RFC7252] section 6.5. consecutive key values to produce the value of the 'k' parameter.
4.2. Data Retrieval 4.2. Data Retrieval
One or more data nodes can be retrieved by the client. The operation One or more data nodes can be retrieved by the client. The operation
is mapped to the GET method defined in section 5.8.1 of [RFC7252] and is mapped to the GET method defined in section 5.8.1 of [RFC7252] and
to the FETCH method defined in section 2 of [RFC8132]. to the FETCH method defined in section 2 of [RFC8132].
There are two additional Uri-Query options for the GET and FETCH There are two additional query parameters for the GET and FETCH
methods. methods.
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Uri-Query | Description | | query | Description |
| option | | | parameters | |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| c | Control selection of configuration and non- | | c | Control selection of configuration and non- |
| | configuration data nodes (GET and FETCH) | | | configuration data nodes (GET and FETCH) |
| | | | | |
| d | Control retrieval of default values. | | d | Control retrieval of default values. |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
4.2.1. Using the 'c' Uri-Query option 4.2.1. Using the 'c' query parameter
The 'c' (content) option controls how descendant nodes of the The 'c' (content) option controls how descendant nodes of the
requested data nodes will be processed in the reply. requested data nodes will be processed in the reply.
The allowed values are: The allowed values are:
+-------+-----------------------------------------------------+ +-------+-----------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------+ +-------+-----------------------------------------------------+
| c | Return only configuration descendant data nodes | | c | Return only configuration descendant data nodes |
| | | | | |
| n | Return only non-configuration descendant data nodes | | n | Return only non-configuration descendant data nodes |
| | | | | |
| a | Return all descendant data nodes | | a | Return all descendant data nodes |
+-------+-----------------------------------------------------+ +-------+-----------------------------------------------------+
This option is only allowed for GET and FETCH methods on datastore This option is only allowed for GET and FETCH methods on datastore
and data node resources. A 4.02 (Bad Option) error is returned if and data node resources. A 4.02 (Bad Option) error is returned if
used for other methods or resource types. used for other methods or resource types.
If this Uri-Query option is not present, the default value is "a". If this query parameter is not present, the default value is "a" (the
quotes are added for readability, but they are not part of the
payload).
4.2.2. Using the 'd' Uri-Query option 4.2.2. Using the 'd' query parameter
The "d" (with-defaults) option controls how the default values of the The 'd' (with-defaults) option controls how the default values of the
descendant nodes of the requested data nodes will be processed. descendant nodes of the requested data nodes will be processed.
The allowed values are: The allowed values are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| a | All data nodes are reported. Defined as 'report-all' in | | a | All data nodes are reported. Defined as 'report-all' in |
| | section 3.1 of [RFC6243]. | | | section 3.1 of [RFC6243]. |
| | | | | |
skipping to change at page 15, line 47 skipping to change at page 16, line 31
If the target of a GET or FETCH method is a data node that represents If the target of a GET or FETCH method is a data node that represents
a leaf that has a default value, and the leaf has not been given a a leaf that has a default value, and the leaf has not been given a
value by any client yet, the server MUST return the default value of value by any client yet, the server MUST return the default value of
the leaf. the leaf.
If the target of a GET method is a data node that represents a If the target of a GET method is a data node that represents a
container or list that has child resources with default values, and container or list that has child resources with default values, and
these have not been given value yet, these have not been given value yet,
The server MUST NOT return the child resource if d= 't' The server MUST NOT return the child resource if d=t
The server MUST return the child resource if d= 'a'. The server MUST return the child resource if d=a.
If this Uri-Query option is not present, the default value is 't'. If this query parameter is not present, the default value is "t" (the
quotes are added for readability, but they are not part of the
payload).
4.2.3. GET 4.2.3. GET
A request to read the value of a data node instance is sent with a A request to read the value of a data node instance is sent with a
CoAP GET message. The URI is set to the data node resource CoAP GET message. The URI is set to the data node resource
requested, the 'k' Uri-Query option is added if the data node is an requested, the 'k' query parameter is added if any of the parents of
instance of a list. the requested data node is a list node.
FORMAT: FORMAT:
GET <data node resource> ['k' Uri-Query option] GET <data node resource> ['k' Uri-Query option]
2.05 Content (Content-Format: application/yang-data+cbor) 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
The returned payload contains the CBOR encoding of the requested The returned payload contains the CBOR encoding of the requested
instance-value. instance-value.
4.2.3.1. GET Examples 4.2.3.1. GET Examples
Using for example the current-datetime leaf from module ietf-system Using, for example, the current-datetime leaf from module ietf-system
[RFC7317], a request is sent to retrieve the value of 'system- [RFC7317], a request is sent to retrieve the value of 'system-
state/clock/current-datetime'. The SID of 'system-state/clock/ state/clock/current-datetime'. The SID of 'system-state/clock/
current-datetime' is 1723, encoded in base64 according to current-datetime' is 1723, encoded in base64 according to
Section 2.2, yields a7. The response to the request returns the CBOR Section 2.2, yields a7. The response to the request returns the CBOR
map with the key set to the SID of the requested data node (i.e. map with the key set to the SID of the requested data node (i.e.
1723) and the value encoded using a 'text string' as defined in 1723) and the value encoded using a 'text string' as defined in
[I-D.ietf-core-yang-cbor] section 6.4. [I-D.ietf-core-yang-cbor] section 6.4. The datastore resource path
/c is an example location discovered with a request similar to
Figure 4.
REQ: GET example.com/c/a7 REQ: GET </c/a7>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1723 : "2014-10-26T12:16:31Z" 1723 : "2014-10-26T12:16:31Z"
} }
The next example represents the retrieval of a YANG container. In The next example represents the retrieval of a YANG container. In
this case, the CoMI client performs a GET request on the clock this case, the CORECONF client performs a GET request on the clock
container (SID = 1721; base64: a5). The container returned is container (SID = 1721; base64: a5). The container returned is
encoded using a CBOR map as specified by [I-D.ietf-core-yang-cbor] encoded using a CBOR map as specified by [I-D.ietf-core-yang-cbor]
section 4.2. section 4.2.
REQ: GET example.com/c/a5 REQ: GET </c/a5>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1721 : { 1721 : {
2 : "2014-10-26T12:16:51Z", / current-datetime (SID 1723) / 2 : "2014-10-26T12:16:51Z", / current-datetime (SID 1723) /
1 : "2014-10-21T03:00:00Z" / boot-datetime (SID 1722) / 1 : "2014-10-21T03:00:00Z" / boot-datetime (SID 1722) /
} }
} }
Figure 3 Figure 3
This example shows the retrieval of the /interfaces/interface YANG This example shows the retrieval of the /interfaces/interface YANG
list accessed using SID 1533 (base64: X9). The return payload is list accessed using SID 1533 (base64: X9). The return payload is
encoded using a CBOR array as specified by [I-D.ietf-core-yang-cbor] encoded using a CBOR array as specified by [I-D.ietf-core-yang-cbor]
section 4.4.1 containing 2 instances. section 4.4.1 containing 2 instances.
REQ: GET example.com/c/X9 REQ: GET </c/X9>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1533 : [ 1533 : [
{ {
4 : "eth0", / name (SID 1537) / 4 : "eth0", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type, (SID 1538) identity / 5 : 1880, / type, (SID 1538) identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
}, },
{ {
4 : "eth1", / name (SID 1537) / 4 : "eth1", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type, (SID 1538) identity / 5 : 1880, / type, (SID 1538) identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : false / enabled (SID 1535) / 2 : false / enabled (SID 1535) /
} }
] ]
} }
To retrieve a specific instance within the /interfaces/interface YANG To retrieve a specific instance within the /interfaces/interface YANG
list, the CoMI client adds the key of the targeted instance in its list, the CORECONF client adds the key of the targeted instance in
CoAP request using the 'k' URI-Query. The return payload containing its CoAP request using the 'k' query parameter. The return payload
the instance requested is encoded using a CBOR array as specified by containing the instance requested is encoded using a CBOR array as
[I-D.ietf-core-yang-cbor] section 4.4.1 containing the requested specified by [I-D.ietf-core-yang-cbor] section 4.4.1 containing the
instance. requested instance.
REQ: GET example.com/c/X9?k="eth0" REQ: GET </c/X9?k=eth0>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1533 : [ 1533 : [
{ {
4 : "eth0", / name (SID 1537) / 4 : "eth0", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type, (SID 1538) identity / 5 : 1880, / type, (SID 1538) identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
} }
] ]
} }
It is equally possible to select a leaf of a specific instance of a It is equally possible to select a leaf of a specific instance of a
list. The example below requests the description leaf (SID 1534, list. The example below requests the description leaf (SID 1534,
base64: X-) within the interface list corresponding to the interface base64: X-) within the interface list corresponding to the interface
name "eth0". The returned value is encoded in CBOR based on the name "eth0". The returned value is encoded in CBOR based on the
rules specified by [I-D.ietf-core-yang-cbor] section 6.4. rules specified by [I-D.ietf-core-yang-cbor] section 6.4.
REQ: GET example.com/c/X-?k="eth0" REQ: GET </c/X-?k=eth0>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1534 : "Ethernet adaptor" 1534 : "Ethernet adaptor"
} }
4.2.4. FETCH 4.2.4. FETCH
The FETCH is used to retrieve multiple instance-values. The FETCH The FETCH is used to retrieve multiple instance-values. The FETCH
request payload contains the list of instance-identifier of the data request payload contains the list of instance-identifier of the data
node instances requested. node instances requested.
The return response payload contains a list of data node instance- The return response payload contains a list of data node instance-
values in the same order as requested. A CBOR null is returned for values in the same order as requested. A CBOR null is returned for
each data node requested by the client, not supported by the server each data node requested by the client, not supported by the server
or not currently instantiated. or not currently instantiated.
For compactness, indexes of the list instance identifiers returned by For compactness, indexes of the list instance identifiers returned by
the FETCH response SHOULD be elided, only the SID is provided. This the FETCH response SHOULD be elided, only the SID is provided. This
appraoch may also help reducing implementations complexity since the approach may also help reducing implementations complexity since the
format of each entry within the CBOR array of the FETCH response is format of each entry within the CBOR array of the FETCH response is
identical to the format of the corresponding GET response. identical to the format of the corresponding GET response.
FORMAT: FORMAT:
FETCH <datastore resource> FETCH <datastore resource>
(Content-Format: application/yang-identifiers+cbor) (Content-Format: application/yang-identifiers+cbor)
CBOR array of instance-identifier CBOR array of instance-identifier
2.05 Content (Content-Format: application/yang-instances+cbor) 2.05 Content (Content-Format: application/yang-instances+cbor)
CBOR array of CBOR map of SID, instance-value CBOR array of CBOR map of SID, instance-value
4.2.4.1. FETCH examples 4.2.4.1. FETCH examples
This example uses the current-datetime leaf from module ietf-system This example uses the current-datetime leaf from module ietf-system
[RFC7317] and the interface list from module ietf-interfaces [RFC7317] and the interface list from module ietf-interfaces
[RFC7223]. In this example the value of current-datetime (SID 1723) [RFC7223]. In this example the value of current-datetime (SID 1723)
and the interface list (SID 1533) instance identified with and the interface list (SID 1533) instance identified with
name="eth0" are queried. name="eth0" are queried.
REQ: FETCH /c (Content-Format: application/yang-identifiers+cbor) REQ: FETCH </c>
(Content-Format: application/yang-identifiers+cbor)
[ [
1723, / current-datetime (SID 1723) / 1723, / current-datetime (SID 1723) /
[1533, "eth0"] / interface (SID 1533) with name = "eth0" / [1533, "eth0"] / interface (SID 1533) with name = "eth0" /
] ]
RES: 2.05 Content (Content-Format: application/yang-instances+cbor) RES: 2.05 Content (Content-Format: application/yang-instances+cbor)
[ [
{ {
1723 : "2014-10-26T12:16:31Z" / current-datetime (SID 1723) / 1723 : "2014-10-26T12:16:31Z" / current-datetime (SID 1723) /
}, },
skipping to change at page 19, line 45 skipping to change at page 20, line 30
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type (SID 1538), identity / 5 : 1880, / type (SID 1538), identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
} }
} }
] ]
4.3. Data Editing 4.3. Data Editing
CoMI allows datastore contents to be created, modified and deleted CORECONF allows datastore contents to be created, modified and
using CoAP methods. deleted using CoAP methods.
4.3.1. Data Ordering 4.3.1. Data Ordering
A CoMI server MUST preserve the relative order of all user-ordered A CORECONF server MUST preserve the relative order of all user-
list and leaf-list entries that are received in a single edit ordered list and leaf-list entries that are received in a single edit
request. These YANG data node types are encoded as CBOR arrays so request. These YANG data node types are encoded as CBOR arrays so
messages will preserve their order. messages will preserve their order.
4.3.2. POST 4.3.2. POST
The CoAP POST operation is used in CoMI for creation of data node The CoAP POST operation is used in CORECONF for the creation of data
resources and the invocation of "ACTION" and "RPC" resources. Refer node resources and the invocation of "ACTION" and "RPC" resources.
to Section 4.6 for details on "ACTION" and "RPC" resources. Refer to Section 4.6 for details on "ACTION" and "RPC" resources.
A request to create a data node instance is sent with a CoAP POST A request to create a data node instance is sent with a CoAP POST
message. The URI specifies the data node resource of the instance to message. The URI specifies the data node resource of the instance to
be created. In the case of a list instance, keys MUST be present in be created. In the case of a list instance, keys MUST be present in
the paylaod. the payload.
FORMAT: FORMAT:
POST <data node resource> POST <data node resource>
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
2.01 Created 2.01 Created
If the data node instance already exists, then the POST request MUST If the data node instance already exists, then the POST request MUST
fail and a "4.09 Conflict" response code MUST be returned fail and a "4.09 Conflict" response code MUST be returned
4.3.2.1. Post example 4.3.2.1. Post example
The example uses the interface list from module ietf-interfaces The example uses the interface list from module ietf-interfaces
[RFC7223]. This example creates a new list instance within the [RFC7223]. This example creates a new list instance within the
interface list (SID = 1533): interface list (SID = 1533), while assuming the datastore resource is
hosted on the CoAP server with DNS name example.com and with path
/ds. The path /ds is an example location that is assumed to have
been discovered using request similar to Figure 4.
REQ: POST /c/X9 (Content-Format: application/yang-data+cbor) REQ: POST <coap://example.com/ds/X9>
(Content-Format: application/yang-data+cbor; id=sid)
{ {
1533 : [ 1533 : [
{ {
4 : "eth5", / name (SID 1537) / 4 : "eth5", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type (SID 1538), identity / 5 : 1880, / type (SID 1538), identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
} }
] ]
skipping to change at page 21, line 13 skipping to change at page 21, line 48
RES: 2.01 Created RES: 2.01 Created
4.3.3. PUT 4.3.3. PUT
A data node resource instance is created or replaced with the PUT A data node resource instance is created or replaced with the PUT
method. A request to set the value of a data node instance is sent method. A request to set the value of a data node instance is sent
with a CoAP PUT message. with a CoAP PUT message.
FORMAT: FORMAT:
PUT <data node resource> ['k' Uri-Query option] PUT <data node resource> ['k' Uri-Query option]
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
2.01 Created 2.01 Created
4.3.3.1. PUT example 4.3.3.1. PUT example
The example uses the interface list from module ietf-interfaces The example uses the interface list from module ietf-interfaces
[RFC7223]. This example updates the instance of the list interface [RFC7223]. This example updates the instance of the list interface
(SID = 1533) with key name="eth0": (SID = 1533) with key name="eth0". The example location /c is an
example location that is discovered using a request similar to
Figure 4.
REQ: PUT /c/X9?k="eth0" (Content-Format: application/yang-data+cbor) REQ: PUT </c/X9?k=eth0>
(Content-Format: application/yang-data+cbor; id=sid)
{ {
1533 : [ 1533 : [
{ {
4 : "eth0", / name (SID 1537) / 4 : "eth0", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type (SID 1538), identity / 5 : 1880, / type (SID 1538), identity /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
} }
] ]
} }
RES: 2.04 Changed RES: 2.04 Changed
4.3.4. iPATCH 4.3.4. iPATCH
One or multiple data node instances are replaced with the idempotent One or multiple data node instances are replaced with the idempotent
CoAP iPATCH method [RFC8132]. CoAP iPATCH method [RFC8132].
There are no Uri-Query options for the iPATCH method. There are no query parameters for the iPATCH method.
The processing of the iPATCH command is specified by Content-Format The processing of the iPATCH command is specified by Media-Type
'application/yang-instances+cbor'. In summary, if the CBOR patch 'application/yang-instances+cbor'. In summary, if the CBOR patch
payload contains a data node instance that is not present in the payload contains a data node instance that is not present in the
target, this instance is added. If the target contains the specified target, this instance is added. If the target contains the specified
instance, the content of this instance is replaced with the value of instance, the content of this instance is replaced with the value of
the payload. A null value indicates the removal of an existing data the payload. A null value indicates the removal of an existing data
node instance. node instance.
FORMAT: FORMAT:
iPATCH <datastore resource> iPATCH <datastore resource>
(Content-Format: application/yang-instances+cbor) (Content-Format: application/yang-instances+cbor)
CBOR array of CBOR map of instance-identifier, instance-value CBOR array of CBOR map of instance-identifier, instance-value
2.04 Changed 2.04 Changed
4.3.4.1. iPATCH example 4.3.4.1. iPATCH example
In this example, a CoMI client requests the following operations: In this example, a CORECONF client requests the following operations:
o Set "/system/ntp/enabled" (SID 1755) to true. o Set "/system/ntp/enabled" (SID 1755) to true.
o Remove the server "tac.nrc.ca" from the "/system/ntp/server" (SID o Remove the server "tac.nrc.ca" from the "/system/ntp/server" (SID
1756) list. 1756) list.
o Add/set the server "NTP Pool server 2" to the list "/system/ntp/ o Add/set the server "NTP Pool server 2" to the list "/system/ntp/
server" (SID 1756). server" (SID 1756).
REQ: iPATCH /c (Content-Format: application/yang-instances+cbor) REQ: iPATCH </c>
(Content-Format: application/yang-instances+cbor)
[ [
{ {
1755 : true / enabled (SID 1755) / 1755 : true / enabled (SID 1755) /
}, },
{ {
[1756, "tac.nrc.ca"] : null / server (SID 1756) / [1756, "tac.nrc.ca"] : null / server (SID 1756) /
}, },
{ {
1756 : { / server (SID 1756) / 1756 : { / server (SID 1756) /
3 : "tic.nrc.ca", / name (SID 1759) / 3 : "tic.nrc.ca", / name (SID 1759) /
skipping to change at page 23, line 11 skipping to change at page 24, line 5
Delete <data node resource> ['k' Uri-Query option] Delete <data node resource> ['k' Uri-Query option]
2.02 Deleted 2.02 Deleted
4.3.5.1. DELETE example 4.3.5.1. DELETE example
This example uses the interface list from module ietf-interfaces This example uses the interface list from module ietf-interfaces
[RFC7223]. This example deletes an instance of the interface list [RFC7223]. This example deletes an instance of the interface list
(SID = 1533): (SID = 1533):
REQ: DELETE /c/X9?k="eth0" REQ: DELETE </c/X9?k=eth0>
RES: 2.02 Deleted RES: 2.02 Deleted
4.4. Full datastore access 4.4. Full datastore access
The methods GET, PUT, POST, and DELETE can be used to request, The methods GET, PUT, POST, and DELETE can be used to request,
replace, create, and delete a whole datastore respectively. replace, create, and delete a whole datastore respectively.
FORMAT: FORMAT:
GET <datastore resource> GET <datastore resource>
2.05 Content (Content-Format: application/yang-data+cbor) 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
FORMAT: FORMAT:
PUT <datastore resource> PUT <datastore resource>
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
2.04 Changed 2.04 Changed
FORMAT: FORMAT:
POST <datastore resource> POST <datastore resource>
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
2.01 Created 2.01 Created
FORMAT: FORMAT:
DELETE <datastore resource> DELETE <datastore resource>
2.02 Deleted 2.02 Deleted
The content of the CBOR map represents the complete datastore of the The content of the CBOR map represents the complete datastore of the
server at the GET indication of after a successful processing of a server at the GET indication of after a successful processing of a
PUT or POST request. PUT or POST request.
4.4.1. Full datastore examples 4.4.1. Full datastore examples
The example uses the interface list from module ietf-interfaces The example uses the interface list from module ietf-interfaces
[RFC7223] and the clock container from module ietf-system [RFC7317]. [RFC7223] and the clock container from module ietf-system [RFC7317].
We assume that the datastore contains two modules ietf-system (SID We assume that the datastore contains two modules ietf-system (SID
1700) and ietf-interfaces (SID 1500); they contain the 'interface' 1700) and ietf-interfaces (SID 1500); they contain the 'interface'
list (SID 1533) with one instance and the 'clock' container (SID list (SID 1533) with one instance and the 'clock' container (SID
1721). After invocation of GET, a CBOR map with data nodes from 1721). After invocation of GET, a CBOR map with data nodes from
these two modules is returned: these two modules is returned:
REQ: GET /c REQ: GET </c>
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
1721 : { / Clock (SID 1721) / 1721 : { / Clock (SID 1721) /
2: "2016-10-26T12:16:31Z", / current-datetime (SID 1723) / 2: "2016-10-26T12:16:31Z", / current-datetime (SID 1723) /
1: "2014-10-05T09:00:00Z" / boot-datetime (SID 1722) / 1: "2014-10-05T09:00:00Z" / boot-datetime (SID 1722) /
}, },
1533 : [ 1533 : [
{ / interface (SID 1533) / { / interface (SID 1533) /
4 : "eth0", / name (SID 1537) / 4 : "eth0", / name (SID 1537) /
1 : "Ethernet adaptor", / description (SID 1534) / 1 : "Ethernet adaptor", / description (SID 1534) /
5 : 1880, / type (SID 1538), identity: / 5 : 1880, / type (SID 1538), identity: /
/ ethernetCsmacd (SID 1880) / / ethernetCsmacd (SID 1880) /
2 : true / enabled (SID 1535) / 2 : true / enabled (SID 1535) /
} }
] ]
} }
4.5. Event stream 4.5. Event stream
Event notification is an essential function for the management of Event notification is an essential function for the management of
servers. CoMI allows notifications specified in YANG [RFC5277] to be servers. CORECONF allows notifications specified in YANG [RFC5277]
reported to a list of clients. The recommended path of the default to be reported to a list of clients. The path for the default event
event stream is /s. The server MAY support additional event stream stream can be discovered as described in Section 4. The server MAY
resources to address different notification needs. support additional event stream resources to address different
notification needs.
Reception of notification instances is enabled with the CoAP Observe Reception of notification instances is enabled with the CoAP Observe
[RFC7641] function. Clients subscribe to the notifications by [RFC7641] function. Clients subscribe to the notifications by
sending a GET request with an "Observe" option, specifying the /s sending a GET request with an "Observe" option to the stream
resource when the default stream is selected. resource.
Each response payload carries one or multiple notifications. The Each response payload carries one or multiple notifications. The
number of notifications reported, and the conditions used to remove number of notifications reported, and the conditions used to remove
notifications from the reported list is left to implementers. When notifications from the reported list are left to implementers. When
multiple notifications are reported, they MUST be ordered starting multiple notifications are reported, they MUST be ordered starting
from the newest notification at index zero. from the newest notification at index zero. Note that this could
lead to notifications being sent multiple times, which increases the
probability for the client to receive them, but it might potentially
lead to messages that exceed the MTU of a single CoAP packet. If
such cases could arise, implementers should make sure appropriate
fragmentation is available - for example the one described in
Section 5.
The format of notification without any content is a null value. The The format of notification without any content is a null value. The
format of single notification is defined in [I-D.ietf-core-yang-cbor] format of single notification is defined in [I-D.ietf-core-yang-cbor]
section 4.2.1. For multiple notifications the format is an array section 4.2.1. For multiple notifications the format is an array
where each element is a single notification as described in where each element is a single notification as described in
[I-D.ietf-core-yang-cbor] section 4.2.1. [I-D.ietf-core-yang-cbor] section 4.2.1.
FORMAT: FORMAT:
GET <stream-resource> Observe(0) GET <stream-resource> Observe(0)
skipping to change at page 25, line 47 skipping to change at page 26, line 43
"Event generated if a hardware fault is detected"; "Event generated if a hardware fault is detected";
leaf port-name { // SID 60011 leaf port-name { // SID 60011
type string; type string;
} }
leaf port-fault { // SID 60012 leaf port-fault { // SID 60012
type string; type string;
} }
} }
} }
By executing a GET on the /s resource the client receives the In this example the default event stream resource path /s is an
following response: example location discovered with a request similar to Figure 5. By
executing a GET with Observe 0 on the default event stream resource
the client receives the following response:
REQ: GET /s Observe(0) REQ: GET </s> Observe(0)
RES: 2.05 Content (Content-Format: application/yang-tree+cbor) RES: 2.05 Content (Content-Format: application/yang-tree+cbor)
Observe(12) Observe(12)
[ [
{ {
60010 : { / example-port-fault (SID 60010) / 60010 : { / example-port-fault (SID 60010) /
1 : "0/4/21", / port-name (SID 60011) / 1 : "0/4/21", / port-name (SID 60011) /
2 : "Open pin 2" / port-fault (SID 60012) / 2 : "Open pin 2" / port-fault (SID 60012) /
} }
}, },
{ {
60010 : { / example-port-fault (SID 60010) / 60010 : { / example-port-fault (SID 60010) /
1 : "1/4/21", / port-name (SID 60011) / 1 : "1/4/21", / port-name (SID 60011) /
2 : "Open pin 5" / port-fault (SID 60012) / 2 : "Open pin 5" / port-fault (SID 60012) /
} }
} }
] ]
In the example, the request returns a success response with the In the example, the request returns a success response with the
contents of the last two generated events. Consecutively the server contents of the last two generated events. Consecutively the server
will regularly notify the client when a new event is generated. will regularly notify the client when a new event is generated.
To check that the client is still alive, the server MUST send 4.5.2. The 'f' query parameter
Confirmable Message periodically. When the client does not confirm
the notification from the server, the server will remove the client
from the list of observers [RFC7641].
4.5.2. The 'f' Uri-Query option
The 'f' (filter) option is used to indicate which subset of all The 'f' (filter) option is used to indicate which subset of all
possible notifications is of interest. If not present, all possible notifications is of interest. If not present, all
notifications supported by the event stream are reported. notifications supported by the event stream are reported.
When not supported by a CoMI server, this option shall be ignored, When not supported by a CORECONF server, this option shall be
all events notifications are reported independently of the presence ignored, all events notifications are reported independently of the
and content of the 'f' (filter) option. presence and content of the 'f' (filter) option.
When present, this option contains a comma separated list of When present, this option contains a comma-separated list of
notification SIDs. For example, the following request returns notification SIDs. For example, the following request returns
notifications 60010 and 60020. notifications 60010 and 60020.
REQ: GET /s?f=60010,60020 Observe(0) REQ: GET </s?f=60010,60020> Observe(0)
4.6. RPC statements 4.6. RPC statements
The YANG "action" and "RPC" statements specify the execution of a The YANG "action" and "RPC" statements specify the execution of a
Remote procedure Call (RPC) in the server. It is invoked using a Remote procedure Call (RPC) in the server. It is invoked using a
POST method to an "Action" or "RPC" resource instance. POST method to an "Action" or "RPC" resource instance.
The request payload contains the values assigned to the input The request payload contains the values assigned to the input
container when specified. The response payload contains the values container when specified. The response payload contains the values
of the output container when specified. Both the input and output of the output container when specified. Both the input and output
containers are encoded in CBOR using the rules defined in containers are encoded in CBOR using the rules defined in
[I-D.ietf-core-yang-cbor] section 4.2.1. [I-D.ietf-core-yang-cbor] section 4.2.1.
The returned success response code is 2.05 Content. The returned success response code is 2.05 Content.
FORMAT: FORMAT:
POST <data node resource> ['k' Uri-Query option] POST <data node resource> ['k' Uri-Query option]
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
2.05 Content (Content-Format: application/yang-data+cbor) 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
CBOR map of SID, instance-value CBOR map of SID, instance-value
4.6.1. RPC Example 4.6.1. RPC Example
The example is based on the YANG action "reset" as defined in The example is based on the YANG action "reset" as defined in
[RFC7950] section 7.15.3 and annotated below with SIDs. [RFC7950] section 7.15.3 and annotated below with SIDs.
module example-server-farm { module example-server-farm {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:server-farm"; namespace "urn:example:server-farm";
skipping to change at page 28, line 39 skipping to change at page 29, line 39
mandatory true; mandatory true;
} }
} }
} }
} }
} }
This example invokes the 'reset' action (SID 60002, base64: Opq), of This example invokes the 'reset' action (SID 60002, base64: Opq), of
the server instance with name equal to "myserver". the server instance with name equal to "myserver".
REQ: POST /c/Opq?k="myserver" REQ: POST </c/Opq?k=myserver>
(Content-Format: application/yang-data+cbor) (Content-Format: application/yang-data+cbor; id=sid)
{ {
60002 : { 60002 : {
1 : "2016-02-08T14:10:08Z09:00" / reset-at (SID 60003) / 1 : "2016-02-08T14:10:08Z09:00" / reset-at (SID 60003) /
}
} }
}
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor; id=sid)
{ {
60002 : { 60002 : {
2 : "2016-02-08T14:10:08Z09:18" / reset-finished-at (SID 60004)/ 2 : "2016-02-08T14:10:08Z09:18" / reset-finished-at (SID 60004)/
}
} }
}
5. Use of Block-wise Transfers 5. Use of Block-wise Transfers
The CoAP protocol provides reliability by acknowledging the UDP The CoAP protocol provides reliability by acknowledging the UDP
datagrams. However, when large pieces of data need to be datagrams. However, when large pieces of data need to be
transported, datagrams get fragmented, thus creating constraints on transported, datagrams get fragmented, thus creating constraints on
the resources in the client, server and intermediate routers. The the resources in the client, server and intermediate routers. The
block option [RFC7959] allows the transport of the total payload in block option [RFC7959] allows the transport of the total payload in
individual blocks of which the size can be adapted to the underlying individual blocks of which the size can be adapted to the underlying
transport sizes such as: (UDP datagram size ~64KiB, IPv6 MTU of 1280, transport sizes such as: (UDP datagram size ~64KiB, IPv6 MTU of 1280,
IEEE 802.15.4 payload of 60-80 bytes). Each block is individually IEEE 802.15.4 payload of 60-80 bytes). Each block is individually
acknowledged to guarantee reliability. acknowledged to guarantee reliability.
Notice that the Block mechanism splits the data at fixed positions, Notice that the Block mechanism splits the data at fixed positions,
such that individual data fields may become fragmented. Therefore, such that individual data fields may become fragmented. Therefore,
assembly of multiple blocks may be required to process complete data assembly of multiple blocks may be required to process complete data
fields. fields.
Beware of race conditions. Blocks are filled one at a time and care Beware of race conditions. In case blocks are filled one at a time,
should be taken that the whole data representation is sent in care should be taken that the whole and consistent data
multiple blocks sequentially without interruption. On the server, representation is sent in multiple blocks sequentially without
values are changed, lists are re-ordered, extended or reduced. When interruption. On the server, values might change, lists might get
these actions happen during the serialization of the contents of the re-ordered, extended or reduced. When these actions happen during
resource, the transported results do not correspond with a state the serialization of the contents of the resource, the transported
having occurred in the server; or worse the returned values are results do not correspond with a state having occurred in the server;
inconsistent. For example: array length does not correspond with the or worse the returned values are inconsistent. For example: array
actual number of items. It may be advisable to use Indefinite-length length does not correspond with the actual number of items. It may
CBOR arrays and maps, which are foreseen for data streaming purposes. be advisable to use Indefinite-length CBOR arrays and maps, which are
foreseen for data streaming purposes.
6. Application Discovery 6. Application Discovery
Two application discovery mechanisms are supported by CoMI, the YANG Two application discovery mechanisms are supported by CORECONF, the
library data model as defined by [I-D.ietf-core-yang-library] and the YANG library data model as defined by [I-D.ietf-core-yang-library]
CORE resource discovery [RFC6690]. Implementers may choose to and the CORE resource discovery [RFC6690]. Implementers may choose
implement one or the other or both. to implement one or the other or both.
6.1. YANG library 6.1. YANG library
The YANG library data model [I-D.ietf-core-yang-library] provides a The YANG library data model [I-D.ietf-core-yang-library] provides a
high level description of the resources available. The YANG library high-level description of the resources available. The YANG library
contains the list of modules, features and deviations supported by contains the list of modules, features, and deviations supported by
the CoMI server. From this information, CoMI clients can infer the the CORECONF server. From this information, CORECONF clients can
list of data nodes supported and the interaction model to be used to infer the list of data nodes supported and the interaction model to
access them. This module also contains the list of datastores be used to access them. This module also contains the list of
implemented. datastores implemented.
As described in [RFC6690], the location of the YANG library can be As described in [RFC6690], the location of the YANG library can be
found by sending a GET request to "/.well-known/core" including a found by sending a GET request to "/.well-known/core" including a
resource type (RT) parameter with the value "core.c.yl". Upon resource type (RT) parameter with the value "core.c.yl". Upon
success, the return payload will contain the root resource of the success, the return payload will contain the root resource of the
YANG library module. YANG library module.
The following example assumes that the SID of the YANG library is The following example assumes that the SID of the YANG library is
2351 (kv encoded as specified in Section 2.2). 2351 (kv encoded as specified in Section 2.2) and that the server
uses /c as datastore resource path.
REQ: GET /.well-known/core?rt=core.c.yl REQ: GET </.well-known/core?rt=core.c.yl>
RES: 2.05 Content (Content-Format: application/link-format) RES: 2.05 Content (Content-Format: application/link-format)
</c/kv>;rt="core.c.yl" </c/kv>;rt="core.c.yl"
6.2. Resource Discovery 6.2. Resource Discovery
As some CoAP interfaces and services might not support the YANG As some CoAP interfaces and services might not support the YANG
library interface and still be interested to discover resources that library interface and still be interested to discover resources that
are available, implementations MAY choose to support discovery of all are available, implementations MAY choose to support discovery of all
available resources using "/.well-known/core" as defined by available resources using "/.well-known/core" as defined by
[RFC6690]. [RFC6690].
6.2.1. Datastore Resource Discovery 6.2.1. Datastore Resource Discovery
The presence and location of (path to) each datastore implemented by The presence and location of (path to) each datastore implemented by
the CoMI server can be discovered by sending a GET request to the CORECONF server can be discovered by sending a GET request to
"/.well-known/core" including a resource type (RT) parameter with the "/.well-known/core" including a resource type (RT) parameter with the
value "core.c.ds". value "core.c.ds".
Upon success, the return payload contains the list of datastore Upon success, the return payload contains the list of datastore
resources. resources.
Each datastore returned is further qualified using the "ds" Link- Each datastore returned is further qualified using the "ds" Link-
Format attribute. This attribute is set to the SID assigned to the Format attribute. This attribute is set to the SID assigned to the
datastore identity. When a unified datastore is implemented, the ds datastore identity. When a unified datastore is implemented, the ds
attribute is set to 1029 as specified in Appendix B. For other attribute is set to 1029 as specified in Appendix B. For other
examples of datastores, see the Network Management Datastore examples of datastores, see the Network Management Datastore
Architecture (NMDA) [RFC7950]. Architecture (NMDA) [RFC7950].
link-extension = ( "ds" "=" sid ) ) link-extension = ( "ds" "=" sid ) )
; SID assigned to the datastore identity ; SID assigned to the datastore identity
sid = 1*DIGIT sid = 1*DIGIT
For example: The following example assumes that the server uses /c as datastore
resource path.
REQ: GET /.well-known/core?rt=core.c.ds REQ: GET </.well-known/core?rt=core.c.ds>
RES: 2.05 Content (Content-Format: application/link-format) RES: 2.05 Content (Content-Format: application/link-format)
</c>; rt="core.c.ds";ds=1029 </c>; rt="core.c.ds";ds=1029
Figure 4
6.2.2. Data node Resource Discovery 6.2.2. Data node Resource Discovery
If implemented, the presence and location of (path to) each data node If implemented, the presence and location of (path to) each data node
implemented by the CoMI server are discovered by sending a GET implemented by the CORECONF server are discovered by sending a GET
request to "/.well-known/core" including a resource type (RT) request to "/.well-known/core" including a resource type (RT)
parameter with the value "core.c.dn". parameter with the value "core.c.dn".
Upon success, the return payload contains the SID assigned to each Upon success, the return payload contains the SID assigned to each
data node and their location. data node and their location.
The example below shows the discovery of the presence and location of The example below shows the discovery of the presence and location of
data nodes. Data nodes '/ietf-system:system-state/clock/boot- data nodes. Data nodes '/ietf-system:system-state/clock/boot-
datetime' (SID 1722) and '/ietf-system:system-state/clock/current- datetime' (SID 1722) and '/ietf-system:system-state/clock/current-
datetime' (SID 1723) are returned. datetime' (SID 1723) are returned. The example assumes that the
server uses /c as datastore resource path.
REQ: GET /.well-known/core?rt=core.c.dn REQ: GET </.well-known/core?rt=core.c.dn>
RES: 2.05 Content (Content-Format: application/link-format) RES: 2.05 Content (Content-Format: application/link-format)
</c/a6>;rt="core.c.dn", </c/a6>;rt="core.c.dn",
</c/a7>;rt="core.c.dn" </c/a7>;rt="core.c.dn"
Without additional filtering, the list of data nodes may become Without additional filtering, the list of data nodes may become
prohibitively long. If this is the case implementations SHOULD prohibitively long. If this is the case implementations SHOULD
support a way to obtain all links using multiple GET requests (for support a way to obtain all links using multiple GET requests (for
example through some form of pagination). example through some form of pagination).
6.2.3. Event stream Resource Discovery 6.2.3. Event stream Resource Discovery
The presence and location of (path to) each event stream implemented The presence and location of (path to) each event stream implemented
by the CoMI server are discovered by sending a GET request to by the CORECONF server are discovered by sending a GET request to
"/.well-known/core" including a resource type (RT) parameter with the "/.well-known/core" including a resource type (RT) parameter with the
value "core.c.es". value "core.c.es".
Upon success, the return payload contains the list of event stream Upon success, the return payload contains the list of event stream
resources. resources.
For example: The following example assumes that the server uses /s as the default
event stream resource.
REQ: GET /.well-known/core?rt=core.c.es REQ: GET </.well-known/core?rt=core.c.es>
RES: 2.05 Content (Content-Format: application/link-format) RES: 2.05 Content (Content-Format: application/link-format)
</s>;rt="core.c.es" </s>;rt="core.c.es"
Figure 5
7. Error Handling 7. Error Handling
In case a request is received which cannot be processed properly, the In case a request is received which cannot be processed properly, the
CoMI server MUST return an error response. This error response MUST CORECONF server MUST return an error response. This error response
contain a CoAP 4.xx or 5.xx response code. MUST contain a CoAP 4.xx or 5.xx response code.
Errors returned by a CoMI server can be broken into two categories, Errors returned by a CORECONF server can be broken into two
those associated to the CoAP protocol itself and those generated categories, those associated with the CoAP protocol itself and those
during the validation of the YANG data model constrains as described generated during the validation of the YANG data model constrains as
in [RFC7950] section 8. described in [RFC7950] section 8.
The following list of common CoAP errors should be implemented by The following list of common CoAP errors should be implemented by
CoMI servers. This list is not exhaustive, other errors defined by CORECONF servers. This list is not exhaustive, other errors defined
CoAP and associated RFCs may be applicable. by CoAP and associated RFCs may be applicable.
o Error 4.01 (Unauthorized) is returned by the CoMI server when the o Error 4.01 (Unauthorized) is returned by the CORECONF server when
CoMI client is not authorized to perform the requested action on the CORECONF client is not authorized to perform the requested
the targeted resource (i.e. data node, datastore, rpc, action or action on the targeted resource (i.e. data node, datastore, rpc,
event stream). action or event stream).
o Error 4.02 (Bad Option) is returned by the CoMI server when one or o Error 4.02 (Bad Option) is returned by the CORECONF server when
more CoAP options are unknown or malformed. one or more CoAP options are unknown or malformed.
o Error 4.04 (Not Found) is returned by the CoMI server when the o Error 4.04 (Not Found) is returned by the CORECONF server when the
CoMI client is requesting a non-instantiated resource (i.e. data CORECONF client is requesting a non-instantiated resource (i.e.
node, datastore, rpc, action or event stream). data node, datastore, rpc, action or event stream).
o Error 4.05 (Method Not Allowed) is returned by the CoMI server o Error 4.05 (Method Not Allowed) is returned by the CORECONF server
when the CoMI client is requesting a method not supported on the when the CORECONF client is requesting a method not supported on
targeted resource. (e.g. GET on an rpc, PUT or POST on a data the targeted resource. (e.g. GET on an rpc, PUT or POST on a data
node with "config" set to false). node with "config" set to false).
o Error 4.08 (Request Entity Incomplete) is returned by the CoMI o Error 4.08 (Request Entity Incomplete) is returned by the CORECONF
server if one or multiple blocks of a block transfer request is server if one or multiple blocks of a block transfer request is
missing, see [RFC7959] for more details. missing, see [RFC7959] for more details.
o Error 4.13 (Request Entity Too Large) may be returned by the CoMI o Error 4.13 (Request Entity Too Large) may be returned by the
server during a block transfer request, see [RFC7959] for more CORECONF server during a block transfer request, see [RFC7959] for
details. more details.
o Error 4.15 (Unsupported Content-Format) is returned by the CoMI o Error 4.15 (Unsupported Content-Format) is returned by the
server when the Content-Format used in the request does not match CORECONF server when the Content-Format used in the request does
those specified in section Section 2.4. not match those specified in section Section 2.4.
The CoMI server MUST also enforce the different constraints The CORECONF server MUST also enforce the different constraints
associated to the YANG data models implemented. These constraints associated with the YANG data models implemented. These constraints
are described in [RFC7950] section 8. These errors are reported are described in [RFC7950] section 8. These errors are reported
using the CoAP error code 4.00 (Bad Request) and may have the using the CoAP error code 4.00 (Bad Request) and may have the
following error container as payload. The YANG definition and following error container as payload. The YANG definition and
associated .sid file are available in Appendix A and Appendix B. The associated .sid file are available in Appendix A and Appendix B. The
error container is encoded using the encoding rules of a YANG data error container is encoded using the encoding rules of a YANG data
template as defined in [I-D.ietf-core-yang-cbor] section 5. template as defined in [I-D.ietf-core-yang-cbor] section 5.
+--rw error! +--rw error!
+--rw error-tag identityref +--rw error-tag identityref
+--rw error-app-tag? identityref +--rw error-app-tag? identityref
+--rw error-data-node? instance-identifier +--rw error-data-node? instance-identifier
+--rw error-message? string +--rw error-message? string
The following 'error-tag' and 'error-app-tag' are defined by the The following 'error-tag' and 'error-app-tag' are defined by the
ietf-comi YANG module, these tags are implemented as YANG identity ietf-coreconf YANG module, these tags are implemented as YANG
and can be extended as needed. identity and can be extended as needed.
o error-tag 'operation-failed' is returned by the CoMI server when o error-tag 'operation-failed' is returned by the CORECONF server
the operation request cannot be processed successfully. when the operation request cannot be processed successfully.
* error-app-tag 'malformed-message' is returned by the CoMI * error-app-tag 'malformed-message' is returned by the CORECONF
server when the payload received from the CoMI client does not server when the payload received from the CORECONF client does
contain a well-formed CBOR content as defined in [RFC7049] not contain a well-formed CBOR content as defined in [RFC7049]
section 3.3 or does not comply with the CBOR structure defined section 3.3 or does not comply with the CBOR structure defined
within this document. within this document.
* error-app-tag 'data-not-unique' is returned by the CoMI server * error-app-tag 'data-not-unique' is returned by the CORECONF
when the validation of the 'unique' constraint of a list or server when the validation of the 'unique' constraint of a list
leaf-list fails. or leaf-list fails.
* error-app-tag 'too-many-elements' is returned by the CoMI * error-app-tag 'too-many-elements' is returned by the CORECONF
server when the validation of the 'max-elements' constraint of server when the validation of the 'max-elements' constraint of
a list or leaf-list fails. a list or leaf-list fails.
* error-app-tag 'too-few-elements' is returned by the CoMI server * error-app-tag 'too-few-elements' is returned by the CORECONF
when the validation of the 'min-elements' constraint of a list server when the validation of the 'min-elements' constraint of
or leaf-list fails. a list or leaf-list fails.
* error-app-tag 'must-violation' is returned by the CoMI server * error-app-tag 'must-violation' is returned by the CORECONF
when the restrictions imposed by a 'must' statement are server when the restrictions imposed by a 'must' statement are
violated. violated.
* error-app-tag 'duplicate' is returned by the CoMI server when a * error-app-tag 'duplicate' is returned by the CORECONF server
client tries to create a duplicate list or leaf-list entry. when a client tries to create a duplicate list or leaf-list
entry.
o error-tag 'invalid-value' is returned by the CoMI server when the o error-tag 'invalid-value' is returned by the CORECONF server when
CoMI client tries to update or create a leaf with a value encoded the CORECONF client tries to update or create a leaf with a value
using an invalid CBOR datatype or if the 'range', 'length', encoded using an invalid CBOR datatype or if the 'range',
'pattern' or 'require-instance' constrain is not fulfilled. 'length', 'pattern' or 'require-instance' constrain is not
fulfilled.
* error-app-tag 'invalid-datatype' is returned by the CoMI server * error-app-tag 'invalid-datatype' is returned by the CORECONF
when CBOR encoding does not follow the rules set by the YANG server when CBOR encoding does not follow the rules set by the
Build-In type or when the value is incompatible with it (e.g. a YANG Build-In type or when the value is incompatible with it
value greater than 127 for an int8, undefined enumeration). (e.g. a value greater than 127 for an int8, undefined
enumeration).
* error-app-tag 'not-in-range' is returned by the CoMI server * error-app-tag 'not-in-range' is returned by the CORECONF server
when the validation of the 'range' property fails. when the validation of the 'range' property fails.
* error-app-tag 'invalid-length' is returned by the CoMI server * error-app-tag 'invalid-length' is returned by the CORECONF
when the validation of the 'length' property fails. server when the validation of the 'length' property fails.
* error-app-tag 'pattern-test-failed' is returned by the CoMI * error-app-tag 'pattern-test-failed' is returned by the CORECONF
server when the validation of the 'pattern' property fails. server when the validation of the 'pattern' property fails.
o error-tag 'missing-element' is returned by the CoMI server when o error-tag 'missing-element' is returned by the CORECONF server
the operation requested by a CoMI client fails to comply with the when the operation requested by a CORECONF client fails to comply
'mandatory' constraint defined. The 'mandatory' constraint is with the 'mandatory' constraint defined. The 'mandatory'
enforced for leafs and choices, unless the node or any of its constraint is enforced for leafs and choices, unless the node or
ancestors have a 'when' condition or 'if-feature' expression that any of its ancestors have a 'when' condition or 'if-feature'
evaluates to 'false'. expression that evaluates to 'false'.
* error-app-tag 'missing-key' is returned by the CoMI server to * error-app-tag 'missing-key' is returned by the CORECONF server
further qualify a missing-element error. This error is to further qualify a missing-element error. This error is
returned when the CoMI client tries to create or list instance, returned when the CORECONF client tries to create or list
without all the 'key' specified or when the CoMI client tries instance, without all the 'key' specified or when the CORECONF
to delete a leaf listed as a 'key'. client tries to delete a leaf listed as a 'key'.
* error-app-tag 'missing-input-parameter' is returned by the CoMI * error-app-tag 'missing-input-parameter' is returned by the
server when the input parameters of an RPC or action are CORECONF server when the input parameters of an RPC or action
incomplete. are incomplete.
o error-tag 'unknown-element' is returned by the CoMI server when o error-tag 'unknown-element' is returned by the CORECONF server
the CoMI client tries to access a data node of a YANG module not when the CORECONF client tries to access a data node of a YANG
supported, of a data node associated to an 'if-feature' expression module not supported, of a data node associated with an 'if-
evaluated to 'false' or to a 'when' condition evaluated to feature' expression evaluated to 'false' or to a 'when' condition
'false'. evaluated to 'false'.
o error-tag 'bad-element' is returned by the CoMI server when the o error-tag 'bad-element' is returned by the CORECONF server when
CoMI client tries to create data nodes for more than one case in a the CORECONF client tries to create data nodes for more than one
choice. case in a choice.
o error-tag 'data-missing' is returned by the CoMI server when a o error-tag 'data-missing' is returned by the CORECONF server when a
data node required to accept the request is not present. data node required to accept the request is not present.
* error-app-tag 'instance-required' is returned by the CoMI * error-app-tag 'instance-required' is returned by the CORECONF
server when a leaf of type 'instance-identifier' or 'leafref' server when a leaf of type 'instance-identifier' or 'leafref'
marked with require-instance set to 'true' refers to an marked with require-instance set to 'true' refers to an
instance that does not exist. instance that does not exist.
* error-app-tag 'missing-choice' is returned by the CoMI server * error-app-tag 'missing-choice' is returned by the CORECONF
when no nodes exist in a mandatory choice. server when no nodes exist in a mandatory choice.
o error-tag 'error' is returned by the CoMI server when an o error-tag 'error' is returned by the CORECONF server when an
unspecified error has occurred. unspecified error has occurred.
For example, the CoMI server might return the following error. For example, the CORECONF server might return the following error.
RES: 4.00 Bad Request (Content-Format: application/yang-data+cbor) RES: 4.00 Bad Request (Content-Format: application/yang-data+cbor; id=sid)
{ {
1024 : { 1024 : {
4 : 1011, / error-tag (SID 1028) / 4 : 1011, / error-tag (SID 1028) /
/ = invalid-value (SID 1011) / / = invalid-value (SID 1011) /
1 : 1018, / error-app-tag (SID 1025) / 1 : 1018, / error-app-tag (SID 1025) /
/ = not-in-range (SID 1018) / / = not-in-range (SID 1018) /
2 : 1740, / error-data-node (SID 1026) / 2 : 1740, / error-data-node (SID 1026) /
/ = timezone-utc-offset (SID 1740) / / = timezone-utc-offset (SID 1740) /
3 : "maximum value exceeded" / error-message (SID 1027) / 3 : "maximum value exceeded" / error-message (SID 1027) /
} }
} }
8. Security Considerations 8. Security Considerations
For secure network management, it is important to restrict access to For secure network management, it is important to restrict access to
configuration variables only to authorized parties. CoMI re-uses the configuration variables only to authorized parties. CORECONF re-uses
security mechanisms already available to CoAP, this includes DTLS the security mechanisms already available to CoAP, this includes DTLS
[RFC6347] for protected access to resources, as well suitable [RFC6347] and OSCORE [RFC8613] for protected access to resources, as
authentication and authorization mechanisms. well as suitable authentication and authorization mechanisms, for
example those defined in ACE OAuth [I-D.ietf-ace-oauth-authz].
Among the security decisions that need to be made are selecting All the security considerations of [RFC7252], [RFC7959], [RFC8132]
security modes and encryption mechanisms (see [RFC7252]). and [RFC7641] apply to this document as well. The use of NoSec DTLS,
when OSCORE is not used, is NOT RECOMMENDED.
In addition, mechanisms for authentication and authorization may need In addition, mechanisms for authentication and authorization may need
to be selected if not provided with the security mode. to be selected if not provided with the CoAP security mode.
As [I-D.ietf-core-yang-cbor] and [RFC4648] are used for payload and
SID encoding, the security considerations of those documents also
need to be well-understood.
9. IANA Considerations 9. IANA Considerations
9.1. Resource Type (rt=) Link Target Attribute Values Registry 9.1. Resource Type (rt=) Link Target Attribute Values Registry
This document adds the following resource type to the "Resource Type This document adds the following resource type to the "Resource Type
(rt=) Link Target Attribute Values", within the "Constrained RESTful (rt=) Link Target Attribute Values", within the "Constrained RESTful
Environments (CoRE) Parameters" registry. Environments (CoRE) Parameters" registry.
+-----------+---------------------+-----------+ +-----------+---------------------+-----------+
skipping to change at page 36, line 30 skipping to change at page 37, line 42
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 | ID | Reference |
| | Coding | | | | | Coding | | |
+-----------------------------------+------------+------+-----------+ +-----------------------------------+------------+------+-----------+
| application/yang-data+cbor | | TBD1 | RFC XXXX |
| | | | |
| application/yang-identifiers+cbor | | TBD2 | RFC XXXX | | application/yang-identifiers+cbor | | TBD2 | RFC XXXX |
| | | | | | | | | |
| application/yang-instances+cbor | | TBD3 | RFC XXXX | | application/yang-instances+cbor | | TBD3 | RFC XXXX |
+-----------------------------------+------------+------+-----------+ +-----------------------------------+------------+------+-----------+
// RFC Ed.: replace TBD1, TBD2 and TBD3 with assigned IDs and remove // RFC Ed.: replace TBD1, TBD2 and TBD3 with assigned IDs and remove
this note. // RFC Ed.: replace RFC XXXX with this RFC number and this note. // RFC Ed.: replace RFC XXXX with this RFC number and
remove this note. remove this note.
9.3. Media Types Registry 9.3. Media Types Registry
This document adds the following media types to the "Media Types" This document adds the following media types to the "Media Types"
registry. registry.
+-----------------------+----------------------------+-----------+ +-----------------------+-----------------------+-----------+
| Name | Template | Reference | | Name | Template | Reference |
+-----------------------+----------------------------+-----------+ +-----------------------+-----------------------+-----------+
| yang-data+cbor | application/yang-data+cbor | RFC XXXX | | yang-identifiers+cbor | application/ | RFC XXXX |
| | | | | | | |
| yang-identifiers+cbor | application/ | RFC XXXX | | | yang-identifiers+cbor | |
| | | | | | | |
| | yang-identifiers+cbor | | | yang-instances+cbor | application/ | RFC XXXX |
| | | | | | | |
| yang-instances+cbor | application/ | RFC XXXX | | | yang-instances+cbor | |
| | | | +-----------------------+-----------------------+-----------+
| | yang-instances+cbor | |
+-----------------------+----------------------------+-----------+
Each of these media types share the following information: Each of these media types share the following information:
o Subtype name: <as listed in table> o Subtype name: <as listed in table>
o Required parameters: N/A o Required parameters: N/A
o Optional parameters: N/A o Optional parameters: N/A
o Encoding considerations: binary o Encoding considerations: binary
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of RFC XXXX of RFC XXXX
o Interoperability considerations: N/A o Interoperability considerations: N/A
o Published specification: RFC XXXX o Published specification: RFC XXXX
o Applications that use this media type: CoMI o Applications that use this media type: CORECONF
o Fragment identifier considerations: N/A o Fragment identifier considerations: N/A
o Additional information: o Additional information:
* Deprecated alias names for this type: N/A * Deprecated alias names for this type: N/A
* Magic number(s): N/A * Magic number(s): N/A
* File extension(s): N/A * File extension(s): N/A
skipping to change at page 37, line 49 skipping to change at page 39, line 4
o Additional information: o Additional information:
* Deprecated alias names for this type: N/A * Deprecated alias names for this type: N/A
* Magic number(s): N/A * Magic number(s): N/A
* File extension(s): N/A * File extension(s): N/A
* Macintosh file type code(s): N/A * Macintosh file type code(s): N/A
o Person & email address to contact for further information: o Person & email address to contact for further information:
iesg&ietf.org iesg&ietf.org
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: N/A o Restrictions on usage: N/A
o Author: Michel Veillette, ietf&augustcellars.com o Author: Michel Veillette, ietf&augustcellars.com
o Change Controller: IESG o Change Controller: IESG
o Provisional registration? No o Provisional registration? No
// RFC Ed.: replace RFC XXXX with this RFC number and remove this // RFC Ed.: replace RFC XXXX with this RFC number and remove this
note. note.
10. Acknowledgements 9.4. YANG Namespace Registration
This document registers the following XML namespace URN in the "IETF
XML Registry", following the format defined in [RFC3688]:
URI: please assign urn:ietf:params:xml:ns:yang:ietf-coreconf
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
Reference: RFC XXXX
// RFC Ed.: please replace XXXX with RFC number and remove this note
10. Acknowledgments
We are very grateful to Bert Greevenbosch who was one of the original We are very grateful to Bert Greevenbosch who was one of the original
authors of the CoMI specification. authors of the CORECONF specification.
Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs
transported under SNMP. Carsten Bormann has given feedback on the transported under SNMP. Carsten Bormann has given feedback on the
use of CBOR. use of CBOR.
The draft has benefited from comments (alphabetical order) by Rodney The draft has benefited from comments (alphabetical order) by Rodney
Cummings, Dee Denteneer, Esko Dijk, Michael van Hartskamp, Tanguy Cummings, Dee Denteneer, Esko Dijk, Klaus Hartke, Michael van
Ropitault, Juergen Schoenwaelder, Anuj Sehgal, Zach Shelby, Hannes Hartskamp, Tanguy Ropitault, Juergen Schoenwaelder, Anuj Sehgal, Zach
Tschofenig, Michael Verschoor, and Thomas Watteyne. Shelby, Hannes Tschofenig, Michael Verschoor, and Thomas Watteyne.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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 (SID)", draft-ietf-core-sid-11 (work in iDentifier (SID)", draft-ietf-core-sid-13 (work in
progress), March 2020. progress), June 2020.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
Data Modeled with YANG", draft-ietf-core-yang-cbor-11 Data Modeled with YANG", draft-ietf-core-yang-cbor-12
(work in progress), September 2019. (work in progress), March 2020.
[I-D.ietf-core-yang-library] [I-D.ietf-core-yang-library]
Veillette, M. and I. Petrov, "Constrained YANG Module Veillette, M. and I. Petrov, "Constrained YANG Module
Library", draft-ietf-core-yang-library-01 (work in Library", draft-ietf-core-yang-library-01 (work in
progress), January 2020. progress), January 2020.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<https://www.rfc-editor.org/info/rfc5277>. <https://www.rfc-editor.org/info/rfc5277>.
[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
skipping to change at page 40, line 16 skipping to change at page 41, line 39
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
(work in progress), June 2020.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
skipping to change at page 40, line 42 skipping to change at page 42, line 23
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
Appendix A. ietf-comi YANG module Appendix A. ietf-coreconf YANG module
<CODE BEGINS> file "ietf-comi@2019-03-28.yang"
module ietf-comi {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-comi";
prefix comi;
import ietf-datastores {
prefix ds;
}
import ietf-restconf { <CODE BEGINS> file "ietf-coreconf@2019-03-28.yang"
prefix rc; module ietf-coreconf {
description yang-version 1.1;
"This import statement is required to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
organization namespace "urn:ietf:params:xml:ns:yang:ietf-coreconf";
"IETF Core Working Group"; prefix coreconf;
contact import ietf-datastores {
"Michel Veillette prefix ds;
<mailto:michel.veillette@trilliantinc.com> }
Alexander Pelov import ietf-restconf {
<mailto:alexander@ackl.io> prefix rc;
description
"This import statement is required to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
Peter van der Stok organization
<mailto:consultancy@vanderstok.org> "IETF Core Working Group";
Andy Bierman contact
<mailto:andy@yumaworks.com>"; "Michel Veillette
<mailto:michel.veillette@trilliantinc.com>
description Alexander Pelov
"This module contains the different definitions required <mailto:alexander@ackl.io>
by the CoMI protocol. Peter van der Stok
<mailto:consultancy@vanderstok.org>
Copyright (c) 2019 IETF Trust and the persons identified as Andy Bierman
authors of the code. All rights reserved. <mailto:andy@yumaworks.com>";
Redistribution and use in source and binary forms, with or description
without modification, is permitted pursuant to, and subject to "This module contains the different definitions required
the license terms contained in, the Simplified BSD License set by the CORECONF protocol.
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; Copyright (c) 2019 IETF Trust and the persons identified as
see the RFC itself for full legal notices."; authors of the code. All rights reserved.
revision 2019-03-28 { Redistribution and use in source and binary forms, with or
description without modification, is permitted pursuant to, and subject to
"Initial revision."; the license terms contained in, the Simplified BSD License set
reference forth in Section 4.c of the IETF Trust's Legal Provisions
"[I-D.ietf-core-comi] CoAP Management Interface"; Relating to IETF Documents
(https://trustee.ietf.org/license-info).
} This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
identity unified { revision 2019-03-28 {
base ds:datastore; description
description "Initial revision.";
"Identifier of the unified configuration and operational reference
state datastore."; "[I-D.ietf-core-comi] CoAP Management Interface";
} }
identity error-tag { identity unified {
description base ds:datastore;
"Base identity for error-tag."; description
} "Identifier of the unified configuration and operational
state datastore.";
}
identity operation-failed { identity error-tag {
base error-tag; description
description "Base identity for error-tag.";
"Returned by the CoMI server when the operation request }
can't be processed successfully.";
}
identity invalid-value { identity operation-failed {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when the CoMI client tries to "Returned by the CORECONF server when the operation request
update or create a leaf with a value encoded using an can't be processed successfully.";
invalid CBOR datatype or if the 'range', 'length', }
'pattern' or 'require-instance' constrain is not identity invalid-value {
fulfilled."; base error-tag;
} description
"Returned by the CORECONF server when the CORECONF client tries to
update or create a leaf with a value encoded using an
invalid CBOR datatype or if the 'range', 'length',
'pattern' or 'require-instance' constrain is not
fulfilled.";
}
identity missing-element { identity missing-element {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when the operation requested "Returned by the CORECONF server when the operation requested
by a CoMI client fails to comply with the 'mandatory' by a CORECONF client fails to comply with the 'mandatory'
constraint defined. The 'mandatory' constraint is constraint defined. The 'mandatory' constraint is
enforced for leafs and choices, unless the node or any of enforced for leafs and choices, unless the node or any of
its ancestors have a 'when' condition or 'if-feature' its ancestors have a 'when' condition or 'if-feature'
expression that evaluates to 'false'."; expression that evaluates to 'false'.";
} }
identity unknown-element { identity unknown-element {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when the CoMI client tries to "Returned by the CORECONF server when the CORECONF client tries to
access a data node of a YANG module not supported, of a access a data node of a YANG module not supported, of a
data node associated with an 'if-feature' expression data node associated with an 'if-feature' expression
evaluated to 'false' or to a 'when' condition evaluated evaluated to 'false' or to a 'when' condition evaluated
to 'false'."; to 'false'.";
} }
identity bad-element { identity bad-element {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when the CoMI client tries to "Returned by the CORECONF server when the CORECONF client tries to
create data nodes for more than one case in a choice."; create data nodes for more than one case in a choice.";
} }
identity data-missing { identity data-missing {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when a data node required to "Returned by the CORECONF server when a data node required to
accept the request is not present."; accept the request is not present.";
} }
identity error { identity error {
base error-tag; base error-tag;
description description
"Returned by the CoMI server when an unspecified error has "Returned by the CORECONF server when an unspecified error has
occurred."; occurred.";
} }
identity error-app-tag { identity error-app-tag {
description description
"Base identity for error-app-tag."; "Base identity for error-app-tag.";
} }
identity malformed-message { identity malformed-message {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the payload received "Returned by the CORECONF server when the payload received
from the CoMI client don't contain a well-formed CBOR from the CORECONF client don't contain a well-formed CBOR
content as defined in [RFC7049] section 3.3 or don't content as defined in [RFC7049] section 3.3 or don't
comply with the CBOR structure defined within this comply with the CBOR structure defined within this
document."; document.";
} }
identity data-not-unique { identity data-not-unique {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server when the validation of the
'unique' constraint of a list or leaf-list fails."; 'unique' constraint of a list or leaf-list fails.";
} }
identity too-many-elements { identity too-many-elements {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server when the validation of the
'max-elements' constraint of a list or leaf-list fails."; 'max-elements' constraint of a list or leaf-list fails.";
} }
identity too-few-elements { identity too-few-elements {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server when the validation of the
'min-elements' constraint of a list or leaf-list fails."; 'min-elements' constraint of a list or leaf-list fails.";
} }
identity must-violation { identity must-violation {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the restrictions "Returned by the CORECONF server when the restrictions
imposed by a 'must' statement are violated."; imposed by a 'must' statement are violated.";
} }
identity duplicate { identity duplicate {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when a client tries to create "Returned by the CORECONF server when a client tries to create
a duplicate list or leaf-list entry."; a duplicate list or leaf-list entry.";
} }
identity invalid-datatype { identity invalid-datatype {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when CBOR encoding is "Returned by the CORECONF server when CBOR encoding is
incorect or when the value encoded is incompatible with incorect or when the value encoded is incompatible with
the YANG Built-In type. (e.g. value greater than 127 the YANG Built-In type. (e.g. value greater than 127
for an int8, undefined enumeration)."; for an int8, undefined enumeration).";
} }
identity not-in-range { identity not-in-range {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server when the validation of the
'range' property fails."; 'range' property fails.";
} }
identity invalid-length { identity invalid-length {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server when the validation of the
'length' property fails."; 'length' property fails.";
}
} identity pattern-test-failed {
base error-app-tag;
description
"Returned by the CORECONF server when the validation of the
'pattern' property fails.";
}
identity pattern-test-failed { identity missing-key {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the validation of the "Returned by the CORECONF server to further qualify a
'pattern' property fails."; missing-element error. This error is returned when the
} CORECONF client tries to create or list instance, without all
the 'key' specified or when the CORECONF client tries to
delete a leaf listed as a 'key'.";
}
identity missing-key { identity missing-input-parameter {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server to further qualify a "Returned by the CORECONF server when the input parameters
missing-element error. This error is returned when the of a RPC or action are incomplete.";
CoMI client tries to create or list instance, without all }
the 'key' specified or when the CoMI client tries to
delete a leaf listed as a 'key'.";
}
identity missing-input-parameter { identity instance-required {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when the input parameters "Returned by the CORECONF server when a leaf of type
of a RPC or action are incomplete."; 'instance-identifier' or 'leafref' marked with
} require-instance set to 'true' refers to an instance
that does not exist.";
}
identity instance-required { identity missing-choice {
base error-app-tag; base error-app-tag;
description description
"Returned by the CoMI server when a leaf of type "Returned by the CORECONF server when no nodes exist in a
'instance-identifier' or 'leafref' marked with mandatory choice.";
require-instance set to 'true' refers to an instance }
that does not exist.";
}
identity missing-choice { rc:yang-data coreconf-error {
base error-app-tag; container error {
description description
"Returned by the CoMI server when no nodes exist in a "Optional payload of a 4.00 Bad Request CoAP error.";
mandatory choice.";
}
rc:yang-data comi-error { leaf error-tag {
container error { type identityref {
description base error-tag;
"Optional payload of a 4.00 Bad Request CoAP error."; }
mandatory true;
description
"The enumerated error-tag.";
}
leaf error-tag { leaf error-app-tag {
type identityref { type identityref {
base error-tag; base error-app-tag;
} }
mandatory true; description
description "The application-specific error-tag.";
"The enumerated error-tag."; }
}
leaf error-app-tag { leaf error-data-node {
type identityref { type instance-identifier;
base error-app-tag; description
} "When the error reported is caused by a specific data node,
description this leaf identifies the data node in error.";
"The application-specific error-tag.";
}
leaf error-data-node { }
type instance-identifier;
description
"When the error reported is caused by a specific data node,
this leaf identifies the data node in error.";
}
leaf error-message { leaf error-message {
type string; type string;
description description
"A message describing the error."; "A message describing the error.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix B. ietf-comi .sid file Appendix B. ietf-coreconf .sid file
{ {
"assignment-ranges": [ "assignment-ranges": [
{ {
"entry-point": 1000, "entry-point": 1000,
"size": 100 "size": 100
} }
], ],
"module-name": "ietf-comi", "module-name": "ietf-coreconf",
"module-revision": "2019-03-28", "module-revision": "2019-03-28",
"items": [ "items": [
{ {
"namespace": "module", "namespace": "module",
"identifier": "ietf-comi", "identifier": "ietf-coreconf",
"sid": 1000 "sid": 1000
}, },
{ {
"namespace": "identity", "namespace": "identity",
"identifier": "bad-element", "identifier": "bad-element",
"sid": 1001 "sid": 1001
}, },
{ {
"namespace": "identity", "namespace": "identity",
"identifier": "data-missing", "identifier": "data-missing",
skipping to change at page 49, line 33 skipping to change at page 51, line 11
"identifier": "unified", "identifier": "unified",
"sid": 1029 "sid": 1029
}, },
{ {
"namespace": "identity", "namespace": "identity",
"identifier": "unknown-element", "identifier": "unknown-element",
"sid": 1023 "sid": 1023
}, },
{ {
"namespace": "data", "namespace": "data",
"identifier": "/ietf-comi:error", "identifier": "/ietf-coreconf:error",
"sid": 1024 "sid": 1024
}, },
{ {
"namespace": "data", "namespace": "data",
"identifier": "/ietf-comi:error/error-app-tag", "identifier": "/ietf-coreconf:error/error-app-tag",
"sid": 1025 "sid": 1025
}, },
{ {
"namespace": "data", "namespace": "data",
"identifier": "/ietf-comi:error/error-data-node", "identifier": "/ietf-coreconf:error/error-data-node",
"sid": 1026 "sid": 1026
}, },
{ {
"namespace": "data", "namespace": "data",
"identifier": "/ietf-comi:error/error-message", "identifier": "/ietf-coreconf:error/error-message",
"sid": 1027 "sid": 1027
}, },
{ {
"namespace": "data", "namespace": "data",
"identifier": "/ietf-comi:error/error-tag", "identifier": "/ietf-coreconf:error/error-tag",
"sid": 1028 "sid": 1028
} }
] ]
} }
Authors' Addresses Authors' Addresses
Michel Veillette (editor) Michel Veillette (editor)
Trilliant Networks Inc. Trilliant Networks Inc.
610 Rue du Luxembourg 610 Rue du Luxembourg
 End of changes. 254 change blocks. 
745 lines changed or deleted 796 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/