Network Working Group                                     J. Clarke, Ed.
Internet-Draft                                            R. Wilton, Ed.
Updates: 8407 (if approved)                          Cisco Systems, Inc.
Intended status: Standards Track                               R. Rahman
Expires: 28 April 12 May 2022
                                                              B. Lengyel
                                                               J. Sterne
                                                               B. Claise
                                                         25 October
                                                         8 November 2021

                        YANG Semantic Versioning


   This document specifies a scheme and guidelines for applying an
   extended set of semantic versioning rules to revisions of YANG
   artifacts (e.g., modules and packages).  Additionally, this document
   defines an RFCAAAA-compliant revision-label-scheme for this YANG
   semantic versioning scheme.

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

   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 28 April 12 May 2022.

Copyright Notice

   Copyright (c) 2021 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 (
   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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   3
   3.  YANG Semantic Versioning  . . . . . . . . . . . . . . . . . .   3
     3.1.  YANG Semver Pattern . . . . . . . . . . . . . . . . . . .   4
     3.2.  Semantic Versioning Scheme for YANG Artifacts . . . . . .   4
       3.2.1.  YANG Semver with submodules . . . . . . . . . . . . .   7
       3.2.2.  Examples for YANG semantic versions . . . . . . . . .   7
     3.3.  YANG Semantic Version Update Rules  . . . . . . . . . . .   9
     3.4.  Examples of the YANG Semver Label . . . . . . . . . . . .  11
       3.4.1.  Example Module Using YANG Semver  . . . . . . . . . .  11
       3.4.2.  Example of Package Using YANG Semver  . . . . . . . .  13
   4.  Import Module by Semantic Version . . . . . . . . . . . . . .  13
   5.  Guidelines for Using Semver During Module Development . . . .  14
     5.1.  Pre-release Version Precedence  . . . . . . . . . . . . .  15
     5.2.  YANG Semver in IETF Modules . . . . . . . . . . . . . . .  15  16
   6.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  18  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  YANG Module Registrations . . . . . . . . . . . . . . . .  19  20
     9.2.  Guidance for YANG Semver in IANA maintained YANG modules
           and submodules  . . . . . . . . . . . . . . . . . . . . .  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21  22
   Appendix A.  Example IETF Module Development  . . . . . . . . . .  22  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   [I-D.ietf-netmod-yang-module-versioning] puts forth a number of
   concepts relating to modified rules for updating modules and
   submodules, a means to signal when a new revision of a module or
   submodule has non-backwards-compatible (NBC) changes compared to its
   previous revision, and a scheme that uses the revision history as a
   lineage for determining from where a specific revision of a YANG
   module or submodule is derived.  Additionally, section 3.4 of

   [I-D.ietf-netmod-yang-module-versioning] defines a revision-label
   which can be used as an alias to provide additional context or as a
   meaningful label to refer to a specific revision.

   This document defines a revision-label scheme that uses extended
   [semver] rules for YANG artifacts (i.e., YANG modules, YANG
   submodules, and YANG packages [I-D.ietf-netmod-yang-packages] ) as
   well as the revision label definition for using this scheme.  The
   goal being to add a human readable revision label that provides
   compatibility information for the YANG artifact without needing to
   compare or parse its body.  The label and rules defined herein
   represent the RECOMMENDED revision label scheme for IETF YANG

   Note that a specific revision of the Semver 2.0.0 specification is
   referenced here (from June 19, 2020) to provide an immutable version.
   This is because the 2.0.0 version of the specification has changed
   over time without any change to the semantic version itself.  In some
   cases the text has changed in non-backwards-compatible ways.

2.  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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.

   Additionally, this document uses the following terminology:

   *  YANG artifact: YANG modules, YANG submodules, and YANG packages
      [I-D.ietf-netmod-yang-packages] are examples of YANG artifacts for
      the purposes of this document.

   *  YANG Semver: A revision-label identifier that is consistent with
      the extended set of semantic versioning rules, based on [semver] ,
      defined within this document.

3.  YANG Semantic Versioning

   This section defines YANG Semantic Versioning, explains how it is
   used with YANG artifacts, and describes the rules associated with
   changing an artifact's semantic version when its contents are

3.1.  YANG Semver Pattern

   YANG artifacts that employ semantic versioning as defined in this
   document MUST use a version string (e.g., in revision-label or as a
   package version) that corresponds to the following pattern:
   X.Y.Z_COMPAT.  Where:

   *  X, Y and Z are mandatory non-negative integers that are each less
      than or equal to 2147483647 (i.e., the maximum signed 32-bit
      integer value) and MUST NOT contain leading zeroes,

   *  The '.' is a literal period (ASCII character 0x2e),

   *  The '_' is an optional single literal underscore (ASCII character
      0x5f) and MUST only be present if the following COMPAT element is

   *  COMPAT, if specified, MUST be either the literal string
      "compatible" or the literal string "non_compatible".

   Additionally, [semver] defines two specific types of metadata that
   may be appended to a semantic version string.  Pre-release metadata
   MAY be appended to a semver string after a trailing '-' character.
   Build metadata MAY be appended after a trailing '+' character.  If
   both pre-release and build metadata are present, then build metadata
   MUST follow pre-release metadata.  While build metadata MUST be
   ignored when comparing YANG semantic versions, pre-release metadata
   MUST be used during module and submodule development as specified in
   Section 5 .  Both pre-release and build metadata are allowed in order
   to support all the [semver] rules.  Thus, a version lineage that
   follows strict [semver] rules is allowed for a YANG artifact.

   To signal the use of this versioning scheme, modules and submodules
   MUST set the revision-label-scheme extension, as defined in
   [I-D.ietf-netmod-yang-module-versioning] , to the identity "yang-
   semver".  That identity value is defined in the ietf-yang-semver
   module below.

   Additionally, this ietf-yang-semver module defines a typedef that
   formally specifies the syntax of the YANG Semver.

3.2.  Semantic Versioning Scheme for YANG Artifacts

   This document defines the YANG semantic versioning scheme that is
   used for YANG artifacts that employ the YANG Semver label.  The
   versioning scheme has the following properties:

   *  The YANG semantic versioning scheme is extended from version 2.0.0
      of the semantic versioning scheme defined at [semver]
      to cover the additional requirements for the management of YANG
      artifact lifecyles that cannot be addressed using the
      2.0.0 versioning scheme alone.

   *  Unlike the [semver] versioning scheme, the YANG semantic
      versioning scheme supports updates to older versions of YANG
      artifacts, to allow for bug fixes and enhancements to artifact
      versions that are not the latest.  However, it does not provide
      for the unlimited branching and updating of older revisions which
      are documented by the general rules in
      [I-D.ietf-netmod-yang-module-versioning] .

   *  YANG artifacts that follow the [semver] versioning scheme are
      fully compatible with implementations that understand the YANG
      semantic versioning scheme defined in this document.

   *  If updates are always restricted to the latest revision of the
      artifact only, then the version numbers used by the YANG semantic
      versioning scheme are exactly the same as those defined by the
      [semver] versioning scheme.

   Every YANG module and submodule versioned using the YANG semantic
   versioning scheme specifies the module's or submodule's semantic
   version number as the argument to the 'rev:revision-label' statement.

   Because the rules put forth in
   [I-D.ietf-netmod-yang-module-versioning] are designed to work well
   with existing versions of YANG and allow for artifact authors to
   migrate to this scheme, it is not expected that all revisions of a
   given YANG artifact will have a semantic version label.  For example,
   the first revision of a module or submodule may have been produced
   before this scheme was available.

   YANG packages that make use of this YANG Semver will reflect that in
   the package metadata.

   As stated above, the YANG semantic version is expressed as a string
   of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent non-
   negative integers less than or equal to 2147483647 without leading
   zeroes, and _COMPAT represents an optional suffix of either
   "_compatible" or "_non_compatible".

   *  'X' is the MAJOR version.  Changes in the MAJOR version number
      indicate changes that are non-backwards-compatible to versions
      with a lower MAJOR version number.

   *  'Y' is the MINOR version.  Changes in the MINOR version number
      indicate changes that are backwards-compatible to versions with
      the same MAJOR version number, but a lower MINOR version number
      and no PATCH "_compatible" or "_non_compatible" modifier.

   *  'Z_COMPAT' is the PATCH version and modifier.  Changes in the
      PATCH version number can indicate editorial, backwards-compatible,
      or non-backwards-compatible changes relative to versions with the
      same MAJOR and MINOR version numbers, but lower PATCH version
      number, depending on what form modifier "_COMPAT" takes:

      -  If the modifier string is absent, the change represents an
         editorial change.  An editorial change is defined to be a
         change in the YANG artifact's content that does not affect the
         semantic meaning or functionality provided by the artifact in
         any way.  Some examples include correcting a spelling mistake
         in the description of a leaf within a YANG module or submodule,
         non-significant whitespace changes (e.g., realigning
         description statements or changing indendation), or changes to
         YANG comments.  Note: restructuring how a module uses, or does
         not use, submodules is treated as an editorial level change on
         the condition that there is no change in the module's semantic
         behavior due to the restructuring.

      -  If, however, the modifier string is present, the meaning is
         described below:

      -  "_compatible" - the change represents a backwards-compatible

      -  "_non_compatible" - the change represents a non-backwards-
         compatible change

   The YANG artifact name and YANG semantic version uniquely identify a
   revision of said artifact.  There MUST NOT be multiple instances of a
   YANG artifact definition with the same name and YANG semantic version
   but different content (and in the case of modules and submodules,
   different revision dates).

   There MUST NOT be multiple versions of a YANG artifact that have the
   same MAJOR, MINOR and PATCH version numbers, but different patch
   modifier strings.  E.g., artifact version "1.2.3_non_compatible" MUST
   NOT be defined if artifact version "1.2.3" has already been defined.

3.2.1.  YANG Semver with submodules

   YANG Semver MAY be used to version submodules.  Submodule version are
   separate of any version on the including module, but if a submodule
   has changed, then the version of the including module MUST also be

   The rules for determining the version change of a submodule are the
   same as those defined in Section 3.1 and Section 3.2 as applied to
   YANG modules, except they only apply to the part of the module schema
   defined within the submodule's file.

   One interesting case is moving definitions from one submodule to
   another in a way that does not change the resultant schema of the
   including module.  In this case:

   1.  The including module has editorial changes

   2.  The submodule with the schema definition removed has non-
       backwards-compatible changes

   3.  The submodule with the schema definitions added has backwards-
       compatible changes

   Note that the meaning of a submodule may change drastically despite
   having no changes in content or revision due to changes in other
   submodules belonging to the same module (e.g. groupings and typedefs
   declared in one submodule and used in another).

3.2.2.  Examples for YANG semantic versions

   The following diagram and explanation illustrate how YANG semantic
   versions work.


   YANG semantic Semantic versions for an example artifact: module:

              |  \
            1.1.0 -> 1.1.1_compatible -> 1.1.2_non_compatible
              |    |
            1.2.0 -> 1.2.1_non_compatible -> 1.2.2_non_compatible
              |  \
            2.0.0 \
             |    \--> 1.3.0 -> 1.3.1 1.3.1_non_compatible
            3.0.0         |
                \         1.4.0

   Assume the

   The tree diagram above illustrates how an example YANG
   module's the version history might evolve.  For example, the
   evolve for an example module.  The tree might
   represent diagram only shows the following changes, listed
   parent/child ancestry relationships between the revisions.  It does
   not describe the chronology of the revisions (i.e.  when in time each
   revision was published relative to the other revisions).

   The following description lists an example of what the chronological
   order of
   when the revisions were published, could look like, from oldest revision to

      0.1.0 - first pre-release module version

      0.2.0 - second pre-release module version (with NBC changes)

      1.0.0 - first release (may have NBC changes from 0.2.0)

      1.1.0 - added new functionality, leaf "foo" (BC)

      1.2.0 - added new functionality, leaf "baz" (BC)

      2.0.0 - change existing model for performance reasons, e.g. re-key
      list (NBC)

      1.3.0 - improve existing functionality, added leaf "foo-64" (BC)

      1.3.1 - improve description wording for "foo-64" (Editorial)

      1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid
      implementing "baz" from 1.2.0.  This revision was created after
      1.2.0 otherwise it may have been released as 1.2.0.  (BC)

      2.0.0 - change existing model for performance reasons, e.g. re-key
      list (NBC)

      1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0
      due to model changes (NBC)

      3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf
      "wibble"; (NBC)
      1.3.1_non_compatible - backport NBC fix, rename "baz" to "bar"

      1.2.1_non_compatible - backport NBC fix, changing rename "baz" to "bar"

      1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0
      due to model changes (NBC)

      1.4.0 - introduce new leaf "ghoti" (BC)

      3.1.0 - introduce new leaf "wobble" (BC)

      1.2.2_non_compatible - backport "wibble".  This is a BC change but
      "non_compatible" modifier is sticky.

      3.1.0 - introduce new leaf "wobble"  (BC)

   The partial ordering ancestry relationships based on the semantic versioning
   numbers are as follows:

      1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 2.0.0 < 3.0.0 < 3.1.0

      1.0.0 < 1.1.0 < 1.1.1_compatible < 1.1.2_non_compatible

      1.0.0 < 1.1.0 < 1.2.0 < 1.2.1_non_compatible <

      1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.3.1_non_compatible

      1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.4.0

   There is no ordering relationship between 1.1.1_non_compatible and
   either 1.2.0 or 1.2.1_non_compatible, except that they share the
   common ancestor of 1.1.0.

   Looking at the version number alone, the alone does not indicate ancestry.  The
   module definition in 2.0.0 2.0.0, for example, does not necessarily contain all the
   contents of 1.3.0.  However, the
   module revision history in  Version 2.0.0 may well indicate that it was edited is not derived from module version 1.3.0.

3.3.  YANG Semantic Version Update Rules

   When a new revision of an artifact is produced, then the following
   rules define how the YANG semantic version number for the new artifact
   revision is calculated, based on the changes between the two artifact
   revisions, and the YANG semantic version number of the base artifact
   revision from which the changes are derived.

   The following four rules specify the RECOMMENDED, and REQUIRED
   minimum, update to a YANG semantic version number: version:

   1.  If an artifact is being updated in a non-backwards-compatible
       way, then the artifact version
       "X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to
       "X+1.0.0" unless that version has already been used for this
       artifact but with different content, in which case the artifact
       version "X.Y.Z+1_non_compatible" SHOULD be used instead.

   2.  If an artifact is being updated in a backwards-compatible way,
       then the next version number depends on the format of the current
       version number:

       i    "X.Y.Z" - the artifact version SHOULD be updated to
            "X.Y+1.0", unless that version has already been used for
            this artifact but with different content, when the artifact
            version SHOULD be updated to "X.Y.Z+1_compatible"" instead.

       ii   "X.Y.Z_compatible" - the artifact version SHOULD be updated
            to "X.Y.Z+1_compatible".

       iii  "X.Y.Z_non_compatible" - the artifact version SHOULD be
            updated to "X.Y.Z+1_non_compatible".

   3.  If an artifact is being updated in an editorial way, then the
       next version number depends on the format of the current version

       i    "X.Y.Z" - the artifact version SHOULD be updated to

       ii   "X.Y.Z_compatible" - the artifact version SHOULD be updated
            to "X.Y.Z+1_compatible".

       iii  "X.Y.Z_non_compatible" - the artifact version SHOULD be
            updated to "X.Y.Z+1_non_compatible".

   4.  YANG artifact semantic version numbers beginning with 0, i.e.,
       "0.X.Y", are regarded as pre-release definitions and need not
       follow the rules above.  Either the MINOR or PATCH version
       numbers may be updated, regardless of whether the changes are
       non-backwards-compatible, backwards-compatible, or editorial.
       See Section 5 for more details on using this notation during
       module and submodule development.

   5.  Additional pre-release rules for modules that have had at least
       one release are specified in Section 5 .

   Although artifacts SHOULD be updated according to the rules above,
   which specify the recommended (and minimum required) update to the
   version number, the following rules MAY be applied when choosing a
   new version number:

   1.  An artifact author MAY update the version number with a more
       significant update than described by the rules above.  For
       example, an artifact could be given a new MAJOR version number
       (i.e., X+1.0.0), even though no non-backwards-compatible changes
       have occurred, or an artifact could be given a new MINOR version
       number (i.e., X.Y+1.0) even if the changes were only editorial.

   2.  An artifact author MAY skip version numbers.  That is, an
       artifact's revision history could be 1.0.0, 1.1.0, and 1.3.0
       where 1.2.0 is skipped.  Note that skipping versions has an
       impact when importing modules by revision-or-derived.  See
       Section 4 for more details on importing modules with revision-
       label version gaps.

   Although YANG Semver always indicates when a non-backwards-
   compatible, or backwards-compatible change may have occurred to a
   YANG artifact, it does not guarantee that such a change has occurred,
   or that consumers of that YANG artifact will be impacted by the
   change.  Hence, tooling, e.g.,
   [I-D.ietf-netmod-yang-schema-comparison] , also plays an important
   role for comparing YANG artifacts and calculating the likely impact
   from changes.

   [I-D.ietf-netmod-yang-module-versioning] defines the "rev:nbc-
   changes" "rev:non-
   backwards-compatible" extension statement to indicate where non-backwards-
   compatible non-
   backwards-compatible changes have occurred in the module revision
   history.  If a revision entry in a module's revision history includes
   "rev:nbc-changes" "rev:non-backwards-compatible" statement then that MUST be
   reflected in any YANG semantic version associated with that revision.
   However, the reverse does not necessarily hold, i.e., if the MAJOR
   version has been incremented it does not necessarily mean that a "rev:nbc-changes"
   "rev:non-backwards-compatible" statement would be present.

3.4.  Examples of the YANG Semver Label

3.4.1.  Example Module Using YANG Semver

   Below is a sample YANG module that uses the YANG Semver revision-
   label based on the rules defined in this document.

    module example-versioned-module {
      yang-version 1.1;
      namespace "urn:example:versioned:module";
      prefix "exvermod";
      rev:revision-label-scheme "yangver:yang-semver"; "ysver:yang-semver";

      import ietf-yang-revisions { prefix "rev"; }
      import ietf-yang-semver { prefix "ysver"; }

        "to be completed";

      revision 2018-02-28 {
           description "Added leaf 'wobble'";
           rev:revision-label 3.1.0;


         revision 2017-12-31 {
           description "Rename 'baz' to 'bar', added leaf 'wibble'";
           rev:revision-label 3.0.0;

         revision 2017-10-30 {
           description "Change the module structure";
           rev:revision-label 2.0.0;

         revision 2017-08-30 {
        description "Clarified description of 'foo-64' "Backport 'wibble' leaf";
        rev:revision-label 1.3.1; 1.2.2_non_compatible;

      revision 2017-07-30 {
        description "Added leaf foo-64"; "Rename 'baz' to 'bar'";
        rev:revision-label 1.3.0; 1.2.1_non_compatible;

      revision 2017-04-20 {
        description "Add new functionality, leaf 'baz'";
        rev:revision-label 1.2.0;

      revision 2017-04-03 {
        description "Add new functionality, leaf 'foo'";
        rev:revision-label 1.1.0;

      revision 2017-02-07 {
        description "First release version.";
        rev:revision-label 1.0.0;

      // Note: semver rules do not apply to 0.X.Y labels.
      // The following pre-release revision statements would not
      // appear in any final published version of a module. They
      // are removed when the final version is published.
      // During the pre-release phase of development, only a
      // single one of these revision statements would appear

      // revision 2017-01-30 {
      //   description "NBC changes to initial revision";
      //   rev:revision-label 0.2.0;
      //   rev:non-backwards-compatible; // optional
          //                                 // (theoretically no
          //                                 // 'previous released version')
      // }

      // revision 2017-01-26 {
      //   description "Initial module version";
      //   rev:revision-label 0.1.0;
      // }

      //YANG module definition starts here

3.4.2.  Example of Package Using YANG Semver

   Below is an example YANG package that uses the semver revision label
   based on the rules defined in this document.

        "ietf-yang-instance-data:instance-data-set": {
          "name": "example-yang-pkg",
          "target-ptr": "TBD",
          "timestamp": "2018-09-06T17:00:00Z",
          "description": "Example IETF package definition",
          "content-data": {
            "ietf-yang-package:yang-package": {
              "name": "example-yang-pkg",
              "version": "1.3.1",

4.  Import Module by Semantic Version

   [I-D.ietf-netmod-yang-module-versioning] allows for imports to be
   done based on a module or a derived revision of a module.  The
   rev:revision-or-derived statement can specify either a revision date
   or a revision label.  The YANG Semver revision-label value can be
   used as the argument to rev:revision-or-derived .  When used as such,
   any module that contains exactly the same YANG semantic version in
   its revision history may be used to satisfy the import requirement.
   For example:

           import example-module {
             rev:revision-or-derived 3.0.0;

   Note: the import lookup does not stop when a non-backward-compatible
   change is encountered.  That is, if module B imports a module A at or
   derived from version 2.0.0, resolving that import will pass through a
   revision of module A with version 2.1.0_non_compatible in order to
   determine if the present instance of module A derives from 2.0.0.

   If an import by revision-or-derived cannot locate the specified
   revision-label in a given module's revision history, that import will
   fail.  This is noted in the case of version gaps.  That is, if a
   module's history includes 1.0.0, 1.1.0, and 1.3.0, an import from
   revision-or-derived at 1.2.0 will be unable to locate the specified
   revision entry and thus the import cannot be satisfied.

5.  Guidelines for Using Semver During Module Development

   This section and the IETF-specific sub-section below provides YANG
   Semver-specific guidelines to consider when developing new YANG
   modules.  As such this section updates [RFC8407] .

   Development of a brand new YANG module or submodule outside of the
   IETF that uses YANG Semver as its revision-label scheme SHOULD begin
   with a 0 for the MAJOR version component.  This allows the module or
   submodule to disregard strict semver rules with respect to non-
   backwards-compatible changes during its initial development.
   However, module or submodule developers MAY choose to use the semver
   pre-release syntax instead with a 1 for the MAJOR version component.
   For example, an initial module or submodule revision-label might be
   either 0.0.1 or 1.0.0-alpha.1.  If the authors choose to use the 0
   MAJOR version component scheme, they MAY switch to the pre-release
   scheme with a MAJOR version component of 1 when the module or
   submodule is nearing initial release (e.g., a module's or submodule's
   revision label may transition from 0.3.0 to 1.0.0-beta.1 to indicate
   it is more mature and ready for testing).

   When using pre-release notation, the format MUST include at least one
   alphabetic component and MUST end with a '.' or '-' and then one or
   more digits.  These alphanumeric components will be used when
   deciding pre-release precedence.  The following are examples of valid
   pre-release versions





   When developing a new revision of an existing module or submodule
   using the YANG semver revision-label scheme, the intended target
   semver version MUST be used along with pre-release notation.  For
   example, if a released module or submodule which has a current
   revision-label of 1.0.0 is being modified with the intent to make
   non-backwards-compatible changes, the first development MAJOR version
   component must be 2 with some pre-release notation such as -alpha.1,
   making the version 2.0.0-alpha.1.  That said, every publicly
   available release of a module or submodule MUST have a unique YANG
   semver revision-label (where a publicly available release is one that
   could be implemented by a vendor or consumed by an end user).
   Therefore, it may be prudent to include the year or year and month
   development began (e.g., 2.0.0-201907-alpha.1).  As a module or
   submodule undergoes development, it is possible that the original
   intent changes.  For example, a 1.0.0 version of a module or
   submodule that was destined to become 2.0.0 after a development cycle
   may have had a scope change such that the final version has no non-
   backwards-compatible changes and becomes 1.1.0 instead.  This change
   is acceptable to make during the development phase so long as pre-
   release notation is present in both versions (e.g., 2.0.0-alpha.3
   becomes 1.1.0-alpha.4).  However, on the next development cycle
   (after 1.1.0 is released), if again the new target release is 2.0.0,
   new pre-release components must be used such that every revision-
   label for a given module or submodule MUST be unique throughout its
   entire lifecycle (e.g., the first pre-release version might be
   2.0.0-202005-alpha.1 if keeping the same year and month notation
   mentioned above).

5.1.  Pre-release Version Precedence

   As a module or submodule is developed, the scope of the work may
   change.  That is, while a ratified module or submodule with revision-
   label 1.0.0 is initially intended to become 2.0.0 in its next
   ratified version, the scope of work may change such that the final
   version is 1.1.0.  During the development cycle, the pre-release
   versions could move from 2.0.0-some-pre-release-tag to 1.1.0-some-
   pre-release-tag.  This downwards changing of version numbers makes it
   difficult to evaluate semver rules between pre-release versions.
   However, taken independently, each pre-release version can be
   compared to the previously ratified version (e.g., 1.1.0-some-pre-
   release-tag and 2.0.0-some-pre-release-tag can each be compared to
   1.0.0).  Module and submodule developers SHOULD maintain only one
   revision statement in a pre-released module or submodule that
   reflects the latest revision.  IETF authors MAY choose to include an
   appendix in the associated draft to track overall changes to the
   module or submodule.

5.2.  YANG Semver in IETF Modules

   All published IETF modules and submodules MUST use YANG semantic
   versions for their revision-labels.

   Development of a new module or submodule within the IETF SHOULD begin
   with the 0 MAJOR number scheme as described above.  When revising an
   existing IETF module or submodule, the revision-label MUST use the
   target (i.e., intended) MAJOR and MINOR version components with a 0
   PATCH version component.  If the intended ratified release will be
   non-backward-compatible with the current ratified release, the MINOR
   version component MUST be 0.

   All IETF modules and submodules in development MUST use the whole
   document name as a pre-release version string, including the current
   document revision.  For example, if a module or submodule which is
   currently released at version 1.0.0 is being revised to include non-
   backwards-compatible changes in draft-user-netmod-foo, its
   development revision-labels MUST include 2.0.0-draft-user-netmod-foo
   followed by the document's revision (e.g., 2.0.0-draft-user-netmod-
   foo-02).  This will ensure each pre-release version is unique across
   the lifecycle of the module or submodule.  Even when using the 0
   MAJOR version for initial module or submodule development (where
   MINOR and PATCH can change), appending the draft name as a pre-
   release component helps to ensure uniqueness when there are perhaps
   multiple, parallel efforts creating the same module or submodule.

   For IETF YANG modules and submodules that have already been
   published, revision-labels MUST be retroactively applied to all
   existing revisions when the next new revision is created, starting at
   version "1.0.0" for the initial published revision, and then
   incrementing according to the YANG Semver version rules specified in
   Section 3.3 . For example, if a module or submodule started out in
   the pre-NMDA ([RFC8342] ) world, and then had NMDA support added
   without removing any legacy "state" branches -- and you are looking
   to add additional new features -- a sensible choice for the target
   YANG Semver would be 1.2.0 (since 1.0.0 would have been the initial,
   pre-NMDA release, and 1.1.0 would have been the NMDA revision).

   See Appendix A for a detailed example of IETF pre-release versions.

6.  YANG Module

   This YANG module contains the typedef for the YANG semantic version
   and the identity to signal its use.

   <CODE BEGINS> file "ietf-yang-semver@2021-10-20.yang" "ietf-yang-semver@2021-11-04.yang"
   module ietf-yang-semver {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver";
     prefix ysver;
     rev:revision-label-scheme "yang-semver";

     import ietf-yang-revisions {
       prefix rev;

       "IETF NETMOD (Network Modeling) Working Group";
       "WG Web:   <>
        WG List:  <>

        Author:   Joe Clarke
        Author:   Benoit Claise
                  <>   Robert Wilton
        Author:   Reshad Rahman
        Author:   Robert Wilton
        Author:   Balazs Lengyel
        Author:   Jason Sterne
        Author:   Benoit Claise
       "This module provides type and grouping definitions for YANG

        Copyright (c) 2021 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 Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

     // RFC Ed.: update the date below with the date of RFC publication
     // and remove this note.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.
     // RFC Ed. update the rev:revision-label to "1.0.0".

     revision 2021-10-20 2021-11-04 {
       rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-04"; "1.0.0-draft-ietf-netmod-yang-semver-05";
         "Initial revision";
         "RFC XXXX: YANG Semantic Versioning.";

      * Identities

     identity yang-semver {
       base rev:revision-label-scheme-base;
         "The revision-label scheme corresponds to the YANG Semver scheme
          which is defined by the pattern in the 'version' typedef below.
          The rules governing this revision-label scheme are defined in the
          reference for this identity.";
         "RFC XXXX: YANG Semantic Versioning.";

      * Typedefs

     typedef version {
       type string rev:revision-label {
         pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?(-[A-Za-z0-9.-]+)?([+][A-Za-z0-9.-]+)?'; '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?'
         + '(-[A-Za-z0-9.-]+[.-][0-9]+)?([+][A-Za-z0-9.-]+)?';
         "Represents a YANG semantic version number. version.  The rules governing the
          use of this revision label scheme are defined in the reference for
          this typedef.";
         "RFC XXXX: YANG Semantic Versioning.";

7.  Contributors

   This document grew out of the YANG module versioning design team that
   started after IETF 101.  The design team consists of the following
   members whom have worked on the YANG versioning project:

   *  Balazs Lengyel

   *  Benoit Claise

   *  Bo Wu

   *  Ebben Aries

   *  Jan Lindblad

   *  Jason Sterne

   *  Joe Clarke

   *  Juergen Schoenwaelder

   *  Mahesh Jethanandani

   *  Michael (Wangzitao)

   *  Qin Wu

   *  Reshad Rahman

   *  Rob Wilton

   The initial revision of this document was refactored and built upon
   [I-D.clacla-netmod-yang-model-update] .  We would like the thank
   Kevin D'Souza for his initial work in this problem space.

   Discussons on the use of Semver for YANG versioning has been held
   with authors of the OpenConfig YANG models based on their own
   [openconfigsemver] .  We would like thank both Anees Shaikh and Rob
   Shakir for their input into this problem space.

8.  Security Considerations

   The document does not define any new protocol or data model.  There
   are no security impacts.

9.  IANA Considerations
9.1.  YANG Module Registrations

   This document requests IANA to register a URI in the "IETF XML
   Registry" [RFC3688] .  Following the format in RFC 3688, the
   following registration is requested.

      URI: urn:ietf:params:xml:ns:yang:ietf-yang-semver

      Registrant Contact: The IESG.

      XML: N/A, the requested URI is an XML namespace.

   The following YANG module is requested to be registred in the "IANA
   Module Names" [RFC6020] .  Following the format in RFC 6020, the
   following registrations are requested:

   The ietf-yang-semver module:

      Name: ietf-yang-semver

      XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver

      Prefix: yangver

      Reference: [RFCXXXX]

9.2.  Guidance for YANG Semver in IANA maintained YANG modules and

   Note for IANA (to be removed by the RFC editor): Please check that
   the registries and IANA YANG modules and submodules are referenced in
   the appropriate way.

   IANA is responsible for maintaining and versioning some YANG modules
   and submodules, e.g., iana-if-types.yang [IfTypeYang] and iana-
   routing-types.yang [RoutingTypesYang] .

   In addition to following the rules specified in the IANA
   Considerations section of [I-D.ietf-netmod-yang-module-versioning] ,
   IANA maintained YANG modules and submodules MUST also include a YANG
   Semver revision label for all new revisions, as defined in Section 3

   The YANG Semver version associated with the new revision MUST follow
   the rules defined in Section 3.3 .

   Note: For IANA maintained YANG modules and submodules that have
   already been published, revision labels MUST be retroactively applied
   to all existing revisions when the next new revision is created,
   starting at version "1.0.0" for the initial published revision, and
   then incrementing according to the YANG Semver rules specified in
   Section 3.3 .

   Most changes to IANA maintained YANG modules and submodules are
   expected to be backwards-compatible changes and classified as MINOR
   version changes.  The PATCH version may be incremented instead when
   only editorial changes are made, and the MAJOR version would be
   incremented if non-backwards-compatible changes are made.

   Given that IANA maintained YANG modules are versioned with a linear
   history, it is anticipated that it should not be necessary to use the
   "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT"
   version element.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
              Documents Containing YANG Data Models", BCP 216, RFC 8407,
              DOI 10.17487/RFC8407, October 2018,

              Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
              Sterne, "Updated YANG Module Revision Handling", Work in
              Progress, Internet-Draft, draft-ietf-netmod-yang-module-
              versioning-03, 12 July
              versioning-04, 25 October 2021,

10.2.  Informative References

              Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New
              YANG Module Update Procedure", Work in Progress, Internet-
              Draft, draft-clacla-netmod-yang-model-update-06, 2 July
              2018, <
              netmod-yang-model-update-06>. <

              Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
              "YANG Packages", Work in Progress, Internet-Draft, draft-
              ietf-netmod-yang-packages-01, 2 November 2020,
              ietf-netmod-yang-packages-02, 25 October 2021,

              Wilton, R., "YANG Schema Comparison", Work in Progress,
              Internet-Draft, draft-ietf-netmod-yang-schema-comparison-
              01, 2 November 2020,
              yang-schema-comparison-01>. <

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,

              "Semantic Versioning for Openconfig Models",

   [semver]   "Semantic Versioning 2.0.0 (text from June 19, 2020)",

              "iana-if-type YANG Module",

              "iana-routing-types YANG Module",

Appendix A.  Example IETF Module Development

   Assume a new YANG module is being developed in the netmod working
   group in the IETF.  Initially, this module is being developed in an
   individual internet draft, draft-jdoe-netmod-example-module.  The
   following represents the initial version tree (i.e., value of
   revision-label) of the module as it's being initially developed.

   Version lineage for initial module development:


   At this point, development stabilizes, and the workgroup adopts the
   draft.  Thus now the draft becomes draft-ietf-netmod-example-module.
   The initial pre-release lineage continues as follows.

   Continued version lineage after adoption:


   At this point, the draft is ratified and becomes RFC12345 and the
   YANG module version number becomes 1.0.0.

   A time later, the module needs to be revised to add additional
   capabilities.  Development will be done in a backwards-compatible
   way.  Two new individual drafts are proposed to go about adding the
   capabilities in different ways: draft-jdoe-netmod-exmod-enhancements
   and draft-jadoe-netmod-exmod-changes.  These are initially developed
   in parallel with the following versions.

   Parallel development for next module revision:

      1.1.0-draft-jdoe-netmod-exmod-enhancements-00 || 1.1.0-draft-jadoe-netmod-exmod-changes-00
        |                                                |
      1.1.0-draft-jdoe-netmod-exmod-enhancements-01 || 1.1.0-draft-jadoe-netmod-exmod-changes-01

   At this point, the WG decides to merge some aspects of both and adopt
   the work in jadoe's draft as draft-ietf-netmod-exmod-changes.  A
   single version lineage continues.


   The draft is ratified, and the new module version becomes 1.1.0.

Authors' Addresses

   Joe Clarke (editor)
   Cisco Systems, Inc.
   7200-12 Kit Creek Rd
   Research Triangle Park, North Carolina
   United States of America

   Phone: +1-919-392-2867

   Robert Wilton (editor)
   Cisco Systems, Inc.


   Reshad Rahman


   Balazs Lengyel
   1117 Budapest
   Magyar Tudosok Korutja

   Phone: +36-70-330-7909

   Jason Sterne


   Benoit Claise