JSON Encoding of Data Modeled with YANG
Extracted elements (27)
64-bit numeric types (int64, uint64, decimal64) are encoded as JSON strings rather than numbers because I-JSON (RFC 7493, Section 2.2) recommends encoding numbers outside the IEEE 754-2008 double-precision range as strings to guarantee reliable exchange across implementations.
The 'empty' type is encoded as '[null]' rather than bare JSON null to facilitate use in common programming languages where a null-valued object member is treated as absent. This preserves the ability to distinguish an 'empty' leaf's presence from its absence.
The JSON encoding follows the I-JSON restricted profile as closely as possible to maximize interoperability across diverse JSON encoder/decoder implementations, accepting the single deviation of base64 vs base64url for binary data to maintain XML compatibility.
Unlike XML encoding where list key order is mandated, JSON-encoded list entries have arbitrary member ordering because JSON objects are fundamentally unordered collections; therefore the XML key-ordering constraint is not imposed on JSON.
Except for anyxml and schema-less anydata nodes, bidirectional conversion between JSON and XML encoding is possible but requires the YANG data model to be available at conversion time.
For the 'union' type, the JSON encoding imposes stricter type constraints than XML: a floating-point JSON number like 13.5 cannot be assigned to a union{uint16, string} leaf even though the XML encoding '<bar>13.5</bar>' would be accepted as a string.
The JSON encoding deviates from I-JSON in one way: the 'binary' type uses standard base64 (not base64url) for XML compatibility. All other I-JSON properties — UTF-8, unique member names, order-independence, reliable number exchange — are satisfied.
With the exception of 'anydata' encoding, all rules in this document are also applicable to YANG 1.0 (RFC 6020), enabling backward compatibility with older YANG models.
A JSON object member name MUST be in one of two forms: simple (identical to the YANG data node identifier) or namespace-qualified (module name prefixed with ':' separator). A namespace-qualified member name MUST be used for all members of a top-level JSON object and whenever the namespaces of the data node and its parent node differ.
An anyxml instance value MUST satisfy I-JSON constraints (RFC 7493).
An 'identityref' value that references an identity defined in a module other than the leaf containing the identityref MUST use the namespace-qualified form (module-name:identity-name).
Character encoding MUST be UTF-8 for all JSON-encoded YANG data.
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, in order to minimize security risks from malformed JSON.
The ordering of leaf-list and list array elements MUST observe the 'ordered-by' properties as defined in Section 7.7.7 of RFC 7950, following the same rules as XML encoding.
When validating a value of the 'union' type, the type information conveyed by the JSON encoding MUST also be taken into account, providing additional means for resolving the member type beyond what XML encoding offers.
Every YANG data node instance is encoded as a JSON name/value pair. Containers encode as name/object pairs, leaf-lists as name/array pairs (scalar elements), lists as name/array pairs (object elements), and leaves as name/scalar pairs.
Metadata objects are JSON object members whose name starts with '@' (COMMERCIAL AT). Their exact syntax and semantics are outside the scope of this document but are used for encoding metadata per RFC 7952.
The anydata data node is encoded as a name/object pair (same as container). Its JSON content must be valid I-JSON, have member names matching the ABNF production, contain arrays of only unique scalars or only objects, and use '[null]' only for the 'empty' type encoding.
JSON parsers may suffer from different vulnerability classes than XML parsers. Receivers SHOULD reject all non-compliant messages and return an appropriate error, minimizing attack surface from malformed or adversarial JSON input.
This document introduces no new security issues beyond those in RFC 7950 Section 17. No signing or encryption mechanisms are defined; data security relies on the management protocol (NETCONF, RESTCONF), or external mechanisms such as PKCS#7 or JOSE if the protocol does not provide it.
The 'binary' YANG type is encoded as a base64-encoded JSON string. This deviates from the I-JSON recommendation of base64url, chosen for compatibility with XML encoding.
The 'bits' YANG type is encoded as a JSON string containing a space-separated sequence of the names of bits that are set.
The 'boolean' YANG type is represented as the JSON literal 'true' or 'false'. The 'string' type maps directly to a JSON string. The 'enumeration' type is encoded as the JSON string name of the assigned enum.
The 'empty' YANG type is encoded as the single-element JSON array '[null]', not as a bare JSON null, to avoid confusion in programming languages that treat null members as absent.
The 'instance-identifier' type is encoded as a string analogous to the XML lexical representation, but namespace prefixes follow the JSON module-name rules of Section 4: the top-level node name is always namespace-qualified; subsequent names are qualified only when the node's module differs from its parent.
The 'int64', 'uint64', and 'decimal64' YANG types are encoded as JSON strings (not numbers) containing the lexical representation, to avoid precision loss beyond the IEEE 754-2008 double-precision range.
The 'int8', 'int16', 'int32', 'uint8', 'uint16', and 'uint32' YANG types are encoded as JSON numbers.