RFC 7951

JSON Encoding of Data Modeled with YANG

📅 published August 2016, from ietf

RFC 7951: JSON Encoding of Data Modeled with YANG 💖

Okay bestie, let's start with the ID card 🪪✨ This is RFC 7951, called JSON Encoding of Data Modeled with YANG. It was written by L. Lhotka from CZ.NIC, it's a Standards Track doc (so it's the real deal, no cap), it's published under ISSN 2070-1721, and it dropped in August 2016 📅. The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Abstract

okay so this doc is all about the rules for turning YANG-modeled data into JSON text 🦋 That covers configuration data, state data, RPC operation or action parameters, and notifications. YANG is the data modeling language, and JSON is the format everyone's using now, so this is the glow-up nobody knew they needed ✨

Status of This Memo

This is an Internet Standards Track document 👑

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🌸

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7951 🧚

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, bestie, because they spell out your rights and restrictions. Code extracted from this document has to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty, also as described in the Simplified BSD License 📜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
3.  Properties of the JSON Encoding . . . . . . . . . . . . . . .   4
4.  Names and Namespaces  . . . . . . . . . . . . . . . . . . . .   5
5.  Encoding of YANG Data Node Instances  . . . . . . . . . . . .   7
  5.1.  The "leaf" Data Node  . . . . . . . . . . . . . . . . . .   7
  5.2.  The "container" Data Node . . . . . . . . . . . . . . . .   8
  5.3.  The "leaf-list" Data Node . . . . . . . . . . . . . . . .   8
  5.4.  The "list" Data Node  . . . . . . . . . . . . . . . . . .   9
  5.5.  The "anydata" Data Node . . . . . . . . . . . . . . . . .   9
  5.6.  The "anyxml" Data Node  . . . . . . . . . . . . . . . . .  10
  5.7.  Metadata Objects  . . . . . . . . . . . . . . . . . . . .  11
6.  Representing YANG Data Types in JSON Values . . . . . . . . .  11
  6.1.  Numeric Types . . . . . . . . . . . . . . . . . . . . . .  11
  6.2.  The "string" Type . . . . . . . . . . . . . . . . . . . .  11
  6.3.  The "boolean" Type  . . . . . . . . . . . . . . . . . . .  11
  6.4.  The "enumeration" Type  . . . . . . . . . . . . . . . . .  12
  6.5.  The "bits" Type . . . . . . . . . . . . . . . . . . . . .  12
  6.6.  The "binary" Type . . . . . . . . . . . . . . . . . . . .  12
  6.7.  The "leafref" Type  . . . . . . . . . . . . . . . . . . .  12
  6.8.  The "identityref" Type  . . . . . . . . . . . . . . . . .  12
  6.9.  The "empty" Type  . . . . . . . . . . . . . . . . . . . .  13
  6.10. The "union" Type  . . . . . . . . . . . . . . . . . . . .  14
  6.11. The "instance-identifier" Type  . . . . . . . . . . . . .  15
7.  I-JSON Compliance . . . . . . . . . . . . . . . . . . . . . .  15
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
Appendix A.  A Complete Example . . . . . . . . . . . . . . . . .  18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

okay so NETCONF [RFC6241] uses XML [XML] to encode data in its Content Layer. Other management protocols might want a different encoding but still want YANG [RFC7950] as their data modeling language. Relatable 🫶

For example, the RESTCONF protocol [RESTCONF] supports two encodings: XML (media type application/yang.data+xml) and JavaScript Object Notation (JSON) (media type application/yang.data+json). Two options, both iconic 💅

The YANG 1.1 spec [RFC7950] only defines XML encoding for data trees. That covers configuration data, state data, input and output parameters of Remote Procedure Call (RPC) operations or actions, and notifications. So this doc's whole job is to define how to encode that same data as JSON text [RFC7159] 🌈

2. Terminology and Notation 📝

Bestie, the BCP 14 key words here are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're to be read as described in [RFC2119], so these words are not just vibes 🔥

These terms are defined in [RFC7950]:

  • action
  • anydata
  • anyxml
  • augment
  • container
  • data node
  • data tree
  • identity
  • instance identifier
  • leaf
  • leaf-list
  • list
  • module
  • RPC operation
  • submodule

These terms are defined in [RFC6241]:

  • configuration data
  • notification
  • state data

3. Properties of the JSON Encoding 🦋

This doc defines the JSON encoding for YANG data trees and their subtrees. It's always assumed that the top-level structure in JSON-encoded data is an object 💜

Instances of YANG data nodes (leafs, containers, leaf-lists, lists, anydata nodes, and anyxml nodes) get encoded as members of a JSON object, which means name/value pairs. Section 4 explains how the name part is formed, and the sections after it handle the value part. The encoding rules are the same for every kind of data tree: configuration data, state data, RPC operation parameters, actions, and notifications. One set of rules, all the vibes 🌸

Except for "anydata" encoding (Section 5.5), every rule in this doc also applies to YANG 1.0 [RFC6020] ✨

Unlike XML element content, JSON values carry partial type information (number, string, boolean). The JSON encoding is designed so that this info never conflicts with the data type of the corresponding YANG leaf or leaf-list 🎀

Except for anyxml and schema-less anydata nodes, a JSON-encoded data tree can be mapped to XML encoding as defined in [RFC7950], and the other way around too. But those conversions need the YANG data model to be available 🧚

To get maximum interoperability while still letting implementations use a bunch of existing JSON parsers, the JSON encoding rules follow the constraints of the I-JSON (Internet JSON) restricted profile [RFC7493] as much as possible. Section 7 goes deeper into I-JSON conformance 🫶

4. Names and Namespaces 🏷️

A JSON object member name MUST be in one of the following forms:

  • simple - identical to the identifier of the corresponding YANG data node.
  • namespace-qualified - the data node identifier is prefixed with the name of the module where the data node is defined, separated from the identifier by a colon character (":").

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, the namespace-qualified member name uses the name of the main module that the submodule belongs to 💅

Here's the ABNF syntax [RFC5234] for a member name, where the production for "identifier" is defined in Section 14 of [RFC7950]:

        member-name = [identifier ":"] identifier

          Figure 1: ABNF Production for a JSON Member Name

A namespace-qualified member name MUST be used for all members of a top-level JSON object, and 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 🔥

Here's an example YANG module, bestie:

module example-foomod {

  namespace "http://example.com/foomod";

  prefix "foomod";

  container top {
    leaf foo {
      type uint8;
    }
  }
}

If the data model is only this module, then the following is valid JSON-encoded configuration data:

{
  "example-foomod:top": {
    "foo": 54
  }
}

Note the vibe here: the top-level object member uses the namespace-qualified name, but the "foo" leaf doesn't, because it's defined in the same module as its parent container "top" 🍓

Now say the container "top" gets augmented from another module, "example-barmod":

module example-barmod {

  namespace "http://example.com/barmod";

  prefix "barmod";

  import example-foomod {
    prefix "foomod";
  }

  augment "/foomod:top" {
    leaf bar {
      type boolean;
    }
  }
}

Valid JSON-encoded configuration data with both leafs might look like this:

{
  "example-foomod:top": {
    "foo": 54,
    "example-barmod:bar": true
  }
}

The name of the "bar" leaf gets the namespace prefix because its parent is defined in a different module. Main character energy 👑

Explicit namespace identifiers are sometimes needed when encoding values of the "identityref" and "instance-identifier" types. The same namespace-qualified name form as above gets used there. See Sections 6.8 and 6.11 for details 🌈

5. Encoding of YANG Data Node Instances 🧁

Every data node instance is encoded as a name/value pair. The name is formed from the data node identifier using the rules in Section 4. The value depends on the category of the data node, as explained in the subsections below 💖

Character encoding MUST be UTF-8. No compromises on this one, bestie 💜

5.1. The "leaf" Data Node 🍃

A leaf instance is encoded as a name/value pair. The value can be a string, a number, the literal "true" or "false", or the special array "[null]", depending on the type of the leaf (see Section 6 for the type encoding rules) ✨

Example: for the leaf node definition

leaf foo {
  type uint8;
}

the following is a valid JSON-encoded instance:

"foo": 123

5.2. The "container" Data Node 📦

A container instance is encoded as a name/object pair. The container's child data nodes are encoded as members of that object 🎀

Example: for the container definition

container bar {
  leaf foo {
    type uint8;
  }
}

the following is a valid JSON-encoded instance:

"bar": {
  "foo": 123
}

5.3. The "leaf-list" Data Node 🌸

A leaf-list is encoded as a name/array pair. The array elements are values of some scalar type, which can be a string, a number, the literal "true" or "false", or the special array "[null]", depending on the type of the leaf-list (see Section 6 for the type encoding rules) 🦋

The order of array elements follows the same rules as the ordering of XML elements that represent leaf-list entries in the XML encoding. Specifically, the "ordered-by" properties (Section 7.7.7 in [RFC7950]) MUST be observed. Non-negotiable, periodt 💅

Example: for the leaf-list definition

leaf-list foo {
  type uint8;
}

the following is a valid JSON-encoded instance:

"foo": [123, 0]

5.4. The "list" Data Node 📋

Okay so a list instance gets encoded as a name/array pair, and the array elements are JSON objects 💖

The array elements follow the same ordering rules as the XML elements that represent list entries in the XML encoding. Specifically, the "ordered-by" properties (Section 7.7.7 in [RFC7950]) MUST be observed ✨

Here's the difference from XML, bestie. In XML, list keys have to come before any other siblings in a list entry, and they show up in the order the data model says. In JSON, the member order inside a list entry is arbitrary, because JSON objects are basically unordered collections of members 🫶

Example: For the list definition

list bar {
  key foo;
  leaf foo {
    type uint8;
  }
  leaf baz {
    type string;
  }
}

here's a valid JSON-encoded instance:

"bar": [
  {
    "foo": 123,
    "baz": "zig"
  },
  {
    "baz": "zag",
    "foo": 0
  }
]

5.5. The "anydata" Data Node 🌈

The anydata data node is a container for an arbitrary set of nodes that otherwise look like normal YANG-modeled data. A data model for anydata content may or may not be known at runtime. If it isn't, converting JSON-encoded instances to the XML encoding defined in [RFC7950] may be impossible 🥺

An anydata instance is encoded the same way as a container, i.e., as a name/object pair. Since anydata content has to be modelable in YANG, the JSON text inside the object follows these rules:

  • It is valid I-JSON [RFC7493].
  • All object member names satisfy the ABNF production in Figure 1.
  • Any JSON array contains either only unique scalar values (as a leaf-list; see Section 5.3) or only objects (as a list; see Section 5.4).
  • The null value is only allowed in the single-element array [null] corresponding to the encoding of the "empty" type; see Section 6.9.

Example: For the anydata definition

anydata data;

here's a valid JSON-encoded instance:

"data": {
  "ietf-notification:notification": {
    "eventTime": "2014-07-29T13:43:01Z",
    "example-event:event": {
      "event-class": "fault",
      "reporting-entity": {
        "card": "Ethernet0"
      },
      "severity": "major"
    }
  }
}

5.6. The "anyxml" Data Node 🎀

An anyxml instance is encoded as a JSON name/value pair. The value MUST satisfy I-JSON constraints 💅

Example: For the anyxml definition

anyxml bar;

here's a valid JSON-encoded instance:

"bar": [true, null, true]

5.7. Metadata Objects 🏷️

Apart from instances of YANG data nodes, a JSON document MAY contain special object members whose name starts with the @ character (COMMERCIAL AT). These members are used for special purposes, like encoding metadata [RFC7952]. The exact syntax and semantics of such members are outside the scope of this document 🧚

6. Representing YANG Data Types in JSON Values 🍓

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 laid out in the following subsections 💖

6.1. Numeric Types 🔢

A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number.

A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string. That string's content is the lexical representation of the corresponding YANG type, as specified in Sections 9.2.1 and 9.3.1 of [RFC7950] ✨

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

"foo": "123"

The special handling of 64-bit numbers comes from the I-JSON recommendation to encode numbers that exceed the IEEE 754-2008 double-precision range [IEEE754-2008] as strings; see Section 2.2 in [RFC7493] 🫧

6.2. The "string" Type 🧵

A "string" value is represented as a JSON string, subject to JSON string encoding rules.

6.3. The "boolean" Type ✅

A "boolean" value is represented as the corresponding JSON literal name true or false.

6.4. The "enumeration" Type 🎈

An "enumeration" value is represented as a JSON string -- one of the names assigned by "enum" statements in YANG.

The representation is identical to the lexical representation of the "enumeration" type in XML; see Section 9.6 in [RFC7950].

6.5. The "bits" Type 🫧

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.

The representation is identical to the lexical representation of the "bits" type; see Section 9.7 in [RFC7950].

6.6. The "binary" Type 🔐

A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data.

The representation is identical to the lexical representation of the "binary" type in XML; see Section 9.8 in [RFC7950].

6.7. The "leafref" Type 🔗

A "leafref" value is represented using the same rules as the type of the leaf to which the leafref value refers.

6.8. The "identityref" Type 🪪

An "identityref" value is represented as a string -- the name of an identity. If the identity is defined in a module other than the leaf node containing the identityref value, the namespace-qualified form (Section 4) MUST be used. Otherwise, both the simple and namespace-qualified forms are permitted 🌸

For example, consider the following schematic module:

module example-mod {
  ...
  import ietf-interfaces {
    prefix if;
  }
  ...
  leaf type {
    type identityref {
      base "if:interface-type";
    }
  }
}

A valid instance of the "type" leaf is then encoded as follows:

"type": "iana-if-type:ethernetCsmacd"

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 🙈

6.9. The "empty" Type 🫙

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 🧁

This encoding of the "empty" type was chosen instead of simply using null, so that empty leafs are easy to use in common programming languages, where a null member value is treated as if the member is not present 💜

Example: For the leaf definition

leaf foo {
  type empty;
}

a valid instance is

"foo": [null]

6.10. The "union" Type 🧩

A value of the "union" type is encoded as the value of any of the member types.

When validating a value of the "union" type, the type information conveyed by the JSON encoding MUST also be taken into account. JSON syntax therefore gives you extra ways to resolve the member type of the union that aren't available in the XML encoding 👑

For example, consider the following YANG definition:

leaf bar {
  type union {
    type uint16;
    type string;
  }
}

In RESTCONF [RESTCONF], you can set the value of "bar" like this when using the "application/yang.data+xml" media type:

<bar>13.5</bar>

That works 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:

"bar": 13.5

In this case, the JSON encoding says the value is supposed to be a number rather than a string, and it isn't a valid "uint16" value 🙅‍♀️

Conversely, the value

"bar": "1"

is to be interpreted as a string 🎀

6.11. The "instance-identifier" Type 🗺️

An "instance-identifier" value is encoded as a string that is analogical to the lexical representation in XML encoding; see Section 9.13.2 in [RFC7950]. However, the encoding of namespaces in instance-identifier values follows the rules stated in Section 4, namely:

  • The leftmost (top-level) data node name is always in the namespace-qualified form.
  • Any subsequent data node name is in the namespace-qualified form if the node is defined in a module other than its parent node, and the simple form is used otherwise. This rule also holds for node names appearing in predicates.

For example,

/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip

is a valid instance-identifier 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" 💫

7. I-JSON Compliance 🫧

I-JSON [RFC7493] is a restricted profile of JSON that guarantees maximum interoperability for protocols that use JSON in their messages, no matter which JSON encoders and decoders the protocol implementations use. The encoding defined in this document therefore observes the I-JSON requirements and recommendations as closely as possible 💖

In particular, the following properties are guaranteed:

  • Character encoding is UTF-8.
  • Member names within the same JSON object are always unique.
  • The order of JSON object members is never relied upon.
  • Numbers of any type supported by YANG can be exchanged reliably. See Section 6.1 for details.

The JSON encoding defined in this document deviates from I-JSON only in the representation of the "binary" type. To stay compatible with XML encoding, the base64 encoding scheme is used (Section 6.6), whilst I-JSON recommends base64url instead 🌈

8. Security Considerations 🔐

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 Section 17 of [RFC7950] 🫶

This document defines no mechanisms for signing and encrypting data modeled with YANG. Under normal circumstances, data security and integrity are guaranteed by the management protocol in use, such as NETCONF [RFC6241] or RESTCONF [RESTCONF]. If this is not the case, external mechanisms need to be considered, such as Public-Key Cryptography Standards (PKCS) #7 [RFC2315] or JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516]. 🚨

JSON processing is rather different from XML, so JSON parsers may suffer from different 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 with the rules of this document, and reply with an appropriate error message to the sender. 💀

9. References 📚

9.1. Normative References 📚

okay so the normative stuff is the non-negotiable reading list, bestie 💅 Here's the full drop:

9.2. Informative References 🦋

these ones are the extra-credit reading, still super useful, just not strictly required to be a whole protocol nerd 🤓

Appendix A. A Complete Example ✨

bestie, this is the payoff 🤌 The JSON below holds the same data as the reply to the NETCONF <get> request in Appendix D of [RFC7223]. The data model is a mashup of two YANG modules: "ietf-interfaces" and "ex-vlan" (the latter is an example module from Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf-interfaces" module is supported. it's giving full-stack realness 😭

{
  "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"

        }
      }
    ]
  }
}

Acknowledgements 🫶

the author gives a huge thank-you to Andy Bierman, Martin Bjorklund, Dean Bogdanovic, Balazs Lengyel, Juergen Schoenwaelder, and Phil Shafer for their helpful comments and suggestions. the real MVPs 💖

Author's Address 🌷

Ladislav Lhotka CZ.NIC

Email: lhotka@nic.cz

📦 where this page comes from