Conversation
Improve text for #120
…ang-ver-dt into remove-pkg-exclusion
There was a problem hiding this comment.
Pull request overview
This PR updates the YANG package specification and associated documentation to version 0.8.0, incorporating refinements to the package model structure, terminology clarifications, and expanded conformance guidance.
Changes:
- Updated package version from 0.7.0 to 0.8.0 with revision date 2026-01-30
- Introduced new
module-nametypedef and restructuredimport-only-moduleexclusion mechanism to support version-specific exclusions - Enhanced conformance section with clearer guidance on package schema comparison, deviation usage, and handling of multiple included package versions
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| yang-packages/ietf-yang-package-types.yang | Updated module version, added module-name typedef, restructured import-only-module exclusions to support per-version exclusions, removed replaces-version field, added mandatory constraints, reformatted descriptions |
| yang-packages/draft-ietf-netmod-yang-packages.xml | Updated terminology definitions, clarified conformance requirements, restructured and expanded conformance section, updated examples and references to use consistent terminology |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| <t>A package definition CANNOT remove a package from a mount point, | ||
| but it MAY replace it a different package version, which SHOULD be | ||
| but it MAY add a different package version, which SHOULD be |
There was a problem hiding this comment.
The phrase 'add a different package version' is unclear. Based on the context that this is about replacing a package at a mount point, consider 'replace it with a different package version' for clarity.
| but it MAY add a different package version, which SHOULD be | |
| but it MAY replace it with a different package version, which SHOULD be |
| <t>Better and easier conformance is a major design goal for YANG Packages. YANG | ||
| package conformance is similiar to how YANG <xref target="RFC7950"/> | ||
| requires that servers either implement a module faithfully, or otherwise | ||
| use deviations to indicate areas of non-conformance. Ulitmately, each |
There was a problem hiding this comment.
Corrected spelling of 'Ulitmately' to 'Ultimately'.
| use deviations to indicate areas of non-conformance. Ulitmately, each | |
| use deviations to indicate areas of non-conformance. Ultimately, each |
| use deviations to indicate areas of non-conformance. Ulitmately, each | ||
| version of a YANG package resolves, as per (<xref target="resolution"/>), | ||
| to a YANG schema that is defined as a set of implemented modules and | ||
| import-only modules, devations, features, and mounted schema. For YANG |
There was a problem hiding this comment.
Corrected spelling of 'devations' to 'deviations'.
| import-only modules, devations, features, and mounted schema. For YANG | |
| import-only modules, deviations, features, and mounted schema. For YANG |
| * 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), |
There was a problem hiding this comment.
So if a module has been removed, that module wouldn't be part of implemented other import-only module list?
|
|
||
| * resolved package schema: The resolved package schema is the YANG | ||
| schema defined by a package after package resolution has been |
There was a problem hiding this comment.
Should we have "YANG schema" as a term introduced in another doc?
|
|
||
| * 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 |
There was a problem hiding this comment.
Drawing a bit of a blank on "expected package definition". So we expect Package X 1.0.0 to have a certain schema and we want to compare whether a server/device actually has that schema? Or are we comparing something else e.g. module versions?
| 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. |
There was a problem hiding this comment.
If we don't have it already, it would be good to have an example of that.
| Identities are only available for use by the server for | ||
| implemented modules. |
There was a problem hiding this comment.
?
I am not understanding this.
| <t>Better and easier conformance is a major design goal for YANG Packages. YANG | ||
| package conformance is similiar to how YANG <xref target="RFC7950"/> | ||
| requires that servers either implement a module faithfully, or otherwise | ||
| use deviations to indicate areas of non-conformance. Ulitmately, each |
There was a problem hiding this comment.
| use deviations to indicate areas of non-conformance. Ulitmately, each | |
| use deviations to indicate areas of non-conformance. Ultimately, each |
| datastore schema used by the server is compatible with the client.</t> | ||
|
|
||
| <t>In the case where a device does not completely conform to | ||
| an standard or industry defined YANG package definition, then there are a |
There was a problem hiding this comment.
| an standard or industry defined YANG package definition, then there are a | |
| a standard or industry defined YANG package definition, then there are a |
|
|
||
| 7.1. Resolving Conflicting Module Versions in Included Packages | ||
| 7.2. Handling multiple included package versions |
There was a problem hiding this comment.
Is included packages the same as import-only packages?
| description | ||
| "Module names are typed as YANG identifiers."; | ||
| } | ||
|
|
||
| typedef version-or-rev-date { |
There was a problem hiding this comment.
I thought we already had a type for this in yang-server, will check
There was a problem hiding this comment.
Shouldn't we flag this? I mean we have to choose between 2 NBC module versions, to me that indicates incorrect package.
PR for current round of package updates