idnits 2.17.1 draft-ietf-netmod-yang-json-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2014) is 3483 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '123' on line 317 -- Looks like a reference, but probably isn't: '0' on line 317 == Outdated reference: A later version (-06) exists of draft-ietf-json-i-json-03 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-02 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track October 13, 2014 5 Expires: April 16, 2015 7 JSON Encoding of Data Modeled with YANG 8 draft-ietf-netmod-yang-json-01 10 Abstract 12 This document defines encoding rules for representing configuration, 13 state data, RPC input and output parameters, and notifications 14 defined using YANG as JavaScript Object Notation (JSON) text. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 16, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 52 3. Validation of JSON-encoded 53 Instance Data . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Names and Namespaces . . . . . . . . . . . . . . . . . . . . 4 55 5. Encoding of YANG Data Node Instances . . . . . . . . . . . . 6 56 5.1. The "leaf" Data Node . . . . . . . . . . . . . . . . . . 6 57 5.2. The "container" Data Node . . . . . . . . . . . . . . . . 7 58 5.3. The "leaf-list" Data Node . . . . . . . . . . . . . . . . 7 59 5.4. The "list" Data Node . . . . . . . . . . . . . . . . . . 7 60 5.5. The "anyxml" Data Node . . . . . . . . . . . . . . . . . 8 61 6. The Mapping of YANG Datatypes to JSON Values . . . . . . . . 8 62 6.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 9 63 6.2. The "string" Type . . . . . . . . . . . . . . . . . . . . 9 64 6.3. The "boolean" Type . . . . . . . . . . . . . . . . . . . 9 65 6.4. The "enumeration" Type . . . . . . . . . . . . . . . . . 9 66 6.5. The "bits" Type . . . . . . . . . . . . . . . . . . . . . 9 67 6.6. The "binary" Type . . . . . . . . . . . . . . . . . . . . 9 68 6.7. The "leafref" Type . . . . . . . . . . . . . . . . . . . 10 69 6.8. The "identityref" Type . . . . . . . . . . . . . . . . . 10 70 6.9. The "empty" Type . . . . . . . . . . . . . . . . . . . . 10 71 6.10. The "union" Type . . . . . . . . . . . . . . . . . . . . 11 72 6.11. The "instance-identifier" Type . . . . . . . . . . . . . 11 73 7. I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 14 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 81 B.1. Changes Between Revisions -00 and -01 . . . . . . . . . . 16 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for 87 encoding data in its Content Layer. Other management protocols might 88 want to use other encodings while still benefiting from using YANG 89 [RFC6020] as the data modeling language. 91 For example, the RESTCONF protocol [I-D.ietf-netconf-restconf] 92 supports two encodings: XML (media type "application/yang.data+xml") 93 and JSON (media type "application/yang.data+json). 95 The specification of the YANG data modelling language [RFC6020] 96 defines only XML encoding for data instances, i.e. contents of 97 configuration datastores, state data, RFC input and output 98 parameters, and event notifications. The aim of this document is to 99 define rules for encoding the same data as JavaScript Object Notation 100 (JSON) text [RFC7159]. 102 In order to achieve maximum interoperability while allowing 103 implementations to use a variety of available JSON parsers, the JSON 104 encoding rules follow, as much as possible, the constraints of the 105 I-JSON restricted profile [I-D.ietf-json-i-json]. Section Section 7 106 discusses I-JSON conformance in more detail. 108 2. Terminology and Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 The following terms are defined in [RFC6020]: 116 o anyxml 118 o augment 120 o container 122 o data node 124 o identity 126 o instance identifier 128 o leaf 130 o leaf-list 132 o list 134 o module 136 o submodule 138 3. Validation of JSON-encoded Instance Data 140 Instance data validation as defined in [RFC6020] is only applicable 141 to XML-encoded data. For one, semantic constraints in "must" 142 statements are expressed using XPath 1.0 [W3C.REC-xpath-19991116], 143 which can be properly interpreted only in the XML context. 145 This document along with the corresponding "XML Mapping Rules" 146 sections from [RFC6020] also define an implicit schema-driven mapping 147 of JSON-encoded instances to XML-encoded instances (and vice versa). 148 This mapping is mostly straightforward. In cases where doubts could 149 arise, this document gives explicit instructions for mapping JSON- 150 encoded instances to XML. 152 In order to validate a JSON instance document, it MUST first be 153 mapped, at least conceptually, to the corresponding XML instance 154 document. By definition, the JSON document is then valid if and only 155 if the XML document is valid according to the rules stated in 156 [RFC6020]. 158 4. Names and Namespaces 160 Instances of YANG data nodes (leafs, containers, leaf-lists, lists 161 and anyxml nodes) are always encoded as members of a JSON object, 162 i.e., as name/value pairs. This section defines how the name part is 163 formed, and the following sections deal with the value part. 165 Except in the cases specified below, the member name is identical to 166 the identifier of the corresponding YANG data node. Every such name 167 belongs to a namespace which is associated with the YANG module where 168 the corresponding data node is defined. If the data node is defined 169 in a submodule, then the namespace is determined by the main module 170 to which the submodule belongs. 172 If the namespace of a member name has to be explicitly specified, the 173 module name SHALL be used as a prefix to the (local) member name. 174 Both parts of the member name SHALL be separated with a colon 175 character (":"). In other words, the namespace-qualified name will 176 have the following form: 178 : 180 Figure 1: Encoding a namespace identifier with a local name. 182 Names with namespace identifiers in the form shown in Figure 1 MUST 183 be used for all top-level YANG data nodes, and also for all nodes 184 whose parent node belongs to a different namespace. Otherwise, names 185 with namespace identifiers MUST NOT be used. 187 For example, consider the following YANG module: 189 module foomod { 191 namespace "http://example.com/foomod"; 193 prefix "foo"; 195 container top { 196 leaf foo { 197 type uint8; 198 } 199 } 200 } 202 If the data model consists only of this module, then the following is 203 a valid JSON-encoded configuration: 205 { 206 "foomod:top": { 207 "foo": 54 208 } 209 } 211 Note that the top-level container instance contains the namespace 212 identifier (module name) but the "foo" leaf doesn't because it is 213 defined in the same module as its parent container. 215 Now, assume the container "top" is augmented from another module, 216 "barmod": 218 module barmod { 220 namespace "http://example.com/barmod"; 222 prefix "bar"; 224 import foomod { 225 prefix "foo"; 226 } 228 augment "/foo:top" { 229 leaf bar { 230 type boolean; 231 } 232 } 233 } 235 A valid JSON-encoded configuration containing both leafs may then 236 look like this: 238 { 239 "foomod:top": { 240 "foo": 54, 241 "barmod:bar": true 242 } 243 } 245 The name of the "bar" leaf must be prefixed with the namespace 246 identifier because its parent is defined in a different module, hence 247 it belongs to another namespace. 249 Explicit namespace identifiers are sometimes needed when encoding 250 values of the "identityref" and "instances-identifier" types. The 251 same form as shown in Figure 1 is then used as well. See Sections 252 6.8 and 6.11 for details. 254 5. Encoding of YANG Data Node Instances 256 Every complete JSON instance document, such as a configuration 257 datastore content, is an object. Its members are instances of all 258 top-level data nodes defined by the YANG data model. 260 Character encoding MUST be UTF-8. 262 Any data node instance is encoded as a name/value pair where the name 263 is formed from the data node identifier using the rules of Section 4. 264 The value depends on the category of the data node as explained in 265 the following subsections. 267 5.1. The "leaf" Data Node 269 A leaf instance is encoded as a name/value pair where the value can 270 be a string, number, literal 'true' or 'false' or the special array 271 '[null]', depending on the type of the leaf (see Section 6 for the 272 type encoding rules). 274 Example: For the leaf node definition 276 leaf foo { 277 type uint8; 278 } 280 the following is a valid JSON-encoded instance: 282 "foo": 123 284 5.2. The "container" Data Node 286 An container instance is encoded as a name/object pair. The 287 container's child data nodes are encoded as members of the object. 289 Example: For the container definition 291 container bar { 292 leaf foo { 293 type uint8; 294 } 295 } 297 the following is a valid instance: 299 "bar": { 300 "foo": 123 301 } 303 5.3. The "leaf-list" Data Node 305 A leaf-list is encoded as a name/array pair, and the array elements 306 are values whose type depends on the datatype of the leaf-list (see 307 Section 6). 309 Example: For the leaf-list definition 311 leaf-list foo { 312 type uint8; 313 } 315 the following is a valid instance: 317 "foo": [123, 0] 319 5.4. The "list" Data Node 321 A list instance is encoded as a name/array pair, and the array 322 elements are JSON objects. 324 Unlike the XML encoding, where list keys are required to precede any 325 other siblings, and to appear in the order specified by the data 326 model, the order of members within a JSON-encoded list entry is 327 arbitrary because JSON objects are fundamentally unordered 328 collections of members. 330 Example: For the list definition 331 list bar { 332 key foo; 333 leaf foo { 334 type uint8; 335 } 336 leaf baz { 337 type string; 338 } 339 } 341 the following is a valid instance: 343 "bar": [ 344 { 345 "foo": 123, 346 "baz": "zig" 347 }, 348 { 349 "baz": "zag", 350 "foo": 0 351 } 352 ] 354 5.5. The "anyxml" Data Node 356 An anyxml instance is translated to a name/value pair. The value can 357 be of any valid JSON type, i.e. an object, array, number, string or 358 any of the literals 'true', 'false' and 'null'. 360 This document defines no mapping between the contents of JSON- and 361 XML-encoded anyxml instances. It is not necessary because anyxml 362 contents are not subject to YANG-based validation (see sec. 7.10 in 363 [RFC6020]). 365 Example: For the anyxml definition 367 anyxml bar; 369 the following is a valid instance: 371 "bar": [true, null, true] 373 6. The Mapping of YANG Datatypes to JSON Values 375 The type of the JSON value in an instance of the leaf or leaf-list 376 data node depends on the datatype of that data node as specified in 377 the following subsections. 379 6.1. Numeric Datatypes 381 A value of the "int8", "int16", "int32", "uint8", "uint16" is 382 represented as a JSON number. 384 A value of the "int64", "uint64" or "decimal64" type is encoded as a 385 JSON string whose contents is the lexical representation of that 386 numeric value as specified in sections 9.2.1 and 9.3.1 of [RFC6020]. 388 For example, if the type of the leaf "foo" in Section 5.1 was 389 "unit64" instead of "uint8", the instance would have to be encoded as 391 "foo": "123" 393 The special handling of 64-bit numbers follows from I-JSON 394 recommendation to encode numbers exceeding the IEEE 754-2000 double 395 precision range as strings, see sec. 2.2 in [I-D.ietf-json-i-json]. 397 6.2. The "string" Type 399 A "string" value encoded as a JSON string, subject to JSON encoding 400 rules. 402 6.3. The "boolean" Type 404 A "boolean" value is mapped to the corresponding JSON literal name 405 'true' or 'false'. 407 6.4. The "enumeration" Type 409 An "enumeration" value is mapped in the same way as a string except 410 that the permitted values are defined by "enum" statements in YANG. 411 See sec. 9.6 in [RFC6020]. 413 6.5. The "bits" Type 415 A "bits" value is mapped to a JSON string identical to the lexical 416 representation of this value in XML, i.e., space-separated names 417 representing the individual bit values that are set. See sec. 9.7 in 418 [RFC6020]. 420 6.6. The "binary" Type 422 A "binary" value is mapped to a JSON string identical to the lexical 423 representation of this value in XML, i.e., base64-encoded binary 424 data. See sec. 9.8 in [RFC6020]. 426 6.7. The "leafref" Type 428 A "leafref" value is mapped according to the same rules as the type 429 of the leaf being referred to. 431 6.8. The "identityref" Type 433 An "identityref" value is mapped to a string representing the name of 434 an identity. Its namespace MUST be expressed as shown in Figure 1 if 435 it is different from the namespace of the leaf node containing the 436 identityref value, and MAY be expressed otherwise. 438 For example, consider the following schematic module: 440 module exmod { 441 ... 442 import ietf-interfaces { 443 prefix if; 444 } 445 import iana-if-type { 446 prefix ianaift; 447 } 448 ... 449 leaf type { 450 type identityref { 451 base "if:interface-type"; 452 } 453 } 454 } 456 A valid instance of the "type" leaf is then encoded as follows: 458 "type": "iana-if-type:ethernetCsmacd" 460 The namespace identifier "iana-if-type" must be present in this case 461 because the "ethernetCsmacd" identity is not defined in the same 462 module as the "type" leaf. 464 6.9. The "empty" Type 466 An "empty" value is mapped to '[null]', i.e., an array with the 467 'null' literal being its only element. 469 This encoding was chosen instead of using simply 'null' in order to 470 facilitate the use of empty leafs in common programming languages. 471 When used in a boolean context, the '[null]' value, unlike 'null', 472 evaluates to true. 474 Example: For the leaf definition 476 leaf foo { 477 type empty; 478 } 480 a valid instance is 482 "foo": [null] 484 6.10. The "union" Type 486 A value of the "union" type is encoded as the value of any of the 487 member types. 489 Unlike XML, JSON conveys part of the type information already in the 490 encoding. When validating a value of the "union" type, this 491 information MUST also be taken into account. 493 For example, consider the following YANG definition: 495 leaf bar { 496 type union { 497 type uint16; 498 type string; 499 } 500 } 502 In RESTCONF [I-D.ietf-netconf-restconf], it is fully acceptable to 503 set the value of "bar" in the following way when using the 504 "application/yang.data+xml" media type: 506 13.5 508 because the value may be interpreted as a string, i.e., the second 509 member type of the union. When using the "application/ 510 yang.data+json" media type, however, this is an error: 512 "bar": 13.5 514 In this case, the JSON encoding indicates the value is supposed to be 515 a number rather than string. 517 6.11. The "instance-identifier" Type 519 An "instance-identifier" value is encoded as a string that is 520 analogical to the lexical representation in XML encoding, see 521 sec. 9.13.3 in [RFC6020]. The only difference is that XML namespace 522 prefixes used for qualifying node names in the instance-identifier 523 value are replaced by the corresponding module names according to the 524 rules of Section 4. 526 Conversely, when translating such a value from JSON to XML, the 527 namespace identifier (YANG module name) in each component of the 528 instance-identifier MUST be replaced by the XML namespace prefix that 529 is associated with the namespace URI reference of the module. 531 For example, assume "ex" is the prefix associated with the namespace 532 URI that is defined in the "example" module. Then the XML-encoded 533 instance-identifier 535 /ex:system/ex:user[ex:name='fred'] 537 corresponds to the following JSON-encoded instance-identifier: 539 /example:system/example:user[example:name='fred'] 541 7. I-JSON Compliance 543 I-JSON [I-D.ietf-json-i-json] is a restricted profile of JSON that 544 guarantees maximum interoperability for protocols that use JSON in 545 their messages, no matter what JSON encoders/decoders are used in 546 protocol implementations. The encoding defined in this document 547 therefore observes the I-JSON requirements and recommendations as 548 closely as possible. 550 In particular, the following properties are guaranteed: 552 o Character encoding is UTF-8. 554 o Member names within the same JSON object are always unique. 556 o The order of JSON object members is never relied upon. 558 o Numbers of any type supported by YANG can be exchanged reliably. 559 See Section 6.1 for details. 561 The only two cases where a JSON instance document encoded according 562 to this document may deviate from I-JSON were dictated by the need to 563 be able to encode the same instance data in both JSON and XML. These 564 two exceptions are: 566 o Leaf values encoded as strings may contain code points identifying 567 Noncharacters that belong to the XML character set (see sec. 2.2 568 in [W3C.REC-xml-20081126]). 570 o Values of the "binary" type are encoded with the base64 encoding 571 scheme (see sec. 9.8.2 in [RFC6020]) whereas I-JSON recommends 572 base64url instead. However, the use of base64 should not cause 573 any interoperability problems because these values never appear in 574 an URL. 576 8. Security Considerations 578 This document defines an alternative encoding for data modeled in the 579 YANG data modeling language. As such, it doesn't contribute any new 580 security issues beyond those discussed in sec. 15 of [RFC6020]. 582 JSON is rather different from XML, and JSON parsers may thus suffer 583 from other types of vulnerabilities than their XML counterparts. To 584 minimize these security risks, it is important that client and server 585 software supporting JSON encoding behaves as required in sec. 3 of 586 [I-D.ietf-json-i-json]. That is, any received JSON data that violate 587 any of I-JSON strict constraints MUST NOT be trusted nor acted upon. 588 Violations due to the presence of Unicode Noncharacters in the data 589 exceptions (see Section 7) SHOULD be carefully examined. 591 9. Acknowledgments 593 The author wishes to thank Andy Bierman, Martin Bjorklund, Juergen 594 Schoenwaelder and Phil Shafer for their helpful comments and 595 suggestions. 597 10. References 599 10.1. Normative References 601 [I-D.ietf-json-i-json] 602 Bray, T., "The I-JSON Message Format", draft-ietf-json- 603 i-json-03 (work in progress), August 2014. 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997. 608 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 609 Network Configuration Protocol (NETCONF)", RFC 6020, 610 October 2010. 612 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 613 Bierman, "Network Configuration Protocol (NETCONF)", RFC 614 6241, June 2011. 616 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 617 Interchange Format", RFC 7159, March 2014. 619 [W3C.REC-xml-20081126] 620 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 621 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 622 Edition)", World Wide Web Consortium Recommendation REC- 623 xml-20081126, November 2008, 624 . 626 10.2. Informative References 628 [I-D.ietf-netconf-restconf] 629 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 630 Protocol", draft-ietf-netconf-restconf-02 (work in 631 progress), October 2014. 633 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 634 Management", RFC 7223, May 2014. 636 [W3C.REC-xpath-19991116] 637 Clark, J. and S. DeRose, "XML Path Language (XPath) 638 Version 1.0", World Wide Web Consortium Recommendation 639 REC-xpath-19991116, November 1999, 640 . 642 Appendix A. A Complete Example 644 The JSON document shown below represents the same data as the reply 645 to the NETCONF request appearing in Appendix D of [RFC7223]. 646 The data model is a combination of two YANG modules: "ietf- 647 interfaces" and "ex-vlan" (the latter is an example module from 648 Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf- 649 interfaces" module is considered to be active. 651 { 652 "ietf-interfaces:interfaces": { 653 "interface": [ 654 { 655 "name": "eth0", 656 "type": "iana-if-type:ethernetCsmacd", 657 "enabled": false 658 }, 659 { 660 "name": "eth1", 661 "type": "iana-if-type:ethernetCsmacd", 662 "enabled": true, 663 "ex-vlan:vlan-tagging": true 664 }, 665 { 666 "name": "eth1.10", 667 "type": "iana-if-type:l2vlan", 668 "enabled": true, 669 "ex-vlan:base-interface": "eth1", 670 "ex-vlan:vlan-id": 10 671 }, 672 { 673 "name": "lo1", 674 "type": "iana-if-type:softwareLoopback", 675 "enabled": true 676 } 677 ] 678 }, 679 "ietf-interfaces:interfaces-state": { 680 "interface": [ 681 { 682 "name": "eth0", 683 "type": "iana-if-type:ethernetCsmacd", 684 "admin-status": "down", 685 "oper-status": "down", 686 "if-index": 2, 687 "phys-address": "00:01:02:03:04:05", 688 "statistics": { 689 "discontinuity-time": "2013-04-01T03:00:00+00:00" 690 } 691 }, 692 { 693 "name": "eth1", 694 "type": "iana-if-type:ethernetCsmacd", 695 "admin-status": "up", 696 "oper-status": "up", 697 "if-index": 7, 698 "phys-address": "00:01:02:03:04:06", 699 "higher-layer-if": [ 700 "eth1.10" 701 ], 702 "statistics": { 703 "discontinuity-time": "2013-04-01T03:00:00+00:00" 704 } 705 }, 706 { 707 "name": "eth1.10", 708 "type": "iana-if-type:l2vlan", 709 "admin-status": "up", 710 "oper-status": "up", 711 "if-index": 9, 712 "lower-layer-if": [ 713 "eth1" 714 ], 715 "statistics": { 716 "discontinuity-time": "2013-04-01T03:00:00+00:00" 717 } 718 }, 719 { 720 "name": "eth2", 721 "type": "iana-if-type:ethernetCsmacd", 722 "admin-status": "down", 723 "oper-status": "down", 724 "if-index": 8, 725 "phys-address": "00:01:02:03:04:07", 726 "statistics": { 727 "discontinuity-time": "2013-04-01T03:00:00+00:00" 728 } 729 }, 730 { 731 "name": "lo1", 732 "type": "iana-if-type:softwareLoopback", 733 "admin-status": "up", 734 "oper-status": "up", 735 "if-index": 1, 736 "statistics": { 737 "discontinuity-time": "2013-04-01T03:00:00+00:00" 738 } 739 } 740 ] 741 } 742 } 744 Appendix B. Change Log 746 RFC Editor: Remove this section upon publication as an RFC. 748 B.1. Changes Between Revisions -00 and -01 750 o Metadata encoding was moved to a separate I-D, draft-lhotka- 751 netmod-yang-metadata. 753 o JSON encoding is now defined directly rather than via XML-JSON 754 mapping. 756 o The rules for namespace encoding has changed. This affect both 757 node instance names and instance-identifiers. 759 o I-JSON-related changes. The most significant is the string 760 encoding of 64-bit numbers. 762 o When validating union type, the partial type info present in JSON 763 encoding is taken into account. 765 o Added section about I-JSON compliance. 767 o Updated the example in appendix. 769 o Wrote Security Considerations. 771 o Removed IANA Considerations as there are none. 773 Author's Address 775 Ladislav Lhotka 776 CZ.NIC 778 Email: lhotka@nic.cz