YANG Schema Comparison

Key Issues { This section is only to present the current ongoing work, not part of the final draft. } The contributors have identified several key issues that need attention. This section presents selected key issues which have been discussed together with suggestions for proposed solution or requirements.

On-wire vs Schema analysis Should one algorithm be used or two? The consesus reached was to define two separate algorithms, one for on-wire format and one for schema. Schema: any changes that affect the YANG schema in an NBC manner according to the full rules of . This may be important for clients that, for example, automatically generate code using the YANG and where the change of a typedef name or a choice name could be significant. Also important for other modules that may augment or deviate the schema being compared. Changes to the module that aren't semantic should raise that there has been editorial changes Ordering in the schema, RFC 7950 doesn't allow reordering; thus an NBC change. Open Questions: Groupings / uses typedefs, namespaces, choice names, prefixes, module metadata.

typedef renaming (on-wire, same base type etc)

Should all editorial (text) diffs be reported?
What about editorial changes that might change semantics, e.g. a description of a leaf?
Metadata arguments which relies on the formatted input text. E.g description, contact (etc), extension (how does the user want to tune verbosity level for editorial changes: whitespace, spelling, editorial, potentially-nbc?
XPath, must, when: don't normalize XPath expressions
presence statements

Comparison on module or full schema (YANG artifact, arbitrary blob. Questions

features
packages vs directories vs libraries vs artifact
package specific comparison, package metadata or only looking at the modules
import only or implemented module

Filter out comparison for a specific subrtree, path etc. Use case for on-wire e.g. yang subscriptions, did the model change fro what is subscribed on?

Open Issues { This section is only to present the current ongoing work, not part of the final draft. } The following issues have not ben discussed in any wider extent yet.

Override/per-node tags

Separate rules for config vs state

Tool/report verbosity

where to report changes (module, grouping, typedef, uses)
output level (conceptual level or exact strings)
granularity: error/warning/info level per reported change category

sub-modules

Write algorithm in pseudo code or just describe the rules/goals in text?

Categories in the report: bc, nbc, potentially-nbc, editorial. Allow filtering in the draft without defining it? One option can be to have a tool option that presents the reason behind the decision, e.g. --details could be used to explain to the user why a certain change was marked as nbc. Another option is to present reasoning and analysis in deeper levels of verbosity; e.g. one extra level of verbosity, -v, could present the reason for categorizing a change nbc, and an additional extra level of verbosity, e.g. -vv, could also present the detailed analysis the tool made to categorize the change.

Only for YANG 1.1?

Introduction This document defines the algorithm for comparing two revisions of a YANG schema. There are two kinds of YANG schemas: on-the-wire or compiled schema and text or parsed schema. The compiled schema is what tools use when working with any kinds of YANG data. Generally, in all the YANG modules, all the schema nodes need to be fully resolved and have their final form. For example, every "uses" statement is replaced with the nodes from the corresponding "grouping", every type referencing a "typedef" is replaced with the type of the "typedef" and so on. On the other hand, the parsed schema is comprised of all the YANG modules together as they are. That means no statements are resolved and they remain in exactly the same text form as present in the YANG modules. For determining whether a new revision of a YANG 1.1 module is or is not backwards-compatible based on all the rules in and , both of these schemas would be required. Similarly for YANG 1.0, the rules in . This document defines only the algorithm for comparing the compiled schema. The output of this algorithm can be utilized by tools processing YANG instance data to determine what exact changes should they expect and even how to transform instance data valid for an old revision of a YANG module to be valid for a newer revision of the same YANG module. Such tools are typically clients or servers of YANG-driven protocols, e.g. NETCONF, RESTCONF, or gNMI. In addition, the comparison algorithm can assist YANG module authors with updating their modules and be used to verify the semantic version of the new revision of the YANG module based on the document.

Terminology and Conventions 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 when, and only when, they appear in all capitals, as shown here. This document makes use of the following terminology introduced in the YANG 1.1 Data Modeling Language : schema node This document uses terminology introduced in the YANG versioning requirements document . This document makes of the following terminology introduced in the YANG Packages :

YANG schema

In addition, this document defines the terminology:

Change scope: Whether a change between two revisions is classified as non-backwards-compatible or backwards-compatible.
Node compatibility statement: An extension statements (e.g. nbc-change-at) that can be used to indicate the backwards compatibility of individual schema nodes and specific YANG statements.

Compiled YANG schema tree The compiled schema tree resolves all the statements used for syntactic abstraction and simplification to obtain one schema node tree with only data definition statements. Textual fields are kept as well because they may affect backwards compatibility of the whole YANG module. The steps taken when compiling a schema:

'Import' statements are resolved by finding the referenced YANG modules and making their contents available.
All submodules of a single module are merged to create one large YANG module.
'Uses' statements are replaced by the referenced 'groupings' and the YANG nodes they define.
'Types' referencing any 'typedef' statements are replaced with the actual type details.
'Augments' are resolved by placing the included YANG nodes in their targets.
'Deviation' and 'refine' statements are applied by changing the appropriate schema nodes.
All the 'if-feature' statements are evaluated based on the enabled 'features' of implemented YANG modules and the disabled schema nodes are removed.

After the compilation the result is still a valid YANG module without the following statements:

import
include
revision
typedef
grouping
augment
deviation
feature
if-feature
refine
extension

Compiled YANG schema tree comparison algorithm This algorithm is defined for separate compiled YANG modules. It first compares all the non data-definition statements in the module and then all the data-definition statements recursively. These schema-only statements are skipped:

choice
case

The non data-definition statements are considered modified when their content is changed or any of their substatements are changed. If a statement is present in the old revision of a module and missing in the new revision, it is considered removed. Vice-versa, if missing in the old revision but present in the new revision, it is considered added. Data-definition statements are compared similarly except that a change in a descendant data-definition statement is not considered a change of the parent data-definition statement but a separate change instead. Only statements with any changes are reported and included in the algorithm output.

Module identification When generating the comparison output of two compiled YANG modules, it includes unique identification of the modules in question. For both the old and the new revision of the module, its name, revision, list of submodules, and a leaf-list of enabled features is included. In addition, the same information is reported for all the imported YANG modules, recursively. This ensures that if any other output is produced with a different set of changes for two YANG modules, their identification information must also differ.

Change content Non-data-definition statements are uniquely identified with their YANG identifier and data-definition statements with their absolute schema data node-ids. For every change, the changed statement and the parent of the changed statement are included. While redundant in many cases, it allows to uniquely report changes in nested statements, e.g. an extension instance change in the type of a leaf statement. Also, all the substatements with their value or content are included for every changed statement, for both older and newer revision of the YANG module, if applicable. This ensures that the output includes all the possibly required information without relying on learning it from the YANG modules themselves.

Change conformance Every change is classified as either backwards-compatible or non-backwards-compatible based on sections 3.1.1 and 3.1.2 in . But, there are cases when it is impossible for tooling to determine whether a change is backwards-compatible or not. The affected statements are:

pattern
when
must
description
extension instance

Normally, any change in these statement is reported as non-backwards-compatible. However, if the author of the new revision of a YANG module determines that the change of an aforementioned statement is backwards-compatible based on the compatibility rules for the specific statement, they can decide to use the 'schema-cmp:backwards-compatible' extension to signify this fact. Then, this change must be reported as backwards-compatible.

Comparison tooling The `yanglint` tool from the libyang library is able to generate the `ietf-schema-comparison` YANG data of two revisions of a YANG module.

Schema Comparison YANG Module YANG module with nodes describing the differences between two revisions of compiled YANG modules. The "ietf-schema-comparison" YANG module imports definitions from the "ietf-yang-types" module defined in and "ietf-yang-library" module defined in . WG Web: https://datatracker.ietf.org/wg/netmod Author: Michal Vaško Author: Rob Wilton Author: Per Andersson "; description "This YANG 1.1 module contains definitions and extensions to support comparison between different versions of YANG modules. The output of the comparison algorithm is described in this YANG module. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. // RFC Ed.: replace XXXX (inc above) with actual RFC number and // remove this note. revision 2025-10-09 { description "Initial revision."; reference "RFC XXXX: YANG Schema Comparison"; } extension backwards-compatible { description "Marks statements in a new revision of a module that were changed but in a backwards-compatible manner according to YANG 1.1 and 1.0 rules for updating a module. When used as a substatement of a 'pattern' statement, it means its allowed value space has been expanded. When used as a substatement of a 'when' or 'must' statement, it means their constraint has been relaxed. When used as a substatement of a 'description' statement, it means it has been changed in a backwards-compatible way. When used as a substatement of an extension instance, it means adding, modifying, or removing it is a backwards-compatible change. Not allowed to be instiantiated for any other statements."; reference "RFC 7950: The YANG 1.1 Data Modeling Language, section 11; RFC 6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF), section 10"; } typedef data-path { type string; description "Used for any data paths and XPath expressions in the compared YANG modules. A generic type is used to not enforce their evaluation or validation in this context."; } typedef stmt-type { type enumeration { enum "base"; enum "bit"; enum "config"; enum "contact"; enum "default"; enum "description"; enum "enum"; enum "error-app-tag"; enum "error-message"; enum "extension-instance"; enum "fraction-digits"; enum "identity"; enum "length"; enum "mandatory"; enum "max-elements"; enum "min-elements"; enum "must"; enum "node"; enum "ordered-by"; enum "organization"; enum "path"; enum "pattern"; enum "presence"; enum "range"; enum "reference"; enum "require-instance"; enum "status"; enum "type"; enum "units"; enum "unique"; enum "when"; } description "Type of the statement that a change affects."; } typedef revision-or-empty { type union { type empty; type yanglib:revision-identifier; } description "Module or submodule revision. If it has none, an empty value is used."; } grouping ext-instance-changes { description "Describes an extension-instance statement change."; leaf module { type yang:yang-identifier; mandatory true; description "Module with the extension definition of an extension instance."; } leaf name { type yang:yang-identifier; mandatory true; description "Name of the extension defition of an extension instance."; } leaf argument { type string; description "Argument used of an extension definition."; } anydata substatements { description "Any substatements of the extension instance."; } } grouping status-changes { description "Describes a status statement change."; leaf status { type enumeration { enum "current"; enum "deprecated"; enum "obsolete"; } mandatory true; description "Status substatement value."; } } grouping must-changes { description "Describes a must statement change."; leaf condition { type data-path; description "Condition substatement value."; } leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } leaf error-message { type string; description "Error-message substatement value."; } leaf error-app-tag { type string; description "Error-app-tag substatement value."; } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping when-changes { description "Describes a when statement change."; leaf condition { type data-path; description "Condition substatement value."; } leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } uses status-changes; list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping restriction-substmts { description "Common substatements shared by all restriction statements."; leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } leaf error-message { type string; description "Error-message substatement value."; } leaf error-app-tag { type string; description "Error-app-tag substatement value."; } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping type-changes { description "Describes a type statement change."; leaf base-type { type enumeration { enum "int8"; enum "int16"; enum "int32"; enum "int64"; enum "uint8"; enum "uint16"; enum "uint32"; enum "uint64"; enum "decimal64"; enum "string"; enum "boolean"; enum "enumeration"; enum "bits"; enum "binary"; enum "leafref"; enum "identityref"; enum "empty"; enum "union"; enum "instance-identifier"; } description "Type substatement value."; } container range { description "Range statement substatements."; list interval { description "Intervals of a range statement."; leaf min { type int64; description "Lower boundary of an interval of a range statement."; } leaf max { type int64; description "Upper boundary of an interval of a range statement."; } } uses restriction-substmts; } container length { description "Length statement substatements."; list interval { description "Intervals of a length statement."; leaf min { type uint64; description "Lower boundary of an interval of a length statement."; } leaf max { type uint64; description "Upper boundary of an interval of a length statement."; } } uses restriction-substmts; } leaf fraction-digits { type uint8; description "Fraction-digits substatement value."; } list pattern { leaf expression { type string; description "Pattern substatement value."; } leaf inverted { type boolean; description "Inverted substatement value."; } uses restriction-substmts; } list enum { key "name"; description "List of enum statements."; leaf name { type yang:yang-identifier; description "Enum statement name."; } leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } leaf value { type int32; description "Value substatement value."; } uses status-changes; list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } list bit { key "name"; leaf name { type yang:yang-identifier; } leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } leaf position { type uint32; description "Position substatement value."; } uses status-changes; list ext-instance { description "List of extension-sintance substatements."; uses ext-instance-changes; } } leaf path { type data-path; description "Path substatement value."; } leaf require-instance { type boolean; description "Require-instance substatement value."; } leaf-list base { type yang:yang-identifier; description "List of base substatement values."; } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping node-changes { leaf config { type boolean; description "Config substatement value."; } leaf description { type string; description "Description substatement value."; } leaf mandatory { type boolean; description "Mandatory substatement value."; } list must { description "List of must substatements."; uses must-changes; } leaf presence { type boolean; description "Presence substatement existence."; } leaf reference { type string; description "Reference substatement value."; } uses status-changes; list when { description "List of when substatements."; uses when-changes; } container type { description "Type substatement."; uses type-changes; list union-type { description "List of a union type substatements."; uses type-changes; } } leaf units { type string; description "Units substatement value."; } leaf ordered-by { type enumeration { enum "system"; enum "user"; } description "Ordered-by substatement value."; } leaf-list default { type string; description "List of default substatement values."; } leaf min-elements { type uint32; description "Min-elements substatement value."; } leaf max-elements { type uint32; description "Max-elements substatement value."; } list unique { description "List of unique substatements."; leaf-list node { type yang:yang-identifier; description "List of nodes referenced by a unique substatement."; } } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping module-changes { leaf organization { type string; description "Organization substatement value."; } leaf contact { type string; description "Contact substatement value."; } leaf description { type string; description "Description substatement value."; } leaf reference { type string; description "Reference substatement value."; } list identity { key "name"; description "List of identity substatements."; leaf name { type yang:yang-identifier; description "Identity statement name."; } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } list ext-instance { description "List of extension-instance substatements."; uses ext-instance-changes; } } grouping conformance-type { leaf conformance { type enumeration { enum "backwards-compatible"; enum "non-backwards-compatible"; } mandatory true; description "Conformance information of a change in the compared YANG modules."; } } grouping change-info { list changed { key "stmt"; min-elements 1; description "List of changes."; leaf stmt { type stmt-type; description "Changed statement."; } leaf parent-stmt { type stmt-type; description "Parent statement of the changed statement."; } leaf change { type enumeration { enum "modified" { description "Statement existed and was modified."; } enum "added" { description "Statement was added."; } enum "removed" { description "Statement was removed."; } enum "moved" { description "Statement was moved and the position affects the meaning."; } } mandatory true; description "Type of change of the statement."; } uses conformance-type; } } grouping module-params { leaf module { type yang:yang-identifier; mandatory true; description "Compared module name."; } leaf revision { type revision-or-empty; mandatory true; description "Compared module revision."; } list submodule { key "name revision"; leaf name { type yang:yang-identifier; mandatory true; description "Submodule name."; } leaf revision { type revision-or-empty; mandatory true; description "Submodule revision."; } description "Submodule of the main module."; } leaf-list enabled-feature { type yang:yang-identifier; description "All the enabled features of the module."; } } container schema-comparison { config false; description "Schema comparison details."; list compiled-diff { description "Instance of a schema comparison of two YANG modules in different revisions with all their imports."; container source { description "Source module information."; uses module-params; } list source-import { key "module revision"; description "List of source module imported modules information."; uses module-params; } container target { description "Target module information."; uses module-params; } list target-import { key "module revision"; description "List of target module imported modules information."; uses module-params; } uses conformance-type; container module-diff { description "Information about direct module statement substatement changes."; uses change-info; container old { description "Changed statements in the older revision of the YANG module."; uses module-changes; } container new { description "Changed statements in the newer revision of the YANG module."; uses module-changes; } } list node-diff { key "node"; description "Information about data-definition (node) statement substatement changes."; leaf node { type data-path; description "Path to the changed data-definition statement."; } leaf node-type { type enumeration { enum "container"; enum "leaf"; enum "leaf-list"; enum "list"; enum "anydata"; enum "anyxml"; enum "rpc"; enum "action"; enum "notification"; } mandatory true; description "Type of the changed data-definition statement."; } leaf in-rpc-action { type enumeration { enum "input"; enum "output"; } description "Present if the changed data-definition statement is a descendant of an action or rpc statement."; } uses change-info; container old { description "All the node substatements in the older revision of the YANG module."; uses node-changes; } container new { description "All the node substatements in the newer revision of the YANG module."; uses node-changes; } } } } } ]]>

Contributors This document grew out of the YANG module versioning design team that started after IETF 101. The following individuals are (or have been) members of the design team and have worked on the YANG versioning project:

Balazs Lengyel
Benoit Claise
Bo Wu
Ebben Aries
Jason Sterne
Joe Clarke
Juergen Schoenwaelder
Mahesh Jethanandani
Michael Wang
Qin Wu
Reshad Rahman
Rob Wilton
Jan Lindblad
Per Andersson

The ideas for a tooling based comparison of YANG module revisions was first described in . This document extends upon those initial ideas.

Security Considerations This section follows the template defined in Section 3.7.1 of . The YANG module specified in this document defines a schema for data that is designed to be used by offline tooling to generate output for differences in supplied YANG modules. The YANG module specifiod in this document MAY be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. When the module is used for offline tooling there are no security considerations, since the user has full access to all YANG modules used. The container "schema-comparison" contains all the groupings reflecting the changes between YANG modules. If this data node is published in online tooling, care needs to be taken so that knowledge of YANG modules are not leaked. Since the modules does not define any RPCs or actions or notifications, and thus the security considerations for such are not provided here.

IANA Considerations

The "IETF XML" Registry This document register one URI in the "ns" subregistry of the IETF XML Registry maintained at . Following the format in , the following registration is requested:

URI: urn:ietf:params:xml:ns:yang:ietf-schema-comparison Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.

The "YANG Module Names" Registry This document registers one YANG module in the YANG Module Names registry maintained at . Following the format defined in , the below registration is requested:

Name: ietf-schema-comparison XML Namespace: urn:ietf:params:xml:ns:yang:ietf-schema-comparison Prefix: schema-cmp Reference: RFC XXXX