< draft-ietf-netmod-yang-module-versioning-01.txt		draft-ietf-netmod-yang-module-versioning-02.txt >
	Network Working Group R. Wilton, Ed.		Network Working Group R. Wilton, Ed.
	Internet-Draft R. Rahman, Ed.		Internet-Draft Cisco Systems, Inc.
	Updates: 7950,8407,8525 (if approved) Cisco Systems, Inc.		Updates: 7950,8407,8525 (if approved) R. Rahman, Ed.
	Intended status: Standards Track B. Lengyel, Ed.		Intended status: Standards Track
	Expires: January 11, 2021 Ericsson		Expires: August 26, 2021 B. Lengyel, Ed.
			Ericsson
	J. Clarke		J. Clarke
	Cisco Systems, Inc.		Cisco Systems, Inc.
	J. Sterne		J. Sterne
	Nokia		Nokia
	B. Claise		B. Claise
	Cisco Systems, Inc.		Huawei
	K. D'Souza		K. D'Souza
	AT&T		AT&T
	July 10, 2020		February 22, 2021
	Updated YANG Module Revision Handling		Updated YANG Module Revision Handling
	draft-ietf-netmod-yang-module-versioning-01		draft-ietf-netmod-yang-module-versioning-02
	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
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 11, 2021.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . 5		3.1. Updating a YANG module with a new revision . . . . . . . 6
	3.1.1. Backwards-compatible changes . . . . . . . . . . . . 6		3.1.1. Backwards-compatible rules for config data . . . . . 6
	3.1.2. Non-backwards-compatible changes . . . . . . . . . . 6		3.1.2. Backwards-compatibility rules for config false and
	3.2. nbc-changes revision extension statement . . . . . . . . 7		output data . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Revision label . . . . . . . . . . . . . . . . . . . . . 7		3.1.3. Non-backwards-compatible changes . . . . . . . . . . 8
	3.3.1. Revision label scheme extension statement . . . . . . 8		3.2. nbc-changes revision extension statement . . . . . . . . 8
	3.4. Examples for updating the YANG module revision history . 8		3.3. Revision label . . . . . . . . . . . . . . . . . . . . . 8
	4. Import by derived revision . . . . . . . . . . . . . . . . . 11		3.3.1. Revision label scheme extension statement . . . . . . 10
	4.1. Module import examples . . . . . . . . . . . . . . . . . 12		3.3.2. Removing revisions from the revision history . . . . 10
	5. Updates to ietf-yang-library . . . . . . . . . . . . . . . . 14		3.4. Examples for updating the YANG module revision history . 10
	5.1. Resolving ambiguous module imports . . . . . . . . . . . 14		4. Import by derived revision . . . . . . . . . . . . . . . . . 13
	5.2. YANG library versioning augmentations . . . . . . . . . . 15		4.1. Module import examples . . . . . . . . . . . . . . . . . 15
	5.2.1. Advertising revision-label . . . . . . . . . . . . . 15		5. Updates to ietf-yang-library . . . . . . . . . . . . . . . . 16
			5.1. Resolving ambiguous module imports . . . . . . . . . . . 16
			5.2. YANG library versioning augmentations . . . . . . . . . . 17
			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 . . . . . . . . . . . . . . . . . . . . . . . 15		handled . . . . . . . . . . . . . . . . . . . . . . . 17
	6. Versioning of YANG instance data . . . . . . . . . . . . . . 16		6. Versioning of YANG instance data . . . . . . . . . . . . . . 18
	7. Guidelines for using the YANG module update rules . . . . . . 16		7. Guidelines for using the YANG module update rules . . . . . . 18
	7.1. Guidelines for YANG module authors . . . . . . . . . . . 16		7.1. Guidelines for YANG module authors . . . . . . . . . . . 18
	7.1.1. Making non-backwards-compatible changes to a YANG		7.1.1. Making non-backwards-compatible changes to a YANG
	module . . . . . . . . . . . . . . . . . . . . . . . 17		module . . . . . . . . . . . . . . . . . . . . . . . 19
	7.2. Versioning Considerations for Clients . . . . . . . . . . 18		7.2. Versioning Considerations for Clients . . . . . . . . . . 20
	8. Module Versioning Extension YANG Modules . . . . . . . . . . 18		8. Module Versioning Extension YANG Modules . . . . . . . . . . 21
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 27		10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	11.1. YANG Module Registrations . . . . . . . . . . . . . . . 27		11.1. YANG Module Registrations . . . . . . . . . . . . . . . 30
	11.2. Instructions . . . . . . . . . . . . . . . . . . . . . . 28		11.2. Guidance for versioning in IANA maintained YANG modules 30
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		12.1. Normative References . . . . . . . . . . . . . . . . . . 31
	12.1. Normative References . . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 32
	12.2. Informative References . . . . . . . . . . . . . . . . . 29		Appendix A. Examples of changes that are NBC . . . . . . . . . . 34
	Appendix A. Examples of changes that are NBC . . . . . . . . . . 29		Appendix B. Examples of applying the NBC change guidelines . . . 34
	Appendix B. Examples of applying the NBC change guidelines . . . 30		B.1. Removing a data node . . . . . . . . . . . . . . . . . . 34
	B.1. Removing a data node . . . . . . . . . . . . . . . . . . 30		B.2. Changing the type of a leaf node . . . . . . . . . . . . 35
	B.2. Changing the type of a leaf node . . . . . . . . . . . . 31		B.3. Reducing the range of a leaf node . . . . . . . . . . . . 36
	B.3. Reducing the range of a leaf node . . . . . . . . . . . . 32		B.4. Changing the key of a list . . . . . . . . . . . . . . . 36
	B.4. Changing the key of a list . . . . . . . . . . . . . . . 32		B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 37
	B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 33		B.6. Changing a default value . . . . . . . . . . . . . . . . 38
	B.6. Changing a default value . . . . . . . . . . . . . . . . 34		Appendix C. Changes between revisions . . . . . . . . . . . . . 38
	Appendix C. Changes between revisions . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	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].
	Specifically, this document recognises a need (within standards		Specifically, this document recognises a need (within standards
	skipping to change at page 4, line 52 ¶		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.2		Section 3.1.3
			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 is strictly linear, i.e., it is prohibited
	to have two independent revisions of a YANG module that are both		to have two independent revisions of a YANG module that are both
	directly derived from the same parent revision.		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 revisions, so modules MAY have multiple
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 25 ¶
	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, i.e., the semantics of
	an existing definition MAY be changed in an NBC way without requiring		an existing definition MAY be changed in an NBC way without requiring
	a new definition with a new identifier. A new module revision with		a new definition with a new identifier. A new module revision with
	NBC changes MUST include the "rev:nbc-changes" extension substatement		NBC changes MUST include the "rev:nbc-changes" extension substatement
	to signal the potential for incompatibility to existing module users		to signal the potential for incompatibility to existing module users
	and readers.		and readers.
	3.1.1. Backwards-compatible changes		3.1.1. Backwards-compatible rules for config data
	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 Obsolete definitions MAY be removed from published modules, and
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 5 ¶
	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. Non-backwards-compatible changes		3.1.2. Backwards-compatibility rules for config false and output data
	Any changes to YANG modules that are not defined by Section 3.1.1 as		Compatibility behavior of configuration and state data is different.
	being backwards-compatible are classified as "non-backwards-		While adding a mandatory configuration leaf makes earlier
	compatible" changes.		configurations invalid, an additional state leaf can easily be
			discarded. Decreasing the valuespace of a configuration leaf makes
			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
			Any changes to YANG modules that are not defined by Section 3.1.1 or
			Section 3.1.2 as being backwards-compatible are classified as "non-
			backwards-compatible" changes.
	3.2. nbc-changes revision extension statement		3.2. nbc-changes revision extension statement
	The "rev:nbc-changes" extension statement is used to indicate YANG		The "rev:nbc-changes" extension statement is used to indicate YANG
	module revisions that contain NBC changes.		module revisions that contain NBC changes.
	If a revision of a YANG module contains changes, relative to the		If a revision of a YANG module contains changes, relative to the
	preceding revision in the revision history, that do not conform to		preceding revision in the revision history, that do not conform to
	the module update rules defined in Section 3.1.1, then a "rev:nbc-		the module update rules defined in Section 3.1.1 or Section 3.1.2,
	changes" extension statement MUST be added as a substatement to the		then a "rev:nbc-changes" extension statement MUST be added as a
	"revision" statement.		substatement to the "revision" statement.
	Conversely, if a revision does not contain an "rev:nbc-changes"		Conversely, if a revision does not contain an "rev:nbc-changes"
	extension substatement then all changes, relative to the preceding		extension substatement then all changes, relative to the preceding
	revision in the revision history, MUST be backwards-compatible.		revision in the revision history, MUST be backwards-compatible.
	3.3. Revision label		3.3. Revision label
	This section updates [RFC7950] section 5.2, it explains how a		This section updates [RFC7950] section 5.2, it explains how a
	revision label can be used in the name of a file containing a YANG		revision label can be used in the name of a file containing a YANG
	module or submodule.		module or submodule.
	skipping to change at page 8, line 5 ¶		skipping to change at page 9, line 27 ¶
	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 an "rev:revision-or-derived"
	extension statement argument.		extension statement argument.
	If a revision has an associated revision label, then it may be used		A specific revision-label identifies a specific revision (variant) of
	instead of the revision date in the filename of a YANG module, where		the module. If two YANG modules contain the same module name and the
	it takes the form:		same revision-label (and hence also the same revision-date) in their
			latest revision statement, then the contents of the two modules,
			including the revision history, MUST be identical.
			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
			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-modules@2018-01-25.yang		E.g., acme-router-module@2018-01-25.yang
	E.g., acme-router-modules#2.0.3.yang		E.g., acme-router-module#2.0.3.yang
	Two file names, one with the revision date and another with the
	revision label, MAY exist for the same module (or submodule)
	revision.
	A specific revision-label identifies a specific revision (variant) of		YANG module (or submodule) files MAY be identified using either
	the module. If two YANG modules contain the same module name and the		revision-date or revision-label. Typically, only one file name
	same revision-label (and hence also the same revision-date) in their		SHOULD exist for the same module (or submodule) revision. Two file
	latest revision statement, then the contents of the two modules MUST		names, one with the revision date and another with the revision
	be identical.		label, MAY exist for the same module (or submodule) revision, e.g
			when migrating from one scheme to the other.
	3.3.1. Revision label scheme extension statement		3.3.1. Revision label scheme extension statement
	The "rev:revision-label-scheme" extension statement is used to		The "rev:revision-label-scheme" extension statement is used to
	indicate which revision-label scheme a module or submodule uses. The		indicate which revision-label scheme a module or submodule uses. The
	mandatory argument to this extension statement:		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
	skipping to change at page 8, line 45 ¶		skipping to change at page 10, line 25 ¶
	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
			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		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, "nbc-changes" extension statement,
	and "revision-label" extension statement could be used:		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
	skipping to change at page 10, line 22 ¶		skipping to change at page 12, line 22 ¶
	import ietf-yang-revisions { prefix "rev"; }		import ietf-yang-revisions { prefix "rev"; }
	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-04-01 {		revision 2019-03-01 {
	rev:revision-label 3.0.0;		rev:revision-label 3.0.0;
	rev:nbc-changes;		rev:nbc-changes;
	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:nbc-changes;
	description "Apply bugfix to pattern statement";		description "Apply bugfix to pattern statement";
	skipping to change at page 11, line 22 ¶		skipping to change at page 13, line 22 ¶
	import ietf-yang-revisions { prefix "rev"; }		import ietf-yang-revisions { prefix "rev"; }
	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-03-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:nbc-changes;
	description "Apply bugfix to pattern statement";		description "Apply bugfix to pattern statement";
	}		}
	skipping to change at page 12, line 45 ¶		skipping to change at page 14, line 45 ¶
	The "revision-or-derived" extension statement does not guarantee		The "revision-or-derived" extension statement does not guarantee
	that all module revisions that satisfy an import statement are		that all module revisions that satisfy an import statement are
	necessarily compatible, it only gives an indication that the		necessarily compatible, it only gives an indication that the
	revisions are more likely to be compatible. Hence, NBC changes to		revisions are more likely to be compatible. Hence, NBC changes to
	an imported module may also require new revisions of any importing		an imported module may also require new revisions of any importing
	modules, updated to accommodation those changes, along with		modules, updated to accommodation those changes, along with
	updated import "revision-or-derived" extension statements to		updated import "revision-or-derived" extension statements to
	depend on the updated imported module revision.		depend on the updated imported module revision.
			Adding, modifying or removing a "revision-or-derived" extension
			statement is considered to be a BC change.
			Adding, modifying or removing a "revision-date" extension
			statement is considered to be a BC change.
	4.1. Module import examples		4.1. Module import examples
	Consider the example module "example-module" from Section 3.4 that is		Consider the example module "example-module" from Section 3.4 that is
	hypothetically available in the following revision/label pairings:		hypothetically available in the following revision/label pairings:
	2019-01-01/1.0.0, 2019-02-01/2.0.0, 2019-03-01/3.0.0,		2019-01-01/1.0.0, 2019-02-01/2.0.0, 2019-03-01/3.0.0,
	2019-04-01/2.1.0, 2019-05-01/2.2.0 and 2019-06-01/3.1.0. The		2019-04-01/2.1.0, 2019-05-01/2.2.0 and 2019-06-01/3.1.0. The
	relationship between the revisions is as before:		relationship between the revisions is as before:
	Module revision date Revision label		Module revision date Revision label
	2019-01-01 <- 1.0.0		2019-01-01 <- 1.0.0
	skipping to change at page 18, line 24 ¶		skipping to change at page 20, line 29 ¶
	information, from when the node had status "deprecated", which is		information, from when the node had status "deprecated", which is
	still relevant.		still relevant.
	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
			the impact on the importing module. The importing modules could
			get broken, e.g. if an augmented node in the importing module has
			been removed from the imported module. Alternatively, the schema
			of the importing modules could undergo an NBC change due to the
			NBC change in the imported module, e.g. if a node in a grouping
			has been removed. As described in Appendix B.1, instead of
			removing a node, that node SHOULD first be deprecated and then
			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
	server. For example, the server may have increased the range of		server. For example, the server may have increased the range of
	an operational node causing the client to receive a value which is		an operational node causing the client to receive a value which is
	skipping to change at page 19, line 5 ¶		skipping to change at page 21, line 22 ¶
	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@2020-07-06.yang"		<CODE BEGINS> file "ietf-yang-revisions@2021-02-17.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
			// 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		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		Author: Benoit Claise
	<mailto:bclaise@cisco.com>		<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:rrahman@cisco.com>		<mailto:reshad@yahoo.com>
	Author: Robert Wilton		Author: Robert Wilton
	<mailto:rwilton@cisco.com>		<mailto:rwilton@cisco.com>
	Author: Kevin D'Souza		Author: Kevin D'Souza
	<mailto:kd6913@att.com>		<mailto:kd6913@att.com>
	Author: Balazs Lengyel		Author: Balazs Lengyel
	<mailto:balazs.lengyel@ericsson.com>		<mailto:balazs.lengyel@ericsson.com>
	skipping to change at page 20, line 22 ¶		skipping to change at page 22, line 41 ¶
	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 (inc above) with actual RFC number and		// RFC Ed.: replace XXXX (inc above) with actual RFC number and
	// remove this note.		// remove this note.
	revision 2020-07-06 {		revision 2021-02-17 {
	description		description
	"Initial version.";		"Initial version.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling";		"XXXX: Updated YANG Module Revision Handling";
	}		}
	typedef revision-label {		typedef revision-label {
	type string {		type string {
	length "1..255";		length "1..255";
	pattern '[^\s@]+';		pattern '[a-zA-Z0-9,\-_.+]+';
	pattern '\d{4}-\d{2}-\d{2}' {		pattern '\d{4}-\d{2}-\d{2}' {
	modifier invert-match;		modifier invert-match;
	}		}
	}		}
	description		description
	"A label associated with a YANG revision.		"A label associated with a YANG revision.
	Excludes spaces and '@'. MUST NOT match revision-date.";		Alphanumeric characters, comma, hyphen, underscore, period
			and plus are the only accepted characters. MUST NOT match
			revision-date.";
	reference		reference
	"XXXX: Updated YANG Module Revision Handling;		"XXXX: Updated YANG Module Revision Handling;
	Section 3.3, Revision label";		Section 3.3, Revision label";
	}		}
	typedef revision-date-or-label {		typedef revision-date-or-label {
	type union {		type union {
	type yang:revision-identifier;		type yang:revision-identifier;
	type revision-label;		type revision-label;
	}		}
	skipping to change at page 23, line 38 ¶		skipping to change at page 26, line 11 ¶
	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@2020-07-06.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 {
	skipping to change at page 24, line 4 ¶		skipping to change at page 26, line 25 ¶
	<CODE BEGINS> file "ietf-yang-library-revisions@2020-07-06.yang"		<CODE BEGINS> file "ietf-yang-library-revisions@2020-07-06.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 Library";
	}		}
	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		Author: Benoit Claise
	<mailto:bclaise@cisco.com>		<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:rrahman@cisco.com>		<mailto:reshad@yahoo.com>
	Author: Robert Wilton		Author: Robert Wilton
	<mailto:rwilton@cisco.com>		<mailto:rwilton@cisco.com>
	Author: Kevin D'Souza		Author: Kevin D'Souza
	<mailto:kd6913@att.com>		<mailto:kd6913@att.com>
	Author: Balazs Lengyel		Author: Balazs Lengyel
	<mailto:balazs.lengyel@ericsson.com>		<mailto:balazs.lengyel@ericsson.com>
	skipping to change at page 28, line 4 ¶		skipping to change at page 30, line 25 ¶
	XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-revisions		XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
	Prefix: rev		Prefix: rev
	Reference: [RFCXXXX]		Reference: [RFCXXXX]
	The ietf-yang-library-revisions module:		The ietf-yang-library-revisions module:
	Name: ietf-yang-library-revisions		Name: ietf-yang-library-revisions
	XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-		XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-
	revisions		revisions
	Prefix: yl-rev		Prefix: yl-rev
	Reference: [RFCXXXX]		Reference: [RFCXXXX]
	11.2. Instructions		11.2. Guidance for versioning in IANA maintained YANG modules
	We may need to give new instructions to IANA e.g. how to review		Note for IANA (to be removed by the RFC editor): Please check that
	revision-label statements to make sure they are accurate? TBD		the registries and IANA YANG modules are referenced in the
			appropriate way.
			IANA is responsible for maintaining and versioning YANG modules that
			are derived from other IANA registries. For example, "iana-if-
			type.yang" [IfTypeYang] is derived from the "Interface Types (ifType)
			IANA registry" [IfTypesReg], and "iana-routing-types.yang"
			[RoutingTypesYang] is derived from the "Address Family Numbers"
			[AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI)
			Parameters" [SAFIReg] IANA registries.
			Normally, updates to the registries cause any derived YANG modules to
			be updated in a backwards-compatible way, but there are some cases
			where the registry updates can cause non-backward-compatible updates
			to the derived YANG module. An example of such an update is the
			2020-12-31 revision of iana-routing-types.yang
			[RoutingTypesDecRevision], where the enum name for two SAFI values
			was changed.
			In all cases, IANA MUST follow the versioning guidance specified in
			Section 3.1, and MUST include a "rev:nbc-changes" substatement to the
			latest revision statement whenever an IANA maintained module is
			updated in a non-backwards-compatible way, as described in
			Section 3.2.
			Note: For published IANA maintained YANG modules that contain non-
			backwards-compatible changes between revisions, a new revision should
			be published with the "rev:nbc-changes" substatement retrospectively
			added to any revisions containing non-backwards-compatible changes.
			Non normative examples of updates to enumeration types in IANA
			maintained modules that would be classified as non-backwards-
			compatible changes are: Changing the status of an enumeration typedef
			to obsolete, changing the status of an enum entry to obsolete,
			removing an enum entry, changing the identifier of an enum entry, or
			changing the described meaning of an enum entry.
			Non normative examples of updates to enumeration types in IANA
			maintained modules that would be classified as backwards-compatible
			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
			description of an enumeration that does not change its defined
			meaning.
			Non normative examples of updates to identity types in IANA
			maintained modules that would be classified as non-backwards-
			compatible changes are: Changing the status of an identity to
			obsolete, removing an identity, renaming an identity, or changing the
			described meaning of an identity.
			Non normative examples of updates to identity types in IANA
			maintained modules that would be classified as backwards-compatible
			changes are: Adding a new identity, changing the status or an
			identity to deprecated, or improving the description of an identity
			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-04 (work in progress), July 2020.
	[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-00 (work in		Versioning", draft-ietf-netmod-yang-semver-01 (work in
	progress), March 2020.		progress), July 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	skipping to change at page 29, line 12 ¶		skipping to change at page 32, line 40 ¶
	DOI 10.17487/RFC8407, October 2018,		DOI 10.17487/RFC8407, October 2018,
	<https://www.rfc-editor.org/info/rfc8407>.		<https://www.rfc-editor.org/info/rfc8407>.
	[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,		[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
	and R. Wilton, "YANG Library", RFC 8525,		and R. Wilton, "YANG Library", RFC 8525,
	DOI 10.17487/RFC8525, March 2019,		DOI 10.17487/RFC8525, March 2019,
	<https://www.rfc-editor.org/info/rfc8525>.		<https://www.rfc-editor.org/info/rfc8525>.
	12.2. Informative References		12.2. Informative References
			[AddrFamilyReg]
			"Address Family Numbers IANA Registry",
			<https://www.iana.org/assignments/address-family-numbers/
			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-12
	(work in progress), April 2020.		(work in progress), April 2020.
	[I-D.ietf-netmod-yang-packages]		[I-D.ietf-netmod-yang-packages]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,
	"YANG Packages", draft-ietf-netmod-yang-packages-00 (work		"YANG Packages", draft-ietf-netmod-yang-packages-01 (work
	in progress), March 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-00 (work in progress), March		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 W. Bo,
	"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-03 (work in progress),		ietf-netmod-yang-versioning-reqs-04 (work in progress),
	June 2020.		January 2021.
			[IfTypesReg]
			"Interface Types (ifType) IANA Registry",
			<https://www.iana.org/assignments/smi-numbers/smi-
			numbers.xhtml#smi-numbers-5>.
			[IfTypeYang]
			"iana-if-type YANG Module",
			<https://www.iana.org/assignments/iana-if-type/iana-if-
			type.xhtml>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
			[RoutingTypesDecRevision]
			"2020-12-31 revision of iana-routing-types.yang",
			<https://www.iana.org/assignments/yang-parameters/iana-
			routing-types@2020-12-31.yang>.
			[RoutingTypesYang]
			"iana-routing-types YANG Module",
			<https://www.iana.org/assignments/iana-routing-types/iana-
			routing-types.xhtml>.
			[SAFIReg] "Subsequent Address Family Identifiers (SAFI) Parameters
			IANA Registry", <https://www.iana.org/assignments/safi-
			namespace/safi-namespace.xhtml>.
	[semver] "Semantic Versioning 2.0.0", <https://www.semver.org>.		[semver] "Semantic Versioning 2.0.0", <https://www.semver.org>.
	Appendix A. Examples of changes that are NBC		Appendix A. Examples of changes that are NBC
	Examples of NBC changes include:		Examples of NBC changes include:
	o Deleting a data node, or changing it to status obsolete.		o Deleting a data node, or changing it to status obsolete.
	o Changing the name, type, or units of a data node.		o Changing the name, type, or units of a data node.
	skipping to change at page 34, line 41 ¶		skipping to change at page 39, line 4 ¶
	Note to RFC Editor (To be removed by RFC Editor)		Note to RFC Editor (To be removed by RFC Editor)
	v00 - v01		v00 - v01
	o Removed status-description		o Removed status-description
	o Allowed both revision-date and revision-label in the filename.		o Allowed both revision-date and revision-label in the filename.
	o New extension revision-label-scheme		o New extension revision-label-scheme
	o To include submodules, inclusion by revision-date changed from		o To include submodules, inclusion by revision-date changed from
	MUST to SHOULD		MUST to SHOULD
	o Submodules can use revision label scheme and it can be same or		o Submodules can use revision label scheme and it can be same or
	different as the including module's scheme		different as the including module's scheme
	o Addressed various comments provided at WG adoption on rev-00		o Addressed various comments provided at WG adoption on rev-00
	Authors' Addresses		Authors' Addresses
	Robert Wilton (editor)		Robert Wilton (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: rwilton@cisco.com		Email: rwilton@cisco.com
	Reshad Rahman (editor)		Reshad Rahman (editor)
	Cisco Systems, Inc.
	Email: rrahman@cisco.com		Email: reshad@yahoo.com
	Balazs Lengyel (editor)		Balazs Lengyel (editor)
	Ericsson		Ericsson
	Email: balazs.lengyel@ericsson.com		Email: balazs.lengyel@ericsson.com
	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		Benoit Claise
	Cisco Systems, Inc.		Huawei
	Email: bclaise@cisco.com
			Email: benoit.claise@huawei.com
	Kevin D'Souza		Kevin D'Souza
	AT&T		AT&T
	Email: kd6913@att.com		Email: kd6913@att.com
End of changes. 48 change blocks.
	99 lines changed or deleted		288 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/