Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is athttps://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 11 January 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

The Constrained Application Protocol (CoAP)[RFC7252] is designed forMachine to Machine (M2M) applications such as smart energy, smart city, and building control.Constrained devices need to be managed in an automatic fashion to handlethe large quantities of devices that are expected infuture installations. Messages between devices need to be as small andinfrequent as possible. The implementationcomplexity and runtime resources need to be as small as possible.¶

This draft describes the CoAP Management Interface (CORECONF) which uses CoAP methodsto access structured data defined in YANG[RFC7950]. This draft iscomplementary to[RFC8040] which describes a REST-like interfacecalled RESTCONF, which uses HTTP methods to access structured datadefined in YANG.¶

The use of standardized data models specified in a standardized language, suchas YANG, promotes interoperability between devices and applications fromdifferent manufacturers.¶

CORECONF and RESTCONF are intended to work in a stateless client-server fashion.They use a single round-trip to complete a single editing transaction, whereNETCONF needs multiple round trips.¶

To promote small messages, CORECONF uses a YANG to CBOR mapping[RFC9254] and numeric identifiers[I-D.ietf-core-sid]to minimize CBOR payloads and URI length.¶

2.CORECONF Architecture

This section describes the CORECONF architecture to use CoAP for reading andmodifying the content of datastore(s) used for the management of the instrumentednode.¶

Figure 1 is a high-level representation of the main elements of the CORECONF managementarchitecture. The different numbered components ofFigure 1 are discussed according to the component number.¶

(1) YANG specification:

contains a set of named and versioned modules.¶

(2) SMIv2 specification:

Optional part that consists of a named module which, specifies a set of variables and "conceptual tables". Thereis an algorithm to translate SMIv2 specifications to YANG specifications.¶

(3) CoAP request/response messages:

The CORECONF client sends request messages to and receives response messagesfrom the CORECONF server.¶

(4) Request, Indication, Response, Confirm:

Processes performed by the CORECONF clients and servers.¶

(5) Datastore:

A resource used to access configuration data, state data, RPCs, and actions. A CORECONF server may support a single unified datastore or multiple datastores as those defined by Network Management Datastore Architecture (NMDA)[RFC8342].¶

(6) Event stream:

A resource used to get real-time notifications. A CORECONF server may support multiple Event streams serving different purposes such as normal monitoring, diagnostic, syslog, security monitoring.¶

(7) Security:

The serverMUST prevent unauthorized users from reading or writing any CORECONFresources. CORECONF relies on security protocols such as DTLS[RFC6347][RFC9147] or OSCORE[RFC8613] to secure CoAP communications.¶

3.CoAP Interface

This document specifies a Management Interface. CoAP endpoints thatimplement the CORECONF management protocol, supportat least one discoverable management resource of resource type (rt): core.c.ds.The path of the discoverable management resource is left to implementers toselect (seeSection 5).¶

YANG data node instances are accessible by performing FETCH and iPATCHoperations on the datastore resource.¶

CORECONF also supports event stream resources used to observe notification instances.Event stream resources can be discovered using resource type (rt): core.c.ev.¶

The description of the CORECONF management interface is shown in the table below:¶

The path values in the table are example ones. On discovery, the server makesthe actual path values known for these resources.¶

The methods used by CORECONF are:¶

FORMAT:  FETCH <datastore resource>        (Content-Format: application/yang-identifiers+cbor-seq)  CBOR sequence of instance-identifiers  2.05 Content (Content-Format: application/yang-instances+cbor-seq)  CBOR sequence of CBOR maps of SID, instance-value

REQ: FETCH </c>     (Content-Format: application/yang-identifiers+cbor-seq)1723,            / current-datetime (SID 1723) /[1533, "eth0"]   / interface (SID 1533) with name = "eth0" /RES: 2.05 Content     (Content-Format: application/yang-instances+cbor-seq){  1723 : "2014-10-26T12:16:31Z" / current-datetime (SID 1723) /},{  1533 : {     4 : "eth0",              / name (SID 1537) /     1 : "Ethernet adaptor",  / description (SID 1534) /     5 : 1880,                / type (SID 1538), identity /                              / ethernetCsmacd (SID 1880) /     2 : true,                / enabled (SID 1535) /    11 : 3             / oper-status (SID 1544), value is testing /  }}

FORMAT:  iPATCH <datastore resource>         (Content-Format: application/yang-instances+cbor-seq)  CBOR sequence of CBOR maps of instance-identifier, instance-value  2.04 Changed

REQ: iPATCH </c>     (Content-Format: application/yang-instances+cbor-seq){  1755 : true                   / enabled (SID 1755) /},{  [1756, "tac.nrc.ca"] : null   / server (SID 1756) /},{  1756 : {                      / server (SID 1756) /    3 : "tic.nrc.ca",           / name (SID 1759) /    4 : true,                   / prefer (SID 1760) /    5 : {                       / udp (SID 1761) /      1 : "132.246.11.231"      / address (SID 1762) /    }  }}RES: 2.04 Changed

FORMAT:  GET <datastore resource>  2.05 Content (Content-Format: application/yang-data+cbor; id=sid)  CBOR map of SID, instance-value

FORMAT:  PUT <datastore resource>      (Content-Format: application/yang-data+cbor; id=sid)  CBOR map of SID, instance-value  2.04 Changed

FORMAT:  POST <datastore resource>       (Content-Format: application/yang-data+cbor; id=sid)  CBOR map of SID, instance-value  2.01 Created

FORMAT:  DELETE <datastore resource>  2.02 Deleted

REQ:  GET </c>RES: 2.05 Content     (Content-Format: application/yang-data+cbor; id=sid){  1721 : {                      / Clock (SID 1721) /    2: "2016-10-26T12:16:31Z",  / current-datetime (SID 1723) /    1: "2014-10-05T09:00:00Z"   / boot-datetime (SID 1722) /  },  1533 : [    {                           / interface (SID 1533) /       4 : "eth0",              / name (SID 1537) /       1 : "Ethernet adaptor",  / description (SID 1534) /       5 : 1880,                / type (SID 1538), identity: /                                / ethernetCsmacd (SID 1880) /       2 : true,                / enabled (SID 1535) /      11 : 3             / oper-status (SID 1544), value is testing /    }  ]}

FORMAT:  GET <stream-resource> Observe(0)  2.05 Content (Content-Format: application/yang-instances+cbor-seq)  CBOR sequence of CBOR maps of instance-identifier, instance-value

module example-port {  yang-version 1.1;  namespace "https://example.com/ns/example-port";  prefix "port";  notification example-port-fault {   // SID 60010    description      "Event generated if a hardware fault is detected";    leaf port-name {                  // SID 60011      type string;    }    leaf port-fault {                 // SID 60012      type string;    }  }}

REQ:  GET </s> Observe(0)RES:  2.05 Content      (Content-Format: application/yang-instances+cbor-seq)      Observe(12){  60010 : {             / example-port-fault (SID 60010) /    1 : "0/4/21",       / port-name (SID 60011) /    2 : "Open pin 2"    / port-fault (SID 60012) /  }},{  60010 : {             / example-port-fault (SID 60010) /    1 : "1/4/21",       / port-name (SID 60011) /    2 : "Open pin 5"    / port-fault (SID 60012) /  }}

REQ:  GET </s?f=60010,60020> Observe(0)

FORMAT:  POST <datastore resource>         (Content-Format: application/yang-instances+cbor-seq)  CBOR sequence of CBOR maps of instance-identifier, instance-value  2.04 (Content-Format: application/yang-instances+cbor-seq)  CBOR sequence of CBOR maps of instance-identifier, instance-value

module example-ops {  yang-version 1.1;  namespace "https://example.com/ns/example-ops";  prefix "ops";  rpc reboot {                          // SID 61000    description "Reboot operation.";    input {                             // SID 61009      leaf delay {                      // SID 61001        type uint32;        units "seconds";        default 0;        description          "Number of seconds to wait before initiating the           reboot operation.";      }    }  }}

REQ:  POST </c>      (Content-Format: application/yang-instances+cbor-seq){ 61000:  {    1 : 77  }}RES:  2.04 Changed      (Content-Format: application/yang-instances+cbor-seq){ 61000:  null}

module example-server-farm {  yang-version 1.1;  namespace "urn:example:server-farm";  prefix "sfarm";  import ietf-yang-types {    prefix "yang";  }  list server {                        // SID 60000    key name;    leaf name {                        // SID 60001      type string;    }    action reset {                     // SID 60002      input {                          // SID 60008        leaf reset-at {                // SID 60003          type yang:date-and-time;          mandatory true;        }      }      output {                         // SID 60009        leaf reset-finished-at {       // SID 60004          type yang:date-and-time;          mandatory true;        }      }    }  }}

REQ:  POST </c>      (Content-Format: application/yang-instances+cbor-seq){ [60002, "myserver"]:  {    0 : { / SID 60002 XXX does this need to be input? /      1 : "2016-02-08T14:10:08Z09:00" / reset-at (SID 60003) /    }  }}RES:  2.04 Changed         (Content-Format: application/yang-instances+cbor-seq){ [60002, "myserver"]:  {    0 : { / SID 60002 XXX does this need to be output? /      2 : "2016-02-08T14:10:08Z" / reset-finished-at (SID 60004)/    }  }}

4.Use of Block-wise Transfers

The CoAP protocol provides reliability by acknowledging the UDP datagrams.However, when large pieces of data need to be transported, datagrams getfragmented, thus creating constraints on the resources in the client, serverand intermediate routers. The block option[RFC7959] allows the transportof the total payload in individual blocks of which thesize can be adapted to the underlying transport sizes such as: (UDP datagramsize ~64KiB, IPv6 MTU of 1280, IEEE 802.15.4 payload of 60-80 bytes). Eachblock is individually acknowledged to guarantee reliability.¶

Notice that the Block mechanism splits the data at fixed positions,such that individual data fields may become fragmented. Therefore, assemblyof multiple blocks may be required to process complete data fields.¶

Beware of race conditions. In case blocks are filled one at a time, care shouldbe taken that the whole and consistent data representation is sent in multiple blocks sequentiallywithout interruption. On the server, values might change, lists might get re-ordered,extended or reduced. When these actions happen during the serialization ofthe contents of the resource, the transported results do not correspond witha state having occurred in the server; or worse the returned values are inconsistent.For example: array length does not correspond with the actual number of items.It may be advisable to use Indefinite-length CBOR arrays and maps,which are foreseen for data streaming purposes.(Note that the outer structure of yang-identifiers and yang-instancesis a CBOR sequence, which already behaves similar to anindefinite-length encoded array.)¶

5.Application Discovery

Two application discovery mechanisms are supported by CORECONF, the YANG librarydata model as defined by[I-D.ietf-core-yang-library] andthe CORE resource discovery[RFC6690].Implementers may choose to implement one or the other or both.¶

REQ: GET </.well-known/core?rt=core.c.yl>RES: 2.05 Content (Content-Format: application/link-format)</c/kv>;rt="core.c.yl"

link-extension    = ( "ds" "=" sid )                    ; SID assigned to the datastore identitysid               = 1*DIGIT

REQ: GET </.well-known/core?rt=core.c.ds>RES: 2.05 Content (Content-Format: application/link-format)</c>; rt="core.c.ds";ds=1029

REQ: GET </.well-known/core?rt=core.c.dn>RES: 2.05 Content (Content-Format: application/link-format)</c/a6>;rt="core.c.dn",</c/a7>;rt="core.c.dn"

REQ: GET </.well-known/core?rt=core.c.es>RES: 2.05 Content (Content-Format: application/link-format)</s>;rt="core.c.es"

6.Error Handling

In case a request is received which cannot be processed properly, the CORECONF serverMUST return an error response. This error responseMUST contain a CoAP 4.xx or 5.xx response code.¶

Errors returned by a CORECONF server can be broken into two categories, those associated with the CoAP protocol itself and those generated during the validation of the YANG data model constraints as described inSection 8 of [RFC7950].¶

The following list of common CoAP errors should be implemented by CORECONF servers. This list is not exhaustive, other errors defined by CoAP and associated RFCs may be applicable.¶

• Error 4.01 (Unauthorized) is returned by the CORECONF server when the CORECONF client is not authorized to perform the requested action on the targeted resource (i.e., data node, datastore, rpc, action or event stream).¶
• Error 4.02 (Bad Option) is returned by the CORECONF server when one or more CoAP options are unknown or malformed.¶
• Error 4.04 (Not Found) is returned by the CORECONF server when the CORECONF client is requesting a non-instantiated resource (i.e., data node, datastore, rpc, action or event stream).¶
• Error 4.05 (Method Not Allowed) is returned by the CORECONF server when the CORECONF client is requesting a method not supported on the targeted resource. (e.g., GET on an rpc, PUT or POST on a data node with "config" set to false).¶
• Error 4.08 (Request Entity Incomplete) is returned by the CORECONF server if one or multiple blocks of a block transfer request is missing, see[RFC7959] for more details.¶
• Error 4.13 (Request Entity Too Large) may be returned by the CORECONF server during a block transfer request, see[RFC7959] for more details.¶
• Error 4.15 (Unsupported Content-Format) is returned by the CORECONF server when the Content-Format used in the request does not match those specified inSection 2.3.¶

The CORECONF serverMUST also enforce the different constraints associated with the YANG data models implemented. These constraints are described inSection 8 of [RFC7950]. These errors are reported using the CoAP error code 4.00 (Bad Request) and may have the following error container as payload. The YANG definition and associated .sid file are available inAppendix A andAppendix B. The error container is encoded using the encoding rules of a YANG data template as defined inSection 5 of [RFC9254].¶

+--rw error!   +--rw error-tag             identityref   +--rw error-app-tag?        identityref   +--rw error-data-node?      instance-identifier   +--rw error-message?        string

The following 'error-tag' and 'error-app-tag' are defined by the ietf-coreconf YANG module, these tags are implemented as YANG identity and can be extended as needed.¶

• error-tag 'operation-failed' is returned by the CORECONF server when the operation request cannot be processed successfully.¶

  • error-app-tag 'malformed-message' is returned by the CORECONF server when the payload received from the CORECONF client does not contain a well-formed CBOR content as defined in[RFC8949] or does not comply with the CBOR structure defined within this document.¶
  • error-app-tag 'data-not-unique' is returned by the CORECONF server when the validation of the 'unique' constraint of a list or leaf-list fails.¶
  • error-app-tag 'too-many-elements' is returned by the CORECONF server when the validation of the 'max-elements' constraint of a list or leaf-list fails.¶
  • error-app-tag 'too-few-elements' is returned by the CORECONF server when the validation of the 'min-elements' constraint of a list or leaf-list fails.¶
  • error-app-tag 'must-violation' is returned by the CORECONF server when the restrictions imposed by a 'must' statement are violated.¶
  • error-app-tag 'duplicate' is returned by the CORECONF server when a client tries to create a duplicate list or leaf-list entry.¶

• error-tag 'invalid-value' is 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.¶

  • error-app-tag 'invalid-datatype' is returned by the CORECONF server when CBOR encoding does not follow the rules set by the YANG Build-In type or when the value is incompatible with it (e.g., a value greater than 127 for an int8, undefined enumeration).¶
  • error-app-tag 'not-in-range' is returned by the CORECONF server when the validation of the 'range' property fails.¶
  • error-app-tag 'invalid-length' is returned by the CORECONF server when the validation of the 'length' property fails.¶
  • error-app-tag 'pattern-test-failed' is returned by the CORECONF server when the validation of the 'pattern' property fails.¶

• error-tag 'missing-element' is returned by the CORECONF server when the operation requested by a CORECONF client fails to comply with the 'mandatory' constraint defined. The 'mandatory' constraint is enforced for leafs and choices, unless the node or any of its ancestors have a 'when' condition or 'if-feature' expression that evaluates to 'false'.¶

  • error-app-tag 'missing-key' is returned by the CORECONF server to further qualify a 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'.¶
  • error-app-tag 'missing-input-parameter' is returned by the CORECONF server when the input parameters of an RPC or action are incomplete.¶
• error-tag 'unknown-element' is returned by the CORECONF server when the CORECONF client tries to access a data node of a YANG module not supported, of a data node associated with an 'if-feature' expression evaluated to 'false' or to a 'when' condition evaluated to 'false'.¶
• error-tag 'bad-element' is returned by the CORECONF server when the CORECONF client tries to create data nodes for more than one case in a choice.¶

• error-tag 'data-missing' is returned by the CORECONF server when a data node required to accept the request is not present.¶

  • error-app-tag 'instance-required' is returned by the CORECONF server when a leaf of type 'instance-identifier' or 'leafref' marked with require-instance set to 'true' refers to an instance that does not exist.¶
  • error-app-tag 'missing-choice' is returned by the CORECONF server when no nodes exist in a mandatory choice.¶
• error-tag 'error' is returned by the CORECONF server when an unspecified error has occurred.¶

For example, the CORECONF server might return the following error.¶

RES:  4.00 Bad Request     (Content-Format: application/yang-data+cbor; id=sid){  1024 : {    4 : 1011,        / error-tag (SID 1028) /                     /   = invalid-value (SID 1011) /    1 : 1018,        / error-app-tag (SID 1025) /                     /   = not-in-range (SID 1018) /    2 : 1740,        / error-data-node (SID 1026) /                     /   = timezone-utc-offset (SID 1740) /    3 : "maximum value exceeded" / error-message (SID 1027) /  }}

I don't quite know how to use application/yang-instances+cbor-seq here, if we don't have an instance?¶

7.Security Considerations

For secure network management, it is important to restrict access to configuration variablesonly to authorized parties. CORECONF re-uses the security mechanisms already available to CoAP,this includes DTLS[RFC6347][RFC9147] and OSCORE[RFC8613] for protected access toresources, as well as suitable authentication and authorization mechanisms, forexample those defined in ACE OAuth[RFC9200].¶

All the security considerations of[RFC7252],[RFC7959],[RFC8132] and[RFC7641] apply to this document as well. The use of NoSec (Section 9 of [RFC7252]), when OSCOREis not used, isNOT RECOMMENDED.¶

In addition, mechanisms for authentication and authorization may need to beselected if not provided with the CoAP security mode.¶

As[RFC9254] and[RFC4648] are used for payload and SIDencoding, the security considerations of those documents also need to bewell-understood.¶

8.IANA Considerations

*  Deprecated alias names for this type: N/A*  Magic number(s): N/A*  File extension(s): N/A*  Macintosh file type code(s): N/A

Appendix A.ietf-coreconf YANG module

<CODE BEGINS> file "ietf-coreconf@2023-07-10.yang"module ietf-coreconf {  yang-version 1.1;  namespace "urn:ietf:params:xml:ns:yang:ietf-coreconf";  prefix coreconf;  import ietf-datastores {    prefix ds;  }  import ietf-restconf {    prefix rc;    description      "This import statement is required to access       the yang-data extension defined in RFC 8040.";    reference "RFC 8040: RESTCONF Protocol";  }  organization    "IETF Core Working Group";  contact    "Michel Veillette     <mailto:michel.veillette@trilliantinc.com>     Alexander Pelov     <mailto:alexander@ackl.io>     Peter van der Stok     <mailto:consultancy@vanderstok.org>     Andy Bierman     <mailto:andy@yumaworks.com>";  description    "This module contains the different definitions required     by the CORECONF protocol.     Copyright (c) 2019 IETF Trust and the persons identified as     authors of the code.  All rights reserved.     Redistribution and use in source and binary forms, with or     without modification, is permitted pursuant to, and subject to     the license terms contained in, the Simplified BSD License set     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;     see the RFC itself for full legal notices.";  revision 2023-07-10 {     description      "Initial revision.";    reference      "[I-D.ietf-core-comi] CoAP Management Interface";  }  identity unified {    base ds:datastore;    description      "Identifier of the unified configuration and operational       state datastore.";  }  identity error-tag {    description      "Base identity for error-tag.";  }  identity operation-failed {    base error-tag;    description      "Returned by the CORECONF server when the operation request       can't be processed successfully.";  }  identity invalid-value {    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 {    base error-tag;    description      "Returned by the CORECONF server when the operation requested       by a CORECONF client fails to comply with the 'mandatory'       constraint defined. The 'mandatory' constraint is       enforced for leafs and choices, unless the node or any of       its ancestors have a 'when' condition or 'if-feature'       expression that evaluates to 'false'.";  }  identity unknown-element {    base error-tag;    description      "Returned by the CORECONF server when the CORECONF client tries       to access a data node of a YANG module not supported, of a       data node associated with an 'if-feature' expression       evaluated to 'false' or to a 'when' condition evaluated       to 'false'.";  }  identity bad-element {    base error-tag;    description      "Returned by the CORECONF server when the CORECONF client tries       to create data nodes for more than one case in a choice.";  }  identity data-missing {    base error-tag;    description      "Returned by the CORECONF server when a data node required to       accept the request is not present.";  }  identity error {    base error-tag;    description      "Returned by the CORECONF server when an unspecified error has      occurred.";  }  identity error-app-tag {    description      "Base identity for error-app-tag.";  }  identity malformed-message {    base error-app-tag;    description      "Returned by the CORECONF server when the payload received       from the CORECONF client don't contain a well-formed CBOR       content as defined in [RFC8949] or don't       comply with the CBOR structure defined within this       document.";  }  identity data-not-unique {    base error-app-tag;    description      "Returned by the CORECONF server when the validation of the       'unique' constraint of a list or leaf-list fails.";  }  identity too-many-elements {    base error-app-tag;    description      "Returned by the CORECONF server when the validation of the       'max-elements' constraint of a list or leaf-list fails.";  }  identity too-few-elements {    base error-app-tag;    description      "Returned by the CORECONF server when the validation of the       'min-elements' constraint of a list or leaf-list fails.";  }  identity must-violation {    base error-app-tag;    description      "Returned by the CORECONF server when the restrictions       imposed by a 'must' statement are violated.";  }  identity duplicate {    base error-app-tag;    description      "Returned by the CORECONF server when a client tries to create       a duplicate list or leaf-list entry.";  }  identity invalid-datatype {    base error-app-tag;    description      "Returned by the CORECONF server when CBOR encoding is       incorect or when the value encoded is incompatible with       the YANG Built-In type. (e.g., value greater than 127       for an int8, undefined enumeration).";  }  identity not-in-range {    base error-app-tag;    description      "Returned by the CORECONF server when the validation of the       'range' property fails.";  }  identity invalid-length {    base error-app-tag;    description      "Returned by the CORECONF server when the validation of the       '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 missing-key {    base error-app-tag;    description      "Returned by the CORECONF server to further qualify a       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-input-parameter {    base error-app-tag;    description      "Returned by the CORECONF server when the input parameters       of a RPC or action are incomplete.";  }  identity instance-required {    base error-app-tag;    description      "Returned by the CORECONF server when a leaf of type       'instance-identifier' or 'leafref' marked with       require-instance set to 'true' refers to an instance       that does not exist.";  }  identity missing-choice {    base error-app-tag;    description      "Returned by the CORECONF server when no nodes exist in a       mandatory choice.";  }  rc:yang-data coreconf-error {    container error {      description        "Optional payload of a 4.00 Bad Request CoAP error.";      leaf error-tag {        type identityref {          base error-tag;        }        mandatory true;        description          "The enumerated error-tag.";      }      leaf error-app-tag {        type identityref {          base error-app-tag;        }        description          "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 {        type string;        description          "A message describing the error.";      }    }  }}<CODE ENDS>

Appendix B.ietf-coreconf .sid file

{  "assignment-ranges": [    {      "entry-point": 1000,      "size": 100    }  ],  "module-name": "ietf-coreconf",  "module-revision": "2023-07-10",  "items": [    {      "namespace": "module",      "identifier": "ietf-coreconf",      "sid": 1000    },    {      "namespace": "identity",      "identifier": "bad-element",      "sid": 1001    },    {      "namespace": "identity",      "identifier": "data-missing",      "sid": 1002    },    {      "namespace": "identity",      "identifier": "data-not-unique",      "sid": 1003    },    {      "namespace": "identity",      "identifier": "duplicate",      "sid": 1004    },    {      "namespace": "identity",      "identifier": "error",      "sid": 1005    },    {      "namespace": "identity",      "identifier": "error-app-tag",      "sid": 1006    },    {      "namespace": "identity",      "identifier": "error-tag",      "sid": 1007    },    {      "namespace": "identity",      "identifier": "instance-required",      "sid": 1008    },    {      "namespace": "identity",      "identifier": "invalid-datatype",      "sid": 1009    },    {      "namespace": "identity",      "identifier": "invalid-length",      "sid": 1010    },    {      "namespace": "identity",      "identifier": "invalid-value",      "sid": 1011    },    {      "namespace": "identity",      "identifier": "malformed-message",      "sid": 1012    },    {      "namespace": "identity",      "identifier": "missing-choice",      "sid": 1013    },    {      "namespace": "identity",      "identifier": "missing-element",      "sid": 1014    },    {      "namespace": "identity",      "identifier": "missing-input-parameter",      "sid": 1015    },    {      "namespace": "identity",      "identifier": "missing-key",      "sid": 1016    },    {      "namespace": "identity",      "identifier": "must-violation",      "sid": 1017    },    {      "namespace": "identity",      "identifier": "not-in-range",      "sid": 1018    },    {      "namespace": "identity",      "identifier": "operation-failed",      "sid": 1019    },    {      "namespace": "identity",      "identifier": "pattern-test-failed",      "sid": 1020    },    {      "namespace": "identity",      "identifier": "too-few-elements",      "sid": 1021    },    {      "namespace": "identity",      "identifier": "too-many-elements",      "sid": 1022    },    {      "namespace": "identity",      "identifier": "unified",      "sid": 1029    },    {      "namespace": "identity",      "identifier": "unknown-element",      "sid": 1023    },    {      "namespace": "data",      "identifier": "/ietf-coreconf:error",      "sid": 1024    },    {      "namespace": "data",      "identifier": "/ietf-coreconf:error/error-app-tag",      "sid": 1025    },    {      "namespace": "data",      "identifier": "/ietf-coreconf:error/error-data-node",      "sid": 1026    },    {      "namespace": "data",      "identifier": "/ietf-coreconf:error/error-message",      "sid": 1027    },    {      "namespace": "data",      "identifier": "/ietf-coreconf:error/error-tag",      "sid": 1028    }  ]}

Acknowledgments

We are very grateful toBert Greevenbosch who was one of the original authorsof the CORECONF specification.¶

Mehmet Ersue andBert Wijnen explained the encoding aspects of PDUs transportedunder SNMP.Koen Zandberg's implementation input motivated massively simplifying(and fixing) the URI construction for GET/PUT/POST requests.¶

The draft has further benefited from comments (alphabetical order) byRodney Cummings,Dee Denteneer,Esko Dijk,Klaus Hartke,Michael van Hartskamp,Tanguy Ropitault,Jürgen Schönwälder,Anuj Sehgal,Zach Shelby,Hannes Tschofenig,Michael Verschoor,andThomas Watteyne.¶

Contributors

Authors' Addresses