idnits 2.17.00 (12 Aug 2021) /tmp/idnits55179/draft-ietf-core-yang-cbor-19.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (20 March 2022) is 61 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-2' is mentioned on line 1274, but not defined -- Looks like a reference, but probably isn't: '257' on line 1274 == Missing Reference: '0-9' is mentioned on line 1644, but not defined == Missing Reference: '1-9' is mentioned on line 1634, but not defined == Missing Reference: '0-4' is mentioned on line 1644, but not defined == Missing Reference: '0-5' is mentioned on line 1644, but not defined -- Looks like a reference, but probably isn't: '01' on line 1644 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Veillette, Ed. 3 Internet-Draft Trilliant Networks Inc. 4 Intended status: Standards Track I. Petrov, Ed. 5 Expires: 21 September 2022 Google Switzerland GmbH 6 A. Pelov 7 Acklio 8 C. Bormann 9 Universität Bremen TZI 10 M. Richardson 11 Sandelman Software Works 12 20 March 2022 14 CBOR Encoding of Data Modeled with YANG 15 draft-ietf-core-yang-cbor-19 17 Abstract 19 Based on the Concise Binary Object Representation (CBOR, RFC 8949), 20 this document defines encoding rules for representing configuration 21 data, state data, parameters and results of Remote Procedure Call 22 (RPC) operations or actions, and notifications, defined using YANG 23 (RFC 7950). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 21 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 60 3. Properties of the CBOR Encoding . . . . . . . . . . . . . . . 5 61 3.1. CBOR diagnostic notation . . . . . . . . . . . . . . . . 6 62 3.2. YANG Schema Item iDentifier . . . . . . . . . . . . . . . 8 63 3.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Encoding of Representation Nodes . . . . . . . . . . . . . . 11 65 4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 11 67 4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 12 68 4.2. The 'container' and other nodes from the data tree . . . 12 69 4.2.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 13 70 4.2.2. Using names in keys . . . . . . . . . . . . . . . . . 14 71 4.3. The 'leaf-list' . . . . . . . . . . . . . . . . . . . . . 15 72 4.3.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 15 73 4.3.2. Using names in keys . . . . . . . . . . . . . . . . . 16 74 4.4. The 'list' and 'list' entries . . . . . . . . . . . . . . 16 75 4.4.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 17 76 4.4.2. Using names in keys . . . . . . . . . . . . . . . . . 19 77 4.5. The 'anydata' . . . . . . . . . . . . . . . . . . . . . . 21 78 4.5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 22 79 4.5.2. Using names in keys . . . . . . . . . . . . . . . . . 23 80 4.6. The 'anyxml' . . . . . . . . . . . . . . . . . . . . . . 24 81 4.6.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 24 82 4.6.2. Using names in keys . . . . . . . . . . . . . . . . . 25 83 5. Encoding of 'yang-data' extension . . . . . . . . . . . . . . 25 84 5.1. Using SIDs in keys . . . . . . . . . . . . . . . . . . . 26 85 5.2. Using names in keys . . . . . . . . . . . . . . . . . . . 27 86 6. Representing YANG Data Types in CBOR . . . . . . . . . . . . 28 87 6.1. The unsigned integer Types . . . . . . . . . . . . . . . 28 88 6.2. The integer Types . . . . . . . . . . . . . . . . . . . . 29 89 6.3. The 'decimal64' Type . . . . . . . . . . . . . . . . . . 29 90 6.4. The 'string' Type . . . . . . . . . . . . . . . . . . . . 30 91 6.5. The 'boolean' Type . . . . . . . . . . . . . . . . . . . 30 92 6.6. The 'enumeration' Type . . . . . . . . . . . . . . . . . 31 93 6.7. The 'bits' Type . . . . . . . . . . . . . . . . . . . . . 32 94 6.8. The 'binary' Type . . . . . . . . . . . . . . . . . . . . 34 95 6.9. The 'leafref' Type . . . . . . . . . . . . . . . . . . . 35 96 6.10. The 'identityref' Type . . . . . . . . . . . . . . . . . 35 97 6.10.1. SIDs as identityref . . . . . . . . . . . . . . . . 35 98 6.10.2. Name as identityref . . . . . . . . . . . . . . . . 36 99 6.11. The 'empty' Type . . . . . . . . . . . . . . . . . . . . 37 100 6.12. The 'union' Type . . . . . . . . . . . . . . . . . . . . 37 101 6.13. The 'instance-identifier' Type . . . . . . . . . . . . . 38 102 6.13.1. SIDs as instance-identifier . . . . . . . . . . . . 39 103 6.13.2. Names as instance-identifier . . . . . . . . . . . . 42 104 7. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 43 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 107 9.1. Media-Types Registry . . . . . . . . . . . . . . . . . . 45 108 9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 46 109 9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 46 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 47 112 10.2. Informative References . . . . . . . . . . . . . . . . . 48 113 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 116 1. Introduction 118 The specification of the YANG 1.1 data modeling language [RFC7950] 119 defines an XML encoding for data instances, i.e., contents of 120 configuration datastores, state data, RPC inputs and outputs, action 121 inputs and outputs, and event notifications. 123 An additional set of encoding rules has been defined in [RFC7951] 124 based on the JavaScript Object Notation (JSON) Data Interchange 125 Format [RFC8259]. 127 The aim of this document is to define a set of encoding rules for the 128 Concise Binary Object Representation (CBOR) [RFC8949], collectively 129 called _YANG-CBOR_. The resulting encoding is more compact compared 130 to XML and JSON and more suitable for Constrained Nodes and/or 131 Constrained Networks as defined by [RFC7228]. 133 2. Terminology and Notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 The following terms are defined in [RFC7950]: 143 * action 145 * anydata 147 * anyxml 149 * data node 151 * data tree 153 * datastore 155 * feature 157 * identity 159 * module 161 * notification 163 * RPC 165 * schema node 167 * submodule 169 The following term is defined in [RFC8040]: 171 * yang-data extension 173 The following term is defined in [RFC8791]: 175 * YANG data structure 177 This specification also makes use of the following terminology: 179 * YANG Schema Item iDentifier (YANG SID or simply SID): 63-bit 180 unsigned integer used to identify different YANG items. 182 * delta: Difference between the current YANG SID and a reference 183 YANG SID. A reference YANG SID is defined for each context for 184 which deltas are used. 186 * absolute SID: YANG SID not encoded as a delta. This is usually 187 called out explicitly only in positions where normally a delta 188 would be found. 190 * representation tree: a YANG data tree, possibly enclosed by a 191 representation of a schema node such as a YANG data structure, a 192 notification, an RPC, or an action. 194 * representation node: a node in a representation tree, i.e., a data 195 tree node, or a representation of a schema node such as a YANG 196 data structure, a notification, an RPC, or an action. 198 * item: A schema node, an identity, a module, or a feature defined 199 using the YANG modeling language. 201 * list entry: the data associated with a single entry of a list (see 202 Section 7.8 of [RFC7950]). 204 * parent (of a representation node): the schema node of the closest 205 enclosing representation node in which a given representation node 206 is defined. 208 3. Properties of the CBOR Encoding 210 This document defines CBOR encoding rules for YANG data trees and 211 their subtrees. 213 A YANG data tree can be enclosed by a representation of a schema node 214 such as a YANG data structure, a notification, an RPC, or an action; 215 this is called a representation tree. The data tree nodes and the 216 enclosing schema node representation, if any, are collectively called 217 the representation nodes. 219 A representation node such as container, list entry, YANG data 220 structure, notification, RPC input, RPC output, action input, or 221 action output is serialized using a CBOR map in which each schema 222 node defined within is encoded using a key and a value. This 223 specification supports two types of CBOR keys; YANG Schema Item 224 iDentifier (YANG SID) as defined in Section 3.2 and names as defined 225 in Section 3.3. Each of these key types is encoded using a specific 226 CBOR type which allows their interpretation during the 227 deserialization process. Protocols or mechanisms implementing this 228 specification can mandate the use of a specific key type or allow the 229 generator to choose freely per key. 231 In order to minimize the size of the encoded data, the mapping avoids 232 any unnecessary meta-information beyond that directly provided by the 233 CBOR basic generic data model (Section 2 of [RFC8949]). For 234 instance, CBOR tags are used solely in the case of an absolute SID, 235 anyxml data nodes, or the union datatype, to distinguish explicitly 236 the use of different YANG datatypes encoded using the same CBOR major 237 type. 239 Unless specified otherwise by the protocol or mechanism implementing 240 this specification, the indefinite length encoding as defined in 241 Section 3.2 of [RFC8949] SHALL be supported by the CBOR decoders 242 employed with YANG-CBOR. (This enables an implementation to begin 243 emitting an array or map before the number of entries in that 244 structure is known, possibly also avoiding excessive locking or race 245 conditions. On the other hand, it deprives the receiver of the 246 encoded data from advance announcement about some size information, 247 so a generator should choose indefinite length encoding only when 248 these benefits do accrue.) 250 Data nodes implemented using a CBOR array, map, byte string, or text 251 string can be instantiated but empty. In this case, they are encoded 252 with a length of zero. 254 When representation nodes are serialized using the rules defined by 255 this specification as part of an application payload, the payload 256 SHOULD include information that would allow a stateless way to 257 identify each node, such as the SID number associated with the node, 258 SID delta from another SID in the application payload, the namespace 259 qualified name, or the instance-identifier. 261 Examples in Section 4 include a root CBOR map with a single entry 262 having a key set to either a namespace qualified name or a SID. This 263 root CBOR map is provided only as a typical usage example and is not 264 part of the present encoding rules. Only the value within this CBOR 265 map is compulsory. 267 3.1. CBOR diagnostic notation 269 Within this document, CBOR binary contents are represented using an 270 equivalent textual form called CBOR diagnostic notation as defined in 271 Section 8 of [RFC8949]. This notation is used strictly for 272 documentation purposes and is never used in the data serialization. 273 Table 1 below provides a summary of this notation. 275 +==========+======+====================+===========+==========+ 276 | CBOR | CBOR | Diagnostic | Example | CBOR | 277 | content | type | notation | | encoding | 278 +==========+======+====================+===========+==========+ 279 | Unsigned | 0 | Decimal digits | 123 | 18 7B | 280 | integer | | | | | 281 +----------+------+--------------------+-----------+----------+ 282 | Negative | 1 | Decimal digits | -123 | 38 7A | 283 | integer | | prefixed by a | | | 284 | | | minus sign | | | 285 +----------+------+--------------------+-----------+----------+ 286 | Byte | 2 | Hexadecimal value | h'F15C' | 42 F15C | 287 | string | | enclosed between | | | 288 | | | single quotes and | | | 289 | | | prefixed by an 'h' | | | 290 +----------+------+--------------------+-----------+----------+ 291 | Text | 3 | String of Unicode | "txt" | 63 | 292 | string | | characters | | 747874 | 293 | | | enclosed between | | | 294 | | | double quotes | | | 295 +----------+------+--------------------+-----------+----------+ 296 | Array | 4 | Comma-separated | [ 1, 2 ] | 82 01 02 | 297 | | | list of values | | | 298 | | | within square | | | 299 | | | brackets | | | 300 +----------+------+--------------------+-----------+----------+ 301 | Map | 5 | Comma-separated | { 1: 123, | A2 | 302 | | | list of key : | 2: 456 } | 01187B | 303 | | | value pairs within | | 021901C8 | 304 | | | curly braces | | | 305 +----------+------+--------------------+-----------+----------+ 306 | Boolean | 7/20 | false | false | F4 | 307 +----------+------+--------------------+-----------+----------+ 308 | | 7/21 | true | true | F5 | 309 +----------+------+--------------------+-----------+----------+ 310 | Null | 7/22 | null | null | F6 | 311 +----------+------+--------------------+-----------+----------+ 312 | Not | 7/23 | undefined | undefined | F7 | 313 | assigned | | | | | 314 +----------+------+--------------------+-----------+----------+ 316 Table 1: CBOR diagnostic notation summary 318 Note: CBOR binary contents shown in this specification are annotated 319 with comments. These comments are delimited by slashes ("/") as 320 defined in [RFC8610] Appendix G.6. 322 3.2. YANG Schema Item iDentifier 324 Some of the items defined in YANG [RFC7950] require the use of a 325 unique identifier. In both Network Configuration Protocol (NETCONF) 326 [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented 327 using text strings. To allow the implementation of data models 328 defined in YANG in constrained devices and constrained networks, a 329 more compact method to identify YANG items is required. This compact 330 identifier, called YANG Schema Item iDentifier, is an unsigned 331 integer limited to 63 bits of range (i.e., 0..9223372036854775807 or 332 0..0x7fffffffffffffff). The following items are identified using 333 YANG SIDs (often shortened to SIDs): 335 * identities 337 * data nodes 339 * RPCs and associated input(s) and output(s) 341 * actions and associated input(s) and output(s) 343 * YANG data structures 345 * notifications and associated information 347 * YANG modules and features 349 Note that any structuring of modules into submodules is transparent 350 to YANG-CBOR: SIDs are not allocated for the names of submodules, and 351 any items within a submodule are effectively allocated SIDs as part 352 of processing the module that includes them. 354 To minimize their size, SIDs used as keys in CBOR maps are encoded 355 using deltas, i.e., signed (negative or unsigned) integers that are 356 added to the reference SID applying to the map. The reference SID of 357 an outermost map is zero, unless a different reference SID is 358 unambiguously conferred from the environment in which the outermost 359 map is used. The reference SID of a map that is most directly 360 embedded in a map entry with a name-based key is zero. For all other 361 maps, the reference SID is the SID computed for the map entry it is 362 most directly embedded in. (The embedding may be indirect if an 363 array intervenes, e.g., in a YANG list.) Where absolute SIDs are 364 desired in map key positions (where a bare integer implies a delta), 365 they need to be identified as absolute SID values by using CBOR tag 366 number 47 (as defined in Section 4.2.1). 368 Thus, conversion from SIDs to deltas and back to SIDs is a stateless 369 process solely based on the data serialized or deserialized combined 370 with, potentially, an outermost reference SID unambiguously conferred 371 by the environment. 373 Mechanisms and processes used to assign SIDs to YANG items and to 374 guarantee their uniqueness are outside the scope of the present 375 specification. If SIDs are to be used, the present specification is 376 used in conjunction with a specification defining this management. A 377 related document, [I-D.ietf-core-sid], is intended to serve as the 378 definitive way to assign SID values for YANG modules managed by the 379 IETF, and recommends itself for YANG modules managed by non-IETF 380 entities, as well. The present specification has been designed to 381 allow different methods of assignment to be used within separate 382 domains. 384 To provide implementations with a way to internally indicate the 385 absence of a SID, the SID value 0 is reserved and will not be 386 allocated; it is not used in interchange. 388 3.3. Name 390 This specification also supports the encoding of YANG item 391 identifiers as text strings, similar to those used by the JSON 392 Encoding of Data Modeled with YANG [RFC7951]. This approach can be 393 used to avoid the management overhead associated with SID allocation. 394 The main drawback is the significant increase in size of the encoded 395 data. 397 YANG item identifiers implemented using names MUST be in one of the 398 following forms: 400 * simple -- the identifier of the YANG item (i.e., schema node or 401 identity). 403 * namespace qualified -- the identifier of the YANG item is prefixed 404 with the name of the module in which this item is defined, 405 separated by the colon character (":"). 407 The name of a module determines the namespace of all YANG items 408 defined in that module. If an item is defined in a submodule, then 409 the namespace qualified name uses the name of the main module to 410 which the submodule belongs. 412 ABNF syntax [RFC5234] of a name is shown in Figure 1, where the 413 production for "identifier" is defined in Section 14 of [RFC7950]. 415 name = [identifier ":"] identifier 417 Figure 1: ABNF Production for a simple or namespace qualified name 419 A namespace qualified name MUST be used for all members of a top- 420 level CBOR map and then also whenever the namespaces of the 421 representation node and its parent node are different. In all other 422 cases, the simple form of the name MUST be used. 424 Definition example: 426 module example-foomod { 427 container top { 428 leaf foo { 429 type uint8; 430 } 431 } 432 } 434 module example-barmod { 435 import example-foomod { 436 prefix "foomod"; 437 } 438 augment "/foomod:top" { 439 leaf bar { 440 type boolean; 441 } 442 } 443 } 445 A valid CBOR encoding of the 'top' container is as follows. 447 CBOR diagnostic notation: 449 { 450 "example-foomod:top": { 451 "foo": 54, 452 "example-barmod:bar": true 453 } 454 } 456 Both the 'top' container and the 'bar' leaf defined in a different 457 YANG module as its parent container are encoded as namespace 458 qualified names. The 'foo' leaf defined in the same YANG module as 459 its parent container is encoded as simple name. 461 4. Encoding of Representation Nodes 463 Representation nodes defined using the YANG modeling language are 464 encoded using CBOR [RFC8949] based on the rules defined in this 465 section. We assume that the reader is already familiar with both 466 YANG [RFC7950] and CBOR [RFC8949]. 468 4.1. The 'leaf' 470 A 'leaf' MUST be encoded accordingly to its datatype using one of the 471 encoding rules specified in Section 6. 473 The following examples show the encoding of a 'hostname' leaf using a 474 SID or a name. 476 Definition example adapted from [RFC6991] and [RFC7317]: 478 typedef domain-name { 479 type string { 480 pattern 481 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 482 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 483 + '|\.'; 484 length "1..253"; 485 } 486 } 488 leaf hostname { 489 type inet:domain-name; 490 } 492 4.1.1. Using SIDs in keys 494 As with all examples below, the delta in the outermost map assumes a 495 reference YANG SID (current schema node) of 0. 497 CBOR diagnostic notation: 499 { 500 1752 : "myhost.example.com" / hostname (SID 1752) / 501 } 503 CBOR encoding: 505 A1 # map(1) 506 19 06D8 # unsigned(1752) 507 72 # text(18) 508 6D79686F73742E6578616D706C652E636F6D # "myhost.example.com" 510 4.1.2. Using names in keys 512 CBOR diagnostic notation: 514 { 515 "ietf-system:hostname" : "myhost.example.com" 516 } 518 CBOR encoding: 520 A1 # map(1) 521 74 # text(20) 522 696574662D73797374656D3A686F73746E616D65 523 72 # text(18) 524 6D79686F73742E6578616D706C652E636F6D 526 4.2. The 'container' and other nodes from the data tree 528 Instances of containers, YANG data structures, notification contents, 529 RPC inputs, RPC outputs, action inputs, and action outputs MUST be 530 encoded using a CBOR map data item (major type 5). The same encoding 531 is also used for the list entries in a list (Section 4.4). A map 532 consists of pairs of data items, with each pair consisting of a key 533 and a value. Each key within the CBOR map is set to a schema node 534 identifier, each value is set to the value of this representation 535 node according to the instance datatype. 537 This specification supports two types of CBOR map keys; SID as 538 defined in Section 3.2 and names as defined in Section 3.3. 540 The following examples show the encoding of a 'system-state' 541 container representation instance using SIDs or names. 543 Definition example adapted from [RFC6991] and [RFC7317]: 545 typedef date-and-time { 546 type string { 547 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 548 + '(Z|[\+\-]\d{2}:\d{2})'; 549 } 550 } 552 container system-state { 554 container clock { 555 leaf current-datetime { 556 type date-and-time; 557 } 559 leaf boot-datetime { 560 type date-and-time; 561 } 562 } 563 } 565 4.2.1. Using SIDs in keys 567 In the context of containers and other nodes from the data tree, CBOR 568 map keys within inner CBOR maps can be encoded using deltas (bare 569 integers) or absolute SIDs (tagged with tag number 47). 571 Delta values are computed as follows: 573 * In the case of a 'container', deltas are equal to the SID of the 574 current representation node minus the SID of the parent 575 'container'. 577 * In the case of a 'list', deltas are equal to the SID of the 578 current representation node minus the SID of the parent 'list'. 580 * In the case of an 'RPC input' or 'RPC output', deltas are equal to 581 the SID of the current representation node minus the SID of the 582 'RPC'. 584 * In the case of an 'action input' or 'action output', deltas are 585 equal to the SID of the current representation node minus the SID 586 of the 'action'. 588 * In the case of a 'notification content', deltas are equal to the 589 SID of the current representation node minus the SID of the 590 'notification'. 592 CBOR diagnostic notation: 594 { 595 1720 : { / system-state (SID 1720) / 596 1 : { / clock (SID 1721) / 597 2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/ 598 1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) / 599 } 600 } 601 } 603 CBOR encoding: 605 A1 # map(1) 606 19 06B8 # unsigned(1720) 607 A1 # map(1) 608 01 # unsigned(1) 609 A2 # map(2) 610 02 # unsigned(2) 611 78 1A # text(26) 612 323031352D31302D30325431343A34373A32345A2D30353A3030 613 01 # unsigned(1) 614 78 1A # text(26) 615 323031352D30392D31355430393A31323A35385A2D30353A3030 617 Figure 2: System state clock encoding 619 4.2.2. Using names in keys 621 CBOR map keys implemented using names MUST be encoded using a CBOR 622 text string data item (major type 3). A namespace-qualified name 623 MUST be used each time the namespace of a representation node and its 624 parent differ. In all other cases, the simple form of the name MUST 625 be used. Names and namespaces are defined in Section 4 of [RFC7951]. 627 The following example shows the encoding of a 'system' container 628 representation node instance using names. 630 CBOR diagnostic notation: 632 { 633 "ietf-system:system-state" : { 634 "clock" : { 635 "current-datetime" : "2015-10-02T14:47:24Z-05:00", 636 "boot-datetime" : "2015-09-15T09:12:58Z-05:00" 637 } 638 } 639 } 641 CBOR encoding: 643 A1 # map(1) 644 78 18 # text(24) 645 696574662D73797374656D3A73797374656D2D7374617465 646 A1 # map(1) 647 65 # text(5) 648 636C6F636B # "clock" 649 A2 # map(2) 650 70 # text(16) 651 63757272656E742D6461746574696D65 652 78 1A # text(26) 653 323031352D31302D30325431343A34373A32345A2D30353A3030 654 6D # text(13) 655 626F6F742D6461746574696D65 656 78 1A # text(26) 657 323031352D30392D31355430393A31323A35385A2D30353A3030 659 4.3. The 'leaf-list' 661 A leaf-list MUST be encoded using a CBOR array data item (major type 662 4). Each entry of this array MUST be encoded accordingly to its 663 datatype using one of the encoding rules specified in Section 6. 665 The following example shows the encoding of the 'search' leaf-list 666 representation node instance containing two entries, "ietf.org" and 667 "ieee.org". 669 Definition example adapted from [RFC6991] and [RFC7317]: 671 typedef domain-name { 672 type string { 673 pattern 674 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 675 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 676 + '|\.'; 677 length "1..253"; 678 } 679 } 681 leaf-list search { 682 type domain-name; 683 ordered-by user; 684 } 686 4.3.1. Using SIDs in keys 688 CBOR diagnostic notation: 690 { 691 1746 : [ "ietf.org", "ieee.org" ] / search (SID 1746) / 692 } 694 CBOR encoding: 696 A1 # map(1) 697 19 06D2 # unsigned(1746) 698 82 # array(2) 699 68 # text(8) 700 696574662E6F7267 # "ietf.org" 701 68 # text(8) 702 696565652E6F7267 # "ieee.org" 704 4.3.2. Using names in keys 706 CBOR diagnostic notation: 708 { 709 "ietf-system:search" : [ "ietf.org", "ieee.org" ] 710 } 712 CBOR encoding: 714 A1 # map(1) 715 72 # text(18) 716 696574662D73797374656D3A736561726368 # "ietf-system:search" 717 82 # array(2) 718 68 # text(8) 719 696574662E6F7267 # "ietf.org" 720 68 # text(8) 721 696565652E6F7267 # "ieee.org" 723 4.4. The 'list' and 'list' entries 725 A list or a subset of a list MUST be encoded using a CBOR array data 726 item (major type 4). Each list entry within this CBOR array is 727 encoded using a CBOR map data item (major type 5) based on the 728 encoding rules of a collection as defined in Section 4.2. 730 It is important to note that this encoding rule also applies to a 731 'list' representation node instance that has a single entry. 733 The following examples show the encoding of a 'server' list using 734 SIDs or names. 736 Definition example simplified from [RFC7317]: 738 list server { 739 key name; 741 leaf name { 742 type string; 743 } 744 choice transport { 745 case udp { 746 container udp { 747 leaf address { 748 type host; 749 mandatory true; 750 } 751 leaf port { 752 type port-number; 753 } 754 } 755 } 756 } 757 leaf association-type { 758 type enumeration { 759 enum server; 760 enum peer; 761 enum pool; 762 } 763 default server; 764 } 765 leaf iburst { 766 type boolean; 767 default false; 768 } 769 leaf prefer { 770 type boolean; 771 default false; 772 } 773 } 775 4.4.1. Using SIDs in keys 777 The encoding rules of each 'list' entry are defined in Section 4.2.1. 779 CBOR diagnostic notation: 781 { 782 1756 : [ / server (SID 1756) / 783 { 784 3 : "NRC TIC server", / name (SID 1759) / 785 5 : { / udp (SID 1761) / 786 1 : "tic.nrc.ca", / address (SID 1762) / 787 2 : 123 / port (SID 1763) / 788 }, 789 1 : 0, / association-type (SID 1757) / 790 2 : false, / iburst (SID 1758) / 791 4 : true / prefer (SID 1760) / 792 }, 793 { 794 3 : "NRC TAC server", / name (SID 1759) / 795 5 : { / udp (SID 1761) / 796 1 : "tac.nrc.ca" / address (SID 1762) / 797 } 798 } 799 ] 800 } 802 CBOR encoding: 804 A1 # map(1) 805 19 06DC # unsigned(1756) 806 82 # array(2) 807 A5 # map(5) 808 03 # unsigned(3) 809 6E # text(14) 810 4E52432054494320736572766572 # "NRC TIC server" 811 05 # unsigned(5) 812 A2 # map(2) 813 01 # unsigned(1) 814 6A # text(10) 815 7469632E6E72632E6361 # "tic.nrc.ca" 816 02 # unsigned(2) 817 18 7B # unsigned(123) 818 01 # unsigned(1) 819 00 # unsigned(0) 820 02 # unsigned(2) 821 F4 # primitive(20) 822 04 # unsigned(4) 823 F5 # primitive(21) 824 A2 # map(2) 825 03 # unsigned(3) 826 6E # text(14) 827 4E52432054414320736572766572 # "NRC TAC server" 828 05 # unsigned(5) 829 A1 # map(1) 830 01 # unsigned(1) 831 6A # text(10) 832 7461632E6E72632E6361 # "tac.nrc.ca" 834 4.4.2. Using names in keys 836 The encoding rules of each 'list' entry are defined in Section 4.2.2. 838 CBOR diagnostic notation: 840 { 841 "ietf-system:server" : [ 842 { 843 "name" : "NRC TIC server", 844 "udp" : { 845 "address" : "tic.nrc.ca", 846 "port" : 123 847 }, 848 "association-type" : 0, 849 "iburst" : false, 850 "prefer" : true 851 }, 852 { 853 "name" : "NRC TAC server", 854 "udp" : { 855 "address" : "tac.nrc.ca" 856 } 857 } 858 ] 859 } 861 CBOR encoding: 863 A1 # map(1) 864 72 # text(18) 865 696574662D73797374656D3A736572766572 866 82 # array(2) 867 A5 # map(5) 868 64 # text(4) 869 6E616D65 # "name" 870 6E # text(14) 871 4E52432054494320736572766572 872 63 # text(3) 873 756470 # "udp" 874 A2 # map(2) 875 67 # text(7) 876 61646472657373 # "address" 877 6A # text(10) 878 7469632E6E72632E6361 # "tic.nrc.ca" 879 64 # text(4) 880 706F7274 # "port" 881 18 7B # unsigned(123) 882 70 # text(16) 883 6173736F63696174696F6E2D74797065 884 00 # unsigned(0) 885 66 # text(6) 886 696275727374 # "iburst" 887 F4 # primitive(20) 888 66 # text(6) 889 707265666572 # "prefer" 890 F5 # primitive(21) 891 A2 # map(2) 892 64 # text(4) 893 6E616D65 # "name" 894 6E # text(14) 895 4E52432054414320736572766572 896 63 # text(3) 897 756470 # "udp" 898 A1 # map(1) 899 67 # text(7) 900 61646472657373 # "address" 901 6A # text(10) 902 7461632E6E72632E6361 # "tac.nrc.ca" 904 4.5. The 'anydata' 906 An anydata serves as a container for an arbitrary set of 907 representation nodes that otherwise appear as normal YANG-modeled 908 data. An anydata representation node instance is encoded using the 909 same rules as a container, i.e., CBOR map. The requirement that 910 anydata content can be modeled by YANG implies the following: 912 * CBOR map keys of any inner representation nodes MUST be set to 913 valid deltas or names. 915 * CBOR arrays MUST contain either unique scalar values (as a leaf- 916 list, see Section 4.3), or maps (as a list, see Section 4.4). 918 * CBOR map values MUST follow the encoding rules of one of the 919 datatypes listed in Section 4. 921 The following example shows a possible use of an anydata. In this 922 example, an anydata is used to define a representation node 923 containing a notification event; this representation node can be part 924 of a YANG list to create an event logger. 926 Definition example: 928 module event-log { 929 ... 930 anydata last-event; # SID 60123 931 } 933 This example also assumes the assistance of the following 934 notification. 936 module example-port { 937 ... 939 notification example-port-fault { # SID 60200 940 leaf port-name { # SID 60201 941 type string; 942 } 943 leaf port-fault { # SID 60202 944 type string; 945 } 946 } 947 } 949 4.5.1. Using SIDs in keys 951 CBOR diagnostic notation: 953 { 954 60123 : { / last-event (SID 60123) / 955 77 : { / example-port-fault (SID 60200) / 956 1 : "0/4/21", / port-name (SID 60201) / 957 2 : "Open pin 2" / port-fault (SID 60202) / 958 } 959 } 960 } 962 CBOR encoding: 964 A1 # map(1) 965 19 EADB # unsigned(60123) 966 A1 # map(1) 967 18 4D # unsigned(77) 968 A2 # map(2) 969 01 # unsigned(1) 970 66 # text(6) 971 302F342F3231 # "0/4/21" 972 02 # unsigned(2) 973 6A # text(10) 974 4F70656E2070696E2032 # "Open pin 2" 976 In some implementations, it might be simpler to use the absolute SID 977 encoding (tag number 47) for the anydata root element. CBOR 978 diagnostic notation: 980 { 981 60123 : { / last-event (SID 60123) / 982 47(60200) : { / event-port-fault (SID 60200) / 983 1 : "0/4/21", / port-name (SID 60201) / 984 2 : "Open pin 2" / port-fault (SID 60202) / 985 } 986 } 987 } 989 4.5.2. Using names in keys 991 CBOR diagnostic notation: 993 { 994 "event-log:last-event" : { 995 "example-port:example-port-fault" : { 996 "port-name" : "0/4/21", 997 "port-fault" : "Open pin 2" 998 } 999 } 1000 } 1001 CBOR encoding: 1003 A1 # map(1) 1004 74 # text(20) 1005 6576656E742D6C6F673A6C6173742D6576656E74 1006 A1 # map(1) 1007 78 1F # text(31) 1008 6578616D706C652D706F72743A 1009 6578616D706C652D706F72742D6661756C74 1010 A2 # map(2) 1011 69 # text(9) 1012 706F72742D6E616D65 # "port-name" 1013 66 # text(6) 1014 302F342F3231 # "0/4/21" 1015 6A # text(10) 1016 706F72742D6661756C74 # "port-fault" 1017 6A # text(10) 1018 4F70656E2070696E2032 # "Open pin 2" 1020 4.6. The 'anyxml' 1022 An anyxml representation node is used to serialize an arbitrary CBOR 1023 content, i.e., its value can be any CBOR binary object. (The "xml" 1024 in the name is a misnomer that only applied to YANG-XML [RFC7950].) 1025 An anyxml value MAY contain CBOR data items tagged with one of the 1026 tags listed in Section 9.3. The tags listed in Section 9.3 SHALL be 1027 supported. 1029 The following example shows a valid CBOR encoded anyxml 1030 representation node instance consisting of a CBOR array containing 1031 the CBOR simple values 'true', 'null' and 'true'. 1033 Definition example from [RFC7951]: 1035 module bar-module { 1036 ... 1037 anyxml bar; # SID 60000 1038 } 1040 4.6.1. Using SIDs in keys 1042 CBOR diagnostic notation: 1044 { 1045 60000 : [true, null, true] / bar (SID 60000) / 1046 } 1048 CBOR encoding: 1050 A1 # map(1) 1051 19 EA60 # unsigned(60000) 1052 83 # array(3) 1053 F5 # primitive(21) 1054 F6 # primitive(22) 1055 F5 # primitive(21) 1057 4.6.2. Using names in keys 1059 CBOR diagnostic notation: 1061 { 1062 "bar-module:bar" : [true, null, true] / bar (SID 60000) / 1063 } 1065 CBOR encoding: 1067 A1 # map(1) 1068 6E # text(14) 1069 6261722D6D6F64756C653A626172 # "bar-module:bar" 1070 83 # array(3) 1071 F5 # primitive(21) 1072 F6 # primitive(22) 1073 F5 # primitive(21) 1075 5. Encoding of 'yang-data' extension 1077 The yang-data extension [RFC8040] is used to define data structures 1078 in YANG that are not intended to be implemented as part of a 1079 datastore. 1081 The yang-data extension will specify a container that MUST be encoded 1082 using the encoding rules of nodes of data trees as defined in 1083 Section 4.2. 1085 Just like YANG containers, the yang-data extension can be encoded 1086 using either SIDs or names. 1088 Definition example from [I-D.ietf-core-comi] Appendix A: 1090 module ietf-coreconf { 1091 ... 1093 import ietf-restconf { 1094 prefix rc; 1095 } 1097 rc:yang-data yang-errors { 1098 container error { 1099 leaf error-tag { 1100 type identityref { 1101 base error-tag; 1102 } 1103 } 1104 leaf error-app-tag { 1105 type identityref { 1106 base error-app-tag; 1107 } 1108 } 1109 leaf error-data-node { 1110 type instance-identifier; 1111 } 1112 leaf error-message { 1113 type string; 1114 } 1115 } 1116 } 1117 } 1119 5.1. Using SIDs in keys 1121 The yang-data extensions encoded using SIDs are carried in a CBOR map 1122 containing a single item pair. The key of this item is set to the 1123 SID assigned to the yang-data extension container; the value is set 1124 to the CBOR encoding of this container as defined in Section 4.2. 1126 This example shows a serialization example of the yang-errors yang- 1127 data extension as defined in [I-D.ietf-core-comi] using SIDs as 1128 defined in Section 3.2. 1130 CBOR diagnostic notation: 1132 { 1133 1024 : { / error (SID 1024) / 1134 4 : 1011, / error-tag (SID 1028) / 1135 / = invalid-value (SID 1011) / 1136 1 : 1018, / error-app-tag (SID 1025) / 1137 / = not-in-range (SID 1018) / 1138 2 : 1740, / error-data-node (SID 1026) / 1139 / = timezone-utc-offset (SID 1740) / 1140 3 : "Maximum exceeded" / error-message (SID 1027) / 1141 } 1142 } 1144 CBOR encoding: 1146 A1 # map(1) 1147 19 0400 # unsigned(1024) 1148 A4 # map(4) 1149 04 # unsigned(4) 1150 19 03F3 # unsigned(1011) 1151 01 # unsigned(1) 1152 19 03FA # unsigned(1018) 1153 02 # unsigned(2) 1154 19 06CC # unsigned(1740) 1155 03 # unsigned(3) 1156 70 # text(16) 1157 4D6178696D756D206578636565646564 # "Maximum exceeded" 1159 5.2. Using names in keys 1161 The yang-data extensions encoded using names are carried in a CBOR 1162 map containing a single item pair. The key of this item is set to 1163 the namespace qualified name of the yang-data extension container; 1164 the value is set to the CBOR encoding of this container as defined in 1165 Section 4.2. 1167 This example shows a serialization example of the yang-errors yang- 1168 data extension as defined in [I-D.ietf-core-comi] using names as 1169 defined Section 3.3. 1171 CBOR diagnostic notation: 1173 { 1174 "ietf-coreconf:error" : { 1175 "error-tag" : "invalid-value", 1176 "error-app-tag" : "not-in-range", 1177 "error-data-node" : "timezone-utc-offset", 1178 "error-message" : "Maximum exceeded" 1179 } 1180 } 1182 CBOR encoding: 1184 A1 # map(1) 1185 73 # text(19) 1186 696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error" 1187 A4 # map(4) 1188 69 # text(9) 1189 6572726F722D746167 # "error-tag" 1190 6D # text(13) 1191 696E76616C69642D76616C7565 # "invalid-value" 1192 6D # text(13) 1193 6572726F722D6170702D746167 # "error-app-tag" 1194 6C # text(12) 1195 6E6F742D696E2D72616E6765 # "not-in-range" 1196 6F # text(15) 1197 6572726F722D646174612D6E6F6465 # "error-data-node" 1198 73 # text(19) 1199 74696D657A6F6E652D7574632D6F6666736574 1200 # "timezone-utc-offset" 1201 6D # text(13) 1202 6572726F722D6D657373616765 # "error-message" 1203 70 # text(16) 1204 4D6178696D756D206578636565646564 # "Maximum exceeded" 1206 6. Representing YANG Data Types in CBOR 1208 The CBOR encoding of an instance of a leaf or leaf-list 1209 representation node depends on the built-in type of that 1210 representation node. The following sub-section defines the CBOR 1211 encoding of each built-in type supported by YANG as listed in 1212 Section 4.2.4 of [RFC7950]. Each subsection shows an example value 1213 assigned to a representation node instance of the discussed built-in 1214 type. 1216 6.1. The unsigned integer Types 1218 Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using 1219 a CBOR unsigned integer data item (major type 0). 1221 The following example shows the encoding of an 'mtu' leaf 1222 representation node instance set to 1280 bytes. 1224 Definition example from [RFC8344]: 1226 leaf mtu { 1227 type uint16 { 1228 range "68..max"; 1229 } 1230 } 1232 CBOR diagnostic notation: 1280 1234 CBOR encoding: 19 0500 1236 6.2. The integer Types 1238 Leafs of type int8, int16, int32 and int64 MUST be encoded using 1239 either CBOR unsigned integer (major type 0) or CBOR negative integer 1240 (major type 1), depending on the actual value. 1242 The following example shows the encoding of a 'timezone-utc-offset' 1243 leaf representation node instance set to -300 minutes. 1245 Definition example from [RFC7317]: 1247 leaf timezone-utc-offset { 1248 type int16 { 1249 range "-1500 .. 1500"; 1250 } 1251 } 1253 CBOR diagnostic notation: -300 1255 CBOR encoding: 39 012B 1257 6.3. The 'decimal64' Type 1259 Leafs of type decimal64 MUST be encoded using a decimal fraction as 1260 defined in Section 3.4.4 of [RFC8949]. 1262 The following example shows the encoding of a 'my-decimal' leaf 1263 representation node instance set to 2.57. 1265 Definition example from [RFC7317]: 1267 leaf my-decimal { 1268 type decimal64 { 1269 fraction-digits 2; 1270 range "1 .. 3.14 | 10 | 20..max"; 1271 } 1272 } 1274 CBOR diagnostic notation: 4([-2, 257]) 1276 CBOR encoding: C4 82 21 19 0101 1278 6.4. The 'string' Type 1280 Leafs of type string MUST be encoded using a CBOR text string data 1281 item (major type 3). 1283 The following example shows the encoding of a 'name' leaf 1284 representation node instance set to "eth0". 1286 Definition example from [RFC8343]: 1288 leaf name { 1289 type string; 1290 } 1292 CBOR diagnostic notation: "eth0" 1294 CBOR encoding: 64 65746830 1296 6.5. The 'boolean' Type 1298 Leafs of type boolean MUST be encoded using a CBOR simple value 1299 'true' (major type 7, additional information 21) or 'false' (major 1300 type 7, additional information 20). 1302 The following example shows the encoding of an 'enabled' leaf 1303 representation node instance set to 'true'. 1305 Definition example from [RFC7317]: 1307 leaf enabled { 1308 type boolean; 1309 } 1311 CBOR diagnostic notation: true 1313 CBOR encoding: F5 1315 6.6. The 'enumeration' Type 1317 Leafs of type enumeration MUST be encoded using a CBOR unsigned 1318 integer (major type 0) or CBOR negative integer (major type 1), 1319 depending on the actual value, or exceptionally as a tagged text 1320 string (see below). Enumeration values are either explicitly 1321 assigned using the YANG statement 'value' or automatically assigned 1322 based on the algorithm defined in Section 9.6.4.2 of [RFC7950]. 1324 The following example shows the encoding of an 'oper-status' leaf 1325 representation node instance set to 'testing'. 1327 Definition example from [RFC7317]: 1329 leaf oper-status { 1330 type enumeration { 1331 enum up { value 1; } 1332 enum down { value 2; } 1333 enum testing { value 3; } 1334 enum unknown { value 4; } 1335 enum dormant { value 5; } 1336 enum not-present { value 6; } 1337 enum lower-layer-down { value 7; } 1338 } 1339 } 1341 CBOR diagnostic notation: 3 1343 CBOR encoding: 03 1345 Values of 'enumeration' types defined in a 'union' type MUST be 1346 encoded using a CBOR text string data item (major type 3) and MUST 1347 contain one of the names assigned by 'enum' statements in YANG (see 1348 also Section 6.12). The encoding MUST be enclosed by the enumeration 1349 CBOR tag as specified in Section 9.3. 1351 Definition example from [RFC7950]: 1353 type union { 1354 type int32; 1355 type enumeration { 1356 enum unbounded; 1357 } 1358 } 1360 CBOR diagnostic notation: 44("unbounded") 1362 CBOR encoding: D8 2C 69 756E626F756E646564 1364 6.7. The 'bits' Type 1366 Keeping in mind that bit positions are either explicitly assigned 1367 using the YANG statement 'position' or automatically assigned based 1368 on the algorithm defined in Section 9.7.4.2 of [RFC7950], each 1369 element of type bits could be seen as a set of bit positions (or 1370 offsets from position 0), that have a value of either 1, which 1371 represents the bit being set or 0, which represents that the bit is 1372 not set. 1374 Leafs of type bits MUST be encoded either using a CBOR array or byte 1375 string (major type 2), or exceptionally as a tagged text string (see 1376 below). In case CBOR array representation is used, each element is 1377 either a positive integer (major type 0 with value 0 being 1378 disallowed) that can be used to calculate the offset of the next byte 1379 string, or a byte string (major type 2) that carries the information 1380 whether certain bits are set or not. The initial offset value is 0 1381 and each unsigned integer modifies the offset value of the next byte 1382 string by the integer value multiplied by 8. For example, if the bit 1383 offset is 0 and there is an integer with value 5, the first byte of 1384 the byte string that follows will represent bit positions 40 to 47 1385 both ends included. If the byte string has a second byte, it will 1386 carry information about bits 48 to 55 and so on. Within each byte, 1387 bits are assigned from least to most significant. After the byte 1388 string, the offset is modified by the number of bytes in the byte 1389 string multiplied by 8. Bytes with no bits set (zero bytes) at the 1390 end of the byte string are never generated: If they would occur at 1391 the end of the array, the zero bytes are simply omitted; if they 1392 occur at the end of a byte string preceding an integer, the zero 1393 bytes are removed and the integer adjusted upwards by the number of 1394 zero bytes removed. An example follows. 1396 The following example shows the encoding of an 'alarm-state' leaf 1397 representation node instance with the 'critical' (position 3), 1398 'warning' (position 8) and 'indeterminate' (position 128) flags set. 1400 typedef alarm-state { 1401 type bits { 1402 bit unknown; 1403 bit under-repair; 1404 bit critical; 1405 bit major; 1406 bit minor; 1407 bit warning { 1408 position 8; 1409 } 1410 bit indeterminate { 1411 position 128; 1412 } 1413 } 1414 } 1416 leaf alarm-state { 1417 type alarm-state; 1418 } 1420 CBOR diagnostic notation: [h'0401', 14, h'01'] 1422 CBOR encoding: 83 42 0401 0E 41 01 1424 In a number of cases the array would only need to have one element -- 1425 a byte string with a few bytes inside. For this case, it is REQUIRED 1426 to omit the array element and have only the byte array that would 1427 have been inside. To illustrate this, let us consider the same 1428 example YANG definition, but this time encoding only 'under-repair' 1429 and 'critical' flags. The result would be 1431 CBOR diagnostic notation: h'06' 1433 CBOR encoding: 41 06 1435 Elements in the array MUST be either byte strings that do not end in 1436 a zero byte, or positive unsigned integers, where byte strings and 1437 integers MUST alternate, i.e., adjacent byte strings or adjacent 1438 integers are an error. An array with a single byte string MUST 1439 instead be encoded as just that byte string. An array with a single 1440 positive integer is an error. Note that a recipient can handle 1441 trailing zero bytes in the byte strings using the normal rules 1442 without any issue, so an implementation MAY silently accept them. 1444 Values of 'bits' types defined in a 'union' type MUST be encoded 1445 using a CBOR text string data item (major type 3) and MUST contain a 1446 space-separated sequence of names of 'bits' that are set (see also 1447 Section 6.12). The encoding MUST be enclosed by the bits CBOR tag as 1448 specified in Section 9.3. 1450 The following example shows the encoding of an 'alarm-state' leaf 1451 representation node instance defined using a union type with the 1452 'under-repair' and 'critical' flags set. 1454 Definition example: 1456 leaf alarm-state-2 { 1457 type union { 1458 type alarm-state; 1459 type bits { 1460 bit extra-flag; 1461 } 1462 } 1463 } 1465 CBOR diagnostic notation: 43("under-repair critical") 1467 CBOR encoding: D8 2B 75 756E6465722D72657061697220637269746963616C 1469 6.8. The 'binary' Type 1471 Leafs of type binary MUST be encoded using a CBOR byte string data 1472 item (major type 2). 1474 The following example shows the encoding of an 'aes128-key' leaf 1475 representation node instance set to 1476 0x1f1ce6a3f42660d888d92a4d8030476e. 1478 Definition example: 1480 leaf aes128-key { 1481 type binary { 1482 length 16; 1483 } 1484 } 1486 CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E' 1488 CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E 1490 6.9. The 'leafref' Type 1492 Leafs of type leafref MUST be encoded using the rules of the 1493 representation node referenced by the 'path' YANG statement. 1495 The following example shows the encoding of an 'interface-state-ref' 1496 leaf representation node instance set to "eth1". 1498 Definition example from [RFC8343]: 1500 typedef interface-state-ref { 1501 type leafref { 1502 path "/interfaces-state/interface/name"; 1503 } 1504 } 1506 container interfaces-state { 1507 list interface { 1508 key "name"; 1509 leaf name { 1510 type string; 1511 } 1512 leaf-list higher-layer-if { 1513 type interface-state-ref; 1514 } 1515 } 1516 } 1518 CBOR diagnostic notation: "eth1" 1520 CBOR encoding: 64 65746831 1522 6.10. The 'identityref' Type 1524 This specification supports two approaches for encoding identityref: 1525 as a YANG Schema Item iDentifier as defined in Section 3.2, or as a 1526 name as defined in Section 6.8 of [RFC7951]. See Section 6.12 for an 1527 exceptional case when this representation needs to be tagged. 1529 6.10.1. SIDs as identityref 1531 When representation nodes of type identityref are implemented using 1532 SIDs, they MUST be encoded using a CBOR unsigned integer data item 1533 (major type 0). (Note that, as they are not used in the position of 1534 CBOR map keys, no delta mechanism is employed for SIDs used for 1535 identityref.) 1536 The following example shows the encoding of a 'type' leaf 1537 representation node instance set to the value 'iana-if- 1538 type:ethernetCsmacd' (SID 1880). 1540 Definition example from [RFC7317]: 1542 identity interface-type { 1543 } 1545 identity iana-interface-type { 1546 base interface-type; 1547 } 1549 identity ethernetCsmacd { 1550 base iana-interface-type; 1551 } 1553 leaf type { 1554 type identityref { 1555 base interface-type; 1556 } 1557 } 1559 CBOR diagnostic notation: 1880 1561 CBOR encoding: 19 0758 1563 6.10.2. Name as identityref 1565 Alternatively, an identityref MAY be encoded using a name as defined 1566 in Section 3.3. When names are used, identityref MUST be encoded 1567 using a CBOR text string data item (major type 3). If the identity 1568 is defined in different module than the leaf node containing the 1569 identityref data node, the namespace qualified form MUST be used. 1570 Otherwise, both the simple and namespace qualified forms are 1571 permitted. Names and namespaces are defined in Section 3.3. 1573 The following example shows the encoding of the identity 'iana-if- 1574 type:ethernetCsmacd' using its namespace qualified name. This 1575 example is described in Section 6.10.1. 1577 CBOR diagnostic notation: "iana-if-type:ethernetCsmacd" 1579 CBOR encoding: 78 1b 1580 69616E612D69662D747970653A65746865726E657443736D616364 1582 6.11. The 'empty' Type 1584 Leafs of type empty MUST be encoded using the CBOR null value (major 1585 type 7, additional information 22). 1587 The following example shows the encoding of an 'is-router' leaf 1588 representation node instance when present. 1590 Definition example from [RFC8344]: 1592 leaf is-router { 1593 type empty; 1594 } 1596 CBOR diagnostic notation: null 1598 CBOR encoding: F6 1600 6.12. The 'union' Type 1602 Leafs of type union MUST be encoded using the rules associated with 1603 one of the types listed. When used in a union, the following YANG 1604 datatypes are enclosed by a CBOR tag to avoid confusion between 1605 different YANG datatypes encoded using the same CBOR major type. 1607 * bits 1609 * enumeration 1611 * identityref 1613 * instance-identifier 1615 See Section 9.3 for the assigned value of these CBOR tags. 1617 As mentioned in Section 6.6 and in Section 6.7, 'enumeration' and 1618 'bits' are encoded as a CBOR text string data item (major type 3) 1619 when defined within a 'union' type. (This adds considerable 1620 complexity, but is necessary because of an idiosyncrasy of the YANG 1621 data model for unions; the workaround allows compatibility to be 1622 maintained with the encoding of overlapping unions in XML and JSON. 1623 See also Section 9.12 of [RFC7950].) 1625 The following example shows the encoding of an 'ip-address' leaf 1626 representation node instance when set to "2001:db8:a0b:12f0::1". 1628 Definition example (adapted from [RFC6991]): 1630 typedef ipv4-address { 1631 type string { 1632 pattern 1633 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1634 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1635 + '(%[\p{N}\p{L}]+)?'; 1636 } 1637 } 1639 typedef ipv6-address { 1640 type string { 1641 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1642 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1643 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1644 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1645 + '(%[\p{N}\p{L}]+)?'; 1646 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1647 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1648 + '(%.+)?'; 1649 } 1650 } 1652 typedef ip-address { 1653 type union { 1654 type ipv4-address; 1655 type ipv6-address; 1656 } 1657 } 1659 leaf address { 1660 type ip-address; 1661 } 1663 CBOR diagnostic notation: "2001:db8:a0b:12f0::1" 1665 CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31 1667 6.13. The 'instance-identifier' Type 1669 This specification supports two approaches for encoding an instance- 1670 identifier, one based on YANG Schema Item iDentifier as defined in 1671 Section 3.2 and one based on names as defined in Section 3.3. See 1672 Section 6.12 for an exceptional case when this representation needs 1673 to be tagged. 1675 6.13.1. SIDs as instance-identifier 1677 SIDs uniquely identify a schema node. In the case of a single 1678 instance schema node, i.e., a schema node defined at the root of a 1679 YANG module or submodule or schema nodes defined within a container, 1680 the SID is sufficient to identify this instance (representation 1681 node). (Note that no delta mechanism is employed for SIDs used for 1682 identityref, see Section 6.10.1.) 1684 In the case of a representation node that is an entry of a YANG list, 1685 a SID is combined with the list key(s) to identify each instance 1686 within the YANG list(s). 1688 Instance identifiers of single instance schema nodes MUST be encoded 1689 using a CBOR unsigned integer data item (major type 0) and set to the 1690 targeted schema node SID. 1692 Instance identifiers of representation node entries of a YANG list 1693 MUST be encoded using a CBOR array data item (major type 4) 1694 containing the following entries: 1696 * The first entry MUST be encoded as a CBOR unsigned integer data 1697 item (major type 0) and set to the targeted schema node SID. 1699 * The following entries MUST contain the value of each key required 1700 to identify the instance of the targeted schema node. These keys 1701 MUST be ordered as defined in the 'key' YANG statement, starting 1702 from the top level list, and followed by each of the subordinate 1703 list(s). 1705 Examples within this section assume the definition of a schema node 1706 of type 'instance-identifier': 1708 Definition example from [RFC7950]: 1710 container system { 1711 ... 1712 leaf reporting-entity { 1713 type instance-identifier; 1714 } 1716 *First example:* 1718 The following example shows the encoding of the 'reporting-entity' 1719 value referencing data node instance "/system/contact" (SID 1741). 1721 Definition example from [RFC7317]: 1723 container system { 1725 leaf contact { 1726 type string; 1727 } 1729 leaf hostname { 1730 type inet:domain-name; 1731 } 1732 } 1734 CBOR diagnostic notation: 1741 1736 CBOR encoding: 19 06CD 1738 *Second example:* 1740 This example aims to show how a representation node entry of a YANG 1741 list is identified. It uses a somewhat arbitrarily modified YANG 1742 module version from [RFC7317] by adding country to the leafs and keys 1743 of authorized-key. 1745 The following example shows the encoding of the 'reporting-entity' 1746 value referencing list instance "/system/authentication/user/ 1747 authorized-key/key-data" (which is assumed to have SID 1734) for 1748 username "bob" and authorized-key with name "admin" and country 1749 "france". 1751 list user { 1752 key name; 1754 leaf name { 1755 type string; 1756 } 1758 leaf password { 1759 type ianach:crypt-hash; 1760 } 1762 list authorized-key { 1763 key "name country"; 1765 leaf country { 1766 type string; 1767 } 1769 leaf name { 1770 type string; 1771 } 1773 leaf algorithm { 1774 type string; 1775 } 1777 leaf key-data { 1778 type binary; 1779 } 1780 } 1781 } 1783 CBOR diagnostic notation: [1734, "bob", "admin", "france"] 1785 CBOR encoding: 1787 84 # array(4) 1788 19 06C6 # unsigned(1734) 1789 63 # text(3) 1790 626F62 # "bob" 1791 65 # text(5) 1792 61646D696E # "admin" 1793 66 # text(6) 1794 6672616E6365 # "france" 1796 *Third example:* 1797 The following example shows the encoding of the 'reporting-entity' 1798 value referencing the list instance "/system/authentication/user" 1799 (SID 1730) corresponding to username "jack". 1801 CBOR diagnostic notation: [1730, "jack"] 1803 CBOR encoding: 1805 82 # array(2) 1806 19 06C2 # unsigned(1730) 1807 64 # text(4) 1808 6A61636B # "jack" 1810 6.13.2. Names as instance-identifier 1812 An "instance-identifier" value is encoded as a text string that is 1813 analogous to the lexical representation in XML encoding; see 1814 Section 9.13.2 of [RFC7950]. However, the encoding of namespaces in 1815 instance-identifier values follows the rules stated in Section 3.3, 1816 namely: 1818 * The leftmost (top-level) data node name is always in the namespace 1819 qualified form. 1821 * Any subsequent data node name is in the namespace qualified form 1822 if the node is defined in a module other than its parent node, and 1823 the simple form is used otherwise. This rule also holds for node 1824 names appearing in predicates. 1826 For example, 1828 /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip 1830 is a valid instance-identifier value because the data nodes 1831 "interfaces", "interface", and "name" are defined in the module 1832 "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". 1834 The resulting xpath MUST be encoded using a CBOR text string data 1835 item (major type 3). 1837 *First example:* 1839 This example is described in Section 6.13.1. 1841 CBOR diagnostic notation: "/ietf-system:system/contact" 1843 CBOR encoding: 1845 78 1c 2F696574662D73797374656D3A73797374656D2F636F6E74616374 1847 *Second example:* 1849 This example is described in Section 6.13.1. 1851 CBOR diagnostic notation (the line break is inserted for exposition 1852 only): 1854 "/ietf-system:system/authentication/user[name='bob']/ 1855 authorized-key[name='admin'][country='france']/key-data" 1857 CBOR encoding: 1859 78 6B 1860 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 1861 74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A 1862 65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27 1863 6672616E6365275D2F6B65792D64617461 1865 *Third example:* 1867 This example is described in Section 6.13.1. 1869 CBOR diagnostic notation: 1871 "/ietf-system:system/authentication/user[name='jack']" 1873 CBOR encoding: 1875 78 34 # text(52) 1876 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 1877 74696F6E2F757365725B6E616D653D276A61636B275D 1879 7. Content-Types 1881 This specification defines the media-type application/yang-data+cbor, 1882 which can be used without parameters or with the id parameter set to 1883 either name or sid. 1885 This media-type represents a YANG-CBOR document containing a 1886 representation tree. If the media-type parameter id is present, 1887 depending on its value, each representation node is identified by its 1888 associated namespace qualified name as defined in Section 3.3 1889 (id=name), or by its associated YANG SID (represented, e.g., in CBOR 1890 map keys as a SID delta or via tag number 47) as defined in 1891 Section 3.2 (id=sid), respectively. If no id parameter is given, 1892 both forms may be present. 1894 The format of an application/yang-data+cbor representation is that of 1895 a CBOR map, mapping names and/or SIDs (as defined above) into 1896 instance values (using the rules defined in Section 4). 1898 It is not foreseen at this point that the valid set of values for the 1899 id parameter will extend beyond name, sid, or being unset; if that 1900 does happen, any new value is foreseen to be of the form 1901 [a-z][a-z0-9]*(-[a-z0-9]+)*. 1903 In summary, this document defines three content-types, which are 1904 intended for use by different classes of applications: 1906 * application/yang-data+cbor; id=sid -- for use by applications that 1907 need to be frugal with encoding space and text string processing 1908 (e.g., applications running on constrained nodes [RFC7228], or 1909 applications with particular performance requirements); 1911 * application/yang-data+cbor; id=name -- for use by applications 1912 that do not want to engage in SID management, and that have ample 1913 resources to manage text-string based item identifiers (e.g., 1914 applications that directly want to substitute application/ 1915 yang.data+json with a more efficient representation without any 1916 other changes); 1918 * application/yang-data+cbor -- for use by more complex applications 1919 that can benefit from the increased efficiency of SID identifiers 1920 but also need to integrate databases of YANG modules before SID 1921 mappings are defined for them. 1923 All three content-types are based on the same representation 1924 mechanisms, parts of which are simply not used in the first and 1925 second case. 1927 How the use of one of these content types is selected in a transfer 1928 protocol is outside the scope of this specification. The last 1929 paragraph of Section 5.2 of [RFC8040] discusses how to indicate and 1930 request the usage of specific content-types in RESTCONF. Similar 1931 mechanisms are available in CoAP [RFC7252] using the Content-Format 1932 and Accept Options; [I-D.ietf-core-comi] demonstrates specifics on 1933 how Content-Format may be used to indicate the id=sid case. 1935 8. Security Considerations 1937 The security considerations of [RFC8949] and [RFC7950] apply. 1939 This document defines an alternative encoding for data modeled in the 1940 YANG data modeling language. As such, this encoding does not 1941 contribute any new security issues in addition to those identified 1942 for the specific protocol or context for which it is used. 1944 To minimize security risks, software on the receiving side SHOULD 1945 reject all messages that do not comply to the rules of this document 1946 and reply with an appropriate error message to the sender. 1948 For instance, when the 'id' parameter to the media type is used, it 1949 is important to properly reject identifiers of the other type, to 1950 avoid scenarios where different implementations interpret a given 1951 content in different ways. 1953 When SIDs are in use, the interpretation of encoded data not only 1954 relies on having the right YANG modules, but also on having the right 1955 SID mapping information. Management and evolution of that mapping 1956 information therefore requires the same care as the management and 1957 evolution of the YANG modules themselves. The procedures in 1958 [I-D.ietf-core-sid] are being defined with this in mind. 1960 9. IANA Considerations 1962 9.1. Media-Types Registry 1964 This document adds the following Media-Type to the "Media Types" 1965 registry. 1967 +================+============================+===========+ 1968 | Name | Template | Reference | 1969 +================+============================+===========+ 1970 | yang-data+cbor | application/yang-data+cbor | RFC XXXX | 1971 +----------------+----------------------------+-----------+ 1973 Table 2 1975 // RFC Ed.: please replace RFC XXXX with this RFC number and remove 1976 this note. 1978 Type name: application 1979 Subtype name: yang-data+cbor 1980 Required parameters: N/A 1981 Optional parameters: id (see Section 7 of RFC XXXX) 1982 Encoding considerations: binary (CBOR) 1983 Security considerations: see Section 8 of RFC XXXX 1984 Published specification: RFC XXXX 1985 Person & email address to contact for further information: CORE WG 1986 mailing list (core@ietf.org), or IETF Applications and Real-Time 1987 Area (art@ietf.org) 1988 Intended usage: COMMON 1989 Restrictions on usage: none 1990 Author/Change controller: IETF 1992 9.2. CoAP Content-Formats Registry 1994 This document adds the following Content-Format to the "CoAP Content- 1995 Formats", within the "Constrained RESTful Environments (CoRE) 1996 Parameters" registry, where TBD3 comes from the "Expert Review" 0-255 1997 range and TBD1 and TBD2 come from the "IETF Review" 256-9999 range. 1999 +============================+================+======+===========+ 2000 | Content Type | Content Coding | ID | Reference | 2001 +============================+================+======+===========+ 2002 | application/yang-data+cbor | - | TBD1 | RFC XXXX | 2003 +----------------------------+----------------+------+-----------+ 2004 | application/yang- | - | TBD2 | RFC XXXX | 2005 | data+cbor; id=name | | | | 2006 +----------------------------+----------------+------+-----------+ 2007 | application/yang- | - | TBD3 | RFC XXXX | 2008 | data+cbor; id=sid | | | | 2009 +----------------------------+----------------+------+-----------+ 2011 Table 3 2013 // RFC Ed.: please replace TBDx with assigned IDs, remove the 2014 requested ranges, and remove this note. 2015 // RFC Ed.: please replace RFC XXXX with this RFC number and remove 2016 this note. 2018 9.3. CBOR Tags Registry 2020 In the registry "CBOR Tags" [IANA.cbor-tags], as per Section 9.2 of 2021 [RFC8949], IANA has allocated the CBOR tags in Table 4 for the YANG 2022 datatypes listed. 2024 +=====+==================+============================+===========+ 2025 | Tag | Data Item | Semantics | Reference | 2026 +=====+==================+============================+===========+ 2027 | 43 | text string | YANG bits datatype; see | RFC XXXX | 2028 | | | Section 6.7 | | 2029 +-----+------------------+----------------------------+-----------+ 2030 | 44 | text string | YANG enumeration datatype; | RFC XXXX | 2031 | | | see Section 6.6. | | 2032 +-----+------------------+----------------------------+-----------+ 2033 | 45 | unsigned integer | YANG identityref datatype; | RFC XXXX | 2034 | | or text string | see Section 6.10. | | 2035 +-----+------------------+----------------------------+-----------+ 2036 | 46 | unsigned integer | YANG instance-identifier | RFC XXXX | 2037 | | or text string | datatype; see | | 2038 | | or array | Section 6.13. | | 2039 +-----+------------------+----------------------------+-----------+ 2040 | 47 | unsigned integer | YANG Schema Item | RFC XXXX | 2041 | | | iDentifier (SID); see | | 2042 | | | Section 3.2. | | 2043 +-----+------------------+----------------------------+-----------+ 2045 Table 4: CBOR tags defined by this specification 2047 // RFC Ed.: please replace RFC XXXX with RFC number and remove this 2048 note 2050 10. References 2052 10.1. Normative References 2054 [IANA.cbor-tags] 2055 IANA, "Concise Binary Object Representation (CBOR) Tags", 2056 . 2058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2059 Requirement Levels", BCP 14, RFC 2119, 2060 DOI 10.17487/RFC2119, March 1997, 2061 . 2063 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2064 Specifications: ABNF", STD 68, RFC 5234, 2065 DOI 10.17487/RFC5234, January 2008, 2066 . 2068 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2069 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2070 . 2072 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2073 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2074 . 2076 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2077 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2078 . 2080 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2081 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2082 May 2017, . 2084 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2085 Interchange Format", STD 90, RFC 8259, 2086 DOI 10.17487/RFC8259, December 2017, 2087 . 2089 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2090 Definition Language (CDDL): A Notational Convention to 2091 Express Concise Binary Object Representation (CBOR) and 2092 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2093 June 2019, . 2095 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 2096 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 2097 June 2020, . 2099 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2100 Representation (CBOR)", STD 94, RFC 8949, 2101 DOI 10.17487/RFC8949, December 2020, 2102 . 2104 10.2. Informative References 2106 [I-D.ietf-core-comi] 2107 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 2108 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 2109 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 2110 January 2021, . 2113 [I-D.ietf-core-sid] 2114 Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. 2115 Richardson, "YANG Schema Item iDentifier (YANG SID)", Work 2116 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 2117 November 2021, . 2120 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2121 and A. Bierman, Ed., "Network Configuration Protocol 2122 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2123 . 2125 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2126 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2127 . 2129 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2130 Constrained-Node Networks", RFC 7228, 2131 DOI 10.17487/RFC7228, May 2014, 2132 . 2134 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2135 Application Protocol (CoAP)", RFC 7252, 2136 DOI 10.17487/RFC7252, June 2014, 2137 . 2139 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2140 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2141 2014, . 2143 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 2144 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 2145 . 2147 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 2148 RFC 8344, DOI 10.17487/RFC8344, March 2018, 2149 . 2151 Acknowledgments 2153 This document has been largely inspired by the extensive works done 2154 by Andy Bierman and Peter van der Stok on [I-D.ietf-core-comi]. 2155 [RFC7951] has also been a critical input to this work. The authors 2156 would like to thank the authors and contributors to these two drafts. 2158 The authors would also like to acknowledge the review, feedback, and 2159 comments from Ladislav Lhotka and Jürgen Schönwälder. 2161 Authors' Addresses 2163 Michel Veillette (editor) 2164 Trilliant Networks Inc. 2165 610 Rue du Luxembourg 2166 Granby Quebec J2J 2V2 2167 Canada 2168 Email: michel.veillette@trilliantinc.com 2170 Ivaylo Petrov (editor) 2171 Google Switzerland GmbH 2172 Brandschenkestrasse 110 2173 CH-8002 Zurich 2174 Switzerland 2175 Email: ivaylopetrov@google.com 2177 Alexander Pelov 2178 Acklio 2179 1137A avenue des Champs Blancs 2180 35510 Cesson-Sevigne 2181 France 2182 Email: a@ackl.io 2184 Carsten Bormann 2185 Universität Bremen TZI 2186 Postfach 330440 2187 D-28359 Bremen 2188 Germany 2189 Phone: +49-421-218-63921 2190 Email: cabo@tzi.org 2192 Michael Richardson 2193 Sandelman Software Works 2194 Canada 2195 Email: mcr+ietf@sandelman.ca