摘要

  • IESG 于 2026 年 8 月 18 日宣布批准 draft-ietf-netmod-yang-module-versioning-17 作为拟议标准发布。文件允许明确记录非向后兼容的模块演进，为 import 加入 recommended-min-date，并说明服务器如何呈现已弃用和已废止节点。
  • 文件自己的分支示例揭示了日期准入的边界：2019-05-01 修订满足 2019-04-01 的最低建议日期，却可能不含 2019-04-01 分支引入的内容。日期可以排序工件，不能证明后代关系、目标端有效模式或部署权。

日期门槛放进了旁支

开篇场景是依据规范示例建立的分析性情境，不是已经发生的设备、厂商或网络事故。解析器严格执行 recommended-min-date：只要候选日期不早于建议日期，就算满足条件。

问题出在历史结构。示例从共同的 2019-02-01 修订分叉：一边经过 2019-03-01 到达 2019-05-01，另一边经过 2019-04-01 到达 2019-06-01。若使用方需要 2019-04-01 引入的能力，以该日为下限后，2019-05-01 在算术上合格，在谱系上却属于兄弟分支。

草案明确提醒，2019-05-01 可能不含 2019-04-01 所需内容，并称这个字段不适合分叉历史，最适用于线性时间序列。由此暴露的不是比较器缺陷，而是准入判断混淆了两类事实：“更晚”是日历位置，“继承自”是图上的路径。

新标准让不兼容边变得可见

IESG 批准的文件题为“Updated YANG Module Revision Handling”，来自 NETMOD 工作组。它目前仍是进入 RFC Editor 队列的 Internet-Draft，正式发表前可能出现编辑性改动；公告还说明实现状态未知，因此不能把规范批准推断成厂商已普遍支持。

RFC 7950 原本要求模块更新保持严格向后兼容。新文件承认，有些错误修复、已废止节点清理、未稳定模型调整或代价失衡的重构可能需要不兼容变化，但作者仍应尽量减少这类变化。

当某次修订相对于父修订包含非向后兼容变化时，它必须在 revision 语句下携带 rev:non-backwards-compatible。这一标记把过去可能沉默的边变成可审查证据，却只描述当前修订与父修订之间的关系。它不会凭空证明所选修订来自使用方需要的那条分支。

不可变身份不等于血缘证明

在同一修订历史内，模块名与修订日期共同标识一个不可变的模块定义。这使日期具有很强的身份用途，却不赋予它谱系用途。文件指出，仅比较日期或版本标识无法确定两个模块或子模块修订之间的祖先关系，必须查看完整修订历史。

子模块进一步说明了边界。如果 include 没有锁定精确的子模块修订日期，仅凭包含它的模块也无法确定最终用了哪一份子模块。YANG Library、软件包清单或精确 revision-date 才能补齐上下文。

因此，准入记录不能只保留“选中了哪个日期”。它还要保留工件哈希、父边或分支路径、子模块版本以及目标端解析出的模块集合。否则，即使标识指向不可变文件，系统仍可能把它放进错误的家谱。

最低建议日期刻意避免硬锁定

recommended-min-date 是 import 下可以出现零次或一次的扩展子语句。被导入修订的日期等于或晚于所列日期时即符合建议；加入、修改或移除这项建议本身被归类为向后兼容。无法识别该扩展的解析器会继续按 RFC 7950 的普通规则处理 import。

草案在需要表达依赖下限时，倾向用它代替精确的 import revision-date，因为精确日期会造成过严耦合。这个取舍有实际价值：使用方可以吸收后来的兼容修订，而不被锁死在单一工件上。

但松耦合必须配套另一道适用性判断。日期建议只是在仓库里扩大候选集合，不会验证候选是否继承指定能力、保留所需节点、采用相同默认值，或适合特定客户端。正确做法不是在“完全锁定”和“只看日期”之间二选一，而是先用日期筛选，再用谱系与有效模式收口。

不兼容标记属于边，不属于整张图

rev:non-backwards-compatible 可以提醒某个节点变为废止、约束发生变化，或出现其他被允许的不兼容调整。它描述的是一条父子边，不能认证该修订与分叉历史上所有其他节点的关系。

当仪表盘把证据压缩成“最新日期”和“是否有警告”时，风险尤其明显。使用方依赖的能力可能在另一分支出现；所选行没有警告，并不会创造一条不存在的祖先边。

规范还允许维护者对形式上兼容、但可能显著影响客户端的变化添加该标记，例如扩展操作状态叶的取值范围。信号故意偏保守：它要求人或工具检查真实差异，而不是自动给出接受或拒绝答案。模式比较说明改了什么，目标测试说明实际能否协同，两者都不能被一个布尔标记替代。

历史裁剪会改变可证明的范围

维护者可以在一定条件下删除旧 revision 语句，例如缩短过长历史或阻止继续依赖陈旧修订。但最新条目必须保留，剩余的不兼容标记也必须继续准确反映保留条目之间的关系。

文件不鼓励裁剪，因为它可能遮蔽不兼容变化首次出现的位置。示例还禁止一种删除：若删除中间条目会让后续修订跨过隐藏的不兼容步骤后显得兼容，就不能这样做。

历史保存因此不是装饰性文档，而是生产证据的一部分。若标准记录不再保存所需边，工件仓库、签名哈希、软件包清单和变更记录就必须保留可重建的链。一个只为界面整洁而压缩历史的决定，可能悄悄削弱未来准入的可审计性。

节点状态是目标端事实

新的 ietf-yang-library-status 模块给 YANG Library 增加两个布尔值。deprecated-nodes-implemented 为 true，表示已弃用节点仍按 current 实现，除非 deviation 明确移除；obsolete-nodes-absent 为 true，表示服务器没有实现已废止节点。

两者默认都是 false，而 false 的含义是行为未指定，不是相反事实已经成立。草案建议服务器把两者都设为 true，使客户端可以确定精确模式。如果第一项不为 true，客户端在判断兼容性时就不能只依赖不兼容标记。

这说明即便分支选对，日期仍不能完成准入。目标设备可能已移除某个已弃用节点，也可能仍保留已废止节点；deviation 还会进一步改变结果。生命周期指引要求从 current 过渡到 deprecated 再到 obsolete，客户端应计划停用已弃用节点，并必须停止使用已废止节点。这是一项运营迁移，而不是日历能够推断的属性。

准入需要图，也需要正在运行的目标

可靠的控制器应记录所需能力及其首次出现的修订，解析精确工件，证明从该修订到候选的父路径，保存不兼容边和历史缺口，锁定子模块，抓取 YANG Library 与节点状态，再应用 deviations、编译有效模式并验证代表性数据。

之后还要在真实服务器软件和配置类别上测试客户端。新模式可以产生超出旧客户端假设范围的值，可以改变默认值，也可能要求调整 NACM 规则。日期比较观察不到这些后果。

失败必须保持可区分：错误旁支是谱系失败，节点状态缺失是目标发现缺口，树结构改变是模式失败，越界值或默认值变化是实现后果，没有授权则是治理失败。日期仍有用，但它的权限只到候选选择为止；进入生产必须由可证明的血缘、精确目标状态、运行测试和具名负责人共同决定。

来源