YANG Versioning Solution Overview

In summary, specifies minimal extensions and updates to the YANG language, YANG Library, and YANG author guidelines to provide more flexible YANG module revision handling. The intent is that these changes and extensions could be folded into future revisions of the updated specifications. The document provides a base solution for all requirements except Req 2.2, Req 3.1 and Req 3.2. The extensions and changes in the document can be summarized thus: It defines a YANG extension statement to indicate where non-backwards-compatible changes have occurred in a module's revision history. It relaxes the rules for the module revision history to allow for a non-linear module revision history. I.e., any given module revision may have multiple revisions directly derived from it. It defines a new import extension statement that restricts the allowed module revisions that satisfy the import to only those derived from a specified module revision. It defines a revision label extension statement to allow an informative name to be associated with a particular revision date, and to be used in import statements, YANG module filenames, and is available in YANG library. One example of how the revision label could be used is to associate a semantic versioning scheme to YANG module revisions. It updates the YANG rules for changes between module revisions that are allowed to be classified as backwards-compatible. In particular, marking a node as obsolete is no longer classified as a backwards compatible change. It provides updated guidance on how servers handle deprecated and obsolete YANG nodes and augments YANG library with additional leaves to report the server's behavior to clients. It provides an extension statement to allow a description statement to be associated with a YANG status statement, providing more information about why the status has changed. It defines how versioning relates to YANG instance data. It refines the guidelines for updating modules, taking into consideration that non-backwards-compatible changes are sometimes necessary for various pragmatic reasons.

defines a semantic versioning scheme, derived from the semver.org 2.0.0 specification, that can be used in conjunction with the revision label extension statement defined in to allow semantic version numbers to be used to manage the revision lifecycle of YANG modules and other related YANG assets, e.g., YANG packages. This document provides an enhanced solution for Req 2.1, but organizations authoring modules are not obliged to use this specific versioning scheme, and could choose a different overlaid versioning scheme, or none at all and rely solely on revision dates. The aims of the YANG semantic versioning scheme are: to generally allow clients to determine whether NBC changes have occurred between two revisions from the version number alone, without having to check the full revision history; to give a more informative identifier for a branched revision history over revision dates alone; to allow revision branches that contain fixes for published non-latest releases.

The two previous solution documents primarily address version and revision management of individual modules. provides a mechanism to group sets of related YANG modules revisions together, into constructs called YANG packages, and to apply a versioning scheme to the groups. The core part of this document are YANG module definitions that define a YANG package. The definitions are used as an augmentation to YANG library and also in YANG instance data documents for offline access. The principle aims of YANG packages are: To define an efficient hierarchical structure that can precisely specify a YANG schema. To provide an simple alternative mechanism to manage conformance of modules. Rather than checking conformance against a set of individual YANG module revisions and enabled features, it should be easier to check for conformance against a much smaller set of YANG package versions. To provide a more efficient mechanism for servers to share conformance information with clients. Rather that downloading and comparing all individual module revisions and features via YANG library, the client can just check whether the package version is compatible instead. The package definition could be retrieved and cached from multiple sources. To define constructs that can be used for YANG schema selection. Although the YANG packages document does not satisfy any versioning requirements directly, it provides foundational building blocks for the schema selection solution, described in , that does address two of the requirements.

specifies a solution for requirements 3.1 and 3.2 via the use of and a model and protocol based schema selection scheme that can be used by clients to choose which schemas to use when interacting with the device from the available schema that are supported and advertised by the server. The dynamic YANG schema selection solution: allows servers to define named 'schema-sets' which specify the schema for each supported datastore via references to YANG packages; can support clients choosing a single default schema-set (from those advertised by the server) that is used for all NETCONF/RESTCONF protocol sessions; can support clients enabling multiple compatible secondary schema-sets that can be used on separate NETCONF/RESTCONF protocol sessions; can support clients configuring named custom schema-sets that can be selected as default or secondary schema-sets; can support different module versions via placing them in different schema-sets; can support different schema families (e.g., IETF YANG modules , native vendor, or OpenConfig); allows considerable freedom in the schema selection capabilities that servers choose to support.

The final piece of the solution jigsaw is a document that describes how to algorithmically compare YANG schema, addressing Req 2.2. specifies an algorithm that can be used to compare two revisions of a YANG schema to determine the overall scope of the changes, and a list of the specific changes, between the two revisions. The YANG Schema Comparison solution: defines a algorithm for comparing two YANG schema, identifying the differences and classifying them as backwards-compatible, non-backwards-compatible or editorial; can be used to compare individual YANG module revisions; can be used to compare YANG schema defined using YANG packages; can filter the comparison output to the subset of the schema nodes that are of interest, providing a more precise answer for clients to determine whether they would likely be affected when upgrading between two schema versions; defines YANG extensions to improve the accuracy of the comparison algorithm by explicitly annotating the type of change to statements within a YANG module, for use where the type of change would otherwise be ambiguous to a simple programmatic comparison algorithm.