YANG Packages

Internet-Draft	YANG Packages	July 2026
Wilton, et al.	Expires 6 January 2027	[Page]

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.¶

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
    +-- 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

3.1. Package definition rules

For a YANG package to be valid, it MUST conform to all the following rules:¶

Each (package name, version) pairing MUST define a globally unique version of that package definition.¶
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.¶
YANG packages MUST be versioned using YANG Semver, [I-D.ietf-netmod-yang-semver]. Versioning YANG packages is further described in Section 6.1.¶
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.2.¶
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.¶
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.¶
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.¶
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.¶
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.¶
Multiple versions/revisions of an import-only module MAY be listed, but any extraneous import-only module versions SHOULD be removed.¶
A package definition MUST NOT include the same module name in both the 'includes/module' and 'excludes/module' lists.¶
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.¶
A package definition MUST NOT include the same feature name in both the 'includes/feature' and 'excludes/feature' lists.¶
A package definition MUST NOT exclude a module and list features defined by that module in the 'includes/feature' list.¶
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.¶
Finally, standard rules for YANG instance data apply. E.g., entries in the various lists MUST be unique by any list key.¶

3.2. 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.¶

Also see Section 5.3 for details on cases when referentially incomplete packages are helpful.¶

3.2.1. Incomplete package dependencies

When a package is referentially incomplete, the "depends-on/package" list can identify other package versions that are expected to be resolved along with the incomplete package to produce a complete schema. This provides a machine-readable indication of the packages that supply missing import dependencies or other schema context needed by the incomplete package.¶

The "depends-on/package" list is not equivalent to the "includes/package" list. Packages listed in "depends-on/package" are not included as part of the incomplete package definition itself and do not, by themselves, change the resolved schema represented by that package. Instead, they identify additional package definitions that a server or client can use when constructing a complete schema from the incomplete package.¶

3.3. 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.4. 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.¶

[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.5. 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.¶

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.¶

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.¶
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.¶

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.¶

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 is selected in the resolved package schema. This allows an extra 'bugfix' 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:¶

The file MUST be encoded in JSON.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The 'revision' list in the instance data file MUST NOT be used, since versioning is handled by the package definition.¶
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:¶

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.¶

========== 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 \
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>

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 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.¶

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.¶

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.¶
: 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):¶

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.¶

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.9.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;
    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-06-12 {
    ys:version 0.9.0;
    description
      "Initial revision";
    reference
      "RFC XXXX: YANG Packages";
  }


  /*
   * 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;

    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";

    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
            "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.";

    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;
      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 {
      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
          "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;
      }

      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 {
      when "../complete = 'false'";
      description
        "Lists packages that are depended on by this 'incomplete'
         package definition.

         All packages listed in this list MUST be fetched and
         resolved by the server or produce a complete package
         definition.

         This additional schema information SHOULD be provided by a
         server 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.";
      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 'incomplete' 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
         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
           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
          "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].¶

<CODE BEGINS> file "ietf-yang-package-instance#0.9.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.8.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
     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-06-12 {
    ys:version 0.9.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.9.0.yang"

module ietf-yang-packages {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages";
  prefix pkgs;

  import ietf-yang-semver  {
    prefix ys;
    reference "XXXX: YANG Semantic Versioning";
  }

  import ietf-yang-package-types {
    prefix pkg-types;
    ys:recommended-min-version 0.8.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.
  revision 2026-06-12 {
    ys:version 0.9.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;
    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.9.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.8.0;
    reference "RFC XXX: YANG Packages.";
  }

  import ietf-yang-packages {
    prefix pkgs;
    ys:recommended-min-version 0.8.0;
    reference "RFC XXX: YANG Packages.";
  }

  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-06-12 {
    ys:version 0.9.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
         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.9.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.8.0;
    reference "RFC XXX: this RFC.";
  }

  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,
     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-06-12 {
    ys:version 0.9.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 {
        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.";
        }
      }
    }
  }
}

<CODE ENDS>

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.¶

Table 1: Common example packages
Package	Versions	Content Overview
example-base-types	1.0.0, 1.1.0	Base IETF and IANA type 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.

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",
              "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.¶

<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>

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"
              ]
            }
          ],
          "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"
              ]
            },
            {
              "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",
        "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"
              ]
            }
          ]
        }
      }
    }
  }
}

<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",
              "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"
              ]
            },
            {
              "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"
              ]
            }
          ],
          "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.¶

<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>

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": [
          {
            "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>

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 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.¶

<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"
            }
          ]
        }
      }
    }
  }
}

<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.¶

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"
              }
            ]
          }
        ],
        "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

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.¶

<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"
          ]
        }
      }
    }
  }
}

<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.¶

<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>

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.¶

<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>

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"
            },
            {
              "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"
            }
          ],
          "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.¶

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.¶

<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.¶

<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.¶
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.¶

<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:¶

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.¶

<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>

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.¶

<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:¶

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.¶

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.¶

<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.¶

<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>

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"
      }
    }
  }
}

<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.¶