| Internet-Draft | YANG Schema Comparison | October 2025 |
| Andersson, et al. | Expires 12 April 2026 | [Page] |
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm.¶
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 12 April 2026.¶
Copyright (c) 2025 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.¶
{ 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.¶
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 [I-D.ietf-netmod-yang-module-versioning]. 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.¶
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?¶
{ 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.¶
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.¶
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 [RFC7950] and [I-D.ietf-netmod-yang-module-versioning] , both of these schemas would be required. Similarly for YANG 1.0, the rules in [RFC6020] . 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 [I-D.ietf-netmod-yang-semver] document.¶
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.¶
This document makes use of the following terminology introduced in the YANG 1.1 Data Modeling Language [RFC7950]:¶
schema node¶
This document uses terminology introduced in the YANG versioning requirements document [I-D.ietf-netmod-yang-versioning-reqs].¶
This document makes of the following terminology introduced in the YANG Packages [I-D.ietf-netmod-yang-packages]:¶
In addition, this document defines the terminology:¶
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:¶
After the compilation the result is still a valid YANG module without the following statements:¶
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:¶
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.¶
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.¶
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.¶
Every change is classified as either backwards-compatible or non-backwards-compatible based on sections 3.1.1 and 3.1.2 in [I-D.ietf-netmod-yang-module-versioning]. But, there are cases when it is impossible for tooling to determine whether a change is backwards-compatible or not. The affected statements are:¶
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.¶
The `yanglint` tool from the libyang library is able to generate the `ietf-schema-comparison` YANG data of two revisions of a 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 [RFC6991] and "ietf-yang-library" module defined in [RFC8525].¶
<CODE BEGINS> file "ietf-schema-comparison@2025-10-09.yang"
module ietf-schema-comparison {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schema-comparison";
prefix schema-cmp;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data types";
}
import ietf-yang-library {
prefix yanglib;
reference
"RFC 8525: YANG Library";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG List: NETCONF WG list <mailto:netmod@ietf.org>
WG Web: https://datatracker.ietf.org/wg/netmod
Author: Michal Vaško
<mailto:mvasko@cesnet.cz>
Author: Rob Wilton
<mailto:rwilton@cisco.com>
Author: Per Andersson
<mailto:per.ietf@ionio.se>";
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;
}
}
}
}
}
<CODE ENDS>¶
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:¶
The ideas for a tooling based comparison of YANG module revisions was first described in [I-D.clacla-netmod-yang-model-update]. This document extends upon those initial ideas.¶
This section follows the template defined in Section 3.7.1 of [RFC8407].¶
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 [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] 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.¶
This document register one URI in the "ns" subregistry of the IETF XML Registry [RFC3688] maintained at https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. Following the format in [RFC3688], 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.¶
This document registers one YANG module in the YANG Module Names registry [RFC6020] maintained at https://www.iana.org/assignments/yang-parameters/yang-paramaters.xhtml. Following the format defined in [RFC6020], 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¶