draft-ietf-netmod-yang-packages-02.txt		draft-ietf-netmod-yang-packages-03.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: 28 April 2022 Cisco Systems, Inc.		Expires: 5 September 2022 Cisco Systems, Inc.
	J. Sterne		J. Sterne
	Nokia		Nokia
	B. Wu, Ed.		B. Wu, Ed.
	Huawei		Huawei
	25 October 2021		4 March 2022
	YANG Packages		YANG Packages
	draft-ietf-netmod-yang-packages-02		draft-ietf-netmod-yang-packages-03
	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 used to manage schema and conformance of YANG modules as a
	define a YANG schema. It describes how packages: are represented on		cohesive set instead of individually.
	a server, can be defined in offline YANG instance data files, and can
	be used to define the schema associated with YANG instance data		It describes how packages: are represented on a server, can be
	files.		defined in offline YANG instance data files, and can be used to
			define the content schema associated with YANG instance data files.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 28 April 2022.		This Internet-Draft will expire on 5 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised 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 . . . . . . . . . . 8
	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.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. The relationship between packages and datastores . . 11		5.3.2. The relationship between packages and datastores . . 11
	5.4. Schema referential completeness . . . . . . . . . . . . . 12		5.4. Schema referential completeness . . . . . . . . . . . . . 12
	5.5. Package name scoping and uniqueness . . . . . . . . . . . 13		5.5. Package name scoping and uniqueness . . . . . . . . . . . 13
	5.5.1. Globally scoped packages . . . . . . . . . . . . . . 13		5.5.1. Globally scoped packages . . . . . . . . . . . . . . 13
	5.5.2. Server scoped packages . . . . . . . . . . . . . . . 13		5.5.2. Server scoped packages . . . . . . . . . . . . . . . 13
	5.6. Submodules packages considerations . . . . . . . . . . . 14		5.6. Submodules packages considerations . . . . . . . . . . . 13
	5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14		5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14
	5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 14		5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 14
	5.8.1. Use of deviations in YANG packages . . . . . . . . . 14		5.8.1. Use of deviations in YANG packages . . . . . . . . . 14
	5.8.2. Use of features in YANG modules and YANG packages . . 15		5.8.2. Use of features in YANG modules and YANG packages . . 15
	5.9. YANG package core definition . . . . . . . . . . . . . . 15		5.9. YANG package core definition . . . . . . . . . . . . . . 15
	6. Package Instance Data Files . . . . . . . . . . . . . . . . . 16		6. Package Instance Data Files . . . . . . . . . . . . . . . . . 17
	7. Package Definitions on a Server . . . . . . . . . . . . . . . 17		7. Package Definitions on a Server . . . . . . . . . . . . . . . 18
	7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18		7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 18		7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 18
	8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 18		8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 19
	9. YANG packages as schema for YANG instance data document . . . 19		9. YANG packages as schema for YANG instance data document . . . 19
	10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 19		10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 39		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 41		13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 39
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 41		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	15.1. Normative References . . . . . . . . . . . . . . . . . . 41		15.1. Normative References . . . . . . . . . . . . . . . . . . 40
	15.2. Informative References . . . . . . . . . . . . . . . . . 44		15.2. Informative References . . . . . . . . . . . . . . . . . 42
			Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 43
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44		A.1. Example IETF Network Device YANG package . . . . . . . . 43
	A.1. Example IETF Network Device YANG package . . . . . . . . 45		A.2. Example IETF Basic Routing YANG package . . . . . . . . . 45
	A.2. Example IETF Basic Routing YANG package . . . . . . . . . 47		A.3. Package import conflict resolution example . . . . . . . 48
	A.3. Package import conflict resolution example . . . . . . . 50		Appendix B. Possible alternative solutions . . . . . . . . . . . 51
	Appendix B. Possible alternative solutions . . . . . . . . . . . 52
	B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 52		B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 52
	B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 53		B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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.
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 36 ¶
	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]:
	* 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]:
	* data node		* data node
			* schema node
	In addition, this document defines the following terminology:		In addition, this document defines the following terminology:
	* YANG schema: A datastore schema, not bound to any particular		* YANG package: a versioned organizational structure used to manage
	datastore.		a set of YANG modules that collectively define a package schema.
			YANG packages are defined in Section 5.
	* YANG package: An organizational structure containing a collection		* package schema: The combined set of schema nodes defined by a YANG
	of YANG modules, normally defined in a YANG instance data file. A		package. Package schema can be used to define datastore schema.
	YANG package defines a YANG schema by specifying a set of YANG
	modules and their revisions, other packages and their revisions,
	mandatory features, and deviations. YANG packages are defined in
	Section 5.
	* 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.
	* 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
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	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.
	A YANG package is an organizational structure that groups a set of		A YANG package is a versioned organizational structure used to manage
	YANG modules together into a consistent versioned definition. For		a set of YANG modules that collectively define a package schema. For
	example, a YANG package could define the set of YANG modules required		example, a YANG package could contain the set of YANG modules
	to implement an L2VPN service on a network device. YANG packages can		required to implement an L2VPN service on a network device.
	themselves refer to, and reuse, other package definitions.
	Non-normative examples of YANG packages are provided in the		Non-normative examples of YANG packages are provided in the
	appendices.		appendices.
	3. Background on YANG packages		3. Background on YANG packages
	It has long been acknowledged within the YANG community that network		It has long been acknowledged within the YANG community that network
	management using YANG requires a unit of organization and conformance		management using YANG requires a unit of organization and conformance
	that is broader in scope than individual YANG modules.		that is broader in scope than individual YANG modules.
	skipping to change at page 5, line 4 ¶		skipping to change at page 4, line 52 ¶
	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 sets of
	YANG packages provide part of the solution for versioning YANG		modules. YANG packages provide part of the solution for versioning
	schema.		sets of modules.
	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:
	* 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).
	* To allow YANG schema to be specified in a concise way rather than		* To allow datastore schema to be specified in a concise way rather
	having each server explicitly list all modules, revisions, and		than having each server explicitly list all modules, revisions,
	features. YANG package definitions can be defined in documents		and features. YANG package definitions can be defined in
	that are available offline, and accessible via a URL, rather than		documents that are available offline, and accessible via a URL,
	requiring explicit lists of modules to be shared between client		rather than requiring explicit lists of modules to be shared
	and server. Hence, a YANG package must contain sufficient		between client and server. Hence, a YANG package must contain
	information to allow a client or server to precisely construct the		sufficient information to allow a client or server to precisely
	schema associated with the package.		construct the schema associated with the package.
	* 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.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	functionality that they support. As industry gains experience using		functionality that they support. As industry gains experience using
	YANG packages, the standard YANG mechanisms of updating, or		YANG packages, the standard YANG mechanisms of updating, or
	augmenting YANG modules could also be used to extend the		augmenting YANG modules could also be used to extend the
	functionality supported by YANG packages, if required.		functionality supported by YANG packages, if required.
	5. YANG Package Definition		5. YANG Package Definition
	This document specifies an approach to defining YANG packages that is		This document specifies an approach to defining YANG packages that is
	different to either of the approaches described in the background.		different to either of the approaches described in the background.
	A YANG package is a versioned organizational structure defining a set		A YANG package is a versioned organizational structure used to manage
	of related YANG modules, packages, features, and deviations. A YANG		a set of YANG modules that collectively define a package schema.
	package collectively defines a YANG schema.
	Each YANG package has a name that SHOULD end with the suffix "-pkg".		Each YANG package has a name that SHOULD end with the suffix "-pkg".
	Package names are normally expected to be globally unique, but in		Package names are normally expected to be globally unique, but in
	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.
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 4 ¶
	[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.
	YANG package definitions are available from the server via		YANG package definitions are available from the server via
	augmentations to YANG Library [RFC8525]. Rather than client		augmentations to YANG Library [RFC8525]. Rather than client
	applications downloading the entire contents of YANG library to		applications downloading the entire contents of YANG library to
	confirm that the server schema is compatible with the client, they		confirm that the server's datastore schema are compatible with the
	can check, or download, a much shorter YANG package definition, and		client, they can simply check the names and versions of the packages
	validate that it conforms to the expected schema.		advertised in YANG library to know what schema to expect in the
			server datastores.
	YANG package definitions can also be used to define the schema		YANG package definitions can also be used to define the content
	associated with YANG instance data files holding other, e.g., non		schema associated with YANG instance data files holding other, e.g.,
	packages related, instance data.		non packages related, instance data.
	5.1. Package definition rules		5.1. Package definition rules
	Packages are defined using the following rules:		Packages are defined using the following rules:
	1. A YANG package MAY represent a complete YANG schema or only part		1. A YANG package MAY represent a referentially complete set of
	of a YANG schema with some module import dependencies missing, as		modules or MAY represent a set of modules with some module import
	described in Section 5.4.		dependencies missing, as described in Section 5.4.
	2. Packages definitions are hierarchical. A package can include		2. Packages definitions are hierarchical. A package can include
	other packages. Only a single version of a package can be		other packages. Only a single version of a package can be
	included, and conflicting package includes (e.g. from descendant		included, and conflicting package includes (e.g. from descendant
	package includes) MUST be explicitly resolved by indicating which		package includes) MUST be explicitly resolved by indicating which
	version takes precedence, and which versions are being replaced.		version takes precedence, and which versions are being replaced.
	3. For each module implemented by a package, only a single revision		3. YANG packages definitions MAY include modules containing
			deviation statements, but those deviation statements MUST only be
			used in an [RFC7950] compatible way to indicate where a server,
			or class of servers, deviates from a published standard.
			Deviations MUST NOT be included in a package definition that is
			part of a published standard. See section Section 5.8.1 for
			further guidance on the use of deviations in YANG packages.
			4. For each module implemented by a package, only a single revision
	of that module MUST be implemented. Multiple revisions of a		of that module MUST be implemented. Multiple revisions of a
	module MAY be listed as import-only dependencies.		module MAY be listed as import-only dependencies.
	4. The revision of a module listed in the package 'module' list		5. The revision of a module listed in the package 'module' list
	supersedes any 'implemented' revision of the module listed in an		supersedes any 'implemented' revision of the module listed in an
	included package module list. The 'replaces-revision' leaf-list		included package module list. The 'replaces-revision' leaf-list
	is used to indicate which 'implemented' or 'import-only' module		is used to indicate which 'implemented' or 'import-only' module
	revisions are replaces by this module revision. This allows a		revisions are replaces by this module revision. This allows a
	package to explicitly resolve conflicts between implemented		package to explicitly resolve conflicts between implemented
	module revisions in included packages.		module revisions in included packages.
	5. The 'replaces-revision' leaf-list in the 'import-only-module'		6. The 'replaces-revision' leaf-list in the 'import-only-module'
	list can be used to exclude duplicate revisions of import-only		list can be used to exclude duplicate revisions of import-only
	modules from included packages. Otherwise, the import-only-		modules from included packages. Otherwise, the import-only-
	modules for a package are the import-only-modules from all		modules for a package are the import-only-modules from all
	included packages combined with any modules listed in the		included packages combined with any modules listed in the
	packages import-only-module list.		packages import-only-module list.
	6. YANG packages definitions MAY include modules containing
	deviation statements, but those deviation statements MUST only be
	used in an RFC 7950 compatible way to indicate where a server, or
	class of servers, deviates from a published standard. Deviations
	MUST NOT be included in a package definition that is part of a
	published standard. See section 5.8.1 for further guidance on
	the use of deviations in YANG packages.
	5.2. Package versioning		5.2. Package versioning
	Individual versions of a YANG package are versioned using the		Individual versions of a YANG package are versioned using the
	"revision-label" scheme defined in section 3.3 of		"revision-label" scheme defined in section 3.3 of
	[I-D.ietf-netmod-yang-module-versioning].		[I-D.ietf-netmod-yang-module-versioning].
	5.2.1. Updating a package with a new version		5.2.1. Updating a package with a new version
	Package compatibility is fundamentally defined by how the YANG schema		Package compatibility is fundamentally defined by how the package
	between two package versions has changed.		schema between two package versions has changed.
	When a package definition is updated, the version associated with the		When a package definition is updated, the version associated with the
	package MUST be updated appropriately, taking into consideration the		package MUST be updated appropriately, taking into consideration the
	scope of the changes as defined by the rules below.		scope of the changes as defined by the rules below.
	A package definition SHOULD define the previous version of the
	package in the 'previous-version' leaf unless it is the initial
	version of the package. If the 'previous-version' leaf is provided
	then the package definition MUST set the 'nbc-changes' leaf if the
	new version is non-backwards-compatible with respect to the package
	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:
	* 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.
	* 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.
	* Removing a feature from the 'mandatory-feature' leaf-list.		* Removing a feature from the 'mandatory-feature' leaf-list.
	* Adding, changing, or removing a deviation that is considered a		* Adding, changing, or removing a module containing one or more
	non-backwards-compatible change to the affected data node in the		deviations, that when applied to the target module would create a
	schema associated with the prior package version.		change that is considered a non-backwards-compatible change to the
			affected data node in the 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:
	* 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.
	* 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.
	* Adding a feature to the 'mandatory-feature' leaf-list.		* Adding a feature to the 'mandatory-feature' leaf-list.
	* Adding, changing, or removing a deviation that is considered a		* Adding, changing, or removing a module containing one or more
	backwards-compatible change to the affected data node in the		deviations, that when applied to the target module would create a
	schema associated with the prior package version.		change that is considered a backwards-compatible change to the
			affected data node in the 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:
	* 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.
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 42 ¶
	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.
	* Any change to any metadata associated with a package definition.		* Any change to any metadata associated with a package definition.
	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 'ysver:version' type specified
	specified in ietf-yang-semver.yang, then the package version leaf		in ietf-yang-semver.yang, then the package version leaf MUST be
	MUST be interpreted as a YANG semantic version number.		interpreted as a YANG semantic version number.
	For YANG packages defined by the IETF, YANG semantic version numbers		For YANG packages defined by the IETF, YANG semantic version numbers
	MUST be used as the version scheme for YANG packages.		MUST be used as the version scheme for YANG packages.
	The rules for incrementing the YANG package version number are		The rules for incrementing the YANG package version number are
	equivalent to the semantic versioning rules used to version		equivalent to the semantic versioning rules used to version
	individual YANG modules, defined in section 3.2 of		individual YANG modules, defined in section 3.2 of
	[I-D.ietf-netmod-yang-semver], but use the rules defined previously		[I-D.ietf-netmod-yang-semver], but use the rules defined previously
	in Section 5.2.1 to determine whether a change is classified as non-		in Section 5.2.1 to determine whether a change is classified as non-
	backwards-compatible, backwards-compatible, or editorial. Where		backwards-compatible, backwards-compatible, or editorial. Where
	available, the semantic version number of the referenced elements in		available, the semantic version number of the referenced elements in
	the package (included packages or modules) can be used to help		the package (included packages or modules) can be used to help
	determine the scope of changes being made.		determine the scope of changes being made.
	5.2.3. Revision history
	YANG packages do not contain a revision history. This is because
	packages may have many revisions and a long revision history would
	bloat the package definition. By recursively examining the
	'previous-version' leaf of a package definition, a full revision
	history (including where non-backwards-compatible changes have
	occurred) can be dynamically constructed, if all package versions are
	available.
	5.3. Package conformance		5.3. Package conformance
	YANG packages allows for conformance to be checked at a package level		YANG packages allows for conformance to be checked at a package level
	rather than requiring a client to download all modules, revisions,		rather than requiring a client to download all modules, revisions,
	and deviations from the server to ensure that the datastore schema		and deviations from the server to ensure that the datastore schema
	used by the server is compatible with the client.		used by the server is compatible with the client.
	YANG package conformance is analogous to how YANG [RFC7950] requires		YANG package conformance is analogous to how YANG [RFC7950] requires
	that servers either implement a module faithfully, or otherwise use		that servers either implement a module faithfully, or otherwise use
	deviations to indicate areas of non-conformance.		deviations to indicate areas of non-conformance.
	For a top level package representing a datastore schema, servers MUST		For a top level package representing a datastore schema, servers MUST
	implement the package definition faithfully, including all mandatory		implement the package definition faithfully, including all mandatory
	features.		features.
	Package definitions MAY modify the schema for directly or		Package definitions MAY modify the schema for directly or
	hierarchically included packages through the use of different module		hierarchically included packages through the use of different module
	revisions or module deviations. If the schema of any included		revisions or module deviations.
	package is modified in a non-backwards-compatible way then it MUST be
	indicated by setting the 'nbc-modified' leaf to true.
	5.3.1. Use of YANG semantic versioning		5.3.1. Use of YANG semantic versioning
	Using the YANG semantic versioning scheme for package version numbers		Using the YANG semantic versioning scheme for package version numbers
	and module revision labels can help with conformance. In the general		and module revision labels can help with conformance. In the general
	case, clients should be able to determine the nature of changes		case, clients should be able to determine the nature of changes
	between two package versions by comparing the version number.		between two package versions by comparing the version number.
	This usually means that a client does not have to be restricted to		This usually means that a client does not have to be restricted to
	working only with servers that advertise exactly the same version of		working only with servers that advertise exactly the same version of
	skipping to change at page 12, line 5 ¶		skipping to change at page 11, line 37 ¶
	* 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 schema, it follows that each
	each datastore schema can be represented using packages. In		datastore schema can be represented using packages. In addition, the
	addition, the schema for most datastores on a server are often		schema for most datastores on a server are often closely related.
	closely related. Given that there are many ways that a datastore		Given that there are many ways that a datastore schema could be
	schema could be represented using packages, the following guidance		represented using packages, the following guidance provides a
	provides a consistent approach to help clients understand the		consistent approach to help clients understand the relationship
	relationship between the different datastore schema supported by a		between the different datastore schema supported by a device (e.g.,
	device (e.g., which parts of the schema are common and which parts		which parts of the schema are common and which parts have
	have differences):		differences):
	* 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.
	* 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.,
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 7 ¶
	offline from the server in a YANG instance data file.		offline from the server in a YANG instance data file.
	5.6. Submodules packages considerations		5.6. Submodules packages considerations
	As defined in [RFC7950] and [I-D.ietf-netmod-yang-semver], YANG		As defined in [RFC7950] and [I-D.ietf-netmod-yang-semver], YANG
	conformance and versioning is specified in terms of particular		conformance and versioning is specified in terms of particular
	revisions of YANG modules rather than for individual submodules.		revisions of YANG modules rather than for individual submodules.
	However, YANG package definitions also include the list of submodules		However, YANG package definitions also include the list of submodules
	included by a module, primarily to provide a location of where the		included by a module, primarily to provide a location of where the
	submodule definition can be obtained from, allowing a YANG schema to		submodule definition can be obtained from, allowing a schema to be
	be fully constructed from a YANG package instance data file		fully constructed from a YANG package instance data file definition.
	definition.
	5.7. Package tags		5.7. Package tags
	[I-D.ietf-netmod-module-tags] defines YANG module tags as a mechanism		[I-D.ietf-netmod-module-tags] defines YANG module tags as a mechanism
	to annotate a module definition with additional metadata. Tags MAY		to annotate a module definition with additional metadata. Tags MAY
	also be associated to a package definition via the 'tags' leaf-list.		also be associated to a package definition via the 'tags' leaf-list.
	The tags use the same registry and definitions used by YANG module		The tags use the same registry and definitions used by YANG module
	tags.		tags.
	5.8. YANG Package Usage Guidance		5.8. YANG Package Usage Guidance
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 21 ¶
	grouping yang-pkg-instance		grouping yang-pkg-instance
	+-- name pkg-name		+-- name pkg-name
	+-- version pkg-version		+-- version pkg-version
	+-- timestamp? yang:date-and-time		+-- timestamp? yang:date-and-time
	+-- organization? string		+-- organization? string
	+-- contact? string		+-- contact? string
	+-- description? string		+-- description? string
	+-- reference? string		+-- reference? string
	+-- complete? boolean		+-- complete? boolean
	+-- local? boolean		+-- local? boolean
	+-- previous-version? pkg-version
	+-- 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
	| +-- location* inet:uri		| +-- location* inet:uri
	+-- 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
	| +-- submodule* [name]		| +-- submodule* [name]
	| +-- name? yang:yang-identifier		| +-- name? yang:yang-identifier
	| +-- revision yang:revision-identifier		| +-- revision yang:revision-identifier
	skipping to change at page 16, line 46 ¶		skipping to change at page 17, line 9 ¶
	+-- location* inet:uri		+-- location* inet:uri
	+-- 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
	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 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:
	1. The file SHOULD be encoded in JSON.		1. The file SHOULD be encoded in JSON.
	2. The name of the file SHOULD follow the format "<package-		2. The name of the file SHOULD follow the format "<package-
	name>@<version>.json".		name>@<version>.json".
	3. The package name MUST be specified in both the instance-data-set		3. The package name MUST be specified in both the instance-data-set
	skipping to change at page 19, line 21 ¶		skipping to change at page 19, line 40 ¶
	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
	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 content schema definition
	YANG instance data files. When using a package schema, the name and		for YANG instance data files. When using a package-based content
	version of the package MUST be specified, a package URL to the		schema, the name and version of the package MUST be specified, a
	package definition MAY also be provided.		package URL to the 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/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
	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@2021-10-25.yang"		<CODE BEGINS>
			file "ietf-yang-package-types#0.3.0-draft-ietf-netmod-yang-packages-03.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;
	rev:revision-or-derived 2013-07-15;		rev:revision-or-derived "2013-07-15";
	reference "RFC 6991: Common YANG Data Types.";		reference
			"RFC 6991: Common YANG Data Types.";
	}		}
	import ietf-module-tags {		import ietf-module-tags {
	prefix tags;		prefix tags;
	// RFC Ed. Fix revision once revision date of		reference
	// ietf-module-tags.yang is known.		"RFC 8819: YANG Module Tags.";
	reference "RFC XXX: YANG Module Tags.";
	}		}
	organization		organization
	"IETF NETMOD (Network Modeling) Working Group";		"IETF NETMOD (Network Modeling) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Rob Wilton		Author: Rob Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This module provides type and grouping definitions for YANG		"This module provides type and grouping definitions for YANG
	packages.		packages.
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2022 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 Revised 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).		(https://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 2021-10-25 {
	rev:revision-label 0.2.0;		revision 2022-03-04 {
			rev:revision-label 0.3.0-draft-ietf-netmod-yang-packages-03;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Typedefs		* Typedefs
	*/		*/
	skipping to change at page 22, line 48 ¶		skipping to change at page 23, line 16 ¶
	draft-verdt-nemod-yang-module-versioning, section XXX";		draft-verdt-nemod-yang-module-versioning, section XXX";
	}		}
	}		}
	grouping yang-pkg-instance {		grouping yang-pkg-instance {
	description		description
	"Specifies the data node for a full YANG package instance		"Specifies the data node for a full YANG package instance
	represented either on a server or as a YANG instance data		represented either on a server or as a YANG instance data
	document.";		document.";
	uses yang-pkg-identification-leafs;		uses yang-pkg-identification-leafs;
	leaf timestamp {		leaf timestamp {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"An optional timestamp for when this package was created.		"An optional timestamp for when this package was created.
	This does not need to be unique across all versions of a		This does not need to be unique across all versions of a
	package.";		package.";
	}		}
	leaf organization {		leaf organization {
	type string;		type string;
			description
	description "Organization responsible for this package";		"Organization responsible for this package";
	}		}
	leaf contact {		leaf contact {
	type string;		type string;
	description		description
	"Contact information for the person or organization to whom		"Contact information for the person or organization to whom
	queries concerning this package should be sent.";		queries concerning this package should be sent.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
			description
	description "Provides a description of the package";		"Provides a description of the package";
	}		}
	leaf reference {		leaf reference {
	type string;		type string;
			description
	description "Allows for a reference for the package";		"Allows for a reference for the package";
	}		}
	leaf complete {		leaf complete {
	type boolean;		type boolean;
	default true;		default "true";
	description		description
	"Indicates whether the schema defined by this package is		"Indicates whether the schema defined by this package is
	referentially complete. I.e. all module imports can be		referentially complete. I.e. all module imports can be
	resolved to a module explicitly defined in this package or		resolved to a module explicitly defined in this package or
	one of the included packages.";		one of the included packages.";
	}		}
	leaf local {		leaf local {
	type boolean;		type boolean;
	default false;		default "false";
	description		description
	"Defines that the package definition is local to the server,		"Defines that the package definition is local to the server,
	and the name of the package MAY not be unique, and the		and the name of the package MAY not be unique, and the
	package definition MAY not be available in an offline file.		package definition MAY not be available in an offline file.
	Local packages can be used when the schema for the device		Local packages can be used when the schema for the device
	can be changed at runtime through the addition or removal of		can be changed at runtime through the addition or removal of
	software packages, or hot fixes.";		software packages, or hot fixes.";
	}		}
	leaf previous-version {
	type pkg-version;
	description
	"The previous package version that this version has been
	derived from. This leaf allows a full version history graph
	to be constructed if required.";
	}
	leaf nbc-changes {
	type boolean;
	default false;
	description
	"Indicates whether the defined package version contains
	non-backwards-compatible changes relative to the package
	version defined in the 'previous-version' leaf.";
	}
	leaf-list tag {		leaf-list tag {
	type tags:tag;		type tags:tag;
	description		description
	"Tags associated with a YANG package. Module tags defined in		"Tags associated with a YANG package. Module tags defined in
	XXX, ietf-netmod-module-tags can be used here but with the		XXX, ietf-netmod-module-tags can be used here but with the
	modification that the tag applies to the entire package		modification that the tag applies to the entire package
	rather than a specific module. See the IANA 'YANG Module		rather than a specific module. See the IANA 'YANG Module
	Tag Prefix' registry for reserved prefixes and the IANA		Tag Prefix' registry for reserved prefixes and the IANA
	'YANG Module IETF Tag' registry for IETF standard tags.";		'YANG Module IETF Tag' registry for IETF standard tags.";
	}		}
	skipping to change at page 25, line 19 ¶		skipping to change at page 25, line 5 ¶
	key "name version";		key "name version";
	description		description
	"An entry in this list represents a package that is included		"An entry in this list represents a package that is included
	as part of the package definition, or an indirectly included		as part of the package definition, or an indirectly included
	package that is changed in a non backwards compatible way.		package that is changed in a non backwards compatible way.
	It can be used to resolve inclusion of conflicting package		It can be used to resolve inclusion of conflicting package
	versions by explicitly specifying which package version is		versions by explicitly specifying which package version is
	used.		used.
	If included packages implement different revisions or		If included packages implement different revisions
	versions of the same module, then an explicit entry in the		of the same module, then an explicit entry in the
	module list MUST be provided to select the specific module		module list MUST be provided to select the specific module
	version 'implemented' by this package definition.		revision 'implemented' by this package definition.
	If the schema for any packages that are included, either
	directly or indirectly via another package include, are
	changed in any non-backwards-compatible way then they MUST
	be explicitly listed in the included-packages list with the
	'nbc-modified' leaf set to true.
	For import-only modules, the 'replaces-revision' leaf-list		For import-only modules, the 'replaces-revision' leaf-list
	can be used to select the specific module versions used by		can be used to select the specific module revisions used by
	this package.";		this package.";
	reference		reference
	"XXX";		"XXX";
	uses yang-pkg-identification-leafs;		uses yang-pkg-identification-leafs;
	leaf-list replaces-version {		leaf-list replaces-version {
	type pkg-version;		type pkg-version;
	description		description
	"Gives the version of an included package version that		"Gives the version of an included package version that
	is replaced by this included package revision.";		is replaced by this included package version.";
	}
	leaf nbc-modified {
	type boolean;
	default false;
	description
	"Set to true if any data nodes in this package are modified
	in a non backwards compatible way, either through the use
	of deviations, or because one of the modules has been
	replaced by an incompatible revision. This could also
	occur if a module's revision was replaced by an earlier
	revision that had the effect of removing some data
	nodes.";
	}		}
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"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
	skipping to change at page 26, line 39 ¶		skipping to change at page 25, line 50 ¶
	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.
	A entry in this list overrides any module revision		A entry in this list overrides any module revision
	'implemented' by an included package. Any replaced module		'implemented' by an included package. Any replaced module
	revision SHOULD also be listed in the 'replaces-revision'		revision SHOULD also be listed in the 'replaces-revision'
	list.";		list.";
	reference		reference
	"RFC 7950: The YANG 1.1 Data Modeling Language.";		"RFC 7950: The YANG 1.1 Data Modeling Language.";
	leaf name {		leaf name {
	type yang:yang-identifier;		type yang:yang-identifier;
	mandatory true;		mandatory true;
	description		description
	"The YANG module name.";		"The YANG module name.";
	}		}
	leaf revision {		leaf revision {
	type rev:revision-date-or-label;		type rev:revision-date-or-label;
	description		description
	"The YANG module revision date or revision-label.		"The YANG module revision date or revision-label.
	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 module (implemented or		"Gives the revision of an module (implemented or
	import-only) defined in an included package that is		import-only) defined in an included package that is
	replaced by this implemented module revision.";		replaced by this implemented 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.";
	}		}
	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
	"The YANG submodule name.";		"The YANG submodule name.";
	}		}
	leaf revision {		leaf revision {
	type yang:revision-identifier;		type rev:revision-date-or-label;
	mandatory true;		mandatory true;
	description		description
	"The YANG submodule revision date. If the parent module		"The YANG submodule revision date or revision-label.
	include statement for this submodule includes a revision
	date then it MUST match this leaf's value.";
			If the parent module include statement for this submodule
			includes a revision date then it MUST match the revision
			date specified here or it MUST match the revision-date
			associated with the revision-label specified here.";
	}		}
	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.";
	}		}
	}		}
	}		}
	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.
	Multiple entries for the same module name MAY exist. This		Multiple entries for the same module name MAY exist. This
	can occur if multiple modules import the same module, but		can occur if multiple modules import the same module, but
	skipping to change at page 28, line 31 ¶		skipping to change at page 27, line 32 ¶
	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.
	Multiple entries for the same module name MAY exist. This		Multiple entries for the same module name MAY exist. This
	can occur if multiple modules import the same module, but		can occur if multiple modules import the same module, but
	specify different revision-dates in the import statements.";		specify different revision-dates in the import statements.";
	leaf name {		leaf name {
	type yang:yang-identifier;		type yang:yang-identifier;
	description		description
	"The YANG module name.";		"The YANG module name.";
	}		}
	leaf revision {		leaf revision {
	type rev:revision-date-or-label;		type rev:revision-date-or-label;
	description		description
	"The YANG module revision date or revision-label.		"The YANG module revision date or revision-label.
	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.";
	}		}
	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
	"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.";
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
			<CODE BEGINS>
	<CODE BEGINS> file "ietf-yang-package-instance@2021-10-25.yang"		file "ietf-yang-package-instance#0.3.0-draft-ietf-netmod-yang-packages-03.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";
	}		}
	import ietf-yang-package-types {		import ietf-yang-package-types {
	prefix pkg-types;		prefix pkg-types;
	rev:revision-or-derived 0.2.0;		rev:revision-or-derived "0.2.0";
	reference "RFC XXX: YANG Schema Versioning.";		reference
			"RFC XXX: this RFC.";
	}		}
	import ietf-yang-structure-ext {		import ietf-yang-structure-ext {
	prefix sx;		prefix sx;
	reference "RFC XXX: YANG Data Structure Extensions.";		reference
			"RFC 8791: YANG Data Structure Extensions.";
	}		}
	organization		organization
	"IETF NETMOD (Network Modeling) Working Group";		"IETF NETMOD (Network Modeling) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Rob Wilton		Author: Rob Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This module provides a definition of a YANG package, which is		"This module provides a definition of a YANG package, which is
	used as the schema for an YANG instance data document specifying		used as the content schema for an YANG instance data document specifying
	a YANG package.		a YANG package.
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2022 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 Revised 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).		(https://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 {
	rev:revision-label 0.2.0;		revision 2022-03-04 {
			rev:revision-label 0.3.0-draft-ietf-netmod-yang-packages-03;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Top-level structure		* Top-level structure
	*/		*/
			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@2021-10-25.yang"		<CODE BEGINS>
			file "ietf-yang-packages#0.3.0-draft-ietf-netmod-yang-packages-03.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 {
	prefix pkg-types;		prefix pkg-types;
	rev:revision-or-derived 0.2.0;		rev:revision-or-derived "0.2.0";
	reference "RFC XXX: YANG Packages.";		reference
			"RFC XXX: this RFC.";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	rev:revision-or-derived 2013-07-15;		rev:revision-or-derived "2013-07-15";
	reference "RFC 6991: Common YANG Data Types.";		reference
			"RFC 6991: Common YANG Data Types.";
	}		}
	organization		organization
	"IETF NETMOD (Network Modeling) Working Group";		"IETF NETMOD (Network Modeling) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Rob Wilton		Author: Rob Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This module defines YANG packages on a server implementation.		"This module defines YANG packages on a server implementation.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2022 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 Revised 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).		(https://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 2021-10-25 {
	rev:revision-label 0.2.0;		revision 2022-03-04 {
			rev:revision-label 0.3.0-draft-ietf-netmod-yang-packages-03;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	skipping to change at page 33, line 24 ¶		skipping to change at page 32, line 16 ¶
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	grouping yang-pkg-ref {		grouping yang-pkg-ref {
	description		description
	"Defines the leaves used to reference a single YANG package";		"Defines the leaves used to reference a single YANG package";
	leaf name {		leaf name {
	type leafref {		type leafref {
	path '/pkgs:packages/pkgs:package/pkgs:name';		path "/pkgs:packages/pkgs:package/pkgs:name";
	}		}
	description		description
	"The name of the references package.";		"The name of the references package.";
	}		}
	leaf version {		leaf version {
	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.";
	}		}
	}		}
	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";
	description		description
	"Identifies the YANG packages that collectively defines the		"Identifies the YANG packages that collectively defines the
	schema for the associated datastore.		schema for the associated datastore.
	The datastore schema is defined as the union of all		The datastore schema is defined as the union of all
	referenced packages, that MUST represent a referentially		referenced packages, that MUST represent a referentially
	complete schema.		complete schema.
	All of the referenced packages must be compatible with no		All of the referenced packages must be compatible with no
	conflicting module versions or dependencies.";		conflicting module versions or dependencies.";
	skipping to change at page 34, line 16 ¶		skipping to change at page 32, line 50 ¶
	description		description
	"Identifies the YANG packages that collectively defines the		"Identifies the YANG packages that collectively defines the
	schema for the associated datastore.		schema for the associated datastore.
	The datastore schema is defined as the union of all		The datastore schema is defined as the union of all
	referenced packages, that MUST represent a referentially		referenced packages, that MUST represent a referentially
	complete schema.		complete schema.
	All of the referenced packages must be compatible with no		All of the referenced packages must be compatible with no
	conflicting module versions or dependencies.";		conflicting module versions or dependencies.";
	uses yang-pkg-ref;		uses yang-pkg-ref;
	}		}
	}		}
	/*		/*
	* Top level data nodes.		* Top level data nodes.
	*/		*/
	container packages {		container packages {
	config false;		config false;
	description "All YANG package definitions";		description
			"All YANG package definitions";
	list package {		list package {
	key "name version";		key "name version";
	description		description
	"YANG package instance";		"YANG package instance";
	uses pkg-types:yang-pkg-instance;		uses pkg-types:yang-pkg-instance;
	leaf-list location {		leaf-list location {
	type inet:uri;		type inet:uri;
	description		description
	"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
	skipping to change at page 35, line 4 ¶		skipping to change at page 33, line 34 ¶
	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";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-yl-package@2020-01-21.yang"		<CODE BEGINS>
			file "ietf-yl-package#0.3.0-draft-ietf-netmod-yang-packages-03.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;
	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-packages {		import ietf-yang-packages {
	prefix pkgs;		prefix pkgs;
	rev:revision-or-derived 0.2.0;		rev:revision-or-derived "0.2.0";
	reference "RFC XXX: YANG Packages.";		reference
			"RFC XXX: YANG Packages.";
	}		}
	import ietf-yang-library {		import ietf-yang-library {
	prefix yanglib;		prefix yanglib;
	rev:revision-or-derived 2019-01-04;		rev:revision-or-derived "2019-01-04";
	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: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Rob Wilton		Author: Rob Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This module provides defined augmentations to YANG library to		"This module provides defined augmentations to YANG library to
	allow a server to report YANG package information.		allow a server to report YANG package information.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2022 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 Revised 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).		(https://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 {
	rev:revision-label 0.2.0;		revision 2022-03-04 {
			rev:revision-label 0.3.0-draft-ietf-netmod-yang-packages-03;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Augmentations		* Augmentations
	*/		*/
	skipping to change at page 36, line 36 ¶		skipping to change at page 35, line 19 ¶
	}		}
	/*		/*
	* 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@2021-10-25.yang"		<CODE BEGINS>
			file "ietf-yang-inst-data-pkg#0.3.0-draft-ietf-netmod-yang-packages-03.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";
	}		}
	import ietf-yang-package-types {		import ietf-yang-package-types {
	prefix pkg-types;		prefix pkg-types;
	rev:revision-or-derived 0.2.0;		rev:revision-or-derived "0.2.0";
	reference "RFC XXX: YANG Schema Versioning.";		reference
			"RFC XXX: this RFC.";
	}		}
	import ietf-yang-structure-ext {		import ietf-yang-structure-ext {
	prefix sx;		prefix sx;
	reference "RFC XXX: YANG Data Structure Extensions.";		reference
			"RFC 8791: YANG Data Structure Extensions.";
	}		}
	import ietf-yang-instance-data {		import ietf-yang-instance-data {
	prefix yid;		prefix yid;
	reference "RFC XXX: YANG Instance Data File Format.";		reference
			"RFC 9195: A File Format for YANG Instance Data.";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference "RFC 6991: Common YANG Data Types.";		reference
			"RFC 6991: Common YANG Data Types.";
	}		}
	organization		organization
	"IETF NETMOD (Network Modeling) Working Group";		"IETF NETMOD (Network Modeling) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Author: Rob Wilton		Author: Rob Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"The module augments ietf-yang-instance-data to allow package		"The module augments ietf-yang-instance-data to allow package
	definitions to be used to define schema in YANG instance data		definitions to be used to define content schema in YANG instance data
	documents.		documents.
	Copyright (c) 2019 IETF Trust and the persons identified as		Copyright (c) 2022 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 Revised 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).		(https://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 {
	rev:revision-label 0.2.0;		revision 2022-03-04 {
			rev:revision-label 0.3.0-draft-ietf-netmod-yang-packages-03;
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: YANG Packages";		"RFC XXXX: YANG Packages";
	}		}
	/*		/*
	* Augmentations		* Augmentations
	*/		*/
			sx:augment-structure "/yid:instance-data-set/yid:content-schema/yid:content-schema-spec" {
	sx:augment-structure
	"/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-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 39, line 39 ¶		skipping to change at page 38, line 19 ¶
	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.		files to restrict access to sensitive information.
	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		information in YANG packages may help an attacker identify the server
	identify the server capabilities and server implementations with		capabilities and server implementations with known bugs since the set
	known bugs since the set of YANG modules supported by a server may		of YANG modules supported by a server may reveal the kind of device
	reveal the kind of device and the manufacturer of the device. Server		and the manufacturer of the device. Server vulnerabilities may be
	vulnerabilities may be specific to particular modules, module		specific to particular modules, module revisions, module features, or
	revisions, module features, or even module deviations. For example,		even module deviations. For example, if a particular operation on a
	if a particular operation on a particular data node is known to cause		particular data node is known to cause a server to crash or
	a server to crash or significantly degrade device performance, then		significantly degrade device performance, then the YANG packages
	the YANG packages information will help an attacker identify server		information will help an attacker identify server implementations
	implementations with such a defect, in order to launch a denial-of-		with such a defect, in order to launch a denial-of-service attack on
	service attack on the device.		the device.
	12. IANA Considerations		12. IANA Considerations
	It is expected that a central registry of standard YANG package		It is expected that a central registry of standard YANG package
	definitions is required to support this solution.		definitions is required to support this solution.
	It is unclear whether an IANA registry is also required to manage		It is unclear whether an IANA registry is also required to manage
	specific package versions. It is highly desirable to have a specific		specific package versions. It is highly desirable to have a specific
	canonical location, under IETF control, where the definitive YANG		canonical location, under IETF control, where the definitive YANG
	package versions can be obtained from.		package versions can be obtained from.
	skipping to change at page 42, line 9 ¶		skipping to change at page 40, line 37 ¶
	tags-10.txt>.		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", Work in Progress, Internet-Draft,		Structure Extensions", Work in Progress, Internet-Draft,
	draft-ietf-netmod-yang-data-ext-05, 9 December 2019,		draft-ietf-netmod-yang-data-ext-05, 9 December 2019,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	data-ext-05.txt>.		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, "A File Format for YANG
	Format", Work in Progress, Internet-Draft, draft-ietf-		Instance Data", Work in Progress, Internet-Draft, draft-
	netmod-yang-instance-file-format-21, 8 October 2021,		ietf-netmod-yang-instance-file-format-21, 8 October 2021,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	instance-file-format-21.txt>.		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., and J.		Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
	Sterne, "Updated YANG Module Revision Handling", Work in		Sterne, "Updated YANG Module Revision Handling", Work in
	Progress, Internet-Draft, draft-ietf-netmod-yang-module-		Progress, Internet-Draft, draft-ietf-netmod-yang-module-
	versioning-03, 12 July 2021,		versioning-05, 8 November 2021,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	module-versioning-03.txt>.		module-versioning-05.txt>.
	[I-D.ietf-netmod-yang-semver]		[I-D.ietf-netmod-yang-semver]
	Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,		Clarke, J., Wilton, R., Rahman, R., Lengyel, B., Sterne,
	B., Sterne, J., and K. D'Souza, "YANG Semantic		J., and B. Claise, "YANG Semantic Versioning", Work in
	Versioning", Work in Progress, Internet-Draft, draft-ietf-		Progress, Internet-Draft, draft-ietf-netmod-yang-semver-
	netmod-yang-semver-03, 12 July 2021,		06, 30 November 2021, <https://www.ietf.org/archive/id/
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		draft-ietf-netmod-yang-semver-06.txt>.
	semver-03.txt>.
	[I-D.ietf-netmod-yang-solutions]		[I-D.ietf-netmod-yang-solutions]
	Wilton, R., "YANG Versioning Solution Overview", Work in		Wilton, R., "YANG Versioning Solution Overview", Work in
	Progress, Internet-Draft, draft-ietf-netmod-yang-		Progress, Internet-Draft, draft-ietf-netmod-yang-
	solutions-01, 2 November 2020,		solutions-01, 2 November 2020,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	solutions-01.txt>.		solutions-01.txt>.
	[I-D.ietf-netmod-yang-ver-selection]		[I-D.ietf-netmod-yang-ver-selection]
	Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,		Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
	"YANG Schema Selection", Work in Progress, Internet-Draft,		"YANG Schema Selection", Work in Progress, Internet-Draft,
	draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,		draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	ver-selection-00.txt>.		ver-selection-00.txt>.
	[I-D.ietf-netmod-yang-versioning-reqs]		[I-D.ietf-netmod-yang-versioning-reqs]
	Clarke, J., "YANG Module Versioning Requirements", Work in		Clarke, J., "YANG Module Versioning Requirements", Work in
	Progress, Internet-Draft, draft-ietf-netmod-yang-		Progress, Internet-Draft, draft-ietf-netmod-yang-
	versioning-reqs-05, 6 July 2021,		versioning-reqs-06, 6 January 2022,
	<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-		<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
	versioning-reqs-05.txt>.		versioning-reqs-06.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 44, line 15 ¶		skipping to change at page 42, line 41 ¶
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	[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>.
			[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
			Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
			June 2020, <https://www.rfc-editor.org/info/rfc8791>.
	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", Work in		Bierman, A., "The YANG Package Statement", Work in
	Progress, Internet-Draft, draft-bierman-netmod-yang-		Progress, Internet-Draft, draft-bierman-netmod-yang-
	package-00, 6 July 2015, <https://www.ietf.org/archive/id/		package-00, 6 July 2015, <https://www.ietf.org/archive/id/
	draft-bierman-netmod-yang-package-00.txt>.		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,
	skipping to change at page 45, line 18 ¶		skipping to change at page 43, line 47 ¶
	Network Device YANG package formatted in JSON.		Network Device YANG package formatted in JSON.
	This example package is intended to represent the standard set of		This example package is intended to represent the standard set of
	YANG modules, with import dependencies, to implement a basic network		YANG modules, with import dependencies, to implement a basic network
	device without any dynamic routing or layer 2 services. E.g., it		device without any dynamic routing or layer 2 services. E.g., it
	includes functionality such as system information, interface and		includes functionality such as system information, interface and
	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, the modules are referenced by
	revision date rather than version number.		revision date rather than revision 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": {		"content-schema": {
	package: "ietf-yang-package-defn-pkg@0.1.0.json"		"pkg-schema": {
			"name": "ietf-yang-package-defn-pkg",
			"version": "0.1.0"
			}
	},		},
	"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",
	"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>",
	skipping to change at page 47, line 23 ¶		skipping to change at page 46, line 13 ¶
	Routing YANG package formatted in JSON.		Routing YANG package formatted in JSON.
	This example package is intended to represent the standard set of		This example package is intended to represent the standard set of
	YANG modules, with import dependencies, that builds upon the example-		YANG modules, with import dependencies, that builds upon the example-
	ietf-network-device YANG package to add support for basic dynamic		ietf-network-device YANG package to add support for basic dynamic
	routing and ACLs.		routing and ACLs.
	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. Locations have been		revision date rather than revision number. Locations have been
	excluded where they are not currently known, e.g., for YANG modules		excluded where they are not currently known, e.g., for YANG modules
	defined in IETF drafts. In a normal YANG package, locations would be		defined in IETF drafts. In a normal YANG package, locations would be
	expected to be provided for all YANG modules.		expected to be provided for all YANG modules.
	<CODE BEGINS> file "example-ietf-routing-pkg.json"		<CODE BEGINS> file "example-ietf-routing-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-routing-pkg",		"name": "example-ietf-routing-pkg",
	"module": [ "ietf-yang-package@2019-09-11.yang" ],		"content-schema": {
			"pkg-schema": {
			"name": "ietf-yang-package-defn-pkg",
			"version": "0.1.0"
			}
			},
	"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-routing",		"name": "example-ietf-routing",
	"version": "1.3.1",		"version": "1.3.1",
	"timestamp": "2018-12-13T17:00:00Z",		"timestamp": "2018-12-13T17:00:00Z",
	"description": "This package defines a small sample set of \		"description": "This package defines a small sample set of \
	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.",
	skipping to change at page 50, line 8 ¶		skipping to change at page 48, line 49 ¶
	]		]
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	A.3. Package import conflict resolution example		A.3. Package import conflict resolution example
	This section provides an example of how a package can resolve		This section provides an example of how a package can resolve
	conflicting module versions from imported packages.		conflicting module revisions from imported packages.
	In this example, YANG package 'example-3-pkg' imports both 'example-		In this example, YANG package 'example-3-pkg' imports both 'example-
	import-1' and 'example-import-2' packages. However, the two imported		import-1' and 'example-import-2' packages. However, the two imported
	packages implement different versions of 'example-module-A' so the		packages implement different revisions of 'example-module-A' so the
	'example-3-pkg' package selects version '1.2.3' to resolve the		'example-3-pkg' package selects version '1.2.3' to resolve the
	conflict. Similarly, for import-only modules, the 'example-3-pkg'		conflict. Similarly, for import-only modules, the 'example-3-pkg'
	package does not require both versions of example-types-module-C to		package does not require both revisions of example-types-module-C to
	be imported, so it indicates that it only imports revision		be imported, so it indicates that it only imports revision
	'2018-11-26' and not '2018-01-01'.		'2018-11-26' and not '2018-01-01'.
	{		{
	"ietf-yang-instance-data:instance-data-set": {		"ietf-yang-instance-data:instance-data-set": {
	"name": "example-import-1-pkg",		"name": "example-import-1-pkg",
			"content-schema": {
			"pkg-schema": {
			"name": "ietf-yang-package-defn-pkg",
			"version": "0.1.0"
			}
			},
	"description": "First imported example package",		"description": "First imported example package",
	"content-data": {		"content-data": {
	"ietf-yang-package-instance:yang-package": {		"ietf-yang-package-instance:yang-package": {
	"name": "example-import-1",		"name": "example-import-1",
	"version": "1.0.0",		"version": "1.0.0",
	"reference": "XXX, draft-rwilton-netmod-yang-packages",		"reference": "XXX, draft-rwilton-netmod-yang-packages",
	"revision-date": "2018-01-01",		"revision-date": "2018-01-01",
	"module": [		"module": [
	{		{
	"name": "example-module-A",		"name": "example-module-A",
	"version": "1.0.0"		"revision": "1.0.0"
	},		},
	{		{
	"name": "example-module-B",		"name": "example-module-B",
	"version": "1.0.0"		"revision": "1.0.0"
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "example-types-module-C",		"name": "example-types-module-C",
	"revision": "2018-01-01"		"revision": "2018-01-01"
	},		},
	{		{
	"name": "example-types-module-D",		"name": "example-types-module-D",
	"revision": "2018-01-01"		"revision": "2018-01-01"
	}		}
	]		]
	}		}
	}		}
	}
			}
	}		}
	{		{
	"ietf-yang-instance-data:instance-data-set": {		"ietf-yang-instance-data:instance-data-set": {
	"name": "example-import-2-pkg",		"name": "example-import-2-pkg",
			"content-schema": {
			"pkg-schema": {
			"name": "ietf-yang-package-defn-pkg",
			"version": "0.1.0"
			}
			},
	"description": "Second imported example package",		"description": "Second imported example package",
	"content-data": {		"content-data": {
	"ietf-yang-package:yang-package": {		"ietf-yang-package:yang-package": {
	"name": "example-import-2",		"name": "example-import-2",
	"version": "2.0.0",		"version": "2.0.0",
	"reference": "XXX, draft-rwilton-netmod-yang-packages",		"reference": "XXX, draft-rwilton-netmod-yang-packages",
	"revision-date": "2018-11-26",		"revision-date": "2018-11-26",
	"module": [		"module": [
	{		{
	"name": "example-module-A",		"name": "example-module-A",
	"version": "1.2.3"		"revision": "1.2.3"
	},		},
	{		{
	"name": "example-module-E",		"name": "example-module-E",
	"version": "1.1.0"		"revision": "1.1.0"
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "example-types-module-C",		"name": "example-types-module-C",
	"revision": "2018-11-26"		"revision": "2018-11-26"
	},		},
	{		{
	"name": "example-types-module-D",		"name": "example-types-module-D",
	"revision": "2018-11-26"		"revision": "2018-11-26"
	}		}
	]		]
	}		}
	}		}
	}		}
	}		}
	{		{
	"ietf-yang-instance-data:instance-data-set": {		"ietf-yang-instance-data:instance-data-set": {
	"name": "example-3-pkg",		"name": "example-3-pkg",
			"content-schema": {
			"pkg-schema": {
			"name": "ietf-yang-package-defn-pkg",
			"version": "0.1.0"
			}
			},
	"description": "Importing example package",		"description": "Importing example package",
	"content-data": {		"content-data": {
	"ietf-yang-package:yang-package": {		"ietf-yang-package:yang-package": {
	"name": "example-3",		"name": "example-3",
	"version": "1.0.0",		"version": "1.0.0",
	"reference": "XXX, draft-rwilton-netmod-yang-packages",		"reference": "XXX, draft-rwilton-netmod-yang-packages",
	"revision-date": "2018-11-26",		"revision-date": "2018-11-26",
	"included-package": [		"included-package": [
	{		{
	"name": "example-import-1",		"name": "example-import-1",
	"version": "1.0.0"		"version": "1.0.0"
	},		},
	{		{
	"name": "example-import-2",		"name": "example-import-2",
	"version": "2.0.0"		"version": "2.0.0"
	}		}
	],		],
	"module": [		"module": [
	{		{
	"name": "example-module-A",		"name": "example-module-A",
	"version": "1.2.3"		"revision": "1.2.3"
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "example-types-module-C",		"name": "example-types-module-C",
	"revision": "2018-11-26",		"revision": "2018-11-26",
	"replaces-revision": [ "2018-01-01 "]		"replaces-revision": [ "2018-01-01 "]
	}		}
	]		]
	}		}
	skipping to change at page 53, line 11 ¶		skipping to change at page 52, line 25 ¶
	problem), or for the module tag information to be hosted elsewhere,		problem), or for the module tag information to be hosted elsewhere,
	perhaps in a centralize YANG Catalog, or in instance data files		perhaps in a centralize YANG Catalog, or in instance data files
	similar to how YANG packages have been defined in this draft.		similar to how YANG packages have been defined in this draft.
	One of the principle aims of YANG packages is to be a versioned		One of the principle aims of YANG packages is to be a versioned
	object that defines a precise set of YANG modules versions that work		object that defines a precise set of YANG modules versions that work
	together. Module tags cannot meet this aim without an explosion of		together. Module tags cannot meet this aim without an explosion of
	module tags definitions (i.e. a separate module tag must be defined		module tags definitions (i.e. a separate module tag must be defined
	for each package version).		for each package version).
	Module tags cannot support the hierachical scheme to construct YANG		Module tags cannot support the hierachical scheme to construct schema
	schema that is proposed in this draft.		that is proposed in this draft.
	B.2. Using YANG library		B.2. Using YANG library
	Another question is whether it is necessary to define new YANG		Another question is whether it is necessary to define new YANG
	modules to define YANG packages, and whether YANG library could just		modules to define YANG packages, and whether YANG library could just
	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. YANG		construct/check the entire schema for each datastore. 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. 208 change blocks.
	381 lines changed or deleted		308 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/