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/