< draft-ietf-netmod-yang-module-versioning-03.txt		draft-ietf-netmod-yang-module-versioning-04.txt >
	Network Working Group R. Wilton, Ed.		Network Working Group R. Wilton, Ed.
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Updates: 7950,8407,8525 (if approved) R. Rahman, Ed.		Updates: 7950, 8407, 8525 (if approved) R. Rahman, Ed.
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 13, 2022 B. Lengyel, Ed.		Expires: 28 April 2022 B. Lengyel, Ed.
	Ericsson		Ericsson
	J. Clarke		J. Clarke
	Cisco Systems, Inc.		Cisco Systems, Inc.
	J. Sterne		J. Sterne
	Nokia		Nokia
	July 12, 2021		25 October 2021
	Updated YANG Module Revision Handling		Updated YANG Module Revision Handling
	draft-ietf-netmod-yang-module-versioning-03		draft-ietf-netmod-yang-module-versioning-04
	Abstract		Abstract
	This document specifies a new YANG module update procedure that can		This document specifies a new YANG module update procedure that can
	document when non-backwards-compatible changes have occurred during		document when non-backwards-compatible changes have occurred during
	the evolution of a YANG module. It extends the YANG import statement		the evolution of a YANG module. It extends the YANG import statement
	with an earliest revision filter to better represent inter-module		with an earliest revision filter to better represent inter-module
	dependencies. It provides help and guidelines for managing the		dependencies. It provides guidelines for managing the lifecycle of
	lifecycle of YANG modules and individual schema nodes. It provides a		YANG modules and individual schema nodes. It provides a mechanism,
	mechanism, via the revision-label YANG extension, to specify a		via the revision-label YANG extension, to specify a revision
	revision identifier for YANG modules and submodules. This document		identifier for YANG modules and submodules. This document updates
	updates RFC 7950, RFC 8407 and RFC 8525.		RFC 7950, RFC 6020, RFC 8407 and RFC 8525.
	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 January 13, 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Updates to YANG RFCs . . . . . . . . . . . . . . . . . . 4		1.1. Updates to YANG RFCs . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4		2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
	3. Refinements to YANG revision handling . . . . . . . . . . . . 5		3. Refinements to YANG revision handling . . . . . . . . . . . . 5
	3.1. Updating a YANG module with a new revision . . . . . . . 6		3.1. Updating a YANG module with a new revision . . . . . . . 6
	3.1.1. Backwards-compatible rules . . . . . . . . . . . . . 6		3.1.1. Backwards-compatible rules . . . . . . . . . . . . . 6
	3.1.2. Non-backwards-compatible changes . . . . . . . . . . 7		3.1.2. Non-backwards-compatible changes . . . . . . . . . . 7
	3.2. non-backwards-compatible revision extension statement . . 7		3.2. non-backwards-compatible revision extension statement . . 7
	3.3. Removing revisions from the revision history . . . . . . 7		3.3. Removing revisions from the revision history . . . . . . 7
	3.4. Revision label . . . . . . . . . . . . . . . . . . . . . 8		3.4. Revision label . . . . . . . . . . . . . . . . . . . . . 9
	3.4.1. File names . . . . . . . . . . . . . . . . . . . . . 8		3.4.1. File names . . . . . . . . . . . . . . . . . . . . . 10
	3.4.2. Revision label scheme extension statement . . . . . . 9		3.4.2. Revision label scheme extension statement . . . . . . 10
	3.5. Examples for updating the YANG module revision history . 9		3.5. Examples for updating the YANG module revision history . 11
	4. Import by derived revision . . . . . . . . . . . . . . . . . 12		4. Import by derived revision . . . . . . . . . . . . . . . . . 13
	4.1. Module import examples . . . . . . . . . . . . . . . . . 14		4.1. Module import examples . . . . . . . . . . . . . . . . . 15
	5. Updates to ietf-yang-library . . . . . . . . . . . . . . . . 15		5. Updates to ietf-yang-library . . . . . . . . . . . . . . . . 16
	5.1. Resolving ambiguous module imports . . . . . . . . . . . 15		5.1. Resolving ambiguous module imports . . . . . . . . . . . 16
	5.2. YANG library versioning augmentations . . . . . . . . . . 16		5.2. YANG library versioning augmentations . . . . . . . . . . 17
	5.2.1. Advertising revision-label . . . . . . . . . . . . . 16		5.2.1. Advertising revision-label . . . . . . . . . . . . . 17
	5.2.2. Reporting how deprecated and obsolete nodes are		5.2.2. Reporting how deprecated and obsolete nodes are
	handled . . . . . . . . . . . . . . . . . . . . . . . 16		handled . . . . . . . . . . . . . . . . . . . . . . . 17
	6. Versioning of YANG instance data . . . . . . . . . . . . . . 17		6. Versioning of YANG instance data . . . . . . . . . . . . . . 18
	7. Guidelines for using the YANG module update rules . . . . . . 17		7. Guidelines for using the YANG module update rules . . . . . . 18
	7.1. Guidelines for YANG module authors . . . . . . . . . . . 17		7.1. Guidelines for YANG module authors . . . . . . . . . . . 19
	7.1.1. Making non-backwards-compatible changes to a YANG		7.1.1. Making non-backwards-compatible changes to a YANG
	module . . . . . . . . . . . . . . . . . . . . . . . 18		module . . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. Versioning Considerations for Clients . . . . . . . . . . 20		7.2. Versioning Considerations for Clients . . . . . . . . . . 21
	8. Module Versioning Extension YANG Modules . . . . . . . . . . 20		8. Module Versioning Extension YANG Modules . . . . . . . . . . 22
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 30		10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	11.1. YANG Module Registrations . . . . . . . . . . . . . . . 30		11.1. YANG Module Registrations . . . . . . . . . . . . . . . 32
	11.2. Guidance for versioning in IANA maintained YANG modules 31		11.2. Guidance for versioning in IANA maintained YANG
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		modules . . . . . . . . . . . . . . . . . . . . . . . . 33
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.1. Normative References . . . . . . . . . . . . . . . . . . 34
	Appendix A. Examples of changes that are NBC . . . . . . . . . . 34		12.2. Informative References . . . . . . . . . . . . . . . . . 35
	Appendix B. Examples of applying the NBC change guidelines . . . 35		Appendix A. Examples of changes that are NBC . . . . . . . . . . 37
	B.1. Removing a data node . . . . . . . . . . . . . . . . . . 35		Appendix B. Examples of applying the NBC change guidelines . . . 37
	B.2. Changing the type of a leaf node . . . . . . . . . . . . 36		B.1. Removing a data node . . . . . . . . . . . . . . . . . . 38
	B.3. Reducing the range of a leaf node . . . . . . . . . . . . 37		B.2. Changing the type of a leaf node . . . . . . . . . . . . 38
	B.4. Changing the key of a list . . . . . . . . . . . . . . . 37		B.3. Reducing the range of a leaf node . . . . . . . . . . . . 39
	B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 38		B.4. Changing the key of a list . . . . . . . . . . . . . . . 39
	B.6. Changing a default value . . . . . . . . . . . . . . . . 39		B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 40
	Appendix C. Changes between revisions . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	This document defines a solution to the YANG module lifecycle		This document defines the foundational pieces of a solution to the
	problems described in [I-D.ietf-netmod-yang-versioning-reqs].		YANG module lifecycle problems described in
	Complementary documents provide a complete solution to the YANG		[I-D.ietf-netmod-yang-versioning-reqs]. Complementary documents
	versioning requirements, with the overall relationship of the		provide other parts of the solution, with the overall relationship of
	solution drafts described in [I-D.ietf-netmod-yang-solutions].		the solution drafts described in [I-D.ietf-netmod-yang-solutions].
	Specifically, this document recognises a need (within standards		Specifically, this document recognises a need (within standards
	organizations, vendors, and the industry) to sometimes allow YANG		organizations, vendors, and the industry) to sometimes allow YANG
	modules to evolve with non-backwards-compatible changes, which could		modules to evolve with non-backwards-compatible changes, which could
	cause breakage to clients and importing YANG modules. Accepting that		cause breakage to clients and importing YANG modules. Accepting that
	non-backwards-compatible changes do sometimes occur, it is important		non-backwards-compatible changes do sometimes occur, it is important
	to have mechanisms to report where these changes occur, and to manage		to have mechanisms to report where these changes occur, and to manage
	their effect on clients and the broader YANG ecosystem.		their effect on clients and the broader YANG ecosystem.
	The document comprises five parts:		The document comprises five parts:
	Refinements to the YANG 1.1 module revision update procedure,		* Refinements to the YANG 1.1 module revision update procedure,
	supported by new extension statements to indicate when a revision		supported by new extension statements to indicate when a revision
	contains non-backwards-compatible changes, and an optional		contains non-backwards-compatible changes, and an optional
	revision label.		revision label.
	A YANG extension statement allowing YANG module imports to specify		* A YANG extension statement allowing YANG module imports to specify
	an earliest module revision that may satisfy the import		an earliest module revision that may satisfy the import
	dependency.		dependency.
	Updates and augmentations to ietf-yang-library to include the		* Updates and augmentations to ietf-yang-library to include the
	revision label in the module and submodule descriptions, to report		revision label in the module and submodule descriptions, to report
	how "deprecated" and "obsolete" nodes are handled by a server, and		how "deprecated" and "obsolete" nodes are handled by a server, and
	to clarify how module imports are resolved when multiple revisions		to clarify how module imports are resolved when multiple revisions
	could otherwise be chosen.		could otherwise be chosen.
	Considerations of how versioning applies to YANG instance data.		* Considerations of how versioning applies to YANG instance data.
	Guidelines for how the YANG module update rules defined in this		* Guidelines for how the YANG module update rules defined in this
	document should be used, along with examples.		document should be used, along with examples.
	Note to RFC Editor (To be removed by RFC Editor)		Note to RFC Editor (To be removed by RFC Editor)
	Open issues are tracked at <https://github.com/netmod-wg/yang-ver-dt/		Open issues are tracked at https://github.com/netmod-wg/yang-ver-dt/
	issues>.		issues.
	1.1. Updates to YANG RFCs		1.1. Updates to YANG RFCs
	This document updates [RFC7950] section 11. Section 3 describes		This document updates [RFC7950] section 11 and [RFC6020] section 10.
	modifications to YANG revision handling and update rules, and		Section 3 describes modifications to YANG revision handling and
	Section 4 describes a YANG extension statement to do import by		update rules, and Section 4 describes a YANG extension statement to
	derived revision.		do import by derived revision.
	This document updates [RFC7950] section 5.2. Section 3.4.1 describes		This document updates [RFC7950] section 5.2 and [RFC6020] section
	the use of a revision label in the name of a file containing a YANG		5.2. Section 3.4.1 describes the use of a revision label in the name
	module or submodule.		of a file containing a YANG module or submodule.
	This document updates [RFC7950] section 5.6.5. Section 5.1 defines		This document updates [RFC7950] section 5.6.5 and [RFC8525].
	how a client of a YANG library datastore schema resolves ambiguous		Section 5.1 defines how a client of a YANG library datastore schema
	imports for modules which are not "import-only".		resolves ambiguous imports for modules which are not "import-only".
	This document updates [RFC8407] section 4.7. Section 7 provides		This document updates [RFC8407] section 4.7. Section 7 provides
	guidelines on managing the lifecycle of YANG modules that may contain		guidelines on managing the lifecycle of YANG modules that may contain
	non-backwards-compatible changes and a branched revision history.		non-backwards-compatible changes and a branched revision history.
	This document updates [RFC8525] with augmentations to include		This document updates [RFC8525] with augmentations to include
	revision labels in the YANG library data and two boolean leaves to		revision labels in the YANG library data and two boolean leafs to
	indicate whether status deprecated and status obsolete schema nodes		indicate whether status deprecated and status obsolete schema nodes
	are implemented by the server.		are implemented by the server.
	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.
	In addition, this document uses the terminology:		In addition, this document uses the following terminology:
	o YANG module revision: An instance of a YANG module, uniquely		* YANG module revision: An instance of a YANG module, uniquely
	identified with a revision date, with no implied ordering or		identified with a revision date, with no implied ordering or
	backwards compatibility between different revisions of the same		backwards compatibility between different revisions of the same
	module.		module.
	o Backwards-compatible (BC) change: A backwards-compatible change		* Backwards-compatible (BC) change: A backwards-compatible change
	between two YANG module revisions, as defined in Section 3.1.1		between two YANG module revisions, as defined in Section 3.1.1
	o Non-backwards-compatible (NBC) change: A non-backwards-compatible		* Non-backwards-compatible (NBC) change: A non-backwards-compatible
	change between two YANG module revisions, as defined in		change between two YANG module revisions, as defined in
	Section 3.1.2		Section 3.1.2
	3. Refinements to YANG revision handling		3. Refinements to YANG revision handling
	[RFC7950] assumes, but does not explicitly state, that the revision		[RFC7950] and [RFC6020] assume, but do not explicitly state, that the
	history for a YANG module or submodule is strictly linear, i.e., it		revision history for a YANG module or submodule is strictly linear,
	is prohibited to have two independent revisions of a YANG module or		i.e., it is prohibited to have two independent revisions of a YANG
	submodule that are both directly derived from the same parent		module or submodule that are both directly derived from the same
	revision.		parent revision.
	This document clarifies [RFC7950] to explicitly allow non-linear		This document clarifies [RFC7950] and [RFC6020] to explicitly allow
	development of YANG module and submodule revisions, so that they MAY		non-linear development of YANG module and submodule revisions, so
	have multiple revisions that directly derive from the same parent		that they MAY have multiple revisions that directly derive from the
	revision. As per [RFC7950], YANG module and submodule revisions		same parent revision. As per [RFC7950] and [RFC6020], YANG module
	continue to be uniquely identified by their revision date, and hence		and submodule revisions continue to be uniquely identified by their
	all revisions of a given module or submodule MUST have unique		revision date, and hence all revisions of a given module or submodule
	revision dates.		MUST have unique revision dates.
	A corollary to the above is that the relationship between two module		A corollary to the above is that the relationship between two module
	or submodule revisions cannot be determined by comparing the module		or submodule revisions cannot be determined by comparing the module
	or submodule revision date alone, and the revision history, or		or submodule revision date alone, and the revision history, or
	revision label, must also be taken into consideration.		revision label, must also be taken into consideration.
	A module's name and revision date identifies a specific immutable		A module's name and revision date identifies a specific immutable
	definition of that module within its revision history. Hence, if a		definition of that module within its revision history. Hence, if a
	module includes submodules then to ensure that the module's content		module includes submodules then to ensure that the module's content
	is uniquely defined, the module's "include" statements SHOULD use		is uniquely defined, the module's "include" statements SHOULD use
	"revision-date" substatements to specify the exact revision date of		"revision-date" substatements to specify the exact revision date of
	each included submodule. When a module does not include its		each included submodule. When a module does not include its
	submodules by revision-date, the revision of submodules used cannot		submodules by revision-date, the revision of submodules used cannot
	be derived from the including module. Mechanisms such as YANG		be derived from the including module. Mechanisms such as YANG
	packages [I-D.ietf-netmod-yang-packages], and YANG library [RFC7895]		packages [I-D.ietf-netmod-yang-packages], and YANG library [RFC8525],
	[RFC8525], MAY be used to specify the exact submodule revisions used		MAY be used to specify the exact submodule revisions used when the
	when the submodule revision date is not constrained by the "include"		submodule revision date is not constrained by the "include"
	statement.		statement.
	[RFC7950] section 11 requires that all updates to a YANG module are		[RFC7950] section 11 and [RFC6020] section 10 require that all
	BC to the previous revision of the module. This document introduces		updates to a YANG module are BC to the previous revision of the
	a method to indicate that an NBC change has occurred between module		module. This document introduces a method to indicate that an NBC
	revisions: this is done by using a new "non-backwards-compatible"		change has occurred between module revisions: this is done by using a
	YANG extension statement in the module revision history.		new "non-backwards-compatible" YANG extension statement in the module
			revision history.
	Two revisions of a module or submodule MAY have identical content		Two revisions of a module or submodule MAY have identical content
	except for the revision history. This could occur, for example, if a		except for the revision history. This could occur, for example, if a
	module or submodule has a branched history and identical changes are		module or submodule has a branched history and identical changes are
	applied in multiple branches.		applied in multiple branches.
	3.1. Updating a YANG module with a new revision		3.1. Updating a YANG module with a new revision
	This section updates [RFC7950] section 11 to refine the rules for		This section updates [RFC7950] section 11 and [RFC6020] section 10 to
	permissible changes when a new YANG module revision is created.		refine the rules for permissible changes when a new YANG module
			revision is created.
	Where pragmatic, updates to YANG modules SHOULD be backwards-		Where pragmatic, updates to YANG modules SHOULD be backwards-
	compatible, following the definition in Section 3.1.1.		compatible, following the definition in Section 3.1.1.
	A new module revision MAY contain NBC changes, e.g., the semantics of		A new module revision MAY contain NBC changes, e.g., the semantics of
	an existing data-node definition MAY be changed in an NBC manner		an existing data-node definition MAY be changed in an NBC manner
	without requiring a new data-node definition with a new identifier.		without requiring a new data-node definition with a new identifier.
	A YANG extension, defined in Section 3.2, is used to signal the		A YANG extension, defined in Section 3.2, is used to signal the
	potential for incompatibility to existing module users and readers.		potential for incompatibility to existing module users and readers.
	As per [RFC7950], all published revisions of a module are given a new		As per [RFC7950] and [RFC6020], all published revisions of a module
	unique revision date. This applies even for module revisions		are given a new unique revision date. This applies even for module
	containing (in the module or included submodules) only changes to any		revisions containing (in the module or included submodules) only
	whitespace, formatting, comments or line endings (e.g., DOS vs UNIX).		changes to any whitespace, formatting, comments or line endings
			(e.g., DOS vs UNIX).
	3.1.1. Backwards-compatible rules		3.1.1. Backwards-compatible rules
	A change between two module revisions is defined as being "backwards-		A change between two module revisions is defined as being "backwards-
	compatible" if the change conforms to the module update rules		compatible" if the change conforms to the module update rules
	specified in [RFC7950] section 11, updated by the following rules:		specified in [RFC7950] section 11 and [RFC6020] section 10, updated
			by the following rules:
	o A "status" "deprecated" statement MAY be added, or changed from		* A "status" "deprecated" statement MAY be added, or changed from
	"current" to "deprecated", but adding or changing "status" to		"current" to "deprecated", but adding or changing "status" to
	"obsolete" is not a backwards-compatible change.		"obsolete" is not a backwards-compatible change.
	o YANG schema nodes with a "status" "obsolete" substatement MAY be		* YANG schema nodes with a "status" "obsolete" substatement MAY be
	removed from published modules, and are classified as backwards-		removed from published modules, and are classified as backwards-
	compatible changes. In some circumstances it may be helpful to		compatible changes. In some circumstances it may be helpful to
	retain the obsolete definitions to ensure that their identifiers		retain the obsolete definitions since their identifiers may still
	are not reused with a different meaning.		be referenced by other modules and to ensure that their
			identifiers are not reused with a different meaning.
	o In statements that have any data definition statements as		* In statements that have any data definition statements as
	substatements, those data definition substatements MAY be		substatements, those data definition substatements MAY be
	reordered, as long as they do not change the ordering of any		reordered, as long as they do not change the ordering of any
	"input" or "output" data definition substatements of "rpc" or		"input" or "output" data definition substatements of "rpc" or
	"action" statements. If new data definition statements are added,		"action" statements. If new data definition statements are added,
	they can be added anywhere in the sequence of existing		they can be added anywhere in the sequence of existing
	substatements.		substatements.
	o Any changes (including whitespace or formatting changes) that do		* A statement that is defined using the YANG "extension" statement
	not change the semantic meaning of the module are backwards
	compatible.
	o A statement that is defined using the YANG "extension" statement
	MAY be added, removed, or changed, if it does not change the		MAY be added, removed, or changed, if it does not change the
	semantics of the module. Extension statement definitions SHOULD		semantics of the module. Extension statement definitions SHOULD
	specify whether adding, removing, or changing statements defined		specify whether adding, removing, or changing statements defined
	by that extension are backwards-compatible or non-backwards-		by that extension are backwards-compatible or non-backwards-
	compatible.		compatible.
			* Any changes (including whitespace or formatting changes) that do
			not change the semantic meaning of the module are backwards
			compatible.
	3.1.2. Non-backwards-compatible changes		3.1.2. Non-backwards-compatible changes
	Any changes to YANG modules that are not defined by Section 3.1.1 as		Any changes to YANG modules that are not defined by Section 3.1.1 as
	being backwards-compatible are classified as "non-backwards-		being backwards-compatible are classified as "non-backwards-
	compatible" changes.		compatible" changes.
	3.2. non-backwards-compatible revision extension statement		3.2. non-backwards-compatible revision extension statement
	The "rev:non-backwards-compatible" extension statement is used to		The "rev:non-backwards-compatible" extension statement is used to
	indicate YANG module revisions that contain NBC changes.		indicate YANG module revisions that contain NBC changes.
	If a revision of a YANG module contains changes, relative to the		If a revision of a YANG module contains changes, relative to the
	preceding revision in the revision history, that do not conform to		preceding revision in the revision history, that do not conform to
	the module update rules defined in Section 3.1.1, then a "rev:non-		the module update rules defined in Section 3.1.1, then a "rev:non-
	backwards-compatible" extension statement MUST be added as a		backwards-compatible" extension statement MUST be added as a
	substatement to the "revision" statement.		substatement to the "revision" statement.
	3.3. Removing revisions from the revision history		3.3. Removing revisions from the revision history
	Authors may wish to remove revision statements from a module or		Authors may wish to remove revision statements from a module or
	submodule. Removal of revision information may be desired for a		submodule. Removal of revision information may be desirable for a
	number of reasons including reducing the size of a large revision		number of reasons including reducing the size of a large revision
	history, or removing a revision that should no longer be used or		history, or removing a revision that should no longer be used or
	imported. Removing revision statements is allowed, but can cause		imported. Removing revision statements is allowed, but can cause
	issues and SHOULD NOT be done without careful analysis of the		issues and SHOULD NOT be done without careful analysis of the
	potential impact to users of the module or submodule. Doing so can		potential impact to users of the module or submodule. Doing so can
	lead to import breakages when import by revision-or-derived is used.		lead to import breakages when import by revision-or-derived is used.
	Moreover, truncating history may cause loss of visibility of when		Moreover, truncating history may cause loss of visibility of when
	non-backwards-compatible changes were introduced.		non-backwards-compatible changes were introduced.
	If a revision containing a rev:non-backwards-compatible substatement		An author MAY remove a contiguous sequence of entries from the end
	is removed from the revision history then a rev:non-backwards-		(i.e., oldest entries) of the revision history. This is acceptable
	compatible substatement MUST be added to the nearest newer revision		even if the first remaining (oldest) revision entry in the revision
	entry in the revision history that is not being removed.		history contains a rev:non-backwards-compatible substatement.
			An author MAY remove a contiguous sequence of entries in the revision
			history as long as the presence or absence of any existing rev:non-
			backwards-compatible substatements on all remaining entries still
			accurately reflect the compatibility relationship to their preceding
			entries remaining in the revision history.
			The author MUST NOT remove the first (i.e., newest) revision entry in
			the revision history.
			Example revision history:
			revision 2020-11-11 {
			rev:revision-label 4.0.0;
			rev:non-backwards-compatible;
			}
			revision 2020-08-09 {
			rev:revision-label 3.0.0;
			rev:non-backwards-compatible;
			}
			revision 2020-06-07 {
			rev:revision-label 2.1.0;
			}
			revision 2020-02-10 {
			rev:revision-label 2.0.0;
			rev:non-backwards-compatible;
			}
			revision 2019-10-21 {
			rev:revision-label 1.1.3;
			}
			revision 2019-03-04 {
			rev:revision-label 1.1.2;
			}
			revision 2019-01-02 {
			rev:revision-label 1.1.1;
			}
			In the revision history example above, removing the revision history
			entry for 2020-02-10 would also remove the rev:non-backwards-
			compatible annotation and hence the resulting revision history would
			incorrectly indicate that revision 2020-06-07 is backwards-compatible
			with revisions 2019-01-02 through 2019-10-21 when it is not, and so
			this change cannot be made. Conversely, removing one or more
			revisions out of 2019-03-04, 2019-10-21 and 2020-08-09 from the
			revision history would still retain a consistent revision history,
			and is acceptable, subject to an awareness of the concerns raised in
			the first paragraph of this section.
	3.4. Revision label		3.4. Revision label
	Each revision entry in a module or submodule MAY have a revision		Each revision entry in a module or submodule MAY have a revision
	label associated with it, providing an alternative alias to identify		label associated with it, providing an alternative alias to identify
	a particular revision of a module or submodule. The revision label		a particular revision of a module or submodule. The revision label
	could be used to provide an additional versioning identifier		could be used to provide an additional versioning identifier
	associated with the revision.		associated with the revision.
	YANG Semver [I-D.ietf-netmod-yang-semver] defines a versioning scheme		A revision label scheme is a set of rules describing how a particular
	based on Semver 2.0.0 [semver] that can be used as a revision label.		type of revision-label operates for versioning YANG modules and
			submodules. For example, YANG Semver [I-D.ietf-netmod-yang-semver]
			defines a revision label scheme based on Semver 2.0.0 [semver].
			Other documents may define other YANG revision label schemes.
	Submodules MAY use a revision label scheme. When they use a revision		Submodules MAY use a revision label scheme. When they use a revision
	label scheme, submodules MAY use a revision label scheme that is		label scheme, submodules MAY use a revision label scheme that is
	different from the one used in the including module.		different from the one used in the including module.
	The revision label space of submodules is separate from the revision		The revision label space of submodules is separate from the revision
	label space of the including module. A change in one submodule MUST		label space of the including module. A change in one submodule MUST
	result in a new revision label of that submodule and the including		result in a new revision label of that submodule and the including
	module, but the actual values of the revision labels in the module		module, but the actual values of the revision labels in the module
	and submodule could be completely different. A change in one		and submodule could be completely different. A change in one
	submodule does not result in a new revision label in another		submodule does not result in a new revision label in another
	submodule. A change in a module revision label does not necessarily		submodule. A change in a module revision label does not necessarily
	mean a change to the revision label in all included submodules.		mean a change to the revision label in all included submodules.
	If a revision has an associated revision label, then it may be used		If a revision has an associated revision label, then it may be used
	instead of the revision date in a "rev:revision-or-derived" extension		instead of the revision date in a "rev:revision-or-derived" extension
	statement argument.		statement argument.
	A specific revision-label identifies a specific revision (variant) of		A specific revision-label identifies a specific revision of the
	the module. If two YANG modules contain the same module name and the		module. If two YANG modules contain the same module name and the
	same revision-label (and hence also the same revision-date) in their		same revision-label (and hence also the same revision-date) in their
	latest revision statement, then the file contents of the two modules,		latest revision statement, then the file contents of the two modules,
	including the revision history, MUST be identical.		including the revision history, MUST be identical.
	3.4.1. File names		3.4.1. File names
	This section updates [RFC7950] section 5.2.		This section updates [RFC7950] section 5.2 and [RFC6020] section 5.2.
	If a revision has an associated revision label, then the revision-		If a revision has an associated revision label, then the revision-
	label may be used instead of the revision date in the filename of a		label MAY be used instead of the revision date in the filename of a
	YANG file, where it takes the form:		YANG file, where it takes the form:
	module-or-submodule-name [['@' revision-date]|['#' revision-label]]		module-or-submodule-name [['@' revision-date]|['#' revision-label]]
	( '.yang' / '.yin' )		( '.yang' / '.yin' )
	E.g., acme-router-module@2018-01-25.yang		E.g., acme-router-module@2018-01-25.yang
	E.g., acme-router-module#2.0.3.yang		E.g., acme-router-module#2.0.3.yang
	YANG module (or submodule) files MAY be identified using either		YANG module (or submodule) files MAY be identified using either
	revision-date or revision-label. Typically, only one file name		revision-date or revision-label. Typically, only one file name
	skipping to change at page 9, line 25 ¶		skipping to change at page 10, line 33 ¶
	label, MAY exist for the same module (or submodule) revision, e.g.,		label, MAY exist for the same module (or submodule) revision, e.g.,
	when migrating from one scheme to the other.		when migrating from one scheme to the other.
	3.4.2. Revision label scheme extension statement		3.4.2. Revision label scheme extension statement
	The optional "rev:revision-label-scheme" extension statement is used		The optional "rev:revision-label-scheme" extension statement is used
	to indicate which revision-label scheme a module or submodule uses.		to indicate which revision-label scheme a module or submodule uses.
	There MUST NOT be more than one revision label scheme in a module or		There MUST NOT be more than one revision label scheme in a module or
	submodule. The mandatory argument to this extension statement:		submodule. The mandatory argument to this extension statement:
	o specifies the revision-label scheme used by the module or		* specifies the revision-label scheme used by the module or
	submodule		submodule
	o is defined in the document which specifies the revision-label		* is defined in the document which specifies the revision-label
	scheme		scheme
	o MUST be an identity derived from "revision-label-scheme-base".		* MUST be an identity derived from "revision-label-scheme-base".
	The revision-label scheme used by a module or submodule SHOULD NOT		The revision-label scheme used by a module or submodule SHOULD NOT
	change during the lifetime of the module or submodule. If the		change during the lifetime of the module or submodule. If the
	revision-label scheme used by a module or submodule is changed to a		revision-label scheme used by a module or submodule is changed to a
	new scheme, then all revision-label statements that do not conform to		new scheme, then all revision-label statements that do not conform to
	the new scheme MUST be replaced or removed.		the new scheme MUST be replaced or removed.
	3.5. Examples for updating the YANG module revision history		3.5. Examples for updating the YANG module revision history
	The following diagram, explanation, and module history illustrates		The following diagram, explanation, and module history illustrates
	skipping to change at page 12, line 45 ¶		skipping to change at page 13, line 43 ¶
	revision 2019-01-01 {		revision 2019-01-01 {
	rev:revision-label 1.0.0;		rev:revision-label 1.0.0;
	description "Initial revision";		description "Initial revision";
	}		}
	//YANG module definition starts here		//YANG module definition starts here
	}		}
	4. Import by derived revision		4. Import by derived revision
	RFC 7950 allows YANG module "import" statements to optionally require		[RFC7950] and [RFC6020] allow YANG module "import" statements to
	the imported module to have a particular revision date. In practice,		optionally require the imported module to have a particular revision
	importing a module with an exact revision date is often too		date. In practice, importing a module with an exact revision date is
	restrictive because it requires the importing module to be updated		often too restrictive because it requires the importing module to be
	whenever any change to the imported module occurs. The alternative		updated whenever any change to the imported module occurs. The
	choice of using an import statement without any revision date		alternative choice of using an import statement without any revision
	statement is also not ideal because the importing module may not work		date statement is also not ideal because the importing module may not
	with all possible revisions of the imported module.		work with all possible revisions of the imported module.
	Instead, it is desirable for an importing module to specify a		Instead, it is desirable for an importing module to specify a
	"minimum required revision" of a module that it is compatible with,		"minimum required revision" of a module that it is compatible with,
	based on the assumption that later revisions derived from that		based on the assumption that later revisions derived from that
	"minimum required revision" are also likely to be compatible. Many		"minimum required revision" are also likely to be compatible. Many
	possible changes to a YANG module do not break importing modules,		possible changes to a YANG module do not break importing modules,
	even if the changes themselves are not strictly backwards-compatible.		even if the changes themselves are not strictly backwards-compatible.
	E.g., fixing an incorrect pattern statement or description for a leaf		E.g., fixing an incorrect pattern statement or description for a leaf
	would not break an import, changing the name of a leaf could break an		would not break an import, changing the name of a leaf could break an
	import but frequently would not, but removing a container would break		import but frequently would not, but removing a container would break
	skipping to change at page 13, line 38 ¶		skipping to change at page 14, line 38 ¶
	An "import" statement MUST NOT contain both a "revision-or-		An "import" statement MUST NOT contain both a "revision-or-
	derived" extension statement and a "revision-date" statement.		derived" extension statement and a "revision-date" statement.
	The "revision-or-derived" extension statement MAY be specified		The "revision-or-derived" extension statement MAY be specified
	multiple times, allowing the import to use any module revision		multiple times, allowing the import to use any module revision
	that satisfies at least one of the "revision-or-derived" extension		that satisfies at least one of the "revision-or-derived" extension
	statements.		statements.
	The "revision-or-derived" extension statement does not guarantee		The "revision-or-derived" extension statement does not guarantee
	that all module revisions that satisfy an import statement are		that all module revisions that satisfy an import statement are
	necessarily compatible, it only gives an indication that the		necessarily compatible; it only gives an indication that the
	revisions are more likely to be compatible. Hence, NBC changes to		revisions are more likely to be compatible. Hence, NBC changes to
	an imported module may also require new revisions of any importing		an imported module may also require new revisions of any importing
	modules, updated to accommodation those changes, along with		modules, updated to accommodation those changes, along with
	updated import "revision-or-derived" extension statements to		updated import "revision-or-derived" extension statements to
	depend on the updated imported module revision.		depend on the updated imported module revision.
	Adding, modifying or removing a "revision-or-derived" extension		Adding, modifying or removing a "revision-or-derived" extension
	statement is considered to be a BC change.		statement is considered to be a BC change.
	Adding, modifying or removing a "revision-date" extension
	statement is considered to be a BC change.
	4.1. Module import examples		4.1. Module import examples
	Consider the example module "example-module" from Section 3.5 that is		Consider the example module "example-module" from Section 3.5 that is
	hypothetically available in the following revision/label pairings:		hypothetically available in the following revision/label pairings:
	2019-01-01/1.0.0, 2019-02-01/2.0.0, 2019-03-01/3.0.0,		2019-01-01/1.0.0, 2019-02-01/2.0.0, 2019-03-01/3.0.0,
	2019-04-01/2.1.0, 2019-05-01/2.2.0 and 2019-06-01/3.1.0. The		2019-04-01/2.1.0, 2019-05-01/2.2.0 and 2019-06-01/3.1.0. The
	relationship between the revisions is as before:		relationship between the revisions is as before:
	Module revision date Revision label		Module revision date Revision label
	2019-01-01 <- 1.0.0		2019-01-01 <- 1.0.0
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 31 ¶
	2019-06-01. It includes revisions/labels: 2019-04-01/2.1.0,		2019-06-01. It includes revisions/labels: 2019-04-01/2.1.0,
	2019-05-01/2.2.0, and 2019-06-01/3.1.0.		2019-05-01/2.2.0, and 2019-06-01/3.1.0.
	import example-module {		import example-module {
	rev:revision-or-derived 2019-04-01;		rev:revision-or-derived 2019-04-01;
	rev:revision-or-derived 2019-06-01;		rev:revision-or-derived 2019-06-01;
	}		}
	5. Updates to ietf-yang-library		5. Updates to ietf-yang-library
	This document updates YANG library [RFC7950] to clarify how ambiguous		This document updates YANG 1.1 [RFC7950] and YANG library [RFC8525]
	module imports are resolved. It also defines the YANG module, ietf-		to clarify how ambiguous module imports are resolved. It also
	yang-library-revisions that augments YANG library [RFC8525] with new		defines the YANG module, ietf-yang-library-revisions, that augments
	revision-label related meta-data.		YANG library [RFC8525] with revision labels and two leafs to indicate
			how a server implements deprecated and obsolete schema nodes.
	5.1. Resolving ambiguous module imports		5.1. Resolving ambiguous module imports
	A YANG datastore schema, defined in [RFC8525], can specify multiple		A YANG datastore schema, defined in [RFC8525], can specify multiple
	revisions of a YANG module in the schema using the "import-only"		revisions of a YANG module in the schema using the "import-only"
	list, with the requirement from [RFC7950] that only a single revision		list, with the requirement from [RFC7950] section 5.6.5 that only a
	of a YANG module may be implemented.		single revision of a YANG module may be implemented.
	If a YANG module import statement does not specify a specific		If a YANG module import statement does not specify a specific
	revision within the datastore schema then it could be ambiguous as to		revision within the datastore schema then it could be ambiguous as to
	which module revision the import statement should resolve to. Hence,		which module revision the import statement should resolve to. Hence,
	a datastore schema constructed by a client using the information		a datastore schema constructed by a client using the information
	contained in YANG library may not exactly match the datastore schema		contained in YANG library may not exactly match the datastore schema
	actually used by the server.		actually used by the server.
	The following two rules remove the ambiguity:		The following two rules remove the ambiguity:
	skipping to change at page 16, line 30 ¶		skipping to change at page 17, line 36 ¶
	+--ro revision-label? rev:revision-label		+--ro revision-label? rev:revision-label
	augment /yanglib:yang-library/yanglib:module-set		augment /yanglib:yang-library/yanglib:module-set
	/yanglib:import-only-module/yanglib:submodule:		/yanglib:import-only-module/yanglib:submodule:
	+--ro revision-label? rev:revision-label		+--ro revision-label? rev:revision-label
	augment /yanglib:yang-library/yanglib:schema:		augment /yanglib:yang-library/yanglib:schema:
	+--ro deprecated-nodes-implemented? boolean		+--ro deprecated-nodes-implemented? boolean
	+--ro obsolete-nodes-absent? boolean		+--ro obsolete-nodes-absent? boolean
	5.2.1. Advertising revision-label		5.2.1. Advertising revision-label
	The ietf-yang-library-revisions YANG module augments the "module"		The ietf-yang-library-revisions YANG module augments the "module" and
	list in ietf-yang-library with a "revision-label" leaf to optionally		"submodule" lists in ietf-yang-library with "revision-label" leafs to
	declare the revision label associated wth the particular revision of		optionally declare the revision label associated with each module and
	each module.		submodule.
	5.2.2. Reporting how deprecated and obsolete nodes are handled		5.2.2. Reporting how deprecated and obsolete nodes are handled
	The ietf-yang-library-revisions YANG module augments YANG library		The ietf-yang-library-revisions YANG module augments YANG library
	with two leaves to allow a server to report how it handles status		with two boolean leafs to allow a server to report how it implements
	"deprecated" and status "obsolete" nodes. The leaves are:		status "deprecated" and status "obsolete" schema nodes. The leafs
			are:
	deprecated-nodes-implemented: If set to "true", this leaf indicates		deprecated-nodes-implemented: If set to "true", this leaf indicates
	that all schema nodes with a status "deprecated" child statement		that all schema nodes with a status "deprecated" are implemented
	are implemented equivalently as if they had status "current", or		equivalently as if they had status "current"; otherwise deviations
	otherwise deviations MUST be used to explicitly remove		MUST be used to explicitly remove "deprecated" nodes from the
	"deprecated" nodes from the schema. If this leaf is set to		schema. If this leaf is set to "false" or absent, then the
	"false" or absent, then the behavior is unspecified.		behavior is unspecified.
	obsolete-nodes-absent: If set to "true", this leaf indicates that		obsolete-nodes-absent: If set to "true", this leaf indicates that
	the server does not implement any status "obsolete" nodes. If		the server does not implement any status "obsolete" schema nodes.
	this leaf is set to "false" or absent, then the behaviour is		If this leaf is set to "false" or absent, then the behaviour is
	unspecified.		unspecified.
	Servers SHOULD set both the "deprecated-nodes-implemented" and		Servers SHOULD set both the "deprecated-nodes-implemented" and
	"obsolete-nodes-absent" leaves to "true".		"obsolete-nodes-absent" leafs to "true".
	If a server does not set the "deprecated-nodes-implemented" leaf to		If a server does not set the "deprecated-nodes-implemented" leaf to
	"true", then clients MUST NOT rely solely on the "rev:non-backwards-		"true", then clients MUST NOT rely solely on the "rev:non-backwards-
	compatible" statements to determine whether two module revisions are		compatible" statements to determine whether two module revisions are
	backwards-compatible, and MUST also consider whether the status of		backwards-compatible, and MUST also consider whether the status of
	any nodes has changed to "deprecated" and whether those nodes are		any nodes has changed to "deprecated" and whether those nodes are
	implemented by the server.		implemented by the server.
	6. Versioning of YANG instance data		6. Versioning of YANG instance data
	skipping to change at page 17, line 48 ¶		skipping to change at page 19, line 13 ¶
	guidelines for updating YANG modules.		guidelines for updating YANG modules.
	7.1. Guidelines for YANG module authors		7.1. Guidelines for YANG module authors
	All IETF YANG modules MUST include revision-label statements for all		All IETF YANG modules MUST include revision-label statements for all
	newly published YANG modules, and all newly published revisions of		newly published YANG modules, and all newly published revisions of
	existing YANG modules. The revision-label MUST take the form of a		existing YANG modules. The revision-label MUST take the form of a
	YANG semantic version number [I-D.ietf-netmod-yang-semver].		YANG semantic version number [I-D.ietf-netmod-yang-semver].
	NBC changes to YANG modules may cause problems to clients, who are		NBC changes to YANG modules may cause problems to clients, who are
	consumers of YANG models, and hence YANG module authors are		consumers of YANG models, and hence YANG module authors SHOULD
	RECOMMENDED to minimize NBC changes and keep changes BC whenever		minimize NBC changes and keep changes BC whenever possible.
	possible.
	When NBC changes are introduced, consideration should be given to the		When NBC changes are introduced, consideration should be given to the
	impact on clients and YANG module authors SHOULD try to mitigate that		impact on clients and YANG module authors SHOULD try to mitigate that
	impact.		impact.
	A "rev:non-backwards-compatible" statement MUST be added if there are		A "rev:non-backwards-compatible" statement MUST be added if there are
	NBC changes relative to the previous revision.		NBC changes relative to the previous revision.
	Removing old revision statements from a module's revision history		Removing old revision statements from a module's revision history
	could break import by revision, and hence it is RECOMMENDED to retain		could break import by revision, and hence it is RECOMMENDED to retain
	them. If all depencencies have been updated to not import specific		them. If all dependencies have been updated to not import specific
	revisions of a module, then the corresponding revision statements can		revisions of a module, then the corresponding revision statements can
	be removed from that module. An alternative solution, if the		be removed from that module. An alternative solution, if the
	revision section is too long, would be to remove, or curtail, the		revision section is too long, would be to remove, or curtail, the
	older description statements associated with the previous revisions.		older description statements associated with the previous revisions.
	The "rev:revision-or-derived" extension should be used in YANG module		The "rev:revision-or-derived" extension SHOULD be used in YANG module
	imports to indicate revision dependencies between modules in		imports to indicate revision dependencies between modules in
	preference to the "revision-date" statement, which causes overly		preference to the "revision-date" statement, which causes overly
	strict import dependencies and SHOULD NOT be used.		strict import dependencies and SHOULD NOT be used.
	A module that includes submodules SHOULD use the "revision-date"		A module that includes submodules SHOULD use the "revision-date"
	statement to include specific submodule revisions. The revision of		statement to include specific submodule revisions. The revision of
	the including module MUST be updated when any included submodule has		the including module MUST be updated when any included submodule has
	changed. The revision-label substatement used in the new module		changed.
	revision MUST indicate the nature of the change, i.e. NBC or BC, to
	the module's schema tree.
	In some cases a module or submodule revision that is not strictly NBC		In some cases a module or submodule revision that is not strictly NBC
	by the definition in Section 3.1.2 of this specification may include		by the definition in Section 3.1.2 of this specification may include
	the "non-backwards-compatible" statement. Here is an example when		the "non-backwards-compatible" statement. Here is an example when
	adding the statement may be desirable:		adding the statement may be desirable:
	o A "config false" leaf had its value space expanded (for example, a		* A "config false" leaf had its value space expanded (for example, a
	range was increased, or additional enum values were added) and the		range was increased, or additional enum values were added) and the
	author or server implementor feels there is a significant		author or server implementor feels there is a significant
	compatibility impact for clients and users of the module or		compatibility impact for clients and users of the module or
	submodule		submodule
	7.1.1. Making non-backwards-compatible changes to a YANG module		7.1.1. Making non-backwards-compatible changes to a YANG module
	There are various valid situations where a YANG module has to be		There are various valid situations where a YANG module has to be
	modified in an NBC way. Here are the different ways in which this		modified in an NBC way. Here are the different ways in which this
	can be done:		can be done:
	o NBC changes can be sometimes be done incrementally using the		* NBC changes can be sometimes be done incrementally using the
	"deprecated" status to provide clients time to adapt to NBC		"deprecated" status to provide clients time to adapt to NBC
	changes.		changes.
	o NBC changes are done at once, i.e. without using "status"		* NBC changes are done at once, i.e. without using "status"
	statements. Depending on the change, this may have a big impact		statements. Depending on the change, this may have a big impact
	on clients.		on clients.
	o If the server can support multiple revisions of the YANG module or		* If the server can support multiple revisions of the YANG module or
	of YANG packages(as specified in [I-D.ietf-netmod-yang-packages]),		of YANG packages (as specified in
	and allows the client to select the revision (as per		[I-D.ietf-netmod-yang-packages]), and allows the client to select
	[I-D.ietf-netmod-yang-ver-selection]), then NBC changes MAY be		the revision (as per [I-D.ietf-netmod-yang-ver-selection]), then
	done without using "status" statements. Clients would be required		NBC changes MAY be done without using "status" statements.
	to select the revision which they support and the NBC change would		Clients would be required to select the revision which they
	have no impact on them.		support and the NBC change would have no impact on them.
	Here are some guidelines on how non-backwards-compatible changes can		Here are some guidelines on how non-backwards-compatible changes can
	be made incrementally, with the assumption that deprecated nodes are		be made incrementally, with the assumption that deprecated nodes are
	implemented by the server, and obsolete nodes are not:		implemented by the server, and obsolete nodes are not:
	1. The changes should be made gradually, e.g., a data node's status		1. The changes should be made gradually, e.g., a data node's status
	SHOULD NOT be changed directly from "current" to "obsolete" (see		SHOULD NOT be changed directly from "current" to "obsolete" (see
	Section 4.7 of [RFC8407]), instead the status SHOULD first be		Section 4.7 of [RFC8407]), instead the status SHOULD first be
	marked "deprecated" and then when support is removed its status		marked "deprecated". At some point in the future, when support
	MUST be changed to "obsolete". Instead of using the "obsolete"		is removed for the data node, there are two options. The first,
	status, the data node MAY be removed from the model but this has		and preferred, option is to keep the data node definition in the
	the risk of breaking modules which import the modified module.		model and change the status to "obsolete". The second option is
			to simply remove the data node from the model, but this has the
			risk of breaking modules which import the modified module, and
			the removed identifier may be accidently reused in a future
			revision.
	2. For deprecated data nodes the "description" statement SHOULD also		2. For deprecated data nodes the "description" statement SHOULD also
	indicate until when support for the node is guaranteed (if		indicate until when support for the node is guaranteed (if
	known). If there is a replacement data node, rpc, action or		known). If there is a replacement data node, rpc, action or
	notification for the deprecated node, this SHOULD be stated in		notification for the deprecated node, this SHOULD be stated in
	the "description". The reason for deprecating the node can also		the "description". The reason for deprecating the node can also
	be included in the "description" if it is deemed to be of		be included in the "description" if it is deemed to be of
	potential interest to the user.		potential interest to the user.
	3. For obsolete data nodes, it is RECOMMENDED to keep the above		3. For obsolete data nodes, it is RECOMMENDED to keep the above
	skipping to change at page 20, line 16 ¶		skipping to change at page 21, line 33 ¶
	of removing a node, that node SHOULD first be deprecated and then		of removing a node, that node SHOULD first be deprecated and then
	obsoleted.		obsoleted.
	See Appendix B for examples on how NBC changes can be made.		See Appendix B for examples on how NBC changes can be made.
	7.2. Versioning Considerations for Clients		7.2. Versioning Considerations for Clients
	Guidelines for clients of modules using the new module revision		Guidelines for clients of modules using the new module revision
	update procedure:		update procedure:
	o Clients SHOULD be liberal when processing data received from a		* Clients SHOULD be liberal when processing data received from a
	server. For example, the server may have increased the range of		server. For example, the server may have increased the range of
	an operational node causing the client to receive a value which is		an operational node causing the client to receive a value which is
	outside the range of the YANG model revision it was coded against.		outside the range of the YANG model revision it was coded against.
	o Clients SHOULD monitor changes to published YANG modules through		* Clients SHOULD monitor changes to published YANG modules through
	their revision history, and use appropriate tooling to understand		their revision history, and use appropriate tooling to understand
	the specific changes between module revision. In particular,		the specific changes between module revision. In particular,
	clients SHOULD NOT migrate to NBC revisions of a module without		clients SHOULD NOT migrate to NBC revisions of a module without
	understanding any potential impact of the specific NBC changes.		understanding any potential impact of the specific NBC changes.
	o Clients SHOULD plan to make changes to match published status		* Clients SHOULD plan to make changes to match published status
	changes. When a node's status changes from "current" to		changes. When a node's status changes from "current" to
	"deprecated", clients SHOULD plan to stop using that node in a		"deprecated", clients SHOULD plan to stop using that node in a
	timely fashion. When a node's status changes to "obsolete",		timely fashion. When a node's status changes to "obsolete",
	clients MUST stop using that node.		clients MUST stop using that node.
	8. Module Versioning Extension YANG Modules		8. Module Versioning Extension YANG Modules
	YANG module with extension statements for annotating NBC changes,		YANG module with extension statements for annotating NBC changes,
	revision label, revision label scheme, and importing by revision.		revision label, revision label scheme, and importing by revision.
	<CODE BEGINS> file "ietf-yang-revisions@2021-06-30.yang"		<CODE BEGINS> file "ietf-yang-revisions@2021-06-30.yang"
	module ietf-yang-revisions {		module ietf-yang-revisions {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions";
	prefix rev;		prefix rev;
	// RFC Ed.: We need the bis version to get the new type revision-identifier		// RFC Ed.: We need the bis version to get the new type revision-identifier
	// If 6991-bis is not yet an RFC we need to copy the definition here		// If 6991-bis is not yet an RFC we need to copy the definition here
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference		reference
	"XXXX [ietf-netmod-rfc6991-bis]: Common YANG Data Types";		"XXXX [ietf-netmod-rfc6991-bis]: Common YANG Data Types";
	}		}
	organization
	"IETF NETMOD (Network Modeling) Working Group";
	contact
	"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>
	Author: Joe Clarke		organization
	<mailto:jclarke@cisco.com>		"IETF NETMOD (Network Modeling) Working Group";
			contact
			"WG Web: <https://datatracker.ietf.org/wg/netmod/>
			WG List: <mailto:netmod@ietf.org>
	Author: Reshad Rahman		Author: Joe Clarke
	<mailto:reshad@yahoo.com>		<mailto:jclarke@cisco.com>
	Author: Robert Wilton		Author: Reshad Rahman
	<mailto:rwilton@cisco.com>		<mailto:reshad@yahoo.com>
	Author: Balazs Lengyel		Author: Robert Wilton
	<mailto:balazs.lengyel@ericsson.com>		<mailto:rwilton@cisco.com>
	Author: Jason Sterne		Author: Balazs Lengyel
	<mailto:jason.sterne@nokia.com>";		<mailto:balazs.lengyel@ericsson.com>
	description
	"This YANG 1.1 module contains definitions and extensions to
	support updated YANG revision handling.
	Copyright (c) 2021 IETF Trust and the persons identified as		Author: Jason Sterne
	authors of the code. All rights reserved.		<mailto:jason.sterne@nokia.com>";
			description
			"This YANG 1.1 module contains definitions and extensions to
			support updated YANG revision handling.
	Redistribution and use in source and binary forms, with or		Copyright (c) 2021 IETF Trust and the persons identified as
	without modification, is permitted pursuant to, and subject		authors of the code. All rights reserved.
	to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		Redistribution and use in source and binary forms, with or
	the RFC itself for full legal notices.		without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD License
			set forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(http://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		This version of this YANG module is part of RFC XXXX; see
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		the RFC itself for full legal notices.
	'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.";
	// RFC Ed.: update the date below with the date of RFC publication		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	// and remove this note.		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	// RFC Ed.: replace XXXX (inc above) with actual RFC number and		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	// remove this note.		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
			they appear in all capitals, as shown here.";
	revision 2021-06-30 {		// RFC Ed.: update the date below with the date of RFC publication
	description		// and remove this note.
	"Initial version.";		// RFC Ed.: replace XXXX (inc above) with actual RFC number and
	reference		// remove this note.
	"XXXX: Updated YANG Module Revision Handling";
	}
	typedef revision-label {		revision 2021-06-30 {
	type string {		rev:revision-label 1.0.0-draft-ietf-netmod-yang-module-versioning-04;
	length "1..255";		description
	pattern '[a-zA-Z0-9,\-_.+]+';		"Initial version.";
	pattern '\d{4}-\d{2}-\d{2}' {		reference
	modifier invert-match;		"XXXX: Updated YANG Module Revision Handling";
	}		}
	}
	description
	"A label associated with a YANG revision.
	Alphanumeric characters, comma, hyphen, underscore, period		typedef revision-label {
	and plus are the only accepted characters. MUST NOT match		type string {
	revision-date.";		length "1..255";
	reference		pattern '[a-zA-Z0-9,\-_.+]+';
	"XXXX: Updated YANG Module Revision Handling;		pattern '\d{4}-\d{2}-\d{2}' {
	Section 3.3, Revision label";		modifier invert-match;
	}		}
			}
			description
			"A label associated with a YANG revision.
	typedef revision-date-or-label {		Alphanumeric characters, comma, hyphen, underscore, period
	type union {		and plus are the only accepted characters. MUST NOT match
	type yang:revision-identifier;		revision-date.";
	type revision-label;		reference
	}		"XXXX: Updated YANG Module Revision Handling;
	description		Section 3.3, Revision label";
	"Represents either a YANG revision date or a revision label";		}
	}
	extension nbc-changes {		typedef revision-date-or-label {
	description		type union {
	"This statement is used to indicate YANG module revisions that		type yang:revision-identifier;
	contain non-backwards-compatible changes.		type revision-label;
			}
			description
			"Represents either a YANG revision date or a revision label";
			}
	The statement MUST only be a substatement of the 'revision'		extension non-backwards-compatible {
	statement. Zero or one 'non-backwards-compatible' statements		description
	per parent statement is allowed. No substatements for this		"This statement is used to indicate YANG module revisions that
	extension have been standardized.		contain non-backwards-compatible changes.
	If a revision of a YANG module contains changes, relative to		The statement MUST only be a substatement of the 'revision'
	the preceding revision in the revision history, that do not		statement. Zero or one 'non-backwards-compatible' statements
	conform to the module update rules defined in RFC-XXX, then		per parent statement is allowed. No substatements for this
	the 'non-backwards-compatible' statement MUST be added as a		extension have been standardized.
	substatement to the revision statement.
	Conversely, if a revision does not contain a		If a revision of a YANG module contains changes, relative to
	'non-backwards-compatible' statement then all changes,		the preceding revision in the revision history, that do not
	relative to the preceding revision in the revision history,		conform to the backwards compatible module update rules defined
	MUST be backwards-compatible.		in RFC-XXX, then the 'non-backwards-compatible' statement MUST
			be added as a substatement to the revision statement.
	A new module revision that only contains changes that are		Conversely, if a revision does not contain a
	backwards compatible SHOULD NOT include the		'non-backwards-compatible' statement then all changes,
	'non-backwards-compatible' statement. An example of when		relative to the preceding revision in the revision history,
	an author might add the 'non-backwards-compatible' statement		MUST be backwards-compatible.
	is if they believe a change could negatively impact clients
	even though the backwards compatibility rules defined in
	RFC-XXXX classify it as a backwards-compatible change.
	Add, removing, or changing a 'non-backwards-compatible'		A new module revision that only contains changes that are
	statement is a backwards-compatible version change.";		backwards compatible SHOULD NOT include the
			'non-backwards-compatible' statement. An example of when
			an author might add the 'non-backwards-compatible' statement
			is if they believe a change could negatively impact clients
			even though the backwards compatibility rules defined in
			RFC-XXXX classify it as a backwards-compatible change.
	reference		Add, removing, or changing a 'non-backwards-compatible'
	"XXXX: Updated YANG Module Revision Handling;		statement is a backwards-compatible version change.";
	Section 3.2, nbc-changes revision extension statement";
	}
	extension revision-label {		reference
	argument revision-label;		"XXXX: Updated YANG Module Revision Handling;
	description		Section 3.2, nbc-changes revision extension statement";
	"The revision label can be used to provide an additional		}
	versioning identifier associated with a module or submodule
	revision. E.g., one option for a versioning scheme that
	could be used is [XXXX: ietf-netmod-yang-semver].
	The format of the revision-label argument MUST conform to the		extension revision-label {
	pattern defined for the revision-label typedef.		argument revision-label;
			description
			"The revision label can be used to provide an additional
			versioning identifier associated with a module or submodule
			revision. One such scheme that
			could be used is [XXXX: ietf-netmod-yang-semver].
	The statement MUST only be a substatement of the revision		The format of the revision-label argument MUST conform to the
	statement. Zero or one revision-label statements per parent		pattern defined for the revision-label typedef in this module.
	statement are allowed. No substatements for this extension
	have been standardized.
	Revision labels MUST be unique amongst all revisions of a		The statement MUST only be a substatement of the revision
	module or submodule.		statement. Zero or one revision-label statements per parent
			statement are allowed. No substatements for this extension
			have been standardized.
	Adding a revision label is a backwards-compatible version		Revision labels MUST be unique amongst all revisions of a
	change. Changing or removing an existing revision label in		module or submodule.
	the revision history is a non-backwards-compatible version
	change, because it could impact any references to that
	revision label.";
	reference		Adding a revision label is a backwards-compatible version
	"XXXX: Updated YANG Module Revision Handling;		change. Changing or removing an existing revision label in
	Section 3.3, Revision label";		the revision history is a non-backwards-compatible version
	}		change, because it could impact any references to that
			revision label.";
	extension revision-label-scheme {		reference
	argument revision-label-scheme-identity;		"XXXX: Updated YANG Module Revision Handling;
	description		Section 3.3, Revision label";
	"The revision label scheme specifies which revision-label scheme		}
	the module or submodule uses.
	The mandatory revision-label-scheme-identity argument MUST be an		extension revision-label-scheme {
	identity derived from revision-label-scheme-base.		argument revision-label-scheme-identity;
			description
			"The revision label scheme specifies which revision-label scheme
			the module or submodule uses.
	This extension is only valid as a top-level statement, i.e.,		The mandatory revision-label-scheme-identity argument MUST be an
	given as as a substatement to 'module' or 'submodule'. No		identity derived from revision-label-scheme-base.
	substatements for this extension have been standardized.
	This extension MUST be used if there is a revision-label		This extension is only valid as a top-level statement, i.e.,
	statement in the module or submodule.		given as as a substatement to 'module' or 'submodule'. No
			substatements for this extension have been standardized.
	Adding a revision label scheme is a backwards-compatible version		This extension MUST be used if there is a revision-label
	change. Changing a revision label scheme is a		statement in the module or submodule.
	non-backwards-compatible version change, unless the new revision
	label scheme is backwards-compatible with the replaced revision
	label scheme. Removing a revision label scheme is a
	non-backwards-compatible version change.";
	reference		Adding a revision label scheme is a backwards-compatible version
	"XXXX: Updated YANG Module Revision Handling;		change. Changing a revision label scheme is a
	Section 3.3.1, Revision label scheme extension statement";		non-backwards-compatible version change, unless the new revision
	}		label scheme is backwards-compatible with the replaced revision
			label scheme. Removing a revision label scheme is a
			non-backwards-compatible version change.";
	extension revision-or-derived {		reference
	argument revision-date-or-label;		"XXXX: Updated YANG Module Revision Handling;
	description		Section 3.3.1, Revision label scheme extension statement";
	"Restricts the revision of the module that may be imported to		}
	one that matches or is derived from the specified
	revision-date or revision-label.
	The argument value MUST conform to the		extension revision-or-derived {
	'revision-date-or-label' defined type.		argument revision-date-or-label;
			description
			"Restricts the revision of the module that may be imported to
			one that matches or is derived from the specified
			revision-date or revision-label.
	The statement MUST only be a substatement of the import		The argument value MUST conform to the
	statement. Zero, one or more 'revision-or-derived' statements		'revision-date-or-label' defined type.
	per parent statement are allowed. No substatements for this
	extension have been standardized.
	If specified multiple times, then any module revision that		The statement MUST only be a substatement of the import
	satisfies at least one of the 'revision-or-derived' statements		statement. Zero, one or more 'revision-or-derived' statements
	is an acceptable revision for import.		per parent statement are allowed. No substatements for this
			extension have been standardized.
	An 'import' statement MUST NOT contain both a		If specified multiple times, then any module revision that
	'revision-or-derived' extension statement and a		satisfies at least one of the 'revision-or-derived' statements
	'revision-date' statement.		is an acceptable revision for import.
	A particular revision of an imported module satisfies an		An 'import' statement MUST NOT contain both a
	import's 'revision-or-derived' extension statement if the		'revision-or-derived' extension statement and a
	imported module's revision history contains a revision		'revision-date' statement.
	statement with a matching revision date or revision label.
	The 'revision-or-derived' extension statement does not		A particular revision of an imported module satisfies an
	guarantee that all module revisions that satisfy an import		import's 'revision-or-derived' extension statement if the
	statement are necessarily compatible, it only gives an		imported module's revision history contains a revision
	indication that the revisions are more likely to be		statement with a matching revision date or revision label.
	compatible.
	Adding, removing or updating a 'revision-or-derived'		The 'revision-or-derived' extension statement does not
	statement to an import is a backwards-compatible change.		guarantee that all module revisions that satisfy an import
	";		statement are necessarily compatible, it only gives an
			indication that the revisions are more likely to be
			compatible.
	reference		Adding, removing or updating a 'revision-or-derived'
	"XXXX: Updated YANG Module Revision Handling;		statement to an import is a backwards-compatible change.
	Section 4, Import by derived revision";		";
	}
	identity revision-label-scheme-base {		reference
	description		"XXXX: Updated YANG Module Revision Handling;
	"Base identity from which all revision label schemes are		Section 4, Import by derived revision";
	derived.";		}
			identity revision-label-scheme-base {
			description
			"Base identity from which all revision label schemes are
			derived.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 3.3.1, Revision label scheme extension statement";		Section 3.3.1, Revision label scheme extension statement";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	YANG module with augmentations to YANG Library to revision labels		YANG module with augmentations to YANG Library to revision labels
	<CODE BEGINS> file "ietf-yang-library-revisions@2021-06-30.yang"		<CODE BEGINS> file "ietf-yang-library-revisions@2021-10-22.yang"
	module ietf-yang-library-revisions {		module ietf-yang-library-revisions {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-yang-library-revisions";		"urn:ietf:params:xml:ns:yang:ietf-yang-library-revisions";
			prefix yl-rev;
	prefix yl-rev;		import ietf-yang-revisions {
			prefix rev;
			reference
			"XXXX: Updated YANG Module Revision Handling";
			}
	import ietf-yang-revisions {		import ietf-yang-library {
	prefix rev;		prefix yanglib;
	reference		reference "RFC 8525: YANG Library";
	"XXXX: Updated YANG Module Revision Handling";		}
	}
	import ietf-yang-library {		organization
	prefix yanglib;		"IETF NETMOD (Network Modeling) Working Group";
	reference "RFC 8525: YANG Libary";		contact
	}		"WG Web: <https://datatracker.ietf.org/wg/netmod/>
			WG List: <mailto:netmod@ietf.org>
	organization		Author: Joe Clarke
	"IETF NETMOD (Network Modeling) Working Group";		<mailto:jclarke@cisco.com>
	contact
	"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>
	Author: Joe Clarke		Author: Reshad Rahman
	<mailto:jclarke@cisco.com>		<mailto:reshad@yahoo.com>
	Author: Reshad Rahman		Author: Robert Wilton
	<mailto:reshad@yahoo.com>		<mailto:rwilton@cisco.com>
	Author: Robert Wilton		Author: Balazs Lengyel
	<mailto:rwilton@cisco.com>		<mailto:balazs.lengyel@ericsson.com>
	Author: Balazs Lengyel		Author: Jason Sterne
	<mailto:balazs.lengyel@ericsson.com>		<mailto:jason.sterne@nokia.com>";
			description
			"This module contains augmentations to YANG Library to add module
			level revision label and to provide an indication of how
			deprecated and obsolete nodes are handled by the server.
	Author: Jason Sterne		Copyright (c) 2021 IETF Trust and the persons identified as
	<mailto:jason.sterne@nokia.com>";		authors of the code. All rights reserved.
	description
	"This module contains augmentations to YANG Library to add module
	level revision label and to provide an indication of how
	deprecated and obsolete nodes are handled by the server.
	Copyright (c) 2021 IETF Trust and the persons identified as		Redistribution and use in source and binary forms, with or
	authors of the code. All rights reserved.		without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD License
			set forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(http://trustee.ietf.org/license-info).
	Redistribution and use in source and binary forms, with or		This version of this YANG module is part of RFC XXXX; see
	without modification, is permitted pursuant to, and subject		the RFC itself for full legal notices.
	to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.";		they appear in all capitals, as shown here.";
	// 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 (including in the imports above) with		// RFC Ed.: replace XXXX (including in the imports above) with
	// actual RFC number and remove this note.		// actual RFC number and remove this note.
	// RFC Ed.: please replace revision-label version with 1.0.0 and		// RFC Ed.: please replace revision-label version with 1.0.0 and
	// remove this note.		// remove this note.
	revision 2021-06-30 {		revision 2021-10-22 {
	rev:revision-label 0.2.0;		rev:revision-label 1.0.0-draft-ietf-netmod-yang-module-versioning-04;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling";		"XXXX: Updated YANG Module Revision Handling";
	}		}
	augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {		// library 1.0 modules-state is not augmented with revision-label
	description
	"Augmentation modules with a revision label";
	leaf revision-label {
	type rev:revision-label;
	description
	"The revision label associated with this module revision.
	The label MUST match the rev:label value in the specific
	revision of the module loaded in this module-set.";
	reference		augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
	"XXXX: Updated YANG Module Revision Handling;		description
	Section 5.2.1, Advertising revision-label";		"Add a revision label to module information";
	}
	}
	augment "/yanglib:yang-library/yanglib:module-set/yanglib:module/"		leaf revision-label {
	+ "yanglib:submodule" {		type rev:revision-label;
	description		description
	"Augment submodule information with a revision label";		"The revision label associated with this module revision.
	leaf revision-label {		The label MUST match the rev:revision-label value in the specific
	type rev:revision-label;		revision of the module loaded in this module-set.";
	description
	"The revision label associated with this submodule revision.
	The label MUST match the rev:label value in the specific
	revision of the submodule included by the module loaded in
	this module-set.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 5.2.1, Advertising revision-label";		Section 5.2.1, Advertising revision-label";
	}		}
	}		}
	augment "/yanglib:yang-library/yanglib:module-set/"		augment "/yanglib:yang-library/yanglib:module-set/yanglib:module/"
	+ "yanglib:import-only-module/yanglib:submodule" {		+ "yanglib:submodule" {
	description		description
	"Augment submodule information with a revision label";		"Add a revision label to submodule information";
	leaf revision-label {		leaf revision-label {
	type rev:revision-label;		type rev:revision-label;
	description		description
	"The revision label associated with this submodule revision.		"The revision label associated with this submodule revision.
	The label MUST match the rev:label value in the specific		The label MUST match the rev:revision-label value in the specific
	revision of the submodule included by the		revision of the submodule included by the module loaded in
	import-only-module loaded in this module-set.";		this module-set.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 5.2.1, Advertising revision-label";		Section 5.2.1, Advertising revision-label";
	}		}
	}		}
	augment "/yanglib:yang-library/yanglib:schema" {		augment "/yanglib:yang-library/yanglib:module-set/"
	description		+ "yanglib:import-only-module" {
	"Augmentations to the ietf-yang-library module to indicate how		description
	deprecated and obsoleted nodes are handled for each datastore		"Add a revision label to module information";
	schema supported by the server.";		leaf revision-label {
			type rev:revision-label;
			description
			"The revision label associated with this module revision.
			The label MUST match the rev:revision-label value in the specific
			revision of the module included in this module-set.";
	leaf deprecated-nodes-implemented {		reference
	type boolean;		"XXXX: Updated YANG Module Revision Handling;
	description		Section 5.2.1, Advertising revision-label";
	"If set to true, this leaf indicates that all schema nodes with		}
	a status 'deprecated' child statement are implemented		}
	equivalently as if they had status 'current', or otherwise		augment "/yanglib:yang-library/yanglib:module-set/"
	deviations MUST be used to explicitly remove 'deprecated'		+ "yanglib:import-only-module/yanglib:submodule" {
	nodes from the schema. If this leaf is absent or set to false,		description
	then the behavior is unspecified.";		"Add a revision label to submodule information";
			leaf revision-label {
			type rev:revision-label;
			description
			"The revision label associated with this submodule revision.
			The label MUST match the rev:label value in the specific
			revision of the submodule included by the
			import-only-module loaded in this module-set.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 5.2.2, Reporting how deprecated and obsolete nodes		Section 5.2.1, Advertising revision-label";
	are handled";		}
	}		}
	leaf obsolete-nodes-absent {
	type boolean;
	description
	"If set to true, this leaf indicates that the server does not
	implement any status 'obsolete' nodes. If this leaf is
	absent or set to false, then the behaviour is unspecified.";
	reference		augment "/yanglib:yang-library/yanglib:schema" {
	"XXXX: Updated YANG Module Revision Handling;		description
	Section 5.2.2, Reporting how deprecated and obsolete nodes		"Augmentations to the ietf-yang-library module to indicate how
	are handled";		deprecated and obsoleted nodes are handled for each datastore
	}		schema supported by the server.";
	}
	}		leaf deprecated-nodes-implemented {
	<CODE ENDS>		type boolean;
			description
			"If set to true, this leaf indicates that all schema nodes with
			a status 'deprecated' are implemented
			equivalently as if they had status 'current'; otherwise
			deviations MUST be used to explicitly remove deprecated
			nodes from the schema. If this leaf is absent or set to false,
			then the behavior is unspecified.";
			reference
			"XXXX: Updated YANG Module Revision Handling;
			Section 5.2.2, Reporting how deprecated and obsolete nodes
			are handled";
			}
			leaf obsolete-nodes-absent {
			type boolean;
			description
			"If set to true, this leaf indicates that the server does not
			implement any status 'obsolete' schema nodes. If this leaf is
			absent or set to false, then the behaviour is unspecified.";
			reference
			"XXXX: Updated YANG Module Revision Handling;
			Section 5.2.2, Reporting how deprecated and obsolete nodes
			are handled";
			}
			}
			}
			<CODE ENDS>
	9. Contributors		9. 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 following individuals are (or have been)		started after IETF 101. The following individuals are (or have been)
	members of the design team and have worked on the YANG versioning		members of the design team and have worked on the YANG versioning
	project:		project:
	o Balazs Lengyel		* Balazs Lengyel
	o Benoit Claise		* Benoit Claise
	o Ebben Aries		* Bo Wu
	o Jan Lindblad		* Ebben Aries
	o Jason Sterne		* Jan Lindblad
	o Joe Clarke		* Jason Sterne
	o Juergen Schoenwaelder		* Joe Clarke
	o Mahesh Jethanandani		* Juergen Schoenwaelder
	o Michael (Wangzitao)		* Mahesh Jethanandani
	o Qin Wu		* Michael (Wangzitao)
	o Reshad Rahman		* Qin Wu
	o Rob Wilton		* Reshad Rahman
			* Rob Wilton
	o Bo Wu
	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 to thank Kevin
			D'Souza and Benoit Claise for their 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. We would like to thank		with authors of the OpenConfig YANG models. We would like to thank
	both Anees Shaikh and Rob Shakir for their input into this problem		both Anees Shaikh and Rob Shakir for their input into this problem
	space.		space.
	We would also like to thank Lou Berger, Andy Bierman, Martin		We would also like to thank Lou Berger, Andy Bierman, Martin
	Bjorklund, Italo Busi, Tom Hill, Scott Mansfield, Kent Watsen for		Bjorklund, Italo Busi, Tom Hill, Scott Mansfield, Kent Watsen for
	their contributions and review comments.		their contributions and review comments.
	10. Security Considerations		10. 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 considerations beyond those specified in [RFC7950].		are no security considerations beyond those specified in [RFC7950]
			and [RFC6020].
	11. IANA Considerations		11. IANA Considerations
	11.1. YANG Module Registrations		11.1. YANG Module Registrations
	This document requests IANA to registers a URI in the "IETF XML		This document requests IANA to registers a URI in the "IETF XML
	Registry" [RFC3688]. Following the format in RFC 3688, the following		Registry" [RFC3688]. Following the format in RFC 3688, the following
	registrations are requested.		registrations are requested.
	URI: urn:ietf:params:xml:ns:yang:ietf-yang-revisions		URI: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
	skipping to change at page 31, line 6 ¶		skipping to change at page 33, line 4 ¶
	XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-revisions		XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
	Prefix: rev		Prefix: rev
	Reference: [RFCXXXX]		Reference: [RFCXXXX]
	The ietf-yang-library-revisions module:		The ietf-yang-library-revisions module:
	Name: ietf-yang-library-revisions		Name: ietf-yang-library-revisions
	XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-		XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-
	revisions		revisions
	Prefix: yl-rev		Prefix: yl-rev
	Reference: [RFCXXXX]		Reference: [RFCXXXX]
	11.2. Guidance for versioning in IANA maintained YANG modules		11.2. Guidance for versioning in IANA maintained YANG modules
	Note for IANA (to be removed by the RFC editor): Please check that		Note for IANA (to be removed by the RFC editor): Please check that
	the registries and IANA YANG modules are referenced in the		the registries and IANA YANG modules are referenced in the
	appropriate way.		appropriate way.
	IANA is responsible for maintaining and versioning YANG modules that		IANA is responsible for maintaining and versioning YANG modules that
	are derived from other IANA registries. For example, "iana-if-		are derived from other IANA registries. For example,
	type.yang" [IfTypeYang] is derived from the "Interface Types (ifType)		"iana-if-type.yang" [IfTypeYang] is derived from the "Interface Types
	IANA registry" [IfTypesReg], and "iana-routing-types.yang"		(ifType) IANA registry" [IfTypesReg], and "iana-routing-types.yang"
	[RoutingTypesYang] is derived from the "Address Family Numbers"		[RoutingTypesYang] is derived from the "Address Family Numbers"
	[AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI)		[AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI)
	Parameters" [SAFIReg] IANA registries.		Parameters" [SAFIReg] IANA registries.
	Normally, updates to the registries cause any derived YANG modules to		Normally, updates to the registries cause any derived YANG modules to
	be updated in a backwards-compatible way, but there are some cases		be updated in a backwards-compatible way, but there are some cases
	where the registry updates can cause non-backward-compatible updates		where the registry updates can cause non-backward-compatible updates
	to the derived YANG module. An example of such an update is the		to the derived YANG module. An example of such an update is the
	2020-12-31 revision of iana-routing-types.yang		2020-12-31 revision of iana-routing-types.yang
	[RoutingTypesDecRevision], where the enum name for two SAFI values		[RoutingTypesDecRevision], where the enum name for two SAFI values
	skipping to change at page 32, line 31 ¶		skipping to change at page 34, line 29 ¶
	maintained modules that would be classified as backwards-compatible		maintained modules that would be classified as backwards-compatible
	changes are: Adding a new identity, changing the status or an		changes are: Adding a new identity, changing the status or an
	identity to deprecated, or improving the description of an identity		identity to deprecated, or improving the description of an identity
	that does not change its defined meaning.		that does not change its defined meaning.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-netmod-rfc6991-bis]		[I-D.ietf-netmod-rfc6991-bis]
	Schoenwaelder, J., "Common YANG Data Types", draft-ietf-		Schoenwaelder, J., "Common YANG Data Types", Work in
	netmod-rfc6991-bis-06 (work in progress), April 2021.		Progress, Internet-Draft, draft-ietf-netmod-rfc6991-bis-
			07, 9 July 2021, <https://www.ietf.org/archive/id/draft-
			ietf-netmod-rfc6991-bis-07.txt>.
	[I-D.ietf-netmod-yang-semver]		[I-D.ietf-netmod-yang-semver]
	Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,		Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
	B., Sterne, J., and K. D'Souza, "YANG Semantic		B., Sterne, J., and K. D'Souza, "YANG Semantic
	Versioning", draft-ietf-netmod-yang-semver-02 (work in		Versioning", Work in Progress, Internet-Draft, draft-ietf-
	progress), February 2021.		netmod-yang-semver-03, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			semver-03.txt>.
	[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,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<https://www.rfc-editor.org/info/rfc7895>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[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,
	skipping to change at page 33, line 41 ¶		skipping to change at page 35, line 37 ¶
	12.2. Informative References		12.2. Informative References
	[AddrFamilyReg]		[AddrFamilyReg]
	"Address Family Numbers IANA Registry",		"Address Family Numbers IANA Registry",
	<https://www.iana.org/assignments/address-family-numbers/		<https://www.iana.org/assignments/address-family-numbers/
	address-family-numbers.xhtml>.		address-family-numbers.xhtml>.
	[I-D.clacla-netmod-yang-model-update]		[I-D.clacla-netmod-yang-model-update]
	Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New		Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New
	YANG Module Update Procedure", draft-clacla-netmod-yang-		YANG Module Update Procedure", Work in Progress, Internet-
	model-update-06 (work in progress), July 2018.		Draft, draft-clacla-netmod-yang-model-update-06, 2 July
			2018, <https://www.ietf.org/archive/id/draft-clacla-
			netmod-yang-model-update-06.txt>.
	[I-D.ietf-netmod-yang-instance-file-format]		[I-D.ietf-netmod-yang-instance-file-format]
	Lengyel, B. and B. Claise, "YANG Instance Data File		Lengyel, B. and B. Claise, "YANG Instance Data File
	Format", draft-ietf-netmod-yang-instance-file-format-13		Format", Work in Progress, Internet-Draft, draft-ietf-
	(work in progress), March 2021.		netmod-yang-instance-file-format-21, 8 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			instance-file-format-21.txt>.
	[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", draft-ietf-netmod-yang-packages-01 (work		"YANG Packages", Work in Progress, Internet-Draft, draft-
	in progress), November 2020.		ietf-netmod-yang-packages-01, 2 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			packages-01.txt>.
	[I-D.ietf-netmod-yang-solutions]		[I-D.ietf-netmod-yang-solutions]
	Wilton, R., "YANG Versioning Solution Overview", draft-		Wilton, R., "YANG Versioning Solution Overview", Work in
	ietf-netmod-yang-solutions-01 (work in progress), November		Progress, Internet-Draft, draft-ietf-netmod-yang-
	2020.		solutions-01, 2 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			solutions-01.txt>.
	[I-D.ietf-netmod-yang-ver-selection]		[I-D.ietf-netmod-yang-ver-selection]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
	"YANG Schema Selection", draft-ietf-netmod-yang-ver-		"YANG Schema Selection", Work in Progress, Internet-Draft,
	selection-00 (work in progress), March 2020.		draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			ver-selection-00.txt>.
	[I-D.ietf-netmod-yang-versioning-reqs]		[I-D.ietf-netmod-yang-versioning-reqs]
	Clarke, J., "YANG Module Versioning Requirements", draft-		Clarke, J., "YANG Module Versioning Requirements", Work in
	ietf-netmod-yang-versioning-reqs-04 (work in progress),		Progress, Internet-Draft, draft-ietf-netmod-yang-
	January 2021.		versioning-reqs-05, 6 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			versioning-reqs-05.txt>.
	[IfTypesReg]		[IfTypesReg]
	"Interface Types (ifType) IANA Registry",		"Interface Types (ifType) IANA Registry",
	<https://www.iana.org/assignments/smi-numbers/smi-		<https://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#smi-numbers-5>.		numbers.xhtml#smi-numbers-5>.
	[IfTypeYang]		[IfTypeYang]
	"iana-if-type YANG Module",		"iana-if-type YANG Module",
	<https://www.iana.org/assignments/iana-if-type/iana-if-		<https://www.iana.org/assignments/iana-if-type/iana-if-
	type.xhtml>.		type.xhtml>.
	skipping to change at page 35, line 5 ¶		skipping to change at page 37, line 20 ¶
	[SAFIReg] "Subsequent Address Family Identifiers (SAFI) Parameters		[SAFIReg] "Subsequent Address Family Identifiers (SAFI) Parameters
	IANA Registry", <https://www.iana.org/assignments/safi-		IANA Registry", <https://www.iana.org/assignments/safi-
	namespace/safi-namespace.xhtml>.		namespace/safi-namespace.xhtml>.
	[semver] "Semantic Versioning 2.0.0", <https://www.semver.org>.		[semver] "Semantic Versioning 2.0.0", <https://www.semver.org>.
	Appendix A. Examples of changes that are NBC		Appendix A. Examples of changes that are NBC
	Examples of NBC changes include:		Examples of NBC changes include:
	o Deleting a data node, or changing it to status obsolete.		* Deleting a data node, or changing it to status obsolete.
	o Changing the name, type, or units of a data node.		* Changing the name, type, or units of a data node.
	o Modifying the description in a way that changes the semantic		* Modifying the description in a way that changes the semantic
	meaning of the data node.		meaning of the data node.
	o Any changes that change or reduce the allowed value set of the		* Any changes that change or reduce the allowed value set of the
	data node, either through changes in the type definition, or the		data node, either through changes in the type definition, or the
	addition or changes to "must" statements, or changes in the		addition or changes to "must" statements, or changes in the
	description.		description.
	o Adding or modifying "when" statements that reduce when the data		* Adding or modifying "when" statements that reduce when the data
	node is available in the schema.		node is available in the schema.
	o Making the statement conditional on if-feature.		* Making the statement conditional on if-feature.
	Appendix B. Examples of applying the NBC change guidelines		Appendix B. Examples of applying the NBC change guidelines
	The following sections give guidance for how some of these NBC		The following sections give steps that could be taken for making NBC
	changes could be made to a YANG module. The examples are all for		changes to a YANG module or submodule using the incremental approach
	"config true" nodes.		described in section Section 7.1.1.
			The examples are all for "config true" nodes.
			Alternatively, the NBC changes MAY be done non-incrementally and
			without using "status" statements if the server can support multiple
			revisions of the YANG module or of YANG packages. Clients would be
			required to select the revision which they support and the NBC change
			would have no impact on them.
	B.1. Removing a data node		B.1. Removing a data node
	Removing a leaf or container from the data tree, e.g., because		Removing a leaf or container from the data tree, e.g., because
	support for the corresponding feature is being removed:		support for the corresponding feature is being removed:
	1. The node's status is changed to "deprecated" and it is supported		1. The schema node's status is changed to "deprecated" and the node
	for at least one year. This is a BC change.		is supported for some period of time (e.g. one year). This is a
			BC change.
	2. When the node is not available anymore, its status is changed to
	"obsolete" and the "description" updated, this is an NBC change.
	If the server can support NBC revisions of the YANG module
	simultaneously using version selection
	[I-D.ietf-netmod-yang-ver-selection], then the changes can be done
	immediately:
	1. The new revision of the YANG module has the node's status changed
	to "obsolete" and the "description" updated, this is an NBC
	change.
	2. Clients which require the data node select the YANG package		2. When the schema node is not supported anymore, its status is
	containing the schema version they use.		changed to "obsolete" and the "description" updated. This is an
			NBC change.
	B.2. Changing the type of a leaf node		B.2. Changing the type of a leaf node
	Changing the type of a leaf-node. e.g., consider a "vpn-id" node of		Changing the type of a leaf node. e.g., a "vpn-id" node of type
	type integer being changed to a string:		integer being changed to a string:
	1. The status of node "vpn-id" is changed to "deprecated" and the		1. The status of schema node "vpn-id" is changed to "deprecated" and
	node should be available for at least one year. This is a BC		the node is supported for some period of time (e.g. one year).
	change.		This is a BC change. The description is updated to indicate that
			"vpn-name" is replacing this node.
	2. A new node, e.g., "vpn-name", of type string is added to the same		2. A new schema node, e.g., "vpn-name", of type string is added to
	location as the existing node "vpn-id". This new node has status		the same location as the existing node "vpn-id". This new node
	"current" and its description explains that it is replacing node		has status "current" and its description explains that it is
	"vpn-id".		replacing node "vpn-id".
	3. During the period of time when both nodes are available, how the		3. During the period of time when both schema nodes are supported,
	server behaves when either node is set is outside the scope of		the interactions between the two nodes is outside the scope of
	this document and will vary on a case by case basis. Here are		this document and will vary on a case by case basis. Here are
	some options:		some options:
	1. A server may prevent the new node from being set if the old		1. A server may prevent the new node from being set if the old
	node is already set (and vice-versa). The new node may have		node is already set (and vice-versa). A "choice"
	a when statement to achieve this. The old node must not have		construction could be used, or the new node may have a "when"
	a when statement since this would be an NBC change, but the		statement to achieve this. The old node must not have a
			"when" statement since this would be an NBC change, but the
	server could reject the old node from being set if the new		server could reject the old node from being set if the new
	node is already set.		node is already set.
	2. If the new node is set and a client does a get or get-config		2. If the new node is set and a client does a get or get-config
	operation on the old node, the server could map the value.		operation on the old node, the server could map the value.
	For example, if the new node "vpn-name" has value "123" then		For example, if the new node "vpn-name" has value "123" then
	the server could return integer value 123 for the old node		the server could return integer value 123 for the old node
	"vpn-id". However, if the value can not be mapped then the		"vpn-id". However, if the value can not be mapped then the
	configuration would be incomplete, this is outside the scope		configuration would be incomplete. The behavior in this case
	of this document.		is outside the scope of this document.
	4. When node "vpn-id" is not available anymore, its status is
	changed to "obsolete" and the "description" is updated. This is
	an NBC change.
	If the server can support NBC revisions of the YANG module
	simultaneously using version selection
	[I-D.ietf-netmod-yang-ver-selection], then the changes can be done
	immediately:
	1. In the new revision of the YANG module, the status of node "vpn-
	id" is changed to "obsolete". This is an NBC change.
	2. New node "vpn-name" is added to the same location as described
	above.
	3. Clients which require the data node select the YANG package
	containing the schema version they use
	4. A server should not map between the nodes "vpn-id" and "vpn-		4. When the schema node "vpn-id" is not supported anymore, its
	name", i.e. if a client creates a data instance with "vpn-name"		status is changed to "obsolete" and the "description" is updated.
	then that data instance should not be visible to a client using a		This is an NBC change.
	module revision which has "vpn-id" (and vice-versa).
	B.3. Reducing the range of a leaf node		B.3. Reducing the range of a leaf node
	Reducing the range of values of a leaf-node, e.g., consider a "vpn-		Reducing the range of values of a leaf-node, e.g., consider a "vpn-
	id" node of type integer being changed from type uint32 to type		id" schema node of type uint32 being changed from range 1..5000 to
	uint16:		range 1..2000:
	1. If all values which are being removed were never supported, e.g.,		1. If all values which are being removed were never supported, e.g.,
	if a vpn-id of 65536 or higher was never accepted, this is a BC		if a vpn-id of 2001 or higher was never accepted, this is a BC
	change for the functionality (no functionality change). Even if		change for the functionality (no functionality change). Even if
	it is an NBC change for the YANG model, there should be no impact		it is an NBC change for the YANG model, there should be no impact
	for clients using that YANG model.		for clients using that YANG model.
	2. If one or more values being removed was previously supported,		2. If one or more values being removed was previously supported,
	e.g., if a vpn-id of 65536 was accepted previously, this is an		e.g., if a vpn-id of 3333 was accepted previously, this is an NBC
	NBC change for the YANG model. Clients using the old YANG model		change for the YANG model. Clients using the old YANG model will
	will be impacted, so a change of this nature should be done		be impacted, so a change of this nature should be done carefully,
	carefully, e.g., by using the steps described in Appendix B.2		e.g., by using the steps described in Appendix B.2
	B.4. Changing the key of a list		B.4. Changing the key of a list
	Changing the key of a list has a big impact to the client. For		Changing the key of a list has a big impact to the client. For
	example, consider a "sessions" list which has a key "interface" and		example, consider a "sessions" list which has a key "interface" and
	there is a need to change the key to "dest-address", such a change		there is a need to change the key to "dest-address". Such a change
	can be done in steps:		can be done in steps:
	1. The status of list "sessions" is changed to "deprecated" and the		1. The status of list "sessions" is changed to "deprecated" and the
	list should be available for at least one year. This is a BC		list is supported for some period of time (e.g. one year). This
	change.		is a BC change. The description is updated to indicate the new
			list that is replacing this list.
	2. A new list is created in the same location with the same data but		2. A new list is created in the same location with the same
	with "dest-address" as key. Finding an appropriate name for the		descendant schema nodes but with "dest-address" as key. Finding
	new list can be tricky especially if the name of the existing		an appropriate name for the new list can be difficult. In this
	list was perfect. In this case the new list is called "sessions-		case the new list is called "sessions-address", has status
	address", has status "current" and its description should explain		"current" and its description should explain that it is replacing
	that it is replacing list "session".		list "session".
	3. During the period of time when both lists are available, how the		3. During the period of time when both lists are supported, the
	server behaves when either list is set is outside the scope of		interactions between the two lists is outside the scope of this
	this document and will vary on a case by case basis. Here are		document and will vary on a case by case basis. Here are some
	some options:		options:
	1. A server could prevent the new list from being set if the old		1. A server could prevent entries in the new list from being
	list already has entries (and vice-versa).		created if the old list already has entries (and vice-versa).
	2. If the new list is set and a client does a get or get-config		2. If the new list has entries created and a client does a get
	operation on the old list, the server could map the entries.		or get-config operation on the old list, the server could map
	However, if the new list has entries which would lead to		the entries. However, if the new list has entries which
	duplicate keys in the old list, the mapping can not be done.		would lead to duplicate keys in the old list, the mapping can
			not be done.
	4. When list "sessions" is not available anymore, its status is		4. When list "sessions" is not available anymore, its status is
	changed to "obsolete" and the "description" is updated. This is		changed to "obsolete" and the "description" is updated. This is
	an NBC change.		an NBC change.
	If the server can support NBC revisions of the YANG module		If the server can support NBC revisions of the YANG module
	simultaneously using version selection		simultaneously using version selection
	[I-D.ietf-netmod-yang-ver-selection], then the changes can be done		[I-D.ietf-netmod-yang-ver-selection], then the changes can be done
	immediately:		immediately:
	1. The new revision of the YANG module has the list "sessions"		1. The new revision of the YANG module has the list "sessions"
	modified to have "dest-address" as key, this is an NBC change.		modified to have "dest-address" as key, this is an NBC change.
	2. Clients which require the previous functionality select the older		2. Clients which require the previous functionality select the older
	module revision		module revision
	B.5. Renaming a node		B.5. Renaming a node
	A leaf-node or a container may be renamed, either due to a spelling		A leaf or container schema node may be renamed, either due to a
	error in the previous name or because of a better name. For example		spelling error in the previous name or because of a better name. For
	a node "ip-adress" could be renamed to "ip-address":		example a node "ip-adress" could be renamed to "ip-address":
	1. The status of the existing node "ip-adress" is changed to		1. The status of the existing node "ip-adress" is changed to
	"deprecated" and the node should be available for at least one		"deprecated" and is supported for some period of time (e.g. one
	year. This is a BC change.		year). This is a BC change. The description is updated to
			indicate the node that is replacing this node.
	2. The new node "ip-address" is added to the same location as the		2. The new schema node "ip-address" is added to the same location as
	existing node "ip-adress". This new node has status "current"		the existing node "ip-adress". This new node has status
	and its description should explain that it is replacing node "ip-		"current" and its description should explain that it is replacing
	adress".		node "ip-adress".
	3. During the period of time when both nodes are available, how the		3. During the period of time when both nodes are available, the
	server behaves when either node is set is outside the scope of		interactions between the two nodes is outside the scope of this
	this document and will vary on a case by case basis. Here are		document and will vary on a case by case basis. Here are some
	some options:		options:
	1. A server could prevent the new node from being set if the old		1. A server may prevent the new node from being set if the old
	node is already set (and vice-versa). The new node could		node is already set (and vice-versa). A "choice"
	have a when statement to achieve this. The old node must not		construction could be used, or the new node may have a "when"
	have a when statement since this would be an NBC change, but		statement to achieve this. The old node must not have a
	the server could reject the old node from being set if the		"when" statement since this would be an NBC change, but the
	new node is already set.		server could reject the old node from being set if the new
			node is already set.
	2. If the new node is set and a client does a get or get-config		2. If the new node is set and a client does a get or get-config
	operation on the old node, the server could use the value of		operation on the old node, the server could use the value of
	the new node. For example, if the new node "ip-address" has		the new node. For example, if the new node "ip-address" has
	value X then the server may return value X for the old node		value X then the server may return value X for the old node
	"ip-adress".		"ip-adress".
	4. When node "ip-adress" is not available anymore, its status is		4. When node "ip-adress" is not available anymore, its status is
	changed to "obsolete" and the "description" is updated. This is		changed to "obsolete" and the "description" is updated. This is
	an NBC change.		an NBC change.
	If the server can support NBC revisions of the YANG module
	simultaneously using version selection
	[I-D.ietf-netmod-yang-ver-selection], then the changes can be done
	immediately:
	1. The new revision of the YANG module has the node with the new
	name replacing the node with the old name, this is an NBC change.
	2. Clients which require the previous node name select the older
	module revision
	B.6. Changing a default value
	Appendix C. Changes between revisions
	Note to RFC Editor (To be removed by RFC Editor)
	v00 - v01
	o Removed status-description
	o Allowed both revision-date and revision-label in the filename.
	o New extension revision-label-scheme
	o To include submodules, inclusion by revision-date changed from
	MUST to SHOULD
	o Submodules can use revision label scheme and it can be same or
	different as the including module's scheme
	o Addressed various comments provided at WG adoption on rev-00
	Authors' Addresses		Authors' Addresses
	Robert Wilton (editor)		Robert Wilton (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: rwilton@cisco.com		Email: rwilton@cisco.com
	Reshad Rahman (editor)		Reshad Rahman (editor)
	Email: reshad@yahoo.com		Email: reshad@yahoo.com
	Balazs Lengyel (editor)		Balazs Lengyel (editor)
End of changes. 198 change blocks.
	711 lines changed or deleted		758 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/