idnits 2.17.1 draft-ietf-netmod-yang-json-02.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 (November 27, 2014) is 3432 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 322 -- Looks like a reference, but probably isn't: '0' on line 322 == 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-03 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-02 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 2 errors (**), 0 flaws (~~), 4 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 November 27, 2014 5 Expires: May 31, 2015 7 JSON Encoding of Data Modeled with YANG 8 draft-ietf-netmod-yang-json-02 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 May 31, 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 Data Types to JSON Values . . . . . . . . 9 62 6.1. Numeric Types . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 10 68 6.7. The "leafref" Type . . . . . . . . . . . . . . . . . . . 10 69 6.8. The "identityref" Type . . . . . . . . . . . . . . . . . 10 70 6.9. The "empty" Type . . . . . . . . . . . . . . . . . . . . 11 71 6.10. The "union" Type . . . . . . . . . . . . . . . . . . . . 11 72 6.11. The "instance-identifier" Type . . . . . . . . . . . . . 12 73 7. I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 15 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 81 B.1. Changes Between Revisions -01 and -02 . . . . . . . . . . 17 82 B.2. Changes Between Revisions -00 and -01 . . . . . . . . . . 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for 88 encoding data in its Content Layer. Other management protocols might 89 want to use other encodings while still benefiting from using YANG 90 [RFC6020] as the data modeling language. 92 For example, the RESTCONF protocol [I-D.ietf-netconf-restconf] 93 supports two encodings: XML (media type "application/yang.data+xml") 94 and JSON (media type "application/yang.data+json). 96 The specification of the YANG data modelling language [RFC6020] 97 defines only XML encoding for data instances, i.e. contents of 98 configuration datastores, state data, RFC input and output 99 parameters, and event notifications. The aim of this document is to 100 define rules for encoding the same data as JavaScript Object Notation 101 (JSON) text [RFC7159]. 103 In order to achieve maximum interoperability while allowing 104 implementations to use a variety of available JSON parsers, the JSON 105 encoding rules follow, as much as possible, the constraints of the 106 I-JSON restricted profile [I-D.ietf-json-i-json]. Section Section 7 107 discusses I-JSON conformance in more detail. 109 2. Terminology and Notation 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 The following terms are defined in [RFC6020]: 117 o anyxml 119 o augment 121 o container 123 o data node 125 o identity 127 o instance identifier 129 o leaf 131 o leaf-list 133 o list 135 o module 137 o submodule 139 3. Validation of JSON-encoded Instance Data 141 Instance data validation as defined in [RFC6020] is only applicable 142 to XML-encoded data. For one, semantic constraints in "must" 143 statements are expressed using XPath 1.0 [W3C.REC-xpath-19991116], 144 which can be properly interpreted only in the XML context. 146 This document along with the corresponding "XML Mapping Rules" 147 sections from [RFC6020] also define an implicit schema-driven mapping 148 of JSON-encoded instances to XML-encoded instances (and vice versa). 149 This mapping is mostly straightforward. In cases where doubts could 150 arise, this document gives explicit instructions for mapping JSON- 151 encoded instances to XML. 153 In order to validate a JSON instance document, it MUST first be 154 mapped, at least conceptually, to the corresponding XML instance 155 document. By definition, the JSON document is then valid if and only 156 if the XML document is valid according to the rules stated in 157 [RFC6020]. 159 4. Names and Namespaces 161 Instances of YANG data nodes (leafs, containers, leaf-lists, lists 162 and anyxml nodes) are always encoded as members of a JSON object, 163 i.e., as name/value pairs. This section defines how the name part is 164 formed, and the following sections deal with the value part. 166 Except in the cases specified below, the member name is identical to 167 the identifier of the corresponding YANG data node. Every such name 168 belongs to a namespace which is associated with the YANG module where 169 the corresponding data node is defined. If the data node is defined 170 in a submodule, then the namespace is determined by the main module 171 to which the submodule belongs. 173 If the namespace of a member name has to be explicitly specified, the 174 module name SHALL be used as a prefix to the (local) member name. 175 Both parts of the member name SHALL be separated with a colon 176 character (":"). In other words, the namespace-qualified name will 177 have the following form: 179 : 181 Figure 1: Encoding a namespace identifier with a local name. 183 Names with namespace identifiers in the form shown in Figure 1 MUST 184 be used for all top-level YANG data nodes, and also for all nodes 185 whose parent node belongs to a different namespace. Otherwise, names 186 with namespace identifiers MUST NOT be used. 188 For example, consider the following YANG module: 190 module foomod { 192 namespace "http://example.com/foomod"; 194 prefix "foo"; 196 container top { 197 leaf foo { 198 type uint8; 199 } 200 } 201 } 203 If the data model consists only of this module, then the following is 204 a valid JSON-encoded configuration: 206 { 207 "foomod:top": { 208 "foo": 54 209 } 210 } 212 Note that the top-level container instance contains the namespace 213 identifier (module name) but the "foo" leaf doesn't because it is 214 defined in the same module as its parent container. 216 Now, assume the container "top" is augmented from another module, 217 "barmod": 219 module barmod { 221 namespace "http://example.com/barmod"; 223 prefix "bar"; 225 import foomod { 226 prefix "foo"; 227 } 229 augment "/foo:top" { 230 leaf bar { 231 type boolean; 232 } 233 } 234 } 236 A valid JSON-encoded configuration containing both leafs may then 237 look like this: 239 { 240 "foomod:top": { 241 "foo": 54, 242 "barmod:bar": true 243 } 244 } 246 The name of the "bar" leaf must be prefixed with the namespace 247 identifier because its parent is defined in a different module, hence 248 it belongs to another namespace. 250 Explicit namespace identifiers are sometimes needed when encoding 251 values of the "identityref" and "instances-identifier" types. The 252 same form as shown in Figure 1 is then used as well. See Sections 253 6.8 and 6.11 for details. 255 5. Encoding of YANG Data Node Instances 257 Every complete JSON instance document, such as a configuration 258 datastore content, is an object. Its members are instances of all 259 top-level data nodes defined by the YANG data model. 261 Character encoding MUST be UTF-8. 263 Any data node instance is encoded as a name/value pair where the name 264 is formed from the data node identifier using the rules of Section 4. 265 The value depends on the category of the data node as explained in 266 the following subsections. 268 5.1. The "leaf" Data Node 270 A leaf instance is encoded as a name/value pair where the value can 271 be a string, number, literal "true" or "false", or the special array 272 "[null]", depending on the type of the leaf (see Section 6 for the 273 type encoding rules). 275 Example: For the leaf node definition 277 leaf foo { 278 type uint8; 279 } 281 the following is a valid JSON-encoded instance: 283 "foo": 123 285 5.2. The "container" Data Node 287 An container instance is encoded as a name/object pair. The 288 container's child data nodes are encoded as members of the object. 290 Example: For the container definition 292 container bar { 293 leaf foo { 294 type uint8; 295 } 296 } 298 the following is a valid instance: 300 "bar": { 301 "foo": 123 302 } 304 5.3. The "leaf-list" Data Node 306 A leaf-list is encoded as a name/array pair, and the array elements 307 are values of the same type, which can be a string, number, literal 308 "true" or "false", or the special array "[null]", depending on the 309 type of the leaf-list (see Section 6 for the type encoding rules). 311 The order of array elements MUST be the same as the order of XML 312 elements representing leaf-list entries in the XML encoding. 314 Example: For the leaf-list definition 316 leaf-list foo { 317 type uint8; 318 } 320 the following is a valid instance: 322 "foo": [123, 0] 324 5.4. The "list" Data Node 326 A list instance is encoded as a name/array pair, and the array 327 elements are JSON objects. 329 The order of array elements MUST be the same as the order of XML 330 elements representing list entries in the XML encoding. 332 Unlike the XML encoding, where list keys are required to precede any 333 other siblings, and to appear in the order specified by the data 334 model, the order of members within a JSON-encoded list entry is 335 arbitrary because JSON objects are fundamentally unordered 336 collections of members. 338 Example: For the list definition 340 list bar { 341 key foo; 342 leaf foo { 343 type uint8; 344 } 345 leaf baz { 346 type string; 347 } 348 } 350 the following is a valid instance: 352 "bar": [ 353 { 354 "foo": 123, 355 "baz": "zig" 356 }, 357 { 358 "foo": 0, 359 "baz": "zag" 360 } 361 ] 363 5.5. The "anyxml" Data Node 365 An anyxml instance is encoded as a name/value pair. The value can be 366 of any valid JSON type, i.e. an object, array, number, string or one 367 of the literals "true", "false" and "null". 369 This document defines no mapping between the contents of JSON- and 370 XML-encoded anyxml instances. Note that the mapping is not needed 371 for the purposes of validation (Section 3) because anyxml contents 372 are not subject to YANG-based validation (see sec. 7.10 in 373 [RFC6020]). 375 Example: For the anyxml definition 377 anyxml bar; 379 the following is a valid instance: 381 "bar": [true, null, true] 383 6. The Mapping of YANG Data Types to JSON Values 385 The type of the JSON value in an instance of the leaf or leaf-list 386 data node depends on the type of that data node as specified in the 387 following subsections. 389 6.1. Numeric Types 391 A value of the "int8", "int16", "int32", "uint8", "uint16" and 392 "uint32" is represented as a JSON number. 394 A value of the "int64", "uint64" or "decimal64" type is encoded as a 395 JSON string whose contents is the lexical representation of that 396 numeric value as specified in sections 9.2.1 and 9.3.1 of [RFC6020]. 398 For example, if the type of the leaf "foo" in Section 5.1 was 399 "uint64" instead of "uint8", the instance would have to be encoded as 401 "foo": "123" 403 The special handling of 64-bit numbers follows from I-JSON 404 recommendation to encode numbers exceeding the IEEE 754-2000 double 405 precision range as strings, see sec. 2.2 in [I-D.ietf-json-i-json]. 407 6.2. The "string" Type 409 A "string" value encoded as a JSON string, subject to JSON encoding 410 rules. 412 6.3. The "boolean" Type 414 A "boolean" value is mapped to the corresponding JSON literal name 415 "true" or "false". 417 6.4. The "enumeration" Type 419 An "enumeration" value is mapped in the same way as a string except 420 that the permitted values are defined by "enum" statements in YANG. 421 See sec. 9.6 in [RFC6020]. 423 6.5. The "bits" Type 425 A "bits" value is mapped to a JSON string identical to the lexical 426 representation of this value in XML, i.e., space-separated names 427 representing the individual bit values that are set. See sec. 9.7 in 428 [RFC6020]. 430 6.6. The "binary" Type 432 A "binary" value is mapped to a JSON string identical to the lexical 433 representation of this value in XML, i.e., base64-encoded binary 434 data. See sec. 9.8 in [RFC6020]. 436 6.7. The "leafref" Type 438 A "leafref" value is mapped according to the same rules as the type 439 of the leaf being referred to. 441 6.8. The "identityref" Type 443 An "identityref" value is mapped to a string representing the name of 444 an identity. Its namespace MUST be expressed as shown in Figure 1 if 445 it is different from the namespace of the leaf node containing the 446 identityref value, and MAY be expressed otherwise. 448 For example, consider the following schematic module: 450 module exmod { 451 ... 452 import ietf-interfaces { 453 prefix if; 454 } 455 import iana-if-type { 456 prefix ianaift; 457 } 458 ... 459 leaf type { 460 type identityref { 461 base "if:interface-type"; 462 } 463 } 464 } 466 A valid instance of the "type" leaf is then encoded as follows: 468 "type": "iana-if-type:ethernetCsmacd" 470 The namespace identifier "iana-if-type" must be present in this case 471 because the "ethernetCsmacd" identity is not defined in the same 472 module as the "type" leaf. 474 6.9. The "empty" Type 476 An "empty" value is mapped to "[null]", i.e., an array with the 477 "null" literal being its only element. 479 This encoding was chosen instead of using simply "null" in order to 480 facilitate the use of empty leafs in common programming languages. 481 When used in a boolean context, the "[null]" value, unlike "null", 482 evaluates to true. 484 Example: For the leaf definition 486 leaf foo { 487 type empty; 488 } 490 a valid instance is 492 "foo": [null] 494 6.10. The "union" Type 496 A value of the "union" type is encoded as the value of any of the 497 member types. 499 Unlike XML, JSON conveys part of the type information already in the 500 encoding. When validating a value of the "union" type, this 501 information MUST also be taken into account. 503 For example, consider the following YANG definition: 505 leaf bar { 506 type union { 507 type uint16; 508 type string; 509 } 510 } 512 In RESTCONF [I-D.ietf-netconf-restconf], it is fully acceptable to 513 set the value of "bar" in the following way when using the 514 "application/yang.data+xml" media type: 516 13.5 518 because the value may be interpreted as a string, i.e., the second 519 member type of the union. When using the "application/ 520 yang.data+json" media type, however, this is an error: 522 "bar": 13.5 524 In this case, the JSON encoding indicates the value is supposed to be 525 a number rather than string. 527 6.11. The "instance-identifier" Type 529 An "instance-identifier" value is encoded as a string that is 530 analogical to the lexical representation in XML encoding, see 531 sec. 9.13.3 in [RFC6020]. However, the encoding of namespaces in 532 instance-identifier values follows the rules stated in Section 4, 533 namely: 535 o The namespace identifier is the module name where each data node 536 is defined. 538 o The encoding of a node name with an explicit namespace is as shown 539 in Figure 1. 541 o The leftmost (top-level) node name is always prefixed with the 542 namespace identifier. 544 o Any subsequent node name has the namespace identifier if and only 545 if its parent node has a different namespace. This also holds for 546 node names appearing in predicates. 548 For example, 550 /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip 552 is a valid instance-identifer value because the data nodes 553 "interfaces", "interface" and "name" are defined in the module "ietf- 554 interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". 556 When translating an instance-identifier value from JSON to XML, the 557 namespace identifier (YANG module name) in each component of the 558 instance-identifier MUST be replaced by an XML namespace prefix that 559 is associated with the namespace URI reference of the module in the 560 scope of the element containing the instance-identifier value. 562 7. I-JSON Compliance 564 I-JSON [I-D.ietf-json-i-json] is a restricted profile of JSON that 565 guarantees maximum interoperability for protocols that use JSON in 566 their messages, no matter what JSON encoders/decoders are used in 567 protocol implementations. The encoding defined in this document 568 therefore observes the I-JSON requirements and recommendations as 569 closely as possible. 571 In particular, the following properties are guaranteed: 573 o Character encoding is UTF-8. 575 o Member names within the same JSON object are always unique. 577 o The order of JSON object members is never relied upon. 579 o Numbers of any type supported by YANG can be exchanged reliably. 580 See Section 6.1 for details. 582 The only two cases where a JSON instance document encoded according 583 to this document may deviate from I-JSON were dictated by the need to 584 be able to encode the same instance data in both JSON and XML. These 585 two exceptions are: 587 o Leaf values encoded as strings may contain code points identifying 588 Noncharacters that belong to the XML character set (see sec. 2.2 589 in [W3C.REC-xml-20081126]). This issue is likely to be solved in 590 YANG 1.1 because noncharacters will not be allowed in string 591 values, see sec. 9.4 in [I-D.ietf-netmod-rfc6020bis]. 593 o Values of the "binary" type are encoded with the base64 encoding 594 scheme (Section 6.6), whereas I-JSON recommends base64url instead. 595 Theoretically, values of the "binary" type might appear in URI 596 references, such as Request-URI in RESTCONF, although in practice 597 the cases where it is really needed should be extremely rare. 599 8. Security Considerations 601 This document defines an alternative encoding for data modeled in the 602 YANG data modeling language. As such, it doesn't contribute any new 603 security issues beyond those discussed in sec. 15 of [RFC6020]. 605 JSON is rather different from XML, and JSON parsers may thus suffer 606 from other types of vulnerabilities than their XML counterparts. To 607 minimize these security risks, it is important that client and server 608 software supporting JSON encoding behaves as required in sec. 3 of 609 [I-D.ietf-json-i-json]. That is, any received JSON data that violate 610 any of I-JSON strict constraints MUST NOT be trusted nor acted upon. 611 Violations due to the presence of Unicode Noncharacters in the data 612 (see Section 7) SHOULD be carefully examined. 614 9. Acknowledgments 616 The author wishes to thank Andy Bierman, Martin Bjorklund, Balazs 617 Lengyel, Juergen Schoenwaelder and Phil Shafer for their helpful 618 comments and suggestions. 620 10. References 622 10.1. Normative References 624 [I-D.ietf-json-i-json] 625 Bray, T., "The I-JSON Message Format", draft-ietf-json- 626 i-json-03 (work in progress), August 2014. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 632 Network Configuration Protocol (NETCONF)", RFC 6020, 633 October 2010. 635 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 636 Bierman, "Network Configuration Protocol (NETCONF)", RFC 637 6241, June 2011. 639 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 640 Interchange Format", RFC 7159, March 2014. 642 [W3C.REC-xml-20081126] 643 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 644 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 645 Edition)", World Wide Web Consortium Recommendation REC- 646 xml-20081126, November 2008, 647 . 649 10.2. Informative References 651 [I-D.ietf-netconf-restconf] 652 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 653 Protocol", draft-ietf-netconf-restconf-03 (work in 654 progress), October 2014. 656 [I-D.ietf-netmod-rfc6020bis] 657 Bjorklund, M., "YANG - A Data Modeling Language for the 658 Network Configuration Protocol (NETCONF)", draft-ietf- 659 netmod-rfc6020bis-02 (work in progress), November 2014. 661 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 662 Management", RFC 7223, May 2014. 664 [W3C.REC-xpath-19991116] 665 Clark, J. and S. DeRose, "XML Path Language (XPath) 666 Version 1.0", World Wide Web Consortium Recommendation 667 REC-xpath-19991116, November 1999, 668 . 670 Appendix A. A Complete Example 672 The JSON document shown below represents the same data as the reply 673 to the NETCONF request appearing in Appendix D of [RFC7223]. 674 The data model is a combination of two YANG modules: "ietf- 675 interfaces" and "ex-vlan" (the latter is an example module from 676 Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf- 677 interfaces" module is considered to be active. 679 { 680 "ietf-interfaces:interfaces": { 681 "interface": [ 682 { 683 "name": "eth0", 684 "type": "iana-if-type:ethernetCsmacd", 685 "enabled": false 686 }, 687 { 688 "name": "eth1", 689 "type": "iana-if-type:ethernetCsmacd", 690 "enabled": true, 691 "ex-vlan:vlan-tagging": true 692 }, 693 { 694 "name": "eth1.10", 695 "type": "iana-if-type:l2vlan", 696 "enabled": true, 697 "ex-vlan:base-interface": "eth1", 698 "ex-vlan:vlan-id": 10 699 }, 700 { 701 "name": "lo1", 702 "type": "iana-if-type:softwareLoopback", 703 "enabled": true 704 } 705 ] 706 }, 707 "ietf-interfaces:interfaces-state": { 708 "interface": [ 709 { 710 "name": "eth0", 711 "type": "iana-if-type:ethernetCsmacd", 712 "admin-status": "down", 713 "oper-status": "down", 714 "if-index": 2, 715 "phys-address": "00:01:02:03:04:05", 716 "statistics": { 717 "discontinuity-time": "2013-04-01T03:00:00+00:00" 718 } 719 }, 720 { 721 "name": "eth1", 722 "type": "iana-if-type:ethernetCsmacd", 723 "admin-status": "up", 724 "oper-status": "up", 725 "if-index": 7, 726 "phys-address": "00:01:02:03:04:06", 727 "higher-layer-if": [ 728 "eth1.10" 729 ], 730 "statistics": { 731 "discontinuity-time": "2013-04-01T03:00:00+00:00" 732 } 733 }, 734 { 735 "name": "eth1.10", 736 "type": "iana-if-type:l2vlan", 737 "admin-status": "up", 738 "oper-status": "up", 739 "if-index": 9, 740 "lower-layer-if": [ 741 "eth1" 742 ], 743 "statistics": { 744 "discontinuity-time": "2013-04-01T03:00:00+00:00" 745 } 746 }, 747 { 748 "name": "eth2", 749 "type": "iana-if-type:ethernetCsmacd", 750 "admin-status": "down", 751 "oper-status": "down", 752 "if-index": 8, 753 "phys-address": "00:01:02:03:04:07", 754 "statistics": { 755 "discontinuity-time": "2013-04-01T03:00:00+00:00" 756 } 757 }, 758 { 759 "name": "lo1", 760 "type": "iana-if-type:softwareLoopback", 761 "admin-status": "up", 762 "oper-status": "up", 763 "if-index": 1, 764 "statistics": { 765 "discontinuity-time": "2013-04-01T03:00:00+00:00" 766 } 767 } 768 ] 769 } 770 } 772 Appendix B. Change Log 774 RFC Editor: Remove this section upon publication as an RFC. 776 B.1. Changes Between Revisions -01 and -02 778 o Encoding of namespaces in instance-identifiers was changed. 780 o Text specifying the order of array elements in leaf-list and list 781 instances was added. 783 B.2. Changes Between Revisions -00 and -01 785 o Metadata encoding was moved to a separate I-D, draft-lhotka- 786 netmod-yang-metadata. 788 o JSON encoding is now defined directly rather than via XML-JSON 789 mapping. 791 o The rules for namespace encoding has changed. This affect both 792 node instance names and instance-identifiers. 794 o I-JSON-related changes. The most significant is the string 795 encoding of 64-bit numbers. 797 o When validating union type, the partial type info present in JSON 798 encoding is taken into account. 800 o Added section about I-JSON compliance. 802 o Updated the example in appendix. 804 o Wrote Security Considerations. 806 o Removed IANA Considerations as there are none. 808 Author's Address 810 Ladislav Lhotka 811 CZ.NIC 813 Email: lhotka@nic.cz