摘要

  • RFC 9911 是 IETF Proposed Standard，发布于 2025 年 12 月；它修订 ietf-yang-types 和 ietf-inet-types，并废止 RFC 6991。
  • 模块名称与命名空间仍然熟悉，但修订可以改变可接受值、规范化表示和描述，因此仅比较 namespace 不能证明语义兼容。
  • 部署方应按确切的模块修订盘点依赖模型，回放真实数据存储值，并比较不同实现的验证结果和序列化输出。

机制：名称稳定，契约会移动

YANG 导入通常让团队把模块名当成稳定边界。RFC 9911 提醒我们，修订声明才是这个边界中的另一项事实：相同的模块身份可以发布新的修订日期。依赖模型未必需要改写 import 的模块名，却可能继承新的 typedef 取值空间、模式、规范形式或说明文字。因而，namespace 连续性不保证语义兼容，也不意味着所有 RFC 6991 的旧值都无效。

RFC 9911 在两个通用模块中补充日期和时间、duration、语言标签、协议号、链路本地地址、地址与前缀、主机名及电子邮件地址等类型。它还把 yang-identifier 与 YANG 1.1（RFC 7950）对齐，并修正或改进多个 pattern 和 description。对只做结构检查的工具来说，这些可能像文档变化；对服务器、客户端、配置数据库和代码生成器来说，它们可能改变验证或互操作结果。

时间类型尤其需要测试。按照 RFC 9557 纳入的语义，Z 和 +00:00 都表达 UTC，但含义并不相同：Z 表示 UTC；+00:00 还断言 UTC 是本地参考点。解析器若把二者无条件折叠，可能丢失输入所携带的语义；序列化器若改写表示，也可能造成签名、缓存、比较或审计差异。这里不是说某一实现一定错误，而是说应用必须知道它保存的是瞬时值、原始词法表示，还是二者。

地址和主机名相关变化也不应被当作单纯升级补丁。新的 link-local、address-and-prefix、host-name 和 email 类型可能让某个此前被接受的字符串在新 pattern 下需要复核，也可能让原本被拒绝的合法输入获得更清楚的表达。RFC 9911 对若干类型还明确说明与 SMIv2 textual convention 的等价或非等价关系；跨 SNMP、YANG 和转换工具的映射不能靠类型名称猜测。

迁移面在哪里

依赖模型的风险不止在编译期。服务器启动时可能选择不同修订，数据存储中的历史值可能在重载、编辑或导出时重新验证，RESTCONF、NETCONF 或代码生成客户端可能使用不同的规范化规则。一个实现能读入值，并不证明另一个实现会接受相同词法形式；一个 serializer 输出了 +00:00，也不代表所有消费者把它与 Z 看成完全相同的输入。

这不是普遍采用的宣告，也不是一刀切的不兼容结论。冻结的数据、明确锁定修订的客户端和只处理不受影响 typedef 的模型，风险可能较低。未知事项包括哪些已部署服务器采用 2025 修订、客户端是否固定修订，以及哪些现有 datastore 值会触发新 pattern。应以证据而不是供应商假设填补这些空白。

来源