idnits 2.17.00 (12 Aug 2021) /tmp/idnits61213/draft-ietf-core-yang-cbor-18.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 December 2021) is 151 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 1268, but not defined -- Looks like a reference, but probably isn't: '257' on line 1268 == Missing Reference: '0-9' is mentioned on line 1635, but not defined == Missing Reference: '1-9' is mentioned on line 1625, but not defined == Missing Reference: '0-4' is mentioned on line 1635, but not defined == Missing Reference: '0-5' is mentioned on line 1635, but not defined -- Looks like a reference, but probably isn't: '01' on line 1635 Summary: 0 errors (**), 0 flaws (~~), 7 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: 23 June 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 December 2021 14 CBOR Encoding of Data Modeled with YANG 15 draft-ietf-core-yang-cbor-18 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 23 June 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . 10 65 4.1. The 'leaf' . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.1. Using SIDs in keys . . . . . . . . . . . . . . . . . 11 67 4.1.2. Using names in keys . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . 45 109 9.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 46 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 47 112 10.2. Informative References . . . . . . . . . . . . . . . . . 47 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): Unsigned 180 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. 230 In order to minimize the size of the encoded data, the mapping avoids 231 any unnecessary meta-information beyond that directly provided by the 232 CBOR basic generic data model (Section 2 of [RFC8949]). For 233 instance, CBOR tags are used solely in the case of an absolute SID, 234 anyxml data nodes, or the union datatype, to distinguish explicitly 235 the use of different YANG datatypes encoded using the same CBOR major 236 type. 238 Unless specified otherwise by the protocol or mechanism implementing 239 this specification, the indefinite length encoding as defined in 240 Section 3.2 of [RFC8949] SHALL be supported by the CBOR decoders 241 employed with YANG-CBOR. (This enables an implementation to begin 242 emitting an array or map before the number of entries in that 243 structure is known, possibly also avoiding excessive locking or race 244 conditions. On the other hand, it deprives the receiver of the 245 encoded data from advance announcement about some size information, 246 so a generator should choose indefinite length encoding only when 247 these benefits do accrue.) 249 Data nodes implemented using a CBOR array, map, byte string, or text 250 string can be instantiated but empty. In this case, they are encoded 251 with a length of zero. 253 When representation nodes are serialized using the rules defined by 254 this specification as part of an application payload, the payload 255 SHOULD include information that would allow a stateless way to 256 identify each node, such as the SID number associated with the node, 257 SID delta from another SID in the application payload, the namespace 258 qualified name, or the instance-identifier. 260 Examples in Section 4 include a root CBOR map with a single entry 261 having a key set to either a namespace qualified name or a SID. This 262 root CBOR map is provided only as a typical usage example and is not 263 part of the present encoding rules. Only the value within this CBOR 264 map is compulsory. 266 3.1. CBOR diagnostic notation 268 Within this document, CBOR binary contents are represented using an 269 equivalent textual form called CBOR diagnostic notation as defined in 270 Section 8 of [RFC8949]. This notation is used strictly for 271 documentation purposes and is never used in the data serialization. 272 Table 1 below provides a summary of this notation. 274 +==========+======+====================+===========+==========+ 275 | CBOR | CBOR | Diagnostic | Example | CBOR | 276 | content | type | notation | | encoding | 277 +==========+======+====================+===========+==========+ 278 | Unsigned | 0 | Decimal digits | 123 | 18 7B | 279 | integer | | | | | 280 +----------+------+--------------------+-----------+----------+ 281 | Negative | 1 | Decimal digits | -123 | 38 7A | 282 | integer | | prefixed by a | | | 283 | | | minus sign | | | 284 +----------+------+--------------------+-----------+----------+ 285 | Byte | 2 | Hexadecimal value | h'F15C' | 42 F15C | 286 | string | | enclosed between | | | 287 | | | single quotes and | | | 288 | | | prefixed by an 'h' | | | 289 +----------+------+--------------------+-----------+----------+ 290 | Text | 3 | String of Unicode | "txt" | 63 | 291 | string | | characters | | 747874 | 292 | | | enclosed between | | | 293 | | | double quotes | | | 294 +----------+------+--------------------+-----------+----------+ 295 | Array | 4 | Comma-separated | [ 1, 2 ] | 82 01 02 | 296 | | | list of values | | | 297 | | | within square | | | 298 | | | brackets | | | 299 +----------+------+--------------------+-----------+----------+ 300 | Map | 5 | Comma-separated | { 1: 123, | A2 | 301 | | | list of key : | 2: 456 } | 01187B | 302 | | | value pairs within | | 021901C8 | 303 | | | curly braces | | | 304 +----------+------+--------------------+-----------+----------+ 305 | Boolean | 7/20 | false | false | F4 | 306 +----------+------+--------------------+-----------+----------+ 307 | | 7/21 | true | true | F5 | 308 +----------+------+--------------------+-----------+----------+ 309 | Null | 7/22 | null | null | F6 | 310 +----------+------+--------------------+-----------+----------+ 311 | Not | 7/23 | undefined | undefined | F7 | 312 | assigned | | | | | 313 +----------+------+--------------------+-----------+----------+ 315 Table 1: CBOR diagnostic notation summary 317 Note: CBOR binary contents shown in this specification are annotated 318 with comments. These comments are delimited by slashes ("/") as 319 defined in [RFC8610] Appendix G.6. 321 3.2. YANG Schema Item iDentifier 323 Some of the items defined in YANG [RFC7950] require the use of a 324 unique identifier. In both Network Configuration Protocol (NETCONF) 325 [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented 326 using text strings. To allow the implementation of data models 327 defined in YANG in constrained devices and constrained networks, a 328 more compact method to identify YANG items is required. This compact 329 identifier, called YANG Schema Item iDentifier, is an unsigned 330 integer. The following items are identified using YANG SIDs (often 331 shortened to SIDs): 333 * identities 335 * data nodes 337 * RPCs and associated input(s) and output(s) 339 * actions and associated input(s) and output(s) 341 * YANG data structures 343 * notifications and associated information 345 * YANG modules and features 347 Note that any structuring of modules into submodules is transparent 348 to YANG-CBOR: SIDs are not allocated for the names of submodules, and 349 any items within a submodule are effectively allocated SIDs as part 350 of processing the module that includes them. 352 To minimize their size, SIDs used as keys in CBOR maps are encoded 353 using deltas, i.e., signed (negative or unsigned) integers that are 354 added to the reference SID applying to the map. The reference SID of 355 an outermost map is zero, unless a different reference SID is 356 unambiguously conferred from the environment in which the outermost 357 map is used. The reference SID of a map that is most directly 358 embedded in a map entry with a name-based key is zero. For all other 359 maps, the reference SID is the SID computed for the map entry it is 360 most directly embedded in. (The embedding may be indirect if an 361 array intervenes, e.g., in a YANG list.) Where absolute SIDs are 362 desired in map key positions where a bare integer implies a delta, 363 they may be encoded using CBOR tag 47 (as defined in Section 9.3). 365 Thus, conversion from SIDs to deltas and back to SIDs is a stateless 366 process solely based on the data serialized or deserialized combined 367 with, potentially, an outermost reference SID unambiguously conferred 368 by the environment. 370 Mechanisms and processes used to assign SIDs to YANG items and to 371 guarantee their uniqueness are outside the scope of the present 372 specification. If SIDs are to be used, the present specification is 373 used in conjunction with a specification defining this management. 374 [I-D.ietf-core-sid] is the definitive way to assign SID values for 375 YANG modules managed by the IETF. With YANG modules managed by non- 376 IETF entities, use of [I-D.ietf-core-sid] is RECOMMENDED. The 377 present specification has been designed to allow different methods of 378 assignment to be used within separate domains. 380 To provide implementations with a way to internally indicate the 381 absence of a SID, the SID value 0 is reserved and will not be 382 allocated; it is not used in interchange. 384 3.3. Name 386 This specification also supports the encoding of YANG item 387 identifiers as text strings, similar to those used by the JSON 388 Encoding of Data Modeled with YANG [RFC7951]. This approach can be 389 used to avoid the management overhead associated with SID allocation. 390 The main drawback is the significant increase in size of the encoded 391 data. 393 YANG item identifiers implemented using names MUST be in one of the 394 following forms: 396 * simple -- the identifier of the YANG item (i.e., schema node or 397 identity). 399 * namespace qualified -- the identifier of the YANG item is prefixed 400 with the name of the module in which this item is defined, 401 separated by the colon character (":"). 403 The name of a module determines the namespace of all YANG items 404 defined in that module. If an item is defined in a submodule, then 405 the namespace qualified name uses the name of the main module to 406 which the submodule belongs. 408 ABNF syntax [RFC5234] of a name is shown in Figure 1, where the 409 production for "identifier" is defined in Section 14 of [RFC7950]. 411 name = [identifier ":"] identifier 413 Figure 1: ABNF Production for a simple or namespace qualified name 415 A namespace qualified name MUST be used for all members of a top- 416 level CBOR map and then also whenever the namespaces of the 417 representation node and its parent node are different. In all other 418 cases, the simple form of the name SHOULD be used. 420 Definition example: 422 module example-foomod { 423 container top { 424 leaf foo { 425 type uint8; 426 } 427 } 428 } 430 module example-barmod { 431 import example-foomod { 432 prefix "foomod"; 433 } 434 augment "/foomod:top" { 435 leaf bar { 436 type boolean; 437 } 438 } 439 } 441 A valid CBOR encoding of the 'top' container is as follows. 443 CBOR diagnostic notation: 445 { 446 "example-foomod:top": { 447 "foo": 54, 448 "example-barmod:bar": true 449 } 450 } 452 Both the 'top' container and the 'bar' leaf defined in a different 453 YANG module as its parent container are encoded as namespace 454 qualified names. The 'foo' leaf defined in the same YANG module as 455 its parent container is encoded as simple name. 457 4. Encoding of Representation Nodes 459 Representation nodes defined using the YANG modeling language are 460 encoded using CBOR [RFC8949] based on the rules defined in this 461 section. We assume that the reader is already familiar with both 462 YANG [RFC7950] and CBOR [RFC8949]. 464 4.1. The 'leaf' 466 A 'leaf' MUST be encoded accordingly to its datatype using one of the 467 encoding rules specified in Section 6. 469 The following examples show the encoding of a 'hostname' leaf using a 470 SID or a name. 472 Definition example adapted from [RFC6991] and [RFC7317]: 474 typedef domain-name { 475 type string { 476 pattern 477 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 478 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 479 + '|\.'; 480 length "1..253"; 481 } 482 } 484 leaf hostname { 485 type inet:domain-name; 486 } 488 4.1.1. Using SIDs in keys 490 As with all examples below, the delta in the outermost map assumes a 491 reference YANG SID (current schema node) of 0. 493 CBOR diagnostic notation: 495 { 496 1752 : "myhost.example.com" / hostname (SID 1752) / 497 } 499 CBOR encoding: 501 A1 # map(1) 502 19 06D8 # unsigned(1752) 503 72 # text(18) 504 6D79686F73742E6578616D706C652E636F6D # "myhost.example.com" 506 4.1.2. Using names in keys 508 CBOR diagnostic notation: 510 { 511 "ietf-system:hostname" : "myhost.example.com" 512 } 514 CBOR encoding: 516 A1 # map(1) 517 74 # text(20) 518 696574662D73797374656D3A686F73746E616D65 519 72 # text(18) 520 6D79686F73742E6578616D706C652E636F6D 522 4.2. The 'container' and other nodes from the data tree 524 Instances of containers, YANG data structures, notification contents, 525 RPC inputs, RPC outputs, action inputs, and action outputs MUST be 526 encoded using a CBOR map data item (major type 5). The same encoding 527 is also used for the list entries in a list (Section 4.4). A map 528 consists of pairs of data items, with each pair consisting of a key 529 and a value. Each key within the CBOR map is set to a schema node 530 identifier, each value is set to the value of this representation 531 node according to the instance datatype. 533 This specification supports two types of CBOR map keys; SID as 534 defined in Section 3.2 and names as defined in Section 3.3. 536 The following examples show the encoding of a 'system-state' 537 container representation instance using SIDs or names. 539 Definition example adapted from [RFC6991] and [RFC7317]: 541 typedef date-and-time { 542 type string { 543 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 544 + '(Z|[\+\-]\d{2}:\d{2})'; 545 } 546 } 548 container system-state { 550 container clock { 551 leaf current-datetime { 552 type date-and-time; 553 } 555 leaf boot-datetime { 556 type date-and-time; 557 } 558 } 559 } 561 4.2.1. Using SIDs in keys 563 In the context of containers and other nodes from the data tree, CBOR 564 map keys within inner CBOR maps can be encoded using deltas or 565 absolute SIDs (tag 47). 567 Delta values are computed as follows: 569 * In the case of a 'container', deltas are equal to the SID of the 570 current representation node minus the SID of the parent 571 'container'. 573 * In the case of a 'list', deltas are equal to the SID of the 574 current representation node minus the SID of the parent 'list'. 576 * In the case of an 'RPC input' or 'RPC output', deltas are equal to 577 the SID of the current representation node minus the SID of the 578 'RPC'. 580 * In the case of an 'action input' or 'action output', deltas are 581 equal to the SID of the current representation node minus the SID 582 of the 'action'. 584 * In the case of a 'notification content', deltas are equal to the 585 SID of the current representation node minus the SID of the 586 'notification'. 588 CBOR diagnostic notation: 590 { 591 1720 : { / system-state (SID 1720) / 592 1 : { / clock (SID 1721) / 593 2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/ 594 1 : "2015-09-15T09:12:58Z-05:00" / boot-datetime (SID 1722) / 595 } 596 } 597 } 599 CBOR encoding: 601 A1 # map(1) 602 19 06B8 # unsigned(1720) 603 A1 # map(1) 604 01 # unsigned(1) 605 A2 # map(2) 606 02 # unsigned(2) 607 78 1A # text(26) 608 323031352D31302D30325431343A34373A32345A2D30353A3030 609 01 # unsigned(1) 610 78 1A # text(26) 611 323031352D30392D31355430393A31323A35385A2D30353A3030 613 Figure 2: System state clock encoding 615 4.2.2. Using names in keys 617 CBOR map keys implemented using names MUST be encoded using a CBOR 618 text string data item (major type 3). A namespace-qualified name 619 MUST be used each time the namespace of a representation node and its 620 parent differ. In all other cases, the simple form of the name MUST 621 be used. Names and namespaces are defined in Section 4 of [RFC7951]. 623 The following example shows the encoding of a 'system' container 624 representation node instance using names. 626 CBOR diagnostic notation: 628 { 629 "ietf-system:system-state" : { 630 "clock" : { 631 "current-datetime" : "2015-10-02T14:47:24Z-05:00", 632 "boot-datetime" : "2015-09-15T09:12:58Z-05:00" 633 } 634 } 635 } 637 CBOR encoding: 639 A1 # map(1) 640 78 18 # text(24) 641 696574662D73797374656D3A73797374656D2D7374617465 642 A1 # map(1) 643 65 # text(5) 644 636C6F636B # "clock" 645 A2 # map(2) 646 70 # text(16) 647 63757272656E742D6461746574696D65 648 78 1A # text(26) 649 323031352D31302D30325431343A34373A32345A2D30353A3030 650 6D # text(13) 651 626F6F742D6461746574696D65 652 78 1A # text(26) 653 323031352D30392D31355430393A31323A35385A2D30353A3030 655 4.3. The 'leaf-list' 657 A leaf-list MUST be encoded using a CBOR array data item (major type 658 4). Each entry of this array MUST be encoded accordingly to its 659 datatype using one of the encoding rules specified in Section 6. 661 The following example shows the encoding of the 'search' leaf-list 662 representation node instance containing two entries, "ietf.org" and 663 "ieee.org". 665 Definition example adapted from [RFC6991] and [RFC7317]: 667 typedef domain-name { 668 type string { 669 pattern 670 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 671 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 672 + '|\.'; 673 length "1..253"; 674 } 675 } 677 leaf-list search { 678 type domain-name; 679 ordered-by user; 680 } 682 4.3.1. Using SIDs in keys 684 CBOR diagnostic notation: 686 { 687 1746 : [ "ietf.org", "ieee.org" ] / search (SID 1746) / 688 } 690 CBOR encoding: 692 A1 # map(1) 693 19 06D2 # unsigned(1746) 694 82 # array(2) 695 68 # text(8) 696 696574662E6F7267 # "ietf.org" 697 68 # text(8) 698 696565652E6F7267 # "ieee.org" 700 4.3.2. Using names in keys 702 CBOR diagnostic notation: 704 { 705 "ietf-system:search" : [ "ietf.org", "ieee.org" ] 706 } 708 CBOR encoding: 710 A1 # map(1) 711 72 # text(18) 712 696574662D73797374656D3A736561726368 # "ietf-system:search" 713 82 # array(2) 714 68 # text(8) 715 696574662E6F7267 # "ietf.org" 716 68 # text(8) 717 696565652E6F7267 # "ieee.org" 719 4.4. The 'list' and 'list' entries 721 A list or a subset of a list MUST be encoded using a CBOR array data 722 item (major type 4). Each list entry within this CBOR array is 723 encoded using a CBOR map data item (major type 5) based on the 724 encoding rules of a collection as defined in Section 4.2. 726 It is important to note that this encoding rule also applies to a 727 'list' representation node instance that has a single entry. 729 The following examples show the encoding of a 'server' list using 730 SIDs or names. 732 Definition example from [RFC7317]: 734 list server { 735 key name; 737 leaf name { 738 type string; 739 } 740 choice transport { 741 case udp { 742 container udp { 743 leaf address { 744 type host; 745 mandatory true; 746 } 747 leaf port { 748 type port-number; 749 } 750 } 751 } 752 } 753 leaf association-type { 754 type enumeration { 755 enum server; 756 enum peer; 757 enum pool; 758 } 759 default server; 760 } 761 leaf iburst { 762 type boolean; 763 default false; 764 } 765 leaf prefer { 766 type boolean; 767 default false; 768 } 769 } 771 4.4.1. Using SIDs in keys 773 The encoding rules of each 'list' entry are defined in Section 4.2.1. 775 CBOR diagnostic notation: 777 { 778 1756 : [ / server (SID 1756) / 779 { 780 3 : "NRC TIC server", / name (SID 1759) / 781 5 : { / udp (SID 1761) / 782 1 : "tic.nrc.ca", / address (SID 1762) / 783 2 : 123 / port (SID 1763) / 784 }, 785 1 : 0, / association-type (SID 1757) / 786 2 : false, / iburst (SID 1758) / 787 4 : true / prefer (SID 1760) / 788 }, 789 { 790 3 : "NRC TAC server", / name (SID 1759) / 791 5 : { / udp (SID 1761) / 792 1 : "tac.nrc.ca" / address (SID 1762) / 793 } 794 } 795 ] 796 } 798 CBOR encoding: 800 A1 # map(1) 801 19 06DC # unsigned(1756) 802 82 # array(2) 803 A5 # map(5) 804 03 # unsigned(3) 805 6E # text(14) 806 4E52432054494320736572766572 # "NRC TIC server" 807 05 # unsigned(5) 808 A2 # map(2) 809 01 # unsigned(1) 810 6A # text(10) 811 7469632E6E72632E6361 # "tic.nrc.ca" 812 02 # unsigned(2) 813 18 7B # unsigned(123) 814 01 # unsigned(1) 815 00 # unsigned(0) 816 02 # unsigned(2) 817 F4 # primitive(20) 818 04 # unsigned(4) 819 F5 # primitive(21) 820 A2 # map(2) 821 03 # unsigned(3) 822 6E # text(14) 823 4E52432054414320736572766572 # "NRC TAC server" 824 05 # unsigned(5) 825 A1 # map(1) 826 01 # unsigned(1) 827 6A # text(10) 828 7461632E6E72632E6361 # "tac.nrc.ca" 830 4.4.2. Using names in keys 832 The encoding rules of each 'list' entry are defined in Section 4.2.2. 834 CBOR diagnostic notation: 836 { 837 "ietf-system:server" : [ 838 { 839 "name" : "NRC TIC server", 840 "udp" : { 841 "address" : "tic.nrc.ca", 842 "port" : 123 843 }, 844 "association-type" : 0, 845 "iburst" : false, 846 "prefer" : true 847 }, 848 { 849 "name" : "NRC TAC server", 850 "udp" : { 851 "address" : "tac.nrc.ca" 852 } 853 } 854 ] 855 } 857 CBOR encoding: 859 A1 # map(1) 860 72 # text(18) 861 696574662D73797374656D3A736572766572 862 82 # array(2) 863 A5 # map(5) 864 64 # text(4) 865 6E616D65 # "name" 866 6E # text(14) 867 4E52432054494320736572766572 868 63 # text(3) 869 756470 # "udp" 870 A2 # map(2) 871 67 # text(7) 872 61646472657373 # "address" 873 6A # text(10) 874 7469632E6E72632E6361 # "tic.nrc.ca" 875 64 # text(4) 876 706F7274 # "port" 877 18 7B # unsigned(123) 878 70 # text(16) 879 6173736F63696174696F6E2D74797065 880 00 # unsigned(0) 881 66 # text(6) 882 696275727374 # "iburst" 883 F4 # primitive(20) 884 66 # text(6) 885 707265666572 # "prefer" 886 F5 # primitive(21) 887 A2 # map(2) 888 64 # text(4) 889 6E616D65 # "name" 890 6E # text(14) 891 4E52432054414320736572766572 892 63 # text(3) 893 756470 # "udp" 894 A1 # map(1) 895 67 # text(7) 896 61646472657373 # "address" 897 6A # text(10) 898 7461632E6E72632E6361 # "tac.nrc.ca" 900 4.5. The 'anydata' 902 An anydata serves as a container for an arbitrary set of 903 representation nodes that otherwise appear as normal YANG-modeled 904 data. An anydata representation node instance is encoded using the 905 same rules as a container, i.e., CBOR map. The requirement that 906 anydata content can be modeled by YANG implies the following: 908 * CBOR map keys of any inner representation nodes MUST be set to 909 valid deltas or names. 911 * The CBOR array MUST contain either unique scalar values (as a 912 leaf-list, see Section 4.3), or maps (as a list, see Section 4.4). 914 * CBOR map values MUST follow the encoding rules of one of the 915 datatypes listed in Section 4. 917 The following example shows a possible use of an anydata. In this 918 example, an anydata is used to define a representation node 919 containing a notification event; this representation node can be part 920 of a YANG list to create an event logger. 922 Definition example: 924 module event-log { 925 ... 926 anydata last-event; # SID 60123 927 } 929 This example also assumes the assistance of the following 930 notification. 932 module example-port { 933 ... 935 notification example-port-fault { # SID 60200 936 leaf port-name { # SID 60201 937 type string; 938 } 939 leaf port-fault { # SID 60202 940 type string; 941 } 942 } 943 } 945 4.5.1. Using SIDs in keys 947 CBOR diagnostic notation: 949 { 950 60123 : { / last-event (SID 60123) / 951 77 : { / example-port-fault (SID 60200) / 952 1 : "0/4/21", / port-name (SID 60201) / 953 2 : "Open pin 2" / port-fault (SID 60202) / 954 } 955 } 956 } 958 CBOR encoding: 960 A1 # map(1) 961 19 EADB # unsigned(60123) 962 A1 # map(1) 963 18 4D # unsigned(77) 964 A2 # map(2) 965 01 # unsigned(1) 966 66 # text(6) 967 302F342F3231 # "0/4/21" 968 02 # unsigned(2) 969 6A # text(10) 970 4F70656E2070696E2032 # "Open pin 2" 972 In some implementations, it might be simpler to use the absolute SID 973 encoding (tag 47) for the anydata root element. CBOR diagnostic 974 notation: 976 { 977 60123 : { / last-event (SID 60123) / 978 47(60200) : { / event-port-fault (SID 60200) / 979 1 : "0/4/21", / port-name (SID 60201) / 980 2 : "Open pin 2" / port-fault (SID 60202) / 981 } 982 } 983 } 985 4.5.2. Using names in keys 987 CBOR diagnostic notation: 989 { 990 "event-log:last-event" : { 991 "example-port:example-port-fault" : { 992 "port-name" : "0/4/21", 993 "port-fault" : "Open pin 2" 994 } 995 } 996 } 997 CBOR encoding: 999 A1 # map(1) 1000 74 # text(20) 1001 6576656E742D6C6F673A6C6173742D6576656E74 1002 A1 # map(1) 1003 78 1F # text(31) 1004 6578616D706C652D706F72743A 1005 6578616D706C652D706F72742D6661756C74 1006 A2 # map(2) 1007 69 # text(9) 1008 706F72742D6E616D65 # "port-name" 1009 66 # text(6) 1010 302F342F3231 # "0/4/21" 1011 6A # text(10) 1012 706F72742D6661756C74 # "port-fault" 1013 6A # text(10) 1014 4F70656E2070696E2032 # "Open pin 2" 1016 4.6. The 'anyxml' 1018 An anyxml representation node is used to serialize an arbitrary CBOR 1019 content, i.e., its value can be any CBOR binary object. An anyxml 1020 value MAY contain CBOR data items tagged with one of the tags listed 1021 in Section 9.3. The tags listed in Section 9.3 SHALL be supported. 1023 The following example shows a valid CBOR encoded anyxml 1024 representation node instance consisting of a CBOR array containing 1025 the CBOR simple values 'true', 'null' and 'true'. 1027 Definition example from [RFC7951]: 1029 module bar-module { 1030 ... 1031 anyxml bar; # SID 60000 1032 } 1034 4.6.1. Using SIDs in keys 1036 CBOR diagnostic notation: 1038 { 1039 60000 : [true, null, true] / bar (SID 60000) / 1040 } 1042 CBOR encoding: 1044 A1 # map(1) 1045 19 EA60 # unsigned(60000) 1046 83 # array(3) 1047 F5 # primitive(21) 1048 F6 # primitive(22) 1049 F5 # primitive(21) 1051 4.6.2. Using names in keys 1053 CBOR diagnostic notation: 1055 { 1056 "bar-module:bar" : [true, null, true] / bar (SID 60000) / 1057 } 1059 CBOR encoding: 1061 A1 # map(1) 1062 6E # text(14) 1063 6261722D6D6F64756C653A626172 # "bar-module:bar" 1064 83 # array(3) 1065 F5 # primitive(21) 1066 F6 # primitive(22) 1067 F5 # primitive(21) 1069 5. Encoding of 'yang-data' extension 1071 The yang-data extension [RFC8040] is used to define data structures 1072 in YANG that are not intended to be implemented as part of a 1073 datastore. 1075 The yang-data extension will specify a container that MUST be encoded 1076 using the encoding rules of nodes of data trees as defined in 1077 Section 4.2. 1079 Just like YANG containers, the yang-data extension can be encoded 1080 using either SIDs or names. 1082 Definition example from [I-D.ietf-core-comi] Appendix A: 1084 module ietf-coreconf { 1085 ... 1087 import ietf-restconf { 1088 prefix rc; 1089 } 1091 rc:yang-data yang-errors { 1092 container error { 1093 leaf error-tag { 1094 type identityref { 1095 base error-tag; 1096 } 1097 } 1098 leaf error-app-tag { 1099 type identityref { 1100 base error-app-tag; 1101 } 1102 } 1103 leaf error-data-node { 1104 type instance-identifier; 1105 } 1106 leaf error-message { 1107 type string; 1108 } 1109 } 1110 } 1111 } 1113 5.1. Using SIDs in keys 1115 The yang-data extensions encoded using SIDs are carried in a CBOR map 1116 containing a single item pair. The key of this item is set to the 1117 SID assigned to the yang-data extension container; the value is set 1118 to the CBOR encoding of this container as defined in Section 4.2. 1120 This example shows a serialization example of the yang-errors yang- 1121 data extension as defined in [I-D.ietf-core-comi] using SIDs as 1122 defined in Section 3.2. 1124 CBOR diagnostic notation: 1126 { 1127 1024 : { / error (SID 1024) / 1128 4 : 1011, / error-tag (SID 1028) / 1129 / = invalid-value (SID 1011) / 1130 1 : 1018, / error-app-tag (SID 1025) / 1131 / = not-in-range (SID 1018) / 1132 2 : 1740, / error-data-node (SID 1026) / 1133 / = timezone-utc-offset (SID 1740) / 1134 3 : "Maximum exceeded" / error-message (SID 1027) / 1135 } 1136 } 1138 CBOR encoding: 1140 A1 # map(1) 1141 19 0400 # unsigned(1024) 1142 A4 # map(4) 1143 04 # unsigned(4) 1144 19 03F3 # unsigned(1011) 1145 01 # unsigned(1) 1146 19 03FA # unsigned(1018) 1147 02 # unsigned(2) 1148 19 06CC # unsigned(1740) 1149 03 # unsigned(3) 1150 70 # text(16) 1151 4D6178696D756D206578636565646564 # "Maximum exceeded" 1153 5.2. Using names in keys 1155 The yang-data extensions encoded using names are carried in a CBOR 1156 map containing a single item pair. The key of this item is set to 1157 the namespace qualified name of the yang-data extension container; 1158 the value is set to the CBOR encoding of this container as defined in 1159 Section 3.3. 1161 This example shows a serialization example of the yang-errors yang- 1162 data extension as defined in [I-D.ietf-core-comi] using names as 1163 defined Section 3.3. 1165 CBOR diagnostic notation: 1167 { 1168 "ietf-coreconf:error" : { 1169 "error-tag" : "invalid-value", 1170 "error-app-tag" : "not-in-range", 1171 "error-data-node" : "timezone-utc-offset", 1172 "error-message" : "Maximum exceeded" 1173 } 1174 } 1176 CBOR encoding: 1178 A1 # map(1) 1179 73 # text(19) 1180 696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error" 1181 A4 # map(4) 1182 69 # text(9) 1183 6572726F722D746167 # "error-tag" 1184 6D # text(13) 1185 696E76616C69642D76616C7565 # "invalid-value" 1186 6D # text(13) 1187 6572726F722D6170702D746167 # "error-app-tag" 1188 6C # text(12) 1189 6E6F742D696E2D72616E6765 # "not-in-range" 1190 6F # text(15) 1191 6572726F722D646174612D6E6F6465 # "error-data-node" 1192 73 # text(19) 1193 74696D657A6F6E652D7574632D6F6666736574 1194 # "timezone-utc-offset" 1195 6D # text(13) 1196 6572726F722D6D657373616765 # "error-message" 1197 70 # text(16) 1198 4D6178696D756D206578636565646564 # "Maximum exceeded" 1200 6. Representing YANG Data Types in CBOR 1202 The CBOR encoding of an instance of a leaf or leaf-list 1203 representation node depends on the built-in type of that 1204 representation node. The following sub-section defines the CBOR 1205 encoding of each built-in type supported by YANG as listed in 1206 Section 4.2.4 of [RFC7950]. Each subsection shows an example value 1207 assigned to a representation node instance of the discussed built-in 1208 type. 1210 6.1. The unsigned integer Types 1212 Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using 1213 a CBOR unsigned integer data item (major type 0). 1215 The following example shows the encoding of an 'mtu' leaf 1216 representation node instance set to 1280 bytes. 1218 Definition example from [RFC8344]: 1220 leaf mtu { 1221 type uint16 { 1222 range "68..max"; 1223 } 1224 } 1226 CBOR diagnostic notation: 1280 1228 CBOR encoding: 19 0500 1230 6.2. The integer Types 1232 Leafs of type int8, int16, int32 and int64 MUST be encoded using 1233 either CBOR unsigned integer (major type 0) or CBOR negative integer 1234 (major type 1), depending on the actual value. 1236 The following example shows the encoding of a 'timezone-utc-offset' 1237 leaf representation node instance set to -300 minutes. 1239 Definition example from [RFC7317]: 1241 leaf timezone-utc-offset { 1242 type int16 { 1243 range "-1500 .. 1500"; 1244 } 1245 } 1247 CBOR diagnostic notation: -300 1249 CBOR encoding: 39 012B 1251 6.3. The 'decimal64' Type 1253 Leafs of type decimal64 MUST be encoded using a decimal fraction as 1254 defined in Section 3.4.4 of [RFC8949]. 1256 The following example shows the encoding of a 'my-decimal' leaf 1257 representation node instance set to 2.57. 1259 Definition example from [RFC7317]: 1261 leaf my-decimal { 1262 type decimal64 { 1263 fraction-digits 2; 1264 range "1 .. 3.14 | 10 | 20..max"; 1265 } 1266 } 1268 CBOR diagnostic notation: 4([-2, 257]) 1270 CBOR encoding: C4 82 21 19 0101 1272 6.4. The 'string' Type 1274 Leafs of type string MUST be encoded using a CBOR text string data 1275 item (major type 3). 1277 The following example shows the encoding of a 'name' leaf 1278 representation node instance set to "eth0". 1280 Definition example from [RFC8343]: 1282 leaf name { 1283 type string; 1284 } 1286 CBOR diagnostic notation: "eth0" 1288 CBOR encoding: 64 65746830 1290 6.5. The 'boolean' Type 1292 Leafs of type boolean MUST be encoded using a CBOR simple value 1293 'true' (major type 7, additional information 21) or 'false' (major 1294 type 7, additional information 20). 1296 The following example shows the encoding of an 'enabled' leaf 1297 representation node instance set to 'true'. 1299 Definition example from [RFC7317]: 1301 leaf enabled { 1302 type boolean; 1303 } 1305 CBOR diagnostic notation: true 1307 CBOR encoding: F5 1309 6.6. The 'enumeration' Type 1311 Leafs of type enumeration MUST be encoded using a CBOR unsigned 1312 integer (major type 0) or CBOR negative integer (major type 1), 1313 depending on the actual value. Enumeration values are either 1314 explicitly assigned using the YANG statement 'value' or automatically 1315 assigned based on the algorithm defined in Section 9.6.4.2 of 1316 [RFC7950]. 1318 The following example shows the encoding of an 'oper-status' leaf 1319 representation node instance set to 'testing'. 1321 Definition example from [RFC7317]: 1323 leaf oper-status { 1324 type enumeration { 1325 enum up { value 1; } 1326 enum down { value 2; } 1327 enum testing { value 3; } 1328 enum unknown { value 4; } 1329 enum dormant { value 5; } 1330 enum not-present { value 6; } 1331 enum lower-layer-down { value 7; } 1332 } 1333 } 1335 CBOR diagnostic notation: 3 1337 CBOR encoding: 03 1339 Values of 'enumeration' types defined in a 'union' type MUST be 1340 encoded using a CBOR text string data item (major type 3) and MUST 1341 contain one of the names assigned by 'enum' statements in YANG (see 1342 also Section 6.12). The encoding MUST be enclosed by the enumeration 1343 CBOR tag as specified in Section 9.3. 1345 Definition example from [RFC7950]: 1347 type union { 1348 type int32; 1349 type enumeration { 1350 enum unbounded; 1351 } 1352 } 1354 CBOR diagnostic notation: 44("unbounded") 1356 CBOR encoding: D8 2C 69 756E626F756E646564 1358 6.7. The 'bits' Type 1360 Keeping in mind that bit positions are either explicitly assigned 1361 using the YANG statement 'position' or automatically assigned based 1362 on the algorithm defined in Section 9.7.4.2 of [RFC7950], each 1363 element of type bits could be seen as a set of bit positions (or 1364 offsets from position 0), that have a value of either 1, which 1365 represents the bit being set or 0, which represents that the bit is 1366 not set. 1368 Leafs of type bits MUST be encoded either using a CBOR array or byte 1369 string (major type 2). In case CBOR array representation is used, 1370 each element is either a positive integer (major type 0 with value 0 1371 being disallowed) that can be used to calculate the offset of the 1372 next byte string, or a byte string (major type 2) that carries the 1373 information whether certain bits are set or not. The initial offset 1374 value is 0 and each unsigned integer modifies the offset value of the 1375 next byte string by the integer value multiplied by 8. For example, 1376 if the bit offset is 0 and there is an integer with value 5, the 1377 first byte of the byte string that follows will represent bit 1378 positions 40 to 47 both ends included. If the byte string has a 1379 second byte, it will carry information about bits 48 to 55 and so on. 1380 Within each byte, bits are assigned from least to most significant. 1381 After the byte string, the offset is modified by the number of bytes 1382 in the byte string multiplied by 8. Bytes with no bits set (zero 1383 bytes) at the end of the byte string are never generated: If they 1384 would occur at the end of the array, the zero bytes are simply 1385 omitted; if they occur at the end of a byte string preceding an 1386 integer, the zero bytes are removed and the integer adjusted upwards 1387 by the number of zero bytes removed. An example follows. 1389 The following example shows the encoding of an 'alarm-state' leaf 1390 representation node instance with the 'critical' (position 3), 1391 'warning' (position 8) and 'indeterminate' (position 128) flags set. 1393 typedef alarm-state { 1394 type bits { 1395 bit unknown; 1396 bit under-repair; 1397 bit critical; 1398 bit major; 1399 bit minor; 1400 bit warning { 1401 position 8; 1402 } 1403 bit indeterminate { 1404 position 128; 1405 } 1406 } 1407 } 1409 leaf alarm-state { 1410 type alarm-state; 1411 } 1413 CBOR diagnostic notation: [h'0401', 14, h'01'] 1415 CBOR encoding: 83 42 0401 0E 41 01 1417 In a number of cases the array would only need to have one element -- 1418 a byte string with a few bytes inside. For this case, it is expected 1419 to omit the array element and have only the byte array that would 1420 have been inside. To illustrate this, let us consider the same 1421 example YANG definition, but this time encoding only 'under-repair' 1422 and 'critical' flags. The result would be 1424 CBOR diagnostic notation: h'06' 1426 CBOR encoding: 41 06 1428 Elements in the array MUST be either byte strings that do not end in 1429 a zero byte, or positive unsigned integers, where byte strings and 1430 integers MUST alternate, i.e., adjacent byte strings or adjacent 1431 integers are an error. An array with a single byte string MUST 1432 instead be encoded as just that byte string. An array with a single 1433 positive integer is an error. 1435 Values of 'bits' types defined in a 'union' type MUST be encoded 1436 using a CBOR text string data item (major type 3) and MUST contain a 1437 space-separated sequence of names of 'bits' that are set (see also 1438 Section 6.12). The encoding MUST be enclosed by the bits CBOR tag as 1439 specified in Section 9.3. 1441 The following example shows the encoding of an 'alarm-state' leaf 1442 representation node instance defined using a union type with the 1443 'under-repair' and 'critical' flags set. 1445 Definition example: 1447 leaf alarm-state-2 { 1448 type union { 1449 type alarm-state; 1450 type bits { 1451 bit extra-flag; 1452 } 1453 } 1454 } 1456 CBOR diagnostic notation: 43("under-repair critical") 1458 CBOR encoding: D8 2B 75 756E6465722D72657061697220637269746963616C 1460 6.8. The 'binary' Type 1462 Leafs of type binary MUST be encoded using a CBOR byte string data 1463 item (major type 2). 1465 The following example shows the encoding of an 'aes128-key' leaf 1466 representation node instance set to 1467 0x1f1ce6a3f42660d888d92a4d8030476e. 1469 Definition example: 1471 leaf aes128-key { 1472 type binary { 1473 length 16; 1474 } 1475 } 1477 CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E' 1479 CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E 1481 6.9. The 'leafref' Type 1483 Leafs of type leafref MUST be encoded using the rules of the 1484 representation node referenced by the 'path' YANG statement. 1486 The following example shows the encoding of an 'interface-state-ref' 1487 leaf representation node instance set to "eth1". 1489 Definition example from [RFC8343]: 1491 typedef interface-state-ref { 1492 type leafref { 1493 path "/interfaces-state/interface/name"; 1494 } 1495 } 1497 container interfaces-state { 1498 list interface { 1499 key "name"; 1500 leaf name { 1501 type string; 1502 } 1503 leaf-list higher-layer-if { 1504 type interface-state-ref; 1505 } 1506 } 1507 } 1509 CBOR diagnostic notation: "eth1" 1511 CBOR encoding: 64 65746831 1513 6.10. The 'identityref' Type 1515 This specification supports two approaches for encoding identityref: 1516 as a YANG Schema Item iDentifier as defined in Section 3.2, or as a 1517 name as defined in Section 6.8 of [RFC7951]. 1519 6.10.1. SIDs as identityref 1521 When representation nodes of type identityref are implemented using 1522 SIDs, they MUST be encoded using a CBOR unsigned integer data item 1523 (major type 0). (Note that, as they are not used in the position of 1524 CBOR map keys, no delta mechanism is employed for SIDs used for 1525 identityref.) 1527 The following example shows the encoding of a 'type' leaf 1528 representation node instance set to the value 'iana-if- 1529 type:ethernetCsmacd' (SID 1880). 1531 Definition example from [RFC7317]: 1533 identity interface-type { 1534 } 1536 identity iana-interface-type { 1537 base interface-type; 1538 } 1540 identity ethernetCsmacd { 1541 base iana-interface-type; 1542 } 1544 leaf type { 1545 type identityref { 1546 base interface-type; 1547 } 1548 } 1550 CBOR diagnostic notation: 1880 1552 CBOR encoding: 19 0758 1554 6.10.2. Name as identityref 1556 Alternatively, an identityref MAY be encoded using a name as defined 1557 in Section 3.3. When names are used, identityref MUST be encoded 1558 using a CBOR text string data item (major type 3). If the identity 1559 is defined in different module than the leaf node containing the 1560 identityref data node, the namespace qualified form MUST be used. 1561 Otherwise, both the simple and namespace qualified forms are 1562 permitted. Names and namespaces are defined in Section 3.3. 1564 The following example shows the encoding of the identity 'iana-if- 1565 type:ethernetCsmacd' using its namespace qualified name. This 1566 example is described in Section 6.10.1. 1568 CBOR diagnostic notation: "iana-if-type:ethernetCsmacd" 1570 CBOR encoding: 78 1b 1571 69616E612D69662D747970653A65746865726E657443736D616364 1573 6.11. The 'empty' Type 1575 Leafs of type empty MUST be encoded using the CBOR null value (major 1576 type 7, additional information 22). 1578 The following example shows the encoding of an 'is-router' leaf 1579 representation node instance when present. 1581 Definition example from [RFC8344]: 1583 leaf is-router { 1584 type empty; 1585 } 1587 CBOR diagnostic notation: null 1589 CBOR encoding: F6 1591 6.12. The 'union' Type 1593 Leafs of type union MUST be encoded using the rules associated with 1594 one of the types listed. When used in a union, the following YANG 1595 datatypes are enclosed by a CBOR tag to avoid confusion between 1596 different YANG datatypes encoded using the same CBOR major type. 1598 * bits 1600 * enumeration 1602 * identityref 1604 * instance-identifier 1606 See Section 9.3 for the assigned value of these CBOR tags. 1608 As mentioned in Section 6.6 and in Section 6.7, 'enumeration' and 1609 'bits' are encoded as a CBOR text string data item (major type 3) 1610 when defined within a 'union' type. (This adds considerable 1611 complexity, but is necessary because of an idiosyncrasy of the YANG 1612 data model for unions; the workaround allows compatibility to be 1613 maintained with the encoding of overlapping unions in XML and JSON. 1614 See also Section 9.12 of [RFC7950].) 1616 The following example shows the encoding of an 'ip-address' leaf 1617 representation node instance when set to "2001:db8:a0b:12f0::1". 1619 Definition example (adapted from [RFC6991]): 1621 typedef ipv4-address { 1622 type string { 1623 pattern 1624 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1625 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1626 + '(%[\p{N}\p{L}]+)?'; 1627 } 1628 } 1630 typedef ipv6-address { 1631 type string { 1632 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1633 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1634 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1635 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1636 + '(%[\p{N}\p{L}]+)?'; 1637 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1638 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1639 + '(%.+)?'; 1640 } 1641 } 1643 typedef ip-address { 1644 type union { 1645 type ipv4-address; 1646 type ipv6-address; 1647 } 1648 } 1650 leaf address { 1651 type ip-address; 1652 } 1654 CBOR diagnostic notation: "2001:db8:a0b:12f0::1" 1656 CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31 1658 6.13. The 'instance-identifier' Type 1660 This specification supports two approaches for encoding an instance- 1661 identifier, one based on YANG Schema Item iDentifier as defined in 1662 Section 3.2 and one based on names as defined in Section 3.3. 1664 6.13.1. SIDs as instance-identifier 1666 SIDs uniquely identify a schema node. In the case of a single 1667 instance schema node, i.e., a schema node defined at the root of a 1668 YANG module or submodule or schema nodes defined within a container, 1669 the SID is sufficient to identify this instance (representation 1670 node). (Note that no delta mechanism is employed for SIDs used for 1671 identityref, see Section 6.10.1.) 1673 In the case of a representation node that is an entry of a YANG list, 1674 a SID is combined with the list key(s) to identify each instance 1675 within the YANG list(s). 1677 Instance identifiers of single instance schema nodes MUST be encoded 1678 using a CBOR unsigned integer data item (major type 0) and set to the 1679 targeted schema node SID. 1681 Instance identifiers of representation node entries of a YANG list 1682 MUST be encoded using a CBOR array data item (major type 4) 1683 containing the following entries: 1685 * The first entry MUST be encoded as a CBOR unsigned integer data 1686 item (major type 0) and set to the targeted schema node SID. 1688 * The following entries MUST contain the value of each key required 1689 to identify the instance of the targeted schema node. These keys 1690 MUST be ordered as defined in the 'key' YANG statement, starting 1691 from the top level list, and followed by each of the subordinate 1692 list(s). 1694 Examples within this section assume the definition of a schema node 1695 of type 'instance-identifier': 1697 Definition example from [RFC7950]: 1699 container system { 1700 ... 1701 leaf reporting-entity { 1702 type instance-identifier; 1703 } 1705 *First example:* 1707 The following example shows the encoding of the 'reporting-entity' 1708 value referencing data node instance "/system/contact" (SID 1741). 1710 Definition example from [RFC7317]: 1712 container system { 1714 leaf contact { 1715 type string; 1716 } 1718 leaf hostname { 1719 type inet:domain-name; 1720 } 1721 } 1723 CBOR diagnostic notation: 1741 1725 CBOR encoding: 19 06CD 1727 *Second example:* 1729 This example aims to show how a representation node entry of a YANG 1730 list is identified. It uses a somewhat arbitrarily modified YANG 1731 module version from [RFC7317] by adding country to the leafs and keys 1732 of authorized-key. 1734 The following example shows the encoding of the 'reporting-entity' 1735 value referencing list instance "/system/authentication/user/ 1736 authorized-key/key-data" (which is assumed to have SID 1734) for 1737 username "bob" and authorized-key with name "admin" and country 1738 "france". 1740 list user { 1741 key name; 1743 leaf name { 1744 type string; 1745 } 1747 leaf password { 1748 type ianach:crypt-hash; 1749 } 1751 list authorized-key { 1752 key "name country"; 1754 leaf country { 1755 type string; 1756 } 1758 leaf name { 1759 type string; 1760 } 1762 leaf algorithm { 1763 type string; 1764 } 1766 leaf key-data { 1767 type binary; 1768 } 1769 } 1770 } 1772 CBOR diagnostic notation: [1734, "bob", "admin", "france"] 1774 CBOR encoding: 1776 84 # array(4) 1777 19 06C6 # unsigned(1734) 1778 63 # text(3) 1779 626F62 # "bob" 1780 65 # text(5) 1781 61646D696E # "admin" 1782 66 # text(6) 1783 6672616E6365 # "france" 1785 *Third example:* 1786 The following example shows the encoding of the 'reporting-entity' 1787 value referencing the list instance "/system/authentication/user" 1788 (SID 1730) corresponding to username "jack". 1790 CBOR diagnostic notation: [1730, "jack"] 1792 CBOR encoding: 1794 82 # array(2) 1795 19 06C2 # unsigned(1730) 1796 64 # text(4) 1797 6A61636B # "jack" 1799 6.13.2. Names as instance-identifier 1801 An "instance-identifier" value is encoded as a text string that is 1802 analogous to the lexical representation in XML encoding; see 1803 Section 9.13.2 of [RFC7950]. However, the encoding of namespaces in 1804 instance-identifier values follows the rules stated in Section 3.3, 1805 namely: 1807 * The leftmost (top-level) data node name is always in the namespace 1808 qualified form. 1810 * Any subsequent data node name is in the namespace qualified form 1811 if the node is defined in a module other than its parent node, and 1812 the simple form is used otherwise. This rule also holds for node 1813 names appearing in predicates. 1815 For example, 1817 /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip 1819 is a valid instance-identifier value because the data nodes 1820 "interfaces", "interface", and "name" are defined in the module 1821 "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". 1823 The resulting xpath MUST be encoded using a CBOR text string data 1824 item (major type 3). 1826 *First example:* 1828 This example is described in Section 6.13.1. 1830 CBOR diagnostic notation: "/ietf-system:system/contact" 1832 CBOR encoding: 1834 78 1c 2F696574662D73797374656D3A73797374656D2F636F6E74616374 1836 *Second example:* 1838 This example is described in Section 6.13.1. 1840 CBOR diagnostic notation (the line break is inserted for exposition 1841 only): 1843 "/ietf-system:system/authentication/user[name='bob']/ 1844 authorized-key[name='admin'][country='france']/key-data" 1846 CBOR encoding: 1848 78 6B 1849 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 1850 74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A 1851 65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27 1852 6672616E6365275D2F6B65792D64617461 1854 *Third example:* 1856 This example is described in Section 6.13.1. 1858 CBOR diagnostic notation: 1860 "/ietf-system:system/authentication/user[name='jack']" 1862 CBOR encoding: 1864 78 34 # text(52) 1865 2F696574662D73797374656D3A73797374656D2F61757468656E74696361 1866 74696F6E2F757365725B6E616D653D276A61636B275D 1868 7. Content-Types 1870 This specification defines the media-type application/yang-data+cbor, 1871 which can be used without parameters or with the parameter id=name or 1872 id=sid. 1874 This media-type represents a YANG-CBOR document containing a 1875 representation tree. If the media-type parameter id is present, 1876 depending on its value, each representation node is identified by its 1877 associated namespace qualified name as defined in Section 3.3 1878 (id=name), or by its associated YANG SID (represented as a SID delta 1879 or via tag 47) as defined in Section 3.2 (id=sid), respectively. If 1880 no id parameter is given, both forms may be present. 1882 The format of an application/yang-data+cbor representation is that of 1883 a CBOR map, mapping names and/or SIDs (as defined above) into 1884 instance values (using the rules defined in Section 4). 1886 It is not foreseen at this point that the valid set of values for the 1887 id parameter will extend beyond name, sid, or being unset; if that 1888 does happen, any new value is foreseen to be of the form 1889 [a-z][a-z0-9]*(-[a-z0-9]+)*. 1891 In summary, this document defines three content-types, which are 1892 intended for use by different classes of applications: 1894 * application/yang-data+cbor; id=sid -- for use by applications that 1895 need to be frugal with encoding space and text string processing 1896 (e.g., applications running on constrained nodes [RFC7228], or 1897 applications with particular performance requirements); 1899 * application/yang-data+cbor; id=name -- for use by applications 1900 that do not want to engage in SID management, and that have ample 1901 resources to manage text-string based item identifiers (e.g., 1902 applications that directly want to substitute application/ 1903 yang.data+json with a more efficient representation without any 1904 other changes); 1906 * application/yang-data+cbor -- for use by more complex applications 1907 that can benefit from the increased efficiency of SID identifiers 1908 but also need to integrate databases of YANG modules before SID 1909 mappings are defined for them. 1911 All three content-types are based on the same representation 1912 mechanisms, parts of which are simply not used in the first and 1913 second case. 1915 8. Security Considerations 1917 The security considerations of [RFC8949] and [RFC7950] apply. 1919 This document defines an alternative encoding for data modeled in the 1920 YANG data modeling language. As such, this encoding does not 1921 contribute any new security issues in addition to those identified 1922 for the specific protocol or context for which it is used. 1924 To minimize security risks, software on the receiving side SHOULD 1925 reject all messages that do not comply to the rules of this document 1926 and reply with an appropriate error message to the sender. 1928 When SIDs are in use, the interpretation of encoded data not only 1929 relies on having the right YANG modules, but also on having the right 1930 SID mapping information. Management and evolution of that mapping 1931 information therefore requires the same care as the management and 1932 evolution of the YANG modules themselves. The procedures in 1933 [I-D.ietf-core-sid] are RECOMMENDED for this purpose. 1935 9. IANA Considerations 1937 9.1. Media-Types Registry 1939 This document adds the following Media-Type to the "Media Types" 1940 registry. 1942 +================+============================+===========+ 1943 | Name | Template | Reference | 1944 +================+============================+===========+ 1945 | yang-data+cbor | application/yang-data+cbor | RFC XXXX | 1946 +----------------+----------------------------+-----------+ 1948 Table 2 1950 // RFC Ed.: please replace RFC XXXX with this RFC number and remove 1951 this note. 1953 Type name: application 1954 Subtype name: yang-data+cbor 1955 Required parameters: N/A 1956 Optional parameters: id (see Section 7 of RFC XXXX) 1957 Encoding considerations: binary (CBOR) 1958 Security considerations: see Section 8 of RFC XXXX 1959 Published specification: RFC XXXX 1960 Person & email address to contact for further information: CORE WG 1961 mailing list (core@ietf.org), or IETF Applications and Real-Time 1962 Area (art@ietf.org) 1963 Intended usage: COMMON 1964 Restrictions on usage: none 1965 Author/Change controller: IETF 1967 9.2. CoAP Content-Formats Registry 1969 This document adds the following Content-Format to the "CoAP Content- 1970 Formats", within the "Constrained RESTful Environments (CoRE) 1971 Parameters" registry, where TBD3 comes from the "Expert Review" 0-255 1972 range and TBD1 and TBD2 come from the "IETF Review" 256-9999 range. 1974 +============================+================+======+===========+ 1975 | Content Type | Content Coding | ID | Reference | 1976 +============================+================+======+===========+ 1977 | application/yang-data+cbor | - | TBD1 | RFC XXXX | 1978 +----------------------------+----------------+------+-----------+ 1979 | application/yang- | - | TBD2 | RFC XXXX | 1980 | data+cbor; id=name | | | | 1981 +----------------------------+----------------+------+-----------+ 1982 | application/yang- | - | TBD3 | RFC XXXX | 1983 | data+cbor; id=sid | | | | 1984 +----------------------------+----------------+------+-----------+ 1986 Table 3 1988 // RFC Ed.: please replace TBDx with assigned IDs, remove the 1989 requested ranges, and remove this note. 1990 // RFC Ed.: please replace RFC XXXX with this RFC number and remove 1991 this note. 1993 9.3. CBOR Tags Registry 1995 In the registry "CBOR Tags" [IANA.cbor-tags], as per Section 9.2 of 1996 [RFC8949], IANA has allocated the CBOR tags in Table 4 for the YANG 1997 datatypes listed. 1999 +=====+==================+============================+===========+ 2000 | Tag | Data Item | Semantics | Reference | 2001 +=====+==================+============================+===========+ 2002 | 43 | text string | YANG bits datatype; see | RFC XXXX | 2003 | | | Section 6.7 | | 2004 +-----+------------------+----------------------------+-----------+ 2005 | 44 | text string | YANG enumeration datatype; | RFC XXXX | 2006 | | | see Section 6.6. | | 2007 +-----+------------------+----------------------------+-----------+ 2008 | 45 | unsigned integer | YANG identityref datatype; | RFC XXXX | 2009 | | or text string | see Section 6.10. | | 2010 +-----+------------------+----------------------------+-----------+ 2011 | 46 | unsigned integer | YANG instance-identifier | RFC XXXX | 2012 | | or text string | datatype; see | | 2013 | | or array | Section 6.13. | | 2014 +-----+------------------+----------------------------+-----------+ 2015 | 47 | unsigned integer | YANG Schema Item | RFC XXXX | 2016 | | | iDentifier (SID); see | | 2017 | | | Section 3.2. | | 2018 +-----+------------------+----------------------------+-----------+ 2020 Table 4: CBOR tags defined by this specification 2022 // RFC Ed.: please replace RFC XXXX with RFC number and remove this 2023 note 2025 10. References 2027 10.1. Normative References 2029 [I-D.ietf-core-sid] 2030 Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. 2031 Richardson, "YANG Schema Item iDentifier (YANG SID)", Work 2032 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 2033 November 2021, . 2036 [IANA.cbor-tags] 2037 IANA, "Concise Binary Object Representation (CBOR) Tags", 2038 . 2040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2041 Requirement Levels", BCP 14, RFC 2119, 2042 DOI 10.17487/RFC2119, March 1997, 2043 . 2045 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2046 Specifications: ABNF", STD 68, RFC 5234, 2047 DOI 10.17487/RFC5234, January 2008, 2048 . 2050 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2051 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2052 . 2054 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2055 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2056 May 2017, . 2058 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2059 Definition Language (CDDL): A Notational Convention to 2060 Express Concise Binary Object Representation (CBOR) and 2061 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2062 June 2019, . 2064 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2065 Representation (CBOR)", STD 94, RFC 8949, 2066 DOI 10.17487/RFC8949, December 2020, 2067 . 2069 10.2. Informative References 2071 [I-D.ietf-core-comi] 2072 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 2073 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 2074 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 2075 January 2021, . 2078 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2079 and A. Bierman, Ed., "Network Configuration Protocol 2080 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2081 . 2083 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2084 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2085 . 2087 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2088 Constrained-Node Networks", RFC 7228, 2089 DOI 10.17487/RFC7228, May 2014, 2090 . 2092 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2093 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2094 2014, . 2096 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2097 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2098 . 2100 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2101 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2102 . 2104 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2105 Interchange Format", STD 90, RFC 8259, 2106 DOI 10.17487/RFC8259, December 2017, 2107 . 2109 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 2110 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 2111 . 2113 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 2114 RFC 8344, DOI 10.17487/RFC8344, March 2018, 2115 . 2117 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 2118 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 2119 June 2020, . 2121 Acknowledgments 2123 This document has been largely inspired by the extensive works done 2124 by Andy Bierman and Peter van der Stok on [I-D.ietf-core-comi]. 2125 [RFC7951] has also been a critical input to this work. The authors 2126 would like to thank the authors and contributors to these two drafts. 2128 The authors would also like to acknowledge the review, feedback, and 2129 comments from Ladislav Lhotka and Jürgen Schönwälder. 2131 Authors' Addresses 2133 Michel Veillette (editor) 2134 Trilliant Networks Inc. 2135 610 Rue du Luxembourg 2136 Granby Quebec J2J 2V2 2137 Canada 2139 Email: michel.veillette@trilliantinc.com 2141 Ivaylo Petrov (editor) 2142 Google Switzerland GmbH 2143 Brandschenkestrasse 110 2144 CH-8002 Zurich 2145 Switzerland 2147 Email: ivaylopetrov@google.com 2149 Alexander Pelov 2150 Acklio 2151 1137A avenue des Champs Blancs 2152 35510 Cesson-Sevigne 2153 France 2155 Email: a@ackl.io 2156 Carsten Bormann 2157 Universität Bremen TZI 2158 Postfach 330440 2159 D-28359 Bremen 2160 Germany 2162 Phone: +49-421-218-63921 2163 Email: cabo@tzi.org 2165 Michael Richardson 2166 Sandelman Software Works 2167 Canada 2169 Email: mcr+ietf@sandelman.ca