摘要

  • draft-ietf-netconf-yp-transport-capabilities-07 让编排器能够从实施期资料或运行中的服务器发现 YANG 通知所支持的传输、编码和安全协议。
  • 这是一份能力菜单，不是执行证明。它不负责选定精确组合，也不证明本地政策已批准、接收端已配置、RFC 8639 订阅已获接受或通知已经送达。
  • 实施时信息与运行时读取的来源、对象和有效时钟不同。把两者压成同一个“支持”布尔值，会抹去 RFC 9196 刻意保留的差别。
  • 可由运营方建立一份能力到订阅决策回执，把观察来源、所选组合、政策版本、接收者、请求、结果和降级串在一起。这是编辑建议，不是 IETF 要求。

菜单越整齐，越容易被误当成订单

设想一台新路由器准备向遥测平台发送状态更新。控制器先读到一个 HTTPS 传输条目，条目下列出 XML 与 JSON，再列出 TLS 1.2 与 TLS 1.3。另一个 UDP-notif 条目可能列出 JSON、CBOR、DTLS 1.2 和 DTLS 1.3。它由此可以排除设备没有声明的方案，减少无意义的试错。

这正是能力发现的价值。但界面若把整棵树折叠成“支持通知”，就会混淆至少五个状态：发现过、选择了、政策允许、发布端接受、接收端正在得到数据。

第 07 版《YANG Notification Transport Capabilities》发布于 2026 年 8 月 17 日。Datatracker 的最后更新时间是 9 月 8 日，这也是 8 月 25 日发布的 IETF Last Call 公告所列意见截止日。截至 9 月 9 日的研究截点，它仍是拟走 Proposed Standard 的活跃 Internet-Draft，已经提交 IESG，状态为等待负责的 Area Director 推进。截止日过去不等于形成最终批准，更不等于 RFC 已经发布。

草案把“可以发现什么”说得更清楚；治理必须继续回答“谁据此做了什么”。

同一个“支持”背后有两只时钟

这项工作扩展 RFC 9196 的系统能力框架。RFC 9196 允许实施者在设备运行以前，以 YANG instance data 文件提供能力信息；也允许客户端通过 NETCONF 或 RESTCONF 从运行中的服务器读取。

前一种信息服务于 NMS 设计、系统集成与采购判断。它可以在具体节点上线前说明某个实现或产品类型的能力。后一种信息服务于模型驱动应用，并可反映许可证、硬件限制或运行期变化。RFC 9196 还明确提出，运行时数据可用于核实早先披露的能力是否真由发布端实现。

因此，两份都诚实的记录也可能不同。产品文件没有义务知道某台设备装了哪张板卡；十点整的运行时读取也无法自动证明十点零五分仍未变化。对于可在运行期间变化的能力，RFC 9196 建议系统支持 capability 容器的 on-change 通知，但消费者仍要接收变化，并把它关联到已经作出的动作。

自动化审计至少应留下：数据来自实施时文件还是实时读取，来源地址与获取方法，模块修订、设备和软件版本，观察时间，以及多长时间以后必须重读。没有这些坐标，“支持”未必是错的，却不足以成为机器决策的依据。

清单只圈定选择空间

草案新增 transport-capabilities 容器；其中 transport-capability 按传输协议作为键，每个条目再有 security-protocol 与 encoding-format 两个叶列表。模型在这里停得很克制：它描述支持值，没有伪装成一次订阅交易记录。

也不应反向发明缺陷。两个分列的叶列表并不能单独证明服务器错误声称了所有笛卡尔积组合。可靠结论应更窄：若控制器想使用某个具体的“传输＋编码＋安全协议”组合，仅凭三个值分别出现在清单里，还不足以证明这个组合在当前实例上可用。应当把所选组合、尝试过程和结果一起保存。

RFC 8639 给出了下一道明确边界。动态订阅不是请求一发出便存在；发布端接受 establish-subscription 后，它才进入外部可见状态。发布端可以因多种原因拒绝，并可返回结构化提示，告诉请求者哪些参数在下次更可能成功。

所以能力发现可以减少盲目协商，却不能替代协商结果。即使请求获准，也只证明发布端创建了订阅状态。接收端可能不可达，流也可能随后暂停或终止。首条通知抵达与持续交付，必须拥有各自的证据。

管理入口已配置，不代表通知出口已打通

草案明确假定编排器与设备之间已有管理网络，设备的管理连接和管理端点已随管理网络配置完成。这项前提让能力树可读，却没有替遥测接收端完成配置。

同样，能够在 NETCONF 或 RESTCONF 上认证某个主体，不代表该主体可以把通知导向任何地址。认证说明谁站在管理入口；NACM 与本地政策限制它能做什么；安全团队还可能规定允许的协议；遥测团队掌握接收端；网络团队掌握路径。

在跨团队环境里，一次绿色读取没有天然的唯一所有者。如果交接不留痕，网络团队可能认为安全已经批准，安全团队可能认为编排器只会选首选协议，平台团队则以为设备会验证目标。所有人的局部假设都合理，合起来却没有任何人真正承担选择。

草案说明新模型节点均为只读，相关数据不敏感，并要求通过安全、双向认证的 NETCONF 或 RESTCONF 访问，结合 NACM 控制权限。没有必要把能力菜单夸大为秘密。真正的治理问题是：非秘密事实也可能被自动化当作未经批准的指令。读到 TLS 1.2 可用，与批准它服务于某个受监管接收者，是两件事。

流程信号不能越界成为运营结论

Datatracker 在 9 月 8 日记录的 YANG 验证结果是零错误、零警告；当前安全审查为 Ready，传输审查为 Almost ready；IANA 显示仍需动作，专家审查则已通过。这些都是具体而有用的标准流程证据，但没有一项测量生产交付。

第 07 版的实施状态章节称，Huawei 在 VRP 的 YANG-Push 发布端实现了本文档，Cisco 也在 IOS XR 实现。该章节同时注明应由 RFC Editor 在发布前删除。这些声明表明存在运行代码，却不是第 07 版的公开互操作矩阵，也不证明部署占比、所有组合的可用性或通知成功率。

dtls12 身份的文字还提醒我们不能按字符串治理。它把 DTLS 1.2 称为过时，并不建议启用。这个结论不能被扩大成“TLS 1.2 被禁止”；示例恰好还在 HTTPS 条目下列出了 TLS 1.2。政策必须识别实际协议身份与适用规范，而不是看见“1.2”便统一处置。

把观察、许可与结果缝成一张回执

一份能力到订阅决策回执不必修改 YANG，也不必成为线上协议消息。它可以在自动化从观察跨入行动时，由运营系统生成。

第一部分标识设备、产品系列、模块修订与软件构建；注明数据来自实施时文件还是一次实时 NETCONF/RESTCONF 读取，记录来源、获取时间和失效规则。第二部分保留原始传输条目，以及真正选中的传输、编码、安全协议组合。

第三部分写明执行主体、接收者身份与端点、本地政策版本、订阅参数和尝试时间。结果不只分成功失败，而应区分接受、拒绝、超时、后来终止，以及接受后未见首次交付。结构化错误提示、重试、备选方案和批准降级的责任主体也要附着其上。

这样的回执不改变任何协议语义。它只是阻止几句分别为真的话被拼成一句假结论：“产品说支持”“设备刚才列出了”“政策允许”“发布端接受”“接收端得到数据”，每一句都应在自己的时钟上接受验证。

The Policy Mirror 要求找到真正控制结果的字段：这里，能力树记录可能性，政策记录许可，订阅状态机记录存在，接收端才记录用途是否实现。Running-Code Primacy 要求这些执行痕迹相遇。Reality, Not Advocacy 则限定结论：草案没有承诺自动成功，它提供了一张更好的菜单。运营方必须为自己点下的那一项负责。

来源