< draft-ietf-core-comi-06.txt   draft-ietf-core-comi-07.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: January 10, 2020 consultant Expires: January 23, 2020 consultant
A. Pelov A. Pelov
Acklio Acklio
A. Bierman A. Bierman
YumaWorks YumaWorks
I. Petrov, Ed. I. Petrov, Ed.
Acklio Acklio
July 09, 2019 July 22, 2019
CoAP Management Interface CoAP Management Interface
draft-ietf-core-comi-06 draft-ietf-core-comi-07
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 (CoMI). 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. CoMI uses the YANG to CBOR mapping and converts
YANG identifier strings to numeric identifiers for payload size YANG identifier strings to numeric identifiers for payload size
reduction. The complete solution composed of CoMI, reduction. The complete solution composed of CoMI,
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 10, 2020. This Internet-Draft will expire on January 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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' Uri-Query option . . . . . . . . . . . . . 13
4.2. Data Retrieval . . . . . . . . . . . . . . . . . . . . . 14 4.2. Data Retrieval . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Using the 'c' Uri-Query option . . . . . . . . . . . 14 4.2.1. Using the 'c' Uri-Query option . . . . . . . . . . . 14
4.2.2. Using the 'd' Uri-Query option . . . . . . . . . . . 15 4.2.2. Using the 'd' Uri-Query option . . . . . . . . . . . 15
4.2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Data Editing . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Data Editing . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Data Ordering . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Data Ordering . . . . . . . . . . . . . . . . . . . . 19
4.3.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.4. iPATCH . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.4. iPATCH . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Full datastore access . . . . . . . . . . . . . . . . . . 23 4.4. Full datastore access . . . . . . . . . . . . . . . . . . 23
4.4.1. Full datastore examples . . . . . . . . . . . . . . . 23 4.4.1. Full datastore examples . . . . . . . . . . . . . . . 23
4.5. Event stream . . . . . . . . . . . . . . . . . . . . . . 24 4.5. Event stream . . . . . . . . . . . . . . . . . . . . . . 24
4.5.1. Notify Examples . . . . . . . . . . . . . . . . . . . 25 4.5.1. Notify Examples . . . . . . . . . . . . . . . . . . . 25
4.5.2. The 'f' Uri-Query option . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 27
5. Use of Block-wise Transfers . . . . . . . . . . . . . . . . . 29 5. Use of Block-wise Transfers . . . . . . . . . . . . . . . . . 29
6. Application Discovery . . . . . . . . . . . . . . . . . . . . 29 6. Application Discovery . . . . . . . . . . . . . . . . . . . . 29
6.1. YANG library . . . . . . . . . . . . . . . . . . . . . . 29 6.1. YANG library . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 30 6.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 30
6.2.1. Datastore Resource Discovery . . . . . . . . . . . . 30 6.2.1. Datastore Resource Discovery . . . . . . . . . . . . 30
6.2.2. Data node Resource Discovery . . . . . . . . . . . . 30 6.2.2. Data node Resource Discovery . . . . . . . . . . . . 31
6.2.3. Event stream Resource Discovery . . . . . . . . . . . 31 6.2.3. Event stream Resource Discovery . . . . . . . . . . . 31
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9.1. Resource Type (rt=) Link Target Attribute Values Registry 35 9.1. Resource Type (rt=) Link Target Attribute Values Registry 35
9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 36 9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 36
9.3. Media Types Registry . . . . . . . . . . . . . . . . . . 36 9.3. Media Types Registry . . . . . . . . . . . . . . . . . . 36
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . 38
skipping to change at page 7, line 31 skipping to change at page 7, line 31
all' and 'trip' options are supported. all' and 'trip' 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 are used instead of these strings. YANG CoMI, numeric identifiers are used instead of these strings. YANG
Schema Item iDentifier (SID) is defined in [I-D.ietf-core-yang-cbor] Schema Item iDentifier (SID) is defined in [I-D.ietf-core-yang-cbor]
section 2.1. section 2.1.
When used in a URI, SIDs are encoded in base64 using the URL and When used in a URI, SIDs are encoded using base64 encoding of the SID
Filename safe alphabet as defined by [RFC4648] section 5, without bytes. The base64 encoding is using the URL and Filename safe
padding. The last 6 bits encoded is always aligned with the least alphabet as defined by [RFC4648] section 5, without padding. The
significant 6 bits of the SID represented using an unsigned integer. last 6 bits encoded is always aligned with the least significant 6
'A' characters (value 0) at the start of the resulting string are bits of the SID represented using an unsigned integer. 'A'
removed. characters (value 0) at the start of the resulting string are
removed. See Figure 2 for complete illustration.
SID in base64 = URLsafeChar[SID >> 60 & 0x3F] | SID in base64 = URLsafeChar[SID >> 60 & 0x3F] |
URLsafeChar[SID >> 54 & 0x3F] | URLsafeChar[SID >> 54 & 0x3F] |
URLsafeChar[SID >> 48 & 0x3F] | URLsafeChar[SID >> 48 & 0x3F] |
URLsafeChar[SID >> 42 & 0x3F] | URLsafeChar[SID >> 42 & 0x3F] |
URLsafeChar[SID >> 36 & 0x3F] | URLsafeChar[SID >> 36 & 0x3F] |
URLsafeChar[SID >> 30 & 0x3F] | URLsafeChar[SID >> 30 & 0x3F] |
URLsafeChar[SID >> 24 & 0x3F] | URLsafeChar[SID >> 24 & 0x3F] |
URLsafeChar[SID >> 18 & 0x3F] | URLsafeChar[SID >> 18 & 0x3F] |
URLsafeChar[SID >> 12 & 0x3F] | URLsafeChar[SID >> 12 & 0x3F] |
URLsafeChar[SID >> 6 & 0x3F] | URLsafeChar[SID >> 6 & 0x3F] |
URLsafeChar[SID & 0x3F] URLsafeChar[SID & 0x3F]
Figure 2
For example, SID 1721 is encoded as follow. For example, SID 1721 is encoded as follow.
URLsafeChar[1721 >> 60 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 60 & 0x3F] = URLsafeChar[0] = 'A'
URLsafeChar[1721 >> 54 & 0x3F] = URLsafeChar[0] = 'A' URLsafeChar[1721 >> 54 & 0x3F] = URLsafeChar[0] = 'A'
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'
skipping to change at page 17, line 4 skipping to change at page 17, line 14
REQ: GET example.com/c/a5 REQ: GET example.com/c/a5
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor)
{ {
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
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 example.com/c/X9
RES: 2.05 Content (Content-Format: application/yang-data+cbor) RES: 2.05 Content (Content-Format: application/yang-data+cbor)
{ {
1533 : [ 1533 : [
skipping to change at page 24, line 43 skipping to change at page 24, line 43
[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, specifying the /s
resource when the default stream is selected. resource when the default stream is selected.
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 is 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.
The format of notification contents is defined in The format of notification without any content is a null value. The
[I-D.ietf-core-yang-cbor] section 4.2.1. For notification without format of single notification is defined in [I-D.ietf-core-yang-cbor]
any content, a null value is returned. section 4.2.1. For multiple notifications the format is an array
where each element is a single notification as described in
[I-D.ietf-core-yang-cbor] section 4.2.1.
FORMAT:
GET /<stream-resource> Observe(0)
2.05 Content (Content-Format: application/yang-instances+cbor)
A CBOR map or a CBOR array of CBOR map of instance-identifier, instance-value
The array of data node instances may contain identical entries which
have been generated at different times.
An example implementation is: An example implementation is:
Every time an event is generated, the generated notification Every time an event is generated, the generated notification
instance is appended to the chosen stream(s). After an instance is appended to the chosen stream(s). After an
aggregation period, which may be adjusted using an exclusion delay aggregation period, which may be adjusted using an exclusion delay
and limited by the maximum number of notifications supported, the and limited by the maximum number of notifications supported, the
content of the instance is sent to all clients observing the content of the instance is sent to all clients observing the
modified stream. modified stream.
FORMAT:
GET /<stream-resource> Observe(0)
2.05 Content (Content-Format: application/yang-instances+cbor)
CBOR array of CBOR map of instance-identifier, instance-value
The array of data node instances may contain identical entries which
have been generated at different times.
4.5.1. Notify Examples 4.5.1. Notify Examples
Let suppose the server generates the example-port-fault event as Let suppose the server generates the example-port-fault event as
defined below. defined below.
module example-port { module example-port {
... ...
notification example-port-fault { // SID 60010 notification example-port-fault { // SID 60010
description description
"Event generated if a hardware fault is detected"; "Event generated if a hardware fault is detected";
skipping to change at page 29, line 50 skipping to change at page 29, line 50
6.1. YANG library 6.1. YANG library
The YANG library data model [I-D.veillette-core-yang-library] The YANG library data model [I-D.veillette-core-yang-library]
provides a high level description of the resources available. The provides a high level description of the resources available. The
YANG library contains the list of modules, features and deviations YANG library contains the list of modules, features and deviations
supported by the CoMI server. From this information, CoMI clients supported by the CoMI server. From this information, CoMI clients
can infer the list of data nodes supported and the interaction model can infer the list of data nodes supported and the interaction model
to be used to access them. This module also contains the list of to be used to access them. This module also contains the list of
datastores implemented. datastores implemented.
The location of the YANG library can be found by sending a GET As described in [RFC6690], the location of the YANG library can be
request to "/.well-known/core" including a resource type (RT) found by sending a GET request to "/.well-known/core" including a
parameter with the value "core.c.yl". Upon success, the return resource type (RT) parameter with the value "core.c.yl". Upon
payload will contain the root resource of the YANG library module. success, the return payload will contain the root resource of the
YANG library module.
The following example assumes that the SID of the YANG library is
2351 (kv encoded as specified in Section 2.2).
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
Even if the YANG library provides all the information needed for As some CoAP interfaces and services might not support the YANG
application discovery once it is itself discovered, other types of library interface and still be interested to discover resources that
resources could be discovered using the implementation of Resource are available, implementations MAY choose to support discovery of all
discovery as defined by [RFC6690]. This can be desirable for a available resources using "/.well-known/core" as defined by
seamless integration with other CoAP interfaces and services. [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 CoMI 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. For other examples of datastores, see the attribute is set to 1029 as specified in Appendix B. For other
Network Management Datastore Architecture (NMDA) [RFC7950]. examples of datastores, see the Network Management Datastore
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: For example:
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
6.2.2. Data node Resource Discovery 6.2.2. Data node Resource Discovery
The presence and location of (path to) each data node implemented by If implemented, the presence and location of (path to) each data node
the CoMI server are discovered by sending a GET request to "/.well- implemented by the CoMI server are discovered by sending a GET
known/core" including a resource type (RT) parameter with the value request to "/.well-known/core" including a resource type (RT)
"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.
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. Implementations MAY return a subset of this list prohibitively long. If this is the case implementations SHOULD
or can rely solely on the YANG library. support a way to obtain all links using multiple GET requests (for
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 CoMI 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.
skipping to change at page 32, line 38 skipping to change at page 32, line 43
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 CoMI
server during a block transfer request, see [RFC7959] for more server during a block transfer request, see [RFC7959] for more
details. details.
o Error 4.15 (Unsupported Content-Format) is returned by the CoMI o Error 4.15 (Unsupported Content-Format) is returned by the CoMI
server when the Content-Format used in the request does not match server when the Content-Format used in the request does not match
those specified in section Section 2.4. those specified in section Section 2.4.
CoMI server MUST also enforce the different constraints associated to The CoMI server MUST also enforce the different constraints
the YANG data models implemented. These constraints are described in associated to the YANG data models implemented. These constraints
[RFC7950] section 8. These errors are reported using the CoAP error are described in [RFC7950] section 8. These errors are reported
code 4.00 (Bad Request) and may have the following error container as using the CoAP error code 4.00 (Bad Request) and may have the
payload. The YANG definition and associated .sid file are available following error container as payload. The YANG definition and
in Appendix A and Appendix B. The error container is encoded using associated .sid file are available in Appendix A and Appendix B. The
the encoding rules of a YANG data template as defined in error container is encoded using the encoding rules of a YANG data
[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-comi YANG module, these tags are implemented as YANG identity
and can be extended as needed. and can be extended as needed.
skipping to change at page 33, line 43 skipping to change at page 33, line 49
* error-app-tag 'duplicate' is returned by the CoMI server when a * error-app-tag 'duplicate' is returned by the CoMI server when a
client tries to create a duplicate list or leaf-list entry. 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 CoMI server when the
CoMI client tries to update or create a leaf with a value encoded CoMI client tries to update or create a leaf with a value encoded
using an invalid CBOR datatype or if the 'range', 'length', using an invalid CBOR datatype or if the 'range', 'length',
'pattern' or 'require-instance' constrain is not fulfilled. '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 CoMI server
when CBOR encoding does not follow the rules set by or when the when CBOR encoding does not follow the rules set by the YANG
value is incompatible with the YANG Built-In type (e.g. a value Build-In type or when the value is incompatible with it (e.g. a
greater than 127 for an int8, undefined enumeration) 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 CoMI 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 CoMI server
when the validation of the 'length' property fails. 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 CoMI
server when the validation of the 'pattern' property fails. server when the validation of the 'pattern' property fails.
skipping to change at page 35, line 27 skipping to change at page 35, line 32
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. CoMI re-uses the
security mechanisms already available to CoAP, this includes DTLS security mechanisms already available to CoAP, this includes DTLS
[RFC6347] for protected access to resources, as well suitable [RFC6347] for protected access to resources, as well suitable
authentication and authorization mechanisms. authentication and authorization mechanisms.
Among the security decisions that need to be made are selecting Among the security decisions that need to be made are selecting
security modes and encryption mechanisms (see [RFC7252]). This security modes and encryption mechanisms (see [RFC7252]).
requires a trade-off, as the NoKey mode gives no protection at all,
but is easy to implement, whereas the Certificate mode is quite
secure, but may be too complex for constrained devices.
In addition, mechanisms for authentication and authorization may need In addition, mechanisms for authentication and authorization may need
to be selected in case NoKey is used. to be selected if not provided with the security mode.
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 38, line 48 skipping to change at page 38, line 48
iDentifier (SID)", draft-ietf-core-sid-07 (work in iDentifier (SID)", draft-ietf-core-sid-07 (work in
progress), July 2019. progress), July 2019.
[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-10 Data Modeled with YANG", draft-ietf-core-yang-cbor-10
(work in progress), April 2019. (work in progress), April 2019.
[I-D.veillette-core-yang-library] [I-D.veillette-core-yang-library]
Veillette, M. and I. Petrov, "Constrained YANG Module Veillette, M. and I. Petrov, "Constrained YANG Module
Library", draft-veillette-core-yang-library-04 (work in Library", draft-veillette-core-yang-library-05 (work in
progress), March 2019. progress), July 2019.
[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>.
[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>.
 End of changes. 21 change blocks. 
59 lines changed or deleted 70 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/