摘要

  • RFC 6020 的旧措辞要求注册表中的所有模块名、子模块名以及所有 XML 命名空间保持唯一；RFC 9890 第 3 节说明，这一措辞并未反映 IANA 对修订版本的既有处理方式。
  • RFC 9890 改为要求初始版本的模块名和子模块名保持唯一；后续修订沿用初始版本的名称。初始版本的 XML 命名空间保持唯一，模块的每个修订也沿用该初始命名空间。
  • IANA 将 RFC 9890 列为附加参考，因为其中的程序对 YANG Module Names 注册表的名称分配具有权威性。注册表身份与部署清单中的修订标识是不同层次的证据。

机制先行：名称不变，内容可能变

操作员看到的模块名和 XML 命名空间可能在修订之间完全相同。这个不变量保护的是初始注册身份的连续性，并不是“每一次修订都有一个全局唯一名称”的承诺。要知道某台设备验证、部署或保留用于回滚的到底是哪一版，系统仍须记录修订信息以及足以重建当时输入的模块文本、校验和或其他明确版本证据。

RFC 6020 的原始唯一性表述容易被读成：注册表中的每个名称和命名空间都不能重复。RFC 9890 的更新承认 IANA 实践中修订需要复用初始名称和命名空间，并把政策调整到这一既有实践。它没有把名称改成修订号，也没有要求每个实现增加新的管理操作。

IANA 的权威程序

这里的“权威”是注册分配程序的权威：IANA 注册表记录初始模块或子模块的名称及其命名空间，并以 RFC 9890 作为额外参考。冻结快照只能证明观察时的注册表状态。它不能证明某个模块修订的实现质量、运营者采用程度、工具兼容性或语义正确性，也不能替代部署系统中的版本清单。

注册表身份不是修订感知库存

这是 Theo March 的分析，而不是 RFC 9890 的要求：把稳定名称直接当作兼容性断言，会制造身份歧义。自动化如果只按名称缓存 schema，可能把新修订误认为已验证输入，形成自动化漂移；如果回滚记录只保留名称和命名空间，事后也无法证明回到了哪一个语义版本。更稳妥的控制是把名称、XML 命名空间、修订日期或等价修订标识、模块来源、哈希、验证结果和部署时间放在同一条修订感知记录中。

可复现的验证夹具

以下是建议的操作验证夹具，不是 RFC 新增要求：

  1. 取两个具有相同初始模块名和 XML 命名空间的连续修订，分别保存原始模块文本和 SHA-256；确认注册表查询返回的是同一稳定身份，而清单仍能区分两个修订。
  2. 让验证器明确接收修订标识和哈希，而不是只接收模块名；记录验证输入、结果、工具版本和时间。
  3. 在部署模拟中故意交换两个修订的文件，检查系统是否拒绝哈希或修订不匹配；回滚时检查是否能从记录准确取回目标文件。
  4. 将冻结的 IANA 快照与当前查询分开保存，标明观察时间，不把快照当成实现正确性的证明。

这些夹具不能推导未提供的事实。证据集没有测量多少工具曾假定所有修订的名称都必须全局唯一；没有确立任何运营事故、互操作失败或迁移成本；RFC 也没有验证连续修订的语义兼容性。快照在观察之后可能变化，供应商支持和部署普及率同样不在来源范围内。

来源