摘要

  • draft-ietf-netmod-yang-versioning-reqs-14 只定义问题和方案必须回答的五组需求，并明确不考虑、不背书具体方案。
  • WG Document、I-D Exists、需求映射或 BC/NBC 标签都是有限的文档证据，不能替代客户端、服务器、迁移与运行验证。

一次架构评审把五组需求做成五行表格。有人为每一行贴上相邻草案的链接，于是整列变绿。表里没有模块字节、依赖闭包、客户端版本、服务器行为、迁移损失或回滚结果，却已经写下“验收通过”。

第 14 版恰好禁止这种阅读。它发布于 2026 年 7 月 20 日，页眉写明预期状态为 Informational；Datatracker 将其列为 NETMOD 的 active Internet-Draft、WG Document，IESG 状态为 I-D Exists。摘要同时划出边界：本文描述问题、定义任何方案应满足的需求，但不讨论也不认可某个方案。

第一组不是一个开关

第一组要求模块可以发生 NBC 更新，而不迫使所有导入者同步改名；只使用未变或兼容变化节点的客户端不应受影响；import 约束要介于“任意 revision”和“精确 revision”之间；不兼容变化还必须可表达。

这至少对应四张收据。依赖收据记录完整 import/include 解析和实际选中的字节；分类收据记录比较规则与人工判断；有效 schema 收据带上 features 和 deviations；客户端收据记录真实二进制的执行。一个标记即使语法正确，也不能同时证明四件事。

第二组要求读者和工具识别 BC/NBC，并能比较任意 revision 的节点变化。草案背景承认，语义行为可能变化而 YANG statement 并未变化，此时机器比较看不到全部后果。验收必须保留前后字节、比较语境、分类依据、审查者和 warning。工具读懂标签，只证明标签可读，不证明标签正确。

旧客户端和退役节点必须在目标上验证

第三组要求服务器继续支持既有客户端，包括仍期待旧模块版本的客户端。验证必须双向进行：旧客户端对新服务器、新客户端对旧服务器，并覆盖读写、RPC、notification、错误和权限语境。

第四组要求客户端知道 deprecated 节点是否实现，要求说明替代方案与状态变更原因，并在定义真正 obsolete 之前给出仍可使用的预警。服务器声明可以缩小不确定性，却不能证明节点真的存在、deviation 已正确应用或重启后仍保持同一行为。

第五组要求说明如何从 YANG 1.0/1.1 迁移，以及 NBC schema 如何影响 instance data 与引用。RFC 9195 能把实例数据绑定到 content-schema，但也明确跨 schema 可用性取决于 revision、feature、deviation、范围和兼容性。真正的迁移收据必须清点重命名、删除、生成、默认化和拒绝的数据，验证语义不变量，并证明回滚还能读取新状态。

revision graph、Semver、package、schema comparison、module filename 与 YANG 2.0 都可能回答矩阵中的部分问题。本篇不重复它们的机制。相邻草案声称对应某项需求，只能建立待核验的映射，不能把实现、互操作或部署结果提前写入。

主要来源

官方冻结来源包括第 14 版、Datatracker 状态、历史、NETMOD 文档表，以及 RFC 2119、RFC 6020、RFC 7950、RFC 8049、RFC 8299、RFC 8525 和 RFC 9195。