摘要

  • PROCON 在 IETF 126 同意提议一句新章程文字：“最终文件应当准确记录现行政策。”截至研究截止时间，Datatracker 仍只把 2025 年批准的第 01 版列为现行章程，新句尚不是生效授权。
  • 现行章程并非只允许文字清理。它明确准许围绕工作组里程碑和草案采纳作有限的非编辑性修改，并另行授权处理 IETF 主席授权与临时继任；新增事项则要重新立项修章。
  • 2418bis 与 2026bis 同时出现多种性质不同的改动：删去百分比共识口诀、界定辅助角色、覆盖聊天等公开论坛、明确采纳可撤销、替换外部标准示例，也处理非公开申诉讨论的边界。
  • “当前有人这样做”不自动等于“现行政策已经如此”；同样，新文本没有逐字出现在旧 RFC，也不自动证明它越权。判断取决于基线、实践证据和章程授权链。
  • 应当为有治理后果的差异建立轻量分类账，把修订版本、旧文本、实践来源、变化类型、章程条款、异议、工作组决定、后续 IETF 状态和最终文本连起来。
  • 分类账不增加新的否决者，也不要求每个编辑修正都重新修章。它还应把 BCP 发布与工具、主席及工作组后来是否实际采用分开记录。

一句看似清楚的话，容纳了四种不同动作

PROCON 的任务源于一项真实的维护困难。RFC 2026 与 RFC 2418构成 IETF 标准流程和工作组运作的重要旧基线，后来又被其他 RFC、勘误以及现实工具的变化层层包围。读者要理解“现在适用什么”，往往得自己拼接多份材料。

现行 PROCON 章程要求新文件归并更新两份 RFC 的后续 RFC，并吸收已经核实或留待更新的勘误。可是，它没有把工作限制在复制与排版：章程点名允许工作组里程碑和 Internet-Draft 采纳方面的非编辑性修改；另有一项 BCP 可以处理 IETF 主席的授权与临时继任。除此以外的新项目要重新修章。

这意味着“准确”至少可能对应四种动作。第一种是归并，把已经生效但散落各处的规范集中起来。第二种是过时机制修正：责任不变，承载责任的工具或称谓变了。第三种是惯例成文化，把现实中的稳定做法写进规范文本。第四种是有意改策，由现行章程的特定条款或获批的新章程提供权限。

这四类并非价值排序。归并也可能出错；有意改策也可能完全正当。分类的作用，是告诉后来审阅者应当去哪里核对主张。归并要能指向原有权威，机制修正要证明旧描述为何失真，惯例成文化要证明实践并说明为何要把它规范化，政策调整则要标明授权路径。

IETF 126 的主席幻灯片把冲突摆上了台面。幻灯片称，工作计划一直被理解为准确、清晰地记录现行流程，把扩展与政策变化留到以后；但如果严格阅读章程，某些编辑修正以及与已改变运作现实对齐的文字也可能被排除。主席最初提出了一段较长的补充，列到 RFC、IESG 声明与工具变化。

会议纪要记录的最终共识更短：工作组同意提议“最终文件应当准确记录现行政策”。纪要自称由 AI 起草，再由主席和参会者审阅更新，因此可作为经复核的决定记录使用，却不应冒充逐字速记。

截至 2026 年 9 月 2 日的研究截点，公开章程页仍只显示 2025 年 7 月 9 日更新的 charter-ietf-procon-01。所以，新句的准确身份是“工作组同意向 IESG 提议的文字”，不是已经生效的新章程。它也不能倒推裁定此前每一处差异是否合规。

删掉 51% 和 99%，究竟是在修错还是改规则

2418bis 第 04 版删去了 RFC 2418 中一段广为人知的说明：51% 支持未必形成粗略共识，99% 支持也可能掩盖尚未解决的实质异议。2418bis 报告材料把这两个数字称为容易混淆的经验说法；会议记录则表明，工作组决定保留删除结果，但不加入此前建议的 RFC 7282 引用。

把数字口诀删掉，可以被理解为保护而不是削弱粗略共识：避免读者把本应由论证质量、未决异议和主席判断共同决定的事情，误读成表决阈值。然而，这种解释仍应进入记录。最有用的证据不是一句“这是现行政策”，而是旧段落、删除理由、留下的原则表述、工作组处置以及后续审查结果之间的连接。

同一草案又写入辅助角色。主席和领域主任可以任命或免除承担辅助职责的参与者；这些角色不会改变共识决策，也不会减轻主席和领域主任的原有责任。IETF 126 的处置显示，文字会调整，但问责护栏要保留。

这里可能同时存在描述与规范化。一封公开工作组邮件提到，许多组并不正式任命 Document Editor，并询问 2418bis 是否应反映这一常见做法。这是一个可引用的实践主张来源，却不是对所有 IETF 工作组的调查，更不是既成的规范裁决。分类账可以诚实写明：“实践证据来自参与者经验，工作组决定将其写入并保留问责边界。”这样既不贬低经验，也不把经验偷偷升级为旧有政策。

邮件列表变成公开论坛时，责任是否仍是同一个责任

RFC 2418 诞生于邮件列表居于中心的位置。2418bis 第 04 版把主席的管理范围写成公开论坛，包括邮件、聊天群和其他协作工具，并要求这些论坛的结果得到总结和充分记录。

如果公共讨论早已分布到多种媒介，这可能只是把旧的公开性与留痕义务投射到新工具上。但文字也可能产生新后果：哪些聊天空间算作工作组论坛，主席能在其中采取什么措施，临时讨论何时必须回流到正式记录，哪些材料能够支持共识判断。只有先说明变化类型，审阅者才知道应检查“责任是否不变”，还是评估“权限是否扩大”。

草案对采纳状态的处理又不同。它说明：工作组采纳一份草案，只是把它作为工作事项的基础，并不等于认可其全部内容；之后也可以撤销采纳，使其回到未采纳状态。这是一种明确的文本保管模型。由于现行章程直接点名准许围绕草案采纳进行非编辑性修改，不能因为旧 RFC 没有同样表述，就把这一变化一概称为越界。更恰当的分类可能是“有章程授权的政策调整，同时归并既有经验”。

2026bis 证明，争议可以消失，分类问题仍会留下

2026bis 更新幻灯片区分了被称为编辑性的修改、仍待处理的问题和准备再次进行工作组最后审议的事项。IETF 126 决定撤回第 09 版中关于非公开申诉讨论的新文字，并把外部标准的例子从 Unicode 改成 IEEE 802 Ethernet。

有关非公开讨论的公开邮件往来值得保留，但只能按其真实身份引用。一位参与者认为增加裁量权属于章程之外的政策变化，回复者则以 RFC 2026 和现行做法为依据，认为它更接近澄清。邮件证明双方确实提出了这些理由，不证明 IETF 已经作出制度判决。后来撤回文本解决了下一版写什么，却没有使边界问题失去研究价值。

另一个词汇问题更加细小：Datatracker 使用 “inactive”，旧文档使用 “expired”。在公开讨论中，参与者明确指出，新词也许更符合现实，却未必只是编辑改动。会议材料把该问题列为延后事项。一个状态名若改变了何时触发程序效果，就不是界面同步；若只是让规范引用当前工具，则可能是机制修正。分类先于结论。

一张薄表，足以保留权限的来路

修改分类账不必变成第二套标准流程。只有会改变行为、角色、责任、共识说明、记录范围、采纳状态或申诉条件的差异，才需要完整条目。每条至少包含：

  1. 不可变的草案版本与具体段落或差异；
  2. 被归并或替换的 RFC、勘误、IESG 声明等基线；
  3. 所主张的现行实践或工具状态及公开证据；
  4. 归并、过时机制修正、惯例成文化、有意改策中的一项或多项分类；
  5. 现行章程条款、拟议修章文字，或无需新增授权的理由；
  6. 编辑理由；
  7. 重要异议及其明确归属；
  8. 工作组决定与日期；
  9. 工作组最后审议后的变化；
  10. IETF Last Call 与 IESG 处置；
  11. 最终发布文字；
  12. 工具和实际运作采用情况。

允许一处差异拥有多种分类，比强迫所有变化落入单一格子更符合现实。关键是不能留下无解释的空白。所谓“惯例”必须给出证据，所谓“修正”必须指出不变的责任，所谓“有意调整”则必须给出授权。

这也把异议放回适当位置。个人邮件不会因为被列入分类账就变成机构裁决；它只是说明审阅者当时面对过什么反例。工作组后来接受、修改或删除差异，也都可以被记录。分类账保存决策路径，不冻结失败提案。

现有审查链能够决定文本，却未必自动保存理由

反对增加记录负担的理由很强：IETF 本来就有工作组共识、Working Group Last Call、IETF Last Call、领域主任审查和 IESG 评估。IETF 126 上，领域主任表示在拟议章程更新下 2026bis 应属于范围内，同时也说明自己尚未深入检查 2418bis 的所有差异。这恰恰表明现有审查仍在运作，并可能补上当前缺失的判断。

PROCON 文件列表在研究截点把 2026bis-11 列为工作组最后审议阶段，把 2418bis-04 列为工作组文件。前者不是 IESG 批准，后者更不是已发布 BCP。任何分析都不应把草案状态提前写成政策完成。

然而，审查节点能决定“通过或修改”，不会自动把“为什么这类修改被认为有权作出”整理成耐久索引。理由分散在邮件、幻灯片、纪要与版本日志中。数年后，读者可能看得见最终句子，却分不清它是在归并旧权威、记录工具现实、把惯例规范化，还是行使了章程明确提供的裁量。

分类账因此不与共识竞争，也不添加审批门槛。它只要求决定者在现有节点留下可追溯说明。若 IESG 改变分类，记录就更新；若差异被删除，条目写明处置；若实践主张被证伪，错误不会被最终文本继承。

Heng Lu 的第 64 则笔记提供了一种观察框架：先稳定最小基线，把未来选择交给有权作出选择的局部主体，并把后来是否采用视为另一项行为。这则笔记不是 PROCON 事实来源，也不能替代 IETF 程序。它在此处的价值，是提醒我们不要把旧基线、后续决定和实际采用压扁成一个“现行”时刻。

来源

  1. PROCON 现行章程
  2. PROCON 文件列表
  3. IETF 126 PROCON 会议纪要
  4. IETF 126 PROCON 主席幻灯片
  5. IETF 126 2026bis 更新幻灯片
  6. IETF 126 2418bis 幻灯片
  7. Heng Lu 第 64 则笔记
  8. PROCON 公开范围讨论
  9. PROCON 关于 Document Editor 惯例的公开讨论
  10. PROCON 关于 inactive 与 expired 的公开讨论
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418