摘要

  • RFC 9984 为 UDP 客户端和服务器定义了可复用的 YANG 分组，并明确没有协议可访问的 config false 节点；它描述配置，不是运行状态清单。
  • 主机名仍需解析，本地端口 0 仍需操作系统作出选择，通配地址仍需进程真实绑定与监听的证据。分组本身不产生这些事实。
  • Kent Watsen 与 Alex Huang-Feng、Pierre Francois 共同署名。共同层保持轻薄并非缺陷；实现方应在其上分别保存实例化、意图、套接字、流量与应用结果回执。

配置页面里那个永远不变的零

某台设备第一次启动时，UDP 客户端实际使用本地端口 51842。服务重启后，端口变成 47619。管理页面两次都显示 0，并把“没有变化”标成绿色。

页面没有读错配置。它读错了配置的含义。

RFC 9984 规定，当客户端启用 local-binding 功能时，local-port 默认值为 0，意思是操作系统可以选择任意可用端口。零是一项委托：由本地执行环境决定。它既不是线上数据包中的源端口，也不是之后还能自动还原的历史事实。

若审计只保存零，套接字关闭后，真实端口就永久丢失；若审计只保存 47619，又会忘记操作者当时选择的是“由系统分配”。诚实的证据必须同时保留意图与结果。

grouping 甚至还不是数据树中的节点

RFC 9984 于2026年6月作为 Standards Track 文档发布，给出 ietf-udp-client 与 ietf-udp-server 两个 YANG 1.1 模块，供其他数据模型复用。

RFC 7950 对这一步作了严格限定：grouping 是一组可复用的模式节点，但 grouping 声明不是数据定义声明，本身不会在模式树中创建任何节点。其他模块通过 uses 将其具体化，还可以进行 refine 与 augment。

因此，“设备带有 RFC 9984 模块”与“某项服务按特定约束使用了这个分组”是两张不同回执。前者需要模块修订号、命名空间、文件哈希与 IANA 引用；后者需要消费模块、uses 所在位置、启用的 feature、细化规则、扩展内容与完整模式指纹。

IANA 的 YANG Module Names 注册表列出了日期为2026年6月15日的两个模块文件及其前缀和命名空间。注册解决的是共同语言的身份。它不证明设备已经装载模块，不证明服务实例化了分组，更不证明内核拥有一个活着的 socket。

一个远端字段里藏着解析器的决定

客户端分组要求 remote-address，但它可以是 IPv4、IPv6，也可以是主机名。主机名并不直接构成远端 tuple；解析器还要在某个时间、某个视图、某个缓存与某套策略下选出地址。

RFC 9984 说明，当本地地址也已配置时，解析结果的地址族通常应与其兼容。它没有定义保存选中地址、解析时刻、解析器或有效期的 leaf。这种留白使一次解析、多地址选择、周期刷新或应用库代理等不同策略都能复用同一分组。

危险不在留白，而在展示层把主机名说成“当前连接对象”。主机名是输入；解析结果是运行事实。若 DNS 在进程存续期间变化，只看当前答案也无法证明早先 socket 使用了哪个地址。

remote-port 同样没有默认值，也不是必填项。RFC 建议，消费模块在有知名端口时加入默认值，在应用始终需要端口时将其设为必填。基础分组因此可能并不包含完整远端 tuple；真正的合同在消费模块完成。

通配绑定是一条策略，不是一张接口清单

服务器分组要求至少一个 local-bind，可以同时描述 IPv4 与 IPv6，也允许通配地址。本地端口仍由消费模块决定是否默认或强制填写。

通配地址表示进程请求按系统可用地址进行绑定。它没有列出所有实际接口。网络命名空间、容器边界、地址增删、双栈行为和操作系统实现都会改变外部暴露面。

而且，符合模式只证明输入形状和约束正确。端口可能已被另一个进程占用，地址可能尚未出现，权限可能不足，进程可能成功 bind() 后立即退出。配置保持不变，运行状态却已经跨过多个阶段。

RFC 9984 对边界并不含糊：文档没有定义协议可访问的 config false 节点。两个模块单独存在时，不暴露可写数据、只读状态或 RPC。复用它们的模块应说明自己的安全风险；地址与端口本身可能涉及隐私。

所以，补充运行证据不能变成无限采集。有效 tuple、进程实例、时间与错误原因可以受到访问控制、缩短留存并避免保存载荷。隐私要求缩小证据面，而不是允许控制平面虚构“服务健康”。

NMDA 把“想要”与“正在使用”分别命名

Kent Watsen 也是 RFC 8342 的五位作者之一。这份 NMDA 文档专门处理配置值与设备实际使用值可能不同的问题。

<intended> 保存转换后的意图配置，即系统尝试应用的内容。applied configuration 是当前确实在使用的配置。system state 是瞬时运行信息与统计。<operational> 则由已应用配置和系统状态共同组成。

RFC 8342 还给出一种核对方式：比较 <intended> 与 <operational> 中 config true 的部分，判断意图有多少已经生效。硬件、软件、协议交互、资源缺失、转换规则与传播时间都可能造成差异。配置删除后，连接、内存或文件句柄释放期间还可能留下 remnant configuration。

RFC 9984 没有替 UDP socket 填写这张运行表。消费模型可以扩展，设备也可以用其他遥测方式提供。共同规范没有规定唯一实现，绝不等于运行证据可以省略。

共同署名中的克制

为本文在2026年9月2日保存的 IETF Datatracker 公开资料，把 Kent Watsen 描述为网络管理与网络安全专家，并列出其当时的 chair、reviewer 角色和21份 RFC，其中包括 RFC 8040、RFC 8342 与 RFC 9984。这些角色和数量都带有抓取时间，不能当作永久身份。

RFC 9984 由 Alex Huang-Feng、Pierre Francois 与 Kent Watsen 共同署名；模块内部的联系段落列出 Huang-Feng 与 Francois，致谢部分还记录更多审阅者。任何来源都不支持把全部模型、实现或部署归于 Watsen 一人。

他在这篇人物文章中的意义更加具体：网络管理接口越精确，就越需要说明一层数据的权力到哪里为止。分组提供一致字段，NMDA 提供状态语法，运行系统提供现场事实。一个模型不替未来所有应用猜测 socket，反而使责任边界更可靠。

Heng Lu 的 Running-Code Primacy 要求文档最终接受运行结果检验；Minimum Initial Specification 则要求共同层只保留互操作真正需要的最小规则。RFC 9984 的轻薄正适合这种分工。解析策略、端口选择、进程监管、流量判断和应用成功可以留在本地，但每一方必须为自己的决定留下回执。

从共同模型走到应用结果的六张回执

第一张是制品回执：模块修订、命名空间、IANA 引用和哈希。第二张是实例化回执：消费模块、uses、feature、refine、augment 与模式版本。

第三张是意图回执：配置变更、操作者、转换结果、时间和 <intended> 快照。第四张是运行回执：服务实例、解析结果、有效本地与远端 tuple、地址族、绑定结果、创建时间和关闭原因。

第五张是流量回执：测量窗口、双向数据报与字节计数、首次与最后一次观测、丢弃和 socket 错误。第六张属于应用：对端身份、握手、有效响应、事务接受或健康检查。

这样，系统可以表达“配置有效但未应用”“已绑定但没有流量”“有数据报但认证失败”“只在部分地址可用”。这些中间状态不会削弱 RFC 9984；它们证明这份 RFC 对自身可知范围的限定是正确的。

来源