摘要

  • draft-ietf-netmod-yang-packages-09 用 includes、excludes、depends-on、模块、特性、偏差与挂载点递归构造 resolved package schema，并可通过 YANG Library 或 .ypkg 文件表达。
  • complete: true、位置可访问、包名与版本唯一、服务器宣告符合某包，都有明确价值；它们却不能单独回答字节是否漂移、冲突是否选中预期版本、进程是否加载、双端是否一致以及滚动部署是否可恢复。

设想一份看起来无可挑剔的验收记录：包名与版本唯一，JSON 通过验证，包含图无环，每个位置都能访问，解析器列出了唯一的实现模块版本、import-only 模块、特性、偏差和挂载模式，并把 complete 判为真。

这份记录依然可能漏掉最重要的事实。控制器从旧缓存读取了同名同版本的 .ypkg；服务器公布的是新定义；两边都“解析成功”，却没有使用同一组字节。

这不是对包机制的否定，恰恰说明它提供了什么。第 09 版发布于 2026 年 7 月 6 日，是 NETMOD 工作组的活跃 Internet-Draft，拟走标准轨，并将于 2027 年 1 月 7 日到期。它把散落模型组织成可命名、可版本化、可递归求解的结构。它仍是进行中的草案，不能被当作实现或部署收据。

解析的实质是继承、覆盖和删减

includes 不只列包，也能直接加入 implemented module、import-only module 和必须开启的 feature。excludes 从继承结果里移除模块、特定 import-only 版本或特性。depends-on 给不完整包提供外部依赖提示，但依赖项本身不进入这个包的 resolved schema。mount 则把包与特性放进指定挂载点，并决定是否继承上层挂载定义。

求解分两步。先递归解析每个 included package；再把所有子结果与本地 includes、excludes、mount 合并。实现模块先取并集，冲突后选出一个版本，本地显式模块可以覆盖，最后再应用排除。import-only 模块可保留多个版本。特性先汇总、再增加或删减；排除模块会连带移除该模块的特性。

挂载点尤其容易被低估。同一路径下，继承开启时，mounted package、additional feature 与 parent reference 叠加；inherit-packages=false 时，继承的挂载包集合会被丢弃，由本地定义接管。顶层包名看似不变，局部模式却可能整体替换。

位置列表也有次序。重复引用同一版本时，列表按 include 顺序合并，保留第一次出现的位置。可重复的算法让结果可审计，却不会认证第一个 URI 返回的内容。

冲突规则不会读取部署者的意图

一个 resolved schema 只能实现一个模块版本。若 included packages 带来冲突，草案会按顺序选择：两者都是 YANG Semver 时，只比较 major、minor、patch，忽略兼容性修饰符、预发布和构建信息；只有一方符合 Semver，则选该方；都不符合时，以较新的 revision-date 为准；本地 includes/module 还能显式覆盖继承选择。

这些规则是确定性的，但不知道客户端针对哪个版本生成代码，也不知道运维者认为哪个分支安全。审计不能只保存“成功”，必须保存候选全集、比较规则、胜出者、覆盖、排除、位置次序和警告。

本文不重复 schema-comparison 对差异的分类。差异标签能帮助判断，却不能证明比较输入就是进程实际加载的字节，也不能替代客户端执行测试。

完整性只回答 import 是否闭合

草案对 referential completeness 的定义很窄：直接或间接纳入的全部模块，其所有 import 都能在包定义中解析到具体模块版本，才算完整。热修复或逻辑分组可以保持不完整，并用 depends-on 指向建议共同解析的包。

因此 complete: true 不等于来源可信、镜像没有漂移、每个 submodule 都实际存在，或实例数据与运行行为都兼容。包会列 submodule 的有序位置，但版本冲突比较以模块为单位；版本相同时，submodule 信息可能被假定等价。运维仍要冻结实际 submodule 字节并复现闭包。

“同一 package name/version 全局唯一”也不是哈希承诺。草案期待多处相同引用的内容和元数据等价，并允许位置不同。若镜像漂移，期待本身不能选出真值。至少要保存发布主体、URI、抓取时间、缓存来源、精确摘要和验证结果。

服务器知道一个包，不等于数据存储正在使用它

服务器顶层 packages 列表是已知包目录，可以同时列多个版本；条目不代表实现，更不代表任何 datastore 当前启用。真正的绑定在 YANG Library augmentation：某 datastore schema 关联哪些顶层 package name/version，以及哪些 additional features。

一旦填写，解析结果必须 referentially complete，并与 YANG Library 的 module-set 精确一致。这是强约束，但仍是报告层一致性。客户端要自行对比两种表示，记录观察时间和 content-id。content-id 是服务器生成的变更标记，不是跨系统通用摘要。

.ypkg 把包作为 JSON 的 YANG instance data 携带，使用专用媒体类型。客户端可用服务器提供的定义、从 location 抓取，或复用同名同版本缓存。文件通过模式验证，只证明结构与声明值符合规则；不会证明作者身份、新鲜度、递归选择、服务器加载或互操作。

RFC 9195 还明确把 instance data 与在线配置/状态协议分开。离开 NETCONF/RESTCONF 的文件需要独立的访问控制与保管证据。

符合性声明停在模式边界

包级符合性判断的是实现是否忠实覆盖 resolved package schema。若设备不能完整实现标准包，草案建议定义 server implementation package：包含并细化原包，选择不同模块版本、增加 deviations、排除模块或 feature。这能诚实表达差异，却不能自动让客户端接受这些差异。

尤其是多个 included package 版本可以同时保留在 resolved schema 的包清单中，而每个 implemented module 最终只有一个胜出版本。对哪个递归包、在什么修改之后仍有何种符合性，必须逐项说明。

最稳妥的证据链要分栏保存：包身份与发布者；实际抓取字节；结构验证；递归边轨迹；冲突选择；import 与 submodule 闭包；最终 resolved schema；YANG Library 的 datastore 绑定；进程加载；客户端与服务器集合；代表性配置、状态、RPC、通知和权限测试；部署次序与回滚；运行态；外部服务结果。

每一栏都能减少一种不确定性。任何一栏都不应借用下一栏的结论。

主要来源

主要依据为 YANG Packages 第 09 版及其 Datatracker 页面/历史，并结合 RFC 7950、RFC 8525、RFC 9195、RFC 8528、RFC 8342、YANG Module Versioning 第 17 版、YANG Semantic Versioning 第 28 版与 IETF 122 NETMOD 会议记录：