< draft-ietf-netmod-yang-module-versioning-02.txt		draft-ietf-netmod-yang-module-versioning-03.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: August 26, 2021 B. Lengyel, Ed.		Expires: January 13, 2022 B. Lengyel, Ed.
	Ericsson		Ericsson
	J. Clarke		J. Clarke
	Cisco Systems, Inc.		Cisco Systems, Inc.
	J. Sterne		J. Sterne
	Nokia		Nokia
	B. Claise		July 12, 2021
	Huawei
	K. D'Souza
	AT&T
	February 22, 2021
	Updated YANG Module Revision Handling		Updated YANG Module Revision Handling
	draft-ietf-netmod-yang-module-versioning-02		draft-ietf-netmod-yang-module-versioning-03
	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 help and guidelines for managing the
	lifecycle of YANG modules and individual schema nodes. It provides a		lifecycle of YANG modules and individual schema nodes. It provides a
	mechanism, via the revision-label YANG extension, to specify a		mechanism, via the revision-label YANG extension, to specify a
	revision identifier for YANG modules. This document updates RFC		revision identifier for YANG modules and submodules. This document
	7950, RFC 8407 and RFC 8525.		updates RFC 7950, 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 August 26, 2021.		This Internet-Draft will expire on January 13, 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are 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 for config data . . . . . 6		3.1.1. Backwards-compatible rules . . . . . . . . . . . . . 6
	3.1.2. Backwards-compatibility rules for config false and		3.1.2. Non-backwards-compatible changes . . . . . . . . . . 7
	output data . . . . . . . . . . . . . . . . . . . . . 7		3.2. non-backwards-compatible revision extension statement . . 7
	3.1.3. Non-backwards-compatible changes . . . . . . . . . . 8		3.3. Removing revisions from the revision history . . . . . . 7
	3.2. nbc-changes revision extension statement . . . . . . . . 8		3.4. Revision label . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Revision label . . . . . . . . . . . . . . . . . . . . . 8		3.4.1. File names . . . . . . . . . . . . . . . . . . . . . 8
	3.3.1. Revision label scheme extension statement . . . . . . 10		3.4.2. Revision label scheme extension statement . . . . . . 9
	3.3.2. Removing revisions from the revision history . . . . 10		3.5. Examples for updating the YANG module revision history . 9
	3.4. Examples for updating the YANG module revision history . 10		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 . . . . . . . . . . . . . . . . . . . . . . . 17		handled . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Versioning of YANG instance data . . . . . . . . . . . . . . 18		6. Versioning of YANG instance data . . . . . . . . . . . . . . 17
	7. Guidelines for using the YANG module update rules . . . . . . 18		7. Guidelines for using the YANG module update rules . . . . . . 17
	7.1. Guidelines for YANG module authors . . . . . . . . . . . 18		7.1. Guidelines for YANG module authors . . . . . . . . . . . 17
	7.1.1. Making non-backwards-compatible changes to a YANG		7.1.1. Making non-backwards-compatible changes to a YANG
	module . . . . . . . . . . . . . . . . . . . . . . . 19		module . . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Versioning Considerations for Clients . . . . . . . . . . 20		7.2. Versioning Considerations for Clients . . . . . . . . . . 20
	8. Module Versioning Extension YANG Modules . . . . . . . . . . 21		8. Module Versioning Extension YANG Modules . . . . . . . . . . 20
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 29		10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	11.1. YANG Module Registrations . . . . . . . . . . . . . . . 30		11.1. YANG Module Registrations . . . . . . . . . . . . . . . 30
	11.2. Guidance for versioning in IANA maintained YANG modules 30		11.2. Guidance for versioning in IANA maintained YANG modules 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	12.1. Normative References . . . . . . . . . . . . . . . . . . 31		12.1. Normative References . . . . . . . . . . . . . . . . . . 32
	12.2. Informative References . . . . . . . . . . . . . . . . . 32		12.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Examples of changes that are NBC . . . . . . . . . . 34		Appendix A. Examples of changes that are NBC . . . . . . . . . . 34
	Appendix B. Examples of applying the NBC change guidelines . . . 34		Appendix B. Examples of applying the NBC change guidelines . . . 35
	B.1. Removing a data node . . . . . . . . . . . . . . . . . . 34		B.1. Removing a data node . . . . . . . . . . . . . . . . . . 35
	B.2. Changing the type of a leaf node . . . . . . . . . . . . 35		B.2. Changing the type of a leaf node . . . . . . . . . . . . 36
	B.3. Reducing the range of a leaf node . . . . . . . . . . . . 36		B.3. Reducing the range of a leaf node . . . . . . . . . . . . 37
	B.4. Changing the key of a list . . . . . . . . . . . . . . . 36		B.4. Changing the key of a list . . . . . . . . . . . . . . . 37
	B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 37		B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 38
	B.6. Changing a default value . . . . . . . . . . . . . . . . 38		B.6. Changing a default value . . . . . . . . . . . . . . . . 39
	Appendix C. Changes between revisions . . . . . . . . . . . . . 38		Appendix C. Changes between revisions . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	This document defines a solution to the YANG module lifecycle		This document defines a solution to the YANG module lifecycle
	problems described in [I-D.ietf-netmod-yang-versioning-reqs].		problems described in [I-D.ietf-netmod-yang-versioning-reqs].
	Complementary documents provide a complete solution to the YANG		Complementary documents provide a complete solution to the YANG
	versioning requirements, with the overall relationship of the		versioning requirements, with the overall relationship of the
	solution drafts described in [I-D.ietf-netmod-yang-solutions].		solution drafts described in [I-D.ietf-netmod-yang-solutions].
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 48 ¶
	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 descriptions, to report how		revision label in the module and submodule descriptions, to report
	"deprecated" and "obsolete" nodes are handled by a server, and to		how "deprecated" and "obsolete" nodes are handled by a server, and
	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. Section 3 describes
	modifications to YANG revision handling and update rules, and		modifications to YANG revision handling and update rules, and
	Section 4 describes a YANG extension statement to do import by		Section 4 describes a YANG extension statement to do import by
	derived revision.		derived revision.
			This document updates [RFC7950] section 5.2. Section 3.4.1 describes
			the use of a revision label in the name 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. Section 5.1 defines
	how a client of a YANG library datastore schema resolves ambiguous		how a client of a YANG library datastore schema resolves ambiguous
	imports for modules which are not "import-only".		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 [RFC7950] section 5.2. Section 3.3 describes		This document updates [RFC8525] with augmentations to include
	the use of a revision label in the name of a file containing a YANG		revision labels in the YANG library data and two boolean leaves to
	module or submodule.		indicate whether status deprecated and status obsolete schema nodes
			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 terminology:
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	o YANG module revision: An instance of a YANG module, uniquely		o 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		o 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		o 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.3		Section 3.1.2
	o Valuespace: The valuespace of a leaf or leaf-list is the set of
	values that the schema node may have according to the type and
	constraint statements of the YANG model.
	3. Refinements to YANG revision handling		3. Refinements to YANG revision handling
	[RFC7950] assumes, but does not explicitly state, that the revision		[RFC7950] assumes, but does not explicitly state, that the revision
	history for a YANG module is strictly linear, i.e., it is prohibited		history for a YANG module or submodule is strictly linear, i.e., it
	to have two independent revisions of a YANG module that are both		is prohibited to have two independent revisions of a YANG module or
	directly derived from the same parent revision.		submodule that are both directly derived from the same parent
			revision.
	This document clarifies [RFC7950] to explicitly allow non linear		This document clarifies [RFC7950] to explicitly allow non-linear
	development of YANG module revisions, so modules MAY have multiple		development of YANG module and submodule revisions, so that they MAY
	revisions that directly derive from the same parent revision. As per		have multiple revisions that directly derive from the same parent
	[RFC7950], YANG module revisions continue to be uniquely identified		revision. As per [RFC7950], YANG module and submodule revisions
	by the module's revision date, and hence all revisions of a module		continue to be uniquely identified by their revision date, and hence
	MUST have unique revision dates.		all revisions of a given module or submodule 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
	revisions cannot be determined by comparing the module revision date		or submodule revisions cannot be determined by comparing the module
	alone, and the revision history, or revision label, must also be		or submodule revision date alone, and the revision history, or
	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 [RFC7895]
	[RFC8525], MAY be used to specify the exact submodule revisions used		[RFC8525], MAY be used to specify the exact submodule revisions used
	when the submodule revision date is not constrained by the "include"		when the 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 requires that all updates to a YANG module are
	BC to the previous revision of the module. This document allows for		BC to the previous revision of the module. This document introduces
	more flexible evolution of YANG modules: NBC changes between module		a method to indicate that an NBC change has occurred between module
	revisions are allowed and are documented using a new "nbc-changes"		revisions: this is done by using a new "non-backwards-compatible"
	YANG extension statement in the module revision history.		YANG extension statement in the module revision history.
	Two revisions of a module MAY have identical content except for the		Two revisions of a module or submodule MAY have identical content
	revision history. This could occur, for example, if a module has a		except for the revision history. This could occur, for example, if a
	branched history and identical changes are applied in multiple		module or submodule has a branched history and identical changes are
	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 to refine the rules for
	permissible changes when a new YANG module revision is created.		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, i.e., the semantics of		A new module revision MAY contain NBC changes, e.g., the semantics of
	an existing definition MAY be changed in an NBC way without requiring		an existing data-node definition MAY be changed in an NBC manner
	a new definition with a new identifier. A new module revision with		without requiring a new data-node definition with a new identifier.
	NBC changes MUST include the "rev:nbc-changes" extension substatement		A YANG extension, defined in Section 3.2, is used to signal the
	to signal the potential for incompatibility to existing module users		potential for incompatibility to existing module users and readers.
	and readers.
	3.1.1. Backwards-compatible rules for config data		As per [RFC7950], all published revisions of a module are given a new
			unique revision date. This applies even for module revisions
			containing (in the module or included submodules) only changes to any
			whitespace, formatting, comments or line endings (e.g., DOS vs UNIX).
			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, updated by the following rules:
	o A "status" "deprecated" statement MAY be added, or changed from		o 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 Obsolete definitions MAY be removed from published modules, and		o YANG schema nodes with a "status" "obsolete" substatement MAY be
	are classified as backwards-compatible changes. In some		removed from published modules, and are classified as backwards-
	circumstances it may be helpful to retain the obsolete definitions		compatible changes. In some circumstances it may be helpful to
	to ensure that their identifiers are not reused with a different		retain the obsolete definitions to ensure that their identifiers
	meaning.		are not reused with a different meaning.
	o In statements that have any data definition statements as		o 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		o Any changes (including whitespace or formatting changes) that do
	not change the semantic meaning of the module are backwards		not change the semantic meaning of the module are backwards
	compatible.		compatible.
	3.1.2. Backwards-compatibility rules for config false and output data		o A statement that is defined using the YANG "extension" statement
			MAY be added, removed, or changed, if it does not change the
	Compatibility behavior of configuration and state data is different.		semantics of the module. Extension statement definitions SHOULD
	While adding a mandatory configuration leaf makes earlier		specify whether adding, removing, or changing statements defined
	configurations invalid, an additional state leaf can easily be		by that extension are backwards-compatible or non-backwards-
	discarded. Decreasing the valuespace of a configuration leaf makes		compatible.
	any configuration invalid that uses the newly excluded values;
	decreasing the valuespace of a state schema node should not disturb a
	client application. Data in the output section of notifications,
	actions or rpcs is governed by the same backwards compatibility
	behavior as config=false data.
	While incoming configuration data is checked according to YANG
	constraints, constraints on state data sent by the server MAY or MAY
	NOT be enforced. The following guidelines are provided for client
	application designers to allow a smooth interworking with servers.
	o A client MUST tolerate any data received (or not received) without
	crashing.
	o A client MUST be able to discard any data that is not part of the
	model but is sent by the server additionally (e.g. XML elements
	or attributes, JSON properties).
	o A client SHOULD be able to handle valid parts of a received data
	set even if it discards other parts as invalid.
	o A client SHOULD be able to handle data that is outside the
	valuespace defined, as long as it is of the same basic type.
	o A client SHOULD be prepared to handle more items for a list or
	leaf-list than what is defined by the model.
	Based on the above client guidelines and the intent to allow the
	correct and flexible handling of state and output data even after
	module revision changes the following rules define which config false
	and output schema changes are considered BC or NBC. The rules
	reflect common client behavior, however a client that expects a
	specific server behavior or data set may have problems with any
	change. The rules are defined as a compromise between protecting
	client applications and allowing the most common changes.
	o Adding mandatory or optional schema nodes is BC
	o Changing an optional schema node to mandatory is BC
	o Removal of a mandatory or optional schema node is NBC
	o Changing a mandatory schema node to optional is NBC
	o Expanding the valuespace of a leaf or leaf-list is BC. Change of
	the valuespace may be the result of a change to a range, length,
	pattern, base, enum, bit, require-instance or must statements.
	o Decreasing the valuespace of a leaf or leaf-list is BC
	o Changing max-elements is BC
	o Increasing min-element is BC
	o Changing min-elements to a lower value is NBC (it is like removing
	mandatory)
	o Modifying the type of a leaf or leaf-list is NBC
	3.1.3. 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 or		Any changes to YANG modules that are not defined by Section 3.1.1 as
	Section 3.1.2 as being backwards-compatible are classified as "non-		being backwards-compatible are classified as "non-backwards-
	backwards-compatible" changes.		compatible" changes.
	3.2. nbc-changes revision extension statement		3.2. non-backwards-compatible revision extension statement
	The "rev:nbc-changes" extension statement is used to indicate YANG		The "rev:non-backwards-compatible" extension statement is used to
	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 or Section 3.1.2,		the module update rules defined in Section 3.1.1, then a "rev:non-
	then a "rev:nbc-changes" 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.
	Conversely, if a revision does not contain an "rev:nbc-changes"		3.3. Removing revisions from the revision history
	extension substatement then all changes, relative to the preceding
	revision in the revision history, MUST be backwards-compatible.
	3.3. Revision label		Authors may wish to remove revision statements from a module or
			submodule. Removal of revision information may be desired for a
			number of reasons including reducing the size of a large revision
			history, or removing a revision that should no longer be used or
			imported. Removing revision statements is allowed, but can cause
			issues and SHOULD NOT be done without careful analysis of the
			potential impact to users of the module or submodule. Doing so can
			lead to import breakages when import by revision-or-derived is used.
			Moreover, truncating history may cause loss of visibility of when
			non-backwards-compatible changes were introduced.
	This section updates [RFC7950] section 5.2, it explains how a		If a revision containing a rev:non-backwards-compatible substatement
	revision label can be used in the name of a file containing a YANG		is removed from the revision history then a rev:non-backwards-
	module or submodule.		compatible substatement MUST be added to the nearest newer revision
			entry in the revision history that is not being removed.
			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		YANG Semver [I-D.ietf-netmod-yang-semver] defines a versioning scheme
	based on Semver 2.0.0 [semver] that can be used as a revision label.		based on Semver 2.0.0 [semver] that can be used as a revision label.
	skipping to change at page 9, line 24 ¶		skipping to change at page 8, line 30 ¶
	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 an "rev:revision-or-derived"		instead of the revision date in a "rev:revision-or-derived" extension
	extension statement argument.		statement argument.
	A specific revision-label identifies a specific revision (variant) of		A specific revision-label identifies a specific revision (variant) of
	the module. If two YANG modules contain the same module name and the		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 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
			This section updates [RFC7950] 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
	SHOULD exist for the same module (or submodule) revision. Two file		SHOULD exist for the same module (or submodule) revision. Two file
	names, one with the revision date and another with the revision		names, one with the revision date and another with the revision
	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.3.1. Revision label scheme extension statement		3.4.2. Revision label scheme extension statement
	The "rev:revision-label-scheme" extension statement is used to		The optional "rev:revision-label-scheme" extension statement is used
	indicate which revision-label scheme a module or submodule uses. The		to indicate which revision-label scheme a module or submodule uses.
	mandatory argument to this extension statement:		There MUST NOT be more than one revision label scheme in a module or
			submodule. The mandatory argument to this extension statement:
	o Specifies the revision-label scheme used by the module or		o specifies the revision-label scheme used by the module or
	submodule		submodule
	o Is defined in the document which specifies the revision-label		o is defined in the document which specifies the revision-label
	scheme		scheme
	o MUST be an identity derived from "revision-label-scheme-base"		o 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.3.2. Removing revisions from the revision history		3.5. Examples for updating the YANG module revision history
	Module authors may wish to remove revision statements from a module
	or submodule. Removal of revision information may be desired for a
	number of reasons including reducing the size of a large revision
	history, or removing a revision that should no longer be used or
	imported. Removing revision statements is allowed, but can cause
	issues and SHOULD NOT be done without careful analysis of the impacts
	to users of the module or submodule. Doing so can lead to import
	breakages when import by revision-or-derived is used. Moreover,
	truncating history may cause loss of visibility of when non-
	backwards-compatible changes were introduced.
	3.4. Examples for updating the YANG module revision history
	The following diagram, explanation, and module history illustrates		The following diagram, explanation, and module history illustrates
	how the branched revision history, "nbc-changes" extension statement,		how the branched revision history, "non-backwards-compatible"
	and "revision-label" extension statement could be used:		extension statement, and "revision-label" extension statement could
			be used:
	Example YANG module with branched revision history.		Example YANG module with branched revision history.
	Module revision date Revision label		Module revision date Revision label
	2019-01-01 <- 1.0.0		2019-01-01 <- 1.0.0
	|		|
	2019-02-01 <- 2.0.0		2019-02-01 <- 2.0.0
	| \		| \
	2019-03-01 \ <- 3.0.0		2019-03-01 \ <- 3.0.0
	| \		| \
	| 2019-04-01 <- 2.1.0		| 2019-04-01 <- 2.1.0
	| |		| |
	| 2019-05-01 <- 2.2.0		| 2019-05-01 <- 2.2.0
	|		|
	2019-06-01 <- 3.1.0		2019-06-01 <- 3.1.0
	The tree diagram above illustrates how an example module's revision		The tree diagram above illustrates how an example module's revision
	history might evolve, over time. For example, the tree might		history might evolve, over time. For example, the tree might
	represent the following changes, listed in chronological order from		represent the following changes, listed in chronological order from
	oldest revision to newest:		the oldest revision to the newest revision:
	Example module, revision 2019-06-01:		Example module, revision 2019-06-01:
	module example-module {		module example-module {
	namespace "urn:example:module";		namespace "urn:example:module";
	prefix "prefix-name";		prefix "prefix-name";
			rev:revision-label-scheme "yangver:yang-semver";
	import ietf-yang-revisions { prefix "rev"; }		import ietf-yang-revisions { prefix "rev"; }
			import ietf-yang-semver { prefix "yangver"; }
	description		description
	"to be completed";		"to be completed";
	revision 2019-06-01 {		revision 2019-06-01 {
	rev:revision-label 3.1.0;		rev:revision-label 3.1.0;
	description "Add new functionality.";		description "Add new functionality.";
	}		}
	revision 2019-03-01 {		revision 2019-03-01 {
	rev:revision-label 3.0.0;		rev:revision-label 3.0.0;
	rev:nbc-changes;		rev:non-backwards-compatible;
	description		description
	"Add new functionality. Remove some deprecated nodes.";		"Add new functionality. Remove some deprecated nodes.";
	}		}
	revision 2019-02-01 {		revision 2019-02-01 {
	rev:revision-label 2.0.0;		rev:revision-label 2.0.0;
	rev:nbc-changes;		rev:non-backwards-compatible;
	description "Apply bugfix to pattern statement";		description "Apply bugfix to pattern statement";
	}		}
	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
	}		}
	Example module, revision 2019-05-01:		Example module, revision 2019-05-01:
	module example-module {		module example-module {
	namespace "urn:example:module";		namespace "urn:example:module";
	prefix "prefix-name";		prefix "prefix-name";
			rev:revision-label-scheme "yangver:yang-semver";
	import ietf-yang-revisions { prefix "rev"; }		import ietf-yang-revisions { prefix "rev"; }
			import ietf-yang-semver { prefix "yangver"; }
	description		description
	"to be completed";		"to be completed";
	revision 2019-05-01 {		revision 2019-05-01 {
	rev:revision-label 2.2.0;		rev:revision-label 2.2.0;
	description "Backwards-compatible bugfix to enhancement.";		description "Backwards-compatible bugfix to enhancement.";
	}		}
	revision 2019-04-01 {		revision 2019-04-01 {
	rev:revision-label 2.1.0;		rev:revision-label 2.1.0;
	description "Apply enhancement to older release train.";		description "Apply enhancement to older release train.";
	}		}
	revision 2019-02-01 {		revision 2019-02-01 {
	rev:revision-label 2.0.0;		rev:revision-label 2.0.0;
	rev:nbc-changes;		rev:non-backwards-compatible;
	description "Apply bugfix to pattern statement";		description "Apply bugfix to pattern statement";
	}		}
	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
	}		}
	skipping to change at page 14, line 5 ¶		skipping to change at page 13, line 5 ¶
	RFC 7950 allows YANG module "import" statements to optionally require		RFC 7950 allows YANG module "import" statements to optionally require
	the imported module to have a particular revision date. In practice,		the imported module to have a particular revision date. In practice,
	importing a module with an exact revision date is often too		importing a module with an exact revision date is often too
	restrictive because it requires the importing module to be updated		restrictive because it requires the importing module to be updated
	whenever any change to the imported module occurs. The alternative		whenever any change to the imported module occurs. The alternative
	choice of using an import statement without any revision date		choice of using an import statement without any revision date
	statement is also not ideal because the importing module may not work		statement is also not ideal because the importing module may not work
	with all possible revisions of the imported module.		with all possible revisions of the imported module.
	Instead, it is desirable for a importing module to specify a "minimum		Instead, it is desirable for an importing module to specify a
	required revision" of a module that it is compatible with, based on		"minimum required revision" of a module that it is compatible with,
	the assumption that later revisions derived from that "minimum		based on the assumption that later revisions derived from that
	required revision" are also likely to be compatible. Many possible		"minimum required revision" are also likely to be compatible. Many
	changes to a YANG module do not break importing modules, even if the		possible changes to a YANG module do not break importing modules,
	changes themselves are not strictly backwards-compatible. E.g.,		even if the changes themselves are not strictly backwards-compatible.
	fixing an incorrect pattern statement or description for a leaf would		E.g., fixing an incorrect pattern statement or description for a leaf
	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
	imports if that container is augmented by another module.		imports if that container is augmented by another module.
	The ietf-revisions module defines the "revision-or-derived" extension		The ietf-revisions module defines the "revision-or-derived" extension
	statement, a substatement to the YANG "import" statement, to allow		statement, a substatement to the YANG "import" statement, to allow
	for a "minimum required revision" to be specified during import:		for a "minimum required revision" to be specified during import:
	The argument to the "revision-or-derived" extension statement is a		The argument to the "revision-or-derived" extension statement is a
	revision date or a revision label.		revision date or a revision label.
	skipping to change at page 15, line 7 ¶		skipping to change at page 14, line 7 ¶
	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		Adding, modifying or removing a "revision-date" extension
	statement is considered to be a BC change.		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.4 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
	|		|
	2019-02-01 <- 2.0.0		2019-02-01 <- 2.0.0
	| \		| \
	skipping to change at page 15, line 31 ¶		skipping to change at page 14, line 31 ¶
	| |		| |
	| 2019-05-01 <- 2.2.0		| 2019-05-01 <- 2.2.0
	|		|
	2019-06-01 <- 3.1.0		2019-06-01 <- 3.1.0
	4.1.1. Example 1		4.1.1. Example 1
	This example selects module revisions that match, or are derived from		This example selects module revisions that match, or are derived from
	the revision 2019-02-01. E.g., this dependency might be used if		the revision 2019-02-01. E.g., this dependency might be used if
	there was a new container added in revision 2019-02-01 that is		there was a new container added in revision 2019-02-01 that is
	augmented by the importing module.It includes revisions/labels:		augmented by the importing module. It includes revisions/labels:
	2019-02-01/2.0.0, 2019-03-01/3.0.0, 2019-04-01/2.1.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.		2019-05-01/2.2.0 and 2019-06-01/3.1.0.
	import example-module {		import example-module {
	rev:revision-or-derived 2019-02-01;		rev:revision-or-derived 2019-02-01;
	}		}
	Alternatively, the first example could have used the revision label		Alternatively, the first example could have used the revision label
	"2.0.0" instead, which selects the same set of revisions/labels.		"2.0.0" instead, which selects the same set of revisions/labels.
	skipping to change at page 17, line 18 ¶		skipping to change at page 16, line 18 ¶
	with the latest revision date.		with the latest revision date.
	5.2. YANG library versioning augmentations		5.2. YANG library versioning augmentations
	The "ietf-yang-library-revisions" YANG module has the following		The "ietf-yang-library-revisions" YANG module has the following
	structure (using the notation defined in [RFC8340]):		structure (using the notation defined in [RFC8340]):
	module: ietf-yang-library-revisions		module: ietf-yang-library-revisions
	augment /yanglib:yang-library/yanglib:module-set/yanglib:module:		augment /yanglib:yang-library/yanglib:module-set/yanglib:module:
	+--ro revision-label? rev:revision-label		+--ro revision-label? rev:revision-label
			augment /yanglib:yang-library/yanglib:module-set/yanglib:module
			/yanglib:submodule:
			+--ro revision-label? rev:revision-label
			augment /yanglib:yang-library/yanglib:module-set
			/yanglib:import-only-module/yanglib:submodule:
			+--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"
	list in ietf-yang-library with a "revision-label" leaf to optionally		list in ietf-yang-library with a "revision-label" leaf to optionally
	declare the revision label associated wth the particular revision of		declare the revision label associated wth the particular revision of
	each module.		each module.
	skipping to change at page 18, line 6 ¶		skipping to change at page 17, line 11 ¶
	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" nodes. If
	this leaf is set to "false" or absent, then the behaviour is		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" leaves 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:nbc-changes"		"true", then clients MUST NOT rely solely on the "rev:non-backwards-
	statements to determine whether two module revisions are backwards-		compatible" statements to determine whether two module revisions are
	compatible, and MUST also consider whether the status of any nodes		backwards-compatible, and MUST also consider whether the status of
	has changed to "deprecated" and whether those nodes are implemented		any nodes has changed to "deprecated" and whether those nodes are
	by the server.		implemented by the server.
	6. Versioning of YANG instance data		6. Versioning of YANG instance data
	Instance data sets [I-D.ietf-netmod-yang-instance-file-format] do not		Instance data sets [I-D.ietf-netmod-yang-instance-file-format] do not
	directly make use of the updated revision handling rules described in		directly make use of the updated revision handling rules described in
	this document, as compatibility for instance data is undefined.		this document, as compatibility for instance data is undefined.
	However, instance data specifies the content-schema of the data-set.		However, instance data specifies the content-schema of the data-set.
	This schema SHOULD make use of versioning using revision dates and/or		This schema SHOULD make use of versioning using revision dates and/or
	revision labels for the individual YANG modules that comprise the		revision labels for the individual YANG modules that comprise the
	schema or potentially for the entire schema itself (e.g.,		schema or potentially for the entire schema itself (e.g.,
	[I-D.ietf-netmod-yang-packages] ).		[I-D.ietf-netmod-yang-packages]).
	In this way, the versioning of a content-schema associated with an		In this way, the versioning of a content-schema associated with an
	instance data set may help a client to determine whether the instance		instance data set may help a client to determine whether the instance
	data could also be used in conjunction with other revisions of the		data could also be used in conjunction with other revisions of the
	YANG schema, or other revisions of the modules that define the		YANG schema, or other revisions of the modules that define the
	schema.		schema.
	7. Guidelines for using the YANG module update rules		7. Guidelines for using the YANG module update rules
	The following text updates section 4.7 of [RFC8407] to revise the		The following text updates section 4.7 of [RFC8407] to revise the
	skipping to change at page 18, line 51 ¶		skipping to change at page 18, line 9 ¶
	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 are
	RECOMMENDED to minimize NBC changes and keep changes BC whenever		RECOMMENDED to 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:nbc-changes" statement MUST be added if there are NBC changes		A "rev:non-backwards-compatible" statement MUST be added if there are
	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 depencencies 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 remove, or curtail, the older		revision section is too long, would be to remove, or curtail, the
	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. The revision-label substatement used in the new module
	revision MUST indicate the nature of the change, i.e. NBC or BC, to		revision MUST indicate the nature of the change, i.e. NBC or BC, to
	the module's schema tree.		the module's schema tree.
			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
			the "non-backwards-compatible" statement. Here is an example when
			adding the statement may be desirable:
			o A "config false" leaf had its value space expanded (for example, a
			range was increased, or additional enum values were added) and the
			author or server implementor feels there is a significant
			compatibility impact for clients and users of the module or
			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		o 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"		o 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		o 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 [I-D.ietf-netmod-yang-packages]),
	and allows the client to select the revision (as per		and allows the client to select the revision (as per
	[I-D.ietf-netmod-yang-ver-selection]), then NBC changes MAY be		[I-D.ietf-netmod-yang-ver-selection]), then NBC changes MAY be
	done without using "status" statements. Clients would be required		done without using "status" statements. Clients would be required
	to select the revision which they support and the NBC change would		to select the revision which they support and the NBC change would
	have no impact on them		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" and then when support is removed its status
	MUST be changed to "obsolete". Instead of using the "obsolete"		MUST be changed to "obsolete". Instead of using the "obsolete"
	status, the data node MAY be removed from the model but this has		status, the data node MAY be removed from the model but this has
	the risk of breaking modules which import the modified module.		the risk of breaking modules which import the modified module.
	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
	skipping to change at page 20, line 31 ¶		skipping to change at page 19, line 50 ¶
	4. When obsoleting or deprecating data nodes, the "deprecated" or		4. When obsoleting or deprecating data nodes, the "deprecated" or
	"obsolete" status SHOULD be applied at the highest possible level		"obsolete" status SHOULD be applied at the highest possible level
	in the data tree. For clarity, the "status" statement SHOULD		in the data tree. For clarity, the "status" statement SHOULD
	also be applied to all descendent data nodes, but the additional		also be applied to all descendent data nodes, but the additional
	status related information does not need to be repeated if it		status related information does not need to be repeated if it
	does not introduce any additional information.		does not introduce any additional information.
	5. NBC changes which can break imports SHOULD be avoided because of		5. NBC changes which can break imports SHOULD be avoided because of
	the impact on the importing module. The importing modules could		the impact on the importing module. The importing modules could
	get broken, e.g. if an augmented node in the importing module has		get broken, e.g., if an augmented node in the importing module
	been removed from the imported module. Alternatively, the schema		has been removed from the imported module. Alternatively, the
	of the importing modules could undergo an NBC change due to the		schema of the importing modules could undergo an NBC change due
	NBC change in the imported module, e.g. if a node in a grouping		to the NBC change in the imported module, e.g., if a node in a
	has been removed. As described in Appendix B.1, instead of		grouping has been removed. As described in Appendix B.1, instead
	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		o Clients SHOULD be liberal when processing data received from a
	skipping to change at page 21, line 22 ¶		skipping to change at page 20, line 38 ¶
	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-02-17.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>
	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: Benoit Claise		Author: Reshad Rahman
	<mailto:benoit.claise@huawei.com>		<mailto:reshad@yahoo.com>
	Author: Joe Clarke		Author: Robert Wilton
	<mailto:jclarke@cisco.com>		<mailto:rwilton@cisco.com>
	Author: Reshad Rahman		Author: Balazs Lengyel
	<mailto:reshad@yahoo.com>		<mailto:balazs.lengyel@ericsson.com>
	Author: Robert Wilton		Author: Jason Sterne
	<mailto:rwilton@cisco.com>		<mailto:jason.sterne@nokia.com>";
			description
			"This YANG 1.1 module contains definitions and extensions to
			support updated YANG revision handling.
	Author: Kevin D'Souza		Copyright (c) 2021 IETF Trust and the persons identified as
	<mailto:kd6913@att.com>		authors of the code. All rights reserved.
	Author: Balazs Lengyel		Redistribution and use in source and binary forms, with or
	<mailto:balazs.lengyel@ericsson.com>		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).
	Author: Jason Sterne		This version of this YANG module is part of RFC XXXX; see
	<mailto:jason.sterne@nokia.com>";		the RFC itself for full legal notices.
	description
	"This YANG 1.1 module contains definitions and extensions to
	support updated YANG revision handling.
	Copyright (c) 2019 IETF Trust and the persons identified as		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	authors of the code. All rights reserved.		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
			'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.";
	Redistribution and use in source and binary forms, with or		// RFC Ed.: update the date below with the date of RFC publication
	without modification, is permitted pursuant to, and subject		// and remove this note.
	to the license terms contained in, the Simplified BSD License		// RFC Ed.: replace XXXX (inc above) with actual RFC number and
	set forth in Section 4.c of the IETF Trust's Legal Provisions		// remove this note.
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		revision 2021-06-30 {
	the RFC itself for full legal notices.		description
			"Initial version.";
			reference
			"XXXX: Updated YANG Module Revision Handling";
			}
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		typedef revision-label {
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		type string {
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		length "1..255";
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		pattern '[a-zA-Z0-9,\-_.+]+';
	they appear in all capitals, as shown here.";		pattern '\d{4}-\d{2}-\d{2}' {
			modifier invert-match;
			}
			}
			description
			"A label associated with a YANG revision.
	// RFC Ed.: update the date below with the date of RFC publication		Alphanumeric characters, comma, hyphen, underscore, period
	// and remove this note.		and plus are the only accepted characters. MUST NOT match
	// RFC Ed.: replace XXXX (inc above) with actual RFC number and		revision-date.";
	// remove this note.		reference
			"XXXX: Updated YANG Module Revision Handling;
			Section 3.3, Revision label";
			}
	revision 2021-02-17 {		typedef revision-date-or-label {
	description		type union {
	"Initial version.";		type yang:revision-identifier;
	reference		type revision-label;
	"XXXX: Updated YANG Module Revision Handling";		}
	}		description
			"Represents either a YANG revision date or a revision label";
			}
	typedef revision-label {		extension nbc-changes {
	type string {		description
	length "1..255";		"This statement is used to indicate YANG module revisions that
	pattern '[a-zA-Z0-9,\-_.+]+';		contain non-backwards-compatible changes.
	pattern '\d{4}-\d{2}-\d{2}' {
	modifier invert-match;
	}
	}
	description
	"A label associated with a YANG revision.
	Alphanumeric characters, comma, hyphen, underscore, period		The statement MUST only be a substatement of the 'revision'
	and plus are the only accepted characters. MUST NOT match		statement. Zero or one 'non-backwards-compatible' statements
	revision-date.";		per parent statement is allowed. No substatements for this
	reference		extension have been standardized.
	"XXXX: Updated YANG Module Revision Handling;
	Section 3.3, Revision label";
	}
	typedef revision-date-or-label {		If a revision of a YANG module contains changes, relative to
	type union {		the preceding revision in the revision history, that do not
	type yang:revision-identifier;		conform to the module update rules defined in RFC-XXX, then
	type revision-label;		the 'non-backwards-compatible' statement MUST be added as a
	}		substatement to the revision statement.
	description
	"Represents either a YANG revision date or a revision label";
	}
	extension nbc-changes {		Conversely, if a revision does not contain a
	description		'non-backwards-compatible' statement then all changes,
	"This statement is used to indicate YANG module revisions that		relative to the preceding revision in the revision history,
	contain non-backwards-compatible changes.		MUST be backwards-compatible.
	The statement MUST only be a substatement of the 'revision'		A new module revision that only contains changes that are
	statement.		backwards compatible SHOULD NOT include the
	Zero or one 'nbc-changes' statement per parent statement is		'non-backwards-compatible' statement. An example of when
	allowed.		an author might add the 'non-backwards-compatible' statement
	The statement MUST NOT have any substatements.		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.
	If a revision of a YANG module contains changes, relative to		Add, removing, or changing a 'non-backwards-compatible'
	the preceding revision in the revision history, that do not		statement is a backwards-compatible version change.";
	conform to the module update rules defined in RFC-XXX, then
	the 'nbc-changes' statement MUST be added as a substatement to
	the revision statement.
	Conversely, if a revision of a YANG module only contains		reference
	changes, relative to the preceding revision in the revision		"XXXX: Updated YANG Module Revision Handling;
	history, that are classified as 'backwards-compatible' then		Section 3.2, nbc-changes revision extension statement";
	the revision statement MUST NOT contain any 'nbc-changes'		}
	substatement.";
	reference		extension revision-label {
	"XXXX: Updated YANG Module Revision Handling;		argument revision-label;
	Section 3.2, nbc-changes revision extension statement";		description
	}		"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].
	extension revision-label {		The format of the revision-label argument MUST conform to the
	argument revision-label;		pattern defined for the revision-label typedef.
	description
	"The revision label can be used to provide an additional
	versioning identifier associated with the revision. E.g., one
	option for a versioning scheme that could be used is [TODO -
	Reference semver draft].
	The format of the revision-label argument MUST conform to the		The statement MUST only be a substatement of the revision
	pattern defined for the revision-label typedef.		statement. Zero or one revision-label statements per parent
			statement are allowed. No substatements for this extension
			have been standardized.
	The statement MUST only be a substatement of the revision		Revision labels MUST be unique amongst all revisions of a
	statement.		module or submodule.
	Zero or one revision-label statement per parent statement
	is allowed.
	The statement MUST NOT have any substatements.
	Revision labels MUST be unique amongst all revisions of a		Adding a revision label is a backwards-compatible version
	module.";		change. Changing or removing an existing revision label in
			the revision history is a non-backwards-compatible version
			change, because it could impact any references to that
			revision label.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 3.3, Revision label";		Section 3.3, Revision label";
	}		}
	extension revision-label-scheme {		extension revision-label-scheme {
	argument revision-label-scheme-identity;		argument revision-label-scheme-identity;
	description		description
	"The revision label scheme specifies which revision-label scheme		"The revision label scheme specifies which revision-label scheme
	the module or submodule uses.		the module or submodule uses.
	The mandatory revision-label-scheme-identity argument MUST be an		The mandatory revision-label-scheme-identity argument MUST be an
	identity derived from revision-label-scheme-base.		identity derived from revision-label-scheme-base.
	This extension is only valid as a top-level statement, i.e.,		This extension is only valid as a top-level statement, i.e.,
	given as as a substatement to 'module' or 'submodule'.		given as as a substatement to 'module' or 'submodule'. No
			substatements for this extension have been standardized.
	This extension MUST be used if there is a revision-label		This extension MUST be used if there is a revision-label
	statement in the module or submodule.		statement in the module or submodule.
	The statement MUST NOT have any substatements.";		Adding a revision label scheme is a backwards-compatible version
			change. Changing a revision label scheme is a
			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		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";
			}
	}		extension revision-or-derived {
			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.
	extension revision-or-derived {		The argument value MUST conform to the
	argument revision-date-or-label;		'revision-date-or-label' defined type.
	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 argument value MUST conform to the		The statement MUST only be a substatement of the import
	'revision-date-or-label' defined type.		statement. Zero, one or more 'revision-or-derived' statements
			per parent statement are allowed. No substatements for this
			extension have been standardized.
	The statement MUST only be a substatement of the import		If specified multiple times, then any module revision that
	statement.		satisfies at least one of the 'revision-or-derived' statements
	Zero, one or more 'revision-or-derived' statement per parent		is an acceptable revision for import.
	statement is allowed.
	The statement MUST NOT have any substatements.
	If specified multiple		An 'import' statement MUST NOT contain both a
	times, then any module revision that satisfies at least one of		'revision-or-derived' extension statement and a
	the 'revision-or-derived' statements is an acceptable revision		'revision-date' statement.
	for import.
	An 'import' statement MUST NOT contain both a		A particular revision of an imported module satisfies an
	'revision-or-derived' extension statement and a		import's 'revision-or-derived' extension statement if the
	'revision-date' statement.		imported module's revision history contains a revision
			statement with a matching revision date or revision label.
	A particular revision of an imported module satisfies an		The 'revision-or-derived' extension statement does not
	import's 'revision-or-derived' extension statement if the		guarantee that all module revisions that satisfy an import
	imported module's revision history contains a revision		statement are necessarily compatible, it only gives an
	statement with a matching revision date or revision label.		indication that the revisions are more likely to be
			compatible.
	The 'revision-or-derived' extension statement does not		Adding, removing or updating a 'revision-or-derived'
	guarantee that all module revisions that satisfy an import		statement to an import is a backwards-compatible change.
	statement are necessarily compatible, it only gives an		";
	indication that the revisions are more likely to be
	compatible.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 4, Import by derived revision";		Section 4, Import by derived revision";
	}		}
	identity revision-label-scheme-base {		identity revision-label-scheme-base {
	description		description
	"Base identity from which all revision label schemes are		"Base identity from which all revision label schemes are
	derived.";		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@2020-07-06.yang"		<CODE BEGINS> file "ietf-yang-library-revisions@2021-06-30.yang"
	module ietf-yang-library-revisions {		module ietf-yang-library-revisions {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library-revisions";		namespace
			"urn:ietf:params:xml:ns:yang:ietf-yang-library-revisions";
	prefix yl-rev;		prefix yl-rev;
	import ietf-yang-revisions {		import ietf-yang-revisions {
	prefix rev;		prefix rev;
	reference		reference
	"XXXX: Updated YANG Module Revision Handling";		"XXXX: Updated YANG Module Revision Handling";
	}		}
	import ietf-yang-library {		import ietf-yang-library {
	prefix yanglib;		prefix yanglib;
	reference "RFC 8525: YANG Library";		reference "RFC 8525: YANG Libary";
	}		}
	organization		organization
	"IETF NETMOD (Network Modeling) Working Group";		"IETF NETMOD (Network Modeling) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/netmod/>		"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Benoit Claise
	<mailto:benoit.claise@huawei.com>
	Author: Joe Clarke		Author: Joe Clarke
	<mailto:jclarke@cisco.com>		<mailto:jclarke@cisco.com>
	Author: Reshad Rahman		Author: Reshad Rahman
	<mailto:reshad@yahoo.com>		<mailto:reshad@yahoo.com>
	Author: Robert Wilton		Author: Robert Wilton
	<mailto:rwilton@cisco.com>		<mailto:rwilton@cisco.com>
	Author: Kevin D'Souza
	<mailto:kd6913@att.com>
	Author: Balazs Lengyel		Author: Balazs Lengyel
	<mailto:balazs.lengyel@ericsson.com>		<mailto:balazs.lengyel@ericsson.com>
	Author: Jason Sterne		Author: Jason Sterne
	<mailto:jason.sterne@nokia.com>";		<mailto:jason.sterne@nokia.com>";
	description		description
	"This module contains augmentations to YANG Library to add module		"This module contains augmentations to YANG Library to add module
	level revision label and to provide an indication of how		level revision label and to provide an indication of how
	deprecated and obsolete nodes are handled by the server.		deprecated and obsolete nodes are handled by the server.
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2021 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.		the RFC itself for full legal notices.
	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 2020-07-06 {		revision 2021-06-30 {
	rev:revision-label 0.1.0;		rev:revision-label 0.2.0;
	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" {		augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
	description		description
	"Augmentation modules with a revision label";		"Augmentation modules with a revision label";
	leaf revision-label {		leaf revision-label {
	skipping to change at page 28, line 15 ¶		skipping to change at page 27, line 43 ¶
	"The revision label associated with this module revision.		"The revision label associated with this module revision.
	The label MUST match the rev:label value in the specific		The label MUST match the rev:label value in the specific
	revision of the module loaded in this module-set.";		revision of 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/yanglib:module/"
			+ "yanglib:submodule" {
			description
			"Augment submodule information with a revision label";
			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 module loaded in
			this module-set.";
			reference
			"XXXX: Updated YANG Module Revision Handling;
			Section 5.2.1, Advertising revision-label";
			}
			}
			augment "/yanglib:yang-library/yanglib:module-set/"
			+ "yanglib:import-only-module/yanglib:submodule" {
			description
			"Augment submodule information with a revision label";
			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
			"XXXX: Updated YANG Module Revision Handling;
			Section 5.2.1, Advertising revision-label";
			}
			}
	augment "/yanglib:yang-library/yanglib:schema" {		augment "/yanglib:yang-library/yanglib:schema" {
	description		description
	"Augmentations to the ietf-yang-library module to indicate how		"Augmentations to the ietf-yang-library module to indicate how
	deprecated and obsoleted nodes are handled for each datastore		deprecated and obsoleted nodes are handled for each datastore
	schema supported by the server.";		schema supported by the server.";
	leaf deprecated-nodes-implemented {		leaf deprecated-nodes-implemented {
	type boolean;		type boolean;
	description		description
	"If set to true, this leaf indicates that all schema nodes with		"If set to true, this leaf indicates that all schema nodes with
	a status 'deprecated' child statement are implemented		a status 'deprecated' child statement are implemented
	equivalently as if they had status 'current', or otherwise		equivalently as if they had status 'current', or otherwise
	deviations MUST be used to explicitly remove 'deprecated'		deviations MUST be used to explicitly remove 'deprecated'
	nodes from the schema. If this leaf is set to false or absent,		nodes from the schema. If this leaf is absent or set to false,
	then the behavior is unspecified.";		then the behavior is unspecified.";
	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.2, Reporting how deprecated and obsolete nodes
	are handled";		are handled";
	}		}
	leaf obsolete-nodes-absent {		leaf obsolete-nodes-absent {
	type boolean;		type boolean;
	description		description
	"If set to true, this leaf indicates that the server does not		"If set to true, this leaf indicates that the server does not
	implement any status 'obsolete' nodes. If this leaf is		implement any status 'obsolete' nodes. If this leaf is
	set to false or absent, then the behaviour is unspecified.";		absent or set to false, then the behaviour is unspecified.";
	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.2, Reporting how deprecated and obsolete nodes
	are handled";		are handled";
	}		}
	}		}
	}		}
	<CODE ENDS>		<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		o Balazs Lengyel
	o Benoit Claise		o Benoit Claise
	o Ebben Aries		o Ebben Aries
			o Jan Lindblad
	o Jason Sterne		o Jason Sterne
	o Joe Clarke		o Joe Clarke
	o Juergen Schoenwaelder		o Juergen Schoenwaelder
	o Mahesh Jethanandani		o Mahesh Jethanandani
	o Michael (Wangzitao)		o Michael (Wangzitao)
	skipping to change at page 29, line 34 ¶		skipping to change at page 30, line 4 ¶
	o Michael (Wangzitao)		o Michael (Wangzitao)
	o Qin Wu		o Qin Wu
	o Reshad Rahman		o Reshad Rahman
	o Rob Wilton		o Rob Wilton
	o Bo Wu		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].
	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 thank both		with authors of the OpenConfig YANG models. We would like to thank
	Anees Shaikh and Rob Shakir for their input into this problem space.		both Anees Shaikh and Rob Shakir for their input into this problem
			space.
	We would also like to thank Martin Bjorklund, Jan Lindblad and Italo		We would also like to thank Lou Berger, Andy Bierman, Martin
	Busi for their contributions.		Bjorklund, Italo Busi, Tom Hill, Scott Mansfield, Kent Watsen for
			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].
	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
			Registry" [RFC3688]. Following the format in RFC 3688, the following
			registrations are requested.
			URI: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
			Registrant Contact: The IESG.
			XML: N/A, the requested URI is an XML namespace.
			URI: urn:ietf:params:xml:ns:yang:ietf-yang-library-revisions
			Registrant Contact: The IESG.
			XML: N/A, the requested URI is an XML namespace.
	The following YANG module is requested to be registred in the "IANA		The following YANG module is requested to be registred in the "IANA
	Module Names" registry:		Module Names" [RFC6020]. Following the format in RFC 6020, the
			following registrations are requested:
	The ietf-yang-revisions module:		The ietf-yang-revisions module:
	Name: ietf-yang-revisions		Name: ietf-yang-revisions
	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]
	skipping to change at page 31, line 4 ¶		skipping to change at page 31, line 33 ¶
	IANA registry" [IfTypesReg], and "iana-routing-types.yang"		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
	was changed.		was changed.
	In all cases, IANA MUST follow the versioning guidance specified in		In all cases, IANA MUST follow the versioning guidance specified in
	Section 3.1, and MUST include a "rev:nbc-changes" substatement to the		Section 3.1, and MUST include a "rev:non-backwards-compatible"
	latest revision statement whenever an IANA maintained module is		substatement to the latest revision statement whenever an IANA
	updated in a non-backwards-compatible way, as described in		maintained module is updated in a non-backwards-compatible way, as
	Section 3.2.		described in Section 3.2.
	Note: For published IANA maintained YANG modules that contain non-		Note: For published IANA maintained YANG modules that contain non-
	backwards-compatible changes between revisions, a new revision should		backwards-compatible changes between revisions, a new revision should
	be published with the "rev:nbc-changes" substatement retrospectively		be published with the "rev:non-backwards-compatible" substatement
	added to any revisions containing non-backwards-compatible changes.		retrospectively added to any revisions containing non-backwards-
			compatible changes.
	Non normative examples of updates to enumeration types in IANA		Non-normative examples of updates to enumeration types in IANA
	maintained modules that would be classified as non-backwards-		maintained modules that would be classified as non-backwards-
	compatible changes are: Changing the status of an enumeration typedef		compatible changes are: Changing the status of an enumeration typedef
	to obsolete, changing the status of an enum entry to obsolete,		to obsolete, changing the status of an enum entry to obsolete,
	removing an enum entry, changing the identifier of an enum entry, or		removing an enum entry, changing the identifier of an enum entry, or
	changing the described meaning of an enum entry.		changing the described meaning of an enum entry.
	Non normative examples of updates to enumeration types in IANA		Non-normative examples of updates to enumeration types in IANA
	maintained modules that would be classified as backwards-compatible		maintained modules that would be classified as backwards-compatible
	changes are: Adding a new enum entry to the end of the enumeration,		changes are: Adding a new enum entry to the end of the enumeration,
	changing the status or an enum entry to deprecated, or improving the		changing the status or an enum entry to deprecated, or improving the
	description of an enumeration that does not change its defined		description of an enumeration that does not change its defined
	meaning.		meaning.
	Non normative examples of updates to identity types in IANA		Non-normative examples of updates to identity types in IANA
	maintained modules that would be classified as non-backwards-		maintained modules that would be classified as non-backwards-
	compatible changes are: Changing the status of an identity to		compatible changes are: Changing the status of an identity to
	obsolete, removing an identity, renaming an identity, or changing the		obsolete, removing an identity, renaming an identity, or changing the
	described meaning of an identity.		described meaning of an identity.
	Non normative examples of updates to identity types in IANA		Non-normative examples of updates to identity types in IANA
	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", draft-ietf-
	netmod-rfc6991-bis-04 (work in progress), July 2020.		netmod-rfc6991-bis-06 (work in progress), April 2021.
	[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-01 (work in		Versioning", draft-ietf-netmod-yang-semver-02 (work in
	progress), July 2020.		progress), February 2021.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
			DOI 10.17487/RFC3688, January 2004,
			<https://www.rfc-editor.org/info/rfc3688>.
			[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
			the Network Configuration Protocol (NETCONF)", RFC 6020,
			DOI 10.17487/RFC6020, October 2010,
			<https://www.rfc-editor.org/info/rfc6020>.
	[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module		[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,		Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<https://www.rfc-editor.org/info/rfc7895>.		<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,
	skipping to change at page 33, line 7 ¶		skipping to change at page 33, line 46 ¶
	<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", draft-clacla-netmod-yang-
	model-update-06 (work in progress), July 2018.		model-update-06 (work in progress), July 2018.
	[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-12		Format", draft-ietf-netmod-yang-instance-file-format-13
	(work in progress), April 2020.		(work in progress), March 2021.
	[I-D.ietf-netmod-yang-packages]		[I-D.ietf-netmod-yang-packages]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
	"YANG Packages", draft-ietf-netmod-yang-packages-01 (work		"YANG Packages", draft-ietf-netmod-yang-packages-01 (work
	in progress), November 2020.		in progress), November 2020.
	[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", draft-
	ietf-netmod-yang-solutions-01 (work in progress), November		ietf-netmod-yang-solutions-01 (work in progress), November
	2020.		2020.
	[I-D.ietf-netmod-yang-ver-selection]		[I-D.ietf-netmod-yang-ver-selection]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
	"YANG Schema Selection", draft-ietf-netmod-yang-ver-		"YANG Schema Selection", draft-ietf-netmod-yang-ver-
	selection-00 (work in progress), March 2020.		selection-00 (work in progress), March 2020.
	[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", draft-
	ietf-netmod-yang-versioning-reqs-04 (work in progress),		ietf-netmod-yang-versioning-reqs-04 (work in progress),
	January 2021.		January 2021.
	[IfTypesReg]		[IfTypesReg]
	"Interface Types (ifType) IANA Registry",		"Interface Types (ifType) IANA Registry",
	skipping to change at page 34, line 40 ¶		skipping to change at page 35, line 30 ¶
	o Making the statement conditional on if-feature.		o 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 guidance for how some of these NBC
	changes could be made to a YANG module. The examples are all for		changes could be made to a YANG module. The examples are all for
	"config true" nodes.		"config true" nodes.
	B.1. Removing a data node		B.1. Removing a data node
	Removing a leaf or container from the data tree, e.g. because support		Removing a leaf or container from the data tree, e.g., because
	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 node's status is changed to "deprecated" and it is supported
	for at least one year. This is a BC change.		for at least one year. This is a BC change.
	2. When the node is not available anymore, its status is changed to		2. When the node is not available anymore, its status is changed to
	"obsolete" and the "description" updated, this is an NBC change.		"obsolete" and the "description" updated, this is 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 node's status changed		1. The new revision of the YANG module has the node's status changed
	to "obsolete" and the "description" updated, this is an NBC		to "obsolete" and the "description" updated, this is an NBC
	change.		change.
	2. Clients which require the data node select the YANG package		2. Clients which require the data node select the YANG package
	containing the schema version they use		containing the schema version they use.
	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., consider a "vpn-id" node of
	type integer being changed to a string:		type integer being changed to a string:
	1. The status of node "vpn-id" is changed to "deprecated" and the		1. The status of node "vpn-id" is changed to "deprecated" and the
	node should be available for at least one year. This is a BC		node should be available for at least one year. This is a BC
	change.		change.
	2. A new node, e.g. "vpn-name", of type string is added to the same		2. A new node, e.g., "vpn-name", of type string is added to the same
	location as the existing node "vpn-id". This new node has status		location as the existing node "vpn-id". This new node has status
	"current" and its description explains that it is replacing node		"current" and its description explains that it is replacing node
	"vpn-id".		"vpn-id".
	3. During the period of time where both nodes are available, how the		3. During the period of time when both nodes are available, how the
	server behaves when either node is set is outside the scope of		server behaves when either node is set 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). The new node may have
	a when statement to achieve this. The old node must not have		a when statement to achieve this. The old node must not have
	a when statement since this would be an NBC change, but the		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.
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 45 ¶
	"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, this is outside the scope
	of this document.		of this document.
	4. When node "vpn-id" is not available anymore, its status is		4. When node "vpn-id" 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. In the new revision of the YANG module, the status of node "vpn-		1. In the new revision of the YANG module, the status of node "vpn-
	id" is changed to "obsolete". This is an NBC change.		id" is changed to "obsolete". This is an NBC change.
	2. New node "vpn-name" is added to the same location as described		2. New node "vpn-name" is added to the same location as described
	above.		above.
	3. Clients which require the data node select the YANG package		3. Clients which require the data node select the YANG package
	containing the schema version they use		containing the schema version they use
	4. A server should not map between the nodes "vpn-id" and "vpn-		4. A server should not map between the nodes "vpn-id" and "vpn-
	name", i.e. if a client creates a data instance with "vpn-name"		name", i.e. if a client creates a data instance with "vpn-name"
	then that data instance should not be visible to a client using a		then that data instance should not be visible to a client using a
	module revision which has "vpn-id" (and vice-versa).		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-id"		Reducing the range of values of a leaf-node, e.g., consider a "vpn-
	node of type integer being changed from type uint32 to type uint16:		id" node of type integer being changed from type uint32 to type
			uint16:
	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 65536 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 NBC		e.g., if a vpn-id of 65536 was accepted previously, this is an
	change for the YANG model. Clients using the old YANG model will		NBC change for the YANG model. Clients using the old YANG model
	be impacted, so a change of this nature should be done carefully,		will be impacted, so a change of this nature should be done
	e.g. by using the steps described in Appendix B.2		carefully, 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 should be available for at least one year. This is a BC
	change.		change.
	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 data but
	with "dest-address" as key. Finding an appropriate name for the		with "dest-address" as key. Finding an appropriate name for the
	new list can be tricky especially if the name of the existing		new list can be tricky especially if the name of the existing
	list was perfect. In this case the new list is called "sessions-		list was perfect. In this case the new list is called "sessions-
	address", has status "current" and its description should explain		address", has status "current" and its description should explain
	that it is replacing list "session".		that it is replacing list "session".
	3. During the period of time where both lists are available, how the		3. During the period of time when both lists are available, how the
	server behaves when either list is set is outside the scope of		server behaves when either list is set 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 could prevent the new list from being set if the old		1. A server could prevent the new list from being set if the old
	list already has entries (and vice-versa).		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 is set and a client does a get or get-config
	operation on the old list, the server could map the entries.		operation on the old list, the server could map the entries.
	However if the new list has entries which would lead to		However, if the new list has entries which would lead to
	duplicate keys in the old list, the mapping can not be done.		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:
	skipping to change at page 38, line 5 ¶		skipping to change at page 38, line 43 ¶
	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 the node should be available for at least one
	year. This is a BC change.		year. This is a BC change.
	2. The new node "ip-address" is added to the same location as the		2. The new node "ip-address" is added to the same location as the
	existing node "ip-adress". This new node has status "current"		existing node "ip-adress". This new node has status "current"
	and its description should explain that it is replacing node "ip-		and its description should explain that it is replacing node "ip-
	adress".		adress".
	3. During the period of time where both nodes are available, how the		3. During the period of time when both nodes are available, how the
	server behaves when either node is set is outside the scope of		server behaves when either node is set 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 could prevent the new node from being set if the old		1. A server could 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). The new node could
	have a when statement to achieve this. The old node must not		have a when statement to achieve this. The old node must not
	have a when statement since this would be an NBC change, but		have a when statement since this would be an NBC change, but
	the server could reject the old node from being set if the		the server could reject the old node from being set if the
	new node is already set.		new node is already set.
	skipping to change at page 39, line 37 ¶		skipping to change at line 1834 ¶
	Joe Clarke		Joe Clarke
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: jclarke@cisco.com		Email: jclarke@cisco.com
	Jason Sterne		Jason Sterne
	Nokia		Nokia
	Email: jason.sterne@nokia.com		Email: jason.sterne@nokia.com
	Benoit Claise
	Huawei
	Email: benoit.claise@huawei.com
	Kevin D'Souza
	AT&T
	Email: kd6913@att.com
End of changes. 157 change blocks.
	467 lines changed or deleted		506 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/