摘要

  • draft-ietf-procon-2026bis-11 发布于 2026 年 7 月 1 日；截至 8 月 27 日，它仍处于工作组最后审议阶段。它保留了 RFC 2026 的变通程序，但尚未成为取代 BCP 9 的正式文本。
  • 当某一份具体规范遭遇程序僵局，或现有程序没有给出处理方法时，负责的工作组可以建议变通；没有工作组时，可由临时委员会提出。建议只是启动审议，不等于获准。
  • IESG 必须说明技术价值、正常路径是否仍可实现目标、替代方案、违规成本、连带与先例效应以及为何范围已足够窄。提案还要成为单独的 Internet-Draft，接受至少四周的延长 Last Call，公开宣布结果；获准后以 BCP 发表，并保留申诉渠道。
  • 明定的时限、开放、公平、共识、记录义务以及若干核心程序不能被豁免。因此，可靠的数据模型应保存一张只绑定该规范的版本化“例外凭证”，而不能让个案修改默认规则、自动授权后案或替运营者作出部署决定。

例外对象不能覆盖规则对象

把程序写成机器可读状态时，人们很容易追求一个答案：某项要求究竟是“必需”还是“非必需”。可变通程序偏偏要求系统同时容纳两个都为真的事实——这项要求仍然是默认规则；在一宗经过完整程序的具名案件中，它没有以通常方式适用。

如果数据库只保存“已豁免”，下一次查询就会丢失对象边界。另一份规范可能自动跳过同一要求，尽管它没有负责工作组的建议，没有替代方案分析，没有公开 Last Call，也没有 IESG 决定。一次本来用于处理异常的判断，就在配置层变成了一次无人提案、无人审议的制度修订。

人的记忆也会复制同样的错误。后来的参与者把旧案称为“惯例”；简报把附带条件删掉，只留下结果；清单把“此前在某案获准”缩成“可以豁免”。久而久之，决定当时花费的程序成本消失了，结论却被无限复用。

正确结构必须保留两个对象。第一是可复用、带版本的程序规则。第二是与目标规范、目标版本和完整决策链绑定的例外记录。旧案当然可以成为新案的分析材料，因为 RFC 2026 明确要求审视先例效应；但“需要考虑先例”不等于“先例自行生效”。先例效应是风险项，不是继承机制。

这也不是对裁量权的不信任。没有出口的程序会在罕见案件前变得僵硬；任何出口都能改写默认值的程序则根本没有稳定规则。把例外独立保存，正是让弹性和可问责性同时成立。

当前看到的是合并草案，不是已完成的换法

Datatracker 文档页显示，draft-ietf-procon-2026bis-11 是 PROCON 工作组的一份活跃 Internet-Draft。但该页的 Intended RFC status 字段显示 None，而草案正文页眉又把 Best Current Practice 写作拟定状态。这两条记录都不能被压缩成“状态已经获批”。-11 版在 2026 年 7 月 1 日发布；若不更新或推进，将在 2027 年 1 月 2 日到期。历史记录则显示，工作组在 5 月 21 日、文件尚为 -08 时把它转入 Working Group Last Call。

截至 8 月 27 日，工作组状态仍是 In WG Last Call，IESG 状态为 I-D Exists，没有 telechat 日期。这些状态证明文件已进入严肃的工作组审议，却不能证明 IESG 已批准、RFC 已发布或新 BCP 已生效。

若最终获批，该草案会合并并废止多份程序 RFC，包括 RFC 2026，并更新 RFC 7475。PROCON 章程解释了任务背景：RFC 2026 和 RFC 2418 这两份基础文件后来被二十多份 RFC 修改，规则链已经分散。工作组的核心职责是把这些更新和经确认的勘误整理成更易读的继任文本。章程只点名两类可讨论的额外非编辑性变化；其他新增议题需要重新制定章程。

第 -11 版第 11 节继续保留变通架构，但它不是 2026 年突然授予的新权力。RFC 2026作为 BCP 9 的已发布组成部分，早在 1996 年的第 9 节就写出了基本相同的机制。新草案整理、更新称谓并重排章节；其变更记录没有把变通描述为新的政策实验。

因此，治理台账必须并列保存三个状态：RFC 2026 是当下已发布基线；2026bis-11 是工作组正在审议的拟议合并文本；将来若继任 RFC 正式发布，基线才在那个可归属的发布事件上改变。用草案解释方向没有问题，用草案替换现行规则则是把“正在发生”误写成“已经完成”。

谁能提出，谁必须判断

变通不能由任何感到不便的人自行宣布。负责该规范的工作组提出建议；若不存在负责的工作组，则由临时委员会提出。靠近技术问题的组织负责说明为什么出现僵局或程序空白，但它并不因此同时拥有批准自己的权力。

建议送到 IESG 后，IESG 要判断预期的互联网共同体收益是否超过不遵守程序要求的成本。判断项目不仅包括规范的技术价值，还包括：能否不变通而实现标准程序的目标，有哪些替代路径，可能产生什么连带后果和先例效应，以及能否把例外收窄到更小范围。

这组问题专门抵抗“文件很好，所以应该放行”的捷径。技术上出色不表示正常流程已经失效；时间紧迫不表示缩短公开审议更合理；工作组支持也不表示所有外部影响都已被看到；旧案相似更不表示新案已经完成自己的举证。

IESG 还可以只对某些条款给予变通，并附加额外限制。一项要求被例外处理，不会令其他程序一起停止。随着提案走向决定，例外的轮廓应越来越窄、越来越明确，而不是逐步获得一层模糊的广泛裁量。

公开链条不是仪式

内部建议如果只剩一句会议结论，很容易被选择性记忆。RFC 2026 要求把变通做成单独的公开对象。

提案必须说明所感知的问题、确切造成困难的条款以及 IESG 的审议内容，并以 Internet-Draft 形式公开。随后，IESG 要发起不少于四周的延长 Last Call。审议结束后，它作出最终决定并向 IETF 宣布；获准的变通送交以 BCP 发表。申诉程序仍然适用。

这些事件各自证明不同的事。工作组建议证明负责组织请求审议；Internet-Draft 固定了提案版本和边界；Last Call 证明公开审议窗口至少存在了四周，却不证明沉默等于赞成；IESG 公告证明谁作出什么决定；BCP 发表固定获准结果；申诉则形成另一条有申请人、有争点、有结论的记录。

RFC 7282说明，粗略共识的核心是反对意见的内容以及这些意见如何被处置，而不是赞成票百分比。变通审议尤其不能只留“支持人数”。一个结构性反对即使没有阻止最终决定，也应在凭证中能找到它的论点和回应。

这条链故意不便宜。若例外比正常程序更容易获得，它会迅速变成第二条常规路线。四周审议、书面理由、公开决定和可申诉性带来的摩擦，是迫使申请者证明“为什么非此不可、为什么只能到此为止”的制度成本。

不能被例外穿透的底板

例外程序最关键的设计，不是它允许什么，而是它绝不允许什么。RFC 2026 不允许变通降低已经明定的延迟期限；不能豁免开放、公平或共识；不能取消会议和邮件列表讨论的妥善记录；也不能绕过有关 BCP 审议、行动发起、IESG 审查、发布、冲突处理、申诉和变通本身的若干核心章节。2026bis-11 在新编号下保留了这块底板。

原因并不抽象。若一项例外可以同时免除公开、留痕和复核它所需的程序，它就能在最需要证据的时候销毁证据。制度仍可声称自己遵循了“例外机制”，外部却无法再区分一项受约束的裁量和一次不透明的权力行使。

至少四周的 Last Call 也是底板的一部分。它不是等待预定结论的计时器，而是让未参与前期讨论的人识别条款、成本和外溢影响的最低窗口。用“情况紧急”来缩短专门审查紧急性的时间，会让理由本身成为规避审查的工具。

底板并不承诺所有人同意最终结果，也不会取消 IESG 的判断空间。它所承诺的是：判断可见、可归属、有记录，并且例外不能顺手撤掉提出申诉的道路。

一张能够独立审计的例外凭证

合格的凭证首先要回答“哪一个”。它需要变通编号和版本，目标规范的名称、修订号与内容哈希，负责的工作组或临时委员会，建议记录及日期，申请豁免的确切 BCP 条款，以及观察到的僵局或程序空白。

接下来是“为什么”。凭证应记录未满足的要求、正常路径为何无法解决、技术价值判断、收益与成本比较、考虑后放弃的替代方案、连带和先例效应，以及最终范围与额外限制。只保存结论而不保存替代路径，会使以后的人无法判断决定是否真的必要。

然后是公开过程：变通 Internet-Draft 的标识和哈希，Last Call 的起止时间，实质性反对意见及其处置。最后是 IESG 决定和公告、若获准时的 BCP 身份、申诉状态与决定、一次性边界以及任何终止条件。

凭证还应明确写出两个“不证明”：它不自动授权以后的规范，也不证明任何运营者已经实施、采购或部署相关协议。

这里容易出现另一个词义陷阱：获准变通会以 BCP 发表，但这不表示它成为通用程序规则。BCP 的发布形式让个案决定稳定、公开、可引用；决定内容仍然只覆盖具名案件。永久修改可复用规则，必须走正常的 BCP 修订路径。

IETF 内部状态与网络采用是两份证据

变通处理的是一份规范如何在 IETF 标准流程中进入或推进。它不会替企业、运营商、公共机构或开源项目决定是否部署。

RFC 9281列明工作组、IESG 和其他主体在标准流程中的角色。角色的存在没有把例外扩展成让外部行动者改写文档状态的权力。RFC 3935则指出，IETF 标准描述的是声称符合标准时如何做；IETF 并不试图强制或监管标准的普遍使用。

所以，程序凭证和部署凭证必须分开。后者需要具名决策者、所采用版本、测试证据、上线范围、时间、回退条件和实际运行数据。变通可以成为部署者评估背景的一部分，却不能替代他们的决定。把 IETF 内部放行说成外部强制采用，是把程序弹性洗成了不存在的命令权。

Heng Lu 关于最小初始规范、本地化未来决策与自愿采用的框架提供了同样的观察角度：共同协调应只覆盖必要的共同边界，后续具体行动仍由相应主体作出并留存来源。这里用它解释治理结构，而不是替代 IETF 的程序证据。

来源