摘要

  • OPSAWG 在 2026 年 8 月 25 日采纳 VELOCE，并把第 00 版列为工作组文档；这不是 RFC、BCP 或最终 IETF 规则。
  • 当日项目会议摘要说 IANA 指向代码库的模式已获确认；第 00 版仍明确没有 IANA 行动。提出哈希、状态、责任联系人和审批路径的 PR49 在研究截止时仍处于开放、未合并状态。
  • 项目会议形成的方向不等于通过邮件列表确认的工作组共识；代码库合并也不等于工作组、Area Director 或 IESG 的批准。IANA 记录已获准的版本，不应凭记录行为取得批准权。
  • 草案已经避开了一个风险：RFC 不应指向会移动的分支头，而应指向特定标签版本。尚待补齐的是：新版本怎样取得批准、IANA 何时抓取并核验它、实现者究竟针对哪一版宣称符合。

同一天发生的事，权限并不相同

先看采纳这一层。6 月采纳结果显示，OPSAWG 主席认定支持足够，要求把个人草案以 draft-ietf-opsawg-veloce-yang-00 名义重新提交，且不作其他改变。Datatracker 记录显示，第 00 版于 8 月 25 日成为工作组文档。它说明该组开始对文稿负责；它不预先授权之后每一项注册、抓取或维护设计。

该草案提出把 YANG 模块放在 RFC 之外。RFC 引向代码库内某个具体、已标记的版本。主分支在 RFC 发布后可以继续变化，特定提交或标签则能让后来者取回并核验当时指向的字节。草案还设想：已采纳的模块可在 IETF 代码库更新，而 RFC 只更新对模块版本的引用。这样的安排确实回应了维护成本：一个狭窄、经过审查的模块修正未必总要重开整份 RFC。可一旦模块离开 RFC 容器，过去由单个出版物默认捆在一起的事实也必须分别保存：谁同意、同意的是哪些字节、指针从何而来、何种版本能支撑符合性声明。

在 IETF 126 之前，作者已把这些问题公开提出。邮件列表讨论询问 RFC 应指向 Git 标签、IANA 条目还是其他目标；“最新”指针应解析为哪一版；实现者该选哪一版；发布后更新怎样仍可测试符合性。IETF 126 OPSAWG 会议记录保留了 GitHub、IETF 控制环境、IANA 发布、可恢复性和归档之间的不同观点。预定时间用完，讨论转回邮件列表。这是未解决设计问题的证据，不是对任何参与者的指控。

8 月 25 日摘要又增加另一层信息：实验将保留 GitHub 代码库，贡献者可提交 issue 或 pull request，双周会议形成的意见会汇总至邮件列表，合并前有异议则继续讨论；其中还称 IANA 间接模式已经确认。这份材料有价值，但它的性质不能被抹平。它是项目会议的归属明确摘要，不是公开的工作组共识征集结论，也不是 IESG 决定。RFC 8874指出，在 GitHub 完成的工作没有特殊地位，工作组的共识决定须在邮件列表上确认。会议可以推进设计，却不能默默替代这一确认。

再看第 00 版本身：IANA 注意事项明确写着没有行动。RFC 8126把明确的“无行动”部分视为作者对该文稿中 IANA 无须处理事项的有意识判断。它不阻止后续修订加上合规的 IANA 请求，却要求我们不要把会议里的方向叙述成已经可执行的注册指令。

PR49 画出的是桥的设计图，不是已经跨过的桥

PR49在截止时尚未合并。它建议设立 YANG 文件／模块引用注册表，列出永久与提议状态、精确 URL、SHA-256、责任联系人，以及 IESG 或其他指定路径的批准规则。这些字段本身值得重视：哈希锁定字节，状态区分候选与当前条目，联系人标明管理责任，审批字段则把决定者写出来。

不过，提议字段不是已经生效的公开注册政策。现有 IANA YANG Module Names 注册表适用 RFC Required，显示名称、文件、命名空间、前缀、参考和注释等栏目；它当前没有 VELOCE 拟议的哈希、批准状态、控制联系人或决定收据栏目。因此，冻结证据并不支持“ IANA 已建立此注册表”“已认可该机制”或“已抓取某个 VELOCE 版本”之类说法。

这里最容易被压扁的，是不同动词的主语。作者提出变更；审阅者和代码库维护者在代码库内处理它；工作组形成技术与程序共识；被指定的 Area Director 或 IESG 可能承担批准职责；IANA 执行边界清楚的登记；登记项保留一个版本的身份。标签、合并、共识、批准和注册各自可以有证据，却不会自动证明彼此已经发生。

区分它们是在保护制度边界。若 IANA 条目被当作“内容已成熟”的证明，登记者就被推成批准者；若维护者合并被当作共识，代码库权限就取代了工作组审议；若标签被当作部署证据，可重复字节就被误当作运营采纳。与此同时，也不应把尚未完成的设计说成失序：第 00 版已经禁止浮动分支，明确保留粗略共识；PR49 尝试以哈希和审批路径限制 IANA 的角色；早期工作组草案滞后于正在讨论的细节，本来就可能是正常状态。

一张“决定到指针”收据即可补齐关键空白

不必为每一个小改动再造一个完整 RFC，也不必新设否决门槛。每次后续模块改变可以有一张公开、可链接的收据，至少连接：

  1. 变更对规范行为的主张及负责的工作组；
  2. 邮件列表共识征集的链接、起止时间、重要异议与主席处置；
  3. 请求注册的精确草案或批准文本，以及批准者；
  4. 代码库 URL、不可变提交、标签和 SHA-256；
  5. 作者、审阅者、合并者与拥有批准权者的独立身份和时间；
  6. IANA 请求人、请求时间、抓取 URL、抓取字节及核验结果；
  7. 前后注册条目的身份、有效时间和替代关系；
  8. 发布时版本、最新获准版本与测试符合性所用版本；
  9. 兼容性与测试材料、镜像与备份位置、同步记录、恢复演练、撤回和回退办法；以及
  10. 与登记分开的实现和运营采纳证据。

这不是把一次有建设性的会议重新命名为共识；它要求把后来的正式确认链接回来。也不是让 IANA 对技术实质作判断。授权机构决定候选版本能否成为当前版本；IANA 按既定政策核验并记录该已获准制品。Heng Lu 的第 63 则笔记在这里提供的是制度透镜，而非 VELOCE 或 IANA 的事实证据：保管和留痕能让一项决定可审计，却不应夺走作出决定的权力。

符合性的边界也必须写清。RFC 9907仍是已发布基线：规范性的 YANG 陈述和 RFC 规范文字同等对待，新建或更新模块须在 IETF XML 与 YANG Module Names 注册表中登记。VELOCE 可以尝试更轻的维护安排，但截至截止时并未取代这一 BCP。RFC 指向版、最新获准版、IANA 当前条目和实现测试版有时可能相同；不能因为方便就假定它们永远相同。

来源

  1. OPSAWG 章程
  2. VELOCE Datatracker 记录
  3. IETF 126 OPSAWG 会议记录
  4. PR49
  5. Heng Lu 第 63 则笔记
  6. IANA YANG 参数
  7. OPSAWG VELOCE 采纳结果
  8. VELOCE 指针讨论
  9. 8 月 25 日 VELOCE 会议摘要
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907