摘要

  • draft-ietf-netconf-error-registries-00 提议建立两个 IANA 注册表，分别收录 YANG 协议错误标签与错误身份；但第 00 版仍明显处于编辑阶段，返回名称并不等于根因记录。
  • 可靠自动化必须保留会话、操作、请求身份、授权判定、目标路径、带模块限定的身份、结构化提示、事务结果、修复动作、状态回读与服务结果。

自动化平台收到 invalid-value，于是准备重试。

这个动作看似有据可依：名称标准、拼写稳定，也能写进规则。然而 RESTCONF 中，同一个标签可以对应 HTTP 400、404 或 406。涉及访问控制时，服务器还可以用 404 和 invalid-value 回应，以免向请求者确认受保护资源确实存在。标签是正确的；它恰恰因为没有泄露全部事实而正确。

这正是 2026 年 9 月 30 日发布的 draft-ietf-netconf-error-registries-00 所揭示的边界。这个 NETCONF 工作组活跃文档建议建立“YANG Protocol Error List”和“YANG Protocol Error Identities”两个注册表。目标合理：随着 YANG 驱动的管理协议演进，不应要求每一个实现都反复从多份 RFC 中拼装一套所谓权威清单。

第 00 版拟走 Standards Track，2027 年 4 月 3 日到期。它不是 RFC，不是已经获批的 IANA 注册表，也不证明任何产品已实现或互通。五页篇幅更像治理面的开题，而不是结题。

第一个注册表计划保存 error-tag、可用的 error-type 与 error-severity、error-info、说明以及登记该值的文档。第二个注册表计划保存身份名称、适用时的基础身份、补充信息和登记文档。两者都提出采用 IETF Review。

集中管理确有价值。统一清单可以减少拼写漂移，让新增值可发现，把每个值与拥有它的规范相连，并让新增、变更、弃用和替代接受共同审议。它建立的是跨实现的词汇控制面。

但第 00 版也显示：要成为机器依赖，注册表自身必须极其精确。错误清单中前三个字段的说明仍写着 TBD。草案称初始内容来自 RFC 6241 附录 A，却只内嵌了前五项：in-use、invalid-value、too-big、missing-attribute 和 bad-attribute。附录 A 后面还有 access-denied、resource-denied、rollback-failed、data-missing、operation-not-supported、operation-failed 以及 malformed-message 等多项。

身份清单同样带有初版编辑痕迹。filter-unsupported、insufficient-resources 和 no-such-subscription 重复出现；引用的 RFC 中却有若干身份未列入。RFC 8639 包括 stream-unavailable、suspension-timeout、unsupportable-volume；RFC 8641 包括 cant-exclude、no-such-subscription-resync、on-change-unsupported、on-change-sync-unsupported 与 sync-too-big。草案还以 RFC 5226 说明注册政策，而当前 BCP 26 已是取代它的 RFC 8126。

这不能被夸大成未来标准的永久缺陷。准确结论只是：第 00 版仍需完成去重、补全、引用更新和字段定义。客户端也不应偷偷用私有表修补空缺，否则会重新制造草案本来要消除的碎片化。

即使这些编辑工作全部完成，注册表仍不会自动成为事故报告。

RFC 6241 的 NETCONF <rpc-error> 从来不是一个孤立代码。一次回复可以包含多个错误元素；每个元素又可包含错误发生的概念层、协议标签、严重性、数据模型或实现特定的应用标签、指向目标节点的 XPath、供人阅读的消息和结构化信息。不同字段回答不同问题，不能压缩成一个“根因”。

RFC 8640 对订阅错误的映射尤其清楚。filter-unsupported 对应较宽泛的 invalid-value；insufficient-resources 对应 resource-denied；on-change-unsupported 对应 operation-not-supported；sync-too-big 对应 too-big；unchanging-selection 对应 operation-failed。更具体的身份作为带模块名的 error-app-tag 传递，例如 ietf-subscribed-notifications:no-such-subscription。

即便拿到这个具体身份，也不能脱离操作解释。RFC 8640 规定，可用的基础身份取决于失败的是建立、修改、删除、终止还是重新同步订阅。建立与修改请求还可能通过 error-info 返回参数提示，让下一次请求有机会成功。把 RPC、模块和提示丢掉，只留下单词，就等于主动降级证据。

unchanging-selection 是最能说明问题的例子。RFC 8641 允许发布者在选择条件指向不存在的数据，或指向接收者无权读取的数据时返回该身份。之后的权限变化若使原本可见的选择再也不能产生可见更新，也可以使用同一身份。修正路径、申请权限、在策略变化后重建过滤器，是三种不同处置。协议把它们压成一个安全回应，是为了维护抽象并降低信息泄漏，而不是邀请客户端猜测隐藏事实。

no-such-subscription 也保持同样的边界。按照 RFC 8639，它可能表示标识符不存在，也可能表示订阅属于其他订阅者，或者该标识符对应配置订阅、当前 RPC 根本不适用。调用方得到的是足以行动的安全结论：“这次操作不能作用于该标识符。”它没有得到窥视服务器内部记录的权利。

insufficient-resources 压缩的是另一类不确定性。它说明发布者无法生产所要求的订阅，却不说明短缺的是内存、CPU、带宽、队列、实现上限还是政策配额；也不说明容量由谁控制、何时恢复、哪项负载应当让路，或者重试应该等待多久。

因此，注册表是名称的权威，不是事件的神谕。

一条最低可用的故障回执必须从错误发生之前开始：协议与传输会话、RPC、请求标识、已认证主体、授权决策。随后保存目标 datastore 与路径、宽泛标签、带模块限定的应用身份及其基础身份、error-info、服务器与模型版本、事务结果。采取干预之后，还要保存谁批准了什么变化、状态回读结果以及服务是否真正恢复。

每一环都阻止一种错误等式。404 不等于不存在。具体应用身份不等于物理根因。再次请求被接受不等于状态已变。状态确已改变，也不等于预期服务已恢复。

Heng Lu 关于“最低初始规范”的论述为责任划分提供了清楚形式。标准过程应当共享最小、稳定、可扩展的词汇；后来的处置决定应留给掌握后来事实的主体——服务器、网络操作员和服务所有者。注册表把词汇治理集中到合适位置，却不应夺走运行现场的因果判断。

现实层的区分同样关键。operation-failed 是符号，缺失的节点、撤销的权限、耗尽的队列或不可能的参数是不同现实。协议可能有意用同一符号覆盖这些现实。把符号直接提升为现实，只会制造虚假的确定性。

“运行代码优先”则要求修复动作取得自己的收据。自动重试并不因为 API 接受了第二次调用就成为恢复；配置写入成功也不等于服务恢复。必须回读状态，再观察真实服务结果。否则组织只证明自己发出了动作，没有证明世界发生了所需变化。

来源