idnits 2.17.1 draft-ietf-netmod-yang-json-04.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 (June 12, 2015) is 3240 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 332 -- Looks like a reference, but probably isn't: '0' on line 332 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-05 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-05 -- 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 June 12, 2015 5 Expires: December 14, 2015 7 JSON Encoding of Data Modeled with YANG 8 draft-ietf-netmod-yang-json-04 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 December 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Names and Namespaces . . . . . . . . . . . . . . . . . . . . 4 55 5. Encoding of YANG Data Node Instances . . . . . . . . . . . . 6 56 5.1. The "leaf" Data Node . . . . . . . . . . . . . . . . . . 7 57 5.2. The "container" Data Node . . . . . . . . . . . . . . . . 7 58 5.3. The "leaf-list" Data Node . . . . . . . . . . . . . . . . 7 59 5.4. The "list" Data Node . . . . . . . . . . . . . . . . . . 8 60 5.5. The "anydata" Data Node . . . . . . . . . . . . . . . . . 9 61 5.6. The "anyxml" Data Node . . . . . . . . . . . . . . . . . 10 62 6. The Mapping of YANG Data Types to JSON Values . . . . . . . . 10 63 6.1. Numeric Types . . . . . . . . . . . . . . . . . . . . . . 10 64 6.2. The "string" Type . . . . . . . . . . . . . . . . . . . . 11 65 6.3. The "boolean" Type . . . . . . . . . . . . . . . . . . . 11 66 6.4. The "enumeration" Type . . . . . . . . . . . . . . . . . 11 67 6.5. The "bits" Type . . . . . . . . . . . . . . . . . . . . . 11 68 6.6. The "binary" Type . . . . . . . . . . . . . . . . . . . . 11 69 6.7. The "leafref" Type . . . . . . . . . . . . . . . . . . . 11 70 6.8. The "identityref" Type . . . . . . . . . . . . . . . . . 11 71 6.9. The "empty" Type . . . . . . . . . . . . . . . . . . . . 12 72 6.10. The "union" Type . . . . . . . . . . . . . . . . . . . . 13 73 6.11. The "instance-identifier" Type . . . . . . . . . . . . . 13 74 7. I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . . 14 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 16 81 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 82 B.1. Changes Between Revisions -03 and -04 . . . . . . . . . . 18 83 B.2. Changes Between Revisions -02 and -03 . . . . . . . . . . 19 84 B.3. Changes Between Revisions -01 and -02 . . . . . . . . . . 19 85 B.4. Changes Between Revisions -00 and -01 . . . . . . . . . . 19 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for 91 encoding data in its Content Layer. Other management protocols might 92 want to use other encodings while still benefiting from using YANG 93 [I-D.ietf-netmod-rfc6020bis] as the data modeling language. 95 For example, the RESTCONF protocol [I-D.ietf-netconf-restconf] 96 supports two encodings: XML (media type "application/yang.data+xml") 97 and JSON (media type "application/yang.data+json). 99 The specification of YANG 1.1 data modelling language 100 [I-D.ietf-netmod-rfc6020bis] defines only XML encoding for data 101 instances, i.e., contents of configuration datastores, state data, 102 RFC input and output parameters, and event notifications. The aim of 103 this document is to define rules for encoding the same data as 104 JavaScript Object Notation (JSON) text [RFC7159]. 106 In order to achieve maximum interoperability while allowing 107 implementations to use a variety of available JSON parsers, the JSON 108 encoding rules follow, as much as possible, the constraints of the 109 I-JSON restricted profile [RFC7493]. Section 7 discusses I-JSON 110 conformance in more detail. 112 2. Terminology and Notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: 120 o anydata, 122 o anyxml, 124 o augment, 126 o container, 128 o data node, 130 o identity, 132 o instance identifier, 134 o leaf, 136 o leaf-list, 138 o list, 140 o module, 142 o submodule. 144 3. Validation of JSON-encoded Instance Data 146 Instance data validation as defined in [I-D.ietf-netmod-rfc6020bis], 147 sec. 8.3.3, is only applicable to XML-encoded data. For one, 148 semantic constraints in "must" statements are expressed using 149 XPath 1.0 [W3C.REC-xpath-19991116], which can be properly interpreted 150 only in the XML context. 152 This document and the corresponding "XML Mapping Rules" sections from 153 [I-D.ietf-netmod-rfc6020bis] also define an implicit schema-driven 154 mapping of JSON-encoded instances to XML-encoded instances (and vice 155 versa). This mapping is mostly straightforward. In cases where 156 doubts could arise, this document gives explicit instructions for 157 mapping JSON-encoded instances to XML. 159 In order to validate a JSON instance document, it needs first to be 160 mapped, at least conceptually, to the corresponding XML instance 161 document. By definition, the JSON document is then valid if and only 162 if the XML document is valid according to the rules stated in 163 [I-D.ietf-netmod-rfc6020bis]. 165 4. Names and Namespaces 167 Instances of YANG data nodes (leafs, containers, leaf-lists, lists, 168 anydata and anyxml nodes) are always encoded as members of a JSON 169 object, i.e., as name/value pairs. This section defines how the name 170 part is formed, and the following sections deal with the value part. 172 Except in the cases specified below, the member name is identical to 173 the identifier of the corresponding YANG data node. Every such name 174 belongs to a namespace which is associated with the YANG module where 175 the corresponding data node is defined. If the data node is defined 176 in a submodule, then the namespace is determined by the main module 177 to which the submodule belongs. 179 If the namespace of a member name has to be explicitly specified, the 180 module name SHALL be used as a prefix to the member's local name. 181 Both parts of the member name SHALL be separated with a colon 182 character (":"). Using ABNF [RFC5234], the namespace-qualified name 183 can be expressed as shown in Figure 1, where the production for 184 "identifier" is defined in sec. 13 of [I-D.ietf-netmod-rfc6020bis]. 186 qualified-member-name = identifier ":" identifier 188 Figure 1: ABNF production for a qualified member name. 190 Names with namespace identifiers in the form shown in Figure 1 are 191 used if and only if the parent data node belongs to a different 192 namespace, which also includes all top-level YANG data nodes that 193 have no parent node. 195 For example, consider the following YANG module: 197 module foomod { 199 namespace "http://example.com/foomod"; 201 prefix "foo"; 203 container top { 204 leaf foo { 205 type uint8; 206 } 207 } 208 } 210 If the data model consists only of this module, then the following is 211 a valid JSON-encoded configuration: 213 { 214 "foomod:top": { 215 "foo": 54 216 } 217 } 219 Note that the top-level container instance contains the namespace 220 identifier (module name) but the "foo" leaf doesn't because it is 221 defined in the same module as its parent container. 223 Now, assume the container "top" is augmented from another module, 224 "barmod": 226 module barmod { 228 namespace "http://example.com/barmod"; 230 prefix "bar"; 232 import foomod { 233 prefix "foo"; 234 } 236 augment "/foo:top" { 237 leaf bar { 238 type boolean; 239 } 240 } 241 } 243 A valid JSON-encoded configuration containing both leafs may then 244 look like this: 246 { 247 "foomod:top": { 248 "foo": 54, 249 "barmod:bar": true 250 } 251 } 253 The name of the "bar" leaf is prefixed with the namespace identifier 254 because its parent is defined in a different module, hence it belongs 255 to another namespace. 257 Explicit namespace identifiers are sometimes needed when encoding 258 values of the "identityref" and "instances-identifier" types. The 259 same form as shown in Figure 1 is then used as well. See Sections 260 6.8 and 6.11 for details. 262 5. Encoding of YANG Data Node Instances 264 Every complete JSON instance document, such as a configuration 265 datastore content, is an object. Its members are instances of all 266 top-level data nodes defined by the YANG data model. 268 Character encoding MUST be UTF-8. 270 Any data node instance is encoded as a name/value pair where the name 271 is formed from the data node identifier using the rules of Section 4. 272 The value depends on the category of the data node as explained in 273 the following subsections. 275 5.1. The "leaf" Data Node 277 A leaf instance is encoded as a name/value pair where the value can 278 be a string, number, literal "true" or "false", or the special array 279 "[null]", depending on the type of the leaf (see Section 6 for the 280 type encoding rules). 282 Example: For the leaf node definition 284 leaf foo { 285 type uint8; 286 } 288 the following is a valid JSON-encoded instance: 290 "foo": 123 292 5.2. The "container" Data Node 294 A container instance is encoded as a name/object pair. The 295 container's child data nodes are encoded as members of the object. 297 Example: For the container definition 299 container bar { 300 leaf foo { 301 type uint8; 302 } 303 } 305 the following is a valid JSON-encoded instance: 307 "bar": { 308 "foo": 123 309 } 311 5.3. The "leaf-list" Data Node 313 A leaf-list is encoded as a name/array pair, and the array elements 314 are values of some scalar type, which can be a string, number, 315 literal "true" or "false", or the special array "[null]", depending 316 on the type of the leaf-list (see Section 6 for the type encoding 317 rules). 319 The ordering of array elements follows the same rules as the ordering 320 of XML elements representing leaf-list entries in the XML encoding. 321 Specifically, the "ordered-by" properties (sec. 7.7.7 in 322 [I-D.ietf-netmod-rfc6020bis]) MUST be observed. 324 Example: For the leaf-list definition 326 leaf-list foo { 327 type uint8; 328 } 330 the following is a valid JSON-encoded instance: 332 "foo": [123, 0] 334 5.4. The "list" Data Node 336 A list instance is encoded as a name/array pair, and the array 337 elements are JSON objects. 339 The ordering of array elements follows the same rules as the ordering 340 of XML elements representing list entries in the XML encoding. 341 Specifically, the "ordered-by" properties (sec. 7.7.7 in 342 [I-D.ietf-netmod-rfc6020bis]) MUST be observed. 344 Unlike the XML encoding, where list keys are required to precede any 345 other siblings within a list entry, and appear in the order specified 346 by the data model, the order of members in a JSON-encoded list entry 347 is arbitrary because JSON objects are fundamentally unordered 348 collections of members. 350 Example: For the list definition 352 list bar { 353 key foo; 354 leaf foo { 355 type uint8; 356 } 357 leaf baz { 358 type string; 359 } 360 } 362 the following is a valid JSON-encoded instance: 364 "bar": [ 365 { 366 "foo": 123, 367 "baz": "zig" 368 }, 369 { 370 "baz": "zag", 371 "foo": 0 372 } 373 ] 375 5.5. The "anydata" Data Node 377 Anydata data node is a new feature in YANG 1.1. It serves as a 378 container for data that appear as normal YANG-modeled data, except 379 their data model is not a priori known. 381 An anydata instance is thus encoded in the same way as a container, 382 and its content is subject to the following rules: 384 o It is a valid I-JSON message [RFC7493]. 386 o Any member name is either a YANG identifier as defined by the 387 "identifier" production in sec. 13 of 388 [I-D.ietf-netmod-rfc6020bis], or two such identifiers separated by 389 the colon character (":"). See also Section 4. 391 o Any JSON array contains either only unique scalar values (as a 392 leaf-list, see Section 5.3), or only objects (as a list, see 393 Section 5.4). 395 o The "null" value is only allowed in the single-element array 396 "[null]" corresponding to the encoding of the "empty" type, see 397 Section 6.9. 399 If a data model for anydata content is not available, it may be 400 impossible to map a JSON-encoded anydata instance to XML, and vice 401 versa. Note, however, that such a mapping is not needed for 402 validation purposes (Section 3) because anydata contents are 403 generally not subject to YANG-based validation (see sec. 7.10 in 404 [I-D.ietf-netmod-rfc6020bis]). 406 Example: for the anydata definition 408 anydata data; 410 the following is a valid JSON-encoded instance: 412 "data": { 413 "ietf-notification:notification": { 414 "eventTime": "2014-07-29T13:43:01Z", 415 "example-event:event": { 416 "event-class: "fault", 417 "reporting-entity": { 418 "card": "Ethernet0" 419 }, 420 "severity": "major" 421 } 422 } 423 } 425 5.6. The "anyxml" Data Node 427 An anyxml instance is encoded as a JSON name/value pair which MUST 428 satisfy I-JSON constraints. Otherwise it is unrestricted, i.e., the 429 value can be an object, array, number, string or one of the literals 430 "true", "false" and "null". 432 As in the case of anydata (Section 5.5), there is no universal 433 procedure for mapping JSON-encoded anyxml instances to XML, and vice 434 versa. 436 Example: For the anyxml definition 438 anyxml bar; 440 the following is a valid JSON-encoded instance: 442 "bar": [true, null, true] 444 6. The Mapping of YANG Data Types to JSON Values 446 The type of the JSON value in an instance of the leaf or leaf-list 447 data node depends on the type of that data node as specified in the 448 following subsections. 450 6.1. Numeric Types 452 A value of the "int8", "int16", "int32", "uint8", "uint16" and 453 "uint32" is represented as a JSON number. 455 A value of the "int64", "uint64" or "decimal64" type is encoded as a 456 JSON string whose contents is the lexical representation of that 457 numeric value as specified in sections 9.2.1 and 9.3.1 of 458 [I-D.ietf-netmod-rfc6020bis]. 460 For example, if the type of the leaf "foo" in Section 5.1 was 461 "uint64" instead of "uint8", the instance would have to be encoded as 463 "foo": "123" 465 The special handling of 64-bit numbers follows from I-JSON 466 recommendation to encode numbers exceeding the IEEE 754-2008 double 467 precision range as strings, see sec. 2.2 in [RFC7493]. 469 6.2. The "string" Type 471 A "string" value encoded as a JSON string, subject to JSON string 472 encoding rules. 474 6.3. The "boolean" Type 476 A "boolean" value is mapped to the corresponding JSON literal name 477 "true" or "false". 479 6.4. The "enumeration" Type 481 An "enumeration" value is mapped in the same way as a string except 482 that the permitted values are defined by "enum" statements in YANG. 483 See sec. 9.6 in [I-D.ietf-netmod-rfc6020bis]. 485 6.5. The "bits" Type 487 A "bits" value is mapped to a JSON string identical to the lexical 488 representation of this value in XML, i.e., space-separated names 489 representing the individual bit values that are set. See sec. 9.7 in 490 [I-D.ietf-netmod-rfc6020bis]. 492 6.6. The "binary" Type 494 A "binary" value is mapped to a JSON string identical to the lexical 495 representation of this value in XML, i.e., base64-encoded binary 496 data. See sec. 9.8 in [I-D.ietf-netmod-rfc6020bis]. 498 6.7. The "leafref" Type 500 A "leafref" value is mapped according to the same rules as the type 501 of the leaf being referred to. 503 6.8. The "identityref" Type 505 An "identityref" value is mapped to a string representing the name of 506 an identity. Its namespace MUST be expressed as shown in Figure 1 if 507 it is different from the namespace of the leaf node containing the 508 identityref value, and MAY be expressed otherwise. 510 For example, consider the following schematic module: 512 module exmod { 513 ... 514 import ietf-interfaces { 515 prefix if; 516 } 517 import iana-if-type { 518 prefix ianaift; 519 } 520 ... 521 leaf type { 522 type identityref { 523 base "if:interface-type"; 524 } 525 } 526 } 528 A valid instance of the "type" leaf is then encoded as follows: 530 "type": "iana-if-type:ethernetCsmacd" 532 The namespace identifier "iana-if-type" must be present in this case 533 because the "ethernetCsmacd" identity is not defined in the same 534 module as the "type" leaf. 536 6.9. The "empty" Type 538 An "empty" value is mapped to "[null]", i.e., an array with the 539 "null" literal being its only element. For the purposes of this 540 document, "[null]" is treated as an atomic scalar value. 542 This encoding of the "empty" type was chosen instead of using simply 543 "null" in order to facilitate the use of empty leafs in common 544 programming languages. When used in a boolean context, the "[null]" 545 value, unlike "null", evaluates to true. 547 Example: For the leaf definition 549 leaf foo { 550 type empty; 551 } 553 a valid instance is 554 "foo": [null] 556 6.10. The "union" Type 558 A value of the "union" type is encoded as the value of any of the 559 member types. 561 Unlike XML, JSON conveys part of the type information already in the 562 encoding. When validating a value of the "union" type, this 563 information MUST also be taken into account. 565 For example, consider the following YANG definition: 567 leaf bar { 568 type union { 569 type uint16; 570 type string; 571 } 572 } 574 In RESTCONF [I-D.ietf-netconf-restconf], it is fully acceptable to 575 set the value of "bar" in the following way when using the 576 "application/yang.data+xml" media type: 578 13.5 580 because the value may be interpreted as a string, i.e., the second 581 member type of the union. When using the "application/ 582 yang.data+json" media type, however, this is an error: 584 "bar": 13.5 586 In this case, the JSON encoding indicates the value is supposed to be 587 a number rather than a string. 589 6.11. The "instance-identifier" Type 591 An "instance-identifier" value is encoded as a string that is 592 analogical to the lexical representation in XML encoding, see 593 sec. 9.13.3 in [I-D.ietf-netmod-rfc6020bis]. However, the encoding 594 of namespaces in instance-identifier values follows the rules stated 595 in Section 4, namely: 597 o The namespace identifier is the module name where each data node 598 is defined. 600 o The encoding of a node name with an explicit namespace is as shown 601 in Figure 1. 603 o The leftmost (top-level) node name is always prefixed with the 604 namespace identifier. 606 o Any subsequent node name has the namespace identifier if and only 607 if its parent node has a different namespace. This also holds for 608 node names appearing in predicates. 610 For example, 612 /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip 614 is a valid instance-identifer value because the data nodes 615 "interfaces", "interface" and "name" are defined in the module "ietf- 616 interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". 618 When translating an instance-identifier value from JSON to XML, the 619 namespace identifier (YANG module name) in each component of the 620 instance-identifier MUST be replaced by an XML namespace prefix that 621 is associated with the namespace URI reference of the module in the 622 scope of the element containing the instance-identifier value. 624 7. I-JSON Compliance 626 I-JSON [RFC7493] is a restricted profile of JSON that guarantees 627 maximum interoperability for protocols that use JSON in their 628 messages, no matter what JSON encoders/decoders are used in protocol 629 implementations. The encoding defined in this document therefore 630 observes the I-JSON requirements and recommendations as closely as 631 possible. 633 In particular, the following properties are guaranteed: 635 o Character encoding is UTF-8. 637 o Member names within the same JSON object are always unique. 639 o The order of JSON object members is never relied upon. 641 o Numbers of any type supported by YANG can be exchanged reliably. 642 See Section 6.1 for details. 644 This document deviates from I-JSON only in the encoding of values 645 with the "binary" type. It uses the base64 encoding scheme 646 (Section 6.6), whereas I-JSON recommends base64url instead. 647 Theoretically, values of the "binary" type might appear in URI 648 references, such as Request-URI in RESTCONF, although in practice the 649 cases where it is really needed should be extremely rare. 651 8. Security Considerations 653 This document defines an alternative encoding for data modeled in the 654 YANG data modeling language. As such, it doesn't contribute any new 655 security issues beyond those discussed in sec. 16 of 656 [I-D.ietf-netmod-rfc6020bis]. 658 JSON processing is rather different from XML, and JSON parsers may 659 thus suffer from other types of vulnerabilities than their XML 660 counterparts. To minimize these new security risks, software on the 661 receiving side SHOULD reject all messages that do not comply to the 662 rules of this document and reply with an appropriate error message to 663 the sender. 665 9. Acknowledgments 667 The author wishes to thank Andy Bierman, Martin Bjorklund, Dean 668 Bogdanovic, Balazs Lengyel, Juergen Schoenwaelder and Phil Shafer for 669 their helpful comments and suggestions. 671 10. References 673 10.1. Normative References 675 [I-D.ietf-netmod-rfc6020bis] 676 Bjorklund, M., "YANG - A Data Modeling Language for the 677 Network Configuration Protocol (NETCONF)", draft-ietf- 678 netmod-rfc6020bis-05 (work in progress), May 2015. 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 684 Specifications: ABNF", STD 68, RFC 5234, January 2008. 686 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 687 Bierman, "Network Configuration Protocol (NETCONF)", RFC 688 6241, June 2011. 690 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 691 Interchange Format", RFC 7159, March 2014. 693 [RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, March 694 2015. 696 [W3C.REC-xml-20081126] 697 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 698 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 699 Edition)", World Wide Web Consortium Recommendation REC- 700 xml-20081126, November 2008, 701 . 703 10.2. Informative References 705 [I-D.ietf-netconf-restconf] 706 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 707 Protocol", draft-ietf-netconf-restconf-05 (work in 708 progress), June 2015. 710 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 711 Management", RFC 7223, May 2014. 713 [W3C.REC-xpath-19991116] 714 Clark, J. and S. DeRose, "XML Path Language (XPath) 715 Version 1.0", World Wide Web Consortium Recommendation 716 REC-xpath-19991116, November 1999, 717 . 719 Appendix A. A Complete Example 721 The JSON document shown below represents the same data as the reply 722 to the NETCONF request appearing in Appendix D of [RFC7223]. 723 The data model is a combination of two YANG modules: "ietf- 724 interfaces" and "ex-vlan" (the latter is an example module from 725 Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf- 726 interfaces" module is considered to be active. 728 { 729 "ietf-interfaces:interfaces": { 730 "interface": [ 731 { 732 "name": "eth0", 733 "type": "iana-if-type:ethernetCsmacd", 734 "enabled": false 735 }, 736 { 737 "name": "eth1", 738 "type": "iana-if-type:ethernetCsmacd", 739 "enabled": true, 740 "ex-vlan:vlan-tagging": true 741 }, 742 { 743 "name": "eth1.10", 744 "type": "iana-if-type:l2vlan", 745 "enabled": true, 746 "ex-vlan:base-interface": "eth1", 747 "ex-vlan:vlan-id": 10 748 }, 749 { 750 "name": "lo1", 751 "type": "iana-if-type:softwareLoopback", 752 "enabled": true 753 } 754 ] 755 }, 756 "ietf-interfaces:interfaces-state": { 757 "interface": [ 758 { 759 "name": "eth0", 760 "type": "iana-if-type:ethernetCsmacd", 761 "admin-status": "down", 762 "oper-status": "down", 763 "if-index": 2, 764 "phys-address": "00:01:02:03:04:05", 765 "statistics": { 766 "discontinuity-time": "2013-04-01T03:00:00+00:00" 767 } 768 }, 769 { 770 "name": "eth1", 771 "type": "iana-if-type:ethernetCsmacd", 772 "admin-status": "up", 773 "oper-status": "up", 774 "if-index": 7, 775 "phys-address": "00:01:02:03:04:06", 776 "higher-layer-if": [ 777 "eth1.10" 778 ], 779 "statistics": { 780 "discontinuity-time": "2013-04-01T03:00:00+00:00" 781 } 782 }, 783 { 784 "name": "eth1.10", 785 "type": "iana-if-type:l2vlan", 786 "admin-status": "up", 787 "oper-status": "up", 788 "if-index": 9, 789 "lower-layer-if": [ 790 "eth1" 791 ], 792 "statistics": { 793 "discontinuity-time": "2013-04-01T03:00:00+00:00" 794 } 795 }, 796 { 797 "name": "eth2", 798 "type": "iana-if-type:ethernetCsmacd", 799 "admin-status": "down", 800 "oper-status": "down", 801 "if-index": 8, 802 "phys-address": "00:01:02:03:04:07", 803 "statistics": { 804 "discontinuity-time": "2013-04-01T03:00:00+00:00" 805 } 806 }, 807 { 808 "name": "lo1", 809 "type": "iana-if-type:softwareLoopback", 810 "admin-status": "up", 811 "oper-status": "up", 812 "if-index": 1, 813 "statistics": { 814 "discontinuity-time": "2013-04-01T03:00:00+00:00" 815 } 816 } 817 ] 818 } 819 } 821 Appendix B. Change Log 823 RFC Editor: Remove this section upon publication as an RFC. 825 B.1. Changes Between Revisions -03 and -04 827 o I-D.ietf-netmod-rfc6020bis is used as a normative reference 828 instead of RFC 6020. 830 o Removed noncharacters as an I-JSON issue because it doesn't exist 831 in YANG 1.1. 833 o Section about anydata encoding was added. 835 o Require I-JSON for anyxml encoding. 837 o Use ABNF for defining qualified name. 839 B.2. Changes Between Revisions -02 and -03 841 o Namespace encoding is defined without using RFC 2119 keywords. 843 o Specification for anyxml nodes was extended and clarified. 845 o Text about ordering of list entries was corrected. 847 B.3. Changes Between Revisions -01 and -02 849 o Encoding of namespaces in instance-identifiers was changed. 851 o Text specifying the order of array elements in leaf-list and list 852 instances was added. 854 B.4. Changes Between Revisions -00 and -01 856 o Metadata encoding was moved to a separate I-D, draft-lhotka- 857 netmod-yang-metadata. 859 o JSON encoding is now defined directly rather than via XML-JSON 860 mapping. 862 o The rules for namespace encoding has changed. This affect both 863 node instance names and instance-identifiers. 865 o I-JSON-related changes. The most significant is the string 866 encoding of 64-bit numbers. 868 o When validating union type, the partial type info present in JSON 869 encoding is taken into account. 871 o Added section about I-JSON compliance. 873 o Updated the example in appendix. 875 o Wrote Security Considerations. 877 o Removed IANA Considerations as there are none. 879 Author's Address 881 Ladislav Lhotka 882 CZ.NIC 884 Email: lhotka@nic.cz