One document matched: draft-ietf-netmod-yang-json-09.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc docName="draft-ietf-netmod-yang-json-09" ipr="trust200902" category="std">
<front>
<title abbrev="JSON Encoding of YANG Data">JSON Encoding of Data
Modeled with YANG</title>
<author initials="L." surname="Lhotka" fullname="Ladislav Lhotka">
<organization>CZ.NIC</organization>
<address>
<email>lhotka@nic.cz</email>
</address>
</author>
<date day="09" month="March" year="2016"/>
<area>Operations and Management</area>
<area>Operations and Management</area>
<workgroup>NETMOD Working Group</workgroup>
<abstract>
<t>This document defines encoding rules for representing
configuration data, state data, parameters of RPC operations or
actions, and notifications defined using YANG as JavaScript
Object Notation (JSON) text.</t>
</abstract>
</front>
<middle>
<section anchor="sec.introduction" title="Introduction">
<t>The NETCONF protocol <xref target="RFC6241"/> uses XML <xref target="W3C.REC-xml-20081126"/> for encoding data in its Content
Layer. Other management protocols might want to use other
encodings while still benefiting from using YANG <xref target="I-D.ietf-netmod-rfc6020bis"/> as the data modeling
language.</t>
<t>For example, the RESTCONF protocol <xref target="I-D.ietf-netconf-restconf"/> supports two encodings: XML
(media type "application/yang.data+xml") and JSON (media type
"application/yang.data+json").</t>
<t>The specification of YANG 1.1 data modelling language <xref target="I-D.ietf-netmod-rfc6020bis"/> defines only XML encoding
of data trees, i.e., configuration data, state data,
input/output parameters of RPC operations or actions, and
notifications. The aim of this document is to define rules for
encoding the same data as JavaScript Object Notation (JSON)
text <xref target="RFC7159"/>.</t>
</section>
<section anchor="sec.term-not" title="Terminology and Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
<t>The following terms are defined in <xref target="I-D.ietf-netmod-rfc6020bis"/>:
<list style="symbols">
<t>action,</t>
<t>anydata,</t>
<t>anyxml,</t>
<t>augment,</t>
<t>container,</t>
<t>data node,</t>
<t>data tree,</t>
<t>identity,</t>
<t>instance identifier,</t>
<t>leaf,</t>
<t>leaf-list,</t>
<t>list,</t>
<t>module,</t>
<t>RPC operation,</t>
<t>submodule.</t>
</list></t>
<t>The following terms are defined in <xref target="RFC6241"/>:
<list style="symbols">
<t>configuration data,</t>
<t>notification,</t>
<t>state data.</t>
</list></t>
</section>
<section anchor="sec.properties" title="Properties of the JSON Encoding">
<t>This document defines JSON encoding for YANG data trees and
their subtrees. It is always assumed that the top-level
structure in JSON-encoded data is an object.</t>
<t>Instances of YANG data nodes (leafs, containers, leaf-lists,
lists, anydata and anyxml nodes) are encoded as members of a
JSON object, i.e., name/value pairs. <xref target="sec.names-ns"/> defines how the name part is formed, and
the following sections deal with the value part. The encoding
rules are identical for all types of data trees, i.e.,
configuration data, state data, parameters of RPC operations,
actions, and notifications.</t>
<t>With the exception of "anydata" encoding (<xref target="sec.anydata"/>), all rules in this document are also
applicable to YANG 1.0 <xref target="RFC6020"/>.</t>
<t>Unlike XML element content, JSON values carry partial type
information (number, string, boolean). The JSON encoding is
defined so that this information is never in conflict with the
data type of the corresponding YANG leaf or leaf-list.</t>
<t>With the exception of anyxml and schema-less anydata nodes,
it is possible to map a JSON-encoded data tree to XML encoding
as defined in <xref target="I-D.ietf-netmod-rfc6020bis"/>, and
vice versa. However, such conversions require the YANG data
model to be available.</t>
<t>In order to achieve maximum interoperability while allowing
implementations to use a variety of existing JSON parsers, the
JSON encoding rules follow, as much as possible, the constraints
of the I-JSON restricted profile <xref target="RFC7493"/>. <xref target="sec.i-json"/> discusses I-JSON conformance in more
detail.</t>
</section>
<section anchor="sec.names-ns" title="Names and Namespaces">
<t>A JSON object member name MUST be in one of the following
forms:
<list style="symbols">
<t>simple - identical to the identifier of the corresponding
YANG data node;</t>
<t>namespace-qualified - the data node identifier is prefixed
with the name of the module in which the data node is defined,
separated from the data node identifier by the colon character
(":").</t>
</list></t>
<t>The name of a module determines the namespace of all data
node names defined in that module. If a data node is defined in
a submodule, then the namespace-qualified member name uses the
name of the main module to which the submodule belongs.</t>
<t>ABNF syntax <xref target="RFC5234"/> of a member name is
shown in <xref target="fig.mname"/>, where the production for
"identifier" is defined in sec. 13 of <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
<figure anchor="fig.mname" title="ABNF production for a JSON member name.">
<artwork>
member-name = [identifier ":"] identifier
</artwork>
</figure>
<t>A namespace-qualified member name MUST be used for all
members of a top-level JSON object, and then also whenever the
namespaces of the data node and its parent node are
different. In all other cases, the simple form of the member
name MUST be used.</t>
<t>For example, consider the following YANG module:
<figure>
<artwork>
module example-foomod {
namespace "http://example.com/foomod";
prefix "foomod";
container top {
leaf foo {
type uint8;
}
}
}
</artwork>
</figure></t>
<t>If the data model consists only of this module, then the
following is a valid JSON-encoded configuration data:
<figure>
<artwork>
{
"example-foomod:top": {
"foo": 54
}
}
</artwork>
</figure>
</t>
<t>Note that the member of the top-level object uses the
namespace-qualified name but the "foo" leaf doesn't because it
is defined in the same module as its parent container "top".</t>
<t>Now, assume the container "top" is augmented from another
module, "example-barmod":
<figure>
<artwork>
module example-barmod {
namespace "http://example.com/barmod";
prefix "barmod";
import example-foomod {
prefix "foomod";
}
augment "/foo:top" {
leaf bar {
type boolean;
}
}
}
</artwork>
</figure>
</t>
<t>A valid JSON-encoded configuration data containing both leafs
may then look like this:
<figure>
<artwork>
{
"example-foomod:top": {
"foo": 54,
"example-barmod:bar": true
}
}
</artwork>
</figure>
</t>
<t>The name of the "bar" leaf is prefixed with the namespace
identifier because its parent is defined in a different
module.</t>
<t>Explicit namespace identifiers are sometimes needed when
encoding values of the "identityref" and "instances-identifier"
types. The same form of namespace-qualified name as defined
above is then used. See Sections <xref format="counter" target="sec.idref"/> and <xref format="counter" target="sec.i-i"/> for details.</t>
</section>
<section anchor="sec.datanodes" title="Encoding of YANG Data Node Instances">
<t>Every data node instance is encoded as a name/value pair
where the name is formed from the data node identifier using the
rules of <xref target="sec.names-ns"/>. The value depends on the
category of the data node as explained in the following
subsections.</t>
<t>Character encoding MUST be UTF-8.</t>
<section anchor="sec.leaf" title="The "leaf" Data Node">
<t>A leaf instance is encoded as a name/value pair where the
value can be a string, number, literal "true" or "false", or
the special array "[null]", depending on the type of the leaf
(see <xref target="sec.datatypes"/> for the type encoding
rules).</t>
<t>Example: For the leaf node definition
<figure>
<artwork>
leaf foo {
type uint8;
}
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"foo": 123
</artwork>
</figure>
</t>
</section>
<section anchor="sec.container" title="The "container" Data Node">
<t>A container instance is encoded as a name/object pair. The
container's child data nodes are encoded as members of the
object.</t>
<t>Example: For the container definition
<figure>
<artwork>
container bar {
leaf foo {
type uint8;
}
}
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"bar": {
"foo": 123
}
</artwork>
</figure>
</t>
</section>
<section anchor="sec.leaf-list" title="The "leaf-list" Data Node">
<t>A leaf-list is encoded as a name/array pair, and the array
elements are values of some scalar type, which can be a
string, number, literal "true" or "false", or the special
array "[null]", depending on the type of the leaf-list (see
<xref target="sec.datatypes"/> for the type encoding
rules).</t>
<t>The ordering of array elements follows the same rules as
the ordering of XML elements representing leaf-list entries in
the XML encoding. Specifically, the "ordered-by" properties
(sec. 7.7.7 in <xref target="I-D.ietf-netmod-rfc6020bis"/>)
MUST be observed.</t>
<t>Example: For the leaf-list definition
<figure>
<artwork>
leaf-list foo {
type uint8;
}
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"foo": [123, 0]
</artwork>
</figure>
</t>
</section>
<section anchor="sec.list" title="The "list" Data Node">
<t>A list instance is encoded as a name/array pair, and the
array elements are JSON objects.</t>
<t>The ordering of array elements follows the same rules as
the ordering of XML elements representing list entries in the
XML encoding. Specifically, the "ordered-by" properties
(sec. 7.7.7 in <xref target="I-D.ietf-netmod-rfc6020bis"/>)
MUST be observed.</t>
<t>Unlike the XML encoding, where list keys are required to
precede any other siblings within a list entry, and appear in
the order specified by the data model, the order of members in
a JSON-encoded list entry is arbitrary because JSON objects
are fundamentally unordered collections of members.</t>
<t>Example: For the list definition
<figure>
<artwork>
list bar {
key foo;
leaf foo {
type uint8;
}
leaf baz {
type string;
}
}
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"bar": [
{
"foo": 123,
"baz": "zig"
},
{
"baz": "zag",
"foo": 0
}
]
</artwork>
</figure>
</t>
</section>
<section anchor="sec.anydata" title="The "anydata" Data Node">
<t>Anydata data node serves as a container for an arbitrary
set of nodes that otherwise appear as normal YANG-modeled
data. A data model for anydata content may or may not be known
at run time. In the latter case, converting JSON-encoded
instances to the XML encoding defined in <xref target="I-D.ietf-netmod-rfc6020bis"/> may be impossible.</t>
<t>An anydata instance is encoded in the same way as a
container, i.e., as a value/object pair. The requirement that
anydata content can be modeled by YANG implies the following
rules for the JSON text inside the object:
<list style="symbols">
<t>It is valid I-JSON <xref target="RFC7493"/>.</t>
<t>All object member names satisfy the ABNF production in
<xref target="fig.mname"/>.</t>
<t>Any JSON array contains either only unique scalar values
(as a leaf-list, see <xref target="sec.leaf-list"/>), or
only objects (as a list, see <xref target="sec.list"/>).</t>
<t>The "null" value is only allowed in the single-element
array "[null]" corresponding to the encoding of the "empty"
type, see <xref target="sec.empty"/>.</t>
</list></t>
<t>Example: for the anydata definition
<figure>
<artwork>
anydata data;
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"data": {
"ietf-notification:notification": {
"eventTime": "2014-07-29T13:43:01Z",
"example-event:event": {
"event-class": "fault",
"reporting-entity": {
"card": "Ethernet0"
},
"severity": "major"
}
}
}
</artwork>
</figure>
</t>
</section>
<section anchor="sec.anyxml" title="The "anyxml" Data Node">
<t>An anyxml instance is encoded as a JSON name/value pair.
The value MUST satisfy I-JSON constraints.</t>
<t>Example: For the anyxml definition
<figure>
<artwork>
anyxml bar;
</artwork>
</figure>
the following is a valid JSON-encoded instance:
<figure>
<artwork>
"bar": [true, null, true]
</artwork>
</figure>
</t>
</section>
<section anchor="sec.meta" title="Metadata Objects">
<t>Apart from instances of YANG data nodes, a JSON document
MAY contain special object members whose name starts with the
"@" character (COMMERCIAL AT). Such members are used for
special purposes such as encoding metadata <xref target="I-D.ietf-netmod-yang-metadata"/>. Exact syntax and
semantics of such members are outside the scope of this
document.</t>
</section>
</section>
<section anchor="sec.datatypes" title="Representing YANG Data Types in JSON Values">
<t>The type of the JSON value in an instance of the leaf or
leaf-list data node depends on the type of that data node as
specified in the following subsections.</t>
<section anchor="sec.numtypes" title="Numeric Types">
<t>A value of the types "int8", "int16", "int32", "uint8",
"uint16" and "uint32" is represented as a JSON number.</t>
<t>A value of the "int64", "uint64" or "decimal64" type is
represented as a JSON string whose content is the lexical
representation of the corresponding YANG type as specified in
sections 9.2.1 and 9.3.1 of <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
<t>For example, if the type of the leaf "foo" in <xref target="sec.leaf"/> was "uint64" instead of "uint8", the
instance would have to be encoded as</t>
<figure>
<artwork>
"foo": "123"
</artwork>
</figure>
<t>The special handling of 64-bit numbers follows from the
I-JSON recommendation to encode numbers exceeding the IEEE
754-2008 double precision range as strings, see sec. 2.2 in
<xref target="RFC7493"/>.</t>
</section>
<section anchor="sec.string" title="The "string" Type">
<t>A "string" value is represented as a JSON string, subject to
JSON string encoding rules.</t>
</section>
<section anchor="sec.boolean" title="The "boolean" Type">
<t>A "boolean" value is represented as the corresponding JSON
literal name "true" or "false".</t>
</section>
<section anchor="sec.enum" title="The "enumeration" Type">
<t>An "enumeration" value is represented as a JSON string -
one of the names assigned by "enum" statements in YANG.</t>
<t>The representation is identical to the lexical
representation of the "enumeration" type in XML, see sec. 9.6
in <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
</section>
<section anchor="sec.bits" title="The "bits" Type">
<t>A "bits" value is represented as a JSON string - a
space-separated sequence of names of bits that are set. The
permitted bit names are assigned by "bit" statements in
YANG.</t>
<t>The representation is identical to the lexical
representation of the "bits" type, see sec. 9.7 in <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
</section>
<section anchor="sec.binary" title="The "binary" Type">
<t>A "binary" value is represented as a JSON string -
base64-encoding of arbitrary binary data.</t>
<t>The representation is identical to the lexical
representation of the "binary" type in XML, see sec. 9.8 in
<xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
</section>
<section anchor="sec.leafref" title="The "leafref" Type">
<t>A "leafref" value is represented using the same rules as
the type of the leaf to which the leafref value refers.</t>
</section>
<section anchor="sec.idref" title="The "identityref" Type">
<t>An "identityref" value is represented as a string - the
name of an identity. If the identity is defined in another
module than the leaf node containing the identityref value,
the namespace-qualified form (<xref target="sec.names-ns"/>)
MUST be used. Otherwise, both the simple and
namespace-qualified forms are permitted.</t>
<t>For example, consider the following schematic module:</t>
<figure>
<artwork>
module example-mod {
...
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
...
leaf type {
type identityref {
base "if:interface-type";
}
}
}
</artwork>
</figure>
<t>A valid instance of the "type" leaf is then encoded as
follows:
<figure>
<artwork>
"type": "iana-if-type:ethernetCsmacd"
</artwork>
</figure>
</t>
<t>The namespace identifier "iana-if-type" must be present in
this case because the "ethernetCsmacd" identity is not defined
in the same module as the "type" leaf.</t>
</section>
<section anchor="sec.empty" title="The "empty" Type">
<t>An "empty" value is represented as "[null]", i.e., an array
with the "null" literal being its only element. For the
purposes of this document, "[null]" is considered an atomic
scalar value.</t>
<t>This encoding of the "empty" type was chosen instead of
using simply "null" in order to facilitate the use of empty
leafs in common programming languages where the "null" value of a
member is treated as if the member is not present.</t>
<t>Example: For the leaf definition
<figure>
<artwork>
leaf foo {
type empty;
}
</artwork>
</figure>
a valid instance is
<figure>
<artwork>
"foo": [null]
</artwork>
</figure>
</t>
</section>
<section anchor="sec.union" title="The "union" Type">
<t>A value of the "union" type is encoded as the value of any
of the member types.</t>
<t>When validating a value of the "union" type, the type
information conveyed by the JSON encoding MUST also be taken
into account. JSON syntax thus provides additional means for
resolving union member type that are not available in XML
encoding.</t>
<t>For example, consider the following YANG definition:
<figure>
<artwork>
leaf bar {
type union {
type uint16;
type string;
}
}
</artwork>
</figure>
In RESTCONF <xref target="I-D.ietf-netconf-restconf"/>, it is
possible to set the value of "bar" in the following way when
using the "application/yang.data+xml" media type:
<figure>
<artwork>
<bar>13.5</bar>
</artwork>
</figure>
because the value may be interpreted as a string, i.e., the
second member type of the union. When using the
"application/yang.data+json" media type, however, this is an error:
<figure>
<artwork>
"bar": 13.5
</artwork>
</figure>
In this case, the JSON encoding indicates the value is
supposed to be a number rather than a string, and it is not a
valid "uint16" value.</t>
<t>Conversely, the value of
<figure>
<artwork>
"bar": "1"
</artwork>
</figure>
is to be interpreted as a string.</t>
</section>
<section anchor="sec.i-i" title="The "instance-identifier" Type">
<t>An "instance-identifier" value is encoded as a string that
is analogical to the lexical representation in XML encoding,
see sec. 9.13.3 in <xref target="I-D.ietf-netmod-rfc6020bis"/>. However, the encoding
of namespaces in instance-identifier values follows the rules
stated in <xref target="sec.names-ns"/>, namely:
<list style="symbols">
<t>The leftmost (top-level) data node name is always in the
namespace-qualified form.</t>
<t>Any subsequent data node name is in the
namespace-qualified form if the node is defined in another
module than its parent node, and the simple form is used
otherwise. This rule also holds for node names appearing in
predicates.</t>
</list></t>
<t>For example,
<figure>
<artwork>
/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip
</artwork>
</figure>
is a valid instance-identifer value because the data nodes
"interfaces", "interface" and "name" are defined in the module
"ietf-interfaces", whereas "ipv4" and "ip" are defined in
"ietf-ip".</t>
</section>
</section>
<section anchor="sec.i-json" title="I-JSON Compliance">
<t>I-JSON <xref target="RFC7493"/> is a restricted profile of
JSON that guarantees maximum interoperability for protocols that
use JSON in their messages, no matter what JSON
encoders/decoders are used in protocol implementations. The
encoding defined in this document therefore observes the I-JSON
requirements and recommendations as closely as possible.</t>
<t>In particular, the following properties are guaranteed:
<list style="symbols">
<t>Character encoding is UTF-8.</t>
<t>Member names within the same JSON object are always unique.</t>
<t>The order of JSON object members is never relied upon.</t>
<t>Numbers of any type supported by YANG can be exchanged
reliably. See <xref target="sec.numtypes"/> for details.</t>
</list>
</t>
<t>The JSON encoding defined in this document deviates from
I-JSON only in the representation of the "binary" type. In order
to remain compatible with XML encoding, the base64 encoding
scheme is used (<xref target="sec.binary"/>), whilst I-JSON
recommends base64url instead.</t>
</section>
<section anchor="sec.cons" title="Security Considerations">
<t>This document defines an alternative encoding for data
modeled in the YANG data modeling language. As such, it doesn't
contribute any new security issues beyond those discussed in
sec. 16 of <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
<t>JSON processing is rather different from XML, and JSON
parsers may thus suffer from other types of vulnerabilities than
their XML counterparts. To minimize these new security risks,
software on the receiving side SHOULD reject all messages that
do not comply to the rules of this document and reply with an
appropriate error message to the sender.</t>
</section>
<section anchor="sec.ack" title="Acknowledgments">
<t>The author wishes to thank Andy Bierman, Martin Bjorklund,
Dean Bogdanovic, Balazs Lengyel, Juergen Schoenwaelder and Phil
Shafer for their helpful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC7159" target="http://www.rfc-editor.org/info/rfc7159">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author>
<date year="2014" month="March"/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name="RFC" value="7159"/>
<seriesInfo name="DOI" value="10.17487/RFC7159"/>
</reference>
<reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5234" target="http://www.rfc-editor.org/info/rfc5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="editor"><organization/></author>
<author initials="P." surname="Overell" fullname="P. Overell"><organization/></author>
<date year="2008" month="January"/>
<abstract><t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="I-D.ietf-netmod-rfc6020bis">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<date month="February" day="16" year="2016"/>
<abstract><t>YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols like the Network Configuration Protocol (NETCONF).</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc6020bis-11"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-rfc6020bis-11.txt"/>
</reference>
<reference anchor="RFC6241" target="http://www.rfc-editor.org/info/rfc6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor"><organization/></author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><organization/></author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor"><organization/></author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="editor"><organization/></author>
<date year="2011" month="June"/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC7493" target="http://www.rfc-editor.org/info/rfc7493">
<front>
<title>The I-JSON Message Format</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author>
<date year="2015" month="March"/>
<abstract><t>I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t></abstract>
</front>
<seriesInfo name="RFC" value="7493"/>
<seriesInfo name="DOI" value="10.17487/RFC7493"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC6020" target="http://www.rfc-editor.org/info/rfc6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><organization/></author>
<date year="2010" month="October"/>
<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC7223" target="http://www.rfc-editor.org/info/rfc7223">
<front>
<title>A YANG Data Model for Interface Management</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund"><organization/></author>
<date year="2014" month="May"/>
<abstract><t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).</t></abstract>
</front>
<seriesInfo name="RFC" value="7223"/>
<seriesInfo name="DOI" value="10.17487/RFC7223"/>
</reference>
<reference anchor="I-D.ietf-netconf-restconf">
<front>
<title>RESTCONF Protocol</title>
<author initials="A" surname="Bierman" fullname="Andy Bierman">
<organization/>
</author>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<author initials="K" surname="Watsen" fullname="Kent Watsen">
<organization/>
</author>
<date month="December" day="15" year="2015"/>
<abstract><t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-restconf-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-restconf-09.txt"/>
</reference>
<reference anchor="I-D.ietf-netmod-yang-metadata">
<front>
<title>Defining and Using Metadata with YANG</title>
<author initials="L" surname="Lhotka" fullname="Ladislav Lhotka">
<organization/>
</author>
<date month="February" day="24" year="2016"/>
<abstract><t>This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-metadata-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-04.txt"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="http://www.w3.org/TR/2008/REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization/>
</author>
<author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization/>
</author>
<author initials="M." surname="Sperberg-McQueen" fullname="Michael Sperberg-McQueen">
<organization/>
</author>
<author initials="E." surname="Maler" fullname="Eve Maler">
<organization/>
</author>
<author initials="F." surname="Yergeau" fullname="François Yergeau">
<organization/>
</author>
<date month="November" day="26" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
<format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-20081126"/>
</reference>
</references>
<section anchor="app.ex-if" title="A Complete Example">
<t>The JSON document shown below represents the same data as the
reply to the NETCONF <get> request appearing in Appendix D
of <xref target="RFC7223"/>. The data model is a combination of
two YANG modules: "ietf-interfaces" and "ex-vlan" (the latter is
an example module from Appendix C of <xref target="RFC7223"/>). The "if-mib" feature defined in the
"ietf-interfaces" module is supported.</t>
<figure>
<artwork>
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"enabled": false
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ex-vlan:vlan-tagging": true
},
{
"name": "eth1.10",
"type": "iana-if-type:l2vlan",
"enabled": true,
"ex-vlan:base-interface": "eth1",
"ex-vlan:vlan-id": 10
},
{
"name": "lo1",
"type": "iana-if-type:softwareLoopback",
"enabled": true
}
]
},
"ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"admin-status": "down",
"oper-status": "down",
"if-index": 2,
"phys-address": "00:01:02:03:04:05",
"statistics": {
"discontinuity-time": "2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"admin-status": "up",
"oper-status": "up",
"if-index": 7,
"phys-address": "00:01:02:03:04:06",
"higher-layer-if": [
"eth1.10"
],
"statistics": {
"discontinuity-time": "2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth1.10",
"type": "iana-if-type:l2vlan",
"admin-status": "up",
"oper-status": "up",
"if-index": 9,
"lower-layer-if": [
"eth1"
],
"statistics": {
"discontinuity-time": "2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"admin-status": "down",
"oper-status": "down",
"if-index": 8,
"phys-address": "00:01:02:03:04:07",
"statistics": {
"discontinuity-time": "2013-04-01T03:00:00+00:00"
}
},
{
"name": "lo1",
"type": "iana-if-type:softwareLoopback",
"admin-status": "up",
"oper-status": "up",
"if-index": 1,
"statistics": {
"discontinuity-time": "2013-04-01T03:00:00+00:00"
}
}
]
}
}
</artwork>
</figure>
</section>
<section title="Change Log">
<t>RFC Editor: Remove this section upon publication as an RFC.</t>
<section title="Changes Between Revisions -08 and -09">
<t>
<list style="symbols">
<t>References to RFC 6241 term in the Terminology section
were added.</t>
<t>Prefixes in the example in Sec. 4 were changed so as to be
different from node names.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -07 and -08">
<t>
<list style="symbols">
<t>Changed the names of example modules so that they start
with "example-".</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -06 and -07">
<t>
<list style="symbols">
<t>General permit on object members whose names start with
"@".</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -05 and -06">
<t>
<list style="symbols">
<t>More text and a new example about resolving union-type values.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -04 and -05">
<t>
<list style="symbols">
<t>Removed section "Validation of JSON-encoded Instance
Data" and other text about XML-JSON mapping.</t>
<t>Added section "Properties of the JSON Encoding".</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -03 and -04">
<t>
<list style="symbols">
<t>I-D.ietf-netmod-rfc6020bis is used as a normative
reference instead of RFC 6020.</t>
<t>Removed noncharacters as an I-JSON issue because it
doesn't exist in YANG 1.1.</t>
<t>Section about anydata encoding was added.</t>
<t>Require I-JSON for anyxml encoding.</t>
<t>Use ABNF for defining qualified name.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -02 and -03">
<t>
<list style="symbols">
<t>Namespace encoding is defined without using RFC 2119
keywords.</t>
<t>Specification for anyxml nodes was extended and
clarified.</t>
<t>Text about ordering of list entries was corrected.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -01 and -02">
<t>
<list style="symbols">
<t>Encoding of namespaces in instance-identifiers was changed.</t>
<t>Text specifying the order of array elements in
leaf-list and list instances was added.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -00 and -01">
<t>
<list style="symbols">
<t>Metadata encoding was moved to a separate I-D,
draft-lhotka-netmod-yang-metadata.</t>
<t>JSON encoding is now defined directly rather than via
XML-JSON mapping.</t>
<t>The rules for namespace encoding has changed. This
affect both node instance names and
instance-identifiers.</t>
<t>I-JSON-related changes. The most significant is the
string encoding of 64-bit numbers.</t>
<t>When validating union type, the partial type info
present in JSON encoding is taken into account.</t>
<t>Added section about I-JSON compliance.</t>
<t>Updated the example in appendix.</t>
<t>Wrote Security Considerations.</t>
<t>Removed IANA Considerations as there are none.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:26:57 |