< draft-ietf-netmod-yang-semver-04.txt		draft-ietf-netmod-yang-semver-05.txt >
	Network Working Group J. Clarke, Ed.		Network Working Group J. Clarke, Ed.
	Internet-Draft R. Wilton, Ed.		Internet-Draft R. Wilton, Ed.
	Updates: 8407 (if approved) Cisco Systems, Inc.		Updates: 8407 (if approved) Cisco Systems, Inc.
	Intended status: Standards Track R. Rahman		Intended status: Standards Track R. Rahman
	Expires: 28 April 2022		Expires: 12 May 2022
	B. Lengyel		B. Lengyel
	Ericsson		Ericsson
	J. Sterne		J. Sterne
	Nokia		Nokia
	B. Claise		B. Claise
	Huawei		Huawei
	25 October 2021		8 November 2021
	YANG Semantic Versioning		YANG Semantic Versioning
	draft-ietf-netmod-yang-semver-04		draft-ietf-netmod-yang-semver-05
	Abstract		Abstract
	This document specifies a scheme and guidelines for applying an		This document specifies a scheme and guidelines for applying an
	extended set of semantic versioning rules to revisions of YANG		extended set of semantic versioning rules to revisions of YANG
	artifacts (e.g., modules and packages). Additionally, this document		artifacts (e.g., modules and packages). Additionally, this document
	defines an RFCAAAA-compliant revision-label-scheme for this YANG		defines an RFCAAAA-compliant revision-label-scheme for this YANG
	semantic versioning scheme.		semantic versioning scheme.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 42 ¶		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 28 April 2022.		This Internet-Draft will expire on 12 May 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	3.2. Semantic Versioning Scheme for YANG Artifacts . . . . . . 4		3.2. Semantic Versioning Scheme for YANG Artifacts . . . . . . 4
	3.2.1. YANG Semver with submodules . . . . . . . . . . . . . 7		3.2.1. YANG Semver with submodules . . . . . . . . . . . . . 7
	3.2.2. Examples for YANG semantic versions . . . . . . . . . 7		3.2.2. Examples for YANG semantic versions . . . . . . . . . 7
	3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 9		3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 9
	3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 11		3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 11
	3.4.1. Example Module Using YANG Semver . . . . . . . . . . 11		3.4.1. Example Module Using YANG Semver . . . . . . . . . . 11
	3.4.2. Example of Package Using YANG Semver . . . . . . . . 13		3.4.2. Example of Package Using YANG Semver . . . . . . . . 13
	4. Import Module by Semantic Version . . . . . . . . . . . . . . 13		4. Import Module by Semantic Version . . . . . . . . . . . . . . 13
	5. Guidelines for Using Semver During Module Development . . . . 14		5. Guidelines for Using Semver During Module Development . . . . 14
	5.1. Pre-release Version Precedence . . . . . . . . . . . . . 15		5.1. Pre-release Version Precedence . . . . . . . . . . . . . 15
	5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 15		5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 16
	6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16		6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 19		9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 20
	9.2. Guidance for YANG Semver in IANA maintained YANG modules		9.2. Guidance for YANG Semver in IANA maintained YANG modules
	and submodules . . . . . . . . . . . . . . . . . . . . . 20		and submodules . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 21
	10.2. Informative References . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Example IETF Module Development . . . . . . . . . . 22		Appendix A. Example IETF Module Development . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		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 scheme that uses the revision history as a		previous revision, and a scheme that uses the revision history as a
	lineage for determining from where a specific revision of a YANG		lineage for determining from where a specific revision of a YANG
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	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 and submodule versioned using the YANG semantic		Every YANG module and submodule versioned using the YANG semantic
	versioning scheme specifies the module's or submodule's semantic		versioning scheme specifies the module's or submodule's semantic
	version number as the argument to the 'rev:revision-label' statement.		version 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 YANG Semver will reflect that in		YANG packages that make use of this YANG Semver will reflect that in
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 39 ¶
	Note that the meaning of a submodule may change drastically despite		Note that the meaning of a submodule may change drastically despite
	having no changes in content or revision due to changes in other		having no changes in content or revision due to changes in other
	submodules belonging to the same module (e.g. groupings and typedefs		submodules belonging to the same module (e.g. groupings and typedefs
	declared in one submodule and used in another).		declared in one submodule and used in another).
	3.2.2. Examples for YANG semantic versions		3.2.2. Examples for YANG semantic versions
	The following diagram and explanation illustrate how YANG semantic		The following diagram and explanation illustrate how YANG semantic
	versions work.		versions work.
	Example YANG semantic versions for an example artifact:		YANG Semantic versions for an example module:
	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
	| |		| \
	| 1.3.0 -> 1.3.1		2.0.0 \
	|		| \--> 1.3.0 -> 1.3.1_non_compatible
	2.0.0		3.0.0 |
	|		| 1.4.0
	3.0.0		3.1.0
	\
	3.1.0
	Assume the tree diagram above illustrates how an example YANG		The tree diagram above illustrates how the version history might
	module's version history might evolve. For example, the tree might		evolve for an example module. The tree diagram only shows the
	represent the following changes, listed in chronological order of		parent/child ancestry relationships between the revisions. It does
	when the revisions were published, from oldest revision to newest:		not describe the chronology of the revisions (i.e. when in time each
			revision was published relative to the other revisions).
			The following description lists an example of what the chronological
			order of the revisions could look like, from oldest revision to
			newest:
	0.1.0 - first pre-release module version		0.1.0 - first pre-release module version
	0.2.0 - second pre-release 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)		2.0.0 - change existing model for performance reasons, e.g. re-key
			list (NBC)
	1.3.1 - improve description wording for "foo-64" (Editorial)		1.3.0 - improve existing functionality, added leaf "foo-64" (BC)
	1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid		1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid
	implementing "baz" from 1.2.0 (BC)		implementing "baz" from 1.2.0. This revision was created after
			1.2.0 otherwise it may have been released as 1.2.0. (BC)
	2.0.0 - change existing model for performance reasons, e.g. re-key		3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf
	list (NBC)		"wibble"; (NBC)
			1.3.1_non_compatible - backport NBC fix, rename "baz" to "bar"
			(NBC)
			1.2.1_non_compatible - backport NBC fix, rename "baz" to "bar"
			(NBC)
	1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0		1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0
	due to model changes (NBC)		due to model changes (NBC)
	3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf		1.4.0 - introduce new leaf "ghoti" (BC)
	"wibble"; (NBC)
	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
	"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		1.2.2_non_compatible - backport "wibble". This is a BC change but
			"non_compatible" modifier is sticky. (BC)
			The partial ancestry relationships based on the semantic versioning
	numbers are 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 < 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
			1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.3.1_non_compatible
			1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.4.0
	There is no ordering relationship between 1.1.1_non_compatible and		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
	common ancestor of 1.1.0.		common ancestor of 1.1.0.
	Looking at the version number alone, the module definition in 2.0.0		Looking at the version number alone does not indicate ancestry. The
	does not necessarily contain the contents of 1.3.0. However, the		module definition in 2.0.0, for example, does not contain all the
	module revision history in 2.0.0 may well indicate that it was edited		contents of 1.3.0. Version 2.0.0 is not derived from 1.3.0.
	from module version 1.3.0.
	3.3. YANG Semantic Version Update Rules		3.3. YANG Semantic Version Update Rules
	When a new revision of an artifact is produced, then the following		When a new revision of an artifact is produced, then the following
	rules define how the YANG semantic version number for the new		rules define how the YANG semantic version for the new artifact
	artifact revision is calculated, based on the changes between the two		revision is calculated, based on the changes between the two artifact
	artifact revisions, and the YANG semantic version number of the base		revisions, and the YANG semantic version of the base artifact
	artifact revision from which the changes are derived.		revision from which the changes are derived.
	The following four rules specify the RECOMMENDED, and REQUIRED		The following four rules specify the RECOMMENDED, and REQUIRED
	minimum, update to a YANG semantic version number:		minimum, update to a YANG semantic version:
	1. If an artifact is being updated in a non-backwards-compatible		1. If an artifact is being updated in a non-backwards-compatible
	way, then the artifact version		way, then the artifact version
	"X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to		"X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to
	"X+1.0.0" unless that version has already been used for this		"X+1.0.0" unless that version has already been used for this
	artifact but with different content, in which case the artifact		artifact but with different content, in which case the artifact
	version "X.Y.Z+1_non_compatible" SHOULD be used instead.		version "X.Y.Z+1_non_compatible" SHOULD be used instead.
	2. If an artifact is being updated in a backwards-compatible way,		2. 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
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 33 ¶
	Although YANG Semver always indicates when a non-backwards-		Although YANG Semver always indicates when a non-backwards-
	compatible, or backwards-compatible change may have occurred to a		compatible, or backwards-compatible change may have occurred to a
	YANG artifact, it does not guarantee that such a change has occurred,		YANG artifact, it does not guarantee that such a change has occurred,
	or that consumers of that YANG artifact will be impacted by the		or that consumers of that YANG artifact will be impacted by the
	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:non-
	changes" extension statement to indicate where non-backwards-		backwards-compatible" extension statement to indicate where non-
	compatible changes have occurred in the module revision history. If		backwards-compatible changes have occurred in the module revision
	a revision entry in a module's revision history includes the		history. If a revision entry in a module's revision history includes
	"rev:nbc-changes" statement then that MUST be reflected in any YANG		the "rev:non-backwards-compatible" statement then that MUST be
	semantic version associated with that revision. However, the reverse		reflected in any YANG semantic version associated with that revision.
	does not necessarily hold, i.e., if the MAJOR version has been		However, the reverse does not necessarily hold, i.e., if the MAJOR
	incremented it does not necessarily mean that a "rev:nbc-changes"		version has been incremented it does not necessarily mean that a
	statement would be present.		"rev:non-backwards-compatible" 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 "ysver:yang-semver";
	import ietf-yang-revisions { prefix "rev"; }
	import ietf-yang-semver { prefix "ysver"; }
	description
	"to be completed";
	revision 2018-02-28 {
	description "Added leaf 'wobble'";
	rev:revision-label 3.1.0;
	}
	revision 2017-12-31 {		import ietf-yang-revisions { prefix "rev"; }
	description "Rename 'baz' to 'bar', added leaf 'wibble'";		import ietf-yang-semver { prefix "ysver"; }
	rev:revision-label 3.0.0;
	rev:nbc-changes;
	}
	revision 2017-10-30 {		description
	description "Change the module structure";		"to be completed";
	rev:revision-label 2.0.0;
	rev:nbc-changes;
	}
	revision 2017-08-30 {		revision 2017-08-30 {
	description "Clarified description of 'foo-64' leaf";		description "Backport 'wibble' leaf";
	rev:revision-label 1.3.1;		rev:revision-label 1.2.2_non_compatible;
	}		}
	revision 2017-07-30 {		revision 2017-07-30 {
	description "Added leaf foo-64";		description "Rename 'baz' to 'bar'";
	rev:revision-label 1.3.0;		rev:revision-label 1.2.1_non_compatible;
	}		rev:non-backwards-compatible;
			}
	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-02-07 {		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.
			// The following pre-release revision statements would not
			// appear in any final published version of a module. They
			// are removed when the final version is published.
			// During the pre-release phase of development, only a
			// single one of these revision statements would appear
	revision 2017-01-30 {		// revision 2017-01-30 {
	description "NBC changes to initial revision";		// description "NBC changes to initial revision";
	semver:module-version 0.2.0;		// rev:revision-label 0.2.0;
	}		// rev:non-backwards-compatible; // optional
			// // (theoretically no
			// // 'previous released version')
			// }
	revision 2017-01-26 {		// revision 2017-01-26 {
	description "Initial module version";		// description "Initial module version";
	semver:module-version 0.1.0;		// rev:revision-label 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 16, line 46 ¶		skipping to change at page 17, line 5 ¶
	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
	and the identity to signal its use.		and the identity to signal its use.
	<CODE BEGINS> file "ietf-yang-semver@2021-10-20.yang"		<CODE BEGINS> file "ietf-yang-semver@2021-11-04.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 ysver;		prefix ysver;
	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>
	Author: Benoit Claise
	<mailto:benoit.claise@huawei.com>
	Author: Reshad Rahman
	<mailto:reshad@yahoo.com>
	Author: Robert Wilton		Author: Robert Wilton
	<mailto:rwilton@cisco.com>		<mailto:rwilton@cisco.com>
			Author: Reshad Rahman
			<mailto:reshad@yahoo.com>
	Author: Balazs Lengyel		Author: Balazs Lengyel
	<mailto:balazs.lengyel@ericsson.com>		<mailto:balazs.lengyel@ericsson.com>
	Author: Jason Sterne		Author: Jason Sterne
	<mailto:jason.sterne@nokia.com>";		<mailto:jason.sterne@nokia.com>
			Author: Benoit Claise
			<mailto:benoit.claise@huawei.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) 2021 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
	skipping to change at page 17, line 45 ¶		skipping to change at page 18, line 4 ¶
	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".		// RFC Ed. update the rev:revision-label to "1.0.0".
	revision 2021-10-20 {		revision 2021-11-04 {
	rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-04";		rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-05";
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Semantic Versioning.";		"RFC XXXX: YANG Semantic Versioning.";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 37 ¶
	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 rev:revision-label {
	pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?(-[A-Za-z0-9.-]+)?([+][A-Za-z0-9.-]+)?';		pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?'
			+ '(-[A-Za-z0-9.-]+[.-][0-9]+)?([+][A-Za-z0-9.-]+)?';
	}		}
	description		description
	"Represents a YANG semantic version number. The rules governing the		"Represents a YANG semantic version. The rules governing the
	use of this revision label scheme are defined in the reference for		use of this revision label scheme are defined in the reference for
	this typedef.";		this typedef.";
	reference		reference
	"RFC XXXX: YANG Semantic Versioning.";		"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
	* Benoit Claise		* Benoit Claise
			* Bo Wu
	* Ebben Aries		* Ebben Aries
			* Jan Lindblad
	* Jason Sterne		* Jason Sterne
	* Joe Clarke		* Joe Clarke
	* Juergen Schoenwaelder		* Juergen Schoenwaelder
	* Mahesh Jethanandani		* Mahesh Jethanandani
	* Michael (Wangzitao)		* Michael (Wangzitao)
	skipping to change at page 21, line 41 ¶		skipping to change at page 22, line 5 ¶
	[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., and J.		Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
	Sterne, "Updated YANG Module Revision Handling", Work in		Sterne, "Updated YANG Module Revision Handling", Work in
	Progress, Internet-Draft, draft-ietf-netmod-yang-module-		Progress, Internet-Draft, draft-ietf-netmod-yang-module-
	versioning-03, 12 July 2021,		versioning-04, 25 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		<https://tools.ietf.org/html/draft-ietf-netmod-yang-
	yang-module-versioning-03>.		module-versioning-04>.
	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://datatracker.ietf.org/doc/html/draft-clacla-		2018, <https://tools.ietf.org/html/draft-clacla-netmod-
	netmod-yang-model-update-06>.		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-02, 25 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		<https://tools.ietf.org/html/draft-ietf-netmod-yang-
	yang-packages-01>.		packages-02>.
	[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,		01, 2 November 2020, <https://tools.ietf.org/html/draft-
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		ietf-netmod-yang-schema-comparison-01>.
	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 23, line 26 ¶		skipping to change at page 23, line 41 ¶
	Continued version lineage after adoption:		Continued version lineage after adoption:
	1.0.0-draft-ietf-netmod-example-module-00		1.0.0-draft-ietf-netmod-example-module-00
	|		|
	1.0.0-draft-ietf-netmod-example-module-01		1.0.0-draft-ietf-netmod-example-module-01
	|		|
	1.0.0-draft-ietf-netmod-example-module-02		1.0.0-draft-ietf-netmod-example-module-02
	At this point, the draft is ratified and becomes RFC12345 and the		At this point, the draft is ratified and becomes RFC12345 and the
	YANG module version number becomes 1.0.0.		YANG module version becomes 1.0.0.
	A time later, the module needs to be revised to add additional		A time later, the module needs to be revised to add additional
	capabilities. Development will be done in a backwards-compatible		capabilities. Development will be done in a backwards-compatible
	way. Two new individual drafts are proposed to go about adding the		way. Two new individual drafts are proposed to go about adding the
	capabilities in different ways: draft-jdoe-netmod-exmod-enhancements		capabilities in different ways: draft-jdoe-netmod-exmod-enhancements
	and draft-jadoe-netmod-exmod-changes. These are initially developed		and draft-jadoe-netmod-exmod-changes. These are initially developed
	in parallel with the following versions.		in parallel with the following versions.
	Parallel development for next module revision:		Parallel development for next module revision:
End of changes. 52 change blocks.
	144 lines changed or deleted		153 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/