摘要

  • Datatracker 把 charter-ietf-radext-07-08 标为拟议重拟章程,状态是 External Review,最后更新于 2026 年 8 月 6 日;页面同时注明当前获批章程仍为 07 版。
  • 拟议文本列出两项 5 月里程碑、五项 8 月里程碑和一项 12 月里程碑,八个 Associated documents 单元格全部为空。
  • 最可能对应两项 5 月目标的草案都是活跃的 RADEXT 工作组文档,但 IESG 状态仍为 I-D Exists。安全审查草案自称 Informational,拟议里程碑却写 Proposed Standard。
  • 五项 8 月目标最可能对应三份已过期的个人草案、一份已过期的工作组采纳候选稿和一份活跃候选稿。活跃的 Connect-Info 同样存在 Informational 与 Proposed Standard 的轨道差异。
  • “过期”不等于放弃,“候选采纳”不等于已采纳,I-D Exists 也不等于已提交 IESG。因此,七个已经到月的日期不能被报道成七项失败。
  • IETF 应给每项里程碑配置版本化基线,把章程状态、文档身份、发布轨道、采纳与 IESG 状态、所测转变、实际日期及重排原因连在一起。

同一份提案里的两条时间线

RADEXT 负责维护和扩展 RADIUS。RADIUS 在网络接入系统中承载认证、授权和计费信息,其改变往往同时涉及协议、安全和运营经验。Datatracker 当前展示的重拟章程编号是 07-08,但页面明确区分“拟议重拟章程”和“当前获批章程”;后者仍为 07 版。这意味着新工作范围已经形成文本,却还没有取得最终制度状态。

页面的完整状态是 External Review (Message to Community, Selected by Secretariat)。Datatracker 的状态说明把 External Review、IESG Review 和 Approved 分成不同阶段。评审意见被化解、ballot 立场变化或新版本上传,都是推进证据,却不能替代 Approved 这一正式状态。

历史页显示,程序并非停滞。八项里程碑在 5 月 12 日加入。7 月 22 日,提案从内部审查进入 External Review,并建立 Approve ballot。7 月底到 8 月初,评审者曾就拥塞控制的跨组协调、项目归属和出版状态提出 Block。文本连续迭代到 07-08;截至 8 月 6 日,记录中的 Block 都已经变为 No Objection。

因此,不能说仍有未解决的 Block。也不能反过来把“Block 已清除”写成“章程已批准”。在本次证据截止时,最新页面仍停留在 External Review,公共记录没有解释下一次状态迁移为何尚未出现。

第二条时间线藏在里程碑表里:两项 5 月向 IESG 提交的 Proposed Standard,五项 8 月提交——其中四项 Proposed Standard、一项 Informational——以及一项 12 月的 Proposed Standard。表格给出了月份和任务名称,却没有给出任何 Associated documents 链接。读者看到的是预测,无法直接打开预测所指向的对象。

5 月两项工作仍活跃,但没有到达表中所写的迁移

第一项是把 RADIUS 安全与隐私审查稿作为 Proposed Standard 提交 IESG。标题最吻合的是 draft-ietf-radext-review-radius-02。它是活跃的 RADEXT 工作组文档,8 月 10 日刚更新;IESG 状态仍是 I-D Exists,文档页标的预期状态却是 Informational。

这里有两件事必须同时保留。新版本说明工作在继续,不能用“5 月”两个字宣布它已经死亡。另一方面,I-D Exists 没有记录“to IESG”这一步,而 Proposed Standard 与 Informational 的差异也没有得到公开解释。

第二项是将废弃不安全 RADIUS 实践的草案提交 IESG。draft-ietf-radext-deprecating-radius-10 是活跃工作组稿,7 月 3 日更新,已有 document shepherd,文档头写 Standards Track。它同样停留在 I-D Exists。其页面仍保留获批章程下的 2024 年 1 月旧里程碑,拟议新章程则把目标写为 2026 年 5 月。两个基线并列,却没有一张表说明承接关系。

IETF 126 的 7 月 22 日会议纪要补上了一部分过程。主席当时说,两份草案尚未通过 Working Group Last Call,应尽快进入这一阶段。由此可以得出的是:文档确实在推进,但距离里程碑命名的“提交 IESG”仍有一个可辨认的程序步骤。不能把背景解释当成完成凭证,也不能把未完成迁移说成没有工作。

8 月五行混合了四种制度状态

拥塞控制一行最可能指向 draft-janfred-radext-radius-congestion-control-01。这是一份没有 stream 的个人草案,最后更新于 2025 年 10 月,2026 年 4 月过期。章程历史证明评审期间讨论过拥塞控制协调,但由于表格没链接,文档身份只能算编辑判断,不能冒充 IETF 的正式关联。

代理负载均衡最可能对应 draft-dekok-radext-proxy-load-00。它也是已过期、没有 stream 的个人草案。摘要明确说,在该版本写作时,运营经验尚不足以支持 Standards Track 或 BCP。拟议里程碑却写着 8 月提交 Proposed Standard。这或许意味着未来会重写、换用其他文档,或工作组后来改变出版判断;当前公共行没有提供答案。

位置不确定性一行与 draft-grayson-5580uncertainty-00 的标题完全吻合。该个人草案也已过期。里程碑给它 Informational 轨道,看上去不冲突,但仍缺正式文档关联和提交状态。

应急通信属性一行可能指 draft-gundavelli-radepcs-02。它出现在 RADEXT 资料中,状态为 Candidate for WG Adoption,并于 7 月过期。候选状态表示采纳决定尚未完成;过期表示当前版本超时,不证明工作被放弃。两者都不是 IESG 收稿凭证。

Connect-Info 是五份可能对应文档中唯一仍活跃的一份。draft-grayson-connectinfo-10 是 Candidate for WG Adoption,IESG 状态为 I-D Exists,文档头写 Informational,拟议里程碑则写 Proposed Standard。IETF 126 纪要称,采纳前征询已经形成共识,重拟章程完成后会进行采纳。

这正好说明为什么日期必须和依赖条件一起呈现。Connect-Info 有活跃文本,也有共识信号;正式采纳却依赖仍在审查的新章程。只写一个 8 月,会把“有人支持”“工作组有权采纳”“已经采纳”和“已提交 IESG”压成一个无法核验的状态。

12 月是一项预警,不是逾期结论

最后一行计划在 12 月提交 Status-Realm 与防环路工作。最可能的对应稿 draft-ietf-radext-status-realm-01 是 RADEXT 工作组文档,最新版本发布于 2025 年 3 月,目前已过期。

证据截止时还没到 12 月,所以不能称其错过里程碑。过期仍然是有用的监测信号:如果这组工作要完成表中迁移,就需要新版本、替代文档、范围调整或日期重排。监测信号和失败判决是两件事。

让里程碑表变成状态账本

RFC 2418 解释了里程碑为什么重要。章程用目标和时间框架帮助 Area Director 跟踪进度,也让潜在参与者识别关键输入时点;里程碑应定期更新。日期会分配注意力,因此必须能指向一个对象和一次转变。

每行至少需要稳定的里程碑标识、章程版本与状态、确切文档族、个人稿/候选稿/工作组稿/IESG 文档状态,以及章程所写与文档所写的出版轨道。它还要说清日期测量什么:采纳、Working Group Last Call 和提交 IESG 不是同义词。

随后可记录实际发生日,或使用少量明确状态:计划中、活跃、达成、重排、被替代、受阻。重排不能覆盖旧日期,应保留原目标,并记录原因、决定者与依赖。如果 5 月 12 日加入的 5 月目标本来就是追溯性目标,就明说;如果 8 月取决于章程获批,也应写出;如果出版轨道从 Proposed Standard 变为 Informational,应留下决定凭证。

Heng Lu 所说的账本原则在这里有一个窄而实用的用法:制度记录应能描述它正在协调的状态。这不是把 IETF 章程说成主权工具,也不是质疑 RADEXT 程序合法性,而是要求公共时间表不要靠页面之间的沉默产生权威。章程提供方向,状态账本负责保存实际路径。

来源

  1. Heng Lu,《The Policy Mirror》
  2. RADEXT 拟议重拟章程
  3. RADEXT 章程历史
  4. Datatracker 章程状态说明
  5. RADEXT 工作组页面
  6. RADEXT 工作组文档
  7. IETF 126 RADEXT 会议纪要
  8. RFC 2418
  9. RADIUS 安全与隐私审查稿
  10. 废弃不安全 RADIUS 实践草案
  11. RADIUS 拥塞控制草案
  12. RADIUS 代理负载草案
  13. 位置不确定性草案
  14. 应急准备属性草案
  15. Connect-Info 草案
  16. Status-Realm 草案