摘要

  • draft-ietf-opsawg-veloce-yang-00 建议让 RFC 正文引用仓库中一个精确的 YANG 标签或提交。它能可靠标识内容，但合并、关闭议题或 CI 通过并不会自动变成工作组共识。
  • 发布之后仍有一条更长的证据链：治理记录是否保存、发布物如何形成、设备声明的模块集与功能/偏差是否一致、代表性操作是否成功，以及网络结果是否真的出现。

想象一次看起来已经结束的修改：拉取请求有两位审阅者，所有检查变成绿色，编辑合并代码，随后创建发布标签。

屏幕上每一个状态都很明确。也正因为如此，人们很容易把“看得见”误认为“权威已经完成”。

事实上，这几项记录只回答了仓库层的问题：哪一组修改被合并，哪些自动检查在什么时刻通过，哪个对象获得了一个名字。它们没有自动回答工作组是否形成粗略共识、IESG 与 RFC 流程是否接受、厂商是否把同一份模块放入产品、设备启用了哪些 feature 与 deviation，更没有证明一次配置操作改善了服务。

这正是 VELOCE 草案最有价值的地方。它并不只是提议“把 YANG 放到 GitHub”。它试图为一种代码形态的规范重新安排证据边界。

draft-ietf-opsawg-veloce-yang-00 是 OPSAWG 的活动工作组草案，日期为 2026 年 8 月 25 日。草案页眉写着预期状态为 Experimental，而 Datatracker 摘要栏没有填写预期 RFC 状态。冻结记录中只有 00 版。它不是 RFC，不是完成的实验，也不是部署报告。草案提出的新模块两年、增量 -bis 模块一年等目标，仍是需要实验检验的假设。

传统做法把 YANG 模块嵌入说明文档。VELOCE 建议分开：说明文字继续承载模型解释、IANA、安全、运维和引用；YANG 模块则放进源代码管理仓库。这样，审阅者能看小范围差异，工具能直接解析与验证，修正模块时也不必为一小段代码重新打开整篇大文档。

这是一项合理的工程改进。YANG 同时是规范文本和可执行工具链处理的源码。它需要解析器、lint、依赖解析、feature 选择、SID 文件和可重复构建环境。把它只当作排版在 RFC 里的几页字符，会浪费源码仓库能提供的精确性。

草案中最关键的规则是：模块不应再嵌入文档；文档必须指向某个精确标签或提交哈希，而不能指向分支 HEAD。这样，RFC 发布时所对应的模块可以被永久检索和验证。

标签因而是一张很强的“内容回执”。main 会移动，提交对象不会因为新提交而改变。审阅者、实现者与审计者可以围绕同一份字节讨论。

但标签只能固定对象，不能固定合法性。

RFC 8874 对此没有留下模糊空间：GitHub 上完成的工作没有特殊地位，工作组仍可接受、拒绝或修改它；仓库中的文档副本也不必在每个时刻都完美反映工作组共识。编辑需要管理文档的余地，因此“仓库现在是什么”与“工作组决定了什么”本来就不是同一个事实。

仓库界面却会制造一种视觉上的结论。议题可以 Closed，PR 可以 Merged，检查可以 Passed，标签甚至可以叫 has-consensus。这些状态都能记录过程，却不能凭自己的名字获得权威。

RFC 8874 要求工作组共识决定在邮件列表上确认，并把最终的共识判断交给主席。RFC 2418 也说明，粗略共识不是投票百分比；主席要综合不同场合的意见，面对面会议形成的决定还要回到邮件列表接受检验。

因此，一次完全合规的合并也可能还不是共识回执。编辑可以按授权处理普通变更，主席可以要求某项重要修改在评估共识前不要合并。对可能影响实现或互操作性的 design 议题，最终仍需工作组共识。

真正需要保存的是一条连接链：哪个问题被提出，接受了哪一个解决方案，主席对哪个范围作出共识判断，哪一个精确提交实现了该决定。少任何一环，日后都可能出现“决定存在、代码也存在，却无法证明两者是同一件事”的局面。

CI 也有类似边界。RFC 8874 允许用持续集成构建文档、验证形式语言、检查示例。VELOCE 还建议设置 YANG 验证，并提供容器化环境让贡献者在本地复现。

绿色结果当然有价值，但它的分母必须保留。它只证明某个提交在某一验证器版本、依赖图、feature 组合、规则集、容器和测试样本下通过。它不证明没有被编写的测试也会通过，不证明所有安全要求都被实现，不证明两个厂商会给出相同行为。

“已验证”若没有输入、工具与例外范围，就会从技术事实变成一句没有边界的口号。

发布又增加一层。精确引用可以让 YANG Doctor 审阅的对象与 RFC 指向的对象相同。这比一个会移动的仓库链接强得多。然而 RFC 发布并不会把模块自动放进设备。中间仍有仓库托管、构建、签名、依赖选择、厂商集成、系统镜像、升级与本地启用。

RFC 8874 本身也提醒了托管风险。Git 的分布式副本有助于保存代码对象，但 issue、PR 讨论、审阅与 wiki 更容易丢失；外部服务故障和高权限凭据被攻破也必须考虑。RFC 8875 则补充组织管理与备份。只保存 Git 提交而丢失“为何接受这次修改”的讨论，并不能构成完整的标准记录。

运行时的第一张可靠回执来自设备，而不是仓库。RFC 8525 的 YANG Library 允许服务器报告各 datastore 对应的 module-set，包括 revision、feature 与 deviation。它能让运营者检查目标设备声称实现的模式环境是否与发布对象一致。

但这仍然不是最终结果。YANG Library 是服务器对模式集的声明，不是每个约束、RPC 或状态转移都正确的证明。还要执行代表性的 NETCONF 或 RESTCONF 操作，重新读取状态，并观察网络或服务是否出现了预期变化。

Heng Lu 的 running-code 视角在这里不是要求标准制定者等到全世界部署后再写文字，而是要求不要把符号层的证据提升成运行层的事实。标签属于仓库层，共识属于决策层，RFC 属于规范层，加载后的模式与行为属于设备层。

“最小初始规范、未来本地决策、自愿采用”的原则提供了建设性方向。共同流程只需固定互操作真正需要的连接：精确对象、可复现验证、可追溯共识和不可变发布引用。具体仓库工具与厂商发布系统可以保留本地选择。随后由独立实现与互操作的运行代码验证提案是否值得继续扩展。

多利益相关方的提醒同样具体：热闹的仓库并不自动代表完整的参与面。长期关注 issue 的人是一个自我选择群体，主要阅读邮件列表的人可能从未进入那条讨论。RFC 8874 已经承认这种选择偏差。成熟流程不会把界面活动量当作授权，而会把仓库重新接回更广的工作组。

VELOCE 真正要实验的是速度与权威能否同时得到改善：代码以代码的方式维护，共识仍由公开流程形成，发布指向精确对象，设备再用自己的运行证据证明采用。

下次有人说“模块已经完成”，应先问他指的是哪一张回执。提交完成，表示字节可能完成；主席的有界共识记录完成，表示工作组决定可能完成；RFC 完成，表示发布可能完成；YANG Library、代表性操作与服务观察一致，才表示某个部署可能完成。

一个绿色图标承担不了四种含义。一个标签也不能。

来源