< draft-ietf-netmod-yang-semver-03.txt   draft-ietf-netmod-yang-semver-04.txt >
Network Working Group B. Claise Network Working Group J. Clarke, Ed.
Internet-Draft Huawei Internet-Draft R. Wilton, Ed.
Updates: 8407 (if approved) J. Clarke, Ed. Updates: 8407 (if approved) Cisco Systems, Inc.
Intended status: Standards Track R. Rahman Intended status: Standards Track R. Rahman
Expires: 13 January 2022 R. Wilton, Ed. Expires: 28 April 2022
Cisco Systems, Inc.
B. Lengyel B. Lengyel
Ericsson Ericsson
J. Sterne J. Sterne
Nokia Nokia
K. D'Souza B. Claise
AT&T Huawei
12 July 2021 25 October 2021
YANG Semantic Versioning YANG Semantic Versioning
draft-ietf-netmod-yang-semver-03 draft-ietf-netmod-yang-semver-04
Abstract Abstract
This document specifies a scheme and guidelines for applying a This document specifies a scheme and guidelines for applying an
modified set of semantic versioning rules to revisions of YANG extended set of semantic versioning rules to revisions of YANG
modules. Additionally, this document defines a revision-label for artifacts (e.g., modules and packages). Additionally, this document
this modified semver scheme. defines an RFCAAAA-compliant revision-label-scheme for this YANG
semantic versioning scheme.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 13 January 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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 Semver Pattern . . . . . . . . . . . . . . . . . . . 4
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. YANG Semver with submodules . . . . . . . . . . . . . 7
3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 8 3.2.2. Examples for YANG semantic versions . . . . . . . . . 7
3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 10 3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 9
3.4.1. Example Module Using YANG Semver . . . . . . . . . . 10 3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 11
3.4.2. Example of Package Using YANG Semver . . . . . . . . 12 3.4.1. Example Module Using YANG Semver . . . . . . . . . . 11
4. Import Module by Semantic Version . . . . . . . . . . . . . . 12 3.4.2. Example of Package Using YANG Semver . . . . . . . . 13
5. Guidelines for Using Semver During Module Development . . . . 13 4. Import Module by Semantic Version . . . . . . . . . . . . . . 13
5.1. Pre-release Version Precedence . . . . . . . . . . . . . 14 5. Guidelines for Using Semver During Module Development . . . . 14
5.1. Pre-release Version Precedence . . . . . . . . . . . . . 15
5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 15 5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 15
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 18 9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 19
9.2. Guidance for YANG Semver in IANA maintained YANG modules 9.2. Guidance for YANG Semver in IANA maintained YANG modules
and submodules . . . . . . . . . . . . . . . . . . . . . 19 and submodules . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Example IETF Module Development . . . . . . . . . . 21 Appendix A. Example IETF Module Development . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 and concepts relating to modified rules for updating modules and
submodules, a means to signal when a new revision of a module or submodules, a means to signal when a new revision of a module or
submodule has non-backwards-compatible (NBC) changes compared to its submodule has non-backwards-compatible (NBC) changes compared to its
previous revision, and a versioning scheme that uses the revision previous revision, and a scheme that uses the revision history as a
history as a lineage for determining from where a specific revision lineage for determining from where a specific revision of a YANG
of a YANG module or submodule is derived. Additionally, section 3.3 module or submodule is derived. Additionally, section 3.4 of
of [I-D.ietf-netmod-yang-module-versioning] 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 specific revision.
This document defines a revision-label scheme that uses modified [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 [semver] rules for YANG artifacts (i.e., YANG modules, YANG
submodules, and YANG packages [I-D.ietf-netmod-yang-packages] ) as submodules, and YANG packages [I-D.ietf-netmod-yang-packages] ) as
well as the revision label definition for using this scheme. The well as the revision label definition for using this scheme. The
goal of this is to add a human readable version label that provides goal being to add a human readable revision label that provides
compatibility information for the YANG artifact without one needing compatibility information for the YANG artifact without needing to
to compare or parse its body. The label and rules defined herein compare or parse its body. The label and rules defined herein
represent the RECOMMENDED revision label scheme for IETF YANG represent the RECOMMENDED revision label scheme for IETF YANG
artifacts. artifacts.
Note that a specific revision of the Semver 2.0.0 specification is Note that a specific revision of the Semver 2.0.0 specification is
referenced here (from June 19, 2020) to provide an immutable version. referenced here (from June 19, 2020) to provide an immutable version.
This is because the 2.0.0 version of the specification has changed 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 over time without any change to the semantic version itself. In some
cases the text has changed in non-backwards-compatible ways. cases the text has changed in non-backwards-compatible ways.
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:
* YANG artifact: YANG modules, YANG submodules, and YANG packages * YANG artifact: YANG modules, YANG submodules, and YANG packages
[I-D.ietf-netmod-yang-packages] , and YANG schema elements are [I-D.ietf-netmod-yang-packages] are examples of YANG artifacts for
examples of YANG artifacts for the purposes of this document. 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 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 describes the rules associated with
artifact's semantic version number when its contents are updated. changing an artifact's semantic version when its contents are
updated.
3.1. YANG Semantic Versioning Pattern 3.1. YANG Semver 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:
* 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 or equal to 2147483647 (i.e., the maximum signed 32-bit
and MUST NOT contain leading zeroes integer value) and MUST NOT contain leading zeroes,
* The '.' is a literal period (ASCII character 0x2e) * The '.' is a literal period (ASCII character 0x2e),
* 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 be present if the following COMPAT element is
included included,
* COMPAT, if it is specified, MUST be either the literal string * COMPAT, if 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 when comparing YANG semantic versions, pre-release metadata
during module and submodule development and MUST be considered base MUST be used during module and submodule development as specified in
on Section 5 . Both pre-release and build metadata are allowed in Section 5 . Both pre-release and build metadata are allowed in order
order to support all of the [semver] rules. Thus, a version lineage to support all the [semver] rules. Thus, a version lineage that
that follows strict [semver] rules is allowed for a YANG artifact. follows strict [semver] rules is allowed for a YANG artifact.
To signal the use of this versioning scheme, modules and submodules To signal the use of this versioning scheme, modules and submodules
MUST set the revision-label-scheme extension as defined in MUST set the 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.
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 updates to older versions of YANG versioning scheme supports updates to older versions of YANG
skipping to change at page 5, line 34 skipping to change at page 5, line 40
version number as the argument to the 'rev:revision-label' statement. version number as the argument to the '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
with existing versions of YANG and allow for artifact authors to with existing versions of YANG and allow for artifact authors to
migrate to this scheme, it is not expected that all revisions of a migrate to this scheme, it is not expected that all revisions of a
given YANG artifact will have a semantic version label. For example, given YANG artifact will have a semantic version label. For example,
the first revision of a module or submodule may have been produced the first revision of a module or submodule may have been produced
before this scheme was available. before this scheme was available.
YANG packages that make use of this semantic versioning scheme will YANG packages that make use of this YANG Semver will reflect that in
have their semantic version as the value of the "revision_label" the package metadata.
property.
As stated above, the YANG semver version number is expressed as a As stated above, the YANG semantic version is expressed as a string
string of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent non-
non-negative integers smaller than 2147483647 without leading zeroes, negative integers less than or equal to 2147483647 without leading
and _COMPAT represents an optional suffix of either "_compatible" or zeroes, and _COMPAT represents an optional suffix of either
"_non_compatible". "_compatible" or "_non_compatible".
* '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.
* '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.
skipping to change at page 6, line 17 skipping to change at page 6, line 22
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. Some examples include correcting a spelling mistake any way. Some examples include correcting a spelling mistake
in the description of a leaf within a YANG module or submodule, in the description of a leaf within a YANG module or submodule,
non-significant whitespace changes (e.g. realigning non-significant whitespace changes (e.g., realigning
description statements, or changing indendation), or changes to description statements or changing indendation), or changes to
YANG comments. Note: restructuring how a module uses, or does YANG comments. Note: restructuring how a module uses, or does
not use, submodules is treated as an editorial level change on not use, submodules is treated as an editorial level change on
the condition that there is no change in the module's semantic the condition that there is no change in the module's semantic
behavior due to the restructuring. 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 uniquely identify a
identify a revision of said artifact. There MUST NOT be multiple revision of said artifact. There MUST NOT be multiple instances of a
instances of a YANG artifact definition with the same name and YANG YANG artifact definition with the same name and YANG semantic version
semantic version number but different content (and in the case of but different content (and in the case of modules and submodules,
modules and submodules, different revision dates). 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
modifier strings. E.g., artifact version "1.2.3_non_compatible" MUST 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. NOT be defined if artifact version "1.2.3" has already been defined.
3.2.1. Examples for YANG semantic version numbers 3.2.1. YANG Semver with submodules
The following diagram and explanation illustrates how YANG semantic YANG Semver MAY be used to version submodules. Submodule version are
version numbers work. separate of any version on the including module, but if a submodule
has changed, then the version of the including module MUST also be
updated.
Example YANG semantic version numbers for an example artifact: 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.
Example YANG semantic versions for an example artifact:
0.1.0 0.1.0
| |
0.2.0 0.2.0
| |
1.0.0 1.0.0
| \ | \
| 1.1.0 -> 1.1.1_compatible -> 1.1.2_non_compatible | 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 | 1.2.0 -> 1.2.1_non_compatible -> 1.2.2_non_compatible
skipping to change at page 7, line 25 skipping to change at page 8, line 25
| 1.3.0 -> 1.3.1 | 1.3.0 -> 1.3.1
| |
2.0.0 2.0.0
| |
3.0.0 3.0.0
\ \
3.1.0 3.1.0
Assume the tree diagram above illustrates how an example YANG Assume the tree diagram above illustrates how an example YANG
module's version history might evolve. For example, the tree might module's version history might evolve. For example, the tree might
represent the following changes, listed in chronological order from represent the following changes, listed in chronological order of
oldest revision to newest: when the revisions were published, from oldest revision to newest:
0.1.0 - first beta module version 0.1.0 - first pre-release module version
0.2.0 - second beta module version (with NBC changes) 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.0.0 - first release (may have NBC changes from 0.2.0)
1.1.0 - added new functionality, leaf "foo" (BC) 1.1.0 - added new functionality, leaf "foo" (BC)
1.2.0 - added new functionality, leaf "baz" (BC) 1.2.0 - added new functionality, leaf "baz" (BC)
1.3.0 - improve existing functionality, added leaf "foo-64" (BC) 1.3.0 - improve existing functionality, added leaf "foo-64" (BC)
1.3.1 - improve description wording for "foo-64" (Editorial) 1.3.1 - improve description wording for "foo-64" (Editorial)
skipping to change at page 8, line 12 skipping to change at page 9, line 12
3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf 3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf
"wibble"; (NBC) "wibble"; (NBC)
1.2.1_non_compatible - backport NBC fix, changing "baz" to "bar" 1.2.1_non_compatible - backport NBC fix, changing "baz" to "bar"
1.2.2_non_compatible - backport "wibble". This is a BC change but 1.2.2_non_compatible - backport "wibble". This is a BC change but
"non_compatible" modifier is sticky. "non_compatible" modifier is sticky.
3.1.0 - introduce new leaf "wobble" (BC) 3.1.0 - introduce new leaf "wobble" (BC)
The partial ordering relationships based on the semantic versioning The partial ordering relationships based on the semantic versioning
numbers can be defined as follows: 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.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.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.2.1_non_compatible <
1.2.2_non_compatible 1.2.2_non_compatible
There is no ordering relationship between 1.1.1_non_compatible and 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 either 1.2.0 or 1.2.1_non_compatible, except that they share the
skipping to change at page 9, line 30 skipping to change at page 10, line 30
i "X.Y.Z" - the artifact version SHOULD be updated to i "X.Y.Z" - the artifact version SHOULD be updated to
"X.Y.Z+1" "X.Y.Z+1"
ii "X.Y.Z_compatible" - the artifact version SHOULD be updated ii "X.Y.Z_compatible" - the artifact version SHOULD be updated
to "X.Y.Z+1_compatible". to "X.Y.Z+1_compatible".
iii "X.Y.Z_non_compatible" - the artifact version SHOULD be iii "X.Y.Z_non_compatible" - the artifact version SHOULD be
updated to "X.Y.Z+1_non_compatible". updated to "X.Y.Z+1_non_compatible".
4. YANG artifact semantic version numbers beginning with 0, i.e., 4. 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 pre-release definitions and need not
rules above. Either the MINOR or PATCH version numbers may be follow the rules above. Either the MINOR or PATCH version
updated, regardless of whether the changes are non-backwards- numbers may be updated, regardless of whether the changes are
compatible, backwards-compatible, or editorial. See Section 5 non-backwards-compatible, backwards-compatible, or editorial.
for more details on using this notation during module and See Section 5 for more details on using this notation during
submodule development. module and submodule development.
5. XXX - Add some text about pre-release labels, or perhaps as a 5. Additional pre-release rules for modules that have had at least
rule 5 above. one release are specified in Section 5 .
Although artifacts SHOULD be updated according to the rules above, Although artifacts SHOULD be updated according to the rules above,
which specify the recommended (and minimum required) update to the which specify the recommended (and minimum required) update to the
version number, the following rules MAY be applied when choosing a version number, the following rules MAY be applied when choosing a
new version number: new version number:
1. An artifact author MAY update the version number with a more 1. An artifact author MAY update the version number with a more
significant update than described by the rules above. For significant update than described by the rules above. For
example, an artifact could be given a new MAJOR version number example, an artifact could be given a new MAJOR version number
(i.e., X+1.0.0), even though no non-backwards-compatible changes (i.e., X+1.0.0), even though no non-backwards-compatible changes
skipping to change at page 10, line 26 skipping to change at page 11, line 26
change. Hence, tooling, e.g., change. Hence, tooling, e.g.,
[I-D.ietf-netmod-yang-schema-comparison] , also plays an important [I-D.ietf-netmod-yang-schema-comparison] , also plays an important
role for comparing YANG artifacts and calculating the likely impact role for comparing YANG artifacts and calculating the likely impact
from changes. from changes.
[I-D.ietf-netmod-yang-module-versioning] defines the "rev:nbc- [I-D.ietf-netmod-yang-module-versioning] defines the "rev:nbc-
changes" extension statement to indicate where non-backwards- changes" extension statement to indicate where non-backwards-
compatible changes have occurred in the module revision history. If compatible changes have occurred in the module revision history. If
a revision entry in a module's revision history includes the a revision entry in a module's revision history includes the
"rev:nbc-changes" statement then that MUST be reflected in any YANG "rev:nbc-changes" statement then that MUST be reflected in any YANG
Semver version associated with that revision. However, the reverse semantic version associated with that revision. However, the reverse
does not necessarily hold, i.e., if the MAJOR version has been does not necessarily hold, i.e., if the MAJOR version has been
incremented it does not necessarily mean that a "rev:nbc-changes" incremented it does not necessarily mean that a "rev:nbc-changes"
statement would be present. statement would be present.
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
Below is a sample YANG module that uses the YANG semver revision Below is a sample YANG module that uses the YANG Semver revision-
label based on the rules defined in this document. label based on the rules defined in this document.
module example-versioned-module { module example-versioned-module {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:versioned:module"; namespace "urn:example:versioned:module";
prefix "exvermod"; prefix "exvermod";
rev:revision-label-scheme "yangver:yang-semver"; rev:revision-label-scheme "yangver:yang-semver";
import ietf-yang-revisions { prefix "rev"; } import ietf-yang-revisions { prefix "rev"; }
import ietf-yang-semver { prefix "yangver"; } import ietf-yang-semver { prefix "ysver"; }
description description
"to be completed"; "to be completed";
revision 2018-02-28 { revision 2018-02-28 {
description "Added leaf 'wobble'"; description "Added leaf 'wobble'";
rev:revision-label "3.1.0"; rev:revision-label 3.1.0;
} }
revision 2017-12-31 { revision 2017-12-31 {
description "Rename 'baz' to 'bar', added leaf 'wibble'"; description "Rename 'baz' to 'bar', added leaf 'wibble'";
rev:revision-label "3.0.0"; rev:revision-label 3.0.0;
rev:nbc-changes; rev:nbc-changes;
} }
revision 2017-10-30 { revision 2017-10-30 {
description "Change the module structure"; description "Change the module structure";
rev:revision-label "2.0.0"; rev:revision-label 2.0.0;
rev:nbc-changes; rev:nbc-changes;
} }
revision 2017-08-30 { revision 2017-08-30 {
description "Clarified description of 'foo-64' leaf"; description "Clarified description of 'foo-64' leaf";
rev:revision-label "1.3.1"; rev:revision-label 1.3.1;
} }
revision 2017-07-30 { revision 2017-07-30 {
description "Added leaf foo-64"; description "Added leaf foo-64";
rev:revision-label "1.3.0"; rev:revision-label 1.3.0;
} }
revision 2017-04-20 { revision 2017-04-20 {
description "Add new functionality, leaf 'baz'"; description "Add new functionality, leaf 'baz'";
rev:revision-label "1.2.0"; rev:revision-label 1.2.0;
} }
revision 2017-04-03 { revision 2017-04-03 {
description "Add new functionality, leaf 'foo'"; description "Add new functionality, leaf 'foo'";
rev:revision-label "1.1.0"; rev:revision-label 1.1.0;
} }
revision 2017-04-03 { revision 2017-02-07 {
description "First release version."; description "First release version.";
rev:revision-label "1.0.0"; rev:revision-label 1.0.0;
} }
// Note: semver rules do not apply to 0.X.Y labels. // Note: semver rules do not apply to 0.X.Y labels.
revision 2017-01-30 { revision 2017-01-30 {
description "NBC changes to initial revision"; description "NBC changes to initial revision";
semver:module-version "0.2.0"; semver:module-version 0.2.0;
} }
revision 2017-01-26 { revision 2017-01-26 {
description "Initial module version"; description "Initial module version";
semver:module-version "0.1.0"; semver:module-version 0.1.0;
} }
//YANG module definition starts here //YANG module definition starts here
}
3.4.2. Example of Package Using YANG Semver 3.4.2. Example of Package Using YANG Semver
Below is an example YANG package that uses the semver revision label Below is an example YANG package that uses the semver revision label
based on the rules defined in this document. based on the rules defined in this document.
{ {
"ietf-yang-instance-data:instance-data-set": { "ietf-yang-instance-data:instance-data-set": {
"name": "example-yang-pkg", "name": "example-yang-pkg",
"target-ptr": "TBD", "target-ptr": "TBD",
skipping to change at page 12, line 32 skipping to change at page 13, line 33
"name": "example-yang-pkg", "name": "example-yang-pkg",
"version": "1.3.1", "version": "1.3.1",
... ...
} }
4. Import Module by Semantic Version 4. Import Module by Semantic Version
[I-D.ietf-netmod-yang-module-versioning] allows for imports to be [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 done based on a module or a derived revision of a module. The
rev:revision-or-derived statement can specify either a revision date rev:revision-or-derived statement can specify either a revision date
or a revision label. When importing by semver, the YANG semver or a revision label. The YANG Semver revision-label value can be
revision label value MAY be used as an argument to rev:revision-or- used as the argument to rev:revision-or-derived . When used as such,
derived. When used as such, any module which has that semver label any module that contains exactly the same YANG semantic version in
as its latest revision label or has that label in its revision its revision history may be used to satisfy the import requirement.
history can be used to satisfy the import requirement. For example: For example:
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 If an import by revision-or-derived cannot locate the specified
revision-label in a given module's revision history, that import will 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 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 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-or-derived at 1.2.0 will be unable to locate the specified
revision entry and thus the import cannot be satisfied. 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 or submodule outside of the Development of a brand new YANG module or submodule outside of the
IETF that uses YANG semver as its revision-label scheme SHOULD begin 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 with a 0 for the MAJOR version component. This allows the module or
submodule to disregard strict semver rules with respect to non- submodule to disregard strict semver rules with respect to non-
backwards-compatible changes during its initial development. backwards-compatible changes during its initial development.
However, module or submodule developers MAY choose to use the semver However, module or submodule developers MAY choose to use the semver
pre-release syntax instead with a 1 for the MAJOR version component. pre-release syntax instead with a 1 for the MAJOR version component.
For example, an initial module or submodule revision-label might be 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 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 MAJOR version component scheme, they MAY switch to the pre-release
scheme with a MAJOR version component of 1 when the module or 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 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 revision label may transition from 0.3.0 to 1.0.0-beta.1 to indicate
it is more mature and ready for testing). it is more mature and ready for testing).
When using pre-release notation, the format MUST include at least one When using pre-release notation, the format MUST include at least one
alphabetic component and MUST end with a '.' and then one or more alphabetic component and MUST end with a '.' or '-' and then one or
digits. These alphanumeric components will be used when deciding more digits. These alphanumeric components will be used when
pre-release precedence. The following are examples of valid pre- deciding pre-release precedence. The following are examples of valid
release versions pre-release versions
1.0.0-alpha.1 1.0.0-alpha.1
1.0.0-alpha.3 1.0.0-alpha.3
2.1.0-beta.42 2.1.0-beta.42
3.0.0-202007.rc.1 3.0.0-202007.rc.1
When developing a new revision of an existing module or submodule When developing a new revision of an existing module or submodule
skipping to change at page 15, line 8 skipping to change at page 15, line 45
release-tag and 2.0.0-some-pre-release-tag can each be compared to 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 1.0.0). Module and submodule developers SHOULD maintain only one
revision statement in a pre-released module or submodule that revision statement in a pre-released module or submodule that
reflects the latest revision. IETF authors MAY choose to include an reflects the latest revision. IETF authors MAY choose to include an
appendix in the associated draft to track overall changes to the appendix in the associated draft to track overall changes to the
module or submodule. module or submodule.
5.2. YANG Semver in IETF Modules 5.2. YANG Semver in IETF Modules
All published IETF modules and submodules MUST use YANG semantic All published IETF modules and submodules MUST use YANG semantic
versions for their revision-labels. For IETF YANG modules and versions for their revision-labels.
submodules 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 or submodule development within the IETF SHOULD begin Development of a new module or submodule within the IETF SHOULD begin
with the 0 MAJOR number scheme as described above. When revising an with the 0 MAJOR number scheme as described above. When revising an
existing IETF module or submodule, the revision-label MUST use the existing IETF module or submodule, the revision-label MUST use the
target (i.e., intended) MAJOR and MINOR version components with a 0 target (i.e., intended) MAJOR and MINOR version components with a 0
PATCH version component. If the intended ratified release will be PATCH version component. If the intended ratified release will be
non-backward-compatible with the current ratified release, the MINOR non-backward-compatible with the current ratified release, the MINOR
version component MUST be 0. version component MUST be 0.
All IETF modules and submodules in development MUST use the whole All IETF modules and submodules in development MUST use the whole
document name as a pre-release version string, including the current document name as a pre-release version string, including the current
document revision. For example, if a module or submodule which is document revision. For example, if a module or submodule which is
skipping to change at page 15, line 37 skipping to change at page 16, line 27
backwards-compatible changes in draft-user-netmod-foo, its backwards-compatible changes in draft-user-netmod-foo, its
development revision-labels MUST include 2.0.0-draft-user-netmod-foo 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- 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 foo-02). This will ensure each pre-release version is unique across
the lifecycle of the module or submodule. Even when using the 0 the lifecycle of the module or submodule. Even when using the 0
MAJOR version for initial module or submodule development (where MAJOR version for initial module or submodule 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 or submodule. multiple, parallel efforts creating the same module or submodule.
If a module or submodule is being revised and the original module or For IETF YANG modules and submodules that have already been
submodule never had a revision-label (i.e., you wish to start using published, revision-labels MUST be retroactively applied to all
YANG semver in future module or submodule revisions), choose a semver existing revisions when the next new revision is created, starting at
value that makes the most sense based on the module's or submodule's version "1.0.0" for the initial published revision, and then
history. For example, if a module or submodule started out in the incrementing according to the YANG Semver version rules specified in
pre-NMDA ([RFC8342] ) world, and then had NMDA support added without Section 3.3 . For example, if a module or submodule started out in
removing any legacy "state" branches -- and you are looking to add the pre-NMDA ([RFC8342] ) world, and then had NMDA support added
additional new features -- a sensible choice for the target YANG without removing any legacy "state" branches -- and you are looking
semver would be 1.2.0 (since 1.0.0 would have been the initial, pre- to add additional new features -- a sensible choice for the target
NMDA release, and 1.1.0 would have been the NMDA revision). 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. 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
and the identity to signal its use.
<CODE BEGINS> file "ietf-yang-semver@2020-06-30.yang"
module ietf-yang-semver {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver";
prefix yangver;
rev:revision-label-scheme "yang-semver";
import ietf-yang-revisions { <CODE BEGINS> file "ietf-yang-semver@2021-10-20.yang"
prefix rev; 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;
}
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 Author: Benoit Claise
"This module provides type and grouping definitions for YANG <mailto:benoit.claise@huawei.com>
packages. Author: Reshad Rahman
<mailto:reshad@yahoo.com>
Author: Robert Wilton
<mailto:rwilton@cisco.com>
Author: Balazs Lengyel
<mailto:balazs.lengyel@ericsson.com>
Author: Jason Sterne
<mailto:jason.sterne@nokia.com>";
description
"This module provides type and grouping definitions for YANG
packages.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2021 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.
// RFC Ed. update the rev:revision-label to "1.0.0".
revision 2020-06-30 { revision 2021-10-20 {
rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-01"; rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-04";
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Semantic Versioning."; "RFC XXXX: YANG Semantic Versioning.";
} }
/* /*
* Identities * Identities
*/ */
identity yang-semver { identity yang-semver {
base rev:revision-label-scheme-base-identity; base rev:revision-label-scheme-base;
description description
"The revision-label scheme corresponds to the YANG semver scheme "The revision-label scheme corresponds to the YANG Semver scheme
which is defined by the pattern in the 'version' typedef below. which is defined by the pattern in the 'version' typedef below.
The rules governing this revision-label scheme are defined in the The rules governing this revision-label scheme are defined in the
reference for this identity."; reference for this identity.";
reference reference
"RFC XXXX: YANG Semantic Versioning."; "RFC XXXX: YANG Semantic Versioning.";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef version { typedef version {
type string { type string {
pattern '\d+[.]\d+[.]\d+(_(non_)?compatible)?(-[\w\d.]+)?([+][\w\d\.]+)?'; pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?(-[A-Za-z0-9.-]+)?([+][A-Za-z0-9.-]+)?';
}
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.";
} }
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> <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:
* Balazs Lengyel * Balazs Lengyel
skipping to change at page 18, line 23 skipping to change at page 19, line 23
* Michael (Wangzitao) * Michael (Wangzitao)
* Qin Wu * Qin Wu
* Reshad Rahman * Reshad Rahman
* Rob Wilton * 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] . 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 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
9.1. YANG Module Registrations 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 The following YANG module is requested to be registred in the "IANA
Module Names" registry: Module Names" [RFC6020] . Following the format in RFC 6020, the
following registrations are requested:
The ietf-yang-semver module:
Name: ietf-yang-semver Name: ietf-yang-semver
XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver
Prefix: yangver Prefix: yangver
Reference: [RFCXXXX] Reference: [RFCXXXX]
9.2. Guidance for YANG Semver in IANA maintained YANG modules and 9.2. Guidance for YANG Semver in IANA maintained YANG modules and
skipping to change at page 19, line 26 skipping to change at page 20, line 40
In addition to following the rules specified in the IANA In addition to following the rules specified in the IANA
Considerations section of [I-D.ietf-netmod-yang-module-versioning] , Considerations section of [I-D.ietf-netmod-yang-module-versioning] ,
IANA maintained YANG modules and submodules MUST also include a YANG IANA maintained YANG modules and submodules MUST also include a YANG
Semver revision label for all new revisions, as defined in Section 3 Semver revision label for all new revisions, as defined in Section 3
. .
The YANG Semver version associated with the new revision MUST follow The YANG Semver version associated with the new revision MUST follow
the rules defined in Section 3.3 . the rules defined in Section 3.3 .
Note: For IANA maintained YANG modules and submodules that have Note: For IANA maintained YANG modules and submodules that have
already been published, revision labels MUST be retrospectively already been published, revision labels MUST be retroactively applied
applied to all existing revisions when the next new revision is to all existing revisions when the next new revision is created,
created, starting at version "1.0.0" for the initial published starting at version "1.0.0" for the initial published revision, and
revision, and then incrementing according to the YANG Semver version then incrementing according to the YANG Semver rules specified in
rules specified in Section 3.3 . Section 3.3 .
Most changes to IANA maintained YANG modules and submodules are Most changes to IANA maintained YANG modules and submodules are
expected to be backwards-compatible changes and classified as MINOR expected to be backwards-compatible changes and classified as MINOR
version changes. The PATCH version may be incremented instead when version changes. The PATCH version may be incremented instead when
only editorial changes are made, and the MAJOR version would be only editorial changes are made, and the MAJOR version would be
incremented if non-backwards-compatible major changes are made. incremented if non-backwards-compatible changes are made.
Given that IANA maintained YANG modules and submodules are versioned Given that IANA maintained YANG modules are versioned with a linear
with a linear history, it is anticipated that it should not be history, it is anticipated that it should not be necessary to use the
necessary to use the "_compatible" or "_non_compatible" modifiers to "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT"
the "Z_COMPAT" version element. version element.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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] [I-D.ietf-netmod-yang-module-versioning]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., Sterne, Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
J., Claise, B., and K. D'Souza, "Updated YANG Module Sterne, "Updated YANG Module Revision Handling", Work in
Revision Handling", Work in Progress, Internet-Draft, Progress, Internet-Draft, draft-ietf-netmod-yang-module-
draft-ietf-netmod-yang-module-versioning-02, 22 February versioning-03, 12 July 2021,
2021, <https://tools.ietf.org/html/draft-ietf-netmod-yang- <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
module-versioning-02>. yang-module-versioning-03>.
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", Work in Progress, Internet- YANG Module Update Procedure", Work in Progress, Internet-
Draft, draft-clacla-netmod-yang-model-update-06, 2 July Draft, draft-clacla-netmod-yang-model-update-06, 2 July
2018, <https://tools.ietf.org/html/draft-clacla-netmod- 2018, <https://datatracker.ietf.org/doc/html/draft-clacla-
yang-model-update-06>. 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 B. Wu, Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
"YANG Packages", Work in Progress, Internet-Draft, draft- "YANG Packages", Work in Progress, Internet-Draft, draft-
ietf-netmod-yang-packages-01, 2 November 2020, ietf-netmod-yang-packages-01, 2 November 2020,
<https://tools.ietf.org/html/draft-ietf-netmod-yang- <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
packages-01>. yang-packages-01>.
[I-D.ietf-netmod-yang-schema-comparison] [I-D.ietf-netmod-yang-schema-comparison]
Wilton, R., "YANG Schema Comparison", Work in Progress, Wilton, R., "YANG Schema Comparison", Work in Progress,
Internet-Draft, draft-ietf-netmod-yang-schema-comparison- Internet-Draft, draft-ietf-netmod-yang-schema-comparison-
01, 2 November 2020, <https://tools.ietf.org/html/draft- 01, 2 November 2020,
ietf-netmod-yang-schema-comparison-01>. <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-schema-comparison-01>.
[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] [openconfigsemver]
"Semantic Versioning for Openconfig Models", "Semantic Versioning for Openconfig Models",
<http://www.openconfig.net/docs/semver/>. <http://www.openconfig.net/docs/semver/>.
skipping to change at page 22, line 34 skipping to change at page 24, line 9
1.1.0-draft-ietf-netmod-exmod-changes-01 1.1.0-draft-ietf-netmod-exmod-changes-01
| |
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
Huawei
Email: benoit.claise@huawei.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
Reshad Rahman
Cisco Systems, Inc.
Email: rrahman@cisco.com
Robert Wilton (editor) Robert Wilton (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: rwilton@cisco.com Email: rwilton@cisco.com
Reshad Rahman
Email: reshad@yahoo.com
Balazs Lengyel Balazs Lengyel
Ericsson Ericsson
1117 Budapest 1117 Budapest
Magyar Tudosok Korutja 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 Benoit Claise
AT&T Huawei
200 S. Laurel Ave
Middletown, NJ
United States of America
Email: kd6913@att.com Email: benoit.claise@huawei.com
 End of changes. 91 change blocks. 
246 lines changed or deleted 304 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/