< draft-ietf-netmod-yang-semver-01.txt   draft-ietf-netmod-yang-semver-02.txt >
Network Working Group B. Claise Network Working Group B. Claise
Internet-Draft J. Clarke, Ed. Internet-Draft Huawei
Updates: 8407 (if approved) R. Rahman Updates: 8407 (if approved) J. Clarke, Ed.
Intended status: Standards Track R. Wilton, Ed. Intended status: Standards Track R. Rahman
Expires: January 14, 2021 Cisco Systems, Inc. Expires: 25 August 2021 R. Wilton, Ed.
Cisco Systems, Inc.
B. Lengyel B. Lengyel
Ericsson Ericsson
J. Sterne J. Sterne
Nokia Nokia
K. D'Souza K. D'Souza
AT&T AT&T
July 13, 2020 21 February 2021
YANG Semantic Versioning YANG Semantic Versioning
draft-ietf-netmod-yang-semver-01 draft-ietf-netmod-yang-semver-02
Abstract Abstract
This document specifies a scheme and guidelines for applying a This document specifies a scheme and guidelines for applying a
modified set of semantic versioning rules to revisions of YANG modified set of semantic versioning rules to revisions of YANG
modules. Additionally, this document defines a revision-label for modules. Additionally, this document defines a revision-label for
this modified semver scheme. this modified semver scheme.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on 25 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. YANG Semantic Versioning . . . . . . . . . . . . . . . . . . 3 3. YANG Semantic Versioning . . . . . . . . . . . . . . . . . . 3
3.1. YANG Semantic Versioning Pattern . . . . . . . . . . . . 3 3.1. YANG Semantic Versioning Pattern . . . . . . . . . . . . 3
3.2. Semantic Versioning Scheme for YANG Artifacts . . . . . . 4 3.2. Semantic Versioning Scheme for YANG Artifacts . . . . . . 4
3.2.1. Examples for YANG semantic version numbers . . . . . 6 3.2.1. Examples for YANG semantic version numbers . . . . . 6
3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 8 3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 8
3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 9 3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 9
3.4.1. Example Module Using YANG Semver . . . . . . . . . . 9 3.4.1. Example Module Using YANG Semver . . . . . . . . . . 9
3.4.2. Example of Package Using YANG Semver . . . . . . . . 11 3.4.2. Example of Package Using YANG Semver . . . . . . . . 11
4. Import Module by Semantic Version . . . . . . . . . . . . . . 11 4. Import Module by Semantic Version . . . . . . . . . . . . . . 11
5. Guidelines for Using Semver During Module Development . . . . 11 5. Guidelines for Using Semver During Module Development . . . . 12
5.1. Pre-release Version Precedence . . . . . . . . . . . . . 13 5.1. Pre-release Version Precedence . . . . . . . . . . . . . 13
5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 13 5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 13
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Guidance for YANG Semver in IANA maintained YANG
10.2. Informative References . . . . . . . . . . . . . . . . . 17 modules . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Example IETF Module Development . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example IETF Module Development . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[I-D.ietf-netmod-yang-module-versioning] puts forth a number of [I-D.ietf-netmod-yang-module-versioning] puts forth a number of
concepts relating to modified rules for updating modules, a means to concepts relating to modified rules for updating modules, a means to
signal when a new revision of a module has non-backwards-compatible signal when a new revision of a module has non-backwards-compatible
(NBC) changes compared to its previous revision, and a versioning (NBC) changes compared to its previous revision, and a versioning
scheme that uses the revision history as a lineage for determining scheme that uses the revision history as a lineage for determining
from where a specific revision of a YANG module is derived. from where a specific revision of a YANG module is derived.
Additionally, section 3.3 of [I-D.ietf-netmod-yang-module-versioning] Additionally, section 3.3 of [I-D.ietf-netmod-yang-module-versioning]
defines a revision label which can be used as an overlay or alias to defines a revision label which can be used as an overlay or alias to
provide additional context or an additional way to refer to a provide additional context or an additional way to refer to a
specific revision. specific revision.
This document defines a revision-label scheme that uses modified This document defines a revision-label scheme that uses modified
[semver] rules for YANG artifacts (i.e., YANG modules and YANG [semver] rules for YANG artifacts (i.e., YANG modules and YANG
packages [I-D.ietf-netmod-yang-packages]) as well as the revision packages [I-D.ietf-netmod-yang-packages] ) as well as the revision
label definition for using this scheme. The goal of this is to add a label definition for using this scheme. The goal of this is to add a
human readable version label that provides compatibility information human readable version label that provides compatibility information
for the YANG artifact without one needing to compare or parse its for the YANG artifact without one needing to compare or parse its
body. The label and rules defined herein represent the RECOMMENDED body. The label and rules defined herein represent the RECOMMENDED
revision label scheme for IETF YANG artifacts. revision label scheme for IETF YANG artifacts.
2. Terminology and Conventions 2. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
o YANG artifact: YANG modules, YANG packages * YANG artifact: YANG modules, YANG packages
[I-D.ietf-netmod-yang-packages], and YANG schema elements are [I-D.ietf-netmod-yang-packages] , and YANG schema elements are
examples of YANG artifacts for the purposes of this document. examples of YANG artifacts for the purposes of this document.
3. YANG Semantic Versioning 3. YANG Semantic Versioning
This section defines YANG Semantic Versioning, explains how it is This section defines YANG Semantic Versioning, explains how it is
used with YANG artifacts, and the rules associated with changing an used with YANG artifacts, and the rules associated with changing an
artifact's semantic version number when its contents are updated. artifact's semantic version number when its contents are updated.
3.1. YANG Semantic Versioning Pattern 3.1. YANG Semantic Versioning Pattern
YANG artifacts that employ semantic versioning as defined in this YANG artifacts that employ semantic versioning as defined in this
document MUST use a version string (e.g., in revision-label or as a document MUST use a version string (e.g., in revision-label or as a
package version) that corresponds to the following pattern: package version) that corresponds to the following pattern:
X.Y.Z_COMPAT. Where: X.Y.Z_COMPAT. Where:
o X, Y and Z are mandatory non-negative integers that are each less * X, Y and Z are mandatory non-negative integers that are each less
than 2147483647 (i.e., the maximum signed 32-bit integer value) than 2147483647 (i.e., the maximum signed 32-bit integer value)
and MUST NOT contain leading zeroes and MUST NOT contain leading zeroes
o The '.' is a literal period (ASCII character 0x2e) * The '.' is a literal period (ASCII character 0x2e)
o The '_' is an optional single literal underscore (ASCII character * The '_' is an optional single literal underscore (ASCII character
0x5f) and MUST only present if the following COMPAT element is 0x5f) and MUST only present if the following COMPAT element is
included included
o COMPAT, if it is specified, MUST be either the literal string * COMPAT, if it is specified, MUST be either the literal string
"compatible" or the literal string "non_compatible" "compatible" or the literal string "non_compatible"
Additionally, [semver] defines two specific types of metadata that 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 semantic version string. Pre-release metadata
MAY be appended to a semver string after a trailing '-' character. MAY be appended to a semver string after a trailing '-' character.
Build metadata MAY be appended after a trailing '+' character. If Build metadata MAY be appended after a trailing '+' character. If
both pre-release and build metadata are present, then build metadata both pre-release and build metadata are present, then build metadata
MUST follow pre-release metadata. While build metadata MUST be MUST follow pre-release metadata. While build metadata MUST be
ignored by YANG semver parsers, pre-release metadata MUST be used ignored by YANG semver parsers, pre-release metadata MUST be used
during module development and MUST be considered base on Section 5. during module development and MUST be considered base on Section 5 .
Both pre-release and build metadata are allowed in order to support Both pre-release and build metadata are allowed in order to support
all of the [semver] rules. Thus, a version lineage that follows all of the [semver] rules. Thus, a version lineage that follows
strict [semver] rules is allowed for a YANG artifact. strict [semver] rules is allowed for a YANG artifact.
To signal the use of this versioning scheme, modules MUST set the To signal the use of this versioning scheme, modules MUST set the
revision-label-scheme extension as defined in revision-label-scheme extension as defined in
[I-D.ietf-netmod-yang-module-versioning] to the identity "yang- [I-D.ietf-netmod-yang-module-versioning] to the identity "yang-
semver". That identity value is defined in the ietf-yang-semver semver". That identity value is defined in the ietf-yang-semver
module below. module below.
Additionally, this ietf-yang-semver module defines a typedef that Additionally, this ietf-yang-semver module defines a typedef that
formally specifies the syntax of the YANG semver version string. formally specifies the syntax of the YANG semver version string.
3.2. Semantic Versioning Scheme for YANG Artifacts 3.2. Semantic Versioning Scheme for YANG Artifacts
This document defines the YANG semantic versioning scheme that is This document defines the YANG semantic versioning scheme that is
used for YANG artifacts that employ the YANG semver label. The used for YANG artifacts that employ the YANG semver label. The
versioning scheme has the following properties: versioning scheme has the following properties:
The YANG semantic versioning scheme is extended from version 2.0.0 * The YANG semantic versioning scheme is extended from version 2.0.0
of the semantic versioning scheme defined at semver.org [semver] of the semantic versioning scheme defined at semver.org [semver]
to cover the additional requirements for the management of YANG to cover the additional requirements for the management of YANG
artifact lifecyles that cannot be addressed using the semver.org artifact lifecyles that cannot be addressed using the semver.org
2.0.0 versioning scheme alone. 2.0.0 versioning scheme alone.
Unlike the [semver] versioning scheme, the YANG semantic * Unlike the [semver] versioning scheme, the YANG semantic
versioning scheme supports limited updates to older versions of versioning scheme supports updates to older versions of YANG
YANG artifacts, to allow for bug fixes and enhancements to artifacts, to allow for bug fixes and enhancements to artifact
artifact versions that are not the latest. However, it does not versions that are not the latest. However, it does not provide
provide for the unlimited branching and updating of older for the unlimited branching and updating of older revisions which
revisions which are documented by the general rules in are documented by the general rules in
[I-D.ietf-netmod-yang-module-versioning]. [I-D.ietf-netmod-yang-module-versioning] .
YANG artifacts that follow the [semver] versioning scheme are * YANG artifacts that follow the [semver] versioning scheme are
fully compatible with implementations that understand the YANG fully compatible with implementations that understand the YANG
semantic versioning scheme defined in this document. semantic versioning scheme defined in this document.
If updates are always restricted to the latest revision of the * If updates are always restricted to the latest revision of the
artifact only, then the version numbers used by the YANG semantic artifact only, then the version numbers used by the YANG semantic
versioning scheme are exactly the same as those defined by the versioning scheme are exactly the same as those defined by the
[semver] versioning scheme. [semver] versioning scheme.
Every YANG module versioned using the YANG semantic versioning scheme Every YANG module versioned using the YANG semantic versioning scheme
specifies the module's semantic version number as the argument to the specifies the module's semantic version number as the argument to the
'rev:revision-label' statement. 'rev:revision-label' statement.
Because the rules put forth in Because the rules put forth in
[I-D.ietf-netmod-yang-module-versioning] are designed to work well [I-D.ietf-netmod-yang-module-versioning] are designed to work well
skipping to change at page 5, line 29 skipping to change at page 5, line 32
YANG packages that make use of this semantic versioning scheme will YANG packages that make use of this semantic versioning scheme will
have their semantic version as the value of the "revision_label" have their semantic version as the value of the "revision_label"
property. property.
As stated above, the YANG semver version number is expressed as a As stated above, the YANG semver version number is expressed as a
string of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent string of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent
non-negative integers smaller than 2147483647 without leading zeroes, non-negative integers smaller than 2147483647 without leading zeroes,
and _COMPAT represents an optional suffix of either "_compatible" or and _COMPAT represents an optional suffix of either "_compatible" or
"_non_compatible". "_non_compatible".
o 'X' is the MAJOR version. Changes in the major version number * 'X' is the MAJOR version. Changes in the MAJOR version number
indicate changes that are non-backwards-compatible to versions indicate changes that are non-backwards-compatible to versions
with a lower major version number. with a lower MAJOR version number.
o 'Y' is the MINOR version. Changes in the minor version number * 'Y' is the MINOR version. Changes in the MINOR version number
indicate changes that are backwards-compatible to versions with indicate changes that are backwards-compatible to versions with
the same major version number, but a lower minor version number the same MAJOR version number, but a lower MINOR version number
and no patch "_compatible" or "_non_compatible" modifier. and no PATCH "_compatible" or "_non_compatible" modifier.
o 'Z_COMPAT' is the PATCH version and modifier. Changes in the * 'Z_COMPAT' is the PATCH version and modifier. Changes in the
patch version number can indicate editorial, backwards-compatible, PATCH version number can indicate editorial, backwards-compatible,
or non-backwards-compatible changes relative to versions with the or non-backwards-compatible changes relative to versions with the
same major and minor version numbers, but lower patch version same MAJOR and MINOR version numbers, but lower PATCH version
number, depending on what form modifier "_COMPAT" takes: number, depending on what form modifier "_COMPAT" takes:
* If the modifier string is absent, the change represents an - If the modifier string is absent, the change represents an
editorial change. An editorial change is defined to be a editorial change. An editorial change is defined to be a
change in the YANG artifact's content that does not affect the change in the YANG artifact's content that does not affect the
semantic meaning or functionality provided by the artifact in semantic meaning or functionality provided by the artifact in
any way. An example is correcting a spelling mistake in the any way. Some examples include correcting a spelling mistake
description of a leaf within a YANG module. Note: in the description of a leaf within a YANG module, non-
restructuring how a module uses, or does not use, submodules is significant whitespace changes (e.g. realigning description
treated as an editorial level change on the condition that statements, or changing indendation), or changes to YANG
there is no change in the module's semantic behavior due to the comments. Note: restructuring how a module uses, or does not
restructuring. 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 - If, however, the modifier string is present, the meaning is
described below: described below:
* "_compatible" - the change represents a backwards-compatible - "_compatible" - the change represents a backwards-compatible
change change
* "_non_compatible" - the change represents a non-backwards- - "_non_compatible" - the change represents a non-backwards-
compatible change compatible change
The YANG artifact name and YANG semantic version number uniquely The YANG artifact name and YANG semantic version number uniquely
identify a revision of said artifact. There MUST NOT be multiple identify a revision of said artifact. There MUST NOT be multiple
instances of a YANG artifact definition with the same name and YANG instances of a YANG artifact definition with the same name and YANG
semantic version number but different content (and in the case of semantic version number but different content (and in the case of
modules, different revision dates). modules, different revision dates).
There MUST NOT be multiple versions of a YANG artifact that have the There MUST NOT be multiple versions of a YANG artifact that have the
same MAJOR, MINOR and PATCH version numbers, but different patch same MAJOR, MINOR and PATCH version numbers, but different patch
skipping to change at page 8, line 37 skipping to change at page 9, line 5
"X.Y.Z+1_non_compatible" MUST be used instead. "X.Y.Z+1_non_compatible" MUST be used instead.
2. Under some circumstances (e.g., to avoid adding a "_compatible" 2. Under some circumstances (e.g., to avoid adding a "_compatible"
modifier) an artifact author MAY also update the MAJOR version modifier) an artifact author MAY also update the MAJOR version
when the only changes are backwards-compatible. This is where when the only changes are backwards-compatible. This is where
tooling is important to highlight all changes. Because, while tooling is important to highlight all changes. Because, while
avoiding the "_compatible" and "_non_compatible" modifiers have a avoiding the "_compatible" and "_non_compatible" modifiers have a
clear advantage, bumping a MAJOR version when changes are clear advantage, bumping a MAJOR version when changes are
entirely backwards-compatible may confuse end users. entirely backwards-compatible may confuse end users.
3. If an artifact is being updated in a backwards-compatible way, 3. An artifact author MAY choose to skip version numbers. That is,
an artifact's revision history can include 1.0.0, 1.1.0, and
1.3.0 where 1.2.0 is skipped. Note that doing so has an impact
when importing modules by revision-or-derived. See Section 4 for
more details on importing modules with revision-label version
gaps.
4. If an artifact is being updated in a backwards-compatible way,
then the next version number depends on the format of the current then the next version number depends on the format of the current
version number: version number:
i "X.Y.Z" - the artifact version MUST be updated to i "X.Y.Z" - the artifact version MUST be updated to "X.Y+1.0",
"X.Y+1.0", unless that artifact version has already been unless that artifact version has already been defined with
defined with different content, when the artifact version different content, when the artifact version MUST be updated
MUST be updated to "X.Y.Z+1_compatible"" instead. to "X.Y.Z+1_compatible"" instead.
ii "X.Y.Z_compatible" - the artifact version MUST be updated ii "X.Y.Z_compatible" - the artifact version MUST be updated to
to "X.Y.Z+1_compatible". "X.Y.Z+1_compatible".
iii "X.Y.Z_non_compatible" - the artifact version MUST be iii "X.Y.Z_non_compatible" - the artifact version MUST be
updated to "X.Y.Z+1_non_compatible". updated to "X.Y.Z+1_non_compatible".
4. If an artifact is being updated in an editorial way, then the 5. If an artifact is being updated in an editorial way, then the
next version number depends on the format of the current version next version number depends on the format of the current version
number: number:
i "X.Y.Z" - the artifact version MUST be updated to "X.Y.Z+1" i "X.Y.Z" - the artifact version MUST be updated to "X.Y.Z+1"
ii "X.Y.Z_compatible" - the artifact version MUST be updated ii "X.Y.Z_compatible" - the artifact version MUST be updated to
to "X.Y.Z+1_compatible". "X.Y.Z+1_compatible".
iii "X.Y.Z_non_compatible" - the artifact version MUST be iii "X.Y.Z_non_compatible" - the artifact version MUST be
updated to "X.Y.Z+1_non_compatible". updated to "X.Y.Z+1_non_compatible".
5. YANG artifact semantic version numbers beginning with 0, i.e 6. YANG artifact semantic version numbers beginning with 0, i.e
"0.X.Y" are regarded as beta definitions and need not follow the "0.X.Y" are regarded as beta definitions and need not follow the
rules above. Either the MINOR or PATCH version numbers may be rules above. Either the MINOR or PATCH version numbers may be
updated, regardless of whether the changes are non-backwards- updated, regardless of whether the changes are non-backwards-
compatible, backwards-compatible, or editorial. See Section 5 compatible, backwards-compatible, or editorial. See Section 5
for more details on using this notation during module for more details on using this notation during module
development. development.
3.4. Examples of the YANG Semver Label 3.4. Examples of the YANG Semver Label
3.4.1. Example Module Using YANG Semver 3.4.1. Example Module Using YANG Semver
skipping to change at page 11, line 44 skipping to change at page 12, line 15
import example-module { import example-module {
rev:revision-or-derived "3.0.0"; rev:revision-or-derived "3.0.0";
} }
Note: the import lookup does not stop when a non-backward-compatible 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 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 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 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. 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 5. Guidelines for Using Semver During Module Development
This section and the IETF-specific sub-section below provides YANG This section and the IETF-specific sub-section below provides YANG
semver-specific guidelines to consider when developing new YANG semver-specific guidelines to consider when developing new YANG
modules. As such this section updates [RFC8407]. modules. As such this section updates [RFC8407] .
Development of a brand new YANG module outside of the IETF that uses Development of a brand new YANG module outside of the IETF that uses
YANG semver as its revision-label scheme SHOULD begin with a 0 for YANG semver as its revision-label scheme SHOULD begin with a 0 for
the MAJOR version component. This allows the module to disregard the MAJOR version component. This allows the module to disregard
strict semver rules with respect to non-backwards-compatible changes strict semver rules with respect to non-backwards-compatible changes
during its initial development. However, module developers MAY during its initial development. However, module developers MAY
choose to use the semver pre-release syntax instead with a 1 for the choose to use the semver pre-release syntax instead with a 1 for the
MAJOR version component. For example, an initial module revision- MAJOR version component. For example, an initial module revision-
label might be either 0.0.1 or 1.0.0-alpha.1. If the authors choose 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 to use the 0 MAJOR version component scheme, they MAY switch to the
skipping to change at page 13, line 14 skipping to change at page 13, line 39
might be 2.0.0-202005-alpha.1 if keeping the same year and month might be 2.0.0-202005-alpha.1 if keeping the same year and month
notation mentioned above). notation mentioned above).
5.1. Pre-release Version Precedence 5.1. Pre-release Version Precedence
[TODO: Describe precedence considering there could be changes during [TODO: Describe precedence considering there could be changes during
development and parallel development tracks.] development and parallel development tracks.]
5.2. YANG Semver in IETF Modules 5.2. YANG Semver in IETF Modules
All publish IETF modules MUST use YANG semantic versions for their
revision-labels. For IETF YANG modules that have already been
published, revision labels MUST be retrospectively 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 .
Net new module development within the IETF SHOULD begin with the 0 Net new module development within the IETF SHOULD begin with the 0
MAJOR number scheme as described above. When revising an existing MAJOR number scheme as described above. When revising an existing
IETF module, the revision-label MUST use the target (i.e., intended) IETF module, the revision-label MUST use the target (i.e., intended)
MAJOR and MINOR version components with a 0 patch version component. MAJOR and MINOR version components with a 0 PATCH version component.
If the intended ratified release will be non-backward-compatible with If the intended ratified release will be non-backward-compatible with
the current ratified release, the MINOR version component MUST be 0. the current ratified release, the MINOR version component MUST be 0.
All IETF modules in development MUST use the whole document name as a All IETF modules in development MUST use the whole document name as a
pre-release version string, including the current document revision. pre-release version string, including the current document revision.
For example, if a module which is currently released at version 1.0.0 For example, if a module which is currently released at version 1.0.0
is being revised to include non-backwards-compatible changes in is being revised to include non-backwards-compatible changes in
draft-user-netmod-foo, its development revision-labels MUST include draft-user-netmod-foo, its development revision-labels MUST include
2.0.0-draft-user-netmod-foo followed by the document's revision 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- (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. Even release version is unique across the lifecycle of the module. Even
when using the 0 MAJOR version for initial module development (where when using the 0 MAJOR version for initial module development (where
MINOR and PATCH can change), appending the draft name as a pre- MINOR and PATCH can change), appending the draft name as a pre-
release component helps to ensure uniqueness when there are perhaps release component helps to ensure uniqueness when there are perhaps
multiple, parallel efforts creating the same module. multiple, parallel efforts creating the same module.
If a module is being revised and the original module never had a If a module is being revised and the original module never had a
revision-label (i.e., you wish to start using YANG semver in future revision-label (i.e., you wish to start using YANG semver in future
module revisions), choose a semver value that makes the most sense module revisions), choose a semver value that makes the most sense
based on the module's history. For example, if a module started out based on the module's history. For example, if a module started out
in the pre-NMDA ([RFC8342]) world, and then had NMDA support added in the pre-NMDA ([RFC8342] ) world, and then had NMDA support added
without removing any legacy "state" branches -- and you are looking without removing any legacy "state" branches -- and you are looking
to add additional new features -- a sensible choice for the target 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, 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). 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. See Appendix A for a detailed example of IETF pre-release versions.
6. YANG Module 6. YANG Module
This YANG module contains the typedef for the YANG semantic version. This YANG module contains the typedef for the YANG semantic version.
<CODE BEGINS> file "ietf-yang-semver@2019-09-06.yang" <CODE BEGINS> file "ietf-yang-semver@2020-06-30.yang"
module ietf-yang-semver { module ietf-yang-semver {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver";
prefix yangver; prefix yangver;
rev:revision-label-scheme "yang-semver"; rev:revision-label-scheme "yang-semver";
import ietf-yang-revisions { import ietf-yang-revisions {
prefix rev; prefix rev;
} }
organization organization
"IETF NETMOD (Network Modeling) Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Joe Clarke Author: Joe Clarke
<mailto:jclarke@cisco.com>"; <mailto:jclarke@cisco.com>";
description description
"This module provides type and grouping definitions for YANG "This module provides type and grouping definitions for YANG
packages. packages.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
revision 2020-06-30 { revision 2020-06-30 {
rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-01"; rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-01";
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Semantic Versioning."; "RFC XXXX: YANG Semantic Versioning.";
} }
/*
* Identities
*/
identity yang-semver { /*
base rev:revision-label-scheme-base-identity; * Identities
description */
"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.";
reference
"RFC XXXX: YANG Semantic Versioning.";
}
/* identity yang-semver {
* Typedefs base rev:revision-label-scheme-base-identity;
*/ description
"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.";
typedef version { reference
type string { "RFC XXXX: YANG Semantic Versioning.";
pattern '\d+[.]\d+[.]\d+(_(non_)?compatible)?(-[\w\d.]+)?([+][\w\d\.]+)?'; }
}
description /*
"Represents a YANG semantic version number. The rules governing the * Typedefs
use of this revision label scheme are defined in the reference for */
this typedef.";
reference typedef version {
"RFC XXXX: YANG Semantic Versioning."; type string {
} pattern '\d+[.]\d+[.]\d+(_(non_)?compatible)?(-[\w\d.]+)?([+][\w\d\.]+)?';
} }
<CODE ENDS> description
"Represents a YANG semantic version number. The rules governing the
use of this revision label scheme are defined in the reference for
this typedef.";
reference
"RFC XXXX: YANG Semantic Versioning.";
}
}
<CODE ENDS>
7. Contributors 7. Contributors
This document grew out of the YANG module versioning design team that This document grew out of the YANG module versioning design team that
started after IETF 101. The design team consists of the following started after IETF 101. The design team consists of the following
members whom have worked on the YANG versioning project: members whom have worked on the YANG versioning project:
o Balazs Lengyel * Balazs Lengyel
o Benoit Claise * Benoit Claise
o Ebben Aries * Ebben Aries
o Jason Sterne * Jason Sterne
o Joe Clarke
o Juergen Schoenwaelder * Joe Clarke
o Mahesh Jethanandani * Juergen Schoenwaelder
o Michael (Wangzitao) * Mahesh Jethanandani
o Qin Wu * Michael (Wangzitao)
o Reshad Rahman * Qin Wu
o Rob Wilton * Reshad Rahman
* Rob Wilton
The initial revision of this document was refactored and built upon The initial revision of this document was refactored and built upon
[I-D.clacla-netmod-yang-model-update]. [I-D.clacla-netmod-yang-model-update] .
Discussons on the use of Semver for YANG versioning has been held Discussons on the use of Semver for YANG versioning has been held
with authors of the OpenConfig YANG models based on their own with authors of the OpenConfig YANG models based on their own
[openconfigsemver]. We would like thank both Anees Shaikh and Rob [openconfigsemver] . We would like thank both Anees Shaikh and Rob
Shakir for their input into this problem space. Shakir for their input into this problem space.
8. Security Considerations 8. Security Considerations
The document does not define any new protocol or data model. There The document does not define any new protocol or data model. There
are no security impacts. are no security impacts.
9. IANA Considerations 9. IANA Considerations
None. 9.1. YANG Module Registrations
The following YANG module is requested to be registred in the "IANA
Module Names" registry:
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
Note for IANA (to be removed by the RFC editor): Please check that
the registries and IANA YANG modules are referenced in the
appropriate way.
IANA is responsible for maintaining and versioning some YANG modules,
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 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 that have already been
published, revision labels MUST be retrospectively 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 .
Most changes to IANA maintained YANG modules 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 major 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. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-netmod-yang-module-versioning]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "Updated YANG Module
Revision Handling", draft-ietf-netmod-yang-module-
versioning-00 (work in progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
[I-D.ietf-netmod-yang-module-versioning]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., Sterne,
J., Claise, B., and K. D'Souza, "Updated YANG Module
Revision Handling", Work in Progress, Internet-Draft,
draft-ietf-netmod-yang-module-versioning-01, 10 July 2020,
<https://tools.ietf.org/html/draft-ietf-netmod-yang-
module-versioning-01>.
10.2. Informative References 10.2. Informative References
[I-D.clacla-netmod-yang-model-update] [I-D.clacla-netmod-yang-model-update]
Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New
YANG Module Update Procedure", draft-clacla-netmod-yang- YANG Module Update Procedure", Work in Progress, Internet-
model-update-06 (work in progress), July 2018. Draft, draft-clacla-netmod-yang-model-update-06, 2 July
2018, <https://tools.ietf.org/html/draft-clacla-netmod-
yang-model-update-06>.
[I-D.ietf-netmod-yang-packages] [I-D.ietf-netmod-yang-packages]
Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo, Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,
"YANG Packages", draft-ietf-netmod-yang-packages-00 (work "YANG Packages", Work in Progress, Internet-Draft, draft-
in progress), March 2020. ietf-netmod-yang-packages-01, 2 November 2020,
<https://tools.ietf.org/html/draft-ietf-netmod-yang-
[openconfigsemver] packages-01>.
"Semantic Versioning for Openconfig Models",
<http://www.openconfig.net/docs/semver/>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[openconfigsemver]
"Semantic Versioning for Openconfig Models",
<http://www.openconfig.net/docs/semver/>.
[semver] "Semantic Versioning 2.0.0", <https://www.semver.org>. [semver] "Semantic Versioning 2.0.0", <https://www.semver.org>.
[IfTypeYang]
"iana-if-type YANG Module",
<https://www.iana.org/assignments/iana-if-type/iana-if-
type.xhtml>.
[RoutingTypesYang]
"iana-routing-types YANG Module",
<https://www.iana.org/assignments/iana-routing-types/iana-
routing-types.xhtml>.
Appendix A. Example IETF Module Development Appendix A. Example IETF Module Development
Assume a new YANG module is being developed in the netmod working Assume a new YANG module is being developed in the netmod working
group in the IETF. Initially, this module is being developed in an group in the IETF. Initially, this module is being developed in an
individual internet draft, draft-jdoe-netmod-example-module. The individual internet draft, draft-jdoe-netmod-example-module. The
following represents the initial version tree (i.e., value of following represents the initial version tree (i.e., value of
revision-label) of the module as it's being initially developed. revision-label) of the module as it's being initially developed.
Version lineage for initial module development: Version lineage for initial module development:
skipping to change at page 19, line 18 skipping to change at page 21, line 10
| |
1.1.0-draft-ietf-netmod-exmod-changes-02 1.1.0-draft-ietf-netmod-exmod-changes-02
| |
1.1.0-draft-ietf-netmod-exmod-changes-03 1.1.0-draft-ietf-netmod-exmod-changes-03
The draft is ratified, and the new module version becomes 1.1.0. The draft is ratified, and the new module version becomes 1.1.0.
Authors' Addresses Authors' Addresses
Benoit Claise Benoit Claise
Cisco Systems, Inc. Huawei
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622 Email: benoit.claise@huawei.com
Email: bclaise@cisco.com
Joe Clarke (editor) Joe Clarke (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
7200-12 Kit Creek Rd 7200-12 Kit Creek Rd
Research Triangle Park, North Carolina Research Triangle Park, North Carolina
United States of America United States of America
Phone: +1-919-392-2867 Phone: +1-919-392-2867
Email: jclarke@cisco.com Email: jclarke@cisco.com
skipping to change at page 20, line 4 skipping to change at page 21, line 32
Reshad Rahman Reshad Rahman
Cisco Systems, Inc. Cisco Systems, Inc.
Email: rrahman@cisco.com Email: rrahman@cisco.com
Robert Wilton (editor) Robert Wilton (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: rwilton@cisco.com Email: rwilton@cisco.com
Balazs Lengyel Balazs Lengyel
Ericsson Ericsson
Magyar Tudosok Korutja
1117 Budapest 1117 Budapest
Magyar Tudosok Korutja
Hungary Hungary
Phone: +36-70-330-7909 Phone: +36-70-330-7909
Email: balazs.lengyel@ericsson.com Email: balazs.lengyel@ericsson.com
Jason Sterne Jason Sterne
Nokia Nokia
Email: jason.sterne@nokia.com Email: jason.sterne@nokia.com
Kevin D'Souza Kevin D'Souza
AT&T AT&T
200 S. Laurel Ave 200 S. Laurel Ave
Middletown, NJ Middletown, NJ
United States of America United States of America
Email: kd6913@att.com Email: kd6913@att.com
 End of changes. 81 change blocks. 
186 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/