YANG Packages
draft-ietf-netmod-yang-packages-09
| Document | Type | Active Internet-Draft (netmod WG) | |
|---|---|---|---|
| Authors | Robert Wilton , Reshad Rahman , Joe Clarke , Jason Sterne | ||
| Last updated | 2026-07-06 | ||
| Replaces | draft-rwilton-netmod-yang-packages | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 1 errors, 0 warnings | ||
| Additional resources |
yang-packages directory
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-netmod-yang-packages-09
Network Working Group R. Wilton, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. Rahman
Expires: 7 January 2027 Equinix
J. Clarke
Cisco Systems, Inc.
J. Sterne
Nokia
6 July 2026
YANG Packages
draft-ietf-netmod-yang-packages-09
Abstract
This document defines YANG packages: versioned organizational
structures used to manage the schema and conformance of a set of YANG
modules as a cohesive unit.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wilton, et al. Expires 7 January 2027 [Page 1]
Internet-Draft YANG Packages July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Main Objectives . . . . . . . . . . . . . . . . . . . . . 4
1.2. Potential Alternative Mechanisms . . . . . . . . . . . . 5
1.3. Open Questions/Issues . . . . . . . . . . . . . . . . . . 6
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
3. The YANG Package Definition . . . . . . . . . . . . . . . . . 8
3.1. Package definition rules . . . . . . . . . . . . . . . . 10
3.2. Package dependencies . . . . . . . . . . . . . . . . . . 11
3.3. Schema referential completeness . . . . . . . . . . . . . 12
3.4. Submodule package considerations . . . . . . . . . . . . 12
3.5. Package Mount Points . . . . . . . . . . . . . . . . . . 12
3.6. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 13
4. Package Resolution . . . . . . . . . . . . . . . . . . . . . 13
4.1. Automatic Module Version Resolution . . . . . . . . . . . 16
5. YANG Package Usage . . . . . . . . . . . . . . . . . . . . . 17
5.1. Achieving package name uniqueness . . . . . . . . . . . . 18
5.2. Specifying modules as implemented or import-only . . . . 18
5.3. Referential completeness and YANG packages . . . . . . . 19
5.4. Providing Package Definitions on a Server . . . . . . . . 19
5.4.1. Package List . . . . . . . . . . . . . . . . . . . . 20
5.4.2. Tree diagram . . . . . . . . . . . . . . . . . . . . 20
5.4.3. YANG Library Package Bindings . . . . . . . . . . . . 20
5.5. Package Instance Data Files . . . . . . . . . . . . . . . 21
5.6. YANG packages as schema for YANG instance data
document . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Package Evolution and Versioning . . . . . . . . . . . . . . 25
6.1. Package versioning . . . . . . . . . . . . . . . . . . . 25
6.1.1. Updating a package with a new version . . . . . . . . 26
6.1.1.1. Non-Backwards-compatible changes . . . . . . . . 26
6.1.1.2. Backwards-compatible changes . . . . . . . . . . 27
6.1.1.3. Editorial changes . . . . . . . . . . . . . . . . 28
6.1.2. Guidelines for Package Versions During Package
Development . . . . . . . . . . . . . . . . . . . . . 28
7. Package Conformance . . . . . . . . . . . . . . . . . . . . . 28
7.1. Resolving conflicting module versions in included
packages . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Handling multiple included package versions . . . . . . . 29
Wilton, et al. Expires 7 January 2027 [Page 2]
Internet-Draft YANG Packages July 2026
7.3. Exclusions and Deviations . . . . . . . . . . . . . . . . 30
7.4. Use of features in YANG modules and YANG packages . . . . 30
7.5. Use of YANG semantic versioning for YANG packages . . . . 31
7.6. Restrictions on the use of deviations in YANG packages . 31
7.7. The relationship between packages and datastores . . . . 32
7.8. Using package comparison tools . . . . . . . . . . . . . 33
8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. ietf-yang-package-types . . . . . . . . . . . . . . . . . 34
8.2. ietf-yang-package-instance . . . . . . . . . . . . . . . 47
8.3. ietf-yang-package . . . . . . . . . . . . . . . . . . . . 49
8.4. ietf-yl-packages . . . . . . . . . . . . . . . . . . . . 52
8.5. ietf-yang-inst-data-pkg . . . . . . . . . . . . . . . . . 55
9. YANG Package Instance Data Schema . . . . . . . . . . . . . . 58
10. Security Considerations . . . . . . . . . . . . . . . . . . . 60
10.1. YANG Module Security Considerations . . . . . . . . . . 60
11. Operational Considerations . . . . . . . . . . . . . . . . . 61
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
12.1. IANA YANG Module and Namespace Registrations . . . . . . 62
12.2. IETF YANG Package Registry . . . . . . . . . . . . . . . 63
12.3. Media Type Registration for application/ypkg . . . . . . 64
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . 67
Appendix A. Package Examples . . . . . . . . . . . . . . . . . . 68
A.1. Basic Package Examples . . . . . . . . . . . . . . . . . 68
A.1.1. Example Basic Types YANG package, version 1.0.0 . . . 69
A.1.2. Example Basic Types YANG package, version 1.1.0 . . . 70
A.1.3. Example Network Device YANG package . . . . . . . . . 72
A.1.4. Example Routing Types YANG package . . . . . . . . . 74
A.1.5. Example Basic Routing YANG package . . . . . . . . . 76
A.2. Device Implementation Examples . . . . . . . . . . . . . 79
A.2.1. device-routing YANG package . . . . . . . . . . . . . 79
A.2.2. YANG library advertisement for device-routing . . . . 81
A.2.3. Hotfix Package Example . . . . . . . . . . . . . . . 83
A.3. Package Versioning Examples . . . . . . . . . . . . . . . 86
A.3.1. Initial Package Version . . . . . . . . . . . . . . . 87
A.3.2. Backwards-compatible Update . . . . . . . . . . . . . 87
A.3.3. Package Downref and Module Removal . . . . . . . . . 89
A.3.4. Adding a Deviations Module . . . . . . . . . . . . . 91
A.3.5. Mixed Backwards-compatible and NBC Changes . . . . . 93
A.3.6. Editorial Location Update . . . . . . . . . . . . . . 94
A.4. Package Resolution Examples . . . . . . . . . . . . . . . 95
A.4.1. Recursive Package Resolution . . . . . . . . . . . . 96
A.4.2. Local Entries and Exclusions . . . . . . . . . . . . 103
A.5. Package Exclusion Examples . . . . . . . . . . . . . . . 105
A.5.1. Example of excluding modules and an enabled
feature . . . . . . . . . . . . . . . . . . . . . . . 106
Wilton, et al. Expires 7 January 2027 [Page 3]
Internet-Draft YANG Packages July 2026
A.6. Mounted Package Examples . . . . . . . . . . . . . . . . 110
A.6.1. Example of package with a mounted package . . . . . . 110
A.6.2. Example of a package replacing the mounted schema . . 110
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110
1. Introduction
This document defines and describes the YANG [RFC7950] constructs
that are used to define and use YANG packages.
A YANG package is a versioned hierarchical organizational structure
used to manage a set of YANG modules that collectively define a
package schema. For example, a YANG package could define the set of
YANG modules required to implement an L2VPN service on a network
device.
YANG packages can be:
exported from a server,
resolved into a YANG schema,
augmented into YANG library [RFC8525],
accessed as instance data files [RFC9195], with a dedicated .ypkg
file suffix,
used to define the schema of data in instance data files,
and used by tooling to compare and manage YANG schema.
Examples of YANG packages are provided in the appendices.
1.1. Main Objectives
The main goals of YANG package definitions include, but are not
restricted to:
* Providing an alternative, simplified, YANG conformance mechanism.
Rather than conformance being performed against a set of
individual YANG module revisions, features, and deviations,
conformance can be more simply stated in terms of YANG packages,
with a set of modifications (e.g. additional modules, deviations,
or features).
* Allowing datastore schema to be specified concisely rather than
having each server explicitly list all modules, deviations, and
features. YANG package definitions can be defined in documents
Wilton, et al. Expires 7 January 2027 [Page 4]
Internet-Draft YANG Packages July 2026
that are available offline, and may be accessible via a URL rather
than requiring explicit lists of modules to be shared between
client and server. Hence, a YANG package must contain sufficient
information to allow a client or server to precisely construct the
schema associated with the package.
* YANG packages should be able to represent the equivalent structure
as YANG library, but making use of a hierarchical resolution
mechanism.
* YANG packages should be flexible enough to provide usable
definitions representing collections of IETF YANG modules,
OpenConfig YANG modules, and other bespoke sets of YANG modules,
e.g., covering sets of vendor native YANG models.
* YANG packages should be flexible enough to represent the
conformance and server implementations of standard or industry
defined YANG package definitions. E.g., it should be possible for
a server implementation to indicate that it does not faithfully
implement a package schema, e.g., by excluding modules,
implementing different module versions/revisions, and/or having
deviations applied.
* Tooling should be able to easily work with YANG package
definitions to compare YANG package versions and to compare server
conformance against expected package definitions.
Protocol mechanisms of how clients can negotiate which YANG packages
or YANG package versions are to be used for NETCONF/RESTCONF
communications are outside the scope of this document. One potential
mechanism is defined in [I-D.ietf-netmod-yang-ver-selection].
Finally, the package definitions proposed by this document are
intended to be relatively basic in their definition and the
functionality that they support. As the industry gains experience
using YANG packages, the standard YANG mechanisms of updating, or
augmenting YANG modules could also be used to extend the
functionality supported by YANG packages, if required.
1.2. Potential Alternative Mechanisms
There are several alternative approaches to managing YANG schema.
These include:
* Using YANG library, along with YANG Instance Data files [RFC9195],
* Using git tags and version labels for modules maintained on
GitHub,
Wilton, et al. Expires 7 January 2027 [Page 5]
Internet-Draft YANG Packages July 2026
* As collections of YANG modules in a zip file or at a directory
folder. E.g., at time of publication, this method is used to
represent the set of YANG modules associated with a particular
vendor release at the GitHub repository at
https://github.com/YangModels/yang
Although these methods are quite simple, there are some disadvantages
with various aspects of these methods: They are verbose, they don't
advertise supported features or support mounts, and they can be
awkward to compare, particularly if YANG modules haven't been
versioned correctly.
1.3. Open Questions/Issues
RFC Editor, please remove this section before publication.
All issues, along with the draft text, are currently being tracked at
https://github.com/rgwilton/YANG-Packages-Draft/issues/
2. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the following terminology introduced in YANG
Semantic Versioning [I-D.ietf-netmod-yang-semver]:
* YANG Semver
This document uses the following terminology introduced in the
Network Management Datastore Architecture [RFC8342]:
* datastore schema
This document uses the following terminology introduced in the YANG
1.1 Data Modeling Language [RFC7950]:
* data node
* schema node
Tree diagrams used in this document follow the notation defined in
[RFC8340].
In addition, this document defines the following terminology:
Wilton, et al. Expires 7 January 2027 [Page 6]
Internet-Draft YANG Packages July 2026
* version (module): In the context of a YANG module, it is used as
shorthand to reference a particular revision of a YANG module,
potentially identified by a YANG Semver version label or a
revision-date.
* version (package): In the context of a YANG package, it refers to
a particular version of a YANG package definition, identified by
the package version field.
* YANG schema: The combined set of schema nodes for a set of modules
taking into account implemented modules, import-only modules,
deviations, features and mount-points. A more complete definition
is provided in Section 4.
* YANG package: The versioned organizational structure defined in
Section 3. Depending on context, the term 'YANG package' is often
used to refer to a specific version of a YANG package rather than
all versions of a package definition.
* package: An alternative term for 'YANG package'.
* backwards-compatible (BC) change: When used in the context of a
YANG module, it follows the definition in Section 3.1.1 of
[I-D.ietf-netmod-yang-module-versioning]. When used in the
context of a YANG package, it follows the definition in
Section 6.1.1.2.
* non-backwards-compatible (NBC) change: When used in the context 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
context of a YANG package, it follows the definition in
Section 6.1.1.1.
* editorial change: When used in the context of a YANG module, it
follows the definition of an 'editorial change' in 4.4 of
[I-D.ietf-netmod-yang-semver]. When used in the context of a YANG
package, it follows the definition in Section 6.1.1.3.
* resolved package schema: The resolved package schema is the YANG
schema defined by a package after package resolution has been
performed, as defined in Section 4. The resolved package schema
identifies the implemented modules (with any deviations applied),
import-only modules, enabled features, and schema mount points.
* package schema: An alternative term for 'resolved package schema'.
Wilton, et al. Expires 7 January 2027 [Page 7]
Internet-Draft YANG Packages July 2026
* enabled feature: A YANG module feature that a resolved package
schema identifies as mandatory to enable for all implementations
that conform to the package definition.
3. The YANG Package Definition
A YANG package is a versioned hierarchical organizational structure
used to manage a set of YANG modules that collectively define a
package schema.
Each YANG package defines:
* YANG package meta-data, such as "name", "version", "organization",
"description", "complete" flag, etc.
* An "includes" container holding a list of included packages. It
also contains lists of any implemented modules and import-only
modules that are used in addition to, or with different version
to, the modules defined in the included packages. Finally, it
lists enabled features in addition to those defined in included
packages.
* An "excludes" container comprising modules and features that are
included via the resolved packages of entries in the "includes/
package" list, but that are excluded from this package definition.
It is not possible to exclude packages.
* Lists of YANG packages that will be found at particular mount
points by any server implementing this package, used in
conjunction with mount points defined by any included packages.
The ietf-yang-package-types.yang module defines a grouping to specify
the core elements of the YANG package structure that is used within
YANG package instance data files (ietf-yang-package-instance.yang)
and also on the server (ietf-yang-packages.yang).
The "yang-pkg-instance" grouping in the "ietf-yang-package-types"
YANG module has the following structure:
module: ietf-yang-package-types
grouping yang-pkg-instance:
+-- name pkg-name
+-- version pkg-version
+-- version-description? string
+-- timestamp? yang:date-and-time
+-- organization? string
+-- contact? string
Wilton, et al. Expires 7 January 2027 [Page 8]
Internet-Draft YANG Packages July 2026
+-- description? string
+-- reference? string
+-- complete? boolean
+-- includes
| +-- package* [name version]
| | +-- name pkg-name
| | +-- version pkg-version
| | +-- location* inet:uri
| +-- module* [name]
| | +-- name module-name
| | +-- version version-or-rev-date
| | +-- location* inet:uri
| | +-- submodule* [name]
| | +-- name module-name
| | +-- version version-or-rev-date
| | +-- location* inet:uri
| +-- import-only-module* [name version]
| | +-- name module-name
| | +-- version version-or-rev-date
| | +-- location* inet:uri
| | +-- submodule* [name]
| | +-- name module-name
| | +-- version version-or-rev-date
| | +-- location* inet:uri
| +-- feature* scoped-feature
+-- excludes
| +-- module* module-name
| +-- import-only-module* [name]
| | +-- name module-name
| | +-- version* version-or-rev-date
| +-- feature* scoped-feature
+-- depends-on
| +-- package* [name version]
| +-- name pkg-name
| +-- version pkg-version
| +-- location* inet:uri
+-- mount* [mount-path]
+-- mount-path mount-ypath
+-- inherit-packages? boolean
+-- package* [name version]
| +-- name pkg-name
| +-- version pkg-version
| +-- location* inet:uri
+-- additional-feature* scoped-feature
+-- parent-reference* mount-ypath
Wilton, et al. Expires 7 January 2027 [Page 9]
Internet-Draft YANG Packages July 2026
3.1. Package definition rules
For a YANG package to be valid, it MUST conform to all the following
rules:
1. Each (package name, version) pairing MUST define a globally
unique version of that package definition.
2. Each YANG package name MUST be globally unique to avoid issues
with tools and caching, e.g., using the mechanisms specified in
Section 5.1.
3. YANG packages MUST be versioned using YANG Semver,
[I-D.ietf-netmod-yang-semver]. Versioning YANG packages is
further described in Section 6.1.
4. A YANG package MAY represent a referentially complete set of
modules or MAY represent a set of modules with some module
import dependencies missing, as described in Section 3.3.
5. Package definitions are hierarchical because a package can
include other packages. There MUST NOT be any circular package
include dependencies, i.e., packages cannot, directly or
indirectly, include themselves.
6. A package definition MAY directly include multiple versions of
the same package in the "includes/package" list, but normally
only a single package version is expected. Multiple package
versions can be listed, for example, to update location
information for package versions included through other
packages.
7. If the same package version, module version, import-only module
version, or submodule version is referenced via multiple
included packages, then the referenced content and metadata are
expected to be equivalent. Location information MAY differ and
is merged as defined by the package resolution rules in
Section 4.
8. A package definition MUST NOT list the same package version
under both the 'includes/package' and 'depends-on/package'
lists.
9. When a location leaf-list is provided for a package, implemented
module, import-only module, or submodule, the first entry MUST
be the canonical location used to retrieve that package, module,
import-only module, or submodule.
Wilton, et al. Expires 7 January 2027 [Page 10]
Internet-Draft YANG Packages July 2026
10. For each module implemented by a package, only a single version/
revision of that module MUST be implemented. Conflicting module
versions (e.g. from package includes) MAY be resolved explicitly
(via "includes/module") or using automatic module version
resolution, as described in Section 4.1.
11. Multiple versions/revisions of an import-only module MAY be
listed, but any extraneous import-only module versions SHOULD be
removed.
12. A package definition MUST NOT include the same module name in
both the 'includes/module' and 'excludes/module' lists.
13. A package definition MUST NOT include and exclude the same
import-only module version. If an 'excludes/import-only-module'
entry does not list any versions, then it excludes all versions
of that import-only module and MUST NOT be used with any
'includes/import-only-module' entry for the same module name.
14. A package definition MUST NOT include the same feature name in
both the 'includes/feature' and 'excludes/feature' lists.
15. A package definition MUST NOT exclude a module and list features
defined by that module in the 'includes/feature' list.
16. A package definition MAY include redundant information, e.g.,
including a module or package version that is already present by
an included package, or excluding a module that is not included
by any included package. However, such redundant information
might be confusing to readers. Although the resolved package
schema is unambiguous, it is best to minimize redundant
information where possible.
17. Finally, standard rules for YANG instance data apply. E.g.,
entries in the various lists MUST be unique by any list key.
3.2. Package dependencies
The "depends-on/package" list can identify other packages that a
package depends on, but that are not included as part of the package
definition, and hence do not form part of the resolved package
schema.
The main anticipated use is for referentially incomplete packages,
where the dependencies identify packages that are expected to be
resolved along with the incomplete package. The same mechanism can
also be used by a referentially complete package to provide
additional machine-readable dependency metadata.
Wilton, et al. Expires 7 January 2027 [Page 11]
Internet-Draft YANG Packages July 2026
3.3. Schema referential completeness
A YANG package may represent a schema that is 'referentially
complete', or 'referentially incomplete', indicated in the package
definition by the 'complete' flag.
If all import statements in all YANG modules included in the package
(either directly, or through included packages) can be resolved to a
module version defined with the YANG package definition, then the
package is classified as being referentially complete. Conversely,
if one or more import statements cannot be resolved to a module
specified as part of the package definition, then the package is
classified as being referentially incomplete.
If the packages needed to resolve a referentially incomplete package
definition are known, and can be expressed without excessive
complexity, then the package definition SHOULD include "depends-on/
package" entries to help a client resolve a complete schema in a
machine-readable way. The server MAY provide the additional schema
information in another way, e.g., via user documentation, or if the
dependencies are more complex.
Also see Section 5.3 for details on cases when referentially
incomplete packages are helpful.
3.4. Submodule package considerations
As defined in [RFC7950] and [I-D.ietf-netmod-yang-semver], YANG
conformance and versioning is specified in terms of particular
versions of YANG modules rather than for individual submodules.
However, YANG package definitions also include the list of submodules
included by a module, primarily to provide user-ordered locations
where each submodule definition can be obtained from. If multiple
locations are provided, the canonical location of where the submodule
definition can be obtained SHOULD be listed first.
3.5. Package Mount Points
YANG Schema Mount [RFC8528] defines a mechanism for YANG modules to
be mounted at specific mount points in the schema tree. This
mechanism is required to instantiate the full schema for some common
networking use cases, e.g., [RFC8529] defines a YANG Model for
Network Instances, that uses YANG mount points to mount IETF routing
protocol YANG modules within the network instance list.
Wilton, et al. Expires 7 January 2027 [Page 12]
Internet-Draft YANG Packages July 2026
[RFC8528] declares that it provides support for mounted schema at
"Implementation time" and "Run time", but does not cover mounting
schema at "Design time". YANG package definitions do not give YANG
language level "Design time" guarantees, but they are able to give a
stronger "Implementation time" guarantee through the use of offline
YANG package definitions. They can also be used to report "Run time"
mounted schema behavior, if the server is able to report the packages
implemented by the device.
Each YANG package definition defines the package schema, additional
features, and parent-references found at a particular mount point,
via two mechanisms:
* Mounted packages, additional features, and parent-references that
are exported from any included packages are also exported at the
same mount point for this specific package, unless package
inheritance is explicitly disabled by a 'mount' list entry for the
same mount point with 'inherit-packages' set to 'false'.
* A package definition can add mounted packages, additional
features, and parent-references to a mount point by listing them
in the 'mount' list entry. These entries are additive, like
entries in the 'includes/package' list. If the same package name
is listed with a different version, then both package versions are
retained. I.e., a package definition can remove inherited mounted
packages, modules, enabled features, or parent-references only by
setting 'inherit-packages' to 'false' and explicitly listing the
packages, features, and parent-references that define the complete
mounted schema. Examples of this are given in Appendix A.6.2.
If a server implements the YANG library package bindings defined in
Section 5.4.3 for a mounted schema, then the YANG library data
provided at the mount point MUST include the 'package' list, and any
applicable 'additional-feature' leaf-list entries, defined by the
"ietf-yl-packages" module, Section 5.4.3.
3.6. Exclusions
A package definition may exclude modules or enabled features. The
mechanism for this is described in Section 4, and the conformance
implications are described in Section 7.
4. Package Resolution
Package resolution is the process of taking a YANG package definition
and converting it to a specification for a YANG schema, e.g., as may
be implemented by a device for a particular datastore. A YANG schema
can be thought of as comprising:
Wilton, et al. Expires 7 January 2027 [Page 13]
Internet-Draft YANG Packages July 2026
A set of implemented modules at specific versions,
A set of import-only modules, potentially with multiple versions
of a given module,
A set of enabled features,
A set of mount points, each with its own YANG schema,
that can be collectively compiled into a YANG schema tree.
The YANG schema generated by a package definition can be converted
into an equivalent instance in YANG library [RFC8525], with Schema
Mount [RFC8528] if mount points are used. E.g., see Section 5.4.3.
The following process defines how a YANG package definition is
resolved, using two explicit steps:
1. Step 1: recursively resolve each package in the "includes/
package" list using this same two-step process.
2. Step 2: merge the resolved package schemas from those included
packages with the local entries defined directly by this package.
The local entries are the contents of the "includes", "excludes",
and "mount" containers in this package. The merge is performed
using the following rules:
* included-packages: The set of included package references is
the union of all included package references in the resolved
included packages, then overwritten, including location
information, by any entries in the local "includes/package"
list with the same package name and version. Location leaf-
lists for duplicate inherited package references are merged
using the location-lists rule.
* implemented-modules: The set of implemented modules is the
union of all implemented modules in the resolved included
packages. Conflicting module versions can be resolved
automatically as per Section 4.1, then overwritten (including
submodule and location information) by any entries in the
"includes/module" list, and finally filtered by any entries in
"excludes/module" list. Location leaf-lists for duplicate
inherited module references are merged using the location-
lists rule.
* import-only-modules: The set of import-only modules is the
union of all import-only modules in the resolved included
packages. Location leaf-lists for duplicate inherited import-
Wilton, et al. Expires 7 January 2027 [Page 14]
Internet-Draft YANG Packages July 2026
only module references are merged using the location-lists
rule. The set is then overwritten (including submodule and
location information) by any entries in the "includes/import-
only-module" list with the same module name and version, and
finally filtered by any entries in the "excludes/import-only-
module" list.
* enabled-features: The set of enabled features is the union of
the enabled features from the resolved included packages, with
any "includes/feature" entries added, and any "excludes/
feature" entries removed. If a module is excluded by
"excludes/module" then all features associated with that
module are also implicitly removed.
* mounts: The set of mounts is the union of the mounts in the
resolved included packages, where for a given mount-path that
is present in more than one included package (exact same path
and bound list keys) then it takes the union of the mounted
packages, "mount/additional-feature" entries, and mount
parent-references. The mounts are then updated by processing
any entries in the package's "mount" list. If "inherit-
packages" is true, or absent, the local "mount/package",
"mount/additional-feature", and "mount/parent-reference"
entries are added to the inherited mounted schema for that
mount point. If the same package version is present in both
the inherited and local "mount/package" entries, then the
local entry overwrites the inherited entry, including location
information. If the same package name is present with
different package versions, then all package versions are
retained. If "inherit-packages" is false, the inherited
mounted packages, additional features, and parent-references
for that mount point are discarded, and the local "mount"
entry defines the mounted schema for that mount point.
* submodules: Submodules are ignored for resolution purposes,
only the module version is considered and compared. For
duplicate inherited references to the same submodule version,
location leaf-lists are merged using the location-lists rule.
* location-lists: This rule applies when duplicate inherited
package, module, import-only module, or submodule references
identify the same version but have different location leaf-
list values. The referenced content and metadata are expected
to be equivalent. The location leaf-lists are merged pairwise
in the order that the included package entries are listed.
For each pairwise merge, values from the second location leaf-
list are appended to the first location leaf-list, except that
values already present in the first location leaf-list are
Wilton, et al. Expires 7 January 2027 [Page 15]
Internet-Draft YANG Packages July 2026
ignored. Hence, the first occurrence of each location is
retained and the relative order of non-duplicate locations is
preserved.
4.1. Automatic Module Version Resolution
A resolved package schema can only include a single version of a
module, and hence when conflicting module versions arise from
included packages that resolve to different versions of a given
module then a single version has to be chosen. The following rules
are used, in the order given, to automatically select the chosen
version by performing a pairwise comparison of the module versions
from the resolved included packages, by comparing the version leaves:
1. If both version leaves match the YANG Semver format, then they
are compared using only the MAJOR, MINOR, and PATCH version
components, as described in Section 4.3 of
[I-D.ietf-netmod-yang-semver] and Section 4.4 of
[I-D.ietf-netmod-yang-semver]. Any "_compatible" or
"_non_compatible" modifier, pre-release metadata, and build
metadata are ignored for this comparison:
i The module with the highest MAJOR version component is
chosen.
ii Otherwise, if the MAJOR version components are the same,
then the module with the highest MINOR version component is
chosen.
iii Otherwise, the module with the highest PATCH version
component is chosen.
2. If one module has a version statement that matches the YANG
Semver format but the other does not, then the module with the
version statement matching the YANG Semver format is chosen.
3. If neither module has a version statement that matches the YANG
Semver format, then the module with the most recent revision-date
is chosen.
4. If there is no difference in version or revision-dates to
distinguish between two modules then:
i Submodule information, if present, for both module
definitions is assumed to be equivalent and hence either can
be used.
Wilton, et al. Expires 7 January 2027 [Page 16]
Internet-Draft YANG Packages July 2026
ii the location leaf-lists for the module definitions are merged
using the location-lists rule.
5. YANG Package Usage
This section provides information and guidance on how YANG packages
can be used.
YANG packages can be defined and used for different purposes:
* By standards development organizations and industry organizations
- to specify common sets of YANG data models that can be used
together to manage network devices, or even just particular
functionality on network devices (e.g., L3VPN services). Since
package definitions can be defined hierarchically, packages
defining different functionalities can be combined into larger
package definitions that define more complex and complete behavior
and YANG schema. These package definitions may be published by
the organizations as package files.
* For devices:
- to describe the YANG schema associated with the device or a
datastore schema on the device. These package schemas can be
made available both from the device and also in offline package
files.
- to define different optional YANG schemas that can be used by
the device and where clients can select which YANG schema can
be used via configuration.
- to refine standards based and industry packages to accurately
report how the device does not fully conform to the package
schema definition.
* To manage and report the schema available at YANG schema mounts
points.
It is RECOMMENDED that organizations publishing YANG modules also
publish YANG package definition that group and version those modules
into units of related functionality. This increases interoperability
by encouraging different implementations to coalesce around use the
same collections of YANG modules versions. Using packages also makes
it easier to understand relationship between modules, and enables
functionality to be described on a more abstract level than
individual modules.
Wilton, et al. Expires 7 January 2027 [Page 17]
Internet-Draft YANG Packages July 2026
Where possible, package definitions SHOULD be made available offline
in Package Instance Data files, see Section 5.5, but also on the
device as a list of known packages and relationships between YANG
library datastore schema and equivalent YANG package definitions,
e.g., see Section 5.4.
5.1. Achieving package name uniqueness
As per Section 3.1, YANG package names are globally unique, since two
different package definitions with the same name, but different
content, cannot both be used together within the same package
definition.
There are a couple of ways of achieving this uniqueness requirement:
* For package definitions that define a public API, or that could
apply to multiple servers exposing the same management API, then
an organization prefix, and perhaps device family name, should be
included in the package name, i.e., following a similar naming
convention as for modules.
* For package definitions that are entirely local to a particular
server or device, then the sysName of the device, a MAC address,
or a UUID should be used as a suffix to the package name to ensure
uniqueness.
5.2. Specifying modules as implemented or import-only
Some YANG modules do not define any implementable data nodes, RPCs,
Actions, or Notifications. These YANG modules often may include
'types' in the name of the YANG Module. For YANG package
definitions, there is a choice whether to include these types modules
in the packages list of implemented modules, or as import-only
modules. This document does not specify how these should be
declared, but instead gives some points of consideration that may be
helpful when choosing. These are:
Listing a "types-only" module as implemented allows for simpler
automatic module version selection between different packages, as
per Section 4.1.
As per [RFC7950] section 9.10.2, identities are only available for
use by the server for implemented modules.
Wilton, et al. Expires 7 January 2027 [Page 18]
Internet-Draft YANG Packages July 2026
If a module defines data nodes and types and the server only wants
to use the types but not implement any data nodes from the module
then listing the module as import-only is clearer and simpler than
marking it as implemented with a separate deviation file that
deviates all data nodes as not-supported.
If a module imports a module at an exact revision (which, as per
[I-D.ietf-netmod-yang-module-versioning], is not recommended) then
it may be helpful to list that module in the import-only module
list (even if implemented) to ensure that the import dependency is
always satisfied.
5.3. Referential completeness and YANG packages
Referentially incomplete packages can be used, along with locally
scoped packages, to represent an update to a device's datastore
schema as part of an optional software hot fix. E.g., the base
software is made available as a complete globally scoped package.
The hot fix is made available as an incomplete globally scoped
package. A device's datastore schema can define a local package that
implements the base software package updated with the hot fix
package. An example is provided in Appendix A.2.3.
An incomplete package, e.g., a hot fix package, can provide "depends-
on/package" entries to identify the package versions that the
incomplete package is intended to be used with.
Referentially incomplete packages could also be used to group sets of
logically related modules together, but without requiring a fixed
dependency on all imported 'types' modules (e.g., iana-if-
types.yang), instead leaving the choice of specific versions of
'types' modules to be resolved when the package definition is used.
5.4. Providing Package Definitions on a Server
A client discovers the package definitions for a datastore schema by
first retrieving YANG Library. For each YANG Library schema entry,
the augmented 'package' list, if present, identifies the top-level
package name/version pairs that define that datastore schema. Those
package references identify entries in the server's top-level
'/packages/package' list. A client can use the package definition
advertised by the server, retrieve a package instance data file from
one of the advertised 'location' URIs, or use a cached package
instance data file for the same package name and version. The client
then resolves the listed packages, together with any 'additional-
feature' entries to construct the complete datastore schema, as
described in Section 5.4.3.
Wilton, et al. Expires 7 January 2027 [Page 19]
Internet-Draft YANG Packages July 2026
5.4.1. Package List
A top level 'packages' container holds the list of all versions of
all packages known to the server. Entries in this list do not
necessarily mean that the package is implemented by the server or
currently active for any datastore. Instead, the YANG Library
package bindings in Section 5.4.3 are used to indicate which of the
advertised packages are supported by each datastore schema.
The '/packages/package' list MAY include multiple versions of a
particular package. E.g. if the server is capable of allowing
clients to select which package versions should be used by the
server, or if package versions have been changed via applying
different software packages or hot fixes.
5.4.2. Tree diagram
The "ietf-yang-packages" YANG module has the following structure:
module: ietf-yang-packages
+--ro packages
+--ro package* [name version]
// Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang.
+--ro name pkg-name
+--ro version pkg-version
... remainder of yang-package-instance grouping ...
5.4.3. YANG Library Package Bindings
The ietf-yl-packages module augments YANG library to provide a
concise alternative approach of using hierarchical packages to define
datastore schema compared to constructing the schema using a union of
more verbose module definitions defined in module-sets.
Since packages can be made available offline in instance data files,
and cached, it may be sufficient for a client to only fetch the
names/versions of the top level packages, along with the list of
additional-feature entries to construct the full datastore schema.
If multiple packages are listed for a datastore schema then they are
resolved as if the packages were all directly included in a single
package definition, including all additional-feature entries, and
following the standard package resolution rules in Section 4.
This means that conflicting module versions between the listed
packages are resolved using the automatic module version resolution
rules in Section 4.1. As a result, the version that wins those rules
Wilton, et al. Expires 7 January 2027 [Page 20]
Internet-Draft YANG Packages July 2026
is selected in the resolved package schema. This allows an extra
'hot fix' package to be added to the list of packages defining a
schema to provide a later module version, but it cannot be used to
select an older module version. Instead, a package that explicitly
includes and refines the referenced packages would need to be defined
to select the older module version (see Section 7.1).
If populated, the set of packages listed for a datastore schema
combined with the leaf-list of additional-feature entries MUST
resolve to a schema that exactly matches the schema defined by the
YANG library 'schema/module-set' leaf-list, and the resolved package
schema MUST be referentially complete.
Since these nodes augment into YANG library, then as per [RFC8525],
the "/yang-library/content-id" leaf is updated if the packages or
additional-feature entries change.
The "ietf-yl-packages" YANG module has the following structure:
module: ietf-yl-packages
augment /yanglib:yang-library/yanglib:schema:
+--ro package* [name version]
| +--ro name -> /pkgs:packages/package/name
| +--ro version leafref
| +--ro location* inet:uri
+--ro additional-feature* pkg-types:scoped-feature
5.5. Package Instance Data Files
YANG packages SHOULD be made available offline from the server,
defined as YANG instance data files [RFC9195] using the schema below
to define the package data.
Package instance data files MUST use the ".ypkg" file extension and
the "application/ypkg" media type as defined in Section 12.3.
The following rules apply to the format of the YANG package instance
files:
1. The file MUST be encoded in JSON.
2. The name of the file MUST follow the format "<package-
name>@<version>.ypkg", and the package-name and version MUST
match the values specified in the package container's 'name' and
'version' leafs.
Wilton, et al. Expires 7 January 2027 [Page 21]
Internet-Draft YANG Packages July 2026
3. The 'format' version leaf for in the instance-data-set for .ypkg
files MUST NOT be set if it uses the default value of
"2022-01-20" but MUST be set if a newer revision is used.
4. The 'include-defaults' leaf in the instance-data-set for .ypkg
files MUST NOT be set, but defaults to the 'trim' mode. I.e.,
default values if the YANG package definition MUST NOT be
included in the instance-data-set content-data.
5. The instance-data file can specify a schema:
* The default schema for .ypkg files is "ietf-inst-data-pkg-
schema.ypkg", defined in Section 9. When used, it SHOULD NOT
be specified in the instance-data file.
* If a different, e.g., newer or augmented, schema is used then
it is RECOMMENDED to specify the YANG instance data file
schema using a package definition. E.g., see Section 9 and
Section 5.6.
6. The 'name', 'description', 'timestamp', 'organization', and
'contact' fields are defined both in the instance-data-set meta-
data and the YANG package meta-data. To avoid redundant
information, package definitions MUST only define these fields as
part of the package definition. They MUST be left unset as part
of the instance-data-set meta-data.
7. If the package definition applies only to a specific datastore
then the 'datastore' leaf in the instance-data-set meta-data MUST
be set. If the package definition applies to multiple
datastores, then the 'datastore' leaf MUST NOT be set.
8. The 'revision' list in the instance data file MUST NOT be used,
since versioning is handled by the package definition.
9. The instance data file for each version of a YANG package SHOULD
be made available at one or more locations accessible via URLs.
If one of the listed locations defines the canonical location for
the package definition then it MUST be listed as the first entry
in the user-ordered list, so that it remains first when locations
are merged during package resolution.
Note, the stricter rules for YANG packages in instance data files are
intended to encourage consistency and provide a canonical base file
representation of the package definition.
The "ietf-yang-package-instance" YANG module has the following
structure:
Wilton, et al. Expires 7 January 2027 [Page 22]
Internet-Draft YANG Packages July 2026
module: ietf-yang-package-instance
structure package:
// Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang
+-- name pkg-name
+-- version pkg-version
... remainder of yang-package-instance grouping ...
5.6. YANG packages as schema for YANG instance data document
YANG package definitions can be used to define the content schema for
YANG instance data files, extending the content schema definition in
Section 3.2 of [RFC9195]. When using a package-based content schema,
the package name and version MUST be specified, and one or more
location URLs for retrieving the package definition MAY also be
provided. The resolved package schema provides the exact
specification for the content schema, taking into consideration all
implemented modules, import-only modules, augmentations, enabled
features and any deviations.
The "ietf-yang-inst-data-pkg" YANG module has the following
structure:
module: ietf-yang-inst-data-pkg
augment-structure /yid:instance-data-set/...
+--:(pkg-schema)
+-- pkg-schema
+-- name pkg-name
+-- version pkg-version
+-- location* inet:uri
The following example shows how the example in Section 2.2.3 of
[RFC9195] could alternatively use example-diagnostics-
schema@1.0.0.ypkg to define the content schema for NETCONF monitoring
state data.
Example of YANG instance data file using a schema defined by a YANG
package.
Wilton, et al. Expires 7 January 2027 [Page 23]
Internet-Draft YANG Packages July 2026
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"ietf-yang-instance-data:instance-data-set": {
"name": "example-router-netconf-diagnostics",
"content-schema": {
"pkg-schema": {
"name": "example-diagnostics-schema",
"version": "1.0.0",
"location":
"https://example.org/\
example-diagnostics-schema@1.0.0.ypkg",
}
},
"timestamp": "2018-01-25T17:00:38Z",
"description": ["NETCONF statistics, \
The data may change at any time."],
"content-data": {
"ietf-netconf-monitoring:netconf-state": {
"statistics": {
"netconf-start-time ": "2018-12-05T17:45:00Z",
"in-bad-hellos ": "32",
"in-sessions ": "397",
"dropped-sessions ": "87",
"in-rpcs ": "8711",
"in-bad-rpcs ": "408",
"out-rpc-errors ": "408",
"out-notifications": "39007"
}
}
}
}
}
Example package definition used as the content schema for the NETCONF
monitoring instance data above.
<CODE BEGINS> file "example-diagnostics-schema@1.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-diagnostics-schema",
"version": "1.0.0",
"timestamp": "2018-01-25T17:00:38Z",
"description": "Example schema package for NETCONF \
Wilton, et al. Expires 7 January 2027 [Page 24]
Internet-Draft YANG Packages July 2026
monitoring instance data.",
"reference": "RFC 6022",
"includes": {
"module": [
{
"name": "ietf-netconf-monitoring",
"version": "2010-10-04",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-netconf-monitoring@2010-10-04.yang"
]
}
],
"import-only-module": [
{
"name": "ietf-yang-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-types@2025-12-22.yang"
]
},
{
"name": "ietf-inet-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-inet-types@2025-12-22.yang"
]
}
]
}
}
}
}
}
<CODE ENDS>
6. Package Evolution and Versioning
6.1. Package versioning
As defined in Section 3.1, YANG packages are versioned using
[I-D.ietf-netmod-yang-semver]. This section describes how those
rules apply to YANG package definitions.
Wilton, et al. Expires 7 January 2027 [Page 25]
Internet-Draft YANG Packages July 2026
6.1.1. Updating a package with a new version
Package compatibility is fundamentally defined by how the package
schema between two package versions has changed.
When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below. See section 4.5
of [I-D.ietf-netmod-yang-semver] for guidance on choosing the next
version number based on the type of change being made.
It is important to note that a non-backwards-compatible (NBC) change
to a package definition (generally requiring a major version number
increment) may not always result in an NBC change to the resolved
package schema. For example, if a package replaces a module version
1.0.0 with version 3.0.0, but the content of version 3.0.0 has been
reverted to be functionally identical to version 1.0.0 (effectively
backing out previous changes between the two), the schema difference
between the package versions may be functionally compatible.
Nevertheless, such changes must still follow the versioning rules
defined above based on the package definition changes, not the
effective change to the resolved package schema.
6.1.1.1. Non-Backwards-compatible changes
Non-backwards-compatible changes to a package are those that may
cause the resolved package schema to change in a way that can
negatively impact clients. E.g., the removal or change of a data
node that was present in the previous package version, which may be
used by client applications.
The following changes classify as non-backwards-compatible changes to
a package definition:
* Changing an 'includes/package' list entry to select a package
version that is non-backwards-compatible to the prior package
version, or removing a previously included package.
* Changing an 'includes/module' or 'includes/import-only-module'
list entry to select a module version that is non-backwards-
compatible to the prior module version, or removing a previously
implemented module.
* Adding an entry to the 'excludes/module' list or the 'excludes/
import-only-module' list, which in either case causes a module to
be removed from an included package and could affect the
conformance reporting of whether the included package is deemed as
being implemented.
Wilton, et al. Expires 7 January 2027 [Page 26]
Internet-Draft YANG Packages July 2026
* Removing a feature from the 'includes/feature' list unless the
feature was not enabled by any included packages.
* Adding a feature to the 'excludes/feature' list unless the feature
was not enabled by any included package.
* Adding, changing, or removing a module containing one or more
deviations, that when applied to the target module would create a
change that is considered a non-backwards-compatible change to the
affected data node in the schema associated with the prior package
version.
* Removing a package from a mount point, or changing a mounted
package to a version that is non-backwards-compatible to the prior
package version.
6.1.1.2. Backwards-compatible changes
Backwards-compatible changes to a package are those that may cause
the resolved package schema to change in a way that should not impact
clients. E.g., the addition of a new data node that was not present
in the previous package version.
The following changes classify as backwards-compatible changes to a
package definition:
* Changing an 'includes/package' list entry to select a package
version that is backwards-compatible to the prior package version,
or including a new package that does not conflict with any
existing included package or module.
* Changing an 'includes/module' or 'includes/import-only-module'
list entry to select a module version that is backwards-compatible
to the prior module version, or including a new module to the
package definition.
* Removing an entry from the 'excludes/module' list or the
'excludes/import-only-module' list.
* Adding a feature to the 'includes/feature' leaf-list.
* Removing a feature from the 'excludes/feature' leaf-list.
* Adding, changing, or removing a module containing one or more
deviations, that when applied to the target module would create a
change that is considered a backwards-compatible change to the
affected data node in the schema associated with the prior package
version.
Wilton, et al. Expires 7 January 2027 [Page 27]
Internet-Draft YANG Packages July 2026
6.1.1.3. Editorial changes
Editorial changes to a package are those that do not change the
resolved package schema.
The following changes classify as editorial changes to a package
definition:
* Changing an 'includes/package' list entry to select a package
version that is classified as an editorial change relative to the
prior package version.
* Changing an 'includes/module' or 'includes/import-only-module'
list entry to select a module version that is classified as an
editorial change relative to the prior module version.
* Adding an 'includes/package', 'includes/module', 'includes/import-
only-module', or 'mount/package' list entry if the referenced
package or module version is already present from an included
package.
* Updating location information in an 'includes/package', 'includes/
module', 'includes/import-only-module', or 'mount/package' list
entry without changing the referenced package or module version.
* Any change to any meta-data associated with a package definition.
6.1.2. Guidelines for Package Versions During Package Development
During development of a new package, or while updating a previously
released package, special care should be taken with the selection of
the version associated with the package.
General YANG Semver versioning guidance from Section 6 of
[I-D.ietf-netmod-yang-semver] may be helpful, additional IETF
specific guidance for managing IETF package definitions may be
provided in a future RFC, pending the output of
[I-D.mahesh-opsawg-veloce-yang].
7. Package Conformance
Better and easier conformance is a major design goal for YANG
packages. YANG package conformance is similar to how YANG [RFC7950]
requires that servers either implement a module faithfully, or
otherwise use deviations to indicate areas of non-conformance.
Ultimately, each version of a YANG package resolves, as per
(Section 4), to a YANG schema that is defined as a set of implemented
modules and import-only modules, deviations, features, and mounted
Wilton, et al. Expires 7 January 2027 [Page 28]
Internet-Draft YANG Packages July 2026
schema. For YANG package conformance, it is necessary to determine
whether an implementation faithfully conforms to the full YANG schema
defined by a resolved YANG package.
The YANG packaging solution is designed to allow for conformance to
be checked at a package level, potentially using cached offline
package definitions, rather than requiring a client to download all
modules, supported features, and deviations from the server to ensure
that the datastore schema used by the server is compatible with the
client.
In the case where a device does not completely conform to a standard
or industry defined YANG package definition, then there are a few
suggestions on how this can be handled:
* Automatic module version resolution rules can be used to select
the latest module version between packages.
* Server implementation packages can be defined that include and
refine standard/industry packages to accurately report the
device's schema and any variations from the standard.
7.1. Resolving conflicting module versions in included packages
Sometimes a package definition may include multiple packages that
implement different versions of a module.
As per the package definition rules in Section 3.1, a package can
only implement a single version of a module, and hence in cases of
conflicting versions in included packages/modules it is necessary to
resolve which version of the module is used. The default behavior,
defined in Section 4.1 is to use automatic resolution, which is
generally the best choice. Manual resolution could be used to select
a different module version instead, or even remove the module from
the package entirely. However, care must be taken if an older module
version is chosen, or a new non-backwards-compatible newer version is
chosen, because, in both cases, this may affect conformance in one of
the included packages.
7.2. Handling multiple included package versions
Unlike modules in a package definition, where there can only be a
single version of a module in a resolved package schema, this does
not apply to included packages. As per the package resolution rules
in Section 4, when multiple included packages define different
versions of the same package, then both versions are retained in the
resolved package schema.
Wilton, et al. Expires 7 January 2027 [Page 29]
Internet-Draft YANG Packages July 2026
Instead, package and schema comparison tooling can be used to
determine what level of package conformance has been achieved for
each of the recursively included packages.
7.3. Exclusions and Deviations
Whenever possible, servers should aim to implement standards defined
packages or industry defined packages accurately since this maximizes
interoperability for clients. However, if a server does not
faithfully implement a YANG package then it can define a new server
specific package to accurately report what it does implement. The
RECOMMENDED approach to achieve this is to define and advertise a
separate "server implementation" package which incorporates the
package to be conformed to via including it in "/includes/package",
and then excludes modules or selects different versions, adds
deviation modules, and excludes enabled features to indicate the
actual conformance of the server implementation.
An example of this approach is provided in Appendix A.2.1.
If an implementation doesn't support any functionality in a module
then it should exclude the module rather than using deviations to
exclude all data nodes added by the module to the resolved package
schema. This gives a clearer indication to users of the package
definition as to the intent. However, be aware when combining two
included packages, that a module removed by one package could still
be re-added by another included package. If deviations are used this
won't happen unless the module defining the deviations is explicitly
removed.
If an alternative version of a module is used then it is RECOMMENDED
to use a newer module version, if possible, rather than an older
version. Selecting a backwards-compatible version is also helpful
because it maximizes the chance that clients will be able to easily
interoperate with the server.
7.4. Use of features in YANG modules and YANG packages
The YANG language, [RFC7950] section 5.6.2, supports feature
statements as the mechanism to make parts of a schema optional.
Published standard YANG modules make use of appropriate feature
statements to provide flexibility in how YANG modules may be used by
implementations and used by YANG modules published by other
organizations.
Wilton, et al. Expires 7 January 2027 [Page 30]
Internet-Draft YANG Packages July 2026
YANG packages include the 'includes/feature' list, which allows the
package to define a set of features that MUST be enabled by any
conformant implementation of the package as a mechanism to simplify
and manage the schema represented by a YANG package.
7.5. Use of YANG semantic versioning for YANG packages
Using the YANG semantic versioning scheme for package version numbers
and module version labels can help with conformance. In the general
case, clients should be able to determine the nature of changes
between two package versions by comparing the version number.
This usually means that a client does not have to be restricted to
working only with servers that advertise exactly the same version of
a package in YANG library. Instead, reasonable clients should be
able to interoperate with any server that supports a package version
that is backwards compatible with the version that the client is
designed for, assuming that the client is designed to ignore
operational values for unknown data nodes.
For example, a client coded to support 'example-foo' package at
version 1.0.0 should interoperate with a server implementing
'example-foo' package at version 1.3.5, because the YANG semantic
versioning rules require that package version 1.3.5 is backwards
compatible with version 1.0.0.
This also has a relevance on servers that are capable of supporting
version selection because they need not support every version of a
YANG package to ensure good client compatibility. Choosing suitable
minor versions within each major version number should generally be
sufficient, particularly if they can avoid non-backwards-compatible
patch level changes.
7.6. Restrictions on the use of deviations in YANG packages
[RFC7950] section 5.6.3 defines deviations as the mechanism to allow
servers to indicate where they do not conform to a published YANG
module that is being implemented.
Organizations may wish to reuse YANG modules and YANG packages
published by other organizations for new functionality. Sometimes,
they may desire to modify the published YANG modules. However, they
MUST NOT use deviations in an attempt to achieve this because such
deviations cause two problems:
They prevent implementations from reporting their own deviations
for the same nodes.
Wilton, et al. Expires 7 January 2027 [Page 31]
Internet-Draft YANG Packages July 2026
They fracture the ecosystem by preventing implementations from
conforming to the standards specified by both organizations. This
hurts the interoperability in the YANG community, promotes
development of disconnected functional silos, and hurts creativity
in the market.
7.7. The relationship between packages and datastores
As defined by NMDA [RFC8342], each datastore has an associated
datastore schema. These datastore schemas can be advertised by
servers using YANG Library [RFC8525], augmented with the associated
YANG package information, as per Section 5.4.3. Sections 5.1 and 5.3
of NMDA defines further constraints on the schema associated with
datastores. These constraints can be summarized thus:
* The schema for all conventional datastores is the same.
* The schema for non-conventional configuration datastores (e.g.,
dynamic datastores) may completely differ (i.e. no overlap at all)
from the schema associated with the conventional configuration
datastores, or may partially or fully overlap with the schema of
the conventional configuration datastores. A dynamic datastore,
for example, may support different modules than conventional
datastores, or may support a subset or superset of modules,
features, or data nodes supported in the conventional
configuration datastores. Where a data node exists in multiple
datastore schemas it has the same type, properties and semantics.
* The schema for the operational datastore is intended to be a
superset of all the configuration datastores (i.e. includes all
the schema nodes from the conventional configuration datastores),
but data nodes can be omitted if they cannot be accurately
reported. The operational datastore schema can include additional
modules containing only config false data nodes, but there is no
harm in including those modules in the configuration datastore
schema as well.
Given that YANG packages represent a schema, it follows that each
datastore schema can be represented using packages. In addition, the
schemas for most datastores on a server are often closely related.
Given that there are many ways that a datastore schema could be
represented using packages, the following guidance provides a
consistent approach to help clients understand the relationship
between the different datastore schemas supported by a device (e.g.,
which parts of the schema are common and which parts have
differences):
Wilton, et al. Expires 7 January 2027 [Page 32]
Internet-Draft YANG Packages July 2026
* Any datastores (e.g., conventional configuration datastores) that
have exactly the same datastore schema MUST use the same package
definitions. This is to avoid, for example, the creation of a
'running-cfg' package and a separate 'intended-cfg' package that
have identical schema.
* Common package definitions SHOULD be used for those parts of the
datastore schema that are common between datastores, when those
datastores do not share exactly the same datastore schema. E.g.,
if a substantial part of the schema is common between the
conventional, dynamic, and operational datastores then a single
common package can be used to describe the common parts, along
with other packages to describe the unique parts of each datastore
schema.
* YANG modules that do not contain any configuration data nodes MAY
be included in the package for configuration datastores if that
helps unify the package definitions.
* The packages for the operational datastore schema SHOULD include
all packages for all configuration datastores, along with any
required modules defining deviations to mark unsupported data
nodes. The deviations MAY be defined directly in the packages
defining the operational datastore schema, or in separate packages
(which may be packages attached to the datastore, or may be
packages included by other packages).
* The schema for a datastore MAY be represented using a single
package or as the union of a set of compatible packages, i.e.,
equivalently to a set of non-conflicting packages being included
together in an overarching package definition that relies on the
automatic resolution of module versions.
* The resolved package schema representing a datastore MUST be
referentially complete.
7.8. Using package comparison tools
Clients fetch the package information from the server (if required),
and then can use tools to generate the resolved package schema. The
resolved package schema may list multiple versions of the same
package (if included with different versions), and it may list
package versions that are not completely implemented by the device.
By using package schema comparison, as described below, tooling can
report on the level of conformance for each package and included
package version advertised by the device.
Wilton, et al. Expires 7 January 2027 [Page 33]
Internet-Draft YANG Packages July 2026
YANG package schema comparison tools (and also documentation) can be
used to determine how closely a device implements particular YANG
package definitions advertised by the device. The tooling, by
resolving the package definition, then comparing the set of module
versions, features, deviations and mounts, can determine if the
package schema is implemented exactly, or if the package schema is
backwards-compatible, or non-backwards-compatible. Tooling can
determine if modules have been removed, mounts have been changed, or
deviations have been applied.
8. YANG Modules
The YANG module definitions for the modules described in the previous
sections follow. Some of these modules use the YANG Data Structure
Extensions defined in [RFC8791].
8.1. ietf-yang-package-types
The "ietf-yang-package-types" module imports "ietf-yang-revisions"
[I-D.ietf-netmod-yang-module-versioning], "ietf-yang-semver"
[I-D.ietf-netmod-yang-semver], "ietf-yang-types" [RFC9911], and
"ietf-inet-types" [RFC9911].
<CODE BEGINS> file "ietf-yang-package-types#0.10.0.yang"
module ietf-yang-package-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types";
prefix "pkg-types";
import ietf-yang-revisions {
prefix rev;
reference "XXXX: Updated YANG Module Revision Handling";
}
import ietf-yang-semver {
prefix ys;
reference "XXXX: YANG Semantic Versioning";
}
import ietf-yang-types {
prefix yang;
rev:recommended-min-date 2025-12-22;
reference "RFC 9911: Common YANG Data Types.";
}
import ietf-inet-types {
prefix inet;
rev:recommended-min-date 2025-12-22;
Wilton, et al. Expires 7 January 2027 [Page 34]
Internet-Draft YANG Packages July 2026
reference "RFC 9911: Common YANG Data Types.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"This module provides type and grouping definitions for YANG
packages.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
revision 2026-07-06 {
ys:version 0.10.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
Wilton, et al. Expires 7 January 2027 [Page 35]
Internet-Draft YANG Packages July 2026
/*
* Typedefs
*/
typedef pkg-name {
type yang:yang-identifier;
description
"Package names are typed as YANG identifiers.";
}
typedef pkg-version {
type ys:version;
description
"Packages are versioned using YANG Semver version labels.";
}
typedef module-name {
type yang:yang-identifier;
description
"Module names are typed as YANG identifiers.";
}
typedef version-or-rev-date {
type union {
type rev:revision-date;
type ys:version;
}
description
"Identifies a module by YANG semantic version or revision
date";
}
typedef scoped-feature {
type string {
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*';
}
description
"Represents a feature name scoped to a particular module,
identified as the '<module-name>:<feature-name>', where both
<module-name> and <feature-name> are YANG identifier strings,
as defined by Section 12 or RFC 6020.";
reference
"RFC XXXX, YANG Packages.";
}
typedef mount-ypath {
type string;
Wilton, et al. Expires 7 January 2027 [Page 36]
Internet-Draft YANG Packages July 2026
description
"A path that identifies a set of data nodes in the schema tree.
This leaf is encoded as a JSON style encoded
instance-identifier (regardless of whether the format
used to encode the YANG instance data), as specified in
RFC 7951, section 6.11, except that keys are optional.
For optional keys, the name and value of the key is
excluded from the key list.
TODO - Check if this definition is sufficient.";
}
/*
* Groupings
*/
grouping yang-pkg-identification-leafs {
description
"Parameters for identifying a specific version of a YANG
package";
leaf name {
type pkg-name;
mandatory true;
description
"The YANG package name.";
}
leaf version {
type pkg-version;
mandatory true;
description
"Uniquely identifies a particular version of a YANG package.
Follows the definition for YANG Semantic Version labels
defined in draft-ietf-netmod-yang-semver, section 4.2
XXXX, RFC Editor, please update reference and section to
the published YANG Semver RFC.";
}
}
grouping yang-pkg-exclusions {
description
"Parameters for excluding modules and packages from a YANG
package definition";
Wilton, et al. Expires 7 January 2027 [Page 37]
Internet-Draft YANG Packages July 2026
container excludes {
description
"Contains parameters for excluding modules and packages
from a YANG package definition";
leaf-list module {
type module-name;
description
"Lists implemented modules, of any version, that may have
have been brought in by included packages, but are
explicitly excluded from this package definition.
Excluding a module can affect the compliance and
correctness of any included packages that expect that
module to be implemented.
Excluding a module also implicitly excludes any submodules
and enabled features defined in the excluded module.
It is an error to list a module in both this list and the
'includes/module' list.";
}
list import-only-module {
key "name";
description
"Lists import-only modules that may have have been brought
in by included packages, but are explicitly excluded from
this package definition.
It is an error to list the same module version in both
this list and the 'includes/import-only-module' list. If
no versions are listed for an entry in this list, then
that entry excludes all versions of the import-only
module and it is an error to list the same module name in
the 'includes/import-only-module' list.";
leaf name {
type module-name;
mandatory true;
description
"The name of the import-only module to exclude some
versions of.";
}
leaf-list version {
type version-or-rev-date;
description
Wilton, et al. Expires 7 January 2027 [Page 38]
Internet-Draft YANG Packages July 2026
"Lists specific versions of the import-only module being
excluded. If no versions are listed, all versions of
the import-only module are excluded.
If required, the YANG Semantic Version SHOULD be used
to identify the module version, otherwise the YANG
module revision date is used.";
}
}
leaf-list feature {
type scoped-feature;
description
"Lists features from the 'includes/feature' list exported
by an included package that are reclassified as being
OPTIONAL to support by any server implementing the package,
overriding the behavior specified by the included package.
Features MUST NOT be specified both in this list and also
the 'includes/feature' list.";
}
}
}
grouping yang-pkg-location {
description
"Parameters for locating a YANG package instance";
leaf-list location {
type inet:uri;
ordered-by user;
description
"Contains a URL that represents where an instance data file
(RFC 9195) for this YANG package can be found.
This leaf will only be present if there is a URL available
for retrieval of the schema for this entry.
If multiple locations are provided, then the first location
in the leaf-list SHOULD be the canonical location that
uniquely identifies this package.";
}
}
grouping submodule-identification-leafs {
description
"Defines the data nodes for representing a submodule reference
in a YANG package definition.";
Wilton, et al. Expires 7 January 2027 [Page 39]
Internet-Draft YANG Packages July 2026
list submodule {
key "name";
description
"Each entry represents one submodule within the
parent module.";
leaf name {
type module-name;
mandatory true;
description
"The YANG submodule name.";
}
leaf version {
type version-or-rev-date;
mandatory true;
description
"The YANG submodule revision date or YANG Semantic
version.
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 version specified here.";
}
leaf-list location {
type inet:uri;
ordered-by user;
description
"Contains a URL from where the YANG schema resource for
this submodule can be retrieved.
If multiple locations are provided, then the first
location in the leaf-list SHOULD be the canonical
location that uniquely identifies this submodule.";
}
}
}
grouping module-and-submodule-identification-leafs {
description
"Defines the data nodes for representing a module reference
with its associated submodules.";
leaf name {
type module-name;
mandatory true;
Wilton, et al. Expires 7 January 2027 [Page 40]
Internet-Draft YANG Packages July 2026
description
"The YANG module name.";
}
leaf version {
type version-or-rev-date;
mandatory true;
description
"Identifies the module version. If available, the YANG
Semantic Version SHOULD be used, otherwise the YANG module
revision date is used.";
}
leaf-list location {
type inet:uri;
ordered-by user;
description
"Contains a URL that represents the YANG schema resource
for this module.
This leaf will only be present if there is a URL available
for retrieval of the schema for this entry.
If multiple locations are provided, then the first location
in the leaf-list SHOULD be the canonical location that
uniquely identifies this module.";
}
uses submodule-identification-leafs;
}
grouping yang-pkg-instance {
description
"Specifies the data node for a full YANG package instance
represented either on a server or as a YANG instance data
document.";
uses yang-pkg-identification-leafs;
leaf version-description {
type string;
description
"An optional description of the package version. E.g.,
perhaps tying it to a software release or a description
of what key changes have occurred compared to the
previous version.";
}
leaf timestamp {
Wilton, et al. Expires 7 January 2027 [Page 41]
Internet-Draft YANG Packages July 2026
type yang:date-and-time;
description
"An optional timestamp for when this package was created.
This does not need to be unique across all versions of a
package.";
}
leaf organization {
type string;
description "Organization responsible for this package";
}
leaf contact {
type string;
description
"Contact information for the person or organization to whom
queries concerning this package should be sent.";
}
leaf description {
type string;
description "Provides a description of the package";
}
leaf reference {
type string;
description "Allows for a reference for the package";
}
leaf complete {
type boolean;
default true;
description
"Indicates whether the schema defined by this package is
referentially complete. I.e. all module imports can be
resolved to a module explicitly defined in this package or
one of the included packages.";
}
container includes {
description
"Lists package and modules that are included in the package
definition.";
list package {
key "name version";
ordered-by user;
description
Wilton, et al. Expires 7 January 2027 [Page 42]
Internet-Draft YANG Packages July 2026
"An entry in this list represents a package that is
included as part of the package definition.
A package MAY directly include multiple versions of the
same package, but normally only a single package version
is expected. Multiple package versions can be listed,
for example, to update location information for package
versions included through other packages.";
reference
"RFC XXXX: YANG Packages, Section 4.";
uses yang-pkg-identification-leafs;
uses yang-pkg-location;
}
list module {
key "name";
description
"An entry in this list represents a module that MUST be
implemented by a server implementing this package, as per
RFC 7950 section 5.6.5.
An entry in this list overrides any module version
'implemented' by an included package.";
reference
"RFC 7950: The YANG 1.1 Data Modeling Language.";
uses module-and-submodule-identification-leafs;
}
list import-only-module {
key "name version";
description
"An entry in this list indicates that the server imports
reusable definitions from the specified version of the
module, but does not implement any protocol accessible
objects from this version.
This entry overrides any import-only module definition
with the same module name and version from an included
package.
Multiple entries for the same module name MAY exist.
This can occur if multiple modules import the same
module, but specify different revision-dates in the
import statements.";
uses module-and-submodule-identification-leafs;
Wilton, et al. Expires 7 January 2027 [Page 43]
Internet-Draft YANG Packages July 2026
}
leaf-list feature {
type scoped-feature;
description
"Lists features, defined in any modules included in the
package, that MUST be supported by any server
implementing the package.
Enabled features specified by any directly included
packages MUST also be supported by server
implementations, unless excluded by an entry in the
'excludes/feature' list, and do not need to be repeated
in this list.
All other features defined in modules included in the
package are OPTIONAL to implement.";
}
}
uses yang-pkg-exclusions;
container depends-on {
description
"Lists packages that this package depends on, but that do
not form part of the resolved package definition.
For an incomplete package definition, this list can help a
client resolve a complete schema in a machine readable
way.";
reference
"RFC XXXX: YANG Packages, Section 4.";
list package {
key "name version";
description
"An entry in this list represents a package that is
depended on by this package definition.";
uses yang-pkg-identification-leafs;
uses yang-pkg-location;
}
}
list mount {
key "mount-path";
description
"An entry in this list represents additions to the schema
Wilton, et al. Expires 7 January 2027 [Page 44]
Internet-Draft YANG Packages July 2026
found at the specified mount point, or, if
'inherit-packages' is 'false', replacement of the
inherited schema found at the specified mount point.";
leaf "mount-path" {
type mount-ypath;
mandatory true;
description
"This path identifies a mount point in the schema.
This leaf is encoded as a JSON style encoded
instance-identifier (regardless of whether the format
used to encode the YANG instance data), as specified in
RFC 7951, section 6.11, except that keys are optional.
For optional keys, the name and value of the key is
excluded from the key list.
Mount paths MUST only be used for schema mount points
defined in the package schema.
For example, if an example module 'ex-module' defines a
mount point under list entry'/modules/module/' then a
mount path of
- '/modules/module[name=foo]' would indicate the mounted
package schema for only the 'foo' entry in the module
list. Each entry in the list could have a different
mounted schema specified.
- '/modules/module[]' would indicate that the same
mounted package schema is available for all list
entries in the module list.";
}
leaf inherit-packages {
type boolean;
default true;
description
"Indicates whether the packages, additional features, and
parent-references available at the mount point for this
package definition automatically include all packages,
additional features, and parent-references mounted at the
same mount path in any 'includes/package' entries.
If set to true (the default), the schema is defined
as the union of the resolved package schema at the mount
point by any packages in the 'includes/package' list
Wilton, et al. Expires 7 January 2027 [Page 45]
Internet-Draft YANG Packages July 2026
combined with the resolved package schema of all packages
listed in the 'package' list, plus any additional
features and parent-references defined for the same
mount point.
If set to false, then the mounted schema starts from a
blank slate and only packages, additional features, and
parent-references listed in this 'mount' entry are
included. This allows the definitions in the mounted
packages to be modified (e.g., remove or change module
versions). To help conformance, the packages listed here
SHOULD include all the packages that would have been
automatically included.
";
}
list package {
key "name version";
ordered-by user;
description
"The packages that will be mounted at the specified mount
path.
A mount point MAY directly list multiple versions of the
same package, but normally only a single package version
is expected. Multiple package versions can be listed,
for example, to update location information for package
versions inherited from included packages.
If 'inherit-packages' is true, or absent, then these
packages are mounted in addition to the mounted packages
from the 'includes/package' list.
If 'inherit-packages' is false, then these packages,
together with any additional features and
parent-references in the same 'mount' entry, define the
mounted package schema at this mount point.
Also see the 'inherit-packages' leaf.";
reference
"RFC XXXX: YANG Packages, Section 4.";
uses yang-pkg-identification-leafs;
uses yang-pkg-location;
}
leaf-list additional-feature {
type scoped-feature;
description
Wilton, et al. Expires 7 January 2027 [Page 46]
Internet-Draft YANG Packages July 2026
"The name of YANG features enabled at the mount point in
addition to the enabled features from the resolved
mounted package definitions.
This list identifies additional features rather than the
complete set of supported features.
The features listed here MUST be defined in modules
included in the resolved mounted package schema.
Features are identified using
<module-name>:<feature-name>.
";
}
leaf-list parent-reference {
type mount-ypath;
description
"Represents paths in the parent schema that are accessible
from the mounted schema for the evaluation of XPath
expressions.
See Mount Point path and parent-reference in Schema Mount
(RFC 8528) for a more detailed description.
Unlike the YANG module defined in RFC 8528, this leaf is
encoded as a JSON style encoded instance-identifier
(regardless of whether the format used to encode the YANG
instance data), as specified in RFC 7951, section 6.11,
except that keys are optional.
For optional keys, the name and value of the key is
excluded from the key list.";
}
}
}
}
<CODE ENDS>
8.2. ietf-yang-package-instance
The "ietf-yang-package-instance" module imports "ietf-yang-semver"
[I-D.ietf-netmod-yang-semver], "ietf-yang-package-types" defined in
this document, and "ietf-yang-structure-ext" [RFC8791].
Wilton, et al. Expires 7 January 2027 [Page 47]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "ietf-yang-package-instance#0.10.0.yang"
module ietf-yang-package-instance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance";
prefix pkg-inst;
import ietf-yang-semver {
prefix ys;
reference "XXXX: YANG Semantic Versioning";
}
import ietf-yang-package-types {
prefix pkg-types;
ys:recommended-min-version 0.10.0;
reference "RFC XXX: this RFC.";
}
import ietf-yang-structure-ext {
prefix sx;
reference "RFC 8791: YANG Data Structure Extensions.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"This module provides a definition of a YANG package, which is
used as the content schema for a YANG instance data
document specifying a YANG package.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
Wilton, et al. Expires 7 January 2027 [Page 48]
Internet-Draft YANG Packages July 2026
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
revision 2026-07-06 {
ys:version 0.10.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
/*
* Top-level structure
*/
sx:structure package {
description
"Defines the YANG package structure for use in a YANG instance
data document.";
uses pkg-types:yang-pkg-instance;
}
}
<CODE ENDS>
8.3. ietf-yang-package
The "ietf-yang-package" module imports "ietf-yang-semver"
[I-D.ietf-netmod-yang-semver] and "ietf-yang-package-types" defined
in this document.
<CODE BEGINS> file "ietf-yang-packages#0.10.0.yang"
module ietf-yang-packages {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages";
prefix pkgs;
Wilton, et al. Expires 7 January 2027 [Page 49]
Internet-Draft YANG Packages July 2026
import ietf-yang-semver {
prefix ys;
reference "XXXX: YANG Semantic Versioning";
}
import ietf-yang-package-types {
prefix pkg-types;
ys:recommended-min-version 0.10.0;
reference "RFC XXX: this RFC.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"This module defines YANG packages on a server implementation.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
Wilton, et al. Expires 7 January 2027 [Page 50]
Internet-Draft YANG Packages July 2026
revision 2026-07-06 {
ys:version 0.10.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
/*
* Groupings
*/
grouping yang-pkg-ref {
description
"Defines the leaves used to reference a single entry in the
top-level '/pkgs:packages/pkgs:package' list.";
leaf name {
type leafref {
path '/pkgs:packages/pkgs:package/pkgs:name';
}
description
"The name of the referenced package in the top-level
'/pkgs:packages/pkgs:package' list.";
}
leaf version {
type leafref {
path '/pkgs:packages'
+ '/pkgs:package[pkgs:name = current()/../name]'
+ '/pkgs:version';
}
description
"The version of the referenced package in the top-level
'/pkgs:packages/pkgs:package' list.";
}
}
/*
* Top level data nodes.
*/
container packages {
config false;
Wilton, et al. Expires 7 January 2027 [Page 51]
Internet-Draft YANG Packages July 2026
description "All YANG package definitions";
list package {
key "name version";
description
"YANG package instance";
uses pkg-types:yang-pkg-instance;
}
}
}
<CODE ENDS>
8.4. ietf-yl-packages
The "ietf-yl-packages" module imports "ietf-yang-revisions"
[I-D.ietf-netmod-yang-module-versioning], "ietf-yang-semver"
[I-D.ietf-netmod-yang-semver], "ietf-yang-package-types" and "ietf-
yang-packages" defined in this document, and "ietf-yang-library"
[RFC8525].
<CODE BEGINS> file "ietf-yl-packages#0.10.0.yang"
module ietf-yl-packages {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages";
prefix yl-pkgs;
import ietf-yang-revisions {
prefix rev;
reference "XXXX: Updated YANG Module Revision Handling";
}
import ietf-yang-semver {
prefix ys;
reference "XXXX: YANG Semantic Versioning";
}
import ietf-yang-package-types {
prefix pkg-types;
ys:recommended-min-version 0.10.0;
reference "RFC XXX: YANG Packages.";
}
import ietf-yang-packages {
prefix pkgs;
ys:recommended-min-version 0.10.0;
reference "RFC XXX: YANG Packages.";
Wilton, et al. Expires 7 January 2027 [Page 52]
Internet-Draft YANG Packages July 2026
}
import ietf-yang-library {
prefix yanglib;
rev:recommended-min-date 2019-01-04;
reference "RFC 8525: YANG Library";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"This module provides defined augmentations to YANG library to
allow a server to report YANG package information.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
revision 2026-07-06 {
Wilton, et al. Expires 7 January 2027 [Page 53]
Internet-Draft YANG Packages July 2026
ys:version 0.10.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
/*
* Augmentations
*/
augment "/yanglib:yang-library/yanglib:schema" {
description
"Allow datastore schema to be related to a set of YANG
packages.
Features enabled by the server in addition to the mandatory
features from the package definitions are listed in the
'additional-feature' list.
";
list package {
key "name version";
ordered-by user;
description
"Identifies the YANG packages that collectively define the
schema for the associated datastore.
The referenced packages are resolved as if they were all
directly included in a single package definition, as
described in RFC XXXX, Section 5.4.3.
The resolved datastore schema MUST be referentially
complete.";
reference
"RFC XXXX: YANG Packages, Section 5.4.3.";
uses pkgs:yang-pkg-ref;
uses pkg-types:yang-pkg-location;
}
leaf-list additional-feature {
type pkg-types:scoped-feature;
description
"The name of YANG features enabled by the server in addition
to the enabled features from the resolved package
Wilton, et al. Expires 7 January 2027 [Page 54]
Internet-Draft YANG Packages July 2026
definitions associated with this datastore schema.
Although this list identifies additional features rather
than the complete set of supported features, enabled
features from the resolved packages MAY be included.
The features listed here MUST be defined in modules
included in the datastore schema.
Features are identified using <module-name>:<feature-name>.
This list, combined with the enabled features from the
resolved package schemas, MUST be equivalent to the
list of supported features advertised in YANG library.";
}
}
}
<CODE ENDS>
8.5. ietf-yang-inst-data-pkg
The "ietf-yang-inst-data-pkg" module imports "ietf-yang-revisions"
[I-D.ietf-netmod-yang-module-versioning], "ietf-yang-semver"
[I-D.ietf-netmod-yang-semver], "ietf-yang-package-types" defined in
this document, "ietf-inet-types" [RFC9911], "ietf-yang-structure-ext"
[RFC8791], and "ietf-yang-instance-data" [RFC9195].
<CODE BEGINS> file "ietf-yang-inst-data-pkg#0.10.0.yang"
module ietf-yang-inst-data-pkg {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg";
prefix yid-pkg;
import ietf-yang-revisions {
prefix rev;
reference "XXXX: Updated YANG Module Revision Handling";
}
import ietf-yang-semver {
prefix ys;
reference "XXXX: YANG Semantic Versioning";
}
import ietf-yang-package-types {
prefix pkg-types;
ys:recommended-min-version 0.10.0;
reference "RFC XXX: this RFC.";
}
Wilton, et al. Expires 7 January 2027 [Page 55]
Internet-Draft YANG Packages July 2026
import ietf-inet-types {
prefix inet;
rev:recommended-min-date 2025-12-22;
reference "RFC 9911: Common YANG Data Types.";
}
import ietf-yang-structure-ext {
prefix sx;
reference "RFC 8791: YANG Data Structure Extensions.";
}
import ietf-yang-instance-data {
prefix yid;
reference "RFC 9195: YANG Instance Data File Format.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"The module augments ietf-yang-instance-data to allow package
definitions to be used to define content schema in YANG
instance data documents.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
Wilton, et al. Expires 7 January 2027 [Page 56]
Internet-Draft YANG Packages July 2026
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
revision 2026-07-06 {
ys:version 0.10.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
/*
* Augmentations
*/
sx:augment-structure
"/yid:instance-data-set/yid:content-schema/"
+ "yid:content-schema-spec" {
description
"Add package reference to instance data set schema
specification";
case pkg-schema {
container pkg-schema {
description
"Identifies the YANG package that defines the content
schema for this instance data set.";
uses pkg-types:yang-pkg-identification-leafs;
leaf-list location {
type inet:uri;
ordered-by user;
description
"Contains a URL that represents where an instance data
file for this YANG package can be found.
This leaf will only be present if there is a URL
available for retrieval of the schema for this entry.
If multiple locations are provided, then the first
location in the leaf-list SHOULD be the canonical
location that uniquely identifies this package.";
}
}
}
Wilton, et al. Expires 7 January 2027 [Page 57]
Internet-Draft YANG Packages July 2026
}
}
<CODE ENDS>
9. YANG Package Instance Data Schema
This section defines the YANG package schema to use as a schema for
YANG instance data files defining YANG packages. Although this
definition may appear to be somewhat self-recursive, this can be
mitigated by the fact that tools SHOULD recognize files of type
".ypkg" as being YANG package instance data files, without needing to
check the package schema.
RFC Editor note: Please check module versions, and update the package
version and module versions to 1.0.0 on publication of the RFC.
I.e., the expectation is that any non-example versions starting 0.x.y
should become 1.0.0 on publication.
<CODE BEGINS> file "yang-inst-data-schema@0.2.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "yang-inst-data-schema",
"version": "0.2.0",
"timestamp": "2026-03-20T17:52:47.188253Z",
"organization": "IETF",
"contact": "IESG",
"description": "Package schema to use for defining the \
yang-inst-data-schema schema for YANG packages. TODO - RFC Editor, \
plesae check semver and module versioning module revisions. RFC \
Editor, please update this module version to 1.0.0 on publication \
of the RFC.",
"includes": {
"module": [
{
"name": "ietf-yang-package-instance",
"version": "0.10.0",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-package-instance@0.10.0.yang"
]
}
],
"import-only-module": [
{
Wilton, et al. Expires 7 January 2027 [Page 58]
Internet-Draft YANG Packages July 2026
"name": "ietf-yang-package-types",
"version": "0.10.0",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-package-types@0.10.0.yang"
]
},
{
"name": "ietf-yang-revisions",
"version": "2025-09-16",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-revisions@2025-09-16.yang"
]
},
{
"name": "ietf-yang-semver",
"version": "2025-09-29",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-semver@2025-09-29.yang"
]
},
{
"name": "ietf-yang-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-types@2025-12-22.yang"
]
},
{
"name": "ietf-inet-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-inet-types@2025-12-22.yang"
]
},
{
"name": "ietf-yang-structure-ext",
"version": "2020-06-17",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-structure-ext@2020-06-17.yang"
]
}
]
Wilton, et al. Expires 7 January 2027 [Page 59]
Internet-Draft YANG Packages July 2026
}
}
}
}
}
<CODE ENDS>
10. Security Considerations
This document defines YANG modules for defining YANG schema, that are
often used to configure and monitor network devices.
The document defines three YANG modules that are accessible from
devices, and the normal YANG network management security
considerations apply, which are further described below, in
Section 10.1.
YANG packages also offer an alternative mechanism to YANG Library
[RFC8525] for reporting YANG schema, and hence the security
considerations from that document also apply to the use of YANG
packages. As per the YANG library security considerations, the
module and version information in YANG packages may help an attacker
identify the server capabilities and server implementations with
known bugs since the set of YANG modules supported by a server may
reveal the kind of device and the manufacturer of the device. Server
vulnerabilities may be specific to particular modules, module
revisions, module features, or even module deviations. For example,
if a particular operation on a particular data node is known to cause
a server to crash or significantly degrade device performance, then
the YANG packages information will help an attacker identify server
implementations with such a defect, in order to launch a denial-of-
service attack on the device.
The 'ietf-yang-package-instance.yang' YANG file allows YANG packages
to be defined in YANG instance data files. In addition, "ietf-yang-
inst-data-pkg" allows YANG packages to be used to define the schema
for YANG instance data files. In both cases, the security
considerations from [RFC9195] apply. Since YANG package instance
data files are outside the security controls of the network
management protocols, it is important to consider controlling access
to these files to restrict access to potentially sensitive
information.
10.1. YANG Module Security Considerations
This section is modeled after the template described in Section 3.7
of [RFC9907].
Wilton, et al. Expires 7 January 2027 [Page 60]
Internet-Draft YANG Packages July 2026
The "ietf-yang-package-types", "ietf-yang-packages" and "ietf-yl-
packages" YANG modules define data models that are designed to be
accessed via YANG-based management protocols, such as NETCONF
[RFC6241] and RESTCONF [RFC8040]. These YANG-based management
protocols (1) have to use a secure transport layer (e.g., SSH
[RFC6242], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following
subtrees and data nodes have particular sensitivities/
vulnerabilities:
* There are no particularly sensitive readable data nodes.
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'yang-pkg-instance').
11. Operational Considerations
YANG packages provide an alternative mechanism to YANG Library
[RFC8525] for describing a server's implemented YANG schema.
However, package support is not expected to replace YANG Library on
servers. Devices are expected to continue supporting YANG Library
for clients that are not package-aware, and package-aware clients may
still use YANG Library information when resolving or validating the
effective datastore schema.
Device vendors and package publishers should take care when making
non-backwards-compatible (NBC) package changes, since such changes
can be impactful to clients that depend on the prior package schema.
Where NBC changes are necessary, it is better to make them clear and
transparent through the package version number. The "version-
description" leaf can also be used to highlight important NBC
changes, such as removed modules, removed enabled features, down-
referenced modules or packages, or new deviations that restrict the
schema. NBC changes should still be minimized where practical.
Wilton, et al. Expires 7 January 2027 [Page 61]
Internet-Draft YANG Packages July 2026
Package resolution is generally expected to be performed off-device
using tooling rather than by the managed device itself. To support
this, package definitions should be made available off-device as
".ypkg" instance data files using stable URIs. Stable locations
allow operators, clients, and tooling to retrieve package
definitions, resolve package dependencies, compare package versions,
and validate schemas without relying on repeated retrieval of schema
information from the device.
12. IANA Considerations
12.1. IANA YANG Module and Namespace Registrations
This document requests IANA to registers a URI in the "IETF XML
Registry" [RFC3688]. Following the format in RFC 3688, the following
registrations are requested.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-package-types
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-package-instance
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-packages
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-yl-packages
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document requests that the following YANG modules are added in
the "YANG Module Names" registry [RFC6020]:
Name: ietf-yang-package-types
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-package-types
Prefix: pkg-types
Reference: RFC XXXX
Name: ietf-yang-package-instance
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-package-instance
Prefix: pkg-inst
Wilton, et al. Expires 7 January 2027 [Page 62]
Internet-Draft YANG Packages July 2026
Reference: RFC XXXX
Name: ietf-yang-packages
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-packages
Prefix: pkgs
Reference: RFC XXXX
Name: ietf-yl-packages
Namespace: urn:ietf:params:xml:ns:yang:ietf-yl-packages
Prefix: yl-pkgs
Reference: RFC XXXX
Name: ietf-yang-inst-data-pkg
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg
Prefix: yid-pkg
Reference: RFC XXXX
12.2. IETF YANG Package Registry
This document requests that IANA create a registry for IETF YANG
packages, that lists all versions of all YANG package definitions
published by the IETF, and provides a reliable location to store the
YANG package definitions.
The name of the registry is "YANG Package Names" in the "YANG
Parameters" registry group.
The registry shall record for each entry:
* the name of the YANG package
* a brief description of the package purpose
* The latest published package version
* A list of all published package versions, each hyperlinked to the
location where a package instance data file, Section 5.5, for that
package definition may be retrieved from.
* a reference to the package documentation (e.g., the RFC number)
On creation of the registry, the ietf-inst-data-pkg-schema.ypkg,
defined in Section 9, should be added.
For allocation, the registration policy is Specification Required, as
defined in [RFC8126]. All registered YANG package names must comply
with the rules for identifiers stated in Section 6.2, and must have a
package name prefix.
Wilton, et al. Expires 7 January 2027 [Page 63]
Internet-Draft YANG Packages July 2026
The package name prefix 'ietf-' is reserved for YANG packages managed
and published under the IETF stream [RFC4844], while the package name
prefix 'irtf-' is reserved for YANG packages defined by the IRTF
stream. Packages published in other RFC streams must use a similar
suitable prefix.
All package names in the registry must be unique.
12.3. Media Type Registration for application/ypkg
This document requests IANA to register the following media type,
following the procedures of [RFC6838]:
Type name: application
Subtype name: ypkg
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: 8bit; YANG package instance data files
are encoded in UTF-8.
Security considerations: See the Security Considerations section
of RFC XXXX.
Interoperability considerations: N/A
Published specification: RFC XXXX
Applications that use this media type: YANG tooling and servers
that generate or consume YANG package instance data files.
Additional information:
Magic number(s): None
File extension(s): ypkg
Macintosh file type code(s): 'Text'
Fragment identifiers: N/A
Person & Email address to contact for further information: NETMOD
WG (mailto:netmod@ietf.org)
Intended usage: COMMON
Restrictions on usage: N/A
Author: IETF
Change controller: IESG
13. Acknowledgements
Feedback helping shape this document has kindly been provided by Andy
Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav
Lhotka, and Jan Lindblad.
Bo Wu acted as a temporary editor for earlier versions of this work.
Wilton, et al. Expires 7 January 2027 [Page 64]
Internet-Draft YANG Packages July 2026
LLMs, mainly Codex, have been used to review and hopefully improve
this document and have been directed help generate some content, in
particular the examples. The final content remains the
responsibility of the authors.
14. References
14.1. Normative References
[I-D.ietf-netmod-yang-module-versioning]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
Sterne, "Updated YANG Module Revision Handling", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-module-
versioning-17, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-module-versioning-17>.
[I-D.ietf-netmod-yang-semver]
Clarke, J., Wilton, R., Rahman, R., Lengyel, B., Sterne,
J., and B. Claise, "YANG Semantic Versioning", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-semver-
26, 7 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-netmod-yang-semver-26>.
[I-D.ietf-netmod-yang-ver-selection]
Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
"YANG Schema Selection", Work in Progress, Internet-Draft,
draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-ver-selection-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
Wilton, et al. Expires 7 January 2027 [Page 65]
Internet-Draft YANG Packages July 2026
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
[RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount",
RFC 8528, DOI 10.17487/RFC8528, March 2019,
<https://www.rfc-editor.org/info/rfc8528>.
[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>.
[RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG
Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
2022, <https://www.rfc-editor.org/info/rfc9195>.
Wilton, et al. Expires 7 January 2027 [Page 66]
Internet-Draft YANG Packages July 2026
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/info/rfc9911>.
14.2. Informative References
[I-D.mahesh-opsawg-veloce-yang]
Jethanandani, M., "YANG deVELpment PrOCEss and maintenance
(VELOCE)", Work in Progress, Internet-Draft, draft-mahesh-
opsawg-veloce-yang-01, 5 May 2026,
<https://datatracker.ietf.org/doc/html/draft-mahesh-
opsawg-veloce-yang-01>.
[RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor",
RFC 4844, DOI 10.17487/RFC4844, July 2007,
<https://www.rfc-editor.org/info/rfc4844>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Data Model for Network Instances", RFC 8529,
DOI 10.17487/RFC8529, March 2019,
<https://www.rfc-editor.org/info/rfc8529>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Wilton, et al. Expires 7 January 2027 [Page 67]
Internet-Draft YANG Packages July 2026
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Appendix A. Package Examples
This section provides various examples of YANG packages, and as such
this text is non-normative. The purpose of the examples is to
illustrate the file format of YANG packages, how package
dependencies, exclusions, and package mounts work. It does not imply
that such packages will be defined by IETF, or which modules would be
included in those packages even if they were defined.
The initial examples, in Appendix A.1, illustrate small, but complete
YANG package definitions. For the remaining examples, the focus is
on illustrating particular features of YANG packages, and so whilst
the packages are complete and will compile, they leave out some of
the optional fields.
Long lines in examples are wrapped using the mechanism defined in
[RFC8792].
A.1. Basic Package Examples
This section provides some very simple examples of YANG package
definitions that may be published by an SDO, illustrated using the
instance data file format defined in Section 5.5. The version
numbers chosen are somewhat arbitrary, and illustrative.
Wilton, et al. Expires 7 January 2027 [Page 68]
Internet-Draft YANG Packages July 2026
+========================+==========+==============================+
| Package | Versions | Content Overview |
+========================+==========+==============================+
| example-base-types | 1.0.0, | Base IETF and IANA type |
| | 1.1.0 | modules. |
+------------------------+----------+------------------------------+
| example-network-device | 1.1.2 | Basic network device system, |
| | | interface, access control, |
| | | key chain, and IP modules. |
+------------------------+----------+------------------------------+
| example-routing-types | 1.0.0 | Routing and BGP type |
| | | modules. |
+------------------------+----------+------------------------------+
| example-routing | 1.3.1 | Basic routing, routing |
| | | policy, BGP, and ACL |
| | | modules. |
+------------------------+----------+------------------------------+
Table 1: Common example packages
A.1.1. Example Basic Types YANG package, version 1.0.0
A very simple package with no dependencies on other packages that
illustrates how a basic types package might be defined. In this
case, the module dependencies have been declared as import-only, but
they could also have been declared as implemented modules.
<CODE BEGINS> file "example-base-types@1.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-base-types",
"version": "1.0.0",
"timestamp": "2026-03-20T17:52:47.188322Z",
"organization": "IETF NETMOD Working Group",
"contact": "WG Web: <http://tools.ietf.org/wg/netmod/>, \
WG List: <mailto:netmod@ietf.org>",
"description": "Example package containing base IETF and \
IANA type modules",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"import-only-module": [
{
"name": "ietf-yang-types",
"version": "2010-09-24",
Wilton, et al. Expires 7 January 2027 [Page 69]
Internet-Draft YANG Packages July 2026
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-types@2010-09-24.yang"
]
},
{
"name": "ietf-inet-types",
"version": "2010-09-24",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-inet-types@2010-09-24.yang"
]
},
{
"name": "ietf-netconf-acm",
"version": "2012-02-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-netconf-acm@2012-02-22.yang"
]
}
]
}
}
}
}
}
<CODE ENDS>
A.1.2. Example Basic Types YANG package, version 1.1.0
An updated version of the basic types package that includes updated
versions of the types modules and follows the YANG Semver versioning
rules.
Wilton, et al. Expires 7 January 2027 [Page 70]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-base-types@1.1.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-base-types",
"version": "1.1.0",
"version-description": "Updated to 2025 RFC module versions",
"timestamp": "2026-03-20T17:52:47.188373Z",
"description": "Example package containing base IETF and \
IANA type modules",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"import-only-module": [
{
"name": "ietf-yang-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-yang-types@2025-12-22.yang"
]
},
{
"name": "ietf-inet-types",
"version": "2025-12-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-inet-types@2025-12-22.yang"
]
},
{
"name": "ietf-netconf-acm",
"version": "2018-02-14",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-netconf-acm@2018-02-14.yang"
]
}
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 71]
Internet-Draft YANG Packages July 2026
A.1.3. Example Network Device YANG package
This section provides an instance data file example of a Network
Device YANG package.
This example package is intended to represent the standard set of
YANG modules, with import dependencies, to implement a basic network
device without any dynamic routing or layer 2 services. E.g., it
includes functionality such as system information, interface and
basic IP configuration. It includes the package (and hence all
modules, enabled features, etc.) from the example-base-types package.
This package also enables features for system authentication,
including local users and RADIUS-based authentication, and enables
IPv6 privacy autoconfiguration for the IP module.
As for all 'complete' YANG packages, all import dependencies are
fully resolved. Because this example uses YANG modules that have
been standardized before YANG semantic versioning, the modules are
referenced by revision date rather than version.
<CODE BEGINS> file "example-network-device@1.1.2.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-network-device",
"version": "1.1.2",
"timestamp": "2018-12-13T17:00:00Z",
"organization": "IETF NETMOD Working Group",
"contact": "WG Web: <http://tools.ietf.org/wg/netmod/>, \
WG List: <mailto:netmod@ietf.org>",
"description": "Example IETF network device YANG package. \
This package defines a small sample set of YANG modules that could \
represent the basic set of modules that a standard network device \
might be expected to support.",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-base-types",
"version": "1.0.0",
"location": [
"https://example.org/yang/packages/\
example-base-types@1.0.0.ypkg"
]
}
Wilton, et al. Expires 7 January 2027 [Page 72]
Internet-Draft YANG Packages July 2026
],
"module": [
{
"name": "iana-crypt-hash",
"version": "2014-08-06",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
iana-crypt-hash@2014-08-06.yang"
]
},
{
"name": "ietf-system",
"version": "2014-08-06",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-system@2014-08-06.yang"
]
},
{
"name": "iana-if-type",
"version": "2026-03-17",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
iana-if-type@2026-03-17.yang"
]
},
{
"name": "ietf-interfaces",
"version": "2018-02-20",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-interfaces@2018-02-20.yang"
]
},
{
"name": "ietf-netconf-acm",
"version": "2018-02-14",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-netconf-acm@2018-02-14.yang"
]
},
{
"name": "ietf-key-chain",
"version": "2017-06-15",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-key-chain@2017-06-15.yang"
Wilton, et al. Expires 7 January 2027 [Page 73]
Internet-Draft YANG Packages July 2026
]
},
{
"name": "ietf-ip",
"version": "2018-02-22",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-ip@2018-02-22.yang"
]
}
],
"feature": [
"ietf-system:authentication",
"ietf-system:local-users",
"ietf-system:radius",
"ietf-system:radius-authentication",
"ietf-ip:ipv6-privacy-autoconf"
]
}
}
}
}
}
<CODE ENDS>
A.1.4. Example Routing Types YANG package
An example package that contains routing type modules used by the
example routing package.
The package imports the updated basic types package for common IETF
and IANA type modules.
The "ietf-routing-types" and "ietf-bgp-types" modules are included as
implemented modules, rather than import-only modules, because they
define identities that may be referenced at runtime. An alternative
design would be to include them as import-only modules and then
require any package containing modules that reference those
identities to re-include them as implemented modules.
<CODE BEGINS> file "example-routing-types@1.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-routing-types",
Wilton, et al. Expires 7 January 2027 [Page 74]
Internet-Draft YANG Packages July 2026
"version": "1.0.0",
"timestamp": "2026-03-20T17:52:47.202513Z",
"description": "Example package containing routing types \
modules",
"includes": {
"package": [
{
"name": "example-base-types",
"version": "1.1.0",
"location": [
"https://example.org/yang/packages/\
example-base-types@1.1.0.ypkg"
]
}
],
"module": [
{
"name": "ietf-routing-types",
"version": "2017-12-04",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-routing-types@2017-12-04.yang"
]
},
{
"name": "ietf-bgp-types",
"version": "2018-05-09",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-bgp-types@2018-05-09.yang"
]
}
],
"import-only-module": [
{
"name": "iana-routing-types",
"version": "2017-12-04",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
iana-routing-types@2017-12-04.yang"
]
}
]
}
}
}
}
}
Wilton, et al. Expires 7 January 2027 [Page 75]
Internet-Draft YANG Packages July 2026
<CODE ENDS>
A.1.5. Example Basic Routing YANG package
This section provides an instance data file example of a basic
Routing YANG package formatted in JSON.
This example package is intended to represent the standard set of
YANG modules, with import dependencies, that builds upon the example-
network-device and example-routing-types YANG packages to add support
for basic dynamic routing and ACLs. The package also enables ACL
features for matching IPv6 packet fields and configuring IPv6 ACL
entries, with the expectation that all devices that implement this
package will support these features.
As for all YANG packages, all import dependencies are fully resolved.
Because this example uses YANG modules that have been standardized
before YANG semantic versioning, the modules are referenced by
revision date rather than version.
<CODE BEGINS> file "example-routing@1.3.1.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-routing",
"version": "1.3.1",
"timestamp": "2018-12-13T17:00:00Z",
"description": "This package defines a small sample set of \
IETF routing YANG modules that could represent the set of IETF \
routing functionality that a basic IP network device might be \
expected to support.",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.1.2",
"location": [
"https://example.org/yang/packages/\
example-network-device@1.1.2.ypkg"
]
},
{
"name": "example-routing-types",
"version": "1.0.0",
Wilton, et al. Expires 7 January 2027 [Page 76]
Internet-Draft YANG Packages July 2026
"location": [
"https://example.org/yang/packages/\
example-routing-types@1.0.0.ypkg"
]
}
],
"module": [
{
"name": "ietf-routing",
"version": "2018-03-13",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-routing@2018-03-13.yang"
]
},
{
"name": "ietf-ipv4-unicast-routing",
"version": "2018-03-13",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-ipv4-unicast-routing@2018-03-13.yang"
]
},
{
"name": "ietf-ipv6-unicast-routing",
"version": "2018-03-13",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-ipv6-unicast-routing@2018-03-13.yang"
]
},
{
"name": "ietf-isis",
"version": "2018-12-11",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-isis@2018-12-11.yang"
]
},
{
"name": "ietf-interfaces-common",
"version": "2018-07-02",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-interfaces-common@2018-07-02.yang"
]
},
{
Wilton, et al. Expires 7 January 2027 [Page 77]
Internet-Draft YANG Packages July 2026
"name": "ietf-if-l3-vlan",
"version": "2017-10-30",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-if-l3-vlan@2017-10-30.yang"
]
},
{
"name": "ietf-routing-policy",
"version": "2018-10-19",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-routing-policy@2018-10-19.yang"
]
},
{
"name": "ietf-bgp",
"version": "2018-05-09",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-bgp@2018-05-09.yang"
]
},
{
"name": "ietf-access-control-list",
"version": "2018-11-06",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-access-control-list@2018-11-06.yang"
]
}
],
"import-only-module": [
{
"name": "ietf-packet-fields",
"version": "2018-11-06",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-packet-fields@2018-11-06.yang"
]
},
{
"name": "ietf-ethertypes",
"version": "2018-11-06",
"location": [
"https://www.iana.org/assignments/yang-parameters/\
ietf-ethertypes@2018-11-06.yang"
]
Wilton, et al. Expires 7 January 2027 [Page 78]
Internet-Draft YANG Packages July 2026
}
],
"feature": [
"ietf-access-control-list:match-on-ipv6",
"ietf-access-control-list:ipv6"
]
}
}
}
}
}
<CODE ENDS>
A.2. Device Implementation Examples
This section provides examples of how a device may implement YANG
packages, and advertise them to clients. It reuses some of the
example packages defined in Appendix A.1, but extended with device
implementation specific modifications to those packages.
A.2.1. device-routing YANG package
This example illustrates a vendor's device-routing package that
includes the example-routing package, and hence all its dependencies,
but also removes a YANG module that is not implemented on the device,
removes enabled features that are not supported, adds a YANG module
containing deviations to other YANG modules, and adds a vendor
device-isis-extensions YANG module, version 1.2.3, that augments the
base ietf-isis package.
Wilton, et al. Expires 7 January 2027 [Page 79]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "device-routing@1.0.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "device-routing",
"version": "1.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example vendor device routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-routing",
"version": "1.3.1"
}
],
"module": [
{
"name": "vendor-ietf-bgp-deviations",
"version": "2026-06-22"
},
{
"name": "device-isis-extensions",
"version": "1.2.3"
}
]
},
"excludes": {
"module": [
"ietf-if-l3-vlan"
],
"feature": [
"ietf-system:radius",
"ietf-system:radius-authentication"
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 80]
Internet-Draft YANG Packages July 2026
A.2.2. YANG library advertisement for device-routing
The following JSON fragment illustrates how the device may advertise
the datastore schema using YANG library and YANG package bindings.
The YANG library "module-set" contains the resolved set of modules
for the device schema, but the module details are elided for brevity.
The schema is bound to the "device-routing" package, and the top-
level package list advertises the directly referenced package and all
packages that it includes, recursively. Again, the contents of the
packages have been elided for brevity, but the content matches the
content previously illustrated in this document.
<CODE BEGINS> file "device-routing-library.json"
{
"ietf-yang-instance-data:instance-data-set": {
"name": "Device routing datastore schema",
"description": "YANG library and package advertisement",
"content-data": {
"ietf-yang-library:library": {
"module-set": [
{
"name": "device-module-set",
"module": [
"... implemented module details elided ..."
],
"import-only-module": [
"... import-only module details elided ..."
]
}
],
"schema": [
{
"name": "device-routing datastore schema",
"module-set": [
"device-module-set"
],
"ietf-yl-packages:package": [
{
"name": "device-routing",
"version": "1.0.0"
}
]
}
],
"content-id": "3a6f9c2d7e0b1845"
},
"ietf-yang-packages:packages": {
"package": [
Wilton, et al. Expires 7 January 2027 [Page 81]
Internet-Draft YANG Packages July 2026
{
"name": "device-routing",
"version": "1.0.0",
"description": "Example vendor device routing package",
"...": "package details elided"
},
{
"name": "example-routing",
"version": "1.3.1",
"description": "Example basic routing package",
"...": "package details elided"
},
{
"name": "example-network-device",
"version": "1.1.2",
"description": "Example network device package",
"...": "package details elided"
},
{
"name": "example-routing-types",
"version": "1.0.0",
"description": "Example routing types package",
"...": "package details elided"
},
{
"name": "example-base-types",
"version": "1.1.0",
"description": "Example updated base types package",
"...": "package details elided"
},
{
"name": "example-base-types",
"version": "1.0.0",
"description": "Example base types package",
"...": "package details elided"
}
]
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 82]
Internet-Draft YANG Packages July 2026
A.2.3. Hotfix Package Example
This example illustrates how a vendor can advertise a small hotfix
package that updates one module in the device schema without
publishing a complete replacement for the baseline device package.
The hotfix package is marked as incomplete (i.e., "complete" =
"false") because it contains only the updated device-isis-extensions
module, and relies on the other packages bound to the datastore
schema to provide the rest of the schema. The hotfix package lists
the "device-routing" package in its "depends-on/package" list to
identify the baseline device package that the hotfix applies to,
without including that baseline package as part of the hotfix package
definition.
The updated device-isis-extensions module uses version
1.2.4_compatible. This follows the YANG Semver versioning rules
described in [I-D.ietf-netmod-yang-semver]. In this example, it is
assumed that version 1.3.0 was not usable because it had previously
been published with different content.
Wilton, et al. Expires 7 January 2027 [Page 83]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "vendor-isis-hotfix@1.0.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "vendor-isis-hotfix",
"version": "1.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example vendor ISIS hotfix package",
"reference": "XXX, draft-ietf-netmod-yang-packages;",
"complete": false,
"includes": {
"module": [
{
"name": "device-isis-extensions",
"version": "1.2.4_compatible"
}
]
},
"depends-on": {
"package": [
{
"name": "device-routing",
"version": "1.0.0"
}
]
}
}
}
}
}
<CODE ENDS>
When the hotfix package is used, the YANG library schema package
binding lists both the baseline device package and the hotfix
package, making use of automatic conflict resolution, as per
Section 4.1, to automatically select the later version
(1.2.4_compatible) of the device-isis-extensions YANG module. The
YANG library module-set contents would be updated so that the
"device-module-set" contains device-isis-extensions version
"1.2.4_compatible" rather than previous version, "1.2.3". The YANG
library "content-id" would also change because the YANG library
content has changed, and a yang-library-update notification would be
generated.
Wilton, et al. Expires 7 January 2027 [Page 84]
Internet-Draft YANG Packages July 2026
However, the goal is that the client doesn't need to fetch the
updated YANG library information at all, and just rely on the
advertised schema package bindings and the location URLs to fetch the
packages and modules and fully resolve the schema off the device.
<CODE BEGINS> file "device-routing-hotfix-library.json"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"name": "Device routing datastore schema with ISIS hotfix",
"description": "YANG library and package advertisement",
"content-data": {
"ietf-yang-library:library": {
"module-set": [
{
"name": "device-module-set",
"module": [
{
"name": "device-isis-extensions",
"revision": "2026-06-22",
"ietf-yang-library-semver:version": \
"1.2.4_compatible"
},
"... other implemented module details elided ..."
],
"import-only-module": [
"... import-only module details elided ..."
]
}
],
"schema": [
{
"name": "device-routing datastore schema",
"module-set": [
"device-module-set"
],
"ietf-yl-packages:package": [
{
"name": "device-routing",
"version": "1.0.0"
},
{
"name": "vendor-isis-hotfix",
"version": "1.0.0"
}
]
}
Wilton, et al. Expires 7 January 2027 [Page 85]
Internet-Draft YANG Packages July 2026
],
"content-id": "9f2c6a0d4b8e7135"
},
"ietf-yang-packages:packages": {
"package": [
{
"name": "vendor-isis-hotfix",
"version": "1.0.0",
"description": "Example vendor ISIS hotfix package",
"...": "package details elided"
},
"... other advertised package entries elided ..."
]
}
}
}
}
<CODE ENDS>
A.3. Package Versioning Examples
This section provides examples of versioning packages. The examples
are non-normative, and for brevity only the relevant package
definition fields are shown in the package instance-data files.
The examples illustrate the history of a single package, "example-
versioned-routing". Each example highlights whether the package
definition changes are backwards-compatible (BC), non-backwards-
compatible (NBC), or editorial.
The following diagram summarizes the version lineage illustrated by
the examples. The lineage is linear because these examples focus on
successive updates to a single package definition.
1.0.0 - Initial published version
|
1.1.0 - BC: add package, module, and mandatory features
|
2.0.0 - NBC: downref package and remove module
|
3.0.0 - NBC: add module containing deviations
|
4.0.0 - NBC: remove IPv4 feature, downref module, and add module
|
4.0.1 - Editorial: update module location information
Wilton, et al. Expires 7 January 2027 [Page 86]
Internet-Draft YANG Packages July 2026
A.3.1. Initial Package Version
The initial package version defines a small routing schema. This
version is used as the starting point for the later examples.
<CODE BEGINS> file "example-versioned-routing@1.0.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "1.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.1.2"
}
],
"module": [
{
"name": "example-routing-core",
"version": "2.0.0"
},
{
"name": "example-routing-acl",
"version": "1.0.0"
}
],
"feature": [
"example-routing-core:ipv4"
]
}
}
}
}
}
<CODE ENDS>
A.3.2. Backwards-compatible Update
In version 1.1.0, a new included package, a new module, and new
mandatory features are added. These are all backwards-compatible
changes, so the minor version is incremented.
Wilton, et al. Expires 7 January 2027 [Page 87]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-versioned-routing@1.1.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "1.1.0",
"version-description": "Adds telemetry, policy, and new \
features.",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.1.2"
},
{
"name": "example-routing-telemetry",
"version": "1.0.0"
}
],
"module": [
{
"name": "example-routing-core",
"version": "2.0.0"
},
{
"name": "example-routing-acl",
"version": "1.0.0"
},
{
"name": "example-routing-policy",
"version": "1.0.0"
}
],
"feature": [
"example-routing-core:ipv4",
"example-routing-core:ipv6",
"example-routing-policy:statistics"
]
}
}
}
}
Wilton, et al. Expires 7 January 2027 [Page 88]
Internet-Draft YANG Packages July 2026
}
<CODE ENDS>
A.3.3. Package Downref and Module Removal
In version 2.0.0, the "example-network-device" package reference is
changed to an older package version, and the previously included
"example-routing-acl" module is removed. Both changes are NBC, so
the major version is incremented.
Wilton, et al. Expires 7 January 2027 [Page 89]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-versioned-routing@2.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "2.0.0",
"version-description": "Downrefs a package and removes the \
ACL module.",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.0.0"
},
{
"name": "example-routing-telemetry",
"version": "1.0.0"
}
],
"module": [
{
"name": "example-routing-core",
"version": "2.0.0"
},
{
"name": "example-routing-policy",
"version": "1.0.0"
}
],
"feature": [
"example-routing-core:ipv4",
"example-routing-core:ipv6",
"example-routing-policy:statistics"
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 90]
Internet-Draft YANG Packages July 2026
A.3.4. Adding a Deviations Module
In version 3.0.0, a new module containing deviations that modified
some data nodes and marked other data nodes as not-supported. The
deviations remove or restrict nodes that were present in the previous
resolved package schema. The change is therefore NBC, and the major
version is incremented.
Wilton, et al. Expires 7 January 2027 [Page 91]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-versioned-routing@3.0.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "3.0.0",
"version-description": "Adds NBC vendor deviations.",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.0.0"
},
{
"name": "example-routing-telemetry",
"version": "1.0.0"
}
],
"module": [
{
"name": "example-routing-core",
"version": "2.0.0"
},
{
"name": "example-routing-policy",
"version": "1.0.0"
},
{
"name": "vendor-routing-deviations",
"version": "2026-06-22"
}
],
"feature": [
"example-routing-core:ipv4",
"example-routing-core:ipv6",
"example-routing-policy:statistics"
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 92]
Internet-Draft YANG Packages July 2026
A.3.5. Mixed Backwards-compatible and NBC Changes
In version 4.0.0, the mandatory "example-routing-core:ipv4" feature
is removed and the "example-routing-core" module is changed to an
older version. Both of these are NBC changes. A new "example-isis"
module is also added, which would otherwise be a BC change, but the
overall package update is still NBC, so the major version is
incremented.
<CODE BEGINS> file "example-versioned-routing@4.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "4.0.0",
"version-description": "Removes IPv4, downrefs core, adds \
ISIS.",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.0.0"
},
{
"name": "example-routing-telemetry",
"version": "1.0.0"
}
],
"module": [
{
"name": "example-routing-core",
"version": "1.5.0"
},
{
"name": "example-routing-policy",
"version": "1.0.0"
},
{
"name": "vendor-routing-deviations",
"version": "2026-06-22"
},
{
Wilton, et al. Expires 7 January 2027 [Page 93]
Internet-Draft YANG Packages July 2026
"name": "example-isis",
"version": "1.0.0"
}
],
"feature": [
"example-routing-core:ipv6",
"example-routing-policy:statistics"
]
}
}
}
}
}
<CODE ENDS>
A.3.6. Editorial Location Update
In version 4.0.1, the referenced module versions are unchanged, but
location information for "example-routing-core" is updated. This
does not change the resolved package schema, so it is an editorial
package update. The same classification would apply if the module
version had already been resolved from an included package and the
package explicitly listed that same module version only to provide
updated location information.
<CODE BEGINS> file "example-versioned-routing@4.0.1.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-versioned-routing",
"version": "4.0.1",
"version-description": "Updates module location \
information.",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example versioned routing package",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-network-device",
"version": "1.0.0"
},
{
"name": "example-routing-telemetry",
"version": "1.0.0"
Wilton, et al. Expires 7 January 2027 [Page 94]
Internet-Draft YANG Packages July 2026
}
],
"module": [
{
"name": "example-routing-core",
"version": "1.5.0",
"location": [
"https://example.org/yang/\
example-routing-core@1.5.0.yang"
]
},
{
"name": "example-routing-policy",
"version": "1.0.0"
},
{
"name": "vendor-routing-deviations",
"version": "2026-06-22"
},
{
"name": "example-isis",
"version": "1.0.0"
}
],
"feature": [
"example-routing-core:ipv6",
"example-routing-policy:statistics"
]
}
}
}
}
}
<CODE ENDS>
A.4. Package Resolution Examples
This section provides examples of package resolution. The examples
are non-normative, and for brevity the package instance data files
omit location information except where used to illustrate a specific
point.
Wilton, et al. Expires 7 January 2027 [Page 95]
Internet-Draft YANG Packages July 2026
As described in Section 4, resolving a set of packages produces a
YANG schema: a set of implemented modules, import-only modules,
enabled features, deviations, and mount points. Included packages
are recursively resolved first. The resulting package schemas are
then combined using automatic module resolution, and finally any
local module, import-only-module, feature, or exclusion entries in
the including package are applied.
A.4.1. Recursive Package Resolution
The following examples define two versions of a common package. The
access package includes version 1.0.0 of that common package, while
the routing package includes version 1.4.0. This illustrates that
package resolution is performed on the resolved module sets, not by
choosing one package version and discarding the other package
version.
Wilton, et al. Expires 7 January 2027 [Page 96]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-resolution-common@1.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-resolution-common",
"version": "1.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example common package for resolution \
examples",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"module": [
{
"name": "example-resolution-base",
"version": "1.0.0"
}
],
"import-only-module": [
{
"name": "example-resolution-types",
"version": "1.0.0"
}
],
"feature": [
"example-resolution-base:basic"
]
}
}
}
}
}
<CODE ENDS>
Resolved contents for "example-resolution-common" version 1.0.0:
* Implemented modules: example-resolution-base@1.0.0.
* Import-only modules: example-resolution-types@1.0.0.
* Enabled features: example-resolution-base:basic.
Since this package does not include any other packages, the resolved
package schema is the module, import-only module, and feature set
that it directly defines.
Wilton, et al. Expires 7 January 2027 [Page 97]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-resolution-common@1.4.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-resolution-common",
"version": "1.4.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Updated common package for resolution \
examples",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"module": [
{
"name": "example-resolution-base",
"version": "1.4.0"
},
{
"name": "example-resolution-telemetry",
"version": "1.2.0"
}
],
"import-only-module": [
{
"name": "example-resolution-types",
"version": "1.4.0"
}
],
"feature": [
"example-resolution-base:basic",
"example-resolution-telemetry:events"
]
}
}
}
}
}
<CODE ENDS>
Resolved contents for "example-resolution-common" version 1.4.0:
* Implemented modules: example-resolution-base@1.4.0, example-
resolution-telemetry@1.2.0.
* Import-only modules: example-resolution-types@1.4.0.
Wilton, et al. Expires 7 January 2027 [Page 98]
Internet-Draft YANG Packages July 2026
* Enabled features: example-resolution-base:basic, example-
resolution-telemetry:events.
This newer package version selects newer versions of the base and
types modules, and adds the telemetry module and its enabled feature.
Wilton, et al. Expires 7 January 2027 [Page 99]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-resolution-access@2.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-resolution-access",
"version": "2.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example access package for resolution \
examples",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-resolution-common",
"version": "1.0.0"
}
],
"module": [
{
"name": "example-resolution-acl",
"version": "1.1.0",
"location": [
"example:location-qux"
]
},
{
"name": "example-resolution-transport",
"version": "1.2.0",
"location": [
"example:location-foo",
"example:location-bar"
]
}
],
"feature": [
"example-resolution-acl:ipv4"
]
}
}
}
}
}
<CODE ENDS>
Resolved contents for "example-resolution-access" version 2.0.0:
Wilton, et al. Expires 7 January 2027 [Page 100]
Internet-Draft YANG Packages July 2026
* Included packages: example-resolution-common@1.0.0.
* Implemented modules: example-resolution-base@1.0.0, example-
resolution-acl@1.1.0 [example:location-qux], example-resolution-
transport@1.2.0 [example:location-foo, example:location-bar].
* Import-only modules: example-resolution-types@1.0.0.
* Enabled features: example-resolution-base:basic, example-
resolution-acl:ipv4.
The included common package is resolved first, then the local ACL and
transport modules and ACL feature are added. The ACL and transport
module entries include location information; the transport module
uses a shared primary location and an access-specific secondary
location.
Wilton, et al. Expires 7 January 2027 [Page 101]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-resolution-routing@3.0.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-resolution-routing",
"version": "3.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Example routing package for resolution \
examples",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-resolution-common",
"version": "1.4.0"
}
],
"module": [
{
"name": "example-resolution-acl",
"version": "1.3.0"
},
{
"name": "example-resolution-routing",
"version": "1.3.0"
},
{
"name": "example-resolution-transport",
"version": "1.2.0",
"location": [
"example:location-foo",
"example:location-baz"
]
}
],
"feature": [
"example-resolution-routing:statistics"
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 102]
Internet-Draft YANG Packages July 2026
Resolved contents for "example-resolution-routing" version 3.0.0:
* Included packages: example-resolution-common@1.4.0.
* Implemented modules: example-resolution-base@1.4.0, example-
resolution-telemetry@1.2.0, example-resolution-acl@1.3.0, example-
resolution-routing@1.3.0, example-resolution-transport@1.2.0
[example:location-foo, example:location-baz].
* Import-only modules: example-resolution-types@1.4.0.
* Enabled features: example-resolution-base:basic, example-
resolution-telemetry:events, example-resolution-
routing:statistics.
The routing package includes the newer common package version, so its
resolved package schema contains the newer base and import-only type
modules, plus telemetry, routing, ACL, and transport modules. The
transport module is the same version as in the access package, with
the same primary location and a routing-specific secondary location.
A.4.2. Local Entries and Exclusions
The top-level device package includes both the access and routing
packages. Recursively, this also brings in both versions of
"example-resolution-common". There is no mechanism to exclude an
included package. Instead, resolution operates on the modules and
features contributed by those packages. This package locally selects
version 1.1.0 of "example-resolution-acl", excludes the telemetry
module, and excludes the routing statistics feature.
Wilton, et al. Expires 7 January 2027 [Page 103]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-resolution-device@4.0.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-resolution-device",
"version": "4.0.0",
"timestamp": "2026-06-22T00:00:00Z",
"description": "Top-level package for resolution examples",
"reference": "XXX, draft-ietf-netmod-yang-packages",
"includes": {
"package": [
{
"name": "example-resolution-access",
"version": "2.0.0"
},
{
"name": "example-resolution-routing",
"version": "3.0.0"
}
],
"module": [
{
"name": "example-resolution-acl",
"version": "1.1.0",
"location": [
"example:location-quux"
]
}
]
},
"excludes": {
"module": [
"example-resolution-telemetry"
],
"feature": [
"example-resolution-routing:statistics"
]
}
}
}
}
}
<CODE ENDS>
Resolved contents for "example-resolution-device" version 4.0.0:
Wilton, et al. Expires 7 January 2027 [Page 104]
Internet-Draft YANG Packages July 2026
* Included packages: example-resolution-access@2.0.0, example-
resolution-routing@3.0.0, example-resolution-common@1.0.0,
example-resolution-common@1.4.0.
* Implemented modules: example-resolution-base@1.4.0, example-
resolution-transport@1.2.0 [example:location-foo,
example:location-bar, example:location-baz], example-resolution-
acl@1.1.0 [example:location-quux], example-resolution-
routing@1.3.0.
* Import-only modules: example-resolution-types@1.0.0, example-
resolution-types@1.4.0.
* Enabled features: example-resolution-base:basic, example-
resolution-acl:ipv4.
The common package is still listed at both versions because packages
themselves are not excluded during resolution; instead, automatic
module resolution selects example-resolution-base@1.4.0 from the two
common package versions. The local module entry for example-
resolution-acl@1.1.0 overrides the newer ACL version inherited from
the routing package. Since the local ACL module entry is explicitly
listed by the device package, its location list also replaces the
location list inherited from the access package for the same ACL
module version. The telemetry module is removed by the excludes/
module list, which also removes its enabled feature. The routing
statistics feature is explicitly removed by the excludes/feature
list.
If multiple package entries contribute the same module at the same
version, the resulting module entry is only included once and the
location lists are merged. In this example, "example-resolution-
transport" version 1.2.0 is included via both the access and routing
packages. Both paths list the same primary location, and each path
also lists a different secondary location. The resolved module entry
contains the deduplicated union of those locations: the shared
primary location, the access-specific secondary location, and the
routing-specific secondary location.
A.5. Package Exclusion Examples
This section provides examples of how to exclude modules, and
packages in a package definition, and to remove enabled features.
The examples are non-normative, and for brevity, some expected
information (e.g., locations) are omitted.
Wilton, et al. Expires 7 January 2027 [Page 105]
Internet-Draft YANG Packages July 2026
A.5.1. Example of excluding modules and an enabled feature
The following example defines two YANG packages.
The first package, "example-ab", implements two example modules,
"example-module-a" and "example-module-b", two related types modules,
and declares two enabled features.
The second package, "example-c", imports the first package, but
excludes the implemented "example-module-a" module, the import-only
"example-module-b-types" module, and the enabled feature "bar" from
the "example-module-b" module.
TODO - Should that feature have been implicitly removed?
The third figure shows the resulting schema in YANG Library format,
but with namespaces and locations elided for brevity.
Wilton, et al. Expires 7 January 2027 [Page 106]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-ab@0.1.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-ab",
"version": "0.1.0",
"timestamp": "2026-03-20T17:52:47.188303Z",
"description": "Example package defining modules A, B and \
associated types",
"includes": {
"module": [
{
"name": "example-module-a",
"version": "1.0.0"
},
{
"name": "example-module-b",
"version": "1.1.0"
}
],
"import-only-module": [
{
"name": "example-module-a-types",
"version": "1.0.0"
},
{
"name": "example-module-b-types",
"version": "1.1.0"
}
],
"feature": [
"example-module-a:foo",
"example-module-b:bar"
]
}
}
}
}
}
<CODE ENDS>
The "example-c" Yang Package example illustrates exclusions of
modules, import-only-modules and features.
Wilton, et al. Expires 7 January 2027 [Page 107]
Internet-Draft YANG Packages July 2026
<CODE BEGINS> file "example-c@0.1.0.ypkg"
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-yang-instance-data:instance-data-set": {
"content-data": {
"ietf-yang-package-instance:package": {
"name": "example-c",
"version": "0.1.0",
"timestamp": "2026-03-20T17:52:47.202747Z",
"description": "Example package importing A, removing B and \
adding C",
"includes": {
"package": [
{
"name": "example-ab",
"version": "0.1.0",
"location": [
"https://example.org/yang/packages/\
example-ab@0.1.0.ypkg"
]
}
],
"module": [
{
"name": "example-module-c",
"version": "2.0.0"
}
]
},
"excludes": {
"module": [
"example-module-b"
],
"import-only-module": [
{
"name": "example-module-b-types"
}
],
"feature": [
"example-module-b:bar"
]
}
}
}
}
}
<CODE ENDS>
Wilton, et al. Expires 7 January 2027 [Page 108]
Internet-Draft YANG Packages July 2026
The following JSON illustrates what a resulting YANG library file
would look like once all dependencies in the "example-c" YANG package
have been resolved.
<CODE BEGINS> file "example-c-library@0.1.0.ypkg"
{
"ietf-yang-instance-data:instance-data-set": {
"name": "Package example-c@0.1.0 schema",
"description": "YANG package definition",
"content-data": {
"ietf-yang-library:library": {
"module-set": [
{
"name": "Package example-c@0.1.0",
"module": [
{
"name": "example-module-c",
"revision": "2.0.0",
"ietf-yang-library-semver:version": "2.0.0"
},
{
"name": "example-module-a",
"revision": "1.0.0",
"ietf-yang-library-semver:version": "1.0.0",
"feature": [
"foo"
]
}
],
"import-only-module": [
{
"name": "example-module-a-types",
"revision": "1.0.0",
"ietf-yang-library-semver:version": "1.0.0"
}
]
}
],
"schema": [
{
"name": "Package example-c@0.1.0 schema",
"module-set": [
"Package example-c@0.1.0"
]
}
],
"content-id": "c826ea09"
}
Wilton, et al. Expires 7 January 2027 [Page 109]
Internet-Draft YANG Packages July 2026
}
}
}
<CODE ENDS>
A.6. Mounted Package Examples
This section provides examples of XXX when using mounted packages.
The examples are non-normative, and for brevity, some expected
information (e.g., locations) are omitted.
A.6.1. Example of package with a mounted package
This example illustrates a YANG package representing a network device
that mounts a routing package at the network-instance mount point.
TODO - Can we use example that is the same, or very similar, to the
network-instances example?
TODO - Indicate that this is a minimal example to illustrate a
concept, and leaves out some optional elements that would be expected
in a full implementation.
A.6.2. Example of a package replacing the mounted schema
This example illustrates an implementation of the mounted package
defined in XXX, but that modifies the mounted package.
Although this example illustrates applying deviations to the schema
of a mounted package, the same mechanism can be used to change the
implemented package version, remove a mounted package in its
entirety, remove modules from a mounted package, change enabled
features, change the behavior of recursive mounts, etc.
TODO - Probably need more than one example.
Authors' Addresses
Robert Wilton (editor)
Cisco Systems, Inc.
Email: rwilton@cisco.com
Reshad Rahman
Equinix
Email: reshad@yahoo.com
Wilton, et al. Expires 7 January 2027 [Page 110]
Internet-Draft YANG Packages July 2026
Joe Clarke
Cisco Systems, Inc.
Email: jclarke@cisco.com
Jason Sterne
Nokia
Email: jason.sterne@nokia.com
Wilton, et al. Expires 7 January 2027 [Page 111]