idnits 2.17.1 draft-ietf-netmod-yang-json-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2014) is 3656 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 410 -- Looks like a reference, but probably isn't: '0' on line 410 -- Looks like a reference, but probably isn't: '6' on line 730 -- Looks like a reference, but probably isn't: '3' on line 730 -- Looks like a reference, but probably isn't: '7' on line 730 -- Looks like a reference, but probably isn't: '8' on line 730 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- No information found for draft-sakimura-json-metadata - is the name correct? == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track April 21, 2014 5 Expires: October 23, 2014 7 JSON Encoding of Data Modeled with YANG 8 draft-ietf-netmod-yang-json-00 10 Abstract 12 This document defines rules for representing configuration and state 13 data defined using YANG as JSON text. It does so by specifying a 14 procedure for translating the subset of YANG-compatible XML documents 15 to JSON text, and vice versa. A JSON encoding of XML attributes is 16 also defined so as to allow for including metadata in JSON documents. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 23, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 54 3. Specification of the Translation Procedure . . . . . . . . . 5 55 3.1. Names and Namespaces . . . . . . . . . . . . . . . . . . 6 56 3.2. Mapping XML Elements to JSON Objects . . . . . . . . . . 8 57 3.2.1. The "leaf" Data Node . . . . . . . . . . . . . . . . 8 58 3.2.2. The "container" Data Node . . . . . . . . . . . . . . 8 59 3.2.3. The "leaf-list" Data Node . . . . . . . . . . . . . . 9 60 3.2.4. The "list" Data Node . . . . . . . . . . . . . . . . 9 61 3.2.5. The "anyxml" Data Node . . . . . . . . . . . . . . . 10 62 3.3. Mapping YANG Datatypes to JSON Values . . . . . . . . . . 11 63 3.3.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . 11 64 3.3.2. The "string" Type . . . . . . . . . . . . . . . . . . 11 65 3.3.3. The "boolean" Type . . . . . . . . . . . . . . . . . 11 66 3.3.4. The "enumeration" Type . . . . . . . . . . . . . . . 11 67 3.3.5. The "bits" Type . . . . . . . . . . . . . . . . . . . 12 68 3.3.6. The "binary" Type . . . . . . . . . . . . . . . . . . 12 69 3.3.7. The "leafref" Type . . . . . . . . . . . . . . . . . 12 70 3.3.8. The "identityref" Type . . . . . . . . . . . . . . . 12 71 3.3.9. The "empty" Type . . . . . . . . . . . . . . . . . . 12 72 3.3.10. The "union" Type . . . . . . . . . . . . . . . . . . 13 73 3.3.11. The "instance-identifier" Type . . . . . . . . . . . 13 74 4. Encoding Metadata in JSON . . . . . . . . . . . . . . . . . . 14 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 8.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 The aim of this document is define rules for representing 87 configuration and state data defined using the YANG data modeling 88 language [RFC6020] as JavaScript Object Notation (JSON) 89 text [RFC7159]. The result can be potentially applied in two 90 different ways: 92 1. JSON may be used instead of the standard XML [XML] encoding in 93 the context of the NETCONF protocol [RFC6241] and/or with 94 existing data models expressed in YANG. An example application 95 is the RESTCONF Protocol [RESTCONF]. 97 2. Other documents that choose JSON to represent structured data can 98 use YANG for defining the data model, i.e., both syntactic and 99 semantic constraints that the data have to satisfy. 101 JSON mapping rules could be specified in a similar way as the XML 102 mapping rules in [RFC6020]. This would however require solving 103 several problems. To begin with, YANG uses XPath [XPath] quite 104 extensively, but XPath is not defined for JSON and such a definition 105 would be far from straightforward. 107 In order to avoid these technical difficulties, this document employs 108 an alternative approach: it defines a relatively simple procedure 109 which allows for translating the subset of XML that can be modeled 110 using YANG to JSON, and vice versa. Consequently, validation of a 111 JSON text against a data model can done by translating the JSON text 112 to XML, which is then validated according to the rules stated in 113 [RFC6020]. 115 The translation procedure is adapted to YANG specifics and 116 requirements, namely: 118 1. The translation is driven by a concrete YANG data model and uses 119 information about data types to achieve better results than 120 generic XML-JSON translation procedures. 122 2. Various document types are supported, namely configuration data, 123 configuration + state data, RPC input and output parameters, and 124 notifications. 126 3. XML namespaces specified in the data model are mapped to 127 namespaces of JSON objects. However, explicit namespace 128 identifiers are rarely needed in JSON text. 130 4. Section 4 defines JSON encoding of XML attributes. Although XML 131 attributes cannot be modeled with YANG, they are often used for 132 attaching metadata to elements, and a standard JSON encoding is 133 therefore needed. 135 5. Translation of XML mixed content, comments and processing 136 instructions is outside the scope of this document. 138 Item 1 above also means that, depending on the data model, the same 139 XML element can be translated to different JSON objects. For 140 example, 142 123 144 is translated to 145 "foo": 123 147 if the "foo" node is defined as a leaf with the "uint8" datatype, or 148 to 150 "foo": ["123"] 152 if the "foo" node is defined as a leaf-list with the "string" 153 datatype, and the element has no siblings of the same name. 155 2. Terminology and Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 The following terms are defined in [RFC6020]: 163 o anyxml 165 o augment 167 o container 169 o data node 171 o data tree 173 o datatype 175 o feature 177 o identity 179 o instance identifier 181 o leaf 183 o leaf-list 185 o list 187 o module 189 o submodule 191 The following terms are defined in [XMLNS]: 193 o local name 195 o prefixed name 197 o qualified name 199 3. Specification of the Translation Procedure 201 The translation procedure defines a 1-1 correspondence between the 202 subset of YANG-compatible XML documents and JSON text. This means 203 that the translation can be applied in both directions and it is 204 always invertible. 206 The translation procedure is applicable only to data hierarchies that 207 are modelled by a YANG data model. An input XML document MAY contain 208 enclosing elements representing NETCONF "Operations" and "Messages" 209 layers. However, these enclosing elements do not appear in the 210 resulting JSON document. 212 Any YANG-compatible XML document can be translated, except documents 213 with mixed content. This is only a minor limitation since mixed 214 content is marginal in YANG - it is allowed only in anyxml data 215 nodes. 217 The following sections specify rules mainly for translating XML 218 documents to JSON text. Rules for the inverse translation are stated 219 only where necessary, otherwise they can be easily inferred. 221 REQUIRED parameters of the translation procedure are: 223 o YANG data model consisting of a set of YANG modules, 225 o type of the input document, 227 o optional features (defined via the "feature" statement) that are 228 considered active. 230 The permissible types of input documents are listed in Table 1 231 together with the corresponding part of the data model that is used 232 for the translation. 234 +------------------------------+---------------------------------+ 235 | Document Type | Data Model Section | 236 +------------------------------+---------------------------------+ 237 | configuration and state data | main data tree | 238 | | | 239 | configuration | main data tree ("config true") | 240 | | | 241 | RPC input parameters | "input" data nodes under "rpc" | 242 | | | 243 | RPC output parameters | "output" data nodes under "rpc" | 244 | | | 245 | notification | "notification" data nodes | 246 +------------------------------+---------------------------------+ 248 Table 1: YANG Document Types 250 When translating XML to JSON, the type of the input document can 251 often be determined form the encapsulating elements belonging to the 252 "Operations" or "Messages" layer as defined by the NETCONF protocol 253 (see Sec. 1.2 in [RFC6241]). 255 A particular application MAY decide to support only a subset of 256 document types from Table 1. 258 XML documents can be translated to JSON text only if they are valid 259 instances of the YANG data model and selected document type, also 260 taking into account the active features, if there are any. 262 The resulting JSON document is always a single object ([RFC7159], 263 Sec. 4) whose members are translated from the original XML document 264 using the rules specified in the following sections. 266 3.1. Names and Namespaces 268 The local part of a JSON name is always identical to the local name 269 of the corresponding XML element. 271 Each JSON name lives in a namespace which is uniquely identified by 272 the name of the YANG module where the corresponding data node is 273 defined. If the data node is defined in a submodule, then the 274 namespace identifier is the name of the main module to which the 275 submodule belongs. The translation procedure MUST correctly map YANG 276 namespace URIs to YANG module names and vice versa. 278 The namespace SHALL be expressed in JSON text by prefixing the local 279 name in the following way: 281 : 283 Figure 1: Encoding a namespace identifier with a local name. 285 The namespace identifier MUST be used for local names that are 286 ambiguous, i.e., whenever the data model permits a sibling data node 287 with the same local name. Otherwise, the namespace identifier is 288 OPTIONAL. 290 For example, consider the following YANG module: 292 module foomod { 293 namespace "http://example.com/foomod"; 294 prefix "fm"; 295 container foo { 296 leaf bar { 297 type boolean; 298 } 299 } 300 } 302 If the data model consists only of this module, then the following is 303 a valid JSON document: 305 { 306 "foo": { 307 "bar": true 308 } 309 } 311 Now, assume the container "foo" is augmented from another module: 313 module barmod { 314 namespace "http://example.com/barmod"; 315 prefix "bm"; 316 import foomod { 317 prefix fm; 318 } 319 augment "/fm:foo" { 320 leaf bar { 321 type uint8; 322 } 323 } 324 } 326 In the data model combining "foomod" and "barmod", we have two 327 sibling data nodes with the same local name, namely "bar". In this 328 case, a valid JSON document has to specify an explicit namespace 329 identifier (module name) for both leaves: 331 { 332 "foo": { 333 "foomod:bar": true, 334 "barmod:bar": 123 335 } 336 } 338 3.2. Mapping XML Elements to JSON Objects 340 An XML element that is modelled as a YANG data node is translated to 341 a name/value pair where the name is formed from the name of the XML 342 element using the rules in Section 3.1. The value depends on the 343 type of the data node as specified in the following sections. 345 3.2.1. The "leaf" Data Node 347 An XML element that is modeled as YANG leaf is translated to a name/ 348 value pair and the type of the value is derived from the YANG 349 datatype of the leaf (see Section 3.3 for the datatype mapping 350 rules). 352 Example: For the leaf node definition 354 leaf foo { 355 type uint8; 356 } 358 the XML element 360 123 362 corresponds to the JSON name/value pair 364 "foo": 123 366 3.2.2. The "container" Data Node 368 An XML element that is modeled as YANG container is translated to a 369 name/object pair. 371 Example: For the container definition 372 container bar { 373 leaf foo { 374 type uint8; 375 } 376 } 378 the XML element 380 381 123 382 384 corresponds to the JSON name/value pair 386 "bar": { 387 "foo": 123 388 } 390 3.2.3. The "leaf-list" Data Node 392 A sequence of one or more sibling XML elements with the same 393 qualified name that is modeled as YANG leaf-list is translated to a 394 name/array pair, and the array elements are primitive values whose 395 type depends on the datatype of the leaf-list (see Section 3.3). 397 Example: For the leaf-list definition 399 leaf-list foo { 400 type uint8; 401 } 403 the XML elements 405 123 406 0 439 123 440 zig 441 442 443 0 444 zag 445 447 correspond to the JSON name/value pair 449 "bar": [ 450 { 451 "foo": 123, 452 "baz": "zig" 453 }, 454 { 455 "foo": 0, 456 "baz": "zag" 457 } 458 ] 460 3.2.5. The "anyxml" Data Node 462 An XML element that is modeled as a YANG anyxml data node is 463 translated to a name/object pair. The content of such an element is 464 not modelled by YANG, and there may not be a straightforward mapping 465 to JSON text (e.g., if it is a mixed XML content). Therefore, 466 translation of anyxml contents is necessarily application-specific 467 and outside the scope of this document. 469 Example: For the anyxml definition 471 anyxml bar; 473 the XML element 475 476

477 This is very cool. 478

479 481 may be translated to the following JSON name/value pair: 483 { 484 "bar": { 485 "p": "This is *very* cool." 486 } 487 } 489 3.3. Mapping YANG Datatypes to JSON Values 491 3.3.1. Numeric Datatypes 493 A value of one of the YANG numeric datatypes ("int8", "int16", 494 "int32", "int64", "uint8", "uint16", "uint32", "uint64" and 495 "decimal64") is mapped to a JSON number using the same lexical 496 representation. 498 3.3.2. The "string" Type 500 A "string" value is mapped to an identical JSON string, subject to 501 JSON encoding rules. 503 3.3.3. The "boolean" Type 505 A "boolean" value is mapped to the corresponding JSON value 'true' or 506 'false'. 508 3.3.4. The "enumeration" Type 510 An "enumeration" value is mapped in the same way as a string except 511 that the permitted values are defined by "enum" statements in YANG. 513 3.3.5. The "bits" Type 515 A "bits" value is mapped to a string identical to the lexical 516 representation of this value in XML, i.e., space-separated names 517 representing the individual bit values that are set. 519 3.3.6. The "binary" Type 521 A "binary" value is mapped to a JSON string identical to the lexical 522 representation of this value in XML, i.e., base64-encoded binary 523 data. 525 3.3.7. The "leafref" Type 527 A "leafref" value is mapped according to the same rules as the type 528 of the leaf being referred to. 530 3.3.8. The "identityref" Type 532 An "identityref" value is mapped to a string representing the 533 qualified name of the identity. Its namespace MAY be expressed as 534 shown in Figure 1. If the namespace part is not present, the 535 namespace of the name of the JSON object containing the value is 536 assumed. 538 3.3.9. The "empty" Type 540 An "empty" value is mapped to '[null]', i.e., an array with the 541 'null' value being its only element. 543 This encoding was chosen instead of using simply 'null' in order to 544 facilitate the use of empty leafs in common programming languages. 545 When used in a boolean context, the '[null]' value, unlike 'null', 546 evaluates to 'true'. 548 Example: For the leaf definition 550 leaf foo { 551 type empty; 552 } 554 the XML element 556 558 corresponds to the JSON name/value pair 560 "foo": [null] 562 3.3.10. The "union" Type 564 YANG "union" type represents a choice among multiple alternative 565 types. The actual type of the XML value MUST be determined using the 566 procedure specified in Sec. 9.12 of [RFC6020] and the mapping rules 567 for that type are used. 569 For example, consider the following YANG definition: 571 leaf-list bar { 572 type union { 573 type uint16; 574 type string; 575 } 576 } 578 The sequence of three XML elements 580 6378 581 14.5 582 infinity 584 will then be translated to this name/array pair: 586 "bar": [6378, "14.5", "infinity"] 588 3.3.11. The "instance-identifier" Type 590 An "instance-identifier" value is a string representing a simplified 591 XPath specification. It is mapped to an analogical JSON string in 592 which all occurrences of XML namespace prefixes are either removed or 593 replaced with the corresponding module name according to the rules of 594 Section 3.1. 596 When translating such a value from JSON to XML, all components of the 597 instance-identifier MUST be given appropriate XML namespace prefixes. 598 It is RECOMMENDED that these prefixes be those defined via the 599 "prefix" statement in the corresponding YANG modules. 601 For example, assume "ex" is the prefix defined for the "example" 602 module. Then the XML-encoded instance identifier 604 /ex:system/ex:user[ex:name='fred'] 606 corresponds to the following JSON-encoded instance identifier: 608 /example:system/example:user[example:name='fred'] 610 or simply 612 /system/user[name='fred'] 614 if the local names of the data nodes "system", "user" and "name" are 615 unambiguous. 617 4. Encoding Metadata in JSON 619 By design, YANG does not allow for modeling XML attributes. However, 620 attributes are often used in XML instance documents for attaching 621 various types of metadata information to elements. It is therefore 622 desirable to have a standard way for representing attributes in JSON 623 documents as well. 625 The metadata encoding defined in the rest of this section satisfies 626 the following two important requirements: 628 1. There has to be a way for adding metadata to instances of all 629 types of YANG data nodes, i.e., leafs, containers, list and leaf- 630 list entries, and anyxml nodes. 632 2. The encoding of YANG data node instances as defined in the 633 previous sections must not change. 635 Existing proposals for metadata encoding in JSON, such as 636 [JSON-META], are oriented on rather specific uses of metadata, and 637 fall short with respect to the first requirement. 639 All attributes assigned to an XML element are mapped in JSON to 640 members (name/value pairs) of a single object, henceforth denoted as 641 the metadata object. The placement of this object depends on the 642 type of the element from YANG viewpoint, as specified in the 643 following paragraphs. 645 For an XML element that is translated to a JSON object (i.e., a 646 container, anyxml node and list entry), the metadata object is added 647 as a new member of that object with the name "@". 649 Examples: 651 o If "cask" is a container or anyxml node, the XML instance with 652 attributes 654 655 ... 656 658 is mapped to the following JSON object: 660 "cask": { 661 "@": { 662 "foo": "a", 663 "bar": "b" 664 } 665 ... 666 } 668 o If "seq" is a list, then the pair of XML elements 670 671 one 672 673 674 two 675 677 is mapped to the following JSON array: 679 "seq": [ 680 { 681 "@": { 682 "foo": "a" 683 }, 684 "name": "one" 685 }, 686 { 687 "@": { 688 "bar": "b" 689 }, 690 "name": "two" 691 } 692 ] 694 In order to assign attributes to a leaf instance, a sibling name/ 695 value pair is added, where the name is the symbol "@" concatenated 696 with the identifier of the leaf. 698 For example, the element 700 true 702 is mapped to the following two name/value pairs: 704 "flag": true, 705 "@flag": { 706 "foo": "a", 707 "bar": "b" 708 } 710 Finally, for a leaf-list instance, which is represented as a JSON 711 array with primitive values, attributes may be assigned to one or 712 more entries by adding a sibling name/value pair, where the name is 713 the symbol "@" concatenated with the identifier of the leaf-list, and 714 the value is a JSON array whose i-th element is the metadata object 715 with attributes assigned to the i-th entry of the leaf-list, or nil 716 if the i-th entry has no attributes. 718 Trailing nil values in the array, i.e., those following the last non- 719 nil metadata object, MAY be omitted. 721 For example, a leaf-list instance with four entries 723 6 724 3 725 7 726 8 728 is mapped to the following two name/value pairs: 730 "folio": [6, 3, 7, 8], 731 "@folio": [nil, {"foo": "a"}, {"bar": "b"}] 733 The encoding of attributes as specified above has the following two 734 limitations: 736 o Mapping of namespaces of XML attributes is undefined. 738 o Attribute values can only be strings, other data types are not 739 supported. 741 5. IANA Considerations 743 TBD - register application/yang.data+json media type? 745 6. Security Considerations 747 TBD. 749 7. Acknowledgments 751 The author wishes to thank Andy Bierman, Martin Bjorklund and Phil 752 Shafer for their helpful comments and suggestions. 754 8. References 756 8.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 762 Network Configuration Protocol (NETCONF)", RFC 6020, 763 September 2010. 765 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 766 Bierman, "NETCONF Configuration Protocol", RFC 6241, June 767 2011. 769 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 770 Interchange Format", RFC 7159, March 2014. 772 [XMLNS] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 773 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 774 Wide Web Consortium Recommendation REC-xml-names-20091208, 775 December 2009, 776 . 778 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 779 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 780 Edition)", World Wide Web Consortium Recommendation REC- 781 xml-20081126, November 2008, 782 . 784 8.2. Informative References 786 [IF-CFG] Bjorklund, M., "A YANG Data Model for Interface 787 Management", draft-ietf-netmod-interfaces-cfg-16 (work in 788 progress), January 2014. 790 [JSON-META] 791 Sakimura, N., "JSON Metadata", draft-sakimura-json- 792 metadata-01 (work in progress), November 2013. 794 [RESTCONF] 795 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 796 "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work 797 in progress), March 2014. 799 [XPath] Clark, J., "XML Path Language (XPath) Version 1.0", World 800 Wide Web Consortium Recommendation REC-xpath-19991116, 801 November 1999, 802 . 804 Appendix A. A Complete Example 806 The JSON document shown below was translated from a reply to the 807 NETCONF request that can be found in Appendix D of [IF-CFG]. 808 The data model is a combination of two YANG modules: "ietf- 809 interfaces" and "ex-vlan" (the latter is an example module from 810 Appendix C of [IF-CFG]). The "if-mib" feature defined in the "ietf- 811 interfaces" module is considered to be active. 813 { 814 "interfaces": { 815 "interface": [ 816 { 817 "name": "eth0", 818 "type": "iana-if-type:ethernetCsmacd", 819 "enabled": false 820 }, 821 { 822 "name": "eth1", 823 "type": "iana-if-type:ethernetCsmacd", 824 "enabled": true, 825 "vlan-tagging": true 826 }, 827 { 828 "name": "eth1.10", 829 "type": "iana-if-type:l2vlan", 830 "enabled": true, 831 "base-interface": "eth1", 832 "vlan-id": 10 833 }, 834 { 835 "name": "lo1", 836 "type": "iana-if-type:softwareLoopback", 837 "enabled": true 838 } 839 ] 840 }, 841 "interfaces-state": { 842 "interface": [ 843 { 844 "name": "eth0", 845 "type": "iana-if-type:ethernetCsmacd", 846 "admin-status": "down", 847 "oper-status": "down", 848 "if-index": 2, 849 "phys-address": "00:01:02:03:04:05", 850 "statistics": { 851 "discontinuity-time": "2013-04-01T03:00:00+00:00" 852 } 853 }, 854 { 855 "name": "eth1", 856 "type": "iana-if-type:ethernetCsmacd", 857 "admin-status": "up", 858 "oper-status": "up", 859 "if-index": 7, 860 "phys-address": "00:01:02:03:04:06", 861 "higher-layer-if": [ 862 "eth1.10" 863 ], 864 "statistics": { 865 "discontinuity-time": "2013-04-01T03:00:00+00:00" 866 } 867 }, 868 { 869 "name": "eth1.10", 870 "type": "iana-if-type:l2vlan", 871 "admin-status": "up", 872 "oper-status": "up", 873 "if-index": 9, 874 "lower-layer-if": [ 875 "eth1" 876 ], 877 "statistics": { 878 "discontinuity-time": "2013-04-01T03:00:00+00:00" 879 } 880 }, 881 { 882 "name": "eth2", 883 "type": "iana-if-type:ethernetCsmacd", 884 "admin-status": "down", 885 "oper-status": "down", 886 "if-index": 8, 887 "phys-address": "00:01:02:03:04:07", 888 "statistics": { 889 "discontinuity-time": "2013-04-01T03:00:00+00:00" 891 } 892 }, 893 { 894 "name": "lo1", 895 "type": "iana-if-type:softwareLoopback", 896 "admin-status": "up", 897 "oper-status": "up", 898 "if-index": 1, 899 "statistics": { 900 "discontinuity-time": "2013-04-01T03:00:00+00:00" 901 } 902 } 903 ] 904 } 905 } 907 Author's Address 909 Ladislav Lhotka 910 CZ.NIC 912 Email: lhotka@nic.cz