< draft-ietf-netmod-yang-packages-01.txt		draft-ietf-netmod-yang-packages-02.txt >
	Network Working Group R. Wilton, Ed.		Network Working Group R. Wilton, Ed.
	Internet-Draft R. Rahman		Internet-Draft R. Rahman
	Intended status: Standards Track J. Clarke		Intended status: Standards Track J. Clarke
	Expires: May 6, 2021 Cisco Systems, Inc.		Expires: 28 April 2022 Cisco Systems, Inc.
	J. Sterne		J. Sterne
	Nokia		Nokia
	B. Wu, Ed.		B. Wu, Ed.
	Huawei		Huawei
	November 2, 2020		25 October 2021
	YANG Packages		YANG Packages
	draft-ietf-netmod-yang-packages-01		draft-ietf-netmod-yang-packages-02
	Abstract		Abstract
	This document defines YANG packages, a versioned organizational		This document defines YANG packages, a versioned organizational
	structure holding a set of related YANG modules that collectively		structure holding a set of related YANG modules that collectively
	define a YANG schema. It describes how packages: are represented on		define a YANG schema. It describes how packages: are represented on
	a server, can be defined in offline YANG instance data files, and can		a server, can be defined in offline YANG instance data files, and can
	be used to define the schema associated with YANG instance data		be used to define the schema associated with YANG instance data
	files.		files.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 May 6, 2021.		This Internet-Draft will expire on 28 April 2022.
	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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		Please review these documents carefully, as they describe your rights
	to this document. Code Components extracted from this document must		and restrictions with respect to this document. Code Components
	include Simplified BSD License text as described in Section 4.e of		extracted from this document must include Simplified BSD License text
	the Trust Legal Provisions and are provided without warranty as		as described in Section 4.e of the Trust Legal Provisions and are
	described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3		1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Background on YANG packages . . . . . . . . . . . . . . . . . 4		3. Background on YANG packages . . . . . . . . . . . . . . . . . 4
	4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. YANG Package Definition . . . . . . . . . . . . . . . . . . . 6		5. YANG Package Definition . . . . . . . . . . . . . . . . . . . 6
	5.1. Package definition rules . . . . . . . . . . . . . . . . 7		5.1. Package definition rules . . . . . . . . . . . . . . . . 7
	5.2. Package versioning . . . . . . . . . . . . . . . . . . . 8		5.2. Package versioning . . . . . . . . . . . . . . . . . . . 8
	5.2.1. Updating a package with a new version . . . . . . . . 8		5.2.1. Updating a package with a new version . . . . . . . . 8
	5.2.1.1. Non-Backwards-compatible changes . . . . . . . . 8		5.2.1.1. Non-Backwards-compatible changes . . . . . . . . 8
	5.2.1.2. Backwards-compatible changes . . . . . . . . . . 9		5.2.1.2. Backwards-compatible changes . . . . . . . . . . 9
	5.2.1.3. Editorial changes . . . . . . . . . . . . . . . . 9		5.2.1.3. Editorial changes . . . . . . . . . . . . . . . . 9
	5.2.2. YANG Semantic Versioning for packages . . . . . . . . 9		5.2.2. YANG Semantic Versioning for packages . . . . . . . . 9
	5.2.3. Revision history . . . . . . . . . . . . . . . . . . 10		5.2.3. Revision history . . . . . . . . . . . . . . . . . . 10
	5.3. Package conformance . . . . . . . . . . . . . . . . . . . 10		5.3. Package conformance . . . . . . . . . . . . . . . . . . . 10
	5.3.1. Use of YANG semantic versioning . . . . . . . . . . . 10		5.3.1. Use of YANG semantic versioning . . . . . . . . . . . 10
	5.3.2. Package checksums . . . . . . . . . . . . . . . . . . 11		5.3.2. The relationship between packages and datastores . . 11
	5.3.3. The relationship between packages and datastores . . 12		5.4. Schema referential completeness . . . . . . . . . . . . . 12
	5.4. Schema referential completeness . . . . . . . . . . . . . 13		5.5. Package name scoping and uniqueness . . . . . . . . . . . 13
	5.5. Package name scoping and uniqueness . . . . . . . . . . . 14		5.5.1. Globally scoped packages . . . . . . . . . . . . . . 13
	5.5.1. Globally scoped packages . . . . . . . . . . . . . . 14		5.5.2. Server scoped packages . . . . . . . . . . . . . . . 13
	5.5.2. Server scoped packages . . . . . . . . . . . . . . . 14
	5.6. Submodules packages considerations . . . . . . . . . . . 14		5.6. Submodules packages considerations . . . . . . . . . . . 14
	5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14		5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14
	5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 15		5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 14
	5.8.1. Use of deviations in YANG packages . . . . . . . . . 15		5.8.1. Use of deviations in YANG packages . . . . . . . . . 14
	5.8.2. Use of features in YANG modules and YANG packages . . 16		5.8.2. Use of features in YANG modules and YANG packages . . 15
	5.9. YANG package core definition . . . . . . . . . . . . . . 16		5.9. YANG package core definition . . . . . . . . . . . . . . 15
	6. Package Instance Data Files . . . . . . . . . . . . . . . . . 17		6. Package Instance Data Files . . . . . . . . . . . . . . . . . 16
	7. Package Definitions on a Server . . . . . . . . . . . . . . . 18		7. Package Definitions on a Server . . . . . . . . . . . . . . . 17
	7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18		7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 19		7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 18
	8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 19		8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 18
	9. YANG packages as schema for YANG instance data document . . . 20		9. YANG packages as schema for YANG instance data document . . . 19
	10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20		10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 41		11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 44		13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 41
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	15.1. Normative References . . . . . . . . . . . . . . . . . . 44		15.1. Normative References . . . . . . . . . . . . . . . . . . 41
	15.2. Informative References . . . . . . . . . . . . . . . . . 46		15.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
	A.1. Example IETF Network Device YANG package . . . . . . . . 47		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44
	A.2. Example IETF Basic Routing YANG package . . . . . . . . . 49		A.1. Example IETF Network Device YANG package . . . . . . . . 45
	A.3. Package import conflict resolution example . . . . . . . 52		A.2. Example IETF Basic Routing YANG package . . . . . . . . . 47
	Appendix B. Possible alternative solutions . . . . . . . . . . . 55		A.3. Package import conflict resolution example . . . . . . . 50
	B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 55		Appendix B. Possible alternative solutions . . . . . . . . . . . 52
	B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 56		B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56		B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 53
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
	1. Terminology and Conventions		1. 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.
	This document uses terminology introduced in the YANG versioning		This document uses terminology introduced in the YANG versioning
	requirements draft [I-D.ietf-netmod-yang-versioning-reqs].		requirements draft [I-D.ietf-netmod-yang-versioning-reqs].
	This document also makes of the following terminology introduced in		This document also makes of the following terminology introduced in
	the Network Management Datastore Architecture [RFC8342]:		the Network Management Datastore Architecture [RFC8342]:
	o datastore schema		* datastore schema
	This document also makes of the following terminology introduced in		This document also makes of the following terminology introduced in
	the YANG 1.1 Data Modeling Language [RFC7950]:		the YANG 1.1 Data Modeling Language [RFC7950]:
	o data node		* data node
	In addition, this document defines the following terminology:		In addition, this document defines the following terminology:
	o YANG schema: A datastore schema, not bound to any particular		* YANG schema: A datastore schema, not bound to any particular
	datastore.		datastore.
	o YANG package: An organizational structure containing a collection		* YANG package: An organizational structure containing a collection
	of YANG modules, normally defined in a YANG instance data file. A		of YANG modules, normally defined in a YANG instance data file. A
	YANG package defines a YANG schema by specifying a set of YANG		YANG package defines a YANG schema by specifying a set of YANG
	modules and their revisions, other packages and their revisions,		modules and their revisions, other packages and their revisions,
	mandatory features, and deviations. YANG packages are defined in		mandatory features, and deviations. YANG packages are defined in
	Section 5.		Section 5.
	o backwards-compatible (BC) change: When used in the context of a		* backwards-compatible (BC) change: When used in the context of a
	YANG module, it follows the definition in Section 3.1.1 of		YANG module, it follows the definition in Section 3.1.1 of
	[I-D.ietf-netmod-yang-module-versioning]. When used in the		[I-D.ietf-netmod-yang-module-versioning]. When used in the
	context of a YANG package, it follows the definition in		context of a YANG package, it follows the definition in
	Section 5.2.1.2.		Section 5.2.1.2.
	o non-backwards-compatible (NBC) change: When used in the context of		* non-backwards-compatible (NBC) change: When used in the context of
	a YANG module, it follows the definition in Section 3.1.2 of		a YANG module, it follows the definition in Section 3.1.2 of
	[I-D.ietf-netmod-yang-module-versioning]. When used in the		[I-D.ietf-netmod-yang-module-versioning]. When used in the
	context of a YANG package, it follows the definition in		context of a YANG package, it follows the definition in
	Section 5.2.1.2.		Section 5.2.1.2.
	o editorial change: When used in the context of a YANG module, it		* editorial change: When used in the context of a YANG module, it
	follows the definition of an 'editorial change' in 3.2 of		follows the definition of an 'editorial change' in 3.2 of
	[I-D.ietf-netmod-yang-module-versioning]. When used in the		[I-D.ietf-netmod-yang-module-versioning]. When used in the
	context of a YANG package, it follows the definition in		context of a YANG package, it follows the definition in
	Section 5.2.1.3.		Section 5.2.1.3.
	2. Introduction		2. Introduction
	This document defines and describes the YANG [RFC7950] constructs		This document defines and describes the YANG [RFC7950] constructs
	that are used to define and use YANG packages.		that are used to define and use YANG packages.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 4 ¶
	OpenConfig [openconfigsemver] describes an approach to versioning		OpenConfig [openconfigsemver] describes an approach to versioning
	'bundle releases' based on git tags. I.e. a set of modules, at		'bundle releases' based on git tags. I.e. a set of modules, at
	particular versions, can be marked with the same release tag to		particular versions, can be marked with the same release tag to
	indicate that they are known to interoperate together.		indicate that they are known to interoperate together.
	The NETMOD WG in general, and the YANG versioning design team in		The NETMOD WG in general, and the YANG versioning design team in
	particular, are exploring solutions [I-D.ietf-netmod-yang-solutions]		particular, are exploring solutions [I-D.ietf-netmod-yang-solutions]
	to the YANG versioning requirements,		to the YANG versioning requirements,
	[I-D.ietf-netmod-yang-versioning-reqs]. Solutions to the versioning		[I-D.ietf-netmod-yang-versioning-reqs]. Solutions to the versioning
	requirements can be split into several distinct areas.		requirements can be split into several distinct areas.
	[I-D.ietf-netmod-yang-module-versioning] is focused on YANG		[I-D.ietf-netmod-yang-module-versioning] is focused on YANG
	versioning scoped to individual modules. The overall solution must		versioning scoped to individual modules. The overall solution must
	also consider YANG versioning and conformance scoped to YANG schema.		also consider YANG versioning and conformance scoped to YANG schema.
	YANG packages provide part of the solution for versioning YANG		YANG packages provide part of the solution for versioning YANG
	schema.		schema.
	4. Objectives		4. Objectives
	The main goals of YANG package definitions include, but are not		The main goals of YANG package definitions include, but are not
	restricted to:		restricted to:
	o To provide an alternative, simplified, YANG conformance mechanism.		* To provide an alternative, simplified, YANG conformance mechanism.
	Rather than conformance being performed against a set of		Rather than conformance being performed against a set of
	individual YANG module revisions, features, and deviations,		individual YANG module revisions, features, and deviations,
	conformance can be more simply stated in terms of YANG packages,		conformance can be more simply stated in terms of YANG packages,
	with a set of modifications (e.g. additional modules, deviations,		with a set of modifications (e.g. additional modules, deviations,
	or features).		or features).
	o To allow YANG schema to be specified in a concise way rather than		* To allow YANG schema to be specified in a concise way rather than
	having each server explicitly list all modules, revisions, and		having each server explicitly list all modules, revisions, and
	features. YANG package definitions can be defined in documents		features. YANG package definitions can be defined in documents
	that are available offline, and accessible via a URL, rather than		that are available offline, and accessible via a URL, rather than
	requiring explicit lists of modules to be shared between client		requiring explicit lists of modules to be shared between client
	and server. Hence, a YANG package must contain sufficient		and server. Hence, a YANG package must contain sufficient
	information to allow a client or server to precisely construct the		information to allow a client or server to precisely construct the
	schema associated with the package.		schema associated with the package.
	o To define a mainly linear versioned history of sets of modules		* To define a mainly linear versioned history of sets of modules
	versions that are known to work together. I.e. to help mitigate		versions that are known to work together. I.e. to help mitigate
	the problem where a client must manage devices from multiple		the problem where a client must manage devices from multiple
	vendors, and vendor A implements version 1.0.0 of module foo and		vendors, and vendor A implements version 1.0.0 of module foo and
	version 2.0.0 of module bar, and vendor B implements version 2.0.0		version 2.0.0 of module bar, and vendor B implements version 2.0.0
	of module foo and version 1.0.0 of module bar. For a client,		of module foo and version 1.0.0 of module bar. For a client,
	trying to interoperate with multiple vendors, and many YANG		trying to interoperate with multiple vendors, and many YANG
	modules, finding a consistent lowest common denominator set of		modules, finding a consistent lowest common denominator set of
	YANG module versions may be difficult, if not impossible.		YANG module versions may be difficult, if not impossible.
	Protocol mechanisms of how clients can negotiate which packages or		Protocol mechanisms of how clients can negotiate which packages or
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 26 ¶
	some cases the package name may be locally scoped to a server or		some cases the package name may be locally scoped to a server or
	device, as described in Section 5.5.		device, as described in Section 5.5.
	YANG packages are versioned using the same approaches described in		YANG packages are versioned using the same approaches described in
	[I-D.ietf-netmod-yang-module-versioning] and		[I-D.ietf-netmod-yang-module-versioning] and
	[I-D.ietf-netmod-yang-semver]. This is described in further detail		[I-D.ietf-netmod-yang-semver]. This is described in further detail
	in Section 5.2.		in Section 5.2.
	Each YANG package version, defines:		Each YANG package version, defines:
	o some metadata about the package, e.g., description, tags, scoping,		* some metadata about the package, e.g., description, tags, scoping,
	referential completeness, location information.		referential completeness, location information.
	o a set of YANG modules, at particular revisions, that are		* a set of YANG modules, at particular revisions, that are
	implemented by servers that implement the package. The modules		implemented by servers that implement the package. The modules
	may contain deviations.		may contain deviations.
	o a set of import-only YANG modules, at particular revisions, that		* a set of import-only YANG modules, at particular revisions, that
	are used 'import-only' by the servers that implement the package.		are used 'import-only' by the servers that implement the package.
	o a set of included YANG packages, at particular revisions, that are		* a set of included YANG packages, at particular revisions, that are
	also implemented by servers that implement the package.		also implemented by servers that implement the package.
	o a set of YANG module features that must be supported by servers		* a set of YANG module features that must be supported by servers
	that implement the package.		that implement the package.
	The structure for YANG package definitions uses existing YANG		The structure for YANG package definitions uses existing YANG
	language statements, YANG Data Structure Extensions		language statements, YANG Data Structure Extensions
	[I-D.ietf-netmod-yang-data-ext], and YANG Instance Data File Format		[I-D.ietf-netmod-yang-data-ext], and YANG Instance Data File Format
	[I-D.ietf-netmod-yang-instance-file-format].		[I-D.ietf-netmod-yang-instance-file-format].
	YANG package definitions are available offline in YANG instance data		YANG package definitions are available offline in YANG instance data
	files. Client applications can be designed to support particular		files. Client applications can be designed to support particular
	package versions that they expect to interoperate with.		package versions that they expect to interoperate with.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 35 ¶
	version of the package. If the 'previous-version' leaf is provided		version of the package. If the 'previous-version' leaf is provided
	then the package definition MUST set the 'nbc-changes' leaf if the		then the package definition MUST set the 'nbc-changes' leaf if the
	new version is non-backwards-compatible with respect to the package		new version is non-backwards-compatible with respect to the package
	version defined in the 'previous-version' leaf.		version defined in the 'previous-version' leaf.
	5.2.1.1. Non-Backwards-compatible changes		5.2.1.1. Non-Backwards-compatible changes
	The following changes classify as non-backwards-compatible changes to		The following changes classify as non-backwards-compatible changes to
	a package definition:		a package definition:
	o Changing an 'included-package' list entry to select a package		* Changing an 'included-package' list entry to select a package
	version that is non-backwards-compatible to the prior package		version that is non-backwards-compatible to the prior package
	version, or removing a previously included package.		version, or removing a previously included package.
	o Changing a 'module' or 'import-only-module' list entry to select a		* Changing a 'module' or 'import-only-module' list entry to select a
	module revision that is non-backwards-compatible to the prior		module revision that is non-backwards-compatible to the prior
	module revision, or removing a previously implemented module.		module revision, or removing a previously implemented module.
	o Removing a feature from the 'mandatory-feature' leaf-list.		* Removing a feature from the 'mandatory-feature' leaf-list.
	o Adding, changing, or removing a deviation that is considered a		* Adding, changing, or removing a deviation that is considered a
	non-backwards-compatible change to the affected data node in the		non-backwards-compatible change to the affected data node in the
	schema associated with the prior package version.		schema associated with the prior package version.
	5.2.1.2. Backwards-compatible changes		5.2.1.2. Backwards-compatible changes
	The following changes classify as backwards-compatible changes to a		The following changes classify as backwards-compatible changes to a
	package definition:		package definition:
	o Changing an 'included-package' list entry to select a package		* Changing an 'included-package' list entry to select a package
	version that is backwards-compatible to the prior package version,		version that is backwards-compatible to the prior package version,
	or including a new package that does not conflict with any		or including a new package that does not conflict with any
	existing included package or module.		existing included package or module.
	o Changing a 'module' or 'import-only-module' list entry to select a		* Changing a 'module' or 'import-only-module' list entry to select a
	module revision that is backwards-compatible to the prior module		module revision that is backwards-compatible to the prior module
	revision, or including a new module to the package definition.		revision, or including a new module to the package definition.
	o Adding a feature to the 'mandatory-feature' leaf-list.		* Adding a feature to the 'mandatory-feature' leaf-list.
	o Adding, changing, or removing a deviation that is considered a		* Adding, changing, or removing a deviation that is considered a
	backwards-compatible change to the affected data node in the		backwards-compatible change to the affected data node in the
	schema associated with the prior package version.		schema associated with the prior package version.
	5.2.1.3. Editorial changes		5.2.1.3. Editorial changes
	The following changes classify as editorial changes to a package		The following changes classify as editorial changes to a package
	definition:		definition:
	o Changing a 'included-package' list entry to select a package		* Changing a 'included-package' list entry to select a package
	version that is classified as an editorial change relative to the		version that is classified as an editorial change relative to the
	prior package version.		prior package version.
	o Changing a 'module' or 'import-only-module' list entry to select a		* Changing a 'module' or 'import-only-module' list entry to select a
	module revision that is classified as an editorial change relative		module revision that is classified as an editorial change relative
	to the prior module revision.		to the prior module revision.
	o Any change to any metadata associated with a package definition		* Any change to any metadata associated with a package definition.
	that causes it to have a different checksum value.
	5.2.2. YANG Semantic Versioning for packages		5.2.2. YANG Semantic Versioning for packages
	YANG Semantic Versioning [I-D.ietf-netmod-yang-semver] MAY be used as		YANG Semantic Versioning [I-D.ietf-netmod-yang-semver] MAY be used as
	an appropriate type of revision-label for the package version leaf.		an appropriate type of revision-label for the package version leaf.
	If the format of the leaf matches the 'yangver:version' type		If the format of the leaf matches the 'yangver:version' type
	specified in ietf-yang-semver.yang, then the package version leaf		specified in ietf-yang-semver.yang, then the package version leaf
	MUST be interpreted as a YANG semantic version number.		MUST be interpreted as a YANG semantic version number.
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 25 ¶
	version 1.3.5, because the YANG semantic versioning rules require		version 1.3.5, because the YANG semantic versioning rules require
	that package version 1.3.5 is backwards compatible to version 1.0.0.		that package version 1.3.5 is backwards compatible to version 1.0.0.
	This also has a relevance on servers that are capable of supporting		This also has a relevance on servers that are capable of supporting
	version selection because they need not support every version of a		version selection because they need not support every version of a
	YANG package to ensure good client compatibility. Choosing suitable		YANG package to ensure good client compatibility. Choosing suitable
	minor versions within each major version number should generally be		minor versions within each major version number should generally be
	sufficient, particular if they can avoid non-backwards-compatible		sufficient, particular if they can avoid non-backwards-compatible
	patch level changes.		patch level changes.
	5.3.2. Package checksums		5.3.2. The relationship between packages and datastores
	Each YANG package definition may have a checksum associated with it
	to allow a client to validate that the package definition of the
	server matches the expected package definition without downloading
	the full package definition from the server.
	The checksum for a package is calculated using the SHA-256 hash (XXX,
	reference) of the full file contents of the YANG package instance
	data file. This means that the checksum includes all whitespace and
	formatting, encoding, and all meta-data fields associated with the
	package and the instance data file).
	The checksum for a module is calculated using the SHA-256 hash of the
	YANG module file definition. This means that the checksum includes
	all whitespace, formatting, and comments within the YANG module.
	Packages that are locally scoped to a server may not have an offline
	instance data file available, and hence MAY not have a checksum.
	The package definition allows URLs and checksums to be specified for
	all included packages, modules and submodules within the package
	definition. Checksums SHOULD be included in package definitions to
	validate the full integrity of the package.
	On a server, package checksums SHOULD also be provided for the top
	level packages associated with the datastore schema.
	5.3.3. The relationship between packages and datastores
	As defined by NMDA [RFC8342], each datastore has an associated		As defined by NMDA [RFC8342], each datastore has an associated
	datastore schema. Sections 5.1 and 5.3 of NMDA defines further		datastore schema. Sections 5.1 and 5.3 of NMDA defines further
	constraints on the schema associated with datastores. These		constraints on the schema associated with datastores. These
	constraints can be summarized thus:		constraints can be summarized thus:
	o The schema for all conventional datastores is the same.		* The schema for all conventional datastores is the same.
	o The schema for non conventional configuration datastores (e.g.,		* The schema for non conventional configuration datastores (e.g.,
	dynamic datastores) may completely differ (i.e. no overlap at all)		dynamic datastores) may completely differ (i.e. no overlap at all)
	from the schema associated with the conventional configuration		from the schema associated with the conventional configuration
	datastores, or may partially or fully overlap with the schema of		datastores, or may partially or fully overlap with the schema of
	the conventional configuration datastores. A dynamic datastore,		the conventional configuration datastores. A dynamic datastore,
	for example, may support different modules than conventional		for example, may support different modules than conventional
	datastores, or may support a subset or superset of modules,		datastores, or may support a subset or superset of modules,
	features, or data nodes supported in the conventional		features, or data nodes supported in the conventional
	configuration datastores. Where a data node exists in multiple		configuration datastores. Where a data node exists in multiple
	datastore schema it has the same type, properties and semantics.		datastore schema it has the same type, properties and semantics.
	o The schema for the operational datastore is intended to be a		* The schema for the operational datastore is intended to be a
	superset of all the configuration datastores (i.e. includes all		superset of all the configuration datastores (i.e. includes all
	the schema nodes from the conventional configuration datastores),		the schema nodes from the conventional configuration datastores),
	but data nodes can be omitted if they cannot be accurately		but data nodes can be omitted if they cannot be accurately
	reported. The operational datastore schema can include additional		reported. The operational datastore schema can include additional
	modules containing only config false data nodes, but there is no		modules containing only config false data nodes, but there is no
	harm in including those modules in the configuration datastore		harm in including those modules in the configuration datastore
	schema as well.		schema as well.
	Given that YANG packages represent a YANG schema, it follows that		Given that YANG packages represent a YANG schema, it follows that
	each datastore schema can be represented using packages. In		each datastore schema can be represented using packages. In
	addition, the schema for most datastores on a server are often		addition, the schema for most datastores on a server are often
	closely related. Given that there are many ways that a datastore		closely related. Given that there are many ways that a datastore
	schema could be represented using packages, the following guidance		schema could be represented using packages, the following guidance
	provides a consistent approach to help clients understand the		provides a consistent approach to help clients understand the
	relationship between the different datastore schema supported by a		relationship between the different datastore schema supported by a
	device (e.g., which parts of the schema are common and which parts		device (e.g., which parts of the schema are common and which parts
	have differences):		have differences):
	o Any datastores (e.g., conventional configuration datastores) that		* Any datastores (e.g., conventional configuration datastores) that
	have exactly the same datastore schema MUST use the same package		have exactly the same datastore schema MUST use the same package
	definitions. This is to avoid, for example, the creation of a		definitions. This is to avoid, for example, the creation of a
	'running-cfg' package and a separate 'intended-cfg' package that		'running-cfg' package and a separate 'intended-cfg' package that
	have identical schema.		have identical schema.
	o Common package definitions SHOULD be used for those parts of the		* Common package definitions SHOULD be used for those parts of the
	datastore schema that are common between datastores, when those		datastore schema that are common between datastores, when those
	datastores do not share exactly the same datastore schema. E.g.,		datastores do not share exactly the same datastore schema. E.g.,
	if a substantial part of the schema is common between the		if a substantial part of the schema is common between the
	conventional, dynamic, and operational datastores then a single		conventional, dynamic, and operational datastores then a single
	common package can be used to describe the common parts, along		common package can be used to describe the common parts, along
	with other packages to describe the unique parts of each datastore		with other packages to describe the unique parts of each datastore
	schema.		schema.
	o YANG modules that do not contain any configuration data nodes		* YANG modules that do not contain any configuration data nodes
	SHOULD be included in the package for configuration datastores if		SHOULD be included in the package for configuration datastores if
	that helps unify the package definitions.		that helps unify the package definitions.
	o The packages for the operational datastore schema MUST include all		* The packages for the operational datastore schema MUST include all
	packages for all configuration datastores, along with any required		packages for all configuration datastores, along with any required
	modules defining deviations to mark unsupported data nodes. The		modules defining deviations to mark unsupported data nodes. The
	deviations MAY be defined directly in the packages defining the		deviations MAY be defined directly in the packages defining the
	operational datastore schema, or in separate non referentially		operational datastore schema, or in separate non referentially
	complete packages.		complete packages.
	o The schema for a datastore MAY be represented using a single		* The schema for a datastore MAY be represented using a single
	package or as the union of a set of compatible packages, i.e.,		package or as the union of a set of compatible packages, i.e.,
	equivalently to a set of non-conflicting packages being included		equivalently to a set of non-conflicting packages being included
	together in an overarching package definition.		together in an overarching package definition.
	5.4. Schema referential completeness		5.4. Schema referential completeness
	A YANG package may represent a schema that is 'referentially		A YANG package may represent a schema that is 'referentially
	complete', or 'referentially incomplete', indicated in the package		complete', or 'referentially incomplete', indicated in the package
	definition by the 'complete' flag.		definition by the 'complete' flag.
	skipping to change at page 17, line 6 ¶		skipping to change at page 16, line 21 ¶
	+-- previous-version? pkg-version		+-- previous-version? pkg-version
	+-- nbc-changes? boolean		+-- nbc-changes? boolean
	+-- tag* tags:tag		+-- tag* tags:tag
	+-- mandatory-feature* scoped-feature		+-- mandatory-feature* scoped-feature
	+-- included-package* [name version]		+-- included-package* [name version]
	| +-- name pkg-name		| +-- name pkg-name
	| +-- version pkg-version		| +-- version pkg-version
	| +-- replaces-version* pkg-version		| +-- replaces-version* pkg-version
	| +-- nbc-modified? boolean		| +-- nbc-modified? boolean
	| +-- location* inet:uri		| +-- location* inet:uri
	| +-- checksum? pkg-types:sha-256-hash
	+-- module* [name]		+-- module* [name]
	| +-- name yang:yang-identifier		| +-- name yang:yang-identifier
	| +-- revision? rev:revision-date-or-label		| +-- revision? rev:revision-date-or-label
	| +-- replaces-revision* rev:revision-date-or-label		| +-- replaces-revision* rev:revision-date-or-label
	| +-- namespace? inet:uri		| +-- namespace? inet:uri
	| +-- location* inet:uri		| +-- location* inet:uri
	| +-- checksum? pkg-types:sha-256-hash
	| +-- submodule* [name]		| +-- submodule* [name]
	| +-- name? yang:yang-identifier		| +-- name? yang:yang-identifier
	| +-- revision yang:revision-identifier		| +-- revision yang:revision-identifier
	| +-- location* inet:uri		| +-- location* inet:uri
	| +-- checksum? pkg-types:sha-256-hash
	+-- import-only-module* [name revision]		+-- import-only-module* [name revision]
	+-- name? yang:yang-identifier		+-- name? yang:yang-identifier
	+-- revision? rev:revision-date-or-label		+-- revision? rev:revision-date-or-label
	+-- replaces-revision* rev:revision-date-or-label		+-- replaces-revision* rev:revision-date-or-label
	+-- namespace? inet:uri		+-- namespace? inet:uri
	+-- location* inet:uri		+-- location* inet:uri
	+-- checksum? pkg-types:sha-256-hash
	+-- submodule* [name]		+-- submodule* [name]
	+-- name? yang:yang-identifier		+-- name? yang:yang-identifier
	+-- revision yang:revision-identifier		+-- revision yang:revision-identifier
	+-- location* inet:uri		+-- location* inet:uri
	+-- checksum? pkg-types:sha-256-hash
	6. Package Instance Data Files		6. Package Instance Data Files
	YANG packages SHOULD be available offline from the server, defined as		YANG packages SHOULD be available offline from the server, defined as
	YANG instance data files [I-D.ietf-netmod-yang-instance-file-format]		YANG instance data files [I-D.ietf-netmod-yang-instance-file-format]
	using the YANG schema below to define the package data.		using the YANG schema below to define the package data.
	The following rules apply to the format of the YANG package instance		The following rules apply to the format of the YANG package instance
	files:		files:
	skipping to change at page 18, line 34 ¶		skipping to change at page 18, line 4 ¶
	module: ietf-yang-package		module: ietf-yang-package
	structure package:		structure package:
	// Uses the yang-package-instance grouping defined in		// Uses the yang-package-instance grouping defined in
	// ietf-yang-package-types.yang		// ietf-yang-package-types.yang
	+-- name pkg-name		+-- name pkg-name
	+-- version pkg-version		+-- version pkg-version
	... remainder of yang-package-instance grouping ...		... remainder of yang-package-instance grouping ...
	7. Package Definitions on a Server		7. Package Definitions on a Server
	7.1. Package List		7.1. Package List
	A top level 'packages' container holds the list of all versions of		A top level 'packages' container holds the list of all versions of
	all packages known to the server. Each list entry uses the common		all packages known to the server. Each list entry uses the common
	package definition, but with the addition of package location and		package definition, but with the addition of package location that
	checksum information that cannot be contained within a offline		cannot be contained within a offline package definition contained in
	package definition contained in an instance data file.		an instance data file.
	The '/packages/package' list MAY include multiple versions of a		The '/packages/package' list MAY include multiple versions of a
	particular package. E.g. if the server is capable of allowing		particular package. E.g. if the server is capable of allowing
	clients to select which package versions should be used by the		clients to select which package versions should be used by the
	server.		server.
	7.2. Tree diagram		7.2. Tree diagram
	The "ietf-yang-packages" YANG module has the following structure:		The "ietf-yang-packages" YANG module has the following structure:
	module: ietf-yang-packages		module: ietf-yang-packages
	+--ro packages		+--ro packages
	+--ro package* [name version]		+--ro package* [name version]
	// Uses the yang-package-instance grouping defined in		// Uses the yang-package-instance grouping defined in
	// ietf-yang-package-types.yang, with location and checksum:		// ietf-yang-package-types.yang, with location:
	+--ro name pkg-name		+--ro name pkg-name
	+--ro version pkg-version		+--ro version pkg-version
	... remainder of yang-package-instance grouping ...		... remainder of yang-package-instance grouping ...
	+--ro location* inet:uri		+--ro location* inet:uri
	+--ro checksum? pkg-types:sha-256-hash
	8. YANG Library Package Bindings		8. YANG Library Package Bindings
	The YANG packages module also augments YANG library to allow a server		The YANG packages module also augments YANG library to allow a server
	to optionally indicate that a datastore schema is defined by a		to optionally indicate that a datastore schema is defined by a
	package, or a union of compatible packages. Since packages can		package, or a union of compatible packages. Since packages can
	generally be made available offline in instance data files, it may be		generally be made available offline in instance data files, it may be
	sufficient for a client to only check that a compatible version of		sufficient for a client to only check that a compatible version of
	the package is implemented by the server without fetching either the		the package is implemented by the server without fetching either the
	package definition, or downloading and comparing the full list of		package definition, or downloading and comparing the full list of
	skipping to change at page 20, line 12 ¶		skipping to change at page 19, line 18 ¶
	definition is not supported on a server, but deviations MAY be used		definition is not supported on a server, but deviations MAY be used
	to disable functionality predicated by an if-feature statement.		to disable functionality predicated by an if-feature statement.
	The "ietf-yl-packages" YANG module has the following structure:		The "ietf-yl-packages" YANG module has the following structure:
	module: ietf-yl-packages		module: ietf-yl-packages
	augment /yanglib:yang-library/yanglib:schema:		augment /yanglib:yang-library/yanglib:schema:
	+--ro package* [name version]		+--ro package* [name version]
	+--ro name -> /pkgs:packages/package/name		+--ro name -> /pkgs:packages/package/name
	+--ro version leafref		+--ro version leafref
	+--ro checksum? leafref
	9. YANG packages as schema for YANG instance data document		9. YANG packages as schema for YANG instance data document
	YANG package definitions can be used as the schema definition for		YANG package definitions can be used as the schema definition for
	YANG instance data files. When using a package schema, the name and		YANG instance data files. When using a package schema, the name and
	version of the package MUST be specified, a package checksum and/or		version of the package MUST be specified, a package URL to the
	URL to the package definition MAY also be provided.		package definition MAY also be provided.
	The "ietf-yang-inst-data-pkg" YANG module has the following		The "ietf-yang-inst-data-pkg" YANG module has the following
	structure:		structure:
	module: ietf-yang-inst-data-pkg		module: ietf-yang-inst-data-pkg
	augment-structure /yid:instance-data-set/yid:content-schema-spec:		augment-structure /yid:instance-data-set/yid:content-schema-spec:
	+--:(pkg-schema)		+--:(pkg-schema)
	+-- pkg-schema		+-- pkg-schema
	+-- name pkg-name		+-- name pkg-name
	+-- version pkg-version		+-- version pkg-version
	+-- location* inet:uri		+-- location* inet:uri
	+-- checksum? pkg-types:sha-256-hash
	10. YANG Modules		10. YANG Modules
	The YANG module definitions for the modules described in the previous		The YANG module definitions for the modules described in the previous
	sections.		sections.
	<CODE BEGINS> file "ietf-yang-package-types@2020-01-21.yang"		<CODE BEGINS> file "ietf-yang-package-types@2021-10-25.yang"
	module ietf-yang-package-types {		module ietf-yang-package-types {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types";
	prefix "pkg-types";		prefix "pkg-types";
	import ietf-yang-revisions {		import ietf-yang-revisions {
	prefix rev;		prefix rev;
	reference "XXXX: Updated YANG Module Revision Handling";		reference "XXXX: Updated YANG Module Revision Handling";
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	rev:revision-or-derived 2019-07-21;		rev:revision-or-derived 2019-07-21;
	reference "RFC 6991bis: Common YANG Data Types.";		reference "RFC 6991bis: Common YANG Data Types.";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	skipping to change at page 21, line 49 ¶		skipping to change at page 21, line 4 ¶
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2019 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 with actual RFC number and remove this		// RFC Ed.: replace XXXX with actual RFC number and remove this
	// note.		// note.
	revision 2020-01-21 {		revision 2021-10-25 {
	rev:revision-label 0.2.0;		rev:revision-label 0.2.0;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Typedefs		* Typedefs
	*/		*/
	skipping to change at page 23, line 13 ¶		skipping to change at page 22, line 16 ¶
	}		}
	description		description
	"Represents a feature name scoped to a particular module,		"Represents a feature name scoped to a particular module,
	identified as the '<module-name>:<feature-name>', where both		identified as the '<module-name>:<feature-name>', where both
	<module-name> and <feature-name> are YANG identifier strings,		<module-name> and <feature-name> are YANG identifier strings,
	as defiend by Section 12 or RFC 6020.";		as defiend by Section 12 or RFC 6020.";
	reference		reference
	"RFC XXXX, YANG Packages.";		"RFC XXXX, YANG Packages.";
	}		}
	typedef sha-256-hash {
	type string {
	length "64";
	pattern "[0-9a-fA-F]*";
	}
	description
	"A SHA-256 hash represented as a hexadecimal string.
	Used as the checksum for modules, submodules and packages in a
	YANG package definition.
	For modules and submodules the SHA-256 hash is calculated on
	the contents of the YANG file defining the module/submodule.
	For packages the SHA-256 hash is calculated on the file
	containing the YANG instance data document holding the package
	definition";
	}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	grouping yang-pkg-identification-leafs {		grouping yang-pkg-identification-leafs {
	description		description
	"Parameters for identifying a specific version of a YANG		"Parameters for identifying a specific version of a YANG
	package";		package";
	leaf name {		leaf name {
	type pkg-name;		type pkg-name;
	skipping to change at page 27, line 38 ¶		skipping to change at page 26, line 23 ¶
	for this YANG package can be found.		for this YANG package can be found.
	This leaf will only be present if there is a URL available		This leaf will only be present if there is a URL available
	for retrieval of the schema for this entry.		for retrieval of the schema for this entry.
	If multiple locations are provided, then the first		If multiple locations are provided, then the first
	location in the leaf-list MUST be the definitive location		location in the leaf-list MUST be the definitive location
	that uniquely identifies this package";		that uniquely identifies this package";
	}		}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash calculated on the textual package
	definition, represented as a hexadecimal string.";
	}
	}		}
	list module {		list module {
	key "name";		key "name";
	description		description
	"An entry in this list represents a module that must be		"An entry in this list represents a module that must be
	implemented by a server implementing this package, as per		implemented by a server implementing this package, as per
	RFC 7950 section 5.6.5, with a particular set of supported		RFC 7950 section 5.6.5, with a particular set of supported
	features and deviations.		features and deviations.
	skipping to change at page 29, line 4 ¶		skipping to change at page 27, line 32 ¶
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"Contains a URL that represents the YANG schema resource		"Contains a URL that represents the YANG schema resource
	for this module.		for this module.
	This leaf will only be present if there is a URL available		This leaf will only be present if there is a URL available
	for retrieval of the schema for this entry.";		for retrieval of the schema for this entry.";
	}		}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash calculated on the textual module
	definition, represented as a hexadecimal string.";
	}
	list submodule {		list submodule {
	key "name";		key "name";
	description		description
	"Each entry represents one submodule within the		"Each entry represents one submodule within the
	parent module.";		parent module.";
	leaf name {		leaf name {
	type yang:yang-identifier;		type yang:yang-identifier;
	description		description
	skipping to change at page 29, line 30 ¶		skipping to change at page 28, line 4 ¶
	"The YANG submodule name.";		"The YANG submodule name.";
	}		}
	leaf revision {		leaf revision {
	type yang:revision-identifier;		type yang:revision-identifier;
	mandatory true;		mandatory true;
	description		description
	"The YANG submodule revision date. If the parent module		"The YANG submodule revision date. If the parent module
	include statement for this submodule includes a revision		include statement for this submodule includes a revision
	date then it MUST match this leaf's value.";		date then it MUST match this leaf's value.";
	}		}
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"Contains a URL that represents the YANG schema resource		"Contains a URL that represents the YANG schema resource
	for this submodule.		for this submodule.
	This leaf will only be present if there is a URL		This leaf will only be present if there is a URL
	available for retrieval of the schema for this entry.";		available for retrieval of the schema for this entry.";
	}		}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash calculated on the textual submodule
	definition, represented as a hexadecimal string.";
	}
	}		}
	}		}
	list import-only-module {		list import-only-module {
	key "name revision";		key "name revision";
	description		description
	"An entry in this list indicates that the server imports		"An entry in this list indicates that the server imports
	reusable definitions from the specified revision of the		reusable definitions from the specified revision of the
	module, but does not implement any protocol accessible		module, but does not implement any protocol accessible
	objects from this revision.		objects from this revision.
	skipping to change at page 30, line 36 ¶		skipping to change at page 29, line 4 ¶
	If no revision statement is present in the YANG module,		If no revision statement is present in the YANG module,
	this leaf is not instantiated.";		this leaf is not instantiated.";
	}		}
	leaf-list replaces-revision {		leaf-list replaces-revision {
	type rev:revision-date-or-label;		type rev:revision-date-or-label;
	description		description
	"Gives the revision of an import-only-module defined in an		"Gives the revision of an import-only-module defined in an
	included package that is replaced by this		included package that is replaced by this
	import-only-module revision.";		import-only-module revision.";
	}		}
	leaf namespace {		leaf namespace {
	type inet:uri;		type inet:uri;
	description		description
	"The XML namespace identifier for this module.";		"The XML namespace identifier for this module.";
	}		}
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"Contains a URL that represents the YANG schema resource		"Contains a URL that represents the YANG schema resource
	for this module.		for this module.
	This leaf will only be present if there is a URL available		This leaf will only be present if there is a URL available
	for retrieval of the schema for this entry.";		for retrieval of the schema for this entry.";
	}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash calculated on the textual submodule
	definition, represented as a hexadecimal string.";
	}		}
	list submodule {		list submodule {
	key "name";		key "name";
	description		description
	"Each entry represents one submodule within the		"Each entry represents one submodule within the
	parent module.";		parent module.";
	leaf name {		leaf name {
	type yang:yang-identifier;		type yang:yang-identifier;
	skipping to change at page 31, line 43 ¶		skipping to change at page 30, line 4 ¶
	}		}
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"Contains a URL that represents the YANG schema resource		"Contains a URL that represents the YANG schema resource
	for this submodule.		for this submodule.
	This leaf will only be present if there is a URL		This leaf will only be present if there is a URL
	available for retrieval of the schema for this entry.";		available for retrieval of the schema for this entry.";
	}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash calculated on the textual submodule
	definition, represented as a hexadecimal string.";
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-yang-package-instance@2020-01-21.yang"		<CODE BEGINS> file "ietf-yang-package-instance@2021-10-25.yang"
	module ietf-yang-package-instance {		module ietf-yang-package-instance {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance";
	prefix pkg-inst;		prefix pkg-inst;
	import ietf-yang-revisions {		import ietf-yang-revisions {
	prefix rev;		prefix rev;
	reference "XXXX: Updated YANG Module Revision Handling";		reference "XXXX: Updated YANG Module Revision Handling";
	}		}
	skipping to change at page 33, line 44 ¶		skipping to change at page 31, line 45 ¶
	sx:structure package {		sx:structure package {
	description		description
	"Defines the YANG package structure for use in a YANG instance		"Defines the YANG package structure for use in a YANG instance
	data document.";		data document.";
	uses pkg-types:yang-pkg-instance;		uses pkg-types:yang-pkg-instance;
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-yang-package@2020-01-21.yang"		<CODE BEGINS> file "ietf-yang-package@2021-10-25.yang"
	module ietf-yang-packages {		module ietf-yang-packages {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages";
	prefix pkgs;		prefix pkgs;
	import ietf-yang-revisions {		import ietf-yang-revisions {
	prefix rev;		prefix rev;
	reference "XXXX: Updated YANG Module Revision Handling";		reference "XXXX: Updated YANG Module Revision Handling";
	}		}
	import ietf-yang-package-types {		import ietf-yang-package-types {
	skipping to change at page 35, line 9 ¶		skipping to change at page 33, line 9 ¶
	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 with actual RFC number and remove this		// RFC Ed.: replace XXXX with actual RFC number and remove this
	// note.		// note.
	revision 2020-01-21 {		revision 2021-10-25 {
	rev:revision-label 0.2.0;		rev:revision-label 0.2.0;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	skipping to change at page 35, line 44 ¶		skipping to change at page 33, line 44 ¶
	type leafref {		type leafref {
	path '/pkgs:packages'		path '/pkgs:packages'
	+ '/pkgs:package[pkgs:name = current()/../name]'		+ '/pkgs:package[pkgs:name = current()/../name]'
	+ '/pkgs:version';		+ '/pkgs:version';
	}		}
	description		description
	"The version of the referenced package.";		"The version of the referenced package.";
	}		}
	leaf checksum {
	type leafref {
	path '/pkgs:packages'
	+ '/pkgs:package[pkgs:name = current()/../name]'
	+ '[pkgs:version = current()/../version]/pkgs:checksum';
	}
	description
	"The checksum of the referenced package.";
	}
	}		}
	grouping yang-ds-pkg-ref {		grouping yang-ds-pkg-ref {
	description		description
	"Defines the list used to reference a set of YANG packages that		"Defines the list used to reference a set of YANG packages that
	collectively represent a datastore schema.";		collectively represent a datastore schema.";
	list package {		list package {
	key "name version";		key "name version";
	skipping to change at page 37, line 13 ¶		skipping to change at page 34, line 50 ¶
	"Contains a URL that represents where an instance data file		"Contains a URL that represents where an instance data file
	for this YANG package can be found.		for this YANG package can be found.
	This leaf will only be present if there is a URL available		This leaf will only be present if there is a URL available
	for retrieval of the schema for this entry.		for retrieval of the schema for this entry.
	If multiple locations are provided, then the first		If multiple locations are provided, then the first
	location in the leaf-list MUST be the definitive location		location in the leaf-list MUST be the definitive location
	that uniquely identifies this package";		that uniquely identifies this package";
	}		}
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The checksum of the package this schema relates to,
	calculated on the 'YANG instance data file' package
	definition available in the 'location' leaf list.
	This leaf MAY be omitted if the referenced package is
	locally scoped without an associated checksum.";
	}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-yl-package@2020-01-21.yang"		<CODE BEGINS> file "ietf-yl-package@2020-01-21.yang"
	module ietf-yl-packages {		module ietf-yl-packages {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages";		namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages";
	prefix yl-pkgs;		prefix yl-pkgs;
	skipping to change at page 39, line 4 ¶		skipping to change at page 36, line 27 ¶
	// and remove this note.		// and remove this note.
	// RFC Ed.: replace XXXX with actual RFC number and remove this		// RFC Ed.: replace XXXX with actual RFC number and remove this
	// note.		// note.
	revision 2020-01-21 {		revision 2020-01-21 {
	rev:revision-label 0.2.0;		rev:revision-label 0.2.0;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Augmentations		* Augmentations
	*/		*/
	augment "/yanglib:yang-library/yanglib:schema" {		augment "/yanglib:yang-library/yanglib:schema" {
	description		description
	"Allow datastore schema to be related to a set of YANG		"Allow datastore schema to be related to a set of YANG
	packages";		packages";
	uses pkgs:yang-ds-pkg-ref;		uses pkgs:yang-ds-pkg-ref;
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-yang-inst-data-pkg@2020-01-21.yang"		<CODE BEGINS> file "ietf-yang-inst-data-pkg@2021-10-25.yang"
	module ietf-yang-inst-data-pkg {		module ietf-yang-inst-data-pkg {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg";
	prefix yid-pkg;		prefix yid-pkg;
	import ietf-yang-revisions {		import ietf-yang-revisions {
	prefix rev;		prefix rev;
	reference "XXXX: Updated YANG Module Revision Handling";		reference "XXXX: Updated YANG Module Revision Handling";
	}		}
	skipping to change at page 41, line 15 ¶		skipping to change at page 38, line 38 ¶
	sx:augment-structure		sx:augment-structure
	"/yid:instance-data-set/yid:content-schema-spec" {		"/yid:instance-data-set/yid:content-schema-spec" {
	description		description
	"Add package reference to instance data set schema		"Add package reference to instance data set schema
	specification";		specification";
	case pkg-schema {		case pkg-schema {
	container pkg-schema {		container pkg-schema {
	uses pkg-types:yang-pkg-identification-leafs;		uses pkg-types:yang-pkg-identification-leafs;
	leaf checksum {
	type pkg-types:sha-256-hash;
	description
	"The SHA-256 hash of the package, calculated on
	the textual package definition, represented as a
	hexadecimal string.";
	}
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"Contains a URL that represents where an instance data		"Contains a URL that represents where an instance data
	file for this YANG package can be found.		file for this YANG package can be found.
	This leaf will only be present if there is a URL		This leaf will only be present if there is a URL
	available for retrieval of the schema for this entry.		available for retrieval of the schema for this entry.
	If multiple locations are provided, then the first		If multiple locations are provided, then the first
	skipping to change at page 42, line 21 ¶		skipping to change at page 39, line 36 ¶
	readable data nodes in these YANG modules may be considered sensitive		readable data nodes in these YANG modules may be considered sensitive
	or vulnerable in some network environments. It is thus important to		or vulnerable in some network environments. It is thus important to
	control read access (e.g., via get, get-config, or notification) to		control read access (e.g., via get, get-config, or notification) to
	these data nodes.		these data nodes.
	One additional key different to YANG library, is that the 'ietf-yang-		One additional key different to YANG library, is that the 'ietf-yang-
	package' YANG module defines a schema to allow YANG packages to be		package' YANG module defines a schema to allow YANG packages to be
	defined in YANG instance data files, that are outside the security		defined in YANG instance data files, that are outside the security
	controls of the network management protocols. Hence, it is important		controls of the network management protocols. Hence, it is important
	to also consider controlling access to these package instance data		to also consider controlling access to these package instance data
	files to restrict access to sensitive information. SHA-256 checksums		files to restrict access to sensitive information.
	are used to ensure the integrity of YANG package definitions,
	imported modules, and sub-modules.
	As per the YANG library security considerations, the module, revision		As per the YANG library security considerations, the module, revision
	and version information in YANG packages may help an attacker		and version information in YANG packages may help an attacker
	identify the server capabilities and server implementations with		identify the server capabilities and server implementations with
	known bugs since the set of YANG modules supported by a server may		known bugs since the set of YANG modules supported by a server may
	reveal the kind of device and the manufacturer of the device. Server		reveal the kind of device and the manufacturer of the device. Server
	vulnerabilities may be specific to particular modules, module		vulnerabilities may be specific to particular modules, module
	revisions, module features, or even module deviations. For example,		revisions, module features, or even module deviations. For example,
	if a particular operation on a particular data node is known to cause		if a particular operation on a particular data node is known to cause
	a server to crash or significantly degrade device performance, then		a server to crash or significantly degrade device performance, then
	skipping to change at page 44, line 23 ¶		skipping to change at page 41, line 37 ¶
	Feedback helping shape this document has kindly been provided by Andy		Feedback helping shape this document has kindly been provided by Andy
	Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav		Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav
	Lhotka,and Jan Lindblad.		Lhotka,and Jan Lindblad.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-netconf-rfc7895bis]		[I-D.ietf-netconf-rfc7895bis]
	Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,		Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
	and R. Wilton, "YANG Library", draft-ietf-netconf-		and R. Wilton, "YANG Library", Work in Progress, Internet-
	rfc7895bis-07 (work in progress), October 2018.		Draft, draft-ietf-netconf-rfc7895bis-07, 17 October 2018,
			<https://www.ietf.org/archive/id/draft-ietf-netconf-
			rfc7895bis-07.txt>.
	[I-D.ietf-netmod-module-tags]		[I-D.ietf-netmod-module-tags]
	Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module		Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
	Tags", draft-ietf-netmod-module-tags-10 (work in		Tags", Work in Progress, Internet-Draft, draft-ietf-
	progress), February 2020.		netmod-module-tags-10, 29 February 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-module-
			tags-10.txt>.
	[I-D.ietf-netmod-yang-data-ext]		[I-D.ietf-netmod-yang-data-ext]
	Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data		Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
	Structure Extensions", draft-ietf-netmod-yang-data-ext-05		Structure Extensions", Work in Progress, Internet-Draft,
	(work in progress), December 2019.		draft-ietf-netmod-yang-data-ext-05, 9 December 2019,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			data-ext-05.txt>.
	[I-D.ietf-netmod-yang-instance-file-format]		[I-D.ietf-netmod-yang-instance-file-format]
	Lengyel, B. and B. Claise, "YANG Instance Data File		Lengyel, B. and B. Claise, "YANG Instance Data File
	Format", draft-ietf-netmod-yang-instance-file-format-12		Format", Work in Progress, Internet-Draft, draft-ietf-
	(work in progress), April 2020.		netmod-yang-instance-file-format-21, 8 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			instance-file-format-21.txt>.
	[I-D.ietf-netmod-yang-module-versioning]		[I-D.ietf-netmod-yang-module-versioning]
	Wilton, R., Rahman, R., Lengyel, B., Clarke, J., Sterne,		Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
	J., Claise, B., and K. D'Souza, "Updated YANG Module		Sterne, "Updated YANG Module Revision Handling", Work in
	Revision Handling", draft-ietf-netmod-yang-module-		Progress, Internet-Draft, draft-ietf-netmod-yang-module-
	versioning-01 (work in progress), July 2020.		versioning-03, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			module-versioning-03.txt>.
	[I-D.ietf-netmod-yang-semver]		[I-D.ietf-netmod-yang-semver]
	Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,		Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
	B., Sterne, J., and K. D'Souza, "YANG Semantic		B., Sterne, J., and K. D'Souza, "YANG Semantic
	Versioning", draft-ietf-netmod-yang-semver-01 (work in		Versioning", Work in Progress, Internet-Draft, draft-ietf-
	progress), July 2020.		netmod-yang-semver-03, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			semver-03.txt>.
	[I-D.ietf-netmod-yang-solutions]		[I-D.ietf-netmod-yang-solutions]
	Wilton, R., "YANG Versioning Solution Overview", draft-		Wilton, R., "YANG Versioning Solution Overview", Work in
	ietf-netmod-yang-solutions-00 (work in progress), March		Progress, Internet-Draft, draft-ietf-netmod-yang-
	2020.		solutions-01, 2 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			solutions-01.txt>.
	[I-D.ietf-netmod-yang-ver-selection]		[I-D.ietf-netmod-yang-ver-selection]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
	"YANG Schema Selection", draft-ietf-netmod-yang-ver-		"YANG Schema Selection", Work in Progress, Internet-Draft,
	selection-00 (work in progress), March 2020.		draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			ver-selection-00.txt>.
	[I-D.ietf-netmod-yang-versioning-reqs]		[I-D.ietf-netmod-yang-versioning-reqs]
	Clarke, J., "YANG Module Versioning Requirements", draft-		Clarke, J., "YANG Module Versioning Requirements", Work in
	ietf-netmod-yang-versioning-reqs-03 (work in progress),		Progress, Internet-Draft, draft-ietf-netmod-yang-
	June 2020.		versioning-reqs-05, 6 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
			versioning-reqs-05.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 46, line 30 ¶		skipping to change at page 44, line 18 ¶
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	[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>.
	15.2. Informative References		15.2. Informative References
	[I-D.bierman-netmod-yang-package]		[I-D.bierman-netmod-yang-package]
	Bierman, A., "The YANG Package Statement", draft-bierman-		Bierman, A., "The YANG Package Statement", Work in
	netmod-yang-package-00 (work in progress), July 2015.		Progress, Internet-Draft, draft-bierman-netmod-yang-
			package-00, 6 July 2015, <https://www.ietf.org/archive/id/
			draft-bierman-netmod-yang-package-00.txt>.
	[I-D.ietf-netmod-artwork-folding]		[I-D.ietf-netmod-artwork-folding]
	Watsen, K., Auerswald, E., Farrel, A., and Q. WU,		Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Inclusions in Internet-Drafts and		"Handling Long Lines in Content of Internet-Drafts and
	RFCs", draft-ietf-netmod-artwork-folding-12 (work in		RFCs", Work in Progress, Internet-Draft, draft-ietf-
	progress), January 2020.		netmod-artwork-folding-12, 20 January 2020,
			<https://www.ietf.org/archive/id/draft-ietf-netmod-
			artwork-folding-12.txt>.
	[openconfigsemver]		[openconfigsemver]
	"Semantic Versioning for OpenConfig Models",		"Semantic Versioning for OpenConfig Models",
	<http://www.openconfig.net/docs/semver/>.		<http://www.openconfig.net/docs/semver/>.
	[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module		[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
	Classification", RFC 8199, DOI 10.17487/RFC8199, July		Classification", RFC 8199, DOI 10.17487/RFC8199, July
	2017, <https://www.rfc-editor.org/info/rfc8199>.		2017, <https://www.rfc-editor.org/info/rfc8199>.
	Appendix A. Examples		Appendix A. Examples
	skipping to change at page 47, line 30 ¶		skipping to change at page 45, line 24 ¶
	basic IP configuration.		basic IP configuration.
	As for all YANG packages, all import dependencies are fully resolved.		As for all YANG packages, all import dependencies are fully resolved.
	Because this example uses YANG modules that have been standardized		Because this example uses YANG modules that have been standardized
	before YANG semantic versioning, they modules are referenced by		before YANG semantic versioning, they modules are referenced by
	revision date rather than version number.		revision date rather than version number.
	<CODE BEGINS> file "example-ietf-network-device-pkg.json"		<CODE BEGINS> file "example-ietf-network-device-pkg.json"
	========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========		========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
	{		{
	"ietf-yang-instance-data:instance-data-set": {		"ietf-yang-instance-data:instance-data-set": {
	"name": "example-ietf-network-device-pkg",		"name": "example-ietf-network-device-pkg",
	"pkg-schema": {		"pkg-schema": {
	package: "ietf-yang-package-defn-pkg@0.1.0.json"		package: "ietf-yang-package-defn-pkg@0.1.0.json"
	},		},
	"description": "YANG package definition",		"description": "YANG package definition",
	"content-data": {		"content-data": {
	"ietf-yang-package-instance:yang-package": {		"ietf-yang-package-instance:yang-package": {
	"name": "example-ietf-network-device-pkg",		"name": "example-ietf-network-device-pkg",
	"version": "1.1.2",		"version": "1.1.2",
	skipping to change at page 48, line 4 ¶		skipping to change at page 45, line 45 ¶
	"timestamp": "2018-12-13T17:00:00Z",		"timestamp": "2018-12-13T17:00:00Z",
	"organization": "IETF NETMOD Working Group",		"organization": "IETF NETMOD Working Group",
	"contact" : "WG Web: <http://tools.ietf.org/wg/netmod/>, \		"contact" : "WG Web: <http://tools.ietf.org/wg/netmod/>, \
	WG List: <mailto:netmod@ietf.org>",		WG List: <mailto:netmod@ietf.org>",
	"description": "Example IETF network device YANG package.\		"description": "Example IETF network device YANG package.\
	\		\
	This package defines a small sample set of \		This package defines a small sample set of \
	YANG modules that could represent the basic set of \		YANG modules that could represent the basic set of \
	modules that a standard network device might be expected \		modules that a standard network device might be expected \
	to support.",		to support.",
	"reference": "XXX, draft-rwilton-netmod-yang-packages",		"reference": "XXX, draft-rwilton-netmod-yang-packages",
	"location": [ "file://example.org/yang/packages/\		"location": [ "file://example.org/yang/packages/\
	ietf-network-device@v1.1.2.json" ],		ietf-network-device@v1.1.2.json" ],
	"module": [		"module": [
	{		{
	"name": "iana-crypt-hash",		"name": "iana-crypt-hash",
	"revision": "2014-08-06",		"revision": "2014-08-06",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	iana-crypt-hash%402014-08-06.yang" ],		iana-crypt-hash%402014-08-06.yang" ],
	"checksum": "fa9fde408ddec2c16bf2c6b9e4c2f80b\
	813a2f9e48c127016f3fa96da346e02d"
	},		},
	{		{
	"name": "ietf-system",		"name": "ietf-system",
	"revision": "2014-08-06",		"revision": "2014-08-06",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-system%402014-08-06.yang" ],		ietf-system%402014-08-06.yang" ],
	"checksum": "8a692ee2521b4ffe87a88303a61a1038\
	79ee26bff050c1b05a2027ae23205d3f"
	},		},
	{		{
	"name": "ietf-interfaces",		"name": "ietf-interfaces",
	"revision": "2018-02-20",		"revision": "2018-02-20",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-interfaces%402018-02-20.yang" ],		ietf-interfaces%402018-02-20.yang" ],
	"checksum": "f6faea9938f0341ed48fda93dba9a69a\
	a32ee7142c463342efec3d38f4eb3621"
	},		},
	{		{
	"name": "ietf-netconf-acm",		"name": "ietf-netconf-acm",
	"revision": "2018-02-14",		"revision": "2018-02-14",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-netconf-acm%402018-02-14.yang" ],		ietf-netconf-acm%402018-02-14.yang" ],
	"checksum": "e03f91317f9538a89296e99df3ff0c40\
	03cdfea70bf517407643b3ec13c1ed25"
	},		},
	{		{
	"name": "ietf-key-chain",		"name": "ietf-key-chain",
	"revision": "2017-06-15",		"revision": "2017-06-15",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-key-chain@2017-06-15.yang" ],		ietf-key-chain@2017-06-15.yang" ],
	"checksum": "6250705f59fc9ad786e8d74172ce90d5\
	8deec437982cbca7922af40b3ae8107c"
	},		},
	{		{
	"name": "ietf-ip",		"name": "ietf-ip",
	"revision": "2018-02-22",		"revision": "2018-02-22",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-ip%402018-02-22.yang" ],		ietf-ip%402018-02-22.yang" ],
	"checksum": "b624c84a66c128ae69ab107a5179ca8e\
	20e693fb57dbe5cb56c3db2ebb18c894"
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "ietf-yang-types",		"name": "ietf-yang-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-yang-types%402013-07-15.yang" ],		ietf-yang-types%402013-07-15.yang" ],
	"checksum": "a04cdcc875764a76e89b7a0200c6b9d8\
	00b10713978093acda7840c7c2907c3f"
	},		},
	{		{
	"name": "ietf-inet-types",		"name": "ietf-inet-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-inet-types%402013-07-15.yang" ],		ietf-inet-types%402013-07-15.yang" ],
	"checksum": "12d98b0143a5ca5095b36420f9ebc1ff\
	a61cfd2eaa850080244cadf01b86ddf9"
	}		}
	]		]
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	A.2. Example IETF Basic Routing YANG package		A.2. Example IETF Basic Routing YANG package
	This section provides an instance data file example of a basic IETF		This section provides an instance data file example of a basic IETF
	Routing YANG package formatted in JSON.		Routing YANG package formatted in JSON.
	skipping to change at page 50, line 29 ¶		skipping to change at page 47, line 52 ¶
	IETF routing YANG modules that could represent the set of \		IETF routing YANG modules that could represent the set of \
	IETF routing functionality that a basic IP network device \		IETF routing functionality that a basic IP network device \
	might be expected to support.",		might be expected to support.",
	"reference": "XXX, draft-rwilton-netmod-yang-packages",		"reference": "XXX, draft-rwilton-netmod-yang-packages",
	"imported-packages": [		"imported-packages": [
	{		{
	"name": "ietf-network-device",		"name": "ietf-network-device",
	"version": "1.1.2",		"version": "1.1.2",
	"location": [ "http://example.org/yang/packages/\		"location": [ "http://example.org/yang/packages/\
	ietf-network-device@v1.1.2.json" ],		ietf-network-device@v1.1.2.json" ],
	"checksum": ""
	}		}
	],		],
	"module": [		"module": [
	{		{
	"name": "ietf-routing",		"name": "ietf-routing",
	"revision": "2018-03-13",		"revision": "2018-03-13",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-routing@2018-03-13.yang" ],		ietf-routing@2018-03-13.yang" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-ipv4-unicast-routing",		"name": "ietf-ipv4-unicast-routing",
	"revision": "2018-03-13",		"revision": "2018-03-13",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-ipv4-unicast-routing@2018-03-13.yang" ],		ietf-ipv4-unicast-routing@2018-03-13.yang" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-ipv6-unicast-routing",		"name": "ietf-ipv6-unicast-routing",
	"revision": "2018-03-13",		"revision": "2018-03-13",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-ipv6-unicast-routing@2018-03-13.yang" ],		ietf-ipv6-unicast-routing@2018-03-13.yang" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-isis",		"name": "ietf-isis",
	"revision": "2018-12-11",		"revision": "2018-12-11",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-interfaces-common",		"name": "ietf-interfaces-common",
	"revision": "2018-07-02",		"revision": "2018-07-02",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-if-l3-vlan",		"name": "ietf-if-l3-vlan",
	"revision": "2017-10-30",		"revision": "2017-10-30",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-routing-policy",		"name": "ietf-routing-policy",
	"revision": "2018-10-19",		"revision": "2018-10-19",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-bgp",		"name": "ietf-bgp",
	"revision": "2018-05-09",		"revision": "2018-05-09",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-access-control-list",		"name": "ietf-access-control-list",
	"revision": "2018-11-06",		"revision": "2018-11-06",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "ietf-routing-types",		"name": "ietf-routing-types",
	"revision": "2017-12-04",		"revision": "2017-12-04",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	ietf-routing-types@2017-12-04.yang" ],		ietf-routing-types@2017-12-04.yang" ],
	"checksum": ""
	},		},
	{		{
	"name": "iana-routing-types",		"name": "iana-routing-types",
	"revision": "2017-12-04",		"revision": "2017-12-04",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	iana-routing-types@2017-12-04.yang" ],		iana-routing-types@2017-12-04.yang" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-bgp-types",		"name": "ietf-bgp-types",
	"revision": "2018-05-09",		"revision": "2018-05-09",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-packet-fields",		"name": "ietf-packet-fields",
	"revision": "2018-11-06",		"revision": "2018-11-06",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	},		},
	{		{
	"name": "ietf-ethertypes",		"name": "ietf-ethertypes",
	"revision": "2018-11-06",		"revision": "2018-11-06",
	"location": [ "https://tiny.cc/ietf-yang/\		"location": [ "https://tiny.cc/ietf-yang/\
	" ],		" ],
	"checksum": ""
	}		}
	]		]
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	A.3. Package import conflict resolution example		A.3. Package import conflict resolution example
	skipping to change at page 56, line 19 ¶		skipping to change at page 53, line 28 ¶
	be reused in an instance data file. The use of YANG packages offers		be reused in an instance data file. The use of YANG packages offers
	several benefits over just using YANG library:		several benefits over just using YANG library:
	1. Packages allow schema to be built in a hierarchical fashion.		1. Packages allow schema to be built in a hierarchical fashion.
	[I-D.ietf-netconf-rfc7895bis] only allows one layer of hierarchy		[I-D.ietf-netconf-rfc7895bis] only allows one layer of hierarchy
	(using module sets), and there must be no conflicts between		(using module sets), and there must be no conflicts between
	module revisions in different module-sets.		module revisions in different module-sets.
	2. Packages can be made available off the box, with a well defined		2. Packages can be made available off the box, with a well defined
	unique name, avoiding the need for clients to download, and		unique name, avoiding the need for clients to download, and
	construct/check the entire YANG schema for each device. Instead		construct/check the entire YANG schema for each device. YANG
	they can rely on the named packages with secure checksums. YANG
	library's use of a 'content-id' is unique only to the device that		library's use of a 'content-id' is unique only to the device that
	generated them.		generated them.
	3. Packages may be versioned using a semantic versioning scheme,		3. Packages may be versioned using a semantic versioning scheme,
	YANG library does not provide a schema level semantic version		YANG library does not provide a schema level semantic version
	number.		number.
	4. For a YANG library instance data file to contain the necessary		4. For a YANG library instance data file to contain the necessary
	information, it probably needs both YANG library and various		information, it probably needs both YANG library and various
	augmentations (e.g. to include each module's semantic version		augmentations (e.g. to include each module's semantic version
End of changes. 121 change blocks.
	281 lines changed or deleted		152 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/