idnits 2.17.1 draft-ietf-netmod-yang-json-03.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 (February 24, 2015) is 3342 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 324 -- Looks like a reference, but probably isn't: '0' on line 324 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-03 -- 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 February 24, 2015 5 Expires: August 28, 2015 7 JSON Encoding of Data Modeled with YANG 8 draft-ietf-netmod-yang-json-03 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 August 28, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . 10 66 6.5. The "bits" Type . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 13 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 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 -02 and -03 . . . . . . . . . . 17 82 B.2. Changes Between Revisions -01 and -02 . . . . . . . . . . 17 83 B.3. Changes Between Revisions -00 and -01 . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for 89 encoding data in its Content Layer. Other management protocols might 90 want to use other encodings while still benefiting from using YANG 91 [RFC6020] as the data modeling language. 93 For example, the RESTCONF protocol [I-D.ietf-netconf-restconf] 94 supports two encodings: XML (media type "application/yang.data+xml") 95 and JSON (media type "application/yang.data+json). 97 The specification of the YANG data modelling language [RFC6020] 98 defines only XML encoding for data instances, i.e. contents of 99 configuration datastores, state data, RFC input and output 100 parameters, and event notifications. The aim of this document is to 101 define rules for encoding the same data as JavaScript Object Notation 102 (JSON) text [RFC7159]. 104 In order to achieve maximum interoperability while allowing 105 implementations to use a variety of available JSON parsers, the JSON 106 encoding rules follow, as much as possible, the constraints of the 107 I-JSON restricted profile [I-D.ietf-json-i-json]. Section 7 108 discusses I-JSON conformance in more detail. 110 2. Terminology and Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The following terms are defined in [RFC6020]: 118 o anyxml 120 o augment 122 o container 124 o data node 126 o identity 128 o instance identifier 130 o leaf 132 o leaf-list 134 o list 136 o module 138 o submodule 140 3. Validation of JSON-encoded Instance Data 142 Instance data validation as defined in [RFC6020] is only applicable 143 to XML-encoded data. For one, semantic constraints in "must" 144 statements are expressed using XPath 1.0 [W3C.REC-xpath-19991116], 145 which can be properly interpreted only in the XML context. 147 This document and the corresponding "XML Mapping Rules" sections from 148 [RFC6020] also define an implicit schema-driven mapping of JSON- 149 encoded instances to XML-encoded instances (and vice versa). This 150 mapping is mostly straightforward. In cases where doubts could 151 arise, this document gives explicit instructions for mapping JSON- 152 encoded instances to XML. 154 In order to validate a JSON instance document, it MUST first be 155 mapped, at least conceptually, to the corresponding XML instance 156 document. By definition, the JSON document is then valid if and only 157 if the XML document is valid according to the rules stated in 158 [RFC6020]. 160 4. Names and Namespaces 162 Instances of YANG data nodes (leafs, containers, leaf-lists, lists 163 and anyxml nodes) are always encoded as members of a JSON object, 164 i.e., as name/value pairs. This section defines how the name part is 165 formed, and the following sections deal with the value part. 167 Except in the cases specified below, the member name is identical to 168 the identifier of the corresponding YANG data node. Every such name 169 belongs to a namespace which is associated with the YANG module where 170 the corresponding data node is defined. If the data node is defined 171 in a submodule, then the namespace is determined by the main module 172 to which the submodule belongs. 174 If the namespace of a member name has to be explicitly specified, the 175 module name SHALL be used as a prefix to the (local) member name. 176 Both parts of the member name SHALL be separated with a colon 177 character (":"). In other words, the namespace-qualified name will 178 have the following form: 180 : 182 Figure 1: Encoding a namespace identifier with a local name. 184 Names with namespace identifiers in the form shown in Figure 1 are 185 used if and only if the parent data node belongs to a different 186 namespace, which also includes all top-level YANG data nodes. 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 is prefixed with the namespace identifier 247 because its parent is defined in a different module, hence it belongs 248 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 ordering of array elements follows the same rules as the ordering 312 of XML elements representing leaf-list entries in the XML encoding. 313 Specifically, the "ordered-by" properties (sec. 7.7.5 in [RFC6020]) 314 MUST be observed. 316 Example: For the leaf-list definition 318 leaf-list foo { 319 type uint8; 320 } 322 the following is a valid instance: 324 "foo": [123, 0] 326 5.4. The "list" Data Node 328 A list instance is encoded as a name/array pair, and the array 329 elements are JSON objects. 331 The ordering of array elements follows the same rules as the ordering 332 of XML elements representing list entries in the XML encoding. 334 Specifically, the "ordered-by" properties (sec. 7.7.5 in [RFC6020]) 335 MUST be observed. 337 Unlike the XML encoding, where list keys are required to precede any 338 other siblings within a list entry, and appear in the order specified 339 by the data model, the order of members in a JSON-encoded list entry 340 is arbitrary because JSON objects are fundamentally unordered 341 collections of members. 343 Example: For the list definition 345 list bar { 346 key foo; 347 leaf foo { 348 type uint8; 349 } 350 leaf baz { 351 type string; 352 } 353 } 355 the following is a valid instance: 357 "bar": [ 358 { 359 "foo": 123, 360 "baz": "zig" 361 }, 362 { 363 "baz": "zag", 364 "foo": 0 365 } 366 ] 368 5.5. The "anyxml" Data Node 370 An anyxml instance is encoded as a name/value pair. The value can be 371 of any valid JSON type, i.e. an object, array, number, string or one 372 of the literals "true", "false" and "null". 374 This document imposes no other restrictions on the contents of JSON- 375 encoded anyxml instances. It also doesn't define any universal 376 mapping between the contents of JSON- and XML-encoded anyxml 377 instances - note that such a mapping is not needed for the purposes 378 of validation (Section 3) because anyxml contents are not subject to 379 YANG-based validation (see sec. 7.10 in [RFC6020]). However, each 380 definition of an anyxml node MAY specify, in its "description" 381 statement, appropriate syntactic, semantic and mapping rules for the 382 values of that anyxml data node. 384 Example: For the anyxml definition 386 anyxml bar; 388 the following is a valid instance: 390 "bar": [true, null, true] 392 6. The Mapping of YANG Data Types to JSON Values 394 The type of the JSON value in an instance of the leaf or leaf-list 395 data node depends on the type of that data node as specified in the 396 following subsections. 398 6.1. Numeric Types 400 A value of the "int8", "int16", "int32", "uint8", "uint16" and 401 "uint32" is represented as a JSON number. 403 A value of the "int64", "uint64" or "decimal64" type is encoded as a 404 JSON string whose contents is the lexical representation of that 405 numeric value as specified in sections 9.2.1 and 9.3.1 of [RFC6020]. 407 For example, if the type of the leaf "foo" in Section 5.1 was 408 "uint64" instead of "uint8", the instance would have to be encoded as 410 "foo": "123" 412 The special handling of 64-bit numbers follows from I-JSON 413 recommendation to encode numbers exceeding the IEEE 754-2008 double 414 precision range as strings, see sec. 2.2 in [I-D.ietf-json-i-json]. 416 6.2. The "string" Type 418 A "string" value encoded as a JSON string, subject to JSON string 419 encoding rules. 421 6.3. The "boolean" Type 423 A "boolean" value is mapped to the corresponding JSON literal name 424 "true" or "false". 426 6.4. The "enumeration" Type 428 An "enumeration" value is mapped in the same way as a string except 429 that the permitted values are defined by "enum" statements in YANG. 430 See sec. 9.6 in [RFC6020]. 432 6.5. The "bits" Type 434 A "bits" value is mapped to a JSON string identical to the lexical 435 representation of this value in XML, i.e., space-separated names 436 representing the individual bit values that are set. See sec. 9.7 in 437 [RFC6020]. 439 6.6. The "binary" Type 441 A "binary" value is mapped to a JSON string identical to the lexical 442 representation of this value in XML, i.e., base64-encoded binary 443 data. See sec. 9.8 in [RFC6020]. 445 6.7. The "leafref" Type 447 A "leafref" value is mapped according to the same rules as the type 448 of the leaf being referred to. 450 6.8. The "identityref" Type 452 An "identityref" value is mapped to a string representing the name of 453 an identity. Its namespace MUST be expressed as shown in Figure 1 if 454 it is different from the namespace of the leaf node containing the 455 identityref value, and MAY be expressed otherwise. 457 For example, consider the following schematic module: 459 module exmod { 460 ... 461 import ietf-interfaces { 462 prefix if; 463 } 464 import iana-if-type { 465 prefix ianaift; 466 } 467 ... 468 leaf type { 469 type identityref { 470 base "if:interface-type"; 471 } 472 } 473 } 474 A valid instance of the "type" leaf is then encoded as follows: 476 "type": "iana-if-type:ethernetCsmacd" 478 The namespace identifier "iana-if-type" must be present in this case 479 because the "ethernetCsmacd" identity is not defined in the same 480 module as the "type" leaf. 482 6.9. The "empty" Type 484 An "empty" value is mapped to "[null]", i.e., an array with the 485 "null" literal being its only element. 487 This encoding was chosen instead of using simply "null" in order to 488 facilitate the use of empty leafs in common programming languages. 489 When used in a boolean context, the "[null]" value, unlike "null", 490 evaluates to true. 492 Example: For the leaf definition 494 leaf foo { 495 type empty; 496 } 498 a valid instance is 500 "foo": [null] 502 6.10. The "union" Type 504 A value of the "union" type is encoded as the value of any of the 505 member types. 507 Unlike XML, JSON conveys part of the type information already in the 508 encoding. When validating a value of the "union" type, this 509 information MUST also be taken into account. 511 For example, consider the following YANG definition: 513 leaf bar { 514 type union { 515 type uint16; 516 type string; 517 } 518 } 519 In RESTCONF [I-D.ietf-netconf-restconf], it is fully acceptable to 520 set the value of "bar" in the following way when using the 521 "application/yang.data+xml" media type: 523 13.5 525 because the value may be interpreted as a string, i.e., the second 526 member type of the union. When using the "application/ 527 yang.data+json" media type, however, this is an error: 529 "bar": 13.5 531 In this case, the JSON encoding indicates the value is supposed to be 532 a number rather than a string. 534 6.11. The "instance-identifier" Type 536 An "instance-identifier" value is encoded as a string that is 537 analogical to the lexical representation in XML encoding, see 538 sec. 9.13.3 in [RFC6020]. However, the encoding of namespaces in 539 instance-identifier values follows the rules stated in Section 4, 540 namely: 542 o The namespace identifier is the module name where each data node 543 is defined. 545 o The encoding of a node name with an explicit namespace is as shown 546 in Figure 1. 548 o The leftmost (top-level) node name is always prefixed with the 549 namespace identifier. 551 o Any subsequent node name has the namespace identifier if and only 552 if its parent node has a different namespace. This also holds for 553 node names appearing in predicates. 555 For example, 557 /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip 559 is a valid instance-identifer value because the data nodes 560 "interfaces", "interface" and "name" are defined in the module "ietf- 561 interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". 563 When translating an instance-identifier value from JSON to XML, the 564 namespace identifier (YANG module name) in each component of the 565 instance-identifier MUST be replaced by an XML namespace prefix that 566 is associated with the namespace URI reference of the module in the 567 scope of the element containing the instance-identifier value. 569 7. I-JSON Compliance 571 I-JSON [I-D.ietf-json-i-json] is a restricted profile of JSON that 572 guarantees maximum interoperability for protocols that use JSON in 573 their messages, no matter what JSON encoders/decoders are used in 574 protocol implementations. The encoding defined in this document 575 therefore observes the I-JSON requirements and recommendations as 576 closely as possible. 578 In particular, the following properties are guaranteed: 580 o Character encoding is UTF-8. 582 o Member names within the same JSON object are always unique. 584 o The order of JSON object members is never relied upon. 586 o Numbers of any type supported by YANG can be exchanged reliably. 587 See Section 6.1 for details. 589 The only two cases where a JSON instance document encoded according 590 to this document may deviate from I-JSON were dictated by the need to 591 be able to encode the same instance data in both JSON and XML. These 592 two exceptions are: 594 o Leaf values encoded as strings may contain code points identifying 595 Noncharacters that belong to the XML character set (see sec. 2.2 596 in [W3C.REC-xml-20081126]). This issue is likely to be solved in 597 YANG 1.1 because noncharacters will not be allowed in string 598 values, see sec. 9.4 in [I-D.ietf-netmod-rfc6020bis]. 600 o Values of the "binary" type are encoded with the base64 encoding 601 scheme (Section 6.6), whereas I-JSON recommends base64url instead. 602 Theoretically, values of the "binary" type might appear in URI 603 references, such as Request-URI in RESTCONF, although in practice 604 the cases where it is really needed should be extremely rare. 606 8. Security Considerations 608 This document defines an alternative encoding for data modeled in the 609 YANG data modeling language. As such, it doesn't contribute any new 610 security issues beyond those discussed in sec. 15 of [RFC6020]. 612 JSON is rather different from XML, and JSON parsers may thus suffer 613 from other types of vulnerabilities than their XML counterparts. To 614 minimize these security risks, it is important that client and server 615 software supporting JSON encoding behaves as required in sec. 3 of 616 [I-D.ietf-json-i-json]. That is, received JSON data that violate any 617 of I-JSON strict constraints MUST NOT be trusted nor acted upon. 618 Violations due to the presence of Unicode Noncharacters in the data 619 (see Section 7) SHOULD be carefully examined. 621 9. Acknowledgments 623 The author wishes to thank Andy Bierman, Martin Bjorklund, Dean 624 Bogdanovic, Balazs Lengyel, Juergen Schoenwaelder and Phil Shafer for 625 their helpful comments and suggestions. 627 10. References 629 10.1. Normative References 631 [I-D.ietf-json-i-json] 632 Bray, T., "The I-JSON Message Format", draft-ietf-json- 633 i-json-06 (work in progress), January 2015. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, March 1997. 638 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 639 Network Configuration Protocol (NETCONF)", RFC 6020, 640 October 2010. 642 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 643 Bierman, "Network Configuration Protocol (NETCONF)", RFC 644 6241, June 2011. 646 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 647 Interchange Format", RFC 7159, March 2014. 649 [W3C.REC-xml-20081126] 650 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 651 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 652 Edition)", World Wide Web Consortium Recommendation REC- 653 xml-20081126, November 2008, 654 . 656 10.2. Informative References 658 [I-D.ietf-netconf-restconf] 659 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 660 Protocol", draft-ietf-netconf-restconf-04 (work in 661 progress), January 2015. 663 [I-D.ietf-netmod-rfc6020bis] 664 Bjorklund, M., "YANG - A Data Modeling Language for the 665 Network Configuration Protocol (NETCONF)", draft-ietf- 666 netmod-rfc6020bis-03 (work in progress), January 2015. 668 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 669 Management", RFC 7223, May 2014. 671 [W3C.REC-xpath-19991116] 672 Clark, J. and S. DeRose, "XML Path Language (XPath) 673 Version 1.0", World Wide Web Consortium Recommendation 674 REC-xpath-19991116, November 1999, 675 . 677 Appendix A. A Complete Example 679 The JSON document shown below represents the same data as the reply 680 to the NETCONF request appearing in Appendix D of [RFC7223]. 681 The data model is a combination of two YANG modules: "ietf- 682 interfaces" and "ex-vlan" (the latter is an example module from 683 Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf- 684 interfaces" module is considered to be active. 686 { 687 "ietf-interfaces:interfaces": { 688 "interface": [ 689 { 690 "name": "eth0", 691 "type": "iana-if-type:ethernetCsmacd", 692 "enabled": false 693 }, 694 { 695 "name": "eth1", 696 "type": "iana-if-type:ethernetCsmacd", 697 "enabled": true, 698 "ex-vlan:vlan-tagging": true 699 }, 700 { 701 "name": "eth1.10", 702 "type": "iana-if-type:l2vlan", 703 "enabled": true, 704 "ex-vlan:base-interface": "eth1", 705 "ex-vlan:vlan-id": 10 706 }, 707 { 708 "name": "lo1", 709 "type": "iana-if-type:softwareLoopback", 710 "enabled": true 712 } 713 ] 714 }, 715 "ietf-interfaces:interfaces-state": { 716 "interface": [ 717 { 718 "name": "eth0", 719 "type": "iana-if-type:ethernetCsmacd", 720 "admin-status": "down", 721 "oper-status": "down", 722 "if-index": 2, 723 "phys-address": "00:01:02:03:04:05", 724 "statistics": { 725 "discontinuity-time": "2013-04-01T03:00:00+00:00" 726 } 727 }, 728 { 729 "name": "eth1", 730 "type": "iana-if-type:ethernetCsmacd", 731 "admin-status": "up", 732 "oper-status": "up", 733 "if-index": 7, 734 "phys-address": "00:01:02:03:04:06", 735 "higher-layer-if": [ 736 "eth1.10" 737 ], 738 "statistics": { 739 "discontinuity-time": "2013-04-01T03:00:00+00:00" 740 } 741 }, 742 { 743 "name": "eth1.10", 744 "type": "iana-if-type:l2vlan", 745 "admin-status": "up", 746 "oper-status": "up", 747 "if-index": 9, 748 "lower-layer-if": [ 749 "eth1" 750 ], 751 "statistics": { 752 "discontinuity-time": "2013-04-01T03:00:00+00:00" 753 } 754 }, 755 { 756 "name": "eth2", 757 "type": "iana-if-type:ethernetCsmacd", 758 "admin-status": "down", 759 "oper-status": "down", 760 "if-index": 8, 761 "phys-address": "00:01:02:03:04:07", 762 "statistics": { 763 "discontinuity-time": "2013-04-01T03:00:00+00:00" 764 } 765 }, 766 { 767 "name": "lo1", 768 "type": "iana-if-type:softwareLoopback", 769 "admin-status": "up", 770 "oper-status": "up", 771 "if-index": 1, 772 "statistics": { 773 "discontinuity-time": "2013-04-01T03:00:00+00:00" 774 } 775 } 776 ] 777 } 778 } 780 Appendix B. Change Log 782 RFC Editor: Remove this section upon publication as an RFC. 784 B.1. Changes Between Revisions -02 and -03 786 o Namespace encoding is defined without using RFC 2119 keywords. 788 o Specification for anyxml nodes was extended and clarified. 790 o Text about ordering of list entries was corrected. 792 B.2. Changes Between Revisions -01 and -02 794 o Encoding of namespaces in instance-identifiers was changed. 796 o Text specifying the order of array elements in leaf-list and list 797 instances was added. 799 B.3. Changes Between Revisions -00 and -01 801 o Metadata encoding was moved to a separate I-D, draft-lhotka- 802 netmod-yang-metadata. 804 o JSON encoding is now defined directly rather than via XML-JSON 805 mapping. 807 o The rules for namespace encoding has changed. This affect both 808 node instance names and instance-identifiers. 810 o I-JSON-related changes. The most significant is the string 811 encoding of 64-bit numbers. 813 o When validating union type, the partial type info present in JSON 814 encoding is taken into account. 816 o Added section about I-JSON compliance. 818 o Updated the example in appendix. 820 o Wrote Security Considerations. 822 o Removed IANA Considerations as there are none. 824 Author's Address 826 Ladislav Lhotka 827 CZ.NIC 829 Email: lhotka@nic.cz