draft-ietf-netmod-yang-json-02.txt   draft-ietf-netmod-yang-json-03.txt 
NETMOD Working Group L. Lhotka NETMOD Working Group L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track November 27, 2014 Intended status: Standards Track February 24, 2015
Expires: May 31, 2015 Expires: August 28, 2015
JSON Encoding of Data Modeled with YANG JSON Encoding of Data Modeled with YANG
draft-ietf-netmod-yang-json-02 draft-ietf-netmod-yang-json-03
Abstract Abstract
This document defines encoding rules for representing configuration, This document defines encoding rules for representing configuration,
state data, RPC input and output parameters, and notifications state data, RPC input and output parameters, and notifications
defined using YANG as JavaScript Object Notation (JSON) text. defined using YANG as JavaScript Object Notation (JSON) text.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 31, 2015. This Internet-Draft will expire on August 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
5. Encoding of YANG Data Node Instances . . . . . . . . . . . . 6 5. Encoding of YANG Data Node Instances . . . . . . . . . . . . 6
5.1. The "leaf" Data Node . . . . . . . . . . . . . . . . . . 6 5.1. The "leaf" Data Node . . . . . . . . . . . . . . . . . . 6
5.2. The "container" Data Node . . . . . . . . . . . . . . . . 7 5.2. The "container" Data Node . . . . . . . . . . . . . . . . 7
5.3. The "leaf-list" Data Node . . . . . . . . . . . . . . . . 7 5.3. The "leaf-list" Data Node . . . . . . . . . . . . . . . . 7
5.4. The "list" Data Node . . . . . . . . . . . . . . . . . . 7 5.4. The "list" Data Node . . . . . . . . . . . . . . . . . . 7
5.5. The "anyxml" Data Node . . . . . . . . . . . . . . . . . 8 5.5. The "anyxml" Data Node . . . . . . . . . . . . . . . . . 8
6. The Mapping of YANG Data Types to JSON Values . . . . . . . . 9 6. The Mapping of YANG Data Types to JSON Values . . . . . . . . 9
6.1. Numeric Types . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Numeric Types . . . . . . . . . . . . . . . . . . . . . . 9
6.2. The "string" Type . . . . . . . . . . . . . . . . . . . . 9 6.2. The "string" Type . . . . . . . . . . . . . . . . . . . . 9
6.3. The "boolean" Type . . . . . . . . . . . . . . . . . . . 9 6.3. The "boolean" Type . . . . . . . . . . . . . . . . . . . 9
6.4. The "enumeration" Type . . . . . . . . . . . . . . . . . 9 6.4. The "enumeration" Type . . . . . . . . . . . . . . . . . 10
6.5. The "bits" Type . . . . . . . . . . . . . . . . . . . . . 9 6.5. The "bits" Type . . . . . . . . . . . . . . . . . . . . . 10
6.6. The "binary" Type . . . . . . . . . . . . . . . . . . . . 10 6.6. The "binary" Type . . . . . . . . . . . . . . . . . . . . 10
6.7. The "leafref" Type . . . . . . . . . . . . . . . . . . . 10 6.7. The "leafref" Type . . . . . . . . . . . . . . . . . . . 10
6.8. The "identityref" Type . . . . . . . . . . . . . . . . . 10 6.8. The "identityref" Type . . . . . . . . . . . . . . . . . 10
6.9. The "empty" Type . . . . . . . . . . . . . . . . . . . . 11 6.9. The "empty" Type . . . . . . . . . . . . . . . . . . . . 11
6.10. The "union" Type . . . . . . . . . . . . . . . . . . . . 11 6.10. The "union" Type . . . . . . . . . . . . . . . . . . . . 11
6.11. The "instance-identifier" Type . . . . . . . . . . . . . 12 6.11. The "instance-identifier" Type . . . . . . . . . . . . . 12
7. I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . . 12 7. I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 15 Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 15
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
B.1. Changes Between Revisions -01 and -02 . . . . . . . . . . 17 B.1. Changes Between Revisions -02 and -03 . . . . . . . . . . 17
B.2. Changes Between Revisions -00 and -01 . . . . . . . . . . 17 B.2. Changes Between Revisions -01 and -02 . . . . . . . . . . 17
B.3. Changes Between Revisions -00 and -01 . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for The NETCONF protocol [RFC6241] uses XML [W3C.REC-xml-20081126] for
encoding data in its Content Layer. Other management protocols might encoding data in its Content Layer. Other management protocols might
want to use other encodings while still benefiting from using YANG want to use other encodings while still benefiting from using YANG
[RFC6020] as the data modeling language. [RFC6020] as the data modeling language.
For example, the RESTCONF protocol [I-D.ietf-netconf-restconf] For example, the RESTCONF protocol [I-D.ietf-netconf-restconf]
skipping to change at page 3, line 15 skipping to change at page 3, line 15
The specification of the YANG data modelling language [RFC6020] The specification of the YANG data modelling language [RFC6020]
defines only XML encoding for data instances, i.e. contents of defines only XML encoding for data instances, i.e. contents of
configuration datastores, state data, RFC input and output configuration datastores, state data, RFC input and output
parameters, and event notifications. The aim of this document is to parameters, and event notifications. The aim of this document is to
define rules for encoding the same data as JavaScript Object Notation define rules for encoding the same data as JavaScript Object Notation
(JSON) text [RFC7159]. (JSON) text [RFC7159].
In order to achieve maximum interoperability while allowing In order to achieve maximum interoperability while allowing
implementations to use a variety of available JSON parsers, the JSON implementations to use a variety of available JSON parsers, the JSON
encoding rules follow, as much as possible, the constraints of the encoding rules follow, as much as possible, the constraints of the
I-JSON restricted profile [I-D.ietf-json-i-json]. Section Section 7 I-JSON restricted profile [I-D.ietf-json-i-json]. Section 7
discusses I-JSON conformance in more detail. discusses I-JSON conformance in more detail.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined in [RFC6020]: The following terms are defined in [RFC6020]:
skipping to change at page 4, line 7 skipping to change at page 4, line 7
o submodule o submodule
3. Validation of JSON-encoded Instance Data 3. Validation of JSON-encoded Instance Data
Instance data validation as defined in [RFC6020] is only applicable Instance data validation as defined in [RFC6020] is only applicable
to XML-encoded data. For one, semantic constraints in "must" to XML-encoded data. For one, semantic constraints in "must"
statements are expressed using XPath 1.0 [W3C.REC-xpath-19991116], statements are expressed using XPath 1.0 [W3C.REC-xpath-19991116],
which can be properly interpreted only in the XML context. which can be properly interpreted only in the XML context.
This document along with the corresponding "XML Mapping Rules" This document and the corresponding "XML Mapping Rules" sections from
sections from [RFC6020] also define an implicit schema-driven mapping [RFC6020] also define an implicit schema-driven mapping of JSON-
of JSON-encoded instances to XML-encoded instances (and vice versa). encoded instances to XML-encoded instances (and vice versa). This
This mapping is mostly straightforward. In cases where doubts could mapping is mostly straightforward. In cases where doubts could
arise, this document gives explicit instructions for mapping JSON- arise, this document gives explicit instructions for mapping JSON-
encoded instances to XML. encoded instances to XML.
In order to validate a JSON instance document, it MUST first be In order to validate a JSON instance document, it MUST first be
mapped, at least conceptually, to the corresponding XML instance mapped, at least conceptually, to the corresponding XML instance
document. By definition, the JSON document is then valid if and only document. By definition, the JSON document is then valid if and only
if the XML document is valid according to the rules stated in if the XML document is valid according to the rules stated in
[RFC6020]. [RFC6020].
4. Names and Namespaces 4. Names and Namespaces
skipping to change at page 4, line 44 skipping to change at page 4, line 44
If the namespace of a member name has to be explicitly specified, the If the namespace of a member name has to be explicitly specified, the
module name SHALL be used as a prefix to the (local) member name. module name SHALL be used as a prefix to the (local) member name.
Both parts of the member name SHALL be separated with a colon Both parts of the member name SHALL be separated with a colon
character (":"). In other words, the namespace-qualified name will character (":"). In other words, the namespace-qualified name will
have the following form: have the following form:
<module name>:<local name> <module name>:<local name>
Figure 1: Encoding a namespace identifier with a local name. Figure 1: Encoding a namespace identifier with a local name.
Names with namespace identifiers in the form shown in Figure 1 MUST Names with namespace identifiers in the form shown in Figure 1 are
be used for all top-level YANG data nodes, and also for all nodes used if and only if the parent data node belongs to a different
whose parent node belongs to a different namespace. Otherwise, names namespace, which also includes all top-level YANG data nodes.
with namespace identifiers MUST NOT be used.
For example, consider the following YANG module: For example, consider the following YANG module:
module foomod { module foomod {
namespace "http://example.com/foomod"; namespace "http://example.com/foomod";
prefix "foo"; prefix "foo";
container top { container top {
skipping to change at page 6, line 12 skipping to change at page 6, line 12
A valid JSON-encoded configuration containing both leafs may then A valid JSON-encoded configuration containing both leafs may then
look like this: look like this:
{ {
"foomod:top": { "foomod:top": {
"foo": 54, "foo": 54,
"barmod:bar": true "barmod:bar": true
} }
} }
The name of the "bar" leaf must be prefixed with the namespace The name of the "bar" leaf is prefixed with the namespace identifier
identifier because its parent is defined in a different module, hence because its parent is defined in a different module, hence it belongs
it belongs to another namespace. to another namespace.
Explicit namespace identifiers are sometimes needed when encoding Explicit namespace identifiers are sometimes needed when encoding
values of the "identityref" and "instances-identifier" types. The values of the "identityref" and "instances-identifier" types. The
same form as shown in Figure 1 is then used as well. See Sections same form as shown in Figure 1 is then used as well. See Sections
6.8 and 6.11 for details. 6.8 and 6.11 for details.
5. Encoding of YANG Data Node Instances 5. Encoding of YANG Data Node Instances
Every complete JSON instance document, such as a configuration Every complete JSON instance document, such as a configuration
datastore content, is an object. Its members are instances of all datastore content, is an object. Its members are instances of all
skipping to change at page 7, line 31 skipping to change at page 7, line 31
"foo": 123 "foo": 123
} }
5.3. The "leaf-list" Data Node 5.3. The "leaf-list" Data Node
A leaf-list is encoded as a name/array pair, and the array elements A leaf-list is encoded as a name/array pair, and the array elements
are values of the same type, which can be a string, number, literal are values of the same type, which can be a string, number, literal
"true" or "false", or the special array "[null]", depending on the "true" or "false", or the special array "[null]", depending on the
type of the leaf-list (see Section 6 for the type encoding rules). type of the leaf-list (see Section 6 for the type encoding rules).
The order of array elements MUST be the same as the order of XML The ordering of array elements follows the same rules as the ordering
elements representing leaf-list entries in the XML encoding. of XML elements representing leaf-list entries in the XML encoding.
Specifically, the "ordered-by" properties (sec. 7.7.5 in [RFC6020])
MUST be observed.
Example: For the leaf-list definition Example: For the leaf-list definition
leaf-list foo { leaf-list foo {
type uint8; type uint8;
} }
the following is a valid instance: the following is a valid instance:
"foo": [123, 0] "foo": [123, 0]
5.4. The "list" Data Node 5.4. The "list" Data Node
A list instance is encoded as a name/array pair, and the array A list instance is encoded as a name/array pair, and the array
elements are JSON objects. elements are JSON objects.
The order of array elements MUST be the same as the order of XML The ordering of array elements follows the same rules as the ordering
elements representing list entries in the XML encoding. of XML elements representing list entries in the XML encoding.
Specifically, the "ordered-by" properties (sec. 7.7.5 in [RFC6020])
MUST be observed.
Unlike the XML encoding, where list keys are required to precede any Unlike the XML encoding, where list keys are required to precede any
other siblings, and to appear in the order specified by the data other siblings within a list entry, and appear in the order specified
model, the order of members within a JSON-encoded list entry is by the data model, the order of members in a JSON-encoded list entry
arbitrary because JSON objects are fundamentally unordered is arbitrary because JSON objects are fundamentally unordered
collections of members. collections of members.
Example: For the list definition Example: For the list definition
list bar { list bar {
key foo; key foo;
leaf foo { leaf foo {
type uint8; type uint8;
} }
leaf baz { leaf baz {
skipping to change at page 8, line 31 skipping to change at page 8, line 34
} }
the following is a valid instance: the following is a valid instance:
"bar": [ "bar": [
{ {
"foo": 123, "foo": 123,
"baz": "zig" "baz": "zig"
}, },
{ {
"foo": 0, "baz": "zag",
"baz": "zag" "foo": 0
} }
] ]
5.5. The "anyxml" Data Node 5.5. The "anyxml" Data Node
An anyxml instance is encoded as a name/value pair. The value can be An anyxml instance is encoded as a name/value pair. The value can be
of any valid JSON type, i.e. an object, array, number, string or one of any valid JSON type, i.e. an object, array, number, string or one
of the literals "true", "false" and "null". of the literals "true", "false" and "null".
This document defines no mapping between the contents of JSON- and This document imposes no other restrictions on the contents of JSON-
XML-encoded anyxml instances. Note that the mapping is not needed encoded anyxml instances. It also doesn't define any universal
for the purposes of validation (Section 3) because anyxml contents mapping between the contents of JSON- and XML-encoded anyxml
are not subject to YANG-based validation (see sec. 7.10 in instances - note that such a mapping is not needed for the purposes
[RFC6020]). of validation (Section 3) because anyxml contents are not subject to
YANG-based validation (see sec. 7.10 in [RFC6020]). However, each
definition of an anyxml node MAY specify, in its "description"
statement, appropriate syntactic, semantic and mapping rules for the
values of that anyxml data node.
Example: For the anyxml definition Example: For the anyxml definition
anyxml bar; anyxml bar;
the following is a valid instance: the following is a valid instance:
"bar": [true, null, true] "bar": [true, null, true]
6. The Mapping of YANG Data Types to JSON Values 6. The Mapping of YANG Data Types to JSON Values
skipping to change at page 9, line 28 skipping to change at page 9, line 36
A value of the "int64", "uint64" or "decimal64" type is encoded as a A value of the "int64", "uint64" or "decimal64" type is encoded as a
JSON string whose contents is the lexical representation of that JSON string whose contents is the lexical representation of that
numeric value as specified in sections 9.2.1 and 9.3.1 of [RFC6020]. numeric value as specified in sections 9.2.1 and 9.3.1 of [RFC6020].
For example, if the type of the leaf "foo" in Section 5.1 was For example, if the type of the leaf "foo" in Section 5.1 was
"uint64" instead of "uint8", the instance would have to be encoded as "uint64" instead of "uint8", the instance would have to be encoded as
"foo": "123" "foo": "123"
The special handling of 64-bit numbers follows from I-JSON The special handling of 64-bit numbers follows from I-JSON
recommendation to encode numbers exceeding the IEEE 754-2000 double recommendation to encode numbers exceeding the IEEE 754-2008 double
precision range as strings, see sec. 2.2 in [I-D.ietf-json-i-json]. precision range as strings, see sec. 2.2 in [I-D.ietf-json-i-json].
6.2. The "string" Type 6.2. The "string" Type
A "string" value encoded as a JSON string, subject to JSON encoding A "string" value encoded as a JSON string, subject to JSON string
rules. encoding rules.
6.3. The "boolean" Type 6.3. The "boolean" Type
A "boolean" value is mapped to the corresponding JSON literal name A "boolean" value is mapped to the corresponding JSON literal name
"true" or "false". "true" or "false".
6.4. The "enumeration" Type 6.4. The "enumeration" Type
An "enumeration" value is mapped in the same way as a string except An "enumeration" value is mapped in the same way as a string except
that the permitted values are defined by "enum" statements in YANG. that the permitted values are defined by "enum" statements in YANG.
skipping to change at page 12, line 8 skipping to change at page 12, line 17
<bar>13.5</bar> <bar>13.5</bar>
because the value may be interpreted as a string, i.e., the second because the value may be interpreted as a string, i.e., the second
member type of the union. When using the "application/ member type of the union. When using the "application/
yang.data+json" media type, however, this is an error: yang.data+json" media type, however, this is an error:
"bar": 13.5 "bar": 13.5
In this case, the JSON encoding indicates the value is supposed to be In this case, the JSON encoding indicates the value is supposed to be
a number rather than string. a number rather than a string.
6.11. The "instance-identifier" Type 6.11. The "instance-identifier" Type
An "instance-identifier" value is encoded as a string that is An "instance-identifier" value is encoded as a string that is
analogical to the lexical representation in XML encoding, see analogical to the lexical representation in XML encoding, see
sec. 9.13.3 in [RFC6020]. However, the encoding of namespaces in sec. 9.13.3 in [RFC6020]. However, the encoding of namespaces in
instance-identifier values follows the rules stated in Section 4, instance-identifier values follows the rules stated in Section 4,
namely: namely:
o The namespace identifier is the module name where each data node o The namespace identifier is the module name where each data node
skipping to change at page 13, line 43 skipping to change at page 14, line 6
8. Security Considerations 8. Security Considerations
This document defines an alternative encoding for data modeled in the This document defines an alternative encoding for data modeled in the
YANG data modeling language. As such, it doesn't contribute any new YANG data modeling language. As such, it doesn't contribute any new
security issues beyond those discussed in sec. 15 of [RFC6020]. security issues beyond those discussed in sec. 15 of [RFC6020].
JSON is rather different from XML, and JSON parsers may thus suffer JSON is rather different from XML, and JSON parsers may thus suffer
from other types of vulnerabilities than their XML counterparts. To from other types of vulnerabilities than their XML counterparts. To
minimize these security risks, it is important that client and server minimize these security risks, it is important that client and server
software supporting JSON encoding behaves as required in sec. 3 of software supporting JSON encoding behaves as required in sec. 3 of
[I-D.ietf-json-i-json]. That is, any received JSON data that violate [I-D.ietf-json-i-json]. That is, received JSON data that violate any
any of I-JSON strict constraints MUST NOT be trusted nor acted upon. of I-JSON strict constraints MUST NOT be trusted nor acted upon.
Violations due to the presence of Unicode Noncharacters in the data Violations due to the presence of Unicode Noncharacters in the data
(see Section 7) SHOULD be carefully examined. (see Section 7) SHOULD be carefully examined.
9. Acknowledgments 9. Acknowledgments
The author wishes to thank Andy Bierman, Martin Bjorklund, Balazs The author wishes to thank Andy Bierman, Martin Bjorklund, Dean
Lengyel, Juergen Schoenwaelder and Phil Shafer for their helpful Bogdanovic, Balazs Lengyel, Juergen Schoenwaelder and Phil Shafer for
comments and suggestions. their helpful comments and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-json-i-json] [I-D.ietf-json-i-json]
Bray, T., "The I-JSON Message Format", draft-ietf-json- Bray, T., "The I-JSON Message Format", draft-ietf-json-
i-json-03 (work in progress), August 2014. i-json-06 (work in progress), January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
skipping to change at page 14, line 38 skipping to change at page 14, line 50
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-03 (work in Protocol", draft-ietf-netconf-restconf-04 (work in
progress), October 2014. progress), January 2015.
[I-D.ietf-netmod-rfc6020bis] [I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "YANG - A Data Modeling Language for the Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", draft-ietf- Network Configuration Protocol (NETCONF)", draft-ietf-
netmod-rfc6020bis-02 (work in progress), November 2014. netmod-rfc6020bis-03 (work in progress), January 2015.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014. Management", RFC 7223, May 2014.
[W3C.REC-xpath-19991116] [W3C.REC-xpath-19991116]
Clark, J. and S. DeRose, "XML Path Language (XPath) Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Recommendation Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, November 1999, REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
skipping to change at page 17, line 20 skipping to change at page 17, line 28
} }
} }
] ]
} }
} }
Appendix B. Change Log Appendix B. Change Log
RFC Editor: Remove this section upon publication as an RFC. RFC Editor: Remove this section upon publication as an RFC.
B.1. Changes Between Revisions -01 and -02 B.1. Changes Between Revisions -02 and -03
o Namespace encoding is defined without using RFC 2119 keywords.
o Specification for anyxml nodes was extended and clarified.
o Text about ordering of list entries was corrected.
B.2. Changes Between Revisions -01 and -02
o Encoding of namespaces in instance-identifiers was changed. o Encoding of namespaces in instance-identifiers was changed.
o Text specifying the order of array elements in leaf-list and list o Text specifying the order of array elements in leaf-list and list
instances was added. instances was added.
B.2. Changes Between Revisions -00 and -01 B.3. Changes Between Revisions -00 and -01
o Metadata encoding was moved to a separate I-D, draft-lhotka- o Metadata encoding was moved to a separate I-D, draft-lhotka-
netmod-yang-metadata. netmod-yang-metadata.
o JSON encoding is now defined directly rather than via XML-JSON o JSON encoding is now defined directly rather than via XML-JSON
mapping. mapping.
o The rules for namespace encoding has changed. This affect both o The rules for namespace encoding has changed. This affect both
node instance names and instance-identifiers. node instance names and instance-identifiers.
 End of changes. 27 change blocks. 
52 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/