diff --git a/.gitignore b/.gitignore index d2003e0..ba499d6 100644 --- a/.gitignore +++ b/.gitignore @@ -4,4 +4,7 @@ venv /.bsp/ .metals/ .bloop/ -out/ \ No newline at end of file +out/ +*.class +.scala-build/ +.bsp \ No newline at end of file diff --git a/yang-packages/draft-ietf-netmod-yang-packages.txt b/yang-packages/draft-ietf-netmod-yang-packages.txt index 8066ac7..5c4e1f4 100644 --- a/yang-packages/draft-ietf-netmod-yang-packages.txt +++ b/yang-packages/draft-ietf-netmod-yang-packages.txt @@ -5,12 +5,12 @@ Network Working Group R. Wilton, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track R. Rahman -Expires: 29 May 2026 Equinix +Expires: 10 August 2026 Equinix J. Clarke Cisco Systems, Inc. J. Sterne Nokia - 25 November 2025 + 6 February 2026 YANG Packages @@ -37,11 +37,11 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 29 May 2026. + This Internet-Draft will expire on 10 August 2026. Copyright Notice - Copyright (c) 2025 IETF Trust and the persons identified as the + Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. @@ -53,9 +53,9 @@ Copyright Notice -Wilton, et al. Expires 29 May 2026 [Page 1] +Wilton, et al. Expires 10 August 2026 [Page 1] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 This document is subject to BCP 78 and the IETF Trust's Legal @@ -75,78 +75,84 @@ Table of Contents 2.2. Potential Alternative Mechanisms . . . . . . . . . . . . 6 2.3. Open Questions/Issues . . . . . . . . . . . . . . . . . . 7 3. The YANG Package Definition . . . . . . . . . . . . . . . . . 7 - 3.1. Package definition rules . . . . . . . . . . . . . . . . 9 - 3.2. Schema referential completeness . . . . . . . . . . . . . 10 - 3.3. Submodules packages considerations . . . . . . . . . . . 10 - 3.4. Package Mount Points . . . . . . . . . . . . . . . . . . 10 - 3.4.1. Exclusions . . . . . . . . . . . . . . . . . . . . . 11 - 4. Package Resolution . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Automatic Module Version Resolution . . . . . . . . . . . 13 - 5. YANG Package Usage . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. Achieving package name uniqueness . . . . . . . . . . . . 14 - 5.2. Referential completeness and YANG packages . . . . . . . 14 - 5.3. Providing Package Definitions on a Server . . . . . . . . 15 - 5.3.1. Package List . . . . . . . . . . . . . . . . . . . . 15 - 5.3.2. Tree diagram . . . . . . . . . . . . . . . . . . . . 15 - 5.3.3. YANG Library Package Bindings . . . . . . . . . . . . 16 - 5.4. Package Instance Data Files . . . . . . . . . . . . . . . 16 - 5.5. YANG packages as schema for YANG instance data - document . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Package Evolution and Versioning . . . . . . . . . . . . . . 18 - 6.1. Package versioning . . . . . . . . . . . . . . . . . . . 18 - 6.1.1. Updating a package with a new version . . . . . . . . 18 - 6.1.1.1. Non-Backwards-compatible changes . . . . . . . . 18 - 6.1.1.2. Backwards-compatible changes . . . . . . . . . . 19 - 6.1.1.3. Editorial changes . . . . . . . . . . . . . . . . 20 + 3.1. Package definition rules . . . . . . . . . . . . . . . . 10 + 3.2. Schema referential completeness . . . . . . . . . . . . . 11 + 3.3. Submodules packages considerations . . . . . . . . . . . 11 + 3.4. Package Mount Points . . . . . . . . . . . . . . . . . . 11 + 3.4.1. Exclusions . . . . . . . . . . . . . . . . . . . . . 12 + 4. Package Resolution . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Automatic Module Version Resolution . . . . . . . . . . . 14 + 5. YANG Package Usage . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. Achieving package name uniqueness . . . . . . . . . . . . 16 + 5.2. Specifying modules as implemented or import-only . . . . 16 + 5.3. Referential completeness and YANG packages . . . . . . . 17 + 5.4. Providing Package Definitions on a Server . . . . . . . . 17 + 5.4.1. Package List . . . . . . . . . . . . . . . . . . . . 17 + 5.4.2. Tree diagram . . . . . . . . . . . . . . . . . . . . 18 + 5.4.3. YANG Library Package Bindings . . . . . . . . . . . . 18 + 5.5. Package Instance Data Files . . . . . . . . . . . . . . . 19 + 5.6. YANG packages as schema for YANG instance data + document . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Package Evolution and Versioning . . . . . . . . . . . . . . 20 + 6.1. Package versioning . . . . . . . . . . . . . . . . . . . 20 + 6.1.1. Updating a package with a new version . . . . . . . . 21 + 6.1.1.1. Non-Backwards-compatible changes . . . . . . . . 21 + 6.1.1.2. Backwards-compatible changes . . . . . . . . . . 22 + 6.1.1.3. Editorial changes . . . . . . . . . . . . . . . . 23 6.1.2. Guidelines for Package Versions During Package - Development . . . . . . . . . . . . . . . . . . . . . 20 - 7. Package Conformance . . . . . . . . . . . . . . . . . . . . . 21 - 7.1. Resolving Conflicting Module Versions in Included - Packages . . . . . . . . . . . . . . . . . . . . . . . . 21 - 7.2. Exclusions, Deviations . . . . . . . . . . . . . . . . . 21 - 7.3. Use of features in YANG modules and YANG packages . . . . 22 - 7.4. Use of YANG semantic versioning . . . . . . . . . . . . . 22 - - - -Wilton, et al. Expires 29 May 2026 [Page 2] - -Internet-Draft YANG Packages November 2025 - - - 7.5. Implementing package versions . . . . . . . . . . . . . . 23 - 7.6. Use of deviations in YANG packages . . . . . . . . . . . 23 - 7.7. The relationship between packages and datastores . . . . 24 - 8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. ietf-yang-package-types . . . . . . . . . . . . . . . . . 25 - 8.2. ietf-yang-package-instance . . . . . . . . . . . . . . . 37 - 8.3. ietf-yang-package . . . . . . . . . . . . . . . . . . . . 39 - 8.4. ietf-yl-packages . . . . . . . . . . . . . . . . . . . . 43 - 8.5. ietf-yang-inst-data-pkg . . . . . . . . . . . . . . . . . 44 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 49 - 12.2. Informative References . . . . . . . . . . . . . . . . . 52 - Appendix A. Package Examples . . . . . . . . . . . . . . . . . . 52 - A.1. Basic Package Examples . . . . . . . . . . . . . . . . . 52 + Development . . . . . . . . . . . . . . . . . . . . . 23 + 7. Package Conformance . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. Resolving conflicting module versions in included + packages . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.2. Handling multiple included package versions . . . . . . . 25 + 7.3. Exclusions and Deviations . . . . . . . . . . . . . . . . 25 + + + +Wilton, et al. Expires 10 August 2026 [Page 2] + +Internet-Draft YANG Packages February 2026 + + + 7.4. Use of features in YANG modules and YANG packages . . . . 26 + 7.5. Use of YANG semantic versioning for YANG packages . . . . 26 + 7.6. Restrictions on the use of deviations in YANG packages . 27 + 7.7. The relationship between packages and datastores . . . . 27 + 7.8. Using package comparison tools . . . . . . . . . . . . . 29 + 8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. ietf-yang-package-types . . . . . . . . . . . . . . . . . 29 + 8.2. ietf-yang-package-instance . . . . . . . . . . . . . . . 42 + 8.3. ietf-yang-package . . . . . . . . . . . . . . . . . . . . 44 + 8.4. ietf-yl-packages . . . . . . . . . . . . . . . . . . . . 47 + 8.5. ietf-yang-inst-data-pkg . . . . . . . . . . . . . . . . . 49 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 + 9.1. YANG Module Security Considerations . . . . . . . . . . . 52 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 + 10.1. IANA YANG Module and Namespace Registrations . . . . . . 53 + 10.2. IETF YANG Package Registry . . . . . . . . . . . . . . . 54 + 10.3. Media Type Registration for application/ypkg . . . . . . 55 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 + 12.2. Informative References . . . . . . . . . . . . . . . . . 58 + Appendix A. Package Examples . . . . . . . . . . . . . . . . . . 59 + A.1. Basic Package Examples . . . . . . . . . . . . . . . . . 59 A.1.1. Example IETF Basic Types YANG package, version - 1.0.0 . . . . . . . . . . . . . . . . . . . . . . . . 53 + 1.0.0 . . . . . . . . . . . . . . . . . . . . . . . . 60 A.1.2. Example IETF Basic Types YANG package, version - 1.1.0 . . . . . . . . . . . . . . . . . . . . . . . . 54 - A.1.3. Example IETF Network Device YANG package . . . . . . 55 - A.1.4. Example IETF Basic Routing YANG package . . . . . . . 58 - A.2. Package Versioning Examples . . . . . . . . . . . . . . . 61 - A.3. Package Resolution Examples . . . . . . . . . . . . . . . 61 - A.3.1. Example of package import conflict resolution . . . . 61 - A.4. Package Exclusion Examples . . . . . . . . . . . . . . . 64 + 1.1.0 . . . . . . . . . . . . . . . . . . . . . . . . 61 + A.1.3. Example IETF Network Device YANG package . . . . . . 61 + A.1.4. Example IETF Basic Routing YANG package . . . . . . . 64 + A.2. Package Versioning Examples . . . . . . . . . . . . . . . 67 + A.3. Package Resolution Examples . . . . . . . . . . . . . . . 67 + A.3.1. Example of package import conflict resolution . . . . 67 + A.4. Package Exclusion Examples . . . . . . . . . . . . . . . 70 A.4.1. Example of excluding modules and a mandatory - feature . . . . . . . . . . . . . . . . . . . . . . . 64 - A.5. Mounted Package Examples . . . . . . . . . . . . . . . . 68 - A.5.1. Example of package with a mounted package . . . . . . 68 - A.5.2. Example of an package replacing the mounted schema . 68 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 + feature . . . . . . . . . . . . . . . . . . . . . . . 70 + A.5. Mounted Package Examples . . . . . . . . . . . . . . . . 75 + A.5.1. Example of package with a mounted package . . . . . . 75 + A.5.2. Example of an package replacing the mounted schema . 75 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 1. Terminology and Conventions @@ -156,19 +162,18 @@ Internet-Draft YANG Packages November 2025 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. - This document uses the following terminology introduced in YANG - Semantic Versioning [I-D.ietf-netmod-yang-semver]: - - * YANG Semver +Wilton, et al. Expires 10 August 2026 [Page 3] + +Internet-Draft YANG Packages February 2026 -Wilton, et al. Expires 29 May 2026 [Page 3] - -Internet-Draft YANG Packages November 2025 + This document uses the following terminology introduced in YANG + Semantic Versioning [I-D.ietf-netmod-yang-semver]: + * YANG Semver This document uses the following terminology introduced in the Network Management Datastore Architecture [RFC8342]: @@ -195,10 +200,12 @@ Internet-Draft YANG Packages November 2025 * YANG package: a versioned organizational structure used to manage a set of YANG modules that collectively define a package schema. - YANG packages are defined in Section 3. + YANG packages are defined in Section 3. Depending on context, the + term 'YANG package' is often used to refer to a specific version + of a YANG package rather than all versions of a package + definition. - * package schema: The combined set of schema nodes defined by a YANG - package. Package schema can be used to define datastore schema. + * package: An alternative term for 'YANG package'. * backwards-compatible (BC) change: When used in the context of a YANG module, it follows the definition in Section 3.1.1 of @@ -212,25 +219,25 @@ Internet-Draft YANG Packages November 2025 context of a YANG package, it follows the definition in Section 6.1.1.1. - * editorial change: When used in the context of a YANG module, it - follows the definition of an 'editorial change' in 4.4 of - [I-D.ietf-netmod-yang-semver]. When used in the context of a YANG - package, it follows the definition in Section 6.1.1.3. - +Wilton, et al. Expires 10 August 2026 [Page 4] + +Internet-Draft YANG Packages February 2026 -Wilton, et al. Expires 29 May 2026 [Page 4] - -Internet-Draft YANG Packages November 2025 + * editorial change: When used in the context of a YANG module, it + follows the definition of an 'editorial change' in 4.4 of + [I-D.ietf-netmod-yang-semver]. When used in the context of a YANG + package, it follows the definition in Section 6.1.1.3. + * resolved package schema: The resolved package schema is the YANG + schema defined by a package after package resolution has been + performed, as defined in Section 4. The resolved package schema + identifies the implemented modules (with any deviations applied), + import-only modules, enabled features, and schema mount points. - * resolved schema: The resolved schema is the YANG schema defined by - a package after package resolution has been performed, as defined - in Section 4. The resolved schema identifies the implemented - modules (with any deviations applied), import-only modules, - enabled features, and schema mount points. + * package schema: An alternative term for 'resolved package schema'. * mandatory-feature: A YANG module feature, declared by a package definition as being mandatory to implement for all implementations @@ -265,6 +272,16 @@ Internet-Draft YANG Packages November 2025 with a set of modifications (e.g. additional modules, deviations, or features). + + + + + +Wilton, et al. Expires 10 August 2026 [Page 5] + +Internet-Draft YANG Packages February 2026 + + * Allowing datastore schema to be specified in a concise way rather than having each server explicitly list all modules, revisions, and features. YANG package definitions can be defined in @@ -274,14 +291,6 @@ Internet-Draft YANG Packages November 2025 sufficient information to allow a client or server to precisely construct the schema associated with the package. - - - -Wilton, et al. Expires 29 May 2026 [Page 5] - -Internet-Draft YANG Packages November 2025 - - * YANG Packages should be able to represent the equivalent structure as YANG library, but making use of a hierarchical resolution mechanism. @@ -294,23 +303,24 @@ Internet-Draft YANG Packages November 2025 * YANG packages should be flexible enough to represent the conformance and server implementations of standard or industry defined YANG package definitions. E.g., it should be possible for - a server implementation to indicate that it does not implement - some modules or packages, or it implements different versions/ - revisions, and/or some modules have deviations applied. + a server implementation to indicate that it does not faithfully + implement a package schema, e.g., by excluding modules, + implementing different module versions/revisions, and/or having + deviations applied. * Tooling should be able to easily work with YANG package - definitions to compare package versions and to compare server + definitions to compare YANG package versions and to compare server conformance against expected package definitions. - Protocol mechanisms of how clients can negotiate which packages or - package versions are to be used for NETCONF/RESTCONF communications - are outside the scope of this document. One potential mechanism is - defined in [I-D.ietf-netmod-yang-ver-selection]. + Protocol mechanisms of how clients can negotiate which YANG packages + or YANG package versions are to be used for NETCONF/RESTCONF + communications are outside the scope of this document. One potential + mechanism is defined in [I-D.ietf-netmod-yang-ver-selection]. Finally, the package definitions proposed by this document are intended to be relatively basic in their definition and the - functionality that they support. As industry gains experience using - YANG packages, the standard YANG mechanisms of updating, or + functionality that they support. As the industry gains experience + using YANG packages, the standard YANG mechanisms of updating, or augmenting YANG modules could also be used to extend the functionality supported by YANG packages, if required. @@ -321,6 +331,13 @@ Internet-Draft YANG Packages November 2025 * Using YANG library, along with YANG Instance Data files [RFC9195], + + +Wilton, et al. Expires 10 August 2026 [Page 6] + +Internet-Draft YANG Packages February 2026 + + * Using git tags and version labels for modules maintained on github, @@ -330,14 +347,6 @@ Internet-Draft YANG Packages November 2025 vendor release at the github repository at https://github.com/YangModels/yang - - - -Wilton, et al. Expires 29 May 2026 [Page 6] - -Internet-Draft YANG Packages November 2025 - - Although these methods are quite simple, there are some disadvantages with various aspects of these methods: They are verbose, they don't advertise supported features or support mounts, and they can be @@ -365,18 +374,26 @@ Internet-Draft YANG Packages November 2025 also contains lists of any implemented modules and import-only modules that are used in addition to, or with different version/ revisions to, the modules defined in the included packages. - Finally, it list required features in addition to those defined in - included packages. + Finally, it lists required features in addition to those defined + in included packages. - * An "excludes" container comprising modules, and features that are + * An "excludes" container comprising modules and features that are included via the resolved packages of entries in the "includes/ packages" list, but that are excluded from this package - definition. + 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. + + + +Wilton, et al. Expires 10 August 2026 [Page 7] + +Internet-Draft YANG Packages February 2026 + + 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) @@ -389,9 +406,48 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 7] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 8] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 module: ietf-yang-package-types @@ -411,49 +467,49 @@ Internet-Draft YANG Packages November 2025 | | +-- version pkg-version | | +-- location* inet:uri | +-- module* [name] - | | +-- name yang:yang-identifier + | | +-- name module-name | | +-- version version-or-rev-date | | +-- location* inet:uri | | +-- submodule* [name] - | | +-- name yang:yang-identifier + | | +-- name module-name | | +-- version version-or-rev-date | | +-- location* inet:uri | +-- import-only-module* [name version] - | | +-- name yang:yang-identifier - | | +-- version version-or-rev-date - | | +-- replaces-version* version-or-rev-date - | | +-- location* inet:uri + | | +-- name module-name + | | +-- version version-or-rev-date + | | +-- location* inet:uri | | +-- submodule* [name] - | | +-- name yang:yang-identifier + | | +-- name module-name | | +-- version version-or-rev-date | | +-- location* inet:uri - | +-- features* scoped-feature + | +-- feature* scoped-feature +-- excludes - | +-- module* pkg-name - | +-- import-only-module* pkg-name - | +-- features* scoped-feature - +-- mounts* [mount-path] + | +-- module* module-name + | +-- import-only-module* [name] + | | +-- name module-name + | | +-- version* version-or-rev-date + | +-- feature* scoped-feature + +-- mount* [mount-path] +-- mount-path mount-ypath +-- package* [name] - | +-- name pkg-name - | +-- version pkg-version - | +-- location* inet:uri - | +-- replaces-package* pkg-name + | +-- name pkg-name + | +-- version pkg-version + | +-- location* inet:uri + | +-- wraps-package* pkg-name +-- parent-reference* mount-ypath - -Wilton, et al. Expires 29 May 2026 [Page 8] +Wilton, et al. Expires 10 August 2026 [Page 9] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 3.1. Package definition rules - For a YANG package to be valid, it MUST conform to all of the - following rules: + For a YANG package to be valid, it MUST conform to all the following + rules: 1. Each (package name, version) pairing MUST define a globally unique version of that package definition. @@ -472,16 +528,18 @@ Internet-Draft YANG Packages November 2025 import dependencies missing, as described in Section 3.2. 5. Packages definitions are hierarchical because a package can - include other packages. + include other packages. There MUST NOT be any circular package + include dependencies, i.e., packages cannot, directly or + indirectly, include themselves. 6. 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/modules") or using automatic version resolution, - as described in Section 4.1. + (via "includes/module") or using automatic module version + resolution, as described in Section 4.1. 7. Multiple versions/revisions of an import-only module MAY be - listed, but any extraneous import-only module versions should be + listed, but any extraneous import-only module versions SHOULD be removed. 8. A package definition MUST NOT include the same module name in @@ -492,18 +550,16 @@ Internet-Draft YANG Packages November 2025 only-module' lists. 10. A package definition MUST NOT include the same feature name in - both the 'includes/features' and 'excludes/features' lists. + both the 'includes/feature' and 'excludes/feature' lists. 11. A package definition MUST NOT exclude a module and list features defined by that module in the 'includes/feature' list. - - -Wilton, et al. Expires 29 May 2026 [Page 9] +Wilton, et al. Expires 10 August 2026 [Page 10] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 12. A package definition MAY include redundant information, e.g., @@ -531,7 +587,7 @@ Internet-Draft YANG Packages November 2025 specified as part of the package definition, then the package is classified as being referentially incomplete. - Also see Section 5.2 for details on cases when referentially + Also see Section 5.3 for details on cases when referentially incomplete packages are helpful. 3.3. Submodules packages considerations @@ -557,9 +613,9 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 10] +Wilton, et al. Expires 10 August 2026 [Page 11] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 [RFC8528] declares that it provides support for mounted schema at @@ -580,28 +636,18 @@ Internet-Draft YANG Packages November 2025 this package with a 'replaces-package' statement. * A package definition CANNOT remove a package from a mount point, - but it MAY replace it a different package version, which SHOULD be - newer version of the package. A package definition MAY also - remove modules or mandatory features. In all cases, this is - achieved by listing the replacement package in the 'mounts/ - package' list, which MUST import a version of the package to be - replaced. - - * Each package definition may include a list of packages found at - each mount point. Only a single version of any package found at a - given mount point is allowed, and hence the version within the - 'mounts/package' list replaces any mounted version exported from - included packages, as defined in Section 4. In addition, the - package mount definition allows for a package to replace one or - more other packages at that mount point. Examples of this are - given in Appendix A.5.2. + but it MAY add a different package version, which SHOULD be newer + version of the package. A package definition MAY also remove + modules or mandatory-features. In all cases, this is achieved by + listing the replacement package in the 'mount/package' list, which + MUST include a version of the package to be replaced. Examples of + this are given in Appendix A.5.2. 3.4.1. Exclusions - A package definition may exclude modules or mandatory features. The + A package definition may exclude modules or mandatory-features. The mechanism for this is described in Section 4, and the conformance - implications are described in Section 7. [TODO - Check if this is - the best reference.] + implications are described in Section 7. 4. Package Resolution @@ -610,73 +656,63 @@ Internet-Draft YANG Packages November 2025 by a device for a particular datastore. A YANG schema can be thought of as comprising: - - - -Wilton, et al. Expires 29 May 2026 [Page 11] - -Internet-Draft YANG Packages November 2025 - - A set of implemented modules at specific versions, A set of import-only modules, potentially with multiple versions of a given module, - A set of mandatory features that are supported, + A set of mandatory-features that are supported, A set of mount points, each with its own YANG schema, that can be collectively compiled into a YANG schema tree. + + +Wilton, et al. Expires 10 August 2026 [Page 12] + +Internet-Draft YANG Packages February 2026 + + The YANG schema generated by a package definition can be converted into an equivalent instance in YANG library [RFC8525], with Schema - Mount [RFC8528] if mount points are used. E.g., see Section 5.3.3. + Mount [RFC8528] if mount points are used. E.g., see Section 5.4.3. The following process defines how a YANG a package definition is resolved, using two steps: 1. The list of included packages are each recursively resolved using - these steps and then combined using the following merge - resolution rules: + these steps and then the resolved package schema is combined + using the following merge resolution rules: * The set of implemented modules is the union of all implemented modules in the resolved included packages. Conflicting module versions can be resolved automatically as per Section 4.1, - then overwritten by any entries in the "includes/modules" - list, and finally filtered by any entries in "excludes/ - modules" list. + then overwritten (including submodule and location + information) by any entries in the "includes/module" list, and + finally filtered by any entries in "excludes/module" list. * The set of import-only modules is the union of all import-only - modules in the resolved included packages, updated by any - entries in the "includes/import-only-modules" list whilst - taking the 'replaces-version' leaf-list into account, and - finally filtered by any entries in "excludes/import-only- - modules" list. + modules in the resolved included packages, then updated by any + entries in the "includes/import-only-module" list, and finally + filtered by any entries in "excludes/import-only-module" list. * The set of mandatory-features is the union of the mandatory features in the resolved included packages, with any - "includes/features" entries added, and any "excludes/features" - entries removed. If a module is excluded by "excludes/ - modules" then all features associated with that module are - also implicitly removed. + "includes/feature" entries added, and any "excludes/feature" + entries removed. If a module is excluded by "excludes/module" + then all features associated with that module are also + implicitly removed. * The set of mounts is the union of the mounts in the resolved included packages, where for a given mount-path that is - present in more than one included package then it takes the - union of the mounted packages and mount parent-references. - The mounts are then updated by combining any entries in the - - - -Wilton, et al. Expires 29 May 2026 [Page 12] - -Internet-Draft YANG Packages November 2025 - - - package's "mounts" list, with any entries listed in - "mounts/package/replaces-package" list removed (or replaced) - at the mount point. + present in more than one included package (same path and same + keys) then it takes the union of the mounted packages and + mount parent-references. The mounts are then updated by + combining any entries in the package's "mount" list, with any + entries listed in "mount/package/wraps-package" list replaced + by a package that wraps the original package at the mount + point. * If the same module version is being resolved from multiple included modules, then the union of the module locations is @@ -685,6 +721,15 @@ Internet-Draft YANG Packages November 2025 * Submodules are ignored for resolution purposes, only the module version is considered and compared. + + + + +Wilton, et al. Expires 10 August 2026 [Page 13] + +Internet-Draft YANG Packages February 2026 + + See https://github.com/netmod-wg/yang-ver-dt/issues/258. How to handle union of meta-data, locations, and override behaviours. @@ -722,12 +767,23 @@ Internet-Draft YANG Packages November 2025 Semver format, then the module with the most recent revision-date is chosen. + 4. If there is no difference in version/revision dates to + distinguish between two module then: + + i Submodule information, if present, for both module + definitions is assumed to be equivalent and hence either can + be used. + + ii the location leaf-list for both modules definitions is + combined into a single list of locations without duplicates. + -Wilton, et al. Expires 29 May 2026 [Page 13] + +Wilton, et al. Expires 10 August 2026 [Page 14] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 5. YANG Package Usage @@ -735,6 +791,36 @@ Internet-Draft YANG Packages November 2025 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 together 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 schema can be + made available both from the device and also in offline package + files. + + - to define different optional YANG schema 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 @@ -744,11 +830,23 @@ Internet-Draft YANG Packages November 2025 functionality to be described on a more abstract level than individual modules. + + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 15] + +Internet-Draft YANG Packages February 2026 + + Where possible, package definitions SHOULD be made available offline - in Package Instance Data files, see Section 5.4, but also on the + 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.3. + e.g., see Section 5.4. 5.1. Achieving package name uniqueness @@ -770,22 +868,56 @@ Internet-Draft YANG Packages November 2025 or a UUID should be used as a suffix to the package name to ensure uniqueness. -5.2. Referential completeness and YANG packages +5.2. Specifying modules as implemented or import-only - 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 + 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 as to 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. + Identities are only available for use by the server for + implemented modules. -Wilton, et al. Expires 29 May 2026 [Page 14] + + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 16] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + + If a module defines data node 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. + 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. @@ -795,28 +927,40 @@ Internet-Draft YANG Packages November 2025 types.yang), instead leaving the choice of specific revisions of 'types' modules to be resolved when the package definition is used. -5.3. Providing Package Definitions on a Server +5.4. Providing Package Definitions on a Server -5.3.1. Package List +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.3.3 are used to indicate which of the + bindings in Section 5.4.3 are used to indicate which of the advertised packages are supported by each datastore schema. Each list entry in '/packages/package' SHOULD list one or more URLs pointing to an offline location where the package definition can be obtained as a YANG Instance Data File. + + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 17] + +Internet-Draft YANG Packages February 2026 + + 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.3.2. Tree diagram +5.4.2. Tree diagram The "ietf-yang-packages" YANG module has the following structure: @@ -830,19 +974,7 @@ Internet-Draft YANG Packages November 2025 ... remainder of yang-package-instance grouping ... +--ro location* inet:uri - - - - - - - -Wilton, et al. Expires 29 May 2026 [Page 15] - -Internet-Draft YANG Packages November 2025 - - -5.3.3. YANG Library Package Bindings +5.4.3. YANG Library Package Bindings The ietf-yl-packages module augments YANG library to allow a server to indicate that a datastore schema is defined by a package, or a @@ -855,12 +987,34 @@ Internet-Draft YANG Packages November 2025 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, following the rules in Section 4. + package definition, 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 higher/newer module version, but it cannot be + used to select a lower/older module version. Instead, a wrapper + package would need to be defined to explicitly select the older + module version (see Section 7.1). + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 18] + +Internet-Draft YANG Packages February 2026 + If populated, the set of packages listed for a datastore schema MUST - resolve to a schema that exactly matches the schema defined the YANG - library module-sets, and the resolved schema MUST be referentially - complete. + resolve to a schema that exactly matches the schema defined by the + YANG library 'schema/module-set' data node, and the resolved schema + MUST be referentially complete. Using YANG packages offers an + alternative hierarchical definition of the same schema. The "ietf-yl-packages" YANG module has the following structure: @@ -871,19 +1025,22 @@ Internet-Draft YANG Packages November 2025 +--ro name -> /pkgs:packages/package/name +--ro version leafref -5.4. Package Instance Data Files +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 use the ".ypkg" file extension and the + "application/ypkg" media type as defined in Section 10.3. + The following rules apply to the format of the YANG package instance files: 1. The file SHOULD be encoded in JSON. 2. The name of the file SHOULD follow the format "@.json". + name>@.ypkg". 3. The package name MUST be specified in both the instance-data-set 'name' and package 'name' leafs. @@ -891,13 +1048,6 @@ Internet-Draft YANG Packages November 2025 4. The 'description' field of the instance-data-set SHOULD be "YANG package definition". - - -Wilton, et al. Expires 29 May 2026 [Page 16] - -Internet-Draft YANG Packages November 2025 - - 5. The 'timestamp', "organization', 'contact' fields are defined in both the instance-data-set meta-data and the YANG package meta- data. Package definitions SHOULD only define these fields as @@ -909,6 +1059,13 @@ Internet-Draft YANG Packages November 2025 6. The 'revision' list in the instance data file SHOULD NOT be used, since versioning is handled by the package definition. + + +Wilton, et al. Expires 10 August 2026 [Page 19] + +Internet-Draft YANG Packages February 2026 + + 7. The instance data file for each version of a YANG package SHOULD be made available at one of more locations accessible via URLs. If one of the listed locations defines a definitive reference @@ -927,7 +1084,7 @@ Internet-Draft YANG Packages November 2025 +-- version pkg-version ... remainder of yang-package-instance grouping ... -5.5. YANG packages as schema for YANG instance data document +5.6. YANG packages as schema for YANG instance data document YANG package definitions can be used as the content schema definition for YANG instance data files. When using a package-based content @@ -946,14 +1103,6 @@ module: ietf-yang-inst-data-pkg +-- version pkg-version +-- location* inet:uri - - - -Wilton, et al. Expires 29 May 2026 [Page 17] - -Internet-Draft YANG Packages November 2025 - - 6. Package Evolution and Versioning 6.1. Package versioning @@ -962,6 +1111,17 @@ Internet-Draft YANG Packages November 2025 [I-D.ietf-netmod-yang-semver]. This section describes how those rules apply to YANG package definitions. + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 20] + +Internet-Draft YANG Packages February 2026 + + 6.1.1. Updating a package with a new version Package compatibility is fundamentally defined by how the package @@ -1000,16 +1160,6 @@ Internet-Draft YANG Packages November 2025 version that is non-backwards-compatible to the prior package version, or removing a previously included package. - - - - - -Wilton, et al. Expires 29 May 2026 [Page 18] - -Internet-Draft YANG Packages November 2025 - - * Changing an 'includes/module' or 'includes/import-only-module' list entry to select a module version that is non-backwards- compatible to the prior module version, or removing a previously @@ -1017,13 +1167,22 @@ Internet-Draft YANG Packages November 2025 * Adding an entry to the 'excludes/module' list or the 'excludes/ import-only-module' list, which in either case causes a module to - be removed from an included package. + be removed from an included package and could affect the + conformance reporting of whether the included package is deemed as + being implemented. + - * Removing a feature from the 'includes/features' list unless the + +Wilton, et al. Expires 10 August 2026 [Page 21] + +Internet-Draft YANG Packages February 2026 + + + * Removing a feature from the 'includes/feature' list unless the feature was not mandatory in any included packages. - * Adding a feature to the 'excludes/features' list unless the - feature was not mandatory in any included package. + * Adding a feature to the 'excludes/feature' list unless the feature + was not mandatory in any included package. * Adding, changing, or removing a module containing one or more deviations, that when applied to the target module would create a @@ -1059,16 +1218,21 @@ Internet-Draft YANG Packages November 2025 deviations here, e.g., removing a deviation may change the schema.] + * Adding a feature to the 'mandatory-feature/include' leaf-list. + + * Removing a feature to the 'mandatory-feature/exclude' leaf-list. + + -Wilton, et al. Expires 29 May 2026 [Page 19] - -Internet-Draft YANG Packages November 2025 - * Adding a feature to the 'mandatory-feature/include' leaf-list. - * Removing a feature to the 'mandatory-feature/exclude' leaf-list. + +Wilton, et al. Expires 10 August 2026 [Page 22] + +Internet-Draft YANG Packages February 2026 + * Adding, changing, or removing a module containing one or more deviations, that when applied to the target module would create a @@ -1117,122 +1281,149 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 20] - -Internet-Draft YANG Packages November 2025 -7. Package Conformance - YANG packages allows for conformance to be checked at a package level - rather than requiring a client to download all modules, revisions, - and deviations from the server to ensure that the datastore schema - used by the server is compatible with the client. - YANG package conformance is analogous to how YANG [RFC7950] requires - that servers either implement a module faithfully, or otherwise use - deviations to indicate areas of non-conformance. +Wilton, et al. Expires 10 August 2026 [Page 23] + +Internet-Draft YANG Packages February 2026 + - For a set of packages representing a datastore schema, servers SHOULD - implement the package definition faithfully, including all mandatory - features. +7. Package Conformance - Package definitions MAY modify the schema for directly or - hierarchically included packages through the use of different module - versions, use of module deviations, and changes to the mandatory - features or mount points. + Better and easier conformance is a major design goal for YANG + Packages. YANG package conformance is similiar to how YANG [RFC7950] + requires that servers either implement a module faithfully, or + otherwise use deviations to indicate areas of non-conformance. + Ulitmately, 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, devations, 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, revisions, 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 an 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. + + * Device specific implementation packages can be defined that 'wrap' + standard/industry packages to accurately report the device's + schema. -7.1. Resolving Conflicting Module Versions in Included Packages +7.1. Resolving conflicting module versions in included packages Sometimes a package definition may include multiple packages that - implement different versions of a module. A package must only - implement a single version of a module, and hence in these cases it - is necessary to resolve which version of the module is used. The - default behaviour, 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. However, - care should be taken if an older module version is chosen because - this may cause a non-backwards-compatible change in one of the - included packaged. - -7.2. Exclusions, Deviations + implement different versions of a module. - If a server cannot faithfully implement a package then it can define - a new package to accurately report what it does implement. The new - package can include the original package as an included package, and - the new package can define modified module versions, exclusions, or - additional modules containing deviations to the modules in the - original package, allowing the new package to accurately describe the - server's behavior. + 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 behaviour, + 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. +Wilton, et al. Expires 10 August 2026 [Page 24] + +Internet-Draft YANG Packages February 2026 +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 definition, 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 definition. -Wilton, et al. Expires 29 May 2026 [Page 21] - -Internet-Draft YANG Packages November 2025 + 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 - YANG Package definitions can exclude implemented modules and import- - only modules. They can also exclude mandatory features, allowing a - server implementation to not implement the feature. Both of these - mechanism, whilst useful, should be used with great care, - particularly if they break or change the resolved schema of any - include packages. + Whenever possible, servers should aim to implement packages + accurately since this maximizes interoperability for clients. + However, if a server cannot faithfully implement a YANG package then + it can define a new package to accurately report what it does + implement. The RECOMMENDED mechanism for this is to define and + advertise a separate "server implementation" package which includes + the package to be conformed to, and then excludes modules or selects + different versions, adds deviation modules, and excludes mandatory- + features to indicate the actual conformance of the server + implementation. - However, it may be necessary for an implementation to use deviations - to indicate where the server does not conform to the package, or even - to exclude modules that are not implemented in their entirety. The - RECOMMENDED mechanism for this is to advertise a separate "server - implementation" package that includes the package to be conformed to, - and then excludes modules, adds deviation modules, and excluded - mandatory-features to indicate the actual conformance of the server. TODO, please see Appendix X for an example. 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 schema. This gives a clearer indication to users of the package definition as - to the intent. + to the intent. However, be aware when combining two included + packages, that a module removed by one package could still be readded + by another included package. If deviations are used this won't + happen unless the module defining the deviations is explicitly + removed. -7.3. Use of features in YANG modules and YANG packages + 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. - The YANG language 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 'features' list, which allow the package to - define a set of features that MUST be implemented by any conformant - implementation of the package as a mechanism to simplify and manage - the schema represented by a YANG package. -7.4. Use of YANG semantic versioning - Using the YANG semantic versioning scheme for package version numbers - and module revision 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. +Wilton, et al. Expires 10 August 2026 [Page 25] + +Internet-Draft YANG Packages February 2026 +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 'features' list, which allow the package to + define a set of features that MUST be implemented by any conformant + implementation of the package as a mechanism to simplify and manage + the schema represented by a YANG package. + TODO, see issue https://github.com/netmod-wg/yang-ver-dt/issues/273. -Wilton, et al. Expires 29 May 2026 [Page 22] - -Internet-Draft YANG Packages November 2025 +7.5. Use of YANG semantic versioning for YANG packages + Using the YANG semantic versioning scheme for package version numbers + and module revision 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 @@ -1255,25 +1446,24 @@ Internet-Draft YANG Packages November 2025 sufficient, particular if they can avoid non-backwards-compatible patch level changes. -7.5. Implementing package versions - TODO - Document differences in implementing package versions. -7.6. Use of deviations in YANG packages + + + + + +Wilton, et al. Expires 10 August 2026 [Page 26] + +Internet-Draft YANG Packages February 2026 + + +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. - In cases where implementations contain deviations from published - packages, then those implementations SHOULD define a package that - includes both the published packages and all modules containing - deviations. This implementation specific package accurately reflects - the schema used by the device and allows clients to determine how the - implementation differs from the published package schema in an - offline consumable way, e.g., when published in an instance data file - (see section 6). - 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 @@ -1283,13 +1473,6 @@ Internet-Draft YANG Packages November 2025 They prevent implementations from reporting their own deviations for the same nodes. - - -Wilton, et al. Expires 29 May 2026 [Page 23] - -Internet-Draft YANG Packages November 2025 - - 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 @@ -1299,9 +1482,11 @@ Internet-Draft YANG Packages November 2025 7.7. The relationship between packages and datastores As defined by NMDA [RFC8342], each datastore has an associated - datastore schema. Sections 5.1 and 5.3 of NMDA defines further - constraints on the schema associated with datastores. These - constraints can be summarized thus: + datastore schema. These datastore schema 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. @@ -1321,6 +1506,14 @@ Internet-Draft YANG Packages November 2025 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 + + + +Wilton, et al. Expires 10 August 2026 [Page 27] + +Internet-Draft YANG Packages February 2026 + + modules containing only config false data nodes, but there is no harm in including those modules in the configuration datastore schema as well. @@ -1335,17 +1528,6 @@ Internet-Draft YANG Packages November 2025 which parts of the schema are common and which parts have differences): - - - - - - -Wilton, et al. Expires 29 May 2026 [Page 24] - -Internet-Draft YANG Packages November 2025 - - * 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 @@ -1361,26 +1543,57 @@ Internet-Draft YANG Packages November 2025 with other packages to describe the unique parts of each datastore schema. - * YANG modules that do not contain any configuration data nodes - SHOULD be included in the package for configuration datastores if - that helps unify the package definitions. + * 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 MUST 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 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. + together in an overarching package definition that relies on the + automatic resolution of module versions. + + + + + +Wilton, et al. Expires 10 August 2026 [Page 28] + +Internet-Draft YANG Packages February 2026 + * The resolved 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 @@ -1388,20 +1601,12 @@ Internet-Draft YANG Packages November 2025 8.1. ietf-yang-package-types - file "ietf-yang-package-types#0.7.0.yang" + file "ietf-yang-package-types#0.8.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"; - - - -Wilton, et al. Expires 29 May 2026 [Page 25] - -Internet-Draft YANG Packages November 2025 - - import ietf-yang-revisions { prefix rev; reference "XXXX: Updated YANG Module Revision Handling"; @@ -1413,6 +1618,14 @@ Internet-Draft YANG Packages November 2025 } import ietf-yang-types { + + + +Wilton, et al. Expires 10 August 2026 [Page 29] + +Internet-Draft YANG Packages February 2026 + + prefix yang; rev:recommended-min-date 2019-07-21; reference "RFC 6991bis: Common YANG Data Types."; @@ -1451,13 +1664,6 @@ Internet-Draft YANG Packages November 2025 This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. - - -Wilton, et al. Expires 29 May 2026 [Page 26] - -Internet-Draft YANG Packages November 2025 - - 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 @@ -1468,8 +1674,16 @@ Internet-Draft YANG Packages November 2025 // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-11-18 { - ys:version 0.7.0; + + + +Wilton, et al. Expires 10 August 2026 [Page 30] + +Internet-Draft YANG Packages February 2026 + + + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -1493,30 +1707,37 @@ Internet-Draft YANG Packages November 2025 "Packages are versioning 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"; + "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 ':', where both -Wilton, et al. Expires 29 May 2026 [Page 27] +Wilton, et al. Expires 10 August 2026 [Page 31] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 - description - "Represents a feature name scoped to a particular module, - identified as the ':', where both and are YANG identifier strings, as defiend by Section 12 or RFC 6020."; reference @@ -1562,17 +1783,16 @@ Internet-Draft YANG Packages November 2025 "Uniquely identies a particular version of a YANG package. Follows the definition for revision labels defined in + draft-verdt-nemod-yang-module-versioning, section XXX"; + } + } -Wilton, et al. Expires 29 May 2026 [Page 28] +Wilton, et al. Expires 10 August 2026 [Page 32] -Internet-Draft YANG Packages November 2025 - +Internet-Draft YANG Packages February 2026 - draft-verdt-nemod-yang-module-versioning, section XXX"; - } - } grouping yang-pkg-exclusions { description @@ -1585,7 +1805,7 @@ Internet-Draft YANG Packages November 2025 from a YANG package definition"; leaf-list module { - type pkg-name; + type module-name; description "Lists implemented modules, of any version, that may have have been brought in by included packages, but are @@ -1602,35 +1822,55 @@ Internet-Draft YANG Packages November 2025 'includes/module' list."; } - leaf-list import-only-module { - type pkg-name; + list import-only-module { + key "name"; description - "Lists import-only modules, of any version, that may have - have been brought in by included packages, but are - explicitly excluded from this package definition. + "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 a module in both this list and the 'includes/import-only-module' list."; - } - leaf-list features { - type scoped-feature; - description - "Lists features from the mandatory features exported by an - included package that are reclassified as being OPTIONAL + 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; -Wilton, et al. Expires 29 May 2026 [Page 29] +Wilton, et al. Expires 10 August 2026 [Page 33] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + + 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 mandatory-features 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/features' list. + the 'includes/feature' list. Features are identified using :."; @@ -1658,6 +1898,14 @@ Internet-Draft YANG Packages November 2025 "Specifies the data node for a full YANG package instance represented either on a server or as a YANG instance data document."; + + + +Wilton, et al. Expires 10 August 2026 [Page 34] + +Internet-Draft YANG Packages February 2026 + + uses yang-pkg-identification-leafs; leaf timestamp { @@ -1674,14 +1922,6 @@ Internet-Draft YANG Packages November 2025 } leaf contact { - - - -Wilton, et al. Expires 29 May 2026 [Page 30] - -Internet-Draft YANG Packages November 2025 - - type string; description "Contact information for the person or organization to whom @@ -1714,30 +1954,30 @@ Internet-Draft YANG Packages November 2025 definition."; list package { - key "name"; - description - "An entry in this list represents a package that is included - as part of the package definition, or to change the version - of a descendent included package. - An entry in this list overrides any other package version - 'included' by an included package, which can be used for - resolving conflicting package versions from included - packages. - A package definition MUST resolve to including only a single - version of any YANG package."; - uses yang-pkg-identification-leafs; - uses yang-pkg-location; +Wilton, et al. Expires 10 August 2026 [Page 35] + +Internet-Draft YANG Packages February 2026 + key "name"; + description + "An entry in this list represents a package that is + included as part of the package definition, or to change + the version of a descendent included package. -Wilton, et al. Expires 29 May 2026 [Page 31] - -Internet-Draft YANG Packages November 2025 + An entry in this list overrides any other package version + 'included' by an included package, which can be used for + resolving conflicting package versions from included + packages. + A package definition MUST resolve to including only a + single version of any YANG package."; + uses yang-pkg-identification-leafs; + uses yang-pkg-location; } list module { @@ -1753,7 +1993,7 @@ Internet-Draft YANG Packages November 2025 "RFC 7950: The YANG 1.1 Data Modeling Language."; leaf name { - type yang:yang-identifier; + type module-name; mandatory true; description "The YANG module name."; @@ -1764,36 +2004,37 @@ Internet-Draft YANG Packages November 2025 mandatory true; description "Identifies the module version. If available, the YANG - Semantic Version SHOULD be used, otherwise the YANG module - revision date is used."; + Semantic Version SHOULD be used, otherwise the YANG + module revision date is used."; } leaf-list location { type inet:uri; + + + +Wilton, et al. Expires 10 August 2026 [Page 36] + +Internet-Draft YANG Packages February 2026 + + description "Contains a URL that represents the YANG schema resource - for this module. + for this module. - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this entry."; } list submodule { key "name"; description "Each entry represents one submodule within the - parent module."; + parent module."; leaf name { - type yang:yang-identifier; - - - -Wilton, et al. Expires 29 May 2026 [Page 32] - -Internet-Draft YANG Packages November 2025 - - + type module-name; + mandatory true; description "The YANG submodule name."; } @@ -1802,88 +2043,93 @@ Internet-Draft YANG Packages November 2025 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."; + "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; description - "Contains a URL that represents the YANG schema resource - for this submodule. + "Contains a URL that represents the YANG schema + resource for this submodule. - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this + entry."; } } } + + + +Wilton, et al. Expires 10 August 2026 [Page 37] + +Internet-Draft YANG Packages February 2026 + + list import-only-module { key "name version"; description "An entry in this list indicates that the server imports - reusable definitions from the specified revision of the - module, but does not implement any protocol accessible - objects from this revision. + reusable definitions from the specified revision of the + module, but does not implement any protocol accessible + objects from this revision. - 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."; + 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."; leaf name { - type yang:yang-identifier; + type module-name; mandatory true; description "The YANG module name."; } leaf version { - - - -Wilton, et al. Expires 29 May 2026 [Page 33] - -Internet-Draft YANG Packages November 2025 - - 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 replaces-version { - type version-or-rev-date; - description - "Gives the version of an import-only-module defined in an - included package that is replaced by this - import-only-module version."; + Semantic Version SHOULD be used, otherwise the YANG + module revision date is used."; } leaf-list location { type inet:uri; description "Contains a URL that represents the YANG schema resource - for this module. + for this module. - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this entry."; } list submodule { key "name"; description "Each entry represents one submodule within the - parent module."; + parent module."; leaf name { - type yang:yang-identifier; + type module-name; + mandatory true; + + + +Wilton, et al. Expires 10 August 2026 [Page 38] + +Internet-Draft YANG Packages February 2026 + + description "The YANG submodule name."; } @@ -1892,81 +2138,79 @@ Internet-Draft YANG Packages November 2025 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."; - - - -Wilton, et al. Expires 29 May 2026 [Page 34] - -Internet-Draft YANG Packages November 2025 - - + "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; description "Contains a URL that represents the YANG schema resource - for this submodule. + for this submodule. - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this + entry."; } } } - leaf-list features { + leaf-list feature { type scoped-feature; description "Lists features from any modules included in the package that MUST be supported by any server implementing the package. - Mandatory features specified by any directly included + Mandatory-features specified by any directly included packages MUST also be supported by server implementations, unless excluded by an entry in the - 'excludes/features' list, and do not need to be repeated + '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. Features are identified using + + + +Wilton, et al. Expires 10 August 2026 [Page 39] + +Internet-Draft YANG Packages February 2026 + + :."; } } uses yang-pkg-exclusions; - list mounts { + list mount { key "mount-path"; description - "An entry in this list represents a package that will be - found mounted in the schema at the specified mount path. - - For a given mount path, the set of mounted package - versions is the union of all packages mounted at the - given mount point. Any conflicting package versions - MUST be explicitly resolved via an entry in the - mounted/packages of the package definition. - - - -Wilton, et al. Expires 29 May 2026 [Page 35] - -Internet-Draft YANG Packages November 2025 + "An entry in this list represents additions or changes to + the schema found at the specified mount point. + The full schema at the mount point is defined by the set of + mounted packages, which is constructed as the union of all + packages mounted at the same mount point by any packages + in the 'includes/package' list, filtered by any packages + listed in the 'wraps-package' leaf-list, and then combined + with all packages listed in the 'package' list. - A mount path with specific keys MUST also includes any + A mount path with specified keys MUST also includes any mounted packages without specific keys."; leaf "mount-path" { type mount-ypath; + mandatory true; description "This path identifies a mount point in the schema. @@ -1990,6 +2234,14 @@ Internet-Draft YANG Packages November 2025 list. Each entry in the list could have a different mounted schema specified. + + + +Wilton, et al. Expires 10 August 2026 [Page 40] + +Internet-Draft YANG Packages February 2026 + + - '/modules/module[]' would indicate that the same mounted package schema is available for all list entries in the module list."; @@ -1999,53 +2251,59 @@ Internet-Draft YANG Packages November 2025 key "name"; description "The packages that will be mounted at the specified mount - path. - - The set of mounteed packages is the union of all packages - mounted at the given mount by any packages in the - 'includes/package' list, except that each entry in this list - replaces any other versions of the same package at the - same mount point. In addition, other package versions may - be omitted from the mount point via the 'replaces-package' - leaf-list."; + path in addition to those in any includes packages with + the same mount path."; uses yang-pkg-identification-leafs; uses yang-pkg-location; - - -Wilton, et al. Expires 29 May 2026 [Page 36] - -Internet-Draft YANG Packages November 2025 - - - leaf-list replaces-package { + leaf-list wraps-package { type pkg-name; description "Lists other packages that have been explicitly mounted - at the same mount point by the included package, that - are replaced by this mounted package. - - The replacing mounted package MUST include the mounted - package being replaced, but it may choose a different - version that SHOULD be a later version or revision. - - Any packages or modules included by the replaced - package are also removed by this mounted package - unless they have also been explicitly mounted at the - same mount point, in which case the replacing package - MUST also explicitly include/exclude them. - - replaces-package is expected to be used if an - implementation does not fully implement a mounted - package and needs to apply deviations or remove - included modules or mandatory-features."; + at the same mount point by an included package (i.e., + in the 'includes/package' list), that are replaced by + this mounted package. + + The replaced mounted package MUST include the mounted + package being replaced at the same package version. It + MAY also include the same package at other versions, in + which case it SHOULD select a higher version of the + wrapped package. + + This leaf is expected to be used if an implementation + does not fully implement the schema defined by a + mounted package and needs to apply deviations, modify + or remove module versions, or change + mandatory-features."; } } leaf-list parent-reference { type mount-ypath; description - "See Mount Point path and parent-reference in Schema Mount"; + "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 + + + +Wilton, et al. Expires 10 August 2026 [Page 41] + +Internet-Draft YANG Packages February 2026 + + + (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."; } } } @@ -2054,7 +2312,7 @@ Internet-Draft YANG Packages November 2025 8.2. ietf-yang-package-instance - file "ietf-yang-package-instance#0.5.0.yang" + file "ietf-yang-package-instance#0.8.0.yang" module ietf-yang-package-instance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance"; @@ -2066,16 +2324,8 @@ Internet-Draft YANG Packages November 2025 } import ietf-yang-package-types { - - - -Wilton, et al. Expires 29 May 2026 [Page 37] - -Internet-Draft YANG Packages November 2025 - - prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } @@ -2096,10 +2346,18 @@ Internet-Draft YANG Packages November 2025 description "This module provides a definition of a YANG package, which is + + + +Wilton, et al. Expires 10 August 2026 [Page 42] + +Internet-Draft YANG Packages February 2026 + + used as the content schema for an YANG instance data document specifying a YANG package. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 @@ -2122,17 +2380,9 @@ Internet-Draft YANG Packages November 2025 // 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 - - - -Wilton, et al. Expires 29 May 2026 [Page 38] - -Internet-Draft YANG Packages November 2025 - - // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2152,11 +2402,19 @@ Internet-Draft YANG Packages November 2025 uses pkg-types:yang-pkg-instance; } } + + + +Wilton, et al. Expires 10 August 2026 [Page 43] + +Internet-Draft YANG Packages February 2026 + + 8.3. ietf-yang-package - file "ietf-yang-packages#0.5.0.yang" + file "ietf-yang-packages#0.8.0.yang" module ietf-yang-packages { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages"; @@ -2174,20 +2432,11 @@ Internet-Draft YANG Packages November 2025 import ietf-yang-package-types { prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } - - - -Wilton, et al. Expires 29 May 2026 [Page 39] - -Internet-Draft YANG Packages November 2025 - - import ietf-inet-types { - prefix inet; rev:recommended-min-date 2013-07-15; reference "RFC 6991: Common YANG Data Types."; @@ -2206,9 +2455,17 @@ Internet-Draft YANG Packages November 2025 description "This module defines YANG packages on a server implementation. - Copyright (c) 2025 IETF Trust and the persons identified as + Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. + + + +Wilton, et al. Expires 10 August 2026 [Page 44] + +Internet-Draft YANG Packages February 2026 + + 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 @@ -2230,18 +2487,10 @@ Internet-Draft YANG Packages November 2025 // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; - - - -Wilton, et al. Expires 29 May 2026 [Page 40] - -Internet-Draft YANG Packages November 2025 - - reference "RFC XXXX: YANG Packages"; @@ -2265,6 +2514,14 @@ Internet-Draft YANG Packages November 2025 } leaf version { + + + +Wilton, et al. Expires 10 August 2026 [Page 45] + +Internet-Draft YANG Packages February 2026 + + type leafref { path '/pkgs:packages' + '/pkgs:package[pkgs:name = current()/../name]' @@ -2290,14 +2547,6 @@ Internet-Draft YANG Packages November 2025 schema for the associated datastore. The datastore schema is defined as the union of all - - - -Wilton, et al. Expires 29 May 2026 [Page 41] - -Internet-Draft YANG Packages November 2025 - - referenced packages, that MUST represent a referentially complete schema. @@ -2321,6 +2570,14 @@ Internet-Draft YANG Packages November 2025 list package { key "name version"; + + + +Wilton, et al. Expires 10 August 2026 [Page 46] + +Internet-Draft YANG Packages February 2026 + + description "YANG package instance"; @@ -2345,18 +2602,9 @@ Internet-Draft YANG Packages November 2025 } - - - - -Wilton, et al. Expires 29 May 2026 [Page 42] - -Internet-Draft YANG Packages November 2025 - - 8.4. ietf-yl-packages - file "ietf-yl-packages#0.5.0.yang" + file "ietf-yl-packages#0.8.0.yang" module ietf-yl-packages { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages"; @@ -2374,10 +2622,18 @@ Internet-Draft YANG Packages November 2025 import ietf-yang-packages { prefix pkgs; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: YANG Packages."; } + + + +Wilton, et al. Expires 10 August 2026 [Page 47] + +Internet-Draft YANG Packages February 2026 + + import ietf-yang-library { prefix yanglib; rev:recommended-min-date 2019-01-04; @@ -2398,18 +2654,10 @@ Internet-Draft YANG Packages November 2025 "This module provides defined augmentations to YANG library to allow a server to report YANG package information. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 - - - -Wilton, et al. Expires 29 May 2026 [Page 43] - -Internet-Draft YANG Packages November 2025 - - 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 @@ -2431,9 +2679,17 @@ Internet-Draft YANG Packages November 2025 // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description + + + +Wilton, et al. Expires 10 August 2026 [Page 48] + +Internet-Draft YANG Packages February 2026 + + "Initial revision"; reference "RFC XXXX: YANG Packages"; @@ -2456,17 +2712,7 @@ Internet-Draft YANG Packages November 2025 8.5. ietf-yang-inst-data-pkg - - - - - -Wilton, et al. Expires 29 May 2026 [Page 44] - -Internet-Draft YANG Packages November 2025 - - - file "ietf-yang-inst-data-pkg#0.5.0.yang" + file "ietf-yang-inst-data-pkg#0.8.0.yang" module ietf-yang-inst-data-pkg { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg"; @@ -2479,7 +2725,7 @@ Internet-Draft YANG Packages November 2025 import ietf-yang-package-types { prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } @@ -2493,6 +2739,13 @@ Internet-Draft YANG Packages November 2025 reference "RFC XXX: YANG Instance Data File Format."; } + + +Wilton, et al. Expires 10 August 2026 [Page 49] + +Internet-Draft YANG Packages February 2026 + + organization "IETF NETMOD (Network Modeling) Working Group"; @@ -2508,20 +2761,12 @@ Internet-Draft YANG Packages November 2025 definitions to be used to define content schema in YANG instance data documents. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 - - - -Wilton, et al. Expires 29 May 2026 [Page 45] - -Internet-Draft YANG Packages November 2025 - - forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). @@ -2539,8 +2784,8 @@ Internet-Draft YANG Packages November 2025 // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2549,6 +2794,14 @@ Internet-Draft YANG Packages November 2025 /* * Augmentations + + + +Wilton, et al. Expires 10 August 2026 [Page 50] + +Internet-Draft YANG Packages February 2026 + + */ sx:augment-structure @@ -2570,14 +2823,6 @@ Internet-Draft YANG Packages November 2025 available for retrieval of the schema for this entry. If multiple locations are provided, then the first - - - -Wilton, et al. Expires 29 May 2026 [Page 46] - -Internet-Draft YANG Packages November 2025 - - location in the leaf-list MUST be the definitive location that uniquely identifies this package"; } @@ -2589,64 +2834,89 @@ Internet-Draft YANG Packages November 2025 9. Security Considerations - TODO - Update this to more closely follow the latest template + This document defines YANG modules for defining YANG schema, that are + often used to configure and monitor network devices. - The YANG modules specified in this document defines a schema for data - that is accessed by network management protocols such as NETCONF - [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the - secure transport layer, and the mandatory-to-implement secure - transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer - is HTTPS, and the mandatory-to-implement secure transport is TLS - [RFC5246]. + The document defines three YANG modules that are accessible from + devices, and the normal YANG network management security + considerations apply, which are further described below, in + Section 9.1. - The NETCONF access control model [RFC6536] provides the means to - restrict access for particular NETCONF or RESTCONF users to a - preconfigured subset of all available NETCONF or RESTCONF protocol - operations and content. + YANG packages also offers an alternative mechanism to YANG Library + [RFC8525] for reporting YANG schema, and hence the security + considerations from that document also apply to the use of YANG + packages. As per the YANG library security considerations, the + module and version information in YANG packages may help an attacker + identify the server capabilities and server implementations with + known bugs since the set of YANG modules supported by a server may + reveal the kind of device and the manufacturer of the device. Server - Similarly to YANG library [I-D.ietf-netconf-rfc7895bis], some of the - readable data nodes in these YANG modules may be considered sensitive - or vulnerable in some network environments. It is thus important to - control read access (e.g., via get, get-config, or notification) to - these data nodes. - One additional key different to YANG library, is that the 'ietf-yang- - package' YANG module defines a schema to allow YANG packages to be - defined in YANG instance data files, that are outside the security - controls of the network management protocols. Hence, it is important - to also consider controlling access to these package instance data - files to restrict access to sensitive information. - As per the YANG library security considerations, the module, revision - information in YANG packages may help an attacker identify the server - capabilities and server implementations with known bugs since the set - of YANG modules supported by a server may reveal the kind of device - and the manufacturer of the device. Server vulnerabilities may be - specific to particular modules, module revisions, module features, or - even module deviations. For example, if a particular operation on a - particular data node is known to cause a server to crash or - significantly degrade device performance, then the YANG packages +Wilton, et al. Expires 10 August 2026 [Page 51] + +Internet-Draft YANG Packages February 2026 + vulnerabilities may be specific to particular modules, module + revisions, module features, or even module deviations. For example, + if a particular operation on a particular data node is known to cause + a server to crash or significantly degrade device performance, then + the YANG packages information will help an attacker identify server + implementations with such a defect, in order to launch a denial-of- + service attack on the device. -Wilton, et al. Expires 29 May 2026 [Page 47] - -Internet-Draft YANG Packages November 2025 + The 'ietf-yang-package-instance.yang' YANG file allows YANG packages + to be defined in YANG instance data files. In addition, "ietf-yang- + inst-data-pkg" allows YANG packages to used to define the schema for + YANG instance data files. In both cases, the security considerations + from [RFC9195] apply. Since YANG package instance data files are + outside the security controls of the network management protocols, it + is important to consider controlling access to these files to + restrict access to potentially sensitive information. +9.1. YANG Module Security Considerations - information will help an attacker identify server implementations - with such a defect, in order to launch a denial-of-service attack on - the device. + This section is modeled after the template described in Section 3.7 + of [I-D.ietf-netmod-rfc8407bis]. -10. IANA Considerations + The "ietf-yang-package-types", "ietf-yang-packages" and "ietf-yl- + packages" YANG modules define data models that are designed to be + accessed via YANG-based management protocols, such as NETCONF + [RFC6241] and RESTCONF [RFC8040]. These YANG-based management + protocols (1) have to use a secure transport layer (e.g., SSH + [RFC6242], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use + mutual authentication. - It is expected that a central registry of standard YANG package - definitions is required to support this solution. + The Network Configuration Access Control Model (NACM) [RFC8341] + provides the means to restrict access for particular NETCONF or + RESTCONF users to a preconfigured subset of all available NETCONF or + RESTCONF protocol operations and content. - It is unclear whether an IANA registry is also required to manage - specific package versions. It is highly desirable to have a specific - canonical location, under IETF control, where the definitive YANG - package versions can be obtained from. + Some of the readable data nodes in this YANG module may be considered + sensitive or vulnerable in some network environments. It is thus + important to control read access (e.g., via get, get-config, or + notification) to these data nodes. Specifically, the following + subtrees and data nodes have particular sensitivities/ + vulnerabilities: + + * There are no particularly sensitive readable data nodes. + + Modules that use the groupings that are defined in this document + should identify the corresponding security considerations. For + example, reusing some of these groupings will expose privacy-related + information (e.g., 'yang-pkg-instance'). + + + +Wilton, et al. Expires 10 August 2026 [Page 52] + +Internet-Draft YANG Packages February 2026 + + +10. IANA Considerations + +10.1. IANA YANG Module and Namespace Registrations This document requests IANA to registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following @@ -2682,14 +2952,6 @@ Internet-Draft YANG Packages November 2025 Reference: RFC XXXX Name: ietf-yang-package-instance.yang - - - -Wilton, et al. Expires 29 May 2026 [Page 48] - -Internet-Draft YANG Packages November 2025 - - Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-package- instance.yang Prefix: pkg-inst @@ -2700,6 +2962,14 @@ Internet-Draft YANG Packages November 2025 Prefix: pkgs Reference: RFC XXXX + + + +Wilton, et al. Expires 10 August 2026 [Page 53] + +Internet-Draft YANG Packages February 2026 + + Name: ietf-yl-packages.yang Namespace: urn:ietf:params:xml:ns:yang:ietf-yl-packages.yang Prefix: yl-pkgs @@ -2711,24 +2981,106 @@ Internet-Draft YANG Packages November 2025 Prefix: yid-pkg Reference: RFC XXXX +10.2. IETF YANG Package Registry + + This document requests that IANA create a registry for IETF YANG + packages, that lists all versions of all YANG package definitions + published by the IETF, and provides a reliable location to store the + YANG package definitions. + + The name of the registry is "YANG Package Names". + + The registry shall record for each entry: + + * the name of the YANG package + + * a brief description of the package purpose + + * The latest published package version + + * A list of all published package versions, each hyperlinked to the + location where that package definition may be retrieved from. + + * a reference to the package documentation (e.g., the RFC number) + + There are no initial assignments. + + For allocation, the registration policy is Specification Required, as + defined in [RFC8126]. All registered YANG package names MUST comply + with the rules for identifiers stated in Section 6.2, and MUST have a + package name prefix. + + The package name prefix 'ietf-' is reserved for package managed and + published under the IETF stream [RFC4844], while the package name + prefix 'irtf-' is reserved for IRTF stream documents. Packages + published in other RFC streams MUST have a similar suitable prefix. + + All package names in the registry MUST be unique. + + + + + +Wilton, et al. Expires 10 August 2026 [Page 54] + +Internet-Draft YANG Packages February 2026 + + +10.3. Media Type Registration for application/ypkg + + This document requests IANA to register the following media type, + following the procedures of [RFC6838]: + + Type name: application + Subtype name: ypkg + Required parameters: N/A + Optional parameters: N/A + Encoding considerations: 8bit; YANG package instance data files + are encoded in UTF-8. + Security considerations: See the Security Considerations section + of RFC XXXX. + Interoperability considerations: N/A + Published specification: RFC XXXX + Applications that use this media type: YANG tooling and servers + that generate or consume YANG package instance data files. + Additional information: + Magic number(s): None + File extension(s): ypkg + Macintosh file type code(s): 'Text' + Fragment identifiers: N/A + Person & Email address to contact for further information: NETMOD + WG (mailto:netmod@ietf.org) + Intended usage: COMMON + Restrictions on usage: N/A + Author: IETF + Change controller: IESG + 11. Acknowledgements Feedback helping shape this document has kindly been provided by Andy Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav Lhotka,and Jan Lindblad. - Bo Wu acted as a temporary editor for earlier versions of this work. + Bo Wu acted as a temporary editor for earlier versions of this work. + +12. References + +12.1. Normative References + + [I-D.ietf-netmod-rfc8407bis] + Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for + Authors and Reviewers of Documents Containing YANG Data + Models", Work in Progress, Internet-Draft, draft-ietf- + netmod-rfc8407bis-28, 5 June 2025, + . + -12. References -12.1. Normative References +Wilton, et al. Expires 10 August 2026 [Page 55] + +Internet-Draft YANG Packages February 2026 - [I-D.ietf-netconf-rfc7895bis] - Bierman, A., Björklund, M., Schönwälder, J., Watsen, K., - and R. Wilton, "YANG Library", Work in Progress, Internet- - Draft, draft-ietf-netconf-rfc7895bis-07, 17 October 2018, - . [I-D.ietf-netmod-yang-data-ext] Bierman, A., Björklund, M., and K. Watsen, "YANG Data @@ -2737,15 +3089,6 @@ Internet-Draft YANG Packages November 2025 . - - - - -Wilton, et al. Expires 29 May 2026 [Page 49] - -Internet-Draft YANG Packages November 2025 - - [I-D.ietf-netmod-yang-module-versioning] Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J. Sterne, "Updated YANG Module Revision Handling", Work in @@ -2785,6 +3128,16 @@ Internet-Draft YANG Packages November 2025 DOI 10.17487/RFC3688, January 2004, . + + + + + +Wilton, et al. Expires 10 August 2026 [Page 56] + +Internet-Draft YANG Packages February 2026 + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, @@ -2795,18 +3148,6 @@ Internet-Draft YANG Packages November 2025 DOI 10.17487/RFC6020, October 2010, . - - -Wilton, et al. Expires 29 May 2026 [Page 50] - -Internet-Draft YANG Packages November 2025 - - - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., - and A. Bierman, Ed., "Network Configuration Protocol - (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, - . - [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . @@ -2816,13 +3157,19 @@ Internet-Draft YANG Packages November 2025 DOI 10.17487/RFC6536, March 2012, . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . - [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, @@ -2838,6 +3185,15 @@ Internet-Draft YANG Packages November 2025 DOI 10.17487/RFC8525, March 2019, . + + + + +Wilton, et al. Expires 10 August 2026 [Page 57] + +Internet-Draft YANG Packages February 2026 + + [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, . @@ -2850,14 +3206,6 @@ Internet-Draft YANG Packages November 2025 Instance Data", RFC 9195, DOI 10.17487/RFC9195, February 2022, . - - - -Wilton, et al. Expires 29 May 2026 [Page 51] - -Internet-Draft YANG Packages November 2025 - - 12.2. Informative References [I-D.bierman-netmod-yang-package] @@ -2879,15 +3227,56 @@ Internet-Draft YANG Packages November 2025 "Semantic Versioning for OpenConfig Models", . + [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, + January 2006, . + + [RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor", + RFC 4844, DOI 10.17487/RFC4844, July 2007, + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 58] + +Internet-Draft YANG Packages February 2026 + + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, . + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + Appendix A. Package Examples This section provides various examples of YANG packages, and as such @@ -2901,23 +3290,22 @@ A.1. Basic Package Examples This section provides some simple examples of YANG package defines, illustrated using the instance data file format defined in - Section 5.4. + Section 5.5. TODO For brevity, most examples excluding the module and package locations. TODO - Probably should point to IANA instead. Some examples use a shortened URL of "tiny.cc/ietf-yang" as a replacement + for + "https://raw.githubusercontent.com/YangModels/yang/master/standard/ + ietf/RFC" -Wilton, et al. Expires 29 May 2026 [Page 52] +Wilton, et al. Expires 10 August 2026 [Page 59] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 - for - "https://raw.githubusercontent.com/YangModels/yang/master/standard/ - ietf/RFC" - TODO, use an IANA reference here instead? TODO, line wrapping in examples. @@ -2929,48 +3317,7 @@ A.1.1. Example IETF Basic Types YANG package, version 1.0.0 case, the module dependencies have been declared as import-only but they could also have been declared as implemented modules. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wilton, et al. Expires 29 May 2026 [Page 53] - -Internet-Draft YANG Packages November 2025 - - - file "example-base-types-pkg%1.0.0.json" + file "example-base-types-pkg%1.0.0.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { "ietf-yang-instance-data:instance-data-set": { @@ -3006,27 +3353,22 @@ Internet-Draft YANG Packages November 2025 } -A.1.2. Example IETF Basic Types YANG package, version 1.1.0 - - An updated version of the basic types package that includes Updated - versions of the types modules and follows the YANG semver versioning - rules. - - - - +Wilton, et al. Expires 10 August 2026 [Page 60] + +Internet-Draft YANG Packages February 2026 -Wilton, et al. Expires 29 May 2026 [Page 54] - -Internet-Draft YANG Packages November 2025 +A.1.2. Example IETF 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. - file "example-base-types-pkg%1.1.0.json" + file "example-base-types-pkg%1.1.0.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { "ietf-yang-instance-data:instance-data-set": { @@ -3067,27 +3409,27 @@ A.1.3. Example IETF Network Device YANG package This section provides an instance data file example of an IETF Network Device YANG package formatted in JSON. - 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. - -Wilton, et al. Expires 29 May 2026 [Page 55] +Wilton, et al. Expires 10 August 2026 [Page 61] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + 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. + 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 revision number. - file "example-ietf-network-device-pkg.json" + file "example-ietf-network-device-pkg.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { @@ -3116,7 +3458,7 @@ Internet-Draft YANG Packages November 2025 to support.", "reference": "XXX, draft-rwilton-netmod-yang-packages", "location": [ "file://example.org/yang/packages/\ - ietf-network-device@v1.1.2.json" ], + ietf-network-device@v1.1.2.ypkg" ], "module": [ { "name": "iana-crypt-hash", @@ -3124,20 +3466,20 @@ Internet-Draft YANG Packages November 2025 "location": [ "https://tiny.cc/ietf-yang/\ iana-crypt-hash%402014-08-06.yang" ], }, - { - "name": "ietf-system", - "revision": "2014-08-06", - "location": [ "https://tiny.cc/ietf-yang/\ - ietf-system%402014-08-06.yang" ], - }, -Wilton, et al. Expires 29 May 2026 [Page 56] +Wilton, et al. Expires 10 August 2026 [Page 62] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + { + "name": "ietf-system", + "revision": "2014-08-06", + "location": [ "https://tiny.cc/ietf-yang/\ + ietf-system%402014-08-06.yang" ], + }, { "name": "ietf-interfaces", "revision": "2018-02-20", @@ -3180,20 +3522,17 @@ Internet-Draft YANG Packages November 2025 } } } - } - - - - - -Wilton, et al. Expires 29 May 2026 [Page 57] +Wilton, et al. Expires 10 August 2026 [Page 63] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + } + + A.1.4. Example IETF Basic Routing YANG package This section provides an instance data file example of a basic IETF @@ -3212,7 +3551,7 @@ A.1.4. Example IETF Basic Routing YANG package defined in IETF drafts. In a normal YANG package, locations would be expected to be provided for all YANG modules. - file "example-ietf-routing-pkg.json" + file "example-ietf-routing-pkg.ypkg" ========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { @@ -3239,17 +3578,17 @@ A.1.4. Example IETF Basic Routing YANG package { "name": "ietf-network-device", "version": "1.1.2", - "location": [ "http://example.org/yang/packages/\ - ietf-network-device@v1.1.2.json" ], - } -Wilton, et al. Expires 29 May 2026 [Page 58] +Wilton, et al. Expires 10 August 2026 [Page 64] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + "location": [ "http://example.org/yang/packages/\ + ietf-network-device@v1.1.2.ypkg" ], + } ], "module": [ { @@ -3295,17 +3634,17 @@ Internet-Draft YANG Packages November 2025 " ], }, { - "name": "ietf-bgp", - "revision": "2018-05-09", - "location": [ "https://tiny.cc/ietf-yang/\ -Wilton, et al. Expires 29 May 2026 [Page 59] +Wilton, et al. Expires 10 August 2026 [Page 65] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + "name": "ietf-bgp", + "revision": "2018-05-09", + "location": [ "https://tiny.cc/ietf-yang/\ " ], }, { @@ -3351,17 +3690,16 @@ Internet-Draft YANG Packages November 2025 } } } - - - -Wilton, et al. Expires 29 May 2026 [Page 60] +Wilton, et al. Expires 10 August 2026 [Page 66] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + + A.2. Package Versioning Examples This section provides examples of versioning packges. @@ -3408,16 +3746,16 @@ A.3.1. Example of package import conflict resolution "name": "example-import-1-pkg", "content-schema": { "pkg-schema": { - "name": "ietf-yang-package-defn-pkg", - "version": "0.1.0" -Wilton, et al. Expires 29 May 2026 [Page 61] +Wilton, et al. Expires 10 August 2026 [Page 67] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + "name": "ietf-yang-package-defn-pkg", + "version": "0.1.0" } }, "description": "First imported example package", @@ -3464,16 +3802,16 @@ Internet-Draft YANG Packages November 2025 "description": "Second imported example package", "content-data": { "ietf-yang-package:yang-package": { - "name": "example-import-2", - "version": "2.0.0", -Wilton, et al. Expires 29 May 2026 [Page 62] +Wilton, et al. Expires 10 August 2026 [Page 68] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + "name": "example-import-2", + "version": "2.0.0", "reference": "XXX, draft-rwilton-netmod-yang-packages", "revision-date": "2018-11-26", "module": [ @@ -3520,16 +3858,16 @@ Internet-Draft YANG Packages November 2025 "included-package": [ { "name": "example-import-1", - "version": "1.0.0" - }, -Wilton, et al. Expires 29 May 2026 [Page 63] +Wilton, et al. Expires 10 August 2026 [Page 69] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + "version": "1.0.0" + }, { "name": "example-import-2", "version": "2.0.0" @@ -3556,7 +3894,7 @@ Internet-Draft YANG Packages November 2025 A.4. Package Exclusion Examples This section provides examples of how to exclude modules, and - packages in a package definition, and to remove mandatory features. + packages in a package definition, and to remove mandatory-features. The examples are non-normative, and for brevity, some expected information (e.g., locations) are omitted. @@ -3572,26 +3910,75 @@ A.4.1. Example of excluding modules and a mandatory feature The first package, "example-ab-pkg", implements two example modules, "example-module-a" and "example-module-b", two related types modules, - and declares two mandatory features. + and declares two mandatory-features. + + - The second package, "example-c-pkg", imports the first package, but - excludes the implemented "example-module-a" module, the import-only - "example-module-b-types" module, and the mandatory feature "bar" from - the "example-module-b" module. -Wilton, et al. Expires 29 May 2026 [Page 64] +Wilton, et al. Expires 10 August 2026 [Page 70] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 + The second package, "example-c-pkg", imports the first package, but + excludes the implemented "example-module-a" module, the import-only + "example-module-b-types" module, and the mandatory 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 Libary format, but with namespaces and locations elided for brevity. - file "example-ab-pkg%0.1.0.json" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wilton, et al. Expires 10 August 2026 [Page 71] + +Internet-Draft YANG Packages February 2026 + + + file "example-ab-pkg%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "example-ab-pkg", @@ -3635,17 +4022,19 @@ Internet-Draft YANG Packages November 2025 } + The "example-c-pkg" Yang Package example illustrates exclusions of + modules, import-only-modules and features. -Wilton, et al. Expires 29 May 2026 [Page 65] - -Internet-Draft YANG Packages November 2025 - The "example-c-pkg" Yang Package example illustrates exclusions of - modules, import-only-modules and features. - file "example-c-pkg%0.1.0.json" +Wilton, et al. Expires 10 August 2026 [Page 72] + +Internet-Draft YANG Packages February 2026 + + + file "example-c-pkg%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "example-c-pkg", @@ -3663,7 +4052,7 @@ Internet-Draft YANG Packages November 2025 "name": "example-ab-pkg", "version": "0.1.0", "location": [ - "file:///Users/rwilton/git/netmod-wg/yang-ver-dt/yang-packages/out/ExampleAbPackage/makePackage.dest/yang-pkg.json" + "file:///Users/rwilton/git/netmod-wg/yang-ver-dt/yang-packages/out/ExampleAbPackage/makePackage.dest/yang-pkg.ypkg" ] } ], @@ -3693,16 +4082,19 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 66] + + + +Wilton, et al. Expires 10 August 2026 [Page 73] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 The following JSON illustrates what a resulting YANG library file would look like once all dependencies in the "example-c-pkg" YANG package have been resolved. - file "example-c-library%0.1.0.json" + file "example-c-library%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "Package example-c-pkg@0.1.0 schema", @@ -3749,9 +4141,9 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 67] +Wilton, et al. Expires 10 August 2026 [Page 74] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 } @@ -3791,7 +4183,7 @@ A.5.2. Example of an package replacing the mounted schema 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 mandatory + entirety, remove modules from a mounted package, change mandatory- features, change the behaviour of recursive mounts, etc. TODO - Probably need more than one example. @@ -3805,9 +4197,9 @@ Authors' Addresses -Wilton, et al. Expires 29 May 2026 [Page 68] +Wilton, et al. Expires 10 August 2026 [Page 75] -Internet-Draft YANG Packages November 2025 +Internet-Draft YANG Packages February 2026 Reshad Rahman @@ -3861,4 +4253,4 @@ Internet-Draft YANG Packages November 2025 -Wilton, et al. Expires 29 May 2026 [Page 69] +Wilton, et al. Expires 10 August 2026 [Page 76] diff --git a/yang-packages/draft-ietf-netmod-yang-packages.xml b/yang-packages/draft-ietf-netmod-yang-packages.xml index 76c3d5e..a849223 100644 --- a/yang-packages/draft-ietf-netmod-yang-packages.xml +++ b/yang-packages/draft-ietf-netmod-yang-packages.xml @@ -1,6 +1,7 @@ + @@ -11,10 +12,14 @@ + + + + ]> @@ -120,10 +125,11 @@ YANG package: a versioned organizational structure used to manage a set of YANG modules that collectively define a package schema. YANG packages are defined in - . + . Depending on context, the term 'YANG + package' is often used to refer to a specific version of a YANG + package rather than all versions of a package definition. - package schema: The combined set of schema nodes defined by a - YANG package. Package schema can be used to define datastore schema. + package: An alternative term for 'YANG package'. backwards-compatible (BC) change: When used in the context of a YANG module, it follows the definition in Section 3.1.1 of . - resolved schema: The resolved schema is the YANG schema defined by - a package after package resolution has been performed, as defined in - . The resolved schema identifies the - implemented modules (with any deviations applied), import-only - modules, enabled features, and schema mount points. + resolved package schema: The resolved package schema is the YANG + schema defined by a package after package resolution has been + performed, as defined in . The resolved + package schema identifies the implemented modules (with any deviations + applied), import-only modules, enabled features, and schema mount + points. + + package schema: An alternative term for 'resolved package schema'. mandatory-feature: A YANG module feature, declared by a package definition as being mandatory to implement for all implementations @@ -202,23 +211,23 @@ YANG packages should be flexible enough to represent the conformance and server implementations of standard or industry defined YANG package definitions. E.g., it should be possible for a server - implementation to indicate that it does not implement some modules or - packages, or it implements different versions/revisions, and/or some - modules have deviations applied. + implementation to indicate that it does not faithfully implement + a package schema, e.g., by excluding modules, implementing different + module versions/revisions, and/or having deviations applied. Tooling should be able to easily work with YANG package definitions - to compare package versions and to compare server conformance against - expected package definitions. + to compare YANG package versions and to compare server conformance + against expected package definitions. - Protocol mechanisms of how clients can negotiate which packages or - package versions are to be used for NETCONF/RESTCONF communications are + Protocol mechanisms of how clients can negotiate which YANG packages or + YANG package versions are to be used for NETCONF/RESTCONF communications are outside the scope of this document. One potential mechanism is defined in . Finally, the package definitions proposed by this document are intended to be relatively basic in their definition and the functionality - that they support. As industry gains experience using YANG packages, the + that they support. As the industry gains experience using YANG packages, the standard YANG mechanisms of updating, or augmenting YANG modules could also be used to extend the functionality supported by YANG packages, if required. @@ -255,6 +264,8 @@
@@ -361,73 +308,19 @@ 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/revisions to, - the modules defined in the included packages. Finally, it list + the modules defined in the included packages. Finally, it lists required features in addition to those defined in included packages. - An "excludes" container comprising modules, and features that are + An "excludes" container comprising modules and features that are included via the resolved packages of entries in the "includes/packages" list, but that are excluded from this package - definition. + 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. - - - - - - - - - - - - - - - See https://github.com/netmod-wg/yang-ver-dt/issues/258. How to handle union of meta-data, locations, and override behaviours. @@ -754,14 +630,50 @@ module: ietf-yang-package-types If neither module has a version statement that matches the YANG Semver format, then the module with the most recent revision-date is chosen. + If there is no difference in version/revision dates to + distinguish between two module then: + + Submodule information, if present, for both module definitions + is assumed to be equivalent and hence either can be used. + the location leaf-list for both modules definitions is + combined into a single list of locations without duplicates. +
+
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 together 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 schema can be made + available both from the device and also in offline package files. + + to define different optional YANG schema 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 @@ -798,6 +710,37 @@ module: ietf-yang-package-types
+
+ + 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 as to 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 . + Identities are only available for use by the server for implemented + modules. + If a module defines data node 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. + If a module imports a module at an exact revision (which, as per , 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. + + + +
+
Referentially incomplete packages can be used, along with locally @@ -868,13 +811,24 @@ module: ietf-yang-packages 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, following the rules in + package definition, following the standard package resolution rules in . + This means that conflicting module versions between the listed + packages are resolved using the automatic module version resolution + rules in . 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 higher/newer module version, + but it cannot be used to select a lower/older module version. + Instead, a wrapper package would need to be defined to explicitly + select the older module version (see + ). If populated, the set of packages listed for a datastore schema - MUST resolve to a schema that exactly matches the schema defined the - YANG library module-sets, and the resolved schema MUST be - referentially complete. + MUST resolve to a schema that exactly matches the schema defined by + the YANG library 'schema/module-set' data node, and the resolved + schema MUST be referentially complete. Using YANG packages offers an + alternative hierarchical definition of the same schema.
The "ietf-yl-packages" YANG module has the following @@ -897,12 +851,16 @@ module: ietf-yl-packages defined as YANG instance data files using the schema below to define the package data. + Package instance data files use the ".ypkg" file extension and the + "application/ypkg" media type as defined in + . + The following rules apply to the format of the YANG package instance files: The file SHOULD be encoded in JSON. The name of the file SHOULD follow the format - "<package-name>@<version>.json". + "<package-name>@<version>.ypkg". The package name MUST be specified in both the instance-data-set 'name' and package 'name' leafs. @@ -1019,12 +977,14 @@ module: ietf-yang-inst-data-pkg Adding an entry to the 'excludes/module' list or the 'excludes/import-only-module' list, which in either case causes - a module to be removed from an included package. + a module to be removed from an included package and could affect + the conformance reporting of whether the included package is + deemed as being implemented. - Removing a feature from the 'includes/features' list unless + Removing a feature from the 'includes/feature' list unless the feature was not mandatory in any included packages. - Adding a feature to the 'excludes/features' list unless the + Adding a feature to the 'excludes/feature' list unless the feature was not mandatory in any included package. Adding, changing, or removing a module containing one @@ -1102,36 +1062,6 @@ module: ietf-yang-inst-data-pkg
- -
During development of a new package, or while updating a previously released package, special care should be taken with the selection of the @@ -1143,121 +1073,113 @@ versioned using YANG Semver labels in an earlier section. IETF YANG Packages?]
- +
- YANG packages allows for conformance to be checked at a package - level rather than requiring a client to download all modules, - revisions, and deviations from the server to ensure that the datastore - schema used by the server is compatible with the client. - - YANG package conformance is analogous to how YANG requires that servers either implement a module - faithfully, or otherwise use deviations to indicate areas of - non-conformance. - - For a set of packages representing a datastore schema, servers - SHOULD implement the package definition faithfully, including all - mandatory features. - - Package definitions MAY modify the schema for directly or - hierarchically included packages through the use of different module - versions, use of module deviations, and changes to the mandatory features - or mount points. - -
+ Better and easier conformance is a major design goal for YANG Packages. YANG + package conformance is similiar to how YANG + requires that servers either implement a module faithfully, or otherwise + use deviations to indicate areas of non-conformance. Ulitmately, each + version of a YANG package resolves, as per (), + to a YANG schema that is defined as a set of implemented modules and + import-only modules, devations, 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, revisions, 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 + an 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. + Device specific implementation packages can be defined that 'wrap' + standard/industry packages to accurately report the device's schema. + + + +
Sometimes a package definition may include multiple packages that - implement different versions of a module. A package must only implement a - single version of a module, and hence in these cases it is necessary to - resolve which version of the module is used. The default behaviour, - defined in is to - use automatic resolution, which is generally the best choice. Manual - resolution could be used to select a different module version instead. - However, care should be taken if an older module version is chosen because - this may cause a non-backwards-compatible change in one of the included - packaged. + implement different versions of a module. + + As per the package definition rules in , 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 + behaviour, defined in 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.
-
- If a server cannot faithfully implement a package then it can define - a new package to accurately report what it does implement. The new - package can include the original package as an included package, and the - new package can define modified module versions, exclusions, or - additional modules containing deviations to the modules in the - original package, allowing the new package to accurately describe the - server's behavior. - - YANG Package definitions can exclude implemented modules and - import-only modules. They can also exclude mandatory features, allowing - a server implementation to not implement the feature. Both of these - mechanism, whilst useful, should be used with great care, particularly - if they break or change the resolved schema of any include packages. - +
+ Unlike modules in a package definition, where there can only be a + single version of a module in a resolved package definition, this does + not apply to included packages. As per the package resolution rules + in , when multiple included packages define + different versions of the same package, then both versions are retained + in the resolved package definition. + 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. +
- However, it may be necessary for an implementation to use deviations - to indicate where the server does not conform to the package, or even to - exclude modules that are not implemented in their entirety. - The RECOMMENDED mechanism for this is to advertise a separate - "server implementation" package that includes the package to be conformed - to, and then excludes modules, adds deviation modules, and excluded - mandatory-features to indicate the actual conformance of the server. - TODO, please see Appendix X for an example. +
+ Whenever possible, servers should aim to implement packages accurately + since this maximizes interoperability for clients. However, if a server + cannot faithfully implement a YANG package then it can define a new + package to accurately report what it does implement. The RECOMMENDED + mechanism for this is to define and advertise a separate + "server implementation" package which includes the package to be + conformed to, and then excludes modules or selects different versions, + adds deviation modules, and excludes mandatory-features to indicate the + actual conformance of the server implementation. + TODO, please see Appendix X for an example. 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 schema. This gives a clearer indication to users of the package definition as to - the intent. + the intent. However, be aware when combining two included packages, + that a module removed by one package could still be readded 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.
- The YANG language 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. + The YANG language, 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 'features' list, which allow the package to define a set of features that MUST be implemented by any conformant implementation of the package as a mechanism to simplify and manage the schema represented by a YANG package. + + TODO, see issue https://github.com/netmod-wg/yang-ver-dt/issues/273.
-
+
Using the YANG semantic versioning scheme for package version numbers and module revision labels can help with conformance. In the general case, clients should be able to determine the nature of @@ -1297,36 +1219,12 @@ This section has already been covered in the resolution section.
--> -
- TODO - Document differences in implementing package versions. -
- -
- - +
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. - In cases where implementations contain deviations from published - packages, then those implementations SHOULD define a package that - includes both the published packages and all modules containing - deviations. This implementation specific package accurately reflects - the schema used by the device and allows clients to determine how - the implementation differs from the published package schema in an - offline consumable way, e.g., when published in an instance data - file (see section 6). - 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 @@ -1348,7 +1246,10 @@ This section has already been covered in the resolution section.
As defined by NMDA , each datastore has - an associated datastore schema. Sections 5.1 and 5.3 of NMDA defines + an associated datastore schema. These datastore schema can be + advertised by servers using YANG Library , + augmented with the associated YANG package information, as per + . 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. @@ -1400,26 +1301,48 @@ This section has already been covered in the resolution section. datastore schema. YANG modules that do not contain any configuration data nodes - SHOULD be included in the package for configuration datastores + MAY be included in the package for configuration datastores if that helps unify the package definitions. - The packages for the operational datastore schema MUST + 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). + 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. + together in an overarching package definition that relies on the + automatic resolution of module versions. The resolved schema representing a datastore MUST be referentially complete.
+ +
+ 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. +
@@ -1429,7 +1352,7 @@ This section has already been covered in the resolution section.
file "ietf-yang-package-types#0.7.0.yang" + file "ietf-yang-package-types#0.8.0.yang" module ietf-yang-package-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types"; @@ -1494,8 +1417,8 @@ module ietf-yang-package-types { // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-11-18 { - ys:version 0.7.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -1519,13 +1442,20 @@ module ietf-yang-package-types { "Packages are versioning 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"; + "Identifies a module by YANG semantic version or revision + date"; } typedef scoped-feature { @@ -1595,7 +1525,7 @@ module ietf-yang-package-types { from a YANG package definition"; leaf-list module { - type pkg-name; + type module-name; description "Lists implemented modules, of any version, that may have have been brought in by included packages, but are @@ -1612,27 +1542,47 @@ module ietf-yang-package-types { 'includes/module' list."; } - leaf-list import-only-module { - type pkg-name; + list import-only-module { + key "name"; description - "Lists import-only modules, of any version, that may have - have been brought in by included packages, but are - explicitly excluded from this package definition. + "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 a module in both this list and 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 features { + leaf-list feature { type scoped-feature; description - "Lists features from the mandatory features exported by an + "Lists features from the mandatory-features 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/features' list. + the 'includes/feature' list. Features are identified using :."; @@ -1710,17 +1660,17 @@ module ietf-yang-package-types { list package { key "name"; description - "An entry in this list represents a package that is included - as part of the package definition, or to change the version - of a descendent included package. + "An entry in this list represents a package that is + included as part of the package definition, or to change + the version of a descendent included package. - An entry in this list overrides any other package version - 'included' by an included package, which can be used for - resolving conflicting package versions from included - packages. + An entry in this list overrides any other package version + 'included' by an included package, which can be used for + resolving conflicting package versions from included + packages. - A package definition MUST resolve to including only a single - version of any YANG package."; + A package definition MUST resolve to including only a + single version of any YANG package."; uses yang-pkg-identification-leafs; uses yang-pkg-location; @@ -1739,7 +1689,7 @@ module ietf-yang-package-types { "RFC 7950: The YANG 1.1 Data Modeling Language."; leaf name { - type yang:yang-identifier; + type module-name; mandatory true; description "The YANG module name."; @@ -1750,28 +1700,29 @@ module ietf-yang-package-types { mandatory true; description "Identifies the module version. If available, the YANG - Semantic Version SHOULD be used, otherwise the YANG module - revision date is used."; + Semantic Version SHOULD be used, otherwise the YANG + module revision date is used."; } leaf-list location { type inet:uri; description "Contains a URL that represents the YANG schema resource - for this module. + for this module. - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this entry."; } list submodule { key "name"; description "Each entry represents one submodule within the - parent module."; + parent module."; leaf name { - type yang:yang-identifier; + type module-name; + mandatory true; description "The YANG submodule name."; } @@ -1780,22 +1731,25 @@ module ietf-yang-package-types { 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."; + "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; description - "Contains a URL that represents the YANG schema resource - for this submodule. + "Contains a URL that represents the YANG schema + resource for this submodule. - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this + entry."; } } } @@ -1804,16 +1758,17 @@ module ietf-yang-package-types { key "name version"; description "An entry in this list indicates that the server imports - reusable definitions from the specified revision of the - module, but does not implement any protocol accessible - objects from this revision. + reusable definitions from the specified revision of the + module, but does not implement any protocol accessible + objects from this revision. - 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."; + 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."; leaf name { - type yang:yang-identifier; + type module-name; mandatory true; description "The YANG module name."; @@ -1824,36 +1779,29 @@ module ietf-yang-package-types { 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 replaces-version { - type version-or-rev-date; - description - "Gives the version of an import-only-module defined in an - included package that is replaced by this - import-only-module version."; + Semantic Version SHOULD be used, otherwise the YANG + module revision date is used."; } leaf-list location { type inet:uri; description "Contains a URL that represents the YANG schema resource - for this module. + for this module. - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this entry."; } list submodule { key "name"; description "Each entry represents one submodule within the - parent module."; + parent module."; leaf name { - type yang:yang-identifier; + type module-name; + mandatory true; description "The YANG submodule name."; } @@ -1862,37 +1810,40 @@ module ietf-yang-package-types { 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."; + "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; description "Contains a URL that represents the YANG schema resource - for this submodule. + for this submodule. - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; + This leaf will only be present if there is a URL + available for retrieval of the schema for this + entry."; } } } - leaf-list features { + leaf-list feature { type scoped-feature; description "Lists features from any modules included in the package that MUST be supported by any server implementing the package. - Mandatory features specified by any directly included + Mandatory-features specified by any directly included packages MUST also be supported by server implementations, unless excluded by an entry in the - 'excludes/features' list, and do not need to be repeated + 'excludes/feature' list, and do not need to be repeated in this list. All other features defined in modules included in the @@ -1905,23 +1856,25 @@ module ietf-yang-package-types { uses yang-pkg-exclusions; - list mounts { + list mount { key "mount-path"; description - "An entry in this list represents a package that will be - found mounted in the schema at the specified mount path. + "An entry in this list represents additions or changes to + the schema found at the specified mount point. - For a given mount path, the set of mounted package - versions is the union of all packages mounted at the - given mount point. Any conflicting package versions - MUST be explicitly resolved via an entry in the - mounted/packages of the package definition. + The full schema at the mount point is defined by the set of + mounted packages, which is constructed as the union of all + packages mounted at the same mount point by any packages + in the 'includes/package' list, filtered by any packages + listed in the 'wraps-package' leaf-list, and then combined + with all packages listed in the 'package' list. - A mount path with specific keys MUST also includes any + A mount path with specified keys MUST also includes any mounted packages without specific keys."; leaf "mount-path" { type mount-ypath; + mandatory true; description "This path identifies a mount point in the schema. @@ -1954,46 +1907,51 @@ module ietf-yang-package-types { key "name"; description "The packages that will be mounted at the specified mount - path. - - The set of mounteed packages is the union of all packages - mounted at the given mount by any packages in the - 'includes/package' list, except that each entry in this list - replaces any other versions of the same package at the - same mount point. In addition, other package versions may - be omitted from the mount point via the 'replaces-package' - leaf-list."; + path in addition to those in any includes packages with + the same mount path."; uses yang-pkg-identification-leafs; uses yang-pkg-location; - leaf-list replaces-package { + leaf-list wraps-package { type pkg-name; description "Lists other packages that have been explicitly mounted - at the same mount point by the included package, that - are replaced by this mounted package. - - The replacing mounted package MUST include the mounted - package being replaced, but it may choose a different - version that SHOULD be a later version or revision. - - Any packages or modules included by the replaced - package are also removed by this mounted package - unless they have also been explicitly mounted at the - same mount point, in which case the replacing package - MUST also explicitly include/exclude them. - - replaces-package is expected to be used if an - implementation does not fully implement a mounted - package and needs to apply deviations or remove - included modules or mandatory-features."; + at the same mount point by an included package (i.e., + in the 'includes/package' list), that are replaced by + this mounted package. + + The replaced mounted package MUST include the mounted + package being replaced at the same package version. It + MAY also include the same package at other versions, in + which case it SHOULD select a higher version of the + wrapped package. + + This leaf is expected to be used if an implementation + does not fully implement the schema defined by a + mounted package and needs to apply deviations, modify + or remove module versions, or change + mandatory-features."; } } leaf-list parent-reference { type mount-ypath; description - "See Mount Point path and parent-reference in Schema Mount"; + "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."; } } } @@ -2005,7 +1963,7 @@ module ietf-yang-package-types {
file "ietf-yang-package-instance#0.5.0.yang" + file "ietf-yang-package-instance#0.8.0.yang" module ietf-yang-package-instance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance"; @@ -2018,7 +1976,7 @@ module ietf-yang-package-instance { import ietf-yang-package-types { prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } @@ -2042,7 +2000,7 @@ module ietf-yang-package-instance { used as the content schema for an YANG instance data document specifying a YANG package. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 @@ -2066,8 +2024,8 @@ module ietf-yang-package-instance { // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2094,7 +2052,7 @@ module ietf-yang-package-instance {
file "ietf-yang-packages#0.5.0.yang" + file "ietf-yang-packages#0.8.0.yang" module ietf-yang-packages { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages"; @@ -2112,12 +2070,11 @@ module ietf-yang-packages { import ietf-yang-package-types { prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } import ietf-inet-types { - prefix inet; rev:recommended-min-date 2013-07-15; reference "RFC 6991: Common YANG Data Types."; @@ -2136,7 +2093,7 @@ module ietf-yang-packages { description "This module defines YANG packages on a server implementation. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 @@ -2160,8 +2117,8 @@ module ietf-yang-packages { // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2264,7 +2221,7 @@ module ietf-yang-packages {
file "ietf-yl-packages#0.5.0.yang" + file "ietf-yl-packages#0.8.0.yang" module ietf-yl-packages { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages"; @@ -2282,7 +2239,7 @@ module ietf-yl-packages { import ietf-yang-packages { prefix pkgs; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: YANG Packages."; } @@ -2306,7 +2263,7 @@ module ietf-yl-packages { "This module provides defined augmentations to YANG library to allow a server to report YANG package information. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 @@ -2331,8 +2288,8 @@ module ietf-yl-packages { // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2359,7 +2316,7 @@ module ietf-yl-packages {
file "ietf-yang-inst-data-pkg#0.5.0.yang" + file "ietf-yang-inst-data-pkg#0.8.0.yang" module ietf-yang-inst-data-pkg { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg"; @@ -2372,7 +2329,7 @@ module ietf-yang-inst-data-pkg { import ietf-yang-package-types { prefix pkg-types; - ys:recommended-min-version 0.5.0; + ys:recommended-min-version 0.8.0; reference "RFC XXX: this RFC."; } @@ -2401,7 +2358,7 @@ module ietf-yang-inst-data-pkg { definitions to be used to define content schema in YANG instance data documents. - Copyright (c) 2025 IETF Trust and the persons identified as + 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 @@ -2424,8 +2381,8 @@ module ietf-yang-inst-data-pkg { // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. - revision 2025-03-03 { - ys:version 0.5.0; + revision 2026-01-30 { + ys:version 0.8.0; description "Initial revision"; reference @@ -2468,141 +2425,245 @@ module ietf-yang-inst-data-pkg {
-
- TODO - Update this to more closely follow the latest template - The YANG modules specified in this document defines a schema for data - that is accessed by network management protocols such as NETCONF or RESTCONF . The lowest - NETCONF layer is the secure transport layer, and the - mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the - mandatory-to-implement secure transport is TLS . - - The NETCONF access control model provides - the means to restrict access for particular NETCONF or RESTCONF users to - a preconfigured subset of all available NETCONF or RESTCONF protocol - operations and content. - - Similarly to YANG library , some of the readable data nodes - in these YANG modules may be considered sensitive or vulnerable in some - network environments. It is thus important to control read access (e.g., - via get, get-config, or notification) to these data nodes. - - One additional key different to YANG library, is that the - 'ietf-yang-package' YANG module defines a schema to allow YANG packages - to be defined in YANG instance data files, that are outside the security - controls of the network management protocols. Hence, it is important to - also consider controlling access to these package instance data files to - restrict access to sensitive information. - - As per the YANG library security considerations, the module, revision - information in YANG packages may help an attacker identify - the server capabilities and server implementations with known bugs since - the set of YANG modules supported by a server may reveal the kind of - device and the manufacturer of the device. Server vulnerabilities may be - specific to particular modules, module revisions, module features, or - even module deviations. For example, if a particular operation on a - particular data node is known to cause a server to crash or - significantly degrade device performance, then the YANG packages - information will help an attacker identify server implementations with - such a defect, in order to launch a denial-of-service attack on the - device. + +
+ This document defines YANG modules for defining YANG schema, that are + often used to configure and monitor network devices. + The document defines three YANG modules that are accessible from devices, + and the normal YANG network management security considerations apply, + which are further described below, in + . + YANG packages also offers an alternative + mechanism to YANG Library for reporting YANG + schema, and hence the security considerations from that document also apply + to the use of YANG packages. As per the YANG library security considerations, + the module and version information in YANG packages may help an attacker identify + the server capabilities and server implementations with known bugs since + the set of YANG modules supported by a server may reveal the kind of + device and the manufacturer of the device. Server vulnerabilities may be + specific to particular modules, module revisions, module features, or + even module deviations. For example, if a particular operation on a + particular data node is known to cause a server to crash or + significantly degrade device performance, then the YANG packages + information will help an attacker identify server implementations with + such a defect, in order to launch a denial-of-service attack on the + device. + The 'ietf-yang-package-instance.yang' YANG file allows YANG packages to + be defined in YANG instance data files. In addition, + "ietf-yang-inst-data-pkg" allows YANG packages to used to define the schema + for YANG instance data files. In both cases, the security considerations + from apply. Since YANG package instance data files + are outside the security controls of the network management protocols, it is + important to consider controlling access to these files to restrict access + to potentially sensitive information. + +
+ This section is modeled after the template described in Section 3.7 + of . + + The "ietf-yang-package-types", "ietf-yang-packages" and "ietf-yl-packages" + YANG modules define data models that are designed to be accessed via + YANG-based management protocols, such as NETCONF and + RESTCONF . These YANG-based management protocols (1) + have to use a secure transport layer (e.g., SSH , + TLS , and QUIC ) and (2) have + to use mutual authentication. + + The Network Configuration Access Control Model (NACM) + provides the means to restrict access for particular NETCONF or + RESTCONF users to a preconfigured subset of all available NETCONF or + RESTCONF protocol operations and content. + + Some of the readable data nodes in this YANG module may be considered + sensitive or vulnerable in some network environments. It is thus + important to control read access (e.g., via get, get-config, or + notification) to these data nodes. Specifically, the following + subtrees and data nodes have particular sensitivities/ + vulnerabilities: + + There are no particularly sensitive readable data nodes. + + + + Modules that use the groupings that are defined in this document + should identify the corresponding security considerations. For + example, reusing some of these groupings will expose privacy-related + information (e.g., 'yang-pkg-instance'). +
- It is expected that a central registry of standard YANG package - definitions is required to support this solution. - - It is unclear whether an IANA registry is also required to manage - specific package versions. It is highly desirable to have a specific - canonical location, under IETF control, where the definitive YANG - package versions can be obtained from. +
This document requests IANA to registers a URI in the "IETF XML Registry" . Following the format in RFC 3688, the following registrations are requested. - - URI: urn:ietf:params:xml:ns:yang:ietf-yang-package-types.yang + + URI: urn:ietf:params:xml:ns:yang:ietf-yang-package-types.yang - Registrant Contact: The IESG. + Registrant Contact: The IESG. - XML: N/A, the requested URI is an XML namespace. - - URI: - urn:ietf:params:xml:ns:yang:ietf-yang-package-instance.yang + XML: N/A, the requested URI is an XML namespace. + + URI: + urn:ietf:params:xml:ns:yang:ietf-yang-package-instance.yang - Registrant Contact: The IESG. + Registrant Contact: The IESG. - XML: N/A, the requested URI is an XML namespace. - - URI: urn:ietf:params:xml:ns:yang:ietf-yang-packages.yang + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-yang-packages.yang - Registrant Contact: The IESG. + Registrant Contact: The IESG. - XML: N/A, the requested URI is an XML namespace. - - URI: urn:ietf:params:xml:ns:yang:ietf-yl-packages.yang + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-yl-packages.yang - Registrant Contact: The IESG. + Registrant Contact: The IESG. - XML: N/A, the requested URI is an XML namespace. - - URI: urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg.yang + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg.yang - Registrant Contact: The IESG. + Registrant Contact: The IESG. - XML: N/A, the requested URI is an XML namespace. - + XML: N/A, the requested URI is an XML namespace. + This document requests that the following YANG modules are added in the "YANG Module Names" registry : - - Name: ietf-yang-package-types.yang + + Name: ietf-yang-package-types.yang - Namespace: - urn:ietf:params:xml:ns:yang:ietf-yang-package-types.yang + Namespace: + urn:ietf:params:xml:ns:yang:ietf-yang-package-types.yang - Prefix: pkg-types + Prefix: pkg-types - Reference: RFC XXXX - - Name: ietf-yang-package-instance.yang + Reference: RFC XXXX + + Name: ietf-yang-package-instance.yang - Namespace: - urn:ietf:params:xml:ns:yang:ietf-yang-package-instance.yang + Namespace: + urn:ietf:params:xml:ns:yang:ietf-yang-package-instance.yang - Prefix: pkg-inst + Prefix: pkg-inst - Reference: RFC XXXX - - Name: ietf-yang-packages.yang + Reference: RFC XXXX + + Name: ietf-yang-packages.yang - Namespace: - urn:ietf:params:xml:ns:yang:ietf-yang-packages.yang + Namespace: + urn:ietf:params:xml:ns:yang:ietf-yang-packages.yang - Prefix: pkgs + Prefix: pkgs - Reference: RFC XXXX - - Name: ietf-yl-packages.yang + Reference: RFC XXXX + + Name: ietf-yl-packages.yang - Namespace: urn:ietf:params:xml:ns:yang:ietf-yl-packages.yang + Namespace: urn:ietf:params:xml:ns:yang:ietf-yl-packages.yang - Prefix: yl-pkgs + Prefix: yl-pkgs - Reference: RFC XXXX - - Name: ietf-yang-inst-data-pkg.yang + Reference: RFC XXXX + + Name: ietf-yang-inst-data-pkg.yang - Namespace: - urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg.yang + Namespace: + urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg.yang - Prefix: yid-pkg + Prefix: yid-pkg Reference: RFC XXXX +
+
+ This document requests that IANA create a registry for IETF YANG + packages, that lists all versions of all YANG package definitions + published by the IETF, and provides a reliable location to store the + YANG package definitions. + + The name of the registry is "YANG Package Names". + + The registry shall record for each entry: + + the name of the YANG package + a brief description of the package purpose + The latest published package version + A list of all published package versions, each hyperlinked to the + location where that package definition may be retrieved from. + a reference to the package documentation (e.g., the RFC number) + + + There are no initial assignments. + + For allocation, the registration policy is Specification Required, + as defined in . All registered YANG package + names MUST comply with the rules for identifiers stated in Section 6.2, + and MUST have a package name prefix. + + The package name prefix 'ietf-' is reserved for package managed and + published under the IETF stream , while the + package name prefix 'irtf-' is reserved for IRTF stream documents. + Packages published in other RFC streams MUST have a similar suitable + prefix. + + All package names in the registry MUST be unique. +
+
+ This document requests IANA to register the following media type, + following the procedures of : + + + + Type name: application + + Subtype name: ypkg + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: 8bit; YANG package instance data files + are encoded in UTF-8. + + Security considerations: See the Security Considerations section + of RFC XXXX. + + Interoperability considerations: N/A + + Published specification: RFC XXXX + + Applications that use this media type: YANG tooling and servers + that generate or consume YANG package instance data files. + + Additional information: + + Magic number(s): None + File extension(s): ypkg + Macintosh file type code(s): 'Text' + Fragment identifiers: N/A + + + + Person & Email address to contact for further information: + NETMOD WG (mailto:netmod@ietf.org) + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: IETF + + Change controller: IESG + + +
@@ -2626,15 +2687,15 @@ module ietf-yang-inst-data-pkg { - - + + - + @@ -2656,18 +2717,32 @@ module ietf-yang-inst-data-pkg { - - + + + + + + + + + + + + + + + + @@ -2716,7 +2791,7 @@ module ietf-yang-inst-data-pkg { could also have been declared as implemented modules.
file "example-base-types-pkg%1.0.0.json" + file "example-base-types-pkg%1.0.0.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { "ietf-yang-instance-data:instance-data-set": { @@ -2761,7 +2836,7 @@ module ietf-yang-inst-data-pkg { rules.
file "example-base-types-pkg%1.1.0.json" + file "example-base-types-pkg%1.1.0.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { "ietf-yang-instance-data:instance-data-set": { @@ -2818,7 +2893,7 @@ module ietf-yang-inst-data-pkg {
file "example-ietf-network-device-pkg.json" + file "example-ietf-network-device-pkg.ypkg" ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { @@ -2847,7 +2922,7 @@ module ietf-yang-inst-data-pkg { to support.", "reference": "XXX, draft-rwilton-netmod-yang-packages", "location": [ "file://example.org/yang/packages/\ - ietf-network-device@v1.1.2.json" ], + ietf-network-device@v1.1.2.ypkg" ], "module": [ { "name": "iana-crypt-hash", @@ -2930,7 +3005,7 @@ module ietf-yang-inst-data-pkg {
file "example-ietf-routing-pkg.json" + file "example-ietf-routing-pkg.ypkg" ========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== { @@ -2958,7 +3033,7 @@ module ietf-yang-inst-data-pkg { "name": "ietf-network-device", "version": "1.1.2", "location": [ "http://example.org/yang/packages/\ - ietf-network-device@v1.1.2.json" ], + ietf-network-device@v1.1.2.ypkg" ], } ], "module": [ @@ -3228,7 +3303,7 @@ module ietf-yang-inst-data-pkg {
This section provides examples of how to exclude modules, and packages - in a package definition, and to remove mandatory features. + in a package definition, and to remove mandatory-features. The examples are non-normative, and for brevity, some expected information (e.g., locations) are omitted. @@ -3240,7 +3315,7 @@ module ietf-yang-inst-data-pkg { The following example defines two YANG packages. The first package, "example-ab-pkg", implements two example modules, "example-module-a" and "example-module-b", two related types modules, - and declares two mandatory features. + and declares two mandatory-features. The second package, "example-c-pkg", imports the first package, but excludes the implemented "example-module-a" module, the import-only @@ -3251,7 +3326,7 @@ module ietf-yang-inst-data-pkg { but with namespaces and locations elided for brevity.
file "example-ab-pkg%0.1.0.json" + file "example-ab-pkg%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "example-ab-pkg", @@ -3300,7 +3375,7 @@ module ietf-yang-inst-data-pkg { modules, import-only-modules and features.
file "example-c-pkg%0.1.0.json" + file "example-c-pkg%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "example-c-pkg", @@ -3318,7 +3393,7 @@ module ietf-yang-inst-data-pkg { "name": "example-ab-pkg", "version": "0.1.0", "location": [ - "file:///Users/rwilton/git/netmod-wg/yang-ver-dt/yang-packages/out/ExampleAbPackage/makePackage.dest/yang-pkg.json" + "file:///Users/rwilton/git/netmod-wg/yang-ver-dt/yang-packages/out/ExampleAbPackage/makePackage.dest/yang-pkg.ypkg" ] } ], @@ -3352,7 +3427,7 @@ module ietf-yang-inst-data-pkg { package have been resolved.
file "example-c-library%0.1.0.json" + file "example-c-library%0.1.0.ypkg" { "ietf-yang-instance-data:instance-data-set": { "name": "Package example-c-pkg@0.1.0 schema", @@ -3436,7 +3511,7 @@ module ietf-yang-inst-data-pkg { 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 mandatory features, + remove modules from a mounted package, change mandatory-features, change the behaviour of recursive mounts, etc. TODO - Probably need more than one example.