Normalized Representation of YANG Data for Equivalence Evaluation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 25 April 2027.¶

Copyright Notice

Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

YANG is widely used to model configuration data, operational state, notifications, and other information exchanged between network management systems.¶

Data modeled using YANG can be represented through different encodings, including XML, JSON, and CBOR. Furthermore, equivalent YANG-modeled information may be serialized differently by distinct implementations due to representation-specific conventions, ordering choices, or encoding mechanisms.¶

These differences make it difficult to determine whether two representations convey the same information. As a result, operations such as datastore comparison, data deduplication, fingerprint generation, integrity verification, provenance processing, and message-broker compaction often depend on representation-specific artifacts rather than on the underlying information itself.¶

Existing canonicalization mechanisms operate at the encoding level. For example, XML, JSON, and CBOR provide independent procedures for producing deterministic encodings of individual documents. However, these mechanisms do not address the broader problem of obtaining a common representation across different encodings.¶

This document defines a normalization procedure for YANG-modeled information that produces a deterministic representation independent of the original encoding. The procedure enables equivalent YANG-modeled information to converge into the same normalized representation, providing a stable basis for comparison, fingerprint generation, integrity verification, and other operational uses.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

• Representation: A concrete serialized einstance of YANG-modeled data. Examples include XML, JSON, and CBOR encodings conveying the same underlying information.¶

• Normalized Representation: A deterministic representation generated by the normalization procedure defined in this document.¶

• Representation Equivalence: Two representations are representation-equivalent when they produce identical normalized representations.¶

• Fingerprint: A cryptographic digest calculated from a normalized representation.¶

• Schema-Independent Normalization: A normalization procedure that does not require access to the corresponding YANG schema during processing.¶

• Semantic Equivalence: The property whereby two representations correspond to the same YANG-modeled information after considering all schema-dependent semantics.¶

3. Problem Statement

YANG-modeled data can be represented using different encodings, including XML [RFC7950], JSON [RFC7951], and CBOR [RFC9254].¶

Existing canonicalization mechanisms operate within a particular encoding and produce deterministic representations of individual documents. Examples include XML Canonicalization (XML-C14N), the JSON Canonicalization Scheme (JCS) [RFC8785], and the deterministic encoding rules defined for CBOR [RFC8949].¶

These mechanisms enable a representation expressed using a particular encoding to be transformed into a deterministic byte sequence. However, they do not provide a common representation across different encodings, nor do they necessarily address all representation variations that may arise from encoding rules or implementation choices.¶

Ordering is one possible source of such variation. These differences may arise from implementation choices, internal datastore representations, module augmentations, or serialization procedures.¶

For example, one implementation may produce:¶

<aaa>
  <bbb/>
  <ccc/>
  <ddd/>
</aaa>

while another implementation may produce:¶

<aaa>
  <ddd/>
  <bbb/>
  <ccc/>
</aaa>

If the order of these nodes is not semantically significant, both serialized representations convey equivalent information despite having different element ordering and byte sequences.¶

As a result, equivalent YANG-modeled information may produce different serialized representations and therefore different fingerprints, hashes, or signatures. Direct comparison of serialized representations cannot reliably determine whether two representations convey the same information.¶

A normalization procedure operating above the encoding-specific representation layer is therefore needed to enable representation-independent comparison of YANG-modeled data.¶

4. Normalization Procedure

The normalization procedure takes a serialized YANG data document as input and produces a deterministic normalized representation.¶

       Serialized YANG Data Document
             XML / JSON / CBOR
                      |
                      v
          Encoding-Specific Parsing
                      |
                      v
            Abstract Data Tree
                      |
                      v
       Identifier and Value Processing
                      |
                      v
     Deterministic Subtree Encoding
                      |
                      v
            Child Node Sorting
                      |
                      v
       Normalized Byte Representation
                      |
                      v
    Comparison / Hashing / Signing /...

5. Examples

This section illustrates how equivalent YANG-modeled data represented using different serialization formats and encodings can produce the same normalized representation. The following XML and JSON representations examples are based on the interface data model originally defined in [RFC7223] and convey equivalent information.¶

<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:iana-if-type="urn:ietf:params:xml:ns:yang:iana-if-type"
    xmlns:vlan="http://example.com/vlan">
  <interface>
    <name>eth0</name>
    <type>iana-if-type:ethernetCsmacd</type>
    <enabled>false</enabled>
  </interface>
  <interface>
    <name>eth1</name>
    <type>iana-if-type:ethernetCsmacd</type>
    <enabled>true</enabled>
    <vlan:vlan-tagging>true</vlan:vlan-tagging>
  </interface>
  <interface>
    <name>eth1.10</name>
    <type>iana-if-type:l2vlan</type>
    <enabled>true</enabled>
    <vlan:base-interface>eth1</vlan:base-interface>
    <vlan:vlan-id>10</vlan:vlan-id>
  </interface>
  <interface>
    <name>lo1</name>
    <type>iana-if-type:softwareLoopback</type>
    <enabled>true</enabled>
  </interface>
</interfaces>

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "enabled": true,
        "name": "lo1",
        "type": "iana-if-type:softwareLoopback"
      },
      {
        "vlan:vlan-id": 10,
        "enabled": true,
        "type": "iana-if-type:l2vlan",
        "vlan:base-interface": "eth1",
        "name": "eth1.10"
      },
      {
        "enabled": false,
        "type": "iana-if-type:ethernetCsmacd",
        "name": "eth0"
      },
      {
        "vlan:vlan-tagging": true,
        "name": "eth1",
        "enabled": true,
        "type": "iana-if-type:ethernetCsmacd"
      }
    ]
  }
}

The following non-normative textual tree illustrates the intended outcome: equivalent XML, JSON, and CBOR representations are expected to produce the same normalized representation.¶

interfaces
├─ interface
│  ├─ enabled = true
│  ├─ name = lo1
│  └─ type = iana-if-type:softwareLoopback
├─ interface
│  ├─ enabled = false
│  ├─ name = eth0
│  └─ type = iana-if-type:ethernetCsmacd
├─ interface
│  ├─ enabled = true
│  ├─ name = eth1
│  ├─ type = iana-if-type:ethernetCsmacd
│  └─ vlan-tagging = true
└─ interface
   ├─ base-interface = eth1
   ├─ enabled = true
   ├─ name = eth1.10
   ├─ type = iana-if-type:l2vlan
   └─ vlan-id = 10

6. Relationship to Existing Work

The normalization procedure defined in this document is intended to complement existing efforts related to the processing, identification, and distribution of YANG-modeled information.¶

The YANG provenance mechanisms defined in [I-D.ietf-opsawg-yang-provenance] operate on serialized representations of YANG data and can benefit from a stable, representation-independent normalization procedure capable of producing equivalent representations across different serialization formats.¶

Similarly, work related to message broker identification and key generation for YANG-modeled information, such as [I-D.ietf-nmop-yang-message-broker-message-key], may benefit from a normalization procedure that produces stable representations for equivalent information independently of their original encoding.¶

This document does not modify or replace such mechanisms. Instead, it provides a potential foundation that can be used by higher-level procedures requiring consistent representation of equivalent YANG-modeled information.¶

7. Security Considerations

The normalization procedure defined in this document is intended to provide a deterministic representation of YANG-modeled data. It does not, by itself, provide integrity, authenticity, confidentiality, or provenance guarantees.¶

Security properties may be obtained by applying appropriate mechanisms, such as cryptographic hash functions, digital signatures, or provenance procedures, to the resulting normalized representation. Implementations relying on the normalized representation for integrity verification or provenance applications MUST use cryptographically secure algorithms appropriate for the intended use case. Incorrect normalization procedures may result in different representations producing the same normalized output or in equivalent information producing different normalized representations. Such situations may negatively affect comparison, fingerprint generation, and verification procedures.¶

8. IANA Considerations

This document has no IANA actions.¶

9. Implementation status

An open-source reference implementation, written in Java, is available at https://github.com/tefiros/yang-data-normalization.¶

10. References

Acknowledgments

This document is based on work partially funded by the EU Horizon Europe projects CYBERNEMO (grant 101168182) and 3C4AI (grant 101298630).¶

Authors' Addresses