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