Summary

  • RFC 9945 于 2026 年 2 月作为 BCP 245 发布，建立覆盖 IETF 公共在线论坛的版主治理框架；但其过渡条款明确，新变化须待 IESG 批准第 4 节程序后才生效，在程序与标准尚未确立之前，旧流程继续有效。
  • RFC Editor 的“已废止”关系、六人团队名单、公开 SOP 与实际处置记录分别证明不同事实。生效凭据应把固定版本、社区参与、IESG 批准行为、决定与生效时间、替代范围、责任角色和在途案件迁移连接起来，同时保护投诉内容和个人信息。

同一天，可以有两种都正确的状态

打开 RFC 3934 的资料页，会看到它已被 RFC 9945 废止。再打开 RFC 9945，会看到 2026 年 2 月、Best Current Practice、BCP 245。这些字段没有错，它们准确描述了 RFC 文献体系中的继承关系。

但如果问题换成“2026 年 6 月 30 日某个工作组邮件列表适用哪套操作程序”，仅靠这两个页面就不够了。

RFC 9945 在引言结尾安放了一个外部开关：本文所述变化在 IESG 批准第 4 节程序后生效。第 4 节又规定，版主团队应在社区参与下制定和维护程序与标准，由 IESG 在其生效前批准，并向公众公开；这些文件不一定进入 RFC 系列。在新程序和标准确立前，第 1 节提到的原有流程继续有效。

因此，“新 RFC 已发布”与“新操作程序已生效”并不矛盾。前者说明框架取得正式文献地位，后者说明外部条件已经完成。RFC 9945 选择把稳定的权力边界写进 BCP，把需要随经验调整的操作细则放在另一个公开层。这种设计提供灵活性，也产生一项记录义务：必须能指出切换发生在哪个版本、哪项批准和哪个时刻。

“Obsoleted” 是路标，不是时钟

文献数据库需要告诉读者旧 RFC 的继任者是谁。否则，后来者可能把 2004 年的规定误认为最新制度。“Obsoleted by RFC 9945”正是在做这件事。

它没有回答所有运行问题。该字段不包含程序文件的哈希、不包含社区意见窗口、不包含 IESG 对某一固定版本的批准，也不包含实际生效时间。它是一条文献关系，而不是完整的授权日志。

两句话由此可以同时成立：RFC 3934 在 RFC 体系中已被废止；RFC 9945 的过渡条款又让旧流程在新程序确立前继续适用。若只保留第一句，旧流程可能被过早丢弃；若只保留第二句，又会错误地把已经发布的 BCP 当成不存在。

治理需要的不是选边，而是把两个状态连接起来。发布证明框架存在，批准证明某版程序获得授权，生效时间决定具体事件受谁约束。

7 月的申诉把抽象条件变成了现实问题

2026 年 6 月 30 日，Andrew Lee 就 TLS 工作组 Last Call 期间的一项版务措施向 IESG 提出申诉。其中一个论点是：RFC 3934 已被 RFC 9945 废止，因而不能继续提供权限依据。

IESG 于 7 月 9 日答复，决定直接审理并驳回申诉。在这一狭窄问题上，IESG 明确认为 RFC 3934 仍然有效，因为 RFC 9945 第 4 节要求，在新程序和标准确立之前继续沿用旧流程。答复还区分了另一处 BCP 9 引用：BCP 9 本身并不授予版务权限，但附带引用并未使该措施失效。

这里不重新裁判案件。公开答复不能被解释为证明审查者实施了审查制度、存在偏见、违法或行为不当；也不能用来证明所有版务措施天然公正。原申诉还涉及技术意见、回避、选择性执行和少数立场，IESG 已分别回应。

它对本文只有一个关键价值：规则何时切换，会实质影响权限来源。IESG 没有仅凭“已废止”标签作出判断，而是把一个带日期的行为与过渡条件连接起来。

该答复只证明 7 月 9 日 IESG 所确认的状态，并不能证明两个月后一切不变。截至 9 月 11 日，在本文查阅的官方材料中，没有找到后来由 IESG 公开批准某一固定新版程序的行为。搜索未命中不等于该行为不存在。它能支持的结论更克制：既然 RFC 要求程序公开且经过批准，读者就应当有一条权威索引，而不必在邮件、会议记录和仓库之间考古。

六人名单与三人 SOP 不是同一种证据

Datatracker 当前列出一个处于 Active 状态的 IETF Moderator Team，共六名成员。页面说明，他们负责为所有现有与未来公共 IETF 论坛建立程序，为社区处理破坏性行为提供资源，直接管理全体性论坛和没有其他管理员的论坛，并由 IESG 任命、向 IESG 负责。

这个页面回答“谁担任这一机构角色”。它没有列出经过批准的不可变程序版本，也没有给出生效行为和时间。

另一个公开入口是 ietf/Moderators 仓库。在固定提交 b907805e15… 中，README 仍围绕 IETF 总讨论列表及 RFC 9245 描述工作。SOP 列出三名成员，要求至少两名版主同意才采取措施，并设置 0、1、2 三个递进等级。统计文件则按这些等级记录年度数量。

差异本身不是指控。仓库可能只保存总讨论列表的旧制度；新团队可能在别处准备通用程序；名单可能尚未同步；旧 SOP 也可能在过渡期合法延续。仅凭公开差异，无法判断是哪一种。

恰恰因为存在多种无害解释，制度不能要求参与者自行猜测。团队页面证明任命，固定提交证明文字内容，统计证明某套分类被用于计数。只有 IESG 对明确版本的批准加上生效时间，才能证明“这套文字从此对这些论坛具有操作权限”。

新团队并没有吞并所有权力

RFC 9945 仍把一线责任交给论坛管理员。在工作组里，chairs 默认是相应公共论坛的管理员。他们可以委托具体工作，却必须接收、确认并跟踪投诉。与版主团队协商后，管理员还可以修改或撤销措施，包括由团队成员作出的措施。

版主团队负责制定共同程序、提供支持，并在管理员未及时响应或同一行为横跨多个论坛时介入。通常首先应联系当地管理员。团队直接管理 IETF 全体性论坛，以及没有其他管理员的公共空间。

Area Directors 处理初步冲突。IESG 负责批准程序、任免版主、定期评估，并处在申诉链条上。此后可依 RFC 2026 向 IAB 申诉。Ombudsteam 继续承担反骚扰职能。IETF Administration LLC 在法律意见认定组织面临严重法律风险时，拥有另一条极少使用的紧急路径。

IRTF、IAB、RSWG、RSAB 与 Independent Submission stream 并不会因为机构相邻而自动纳入 RFC 9945，除非明确同意。分权能够防止一个角色无限扩张，同时要求每个复核者准确知道：原始措施发生时，哪个角色在什么范围内依据哪版程序行动。

旧制度本来就不是一份文件

RFC 3934 主要规定工作组 chairs 如何处理本组邮件列表上的破坏性发言。RFC 3683 定义在社区和 IESG 参与下撤销发帖权的流程。RFC 9245 规范 IETF 总讨论列表及其版主安排。RFC 2418 规定工作组 chairs 的更广泛责任。RFC 2026 提供申诉结构。

RFC 9945 试图修复真实问题：不同论坛判断标准不一，旧流程可能过慢，跨列表模式不易被单个管理员看见，而工作早已进入聊天、远程会议、wiki、GitHub、GitLab 和 issue tracker。跨论坛团队与共同边界具有现实价值。

过渡期保留旧流程，并不把旧权限无限放大。RFC 9945 明确把 Datatracker 账号删除、限制线下或线上会议参与、删除或遮盖内容、私人通信及非 IETF 通信排除在普通版务措施之外。邮件列表权限不能在过渡中变成组织的万能权力。

案件本身也有历史版本。RFC 9945 规定，在新流程之前作出的无限期暂停，只能依据原决定当时的流程重新考虑。这说明文献已经承认：更新不能把旧决定的程序背景抹平。

一条够用的生效凭据

第一部分识别程序，而不是只给一个可变链接：固定提交或版本号、SHA-256、持久地址，以及涵盖的论坛类别。main 适合看当前状态，不适合单独证明过去。

第二部分识别授权：社区意见起止时间、意见处置索引、IESG 决定链接、批准时刻与生效时刻。两者若相同，应明确写明；若分阶段实施，应公布阶段表。

第三部分是替代表。它列出停止适用、暂时保留或只为旧案件保留的 RFC 条款、IESG 声明与本地 SOP，也标出不在范围内的组织与 LLC 法律紧急路径。团队任命另列时间区间，避免“有人上任”替代“程序获批”。

第四部分处理在途状态：待办投诉、有效限制、未结申诉、恢复资格的计时。公开层只需数量、规则版本与迁移方式，个人姓名和投诉内容留在受保护记录中。跨越生效日的案件必须明确选择适用规则，不能事后静默迁移。

第五部分记录落地与修正。各论坛管理员和技术负责人确认采用的版本；确认不创造权限，只证明批准已传达到执行点。发现错误时生成一条有关联的新记录，不覆盖旧时间线。

公开权力，不必公开投诉

版务投诉可能包含个人身份、私人语境或有害表达。逐字公开既会伤害投诉人与被投诉人，也可能扩大原有干扰。法律意见还可能限制通知范围。RFC 9945 所追求的透明与隐私平衡，不允许把“可审计”简化成“全部公开”。

生效凭据讨论的是规则、权力和时间，因此公开字段可以很薄。个案记录则需要另行保存通知、理由类别、范围、期限、决定者、复核和申诉，并采取分级访问。

还应防止证据越权。程序正确获批，不等于每次适用都公平；发出通知，不等于指控已获证明；年度统计，不等于个案一致；团队存在，也不等于程序已生效。每份材料只承担它真正能证明的命题。

Heng Lu 的文章在这里提供的是区分状态的分析方法，而不是关于 IETF 的事实来源。文献标签、可执行决定与运行观察分别属于不同层。最低初始规范应固定必要的连接，让未来变更继续由有权主体在局部作出。

RFC 9945 选择了值得肯定的方向：覆盖多个公共论坛，保留判断空间，明确边界、复核和申诉，又避免把每项操作细节永久冻结在 RFC 中。要让这套架构真正可核验，还需回答四个独立问题：谁被任命，采用哪份程序，谁批准了它，以及它从何时开始生效。

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9945/
  5. https://www.rfc-editor.org/rfc/rfc9945.html
  6. https://www.rfc-editor.org/rfc/rfc3934.html
  7. https://www.rfc-editor.org/rfc/rfc3683.html
  8. https://www.rfc-editor.org/rfc/rfc9245.html
  9. https://www.rfc-editor.org/rfc/rfc2418.html
  10. https://www.rfc-editor.org/rfc/rfc2026.html
  11. https://datatracker.ietf.org/group/iesg/appeals/artifact/314
  12. https://datatracker.ietf.org/group/iesg/appeals/artifact/315
  13. https://datatracker.ietf.org/group/ietfmoderators/about/
  14. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/README.md
  15. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/sop.md
  16. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/stats.md