idnits 2.17.1 draft-vanderstok-core-cbor-yid-00.txt: 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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 18, 2016) is 2780 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-02 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-16 == Outdated reference: A later version (-11) exists of draft-vanderstok-core-comi-09 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core P. van der Stok 3 Internet-Draft consultant 4 Intended status: Standards Track A. Bierman 5 Expires: February 19, 2017 YumaWorks, Inc. 6 August 18, 2016 8 CBOR format for YIDs 9 draft-vanderstok-core-cbor-yid-00 11 Abstract 13 This document describes CoAP content formats to transport CBOR 14 encoded YANG objects which use numeric YANG object identifiers. YANG 15 objects are serialized according to the YANG to CBOR encoding. The 16 object identifier is composed of a module number followed by a yang 17 name numeric identifier 19 Note 21 Discussion and suggestions for improvement are requested, and should 22 be sent to core@ietf.org. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 19, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Design Objectives . . . . . . . . . . . . . . . . . . . . . . 3 61 3. YANG Identifier . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. YANG Identifier encoding . . . . . . . . . . . . . . . . 4 63 3.2. Length of CBOR major type 0 and 1 . . . . . . . . . . . . 4 64 4. CBOR format to encode YID payload . . . . . . . . . . . . . . 6 65 4.1. module form encoding . . . . . . . . . . . . . . . . . . 6 66 4.2. single root encoding . . . . . . . . . . . . . . . . . . 6 67 5. YID addition to merge-patch+cbor . . . . . . . . . . . . . . 7 68 6. YID CBOR Examples . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. single module form . . . . . . . . . . . . . . . . . . . 7 70 6.2. Single root form encoding . . . . . . . . . . . . . . . . 9 71 6.3. Multi module form encoding . . . . . . . . . . . . . . . 9 72 6.4. Multi form encoding with clashes . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 11.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Appendix A. CBOR examples . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 The Concise Binary Object Representation (CBOR, [RFC7049]) defines a 86 binary representation for data that can be described using an 87 extension of the JSON data model [RFC7159]. 89 Numeric YANG Identifiers (YID), described in [I-D.bierman-core-yid], 90 represent YANG object names as numeric identifiers. They are 91 structured according to a module_id, local_id pattern. 93 This document specifies two new content formats. The content-format, 94 called "application/cbor+yid", follows the YANG to CBOR encoding 95 specified in [I-D.ietf-core-yang-cbor], and the YANG name string to 96 numeric identifier specified in [I-D.bierman-core-yid]. 98 The content format called "application/merge-patch+cbor+yid" is an 99 extension of the format specified in 100 [I-D.bormann-appsawg-cbor-merge-patch] 102 The delta encoding specified in [I-D.ietf-core-yang-cbor], is used 103 throughout. 105 The format is primarily intended to describe the numeric identifiers 106 of the CBOR encoded YANG objects transported with CoAP [RFC7252] 107 methods, as specified in [I-D.vanderstok-core-comi]. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 Readers of this specification should be familiar with all the terms 116 and concepts discussed in [RFC2578]. 118 The following terms are defined in the NETCONF protocol [RFC6241]: 119 client, configuration data, datastore, and server. 121 The following terms are defined in the YANG data modelling language 122 [RFC6020]: container, data node, key, key leaf, leaf, leaf-list, and 123 list. 125 The following terms are defined in RESTCONF protocol 126 [I-D.ietf-netconf-restconf]: data resource, data-store resource, edit 127 operation, query parameter, target resource, and unified data-store. 129 The following terms are defined in YANG ID protocol 130 [I-D.bierman-core-yid]: YANG module schema tree, YANG ID, YANG 131 Anchor, YANG Anchor subtree, and YANG Identifier File. 133 The following terms are defined in this document: 135 To be defined term: TODO: specification. 137 2. Design Objectives 139 This work is motivated by the need to minimize the size of numeric 140 object identifiers within protocol messages representing YANG data, 141 encoded according to the CBOR binary format. Both a single complete 142 resource description used with GET and PUT, and partial resource 143 descriptions used with FETCH, PATCH and iPATCH are specified. 145 3. YANG Identifier 147 The numeric YANG identifier used in this document is specified in 148 [I-D.bierman-core-yid]. A YANG Identifier is constructed of 2 149 fields: 151 YANG Identifier Format: 153 +-------------+ +------------+ 154 | module_id | | local_id | 155 +-------------+ +------------+ 157 The meaning of the identifiers in the above figure is: 159 module_id: This is a mandatory number that uniquely identifies a 160 module with a size of "module-bits" bits. 162 local_id: This is a number that uniquely defines a YANG name 163 within a module with a size of "local-bits" bits. Local 164 identifiers can be one of two formats: YANG Hash or Manually 165 Assigned. 167 3.1. YANG Identifier encoding 169 A YANG Identifier (YID) is constructed from module_id and local_id 170 according to the formula: 172 YID = (module_id*2^local-bits)+ local_id. 174 The CBOR encoding uses maps (major type 5) composed of pair (map.key, 175 map.value). Maps can be the parent of children maps. A map can have 176 1 or zero parents. A map without parents is called a root. 178 Using delta encoding (see [I-D.ietf-core-yang-cbor]), the YID is 179 encoded in the maps according to the following rules: 181 If the map is a root, YID(root) = root.key. 183 If the map has a parent, YID(map) = map.key + YID(parent). 185 3.2. Length of CBOR major type 0 and 1 187 Local_ids are represented as unsigned integers (major type 0) or 188 negative integers (major type 1). The two types in CBOR are either 189 represented as one byte, or as multiple bytes, where the first byte 190 indicates the length of the value. This has a consequence for the 191 local_id value size. The smallest possible value is 23 (5 bits), 192 encoded as one byte. For larger local_id values, their size should 193 be 8, 16, 32, and 64 bits, encoded in CBOR by as many bits + 8 bits. 195 When the local_id is based on hashes, clashes can occur. Below two 196 tables give the probability that at least one clash occurs or at 197 least two clashes occur for a given hash size in bits and the number 198 of names to be hashed. 200 +-----------------+---------+----------+---------+---------+ 201 | Number of names | 5 bits | 8 bits | 16 bits | 32 bits | 202 +-----------------+---------+----------+---------+---------+ 203 | 5 | 3,1E-01 | 3,9E-02 | 1,5E-04 | 2,3E-09 | 204 | | | | | | 205 | 10 | 1 | 1,7E-01 | 6,9E-04 | 1,1E-08 | 206 | | | | | | 207 | 20 | 1 | 7,4E-01 | 2,9E-03 | 4,4E-08 | 208 | | | | | | 209 | 40 | 1 | 1 | 1,2E-02 | 1,8E-07 | 210 | | | | | | 211 | 100 | 1 | 1 | 7,6E-02 | 1,2E-06 | 212 | | | | | | 213 | 200 | 1 | 1 | 3,0E-01 | 4,6E-06 | 214 +-----------------+---------+----------+---------+---------+ 216 Table 1: Probability of one or more clashes 218 +-----------------+---------+---------+---------+---------+ 219 | Number of names | 5 bits | 8 bits | 16 bits | 32 bits | 220 +-----------------+---------+---------+---------+---------+ 221 | 5 | 5,9E-02 | 9,2E-04 | 1,4E-08 | 3,3E-18 | 222 | | | | | | 223 | 10 | 1 | 2,5E-02 | 3,8E-07 | 8,8E-17 | 224 | | | | | | 225 | 20 | 1 | 5,0E-01 | 7,6E-06 | 1,8E-15 | 226 | | | | | | 227 | 40 | 1 | 1 | 1,4E-04 | 3,1E-14 | 228 | | | | | | 229 | 100 | 1 | 1 | 5,6E-03 | 1,3E-12 | 230 | | | | | | 231 | 200 | 1 | 1 | 9,1E-02 | 1,1E-10 | 232 +-----------------+---------+---------+---------+---------+ 234 Table 2: Probability of more than 2 entries equal clashes 236 It is clear that for hash size of 5 bits, more than 5 names will 237 certainly provoke one or more clashes. When the number of bits 238 should be as small as possible, an assignment of numbers per hand is 239 favored. 16 bit hashes can safely be used when less than 50 names 240 are present in the module. 32 bit hashes are recommended when more 241 than a few 1000 names occur in a module. 243 4. CBOR format to encode YID payload 245 The general format in Diagnostic JSON is shown below: 247 [ 248 { module_id*2^module-bits: { key: value .... }}, 249 { module_id*2^module-bits: { key: value .... }}, 250 ........................... 251 ] 253 This represents an array of maps, where each map in the array 254 represents a module. When there is one module, the array is removed 255 and a single map remains. The module value: module_id*2^module-bits 256 helps to reduce the key value sizes when multiple root maps follow. 257 When a single root map follows, the module value can be removed. 259 Two identifier forms are discussed in the two sections below: 261 4.1. module form encoding 263 The cbor-yid format is composed of an array (major type 4) of one or 264 more maps (major type 5) called "module maps". 266 The array of module maps collapses to one module map when there is 267 only one module map to transport. The module_id*2^module-bits is 268 represented as an unsigned integer (major type 0). 270 The key is represented as an unsigned integer (major type 0) or 271 negative integer (major type 1), where key = YID - 272 module_id*2^module-bits. YID is the YANG identifier of the YANG 273 object encoded with (key, value) pair. 275 4.2. single root encoding 277 In the special case that there is one module with one root, the cbor- 278 yid format is composed of one map (major type 5) called "object map" 279 as shown below. 281 { YID: value} 282 YID is the YANG Identifier of the YANG root map encoded with the 283 (YID, value) pair. YID = module_id*(2^module-bits) + local_id. The 284 value of the map follows the standard CBOR to YANG encoding. 286 5. YID addition to merge-patch+cbor 288 The general format in Diagnostic JSON is hown below: 290 [ 291 { module_id*2^module-bits: { merge-patch+cbor+yid format... }}, 292 { module_id*2^module-bits: { merge-patch+cbor+yid format --- }}, 293 ........................... 294 ] 296 The figure represents an array of module maps, where each module map 297 in the array represents a module payload encoded in the content 298 format application/merge-patch+cbor. When there is one module the 299 array is removed and a single module remains. 301 The merge-patch+cbor+yid format follows the merge-patch+cbor encoding 302 as specified in [I-D.bormann-appsawg-cbor-merge-patch] where each 303 numeric YANG identifier is encoded with the map keys as described in 304 Section 3.1. 306 6. YID CBOR Examples 308 This section show some examples based on the ietf-system module, or 309 on ietf-interfaces module. 311 6.1. single module form 313 Consider that module ietf-system has been attributed the unique 314 identifier 24. Assume the YANG hash size to be set to 6 bits. The 315 YANG hash values for 'clock', 'current-datetime', and 'boot-datetime' 316 are calculated by constructing the schema node identifier for the 317 objects, and then calculating the 5 bit murmur3 hash values (shown in 318 parentheses) in the figure below. The YIDs are calculated by adding 319 24*2^6 = 0xc00, leading to: 321 /ietf-system:system-state/clock (0x11) YID=0xc11 322 /ietf-system:system-state/clock/current-datetime (0xb) YID=0xc0b 323 /ietf-system:system-state/clock/boot-datetime (0x8) YID=0xc08 325 Consider the request for the values of the clock container, as 326 specified with JSON below. 328 REQ: GET example.com/c/system-state/clock 329 (Content-Format: application/json) 331 RES: 2.05 Content (Content-Format: application/cbor+yid) 332 { "system-state": { 333 "clock" : { 334 "current-datetime" : "2014-10-26T12:16:51Z", 335 "boot-datetime" : "2014-10-21T03:00:00Z" 336 } 337 } 338 } 340 Assuming that there are no hash clashes in the module, knowing that 341 only one module is concerned, using the numeric identifiers above, 342 and using 64 bit encoding [RFC4648] for the URI, the request looks 343 like: 345 REQ: GET example.com/c/CAR 346 (Content-Format: application/cbor+yid) 348 RES: 2.05 Content (Content-Format: application/cbor+yid) 349 { 0xc00: { 350 0x11 : { 351 -0x6 : "2014-10-26T12:16:51Z", 352 -0x9 : "2014-10-21T03:00:00Z" 353 } 354 } 355 } 357 Which creates the corresponding CBOR code to be transported: 359 a1 # map(1) 360 19 0c00 # unsigned(3072) 361 a1 # map(1) 362 11 # unsigned(17) 363 a2 # map(2) 364 25 # negative(5) 365 74 # text(20) 366 323031342d31302d32365431323a31363a35315a 367 # "2014-10-26T12:16:51Z" 368 28 # negative(8) 369 74 # text(20) 370 323031342d31302d32315430333a30303a30305a 371 # "2014-10-21T03:00:00Z" 373 The example shows that the map keys of the objects are encoded as 374 single bytes, because they their absolute value is smaller than 23. 375 The module identifier takes 12 bits and is encoded as two bytes. 377 6.2. Single root form encoding 379 The example of Section 6 can also be encoded in Single root form 380 encoding by stripping the module identifier. The request in 381 diagnostic JSON looks like: 383 REQ: GET example.com/c/CAR 384 (Content-Format: application/cbor+yid) 386 RES: 2.05 Content (Content-Format: application/cbor+yid) 387 { 0xc11 : { 388 -0x6 : "2014-10-26T12:16:51Z", 389 -0x9 : "2014-10-21T03:00:00Z" 390 } 391 } 393 In this simple example, the single root form requires less bytes than 394 the single module form. When there are multiple root maps within the 395 module, the module form generates less code because the module is 396 only encoded once and subtracted from the key values of the root 397 maps. 399 6.3. Multi module form encoding 401 Suppose there are multiple modules that are requested with the FETCH 402 method. The request is for "clock" from module ietf-system and the 403 other for "neighbor" from module ietf-interfaces. Assume the module 404 identifiers for ietf-system and ietf-interfaces are 24 and 7 405 respectively. 407 The YANG hash values for 'neighbor', 'ip', and 'link-layer-address' 408 are calculated by constructing the schema node identifier for the 409 objects, calculating the 7 bit murmur3 hash values (shown in 410 parenthesis below, followed by the module identifier calculation 411 7*2^8 = 0x700. This results in: 413 /ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor 414 (0x78) YID = 0x778 415 /ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor/ip 416 (0x40) YID = 0x740 417 /ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor/ 418 link-layer-address (0x47) YID =0x747 420 The Fetch request and response, assuming no clashes, are shown below: 422 REQ: FETCH example.com/mg/ 423 (Content-Format: application/cbor+yid) 424 [{0x30: 0x11}, { 0x700: 0x78}] 426 RES: 2.05 Content (Content-Format: application/cbor+yid) 427 [ 428 { 0xc00: { 429 0x11 : { 430 -0x6 : "2014-10-26T12:16:51Z", 431 -0x9 : "2014-10-21T03:00:00Z" 432 } 433 } 434 }, 435 { 0x700: { 436 0x78 : { 437 -0x38: "fe80::200:f8ff:fe21:67cf", 438 -0x31: "00:00::10:01:23:45" 439 } 440 } 441 } 442 ] 444 The corresponding CBOR code is shown in Appendix A. 446 6.4. Multi form encoding with clashes 448 As in Section 6.3, multiple modules that are requested with the FETCH 449 method. The request is for "clock" from module ietf-system and the 450 other for "neighbor" from module ietf-interfaces. Assume the module 451 identifiers for ietf-system and ietf-interfaces are 24 and 7 452 respectively. 454 Assume the YANG hash size is still set to 6 bits. Assume a clash 455 occurred during the hashing of the identifier, /ietf-system:system- 456 state/clock/current-datetime of module ietf-system. Another 457 identifier in ietf-system also has hash value 0xb. The rehashed 458 identifier for "clock" is set to 0x21 with bit 6 set to 1. 460 The new YANG hash values for 'clock', 'current-datetime', and 'boot- 461 datetime' are shown within parentheses in the figure below: 463 /ietf-system:system-state/clock (0x11) YID = 0xc11 464 /ietf-system:system-state/clock/current-datetime ( 0x21) YID = 0xc21 465 /ietf-system:system-state/clock/boot-datetime (0x8) YID = 0xc08 466 The Fetch request, including a rehash value, with answer is shown 467 below: 469 REQ: FETCH example.com/mg/ 470 (Content-Format: application/cbor+yid) 471 [{0xc00: 0x11}, { 0x700: 0x78}] 473 RES: 2.05 Content (Content-Format: application/cbor+yid) 474 [ 475 { 0xc00: { 476 0x11 : { 477 0x10 : "2014-10-26T12:16:51Z", 478 -0x9 : "2014-10-21T03:00:00Z" 479 } 480 } 481 }, 482 { 0x700: { 483 0x78 : { 484 -0x38: "fe80::200:f8ff:fe21:67cf", 485 -0x31: "00:00::10:01:23:45" 486 } 487 } 488 } 489 ] 491 The identifier 0xb of current-datetime has been replaced with the 492 rehash value 0x21. 494 The corresponding CBOR code is shown in Appendix A. 496 7. IANA Considerations 498 The Internet media type [RFC6838] for CBOR YANG Identifier are: 500 1. 502 * application/cbor+yid. 504 * Type name: application 506 * Subtype name: cbor+yid 508 * Required parameters: None 510 * Optional parameters: None 511 * Encoding considerations: Resources that use the "application/ 512 cbor+yid" media type are required to conform to the 513 "application/cbor" media type and are therefore subject to the 514 same encoding considerations specified in Section 7.3 of 515 [RFC7049]. 517 * Security considerations: As defined in this specification 519 * Published specification: This specification. 521 * Applications that use this media type: None currently known. 523 2. 525 * application/merge-patch+cbor+yid. 527 * Type name: application 529 * Subtype name: merge-patch+cbor+yid 531 * Required parameters: None 533 * Optional parameters: None 535 * Encoding considerations: Resources that use the "application/ 536 merge-patch+cbor+yid" media type are required to conform to 537 the "application/cbor" media type and are therefore subject to 538 the same encoding considerations specified in Section 7.3 of 539 [RFC7049]. 541 * Security considerations: As defined in this specification 543 * Published specification: This specification. 545 * Applications that use this media type: None currently known. 547 Additional information: 549 Magic number(s): N/A 551 File extension(s): N/A 553 Macintosh file type code(s): N/A 555 Person and email address to contact for further information: IESG 557 Intended usage: COMMON 558 Restrictions on usage: None 560 Author: Peter van der Stok < consultancy@vanderstok.org > 562 Change controller: IESG 564 8. Security considerations 566 Security considerations to be done. 568 9. Acknowledgements 570 We are very grateful to Bert Greevenbosch who suggested the use of 571 hashes and specified the use of murmur3. 573 10. Changelog 575 xxx 577 11. References 579 11.1. Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, 583 DOI 10.17487/RFC2119, March 1997, 584 . 586 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 587 the Network Configuration Protocol (NETCONF)", RFC 6020, 588 DOI 10.17487/RFC6020, October 2010, 589 . 591 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 592 Specifications and Registration Procedures", BCP 13, 593 RFC 6838, DOI 10.17487/RFC6838, January 2013, 594 . 596 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 597 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 598 October 2013, . 600 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 601 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 602 2014, . 604 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 605 Application Protocol (CoAP)", RFC 7252, 606 DOI 10.17487/RFC7252, June 2014, 607 . 609 [I-D.ietf-core-yang-cbor] 610 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 611 Minaburo, "CBOR Encoding of Data Modeled with YANG", 612 draft-ietf-core-yang-cbor-02 (work in progress), July 613 2016. 615 [I-D.bormann-appsawg-cbor-merge-patch] 616 Bormann, C. and P. Stok, "CBOR Merge Patch", draft- 617 bormann-appsawg-cbor-merge-patch-00 (work in progress), 618 March 2016. 620 [I-D.bierman-core-yid] 621 Bierman, A. and P. Stok, "Numeric YANG Identifiers", 622 draft-bierman-core-yid-00 (work in progress), August 2016. 624 11.2. Informative References 626 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 627 Schoenwaelder, Ed., "Structure of Management Information 628 Version 2 (SMIv2)", STD 58, RFC 2578, 629 DOI 10.17487/RFC2578, April 1999, 630 . 632 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 633 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 634 . 636 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 637 and A. Bierman, Ed., "Network Configuration Protocol 638 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 639 . 641 [I-D.ietf-netconf-restconf] 642 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 643 Protocol", draft-ietf-netconf-restconf-16 (work in 644 progress), August 2016. 646 [I-D.vanderstok-core-comi] 647 Stok, P. and A. Bierman, "CoAP Management Interface", 648 draft-vanderstok-core-comi-09 (work in progress), March 649 2016. 651 Appendix A. CBOR examples 653 The CBOR code belonging to Section 6.2 is shown below: 655 a1 # map(1) 656 19 0c11 # unsigned(3089) 657 a2 # map(2) 658 25 # negative(5) 659 74 # text(20) 660 323031342d31302d32365431323a31363a35315a 661 # "2014-10-26T12:16:51Z" 662 28 # negative(8) 663 74 # text(20) 664 323031342d31302d32315430333a30303a30305a 665 # "2014-10-21T03:00:00Z" 667 The CBOR code belonging to Section 6.3 is shown below: 669 82 # array(2) 670 a1 # map(1) 671 19 0c00 # unsigned(3072) 672 a1 # map(1) 673 11 # unsigned(17) 674 a2 # map(2) 675 25 # negative(5) 676 74 # text(20) 677 323031342d31302d32365431323a31363a35315a 678 # "2014-10-26T12:16:51Z" 679 28 # negative(8) 680 74 # text(20) 681 323031342d31302d32315430333a30303a30305a 682 # "2014-10-21T03:00:00Z" 683 a1 # map(1) 684 19 0700 # unsigned(1792) 685 a1 # map(1) 686 18 78 # unsigned(120) 687 a2 # map(2) 688 38 37 # negative(55) 689 78 18 # text(24) 690 666538303a3a3230303a663866663a666532313a36376366 691 # "fe80::200:f8ff:fe21:67cf" 692 38 30 # negative(48) 693 72 # text(18) 694 30303a30303a3a31303a30313a32333a3435 695 # "00:00::10:01:23:45" 697 Because the hash codes for the object identifiers of the ietf- 698 interface module are 1 byte long, the corresponding CBOR encoding 699 takes 2 bytes. 701 The CBOR code belonging to Section 6.4 is shown below: 703 82 # array(2) 704 a1 # map(1) 705 19 0c00 # unsigned(3072) 706 a1 # map(1) 707 11 # unsigned(17) 708 a2 # map(2) 709 10 # unsigned(16) 710 74 # text(20) 711 323031342d31302d32365431323a31363a35315a 712 # "2014-10-26T12:16:51Z" 713 28 # negative(8) 714 74 # text(20) 715 323031342d31302d32315430333a30303a30305a 716 # "2014-10-21T03:00:00Z" 717 a1 # map(1) 718 19 0700 # unsigned(1792) 719 a1 # map(1) 720 18 78 # unsigned(120) 721 a2 # map(2) 722 38 37 # negative(55) 723 78 18 # text(24) 724 666538303a3a3230303a663866663a666532313a36376366 725 # "fe80::200:f8ff:fe21:67cf" 726 38 30 # negative(48) 727 72 # text(18) 728 30303a30303a3a31303a30313a32333a3435 729 # "00:00::10:01:23:45" 731 The byte 0b, numeric identifier of current-datetime, has been 732 replaced by the one byte 20 due to the hash clash. 734 Authors' Addresses 736 Peter van der Stok 737 consultant 739 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 740 Email: consultancy@vanderstok.org 741 URI: www.vanderstok.org 742 Andy Bierman 743 YumaWorks, Inc. 744 685 Cochran St. 745 Suite #160 746 Simi Valley, CA 93065 747 USA 749 Email: andy@yumaworks.com