摘要

  • RSSAC Caucus 完成 RSSAC 大多数报告和建议的专业工作，但不能以 RSSAC 名义采取正式行动。RSSAC 任命 Caucus 成员，可以修改项目范围、退回草稿，并对发布进行表决。
  • 2026 年的 RSSAC000v10 比 2018 年独立审查所描述的程序更明确。不过，公开记录仍未给出当前申请拒绝率、申诉结果、贡献集中度或从初稿到终稿的完整实质修改轨迹。
  • Caucus 的权力在上游：决定哪些专业者进入、哪些证据先被组织、哪个版本成为讨论起点。它无权运营根服务器、分配号码资源、制定 RIR 政策或 IETF 标准，也不能命令 ICANN 董事会或独立运营者执行。

从 RSSAC062 的署名页倒着看

2025 年 5 月获批的 RSSAC062 讨论安全事件报告。文件末尾不是简单的致谢，而是一张程序地图：十三名 RSSAC Caucus 成员被列为贡献者；Robert Story 是工作组负责人；Ken Renard 是 RSSAC shepherd；四名 ICANN 工作人员提供支持，其中 Andrew McConachie 标为编辑。文件同时记录“无异议”和“无人退出”，并说明除异议或退出部分所列人员外，文件得到 RSSAC 的共识批准。

这些记录不能证明每个人写了多少，也不能证明 RSSAC 没有改动草稿。它能证明的是，专业贡献、工作组织、与正式委员会的衔接、编辑支持和最终批准并不是同一个角色。

RSSAC000v10 把这种分工写进现行程序。该版本于 2026 年 8 月 4 日由 RSSAC 批准。程序称，Caucus 生产 RSSAC 大多数报告和建议；同一份程序又明确，只有 RSSAC 才能以“RSSAC”身份采取正式行动。

Caucus 工作成果先在 Caucus 内部审阅。草稿稳定后进入 RSSAC 审阅，RSSAC 可以提出评论、编辑和问题。负责人需要处理这些反馈，反复流转，直到文本再次稳定。此后才向 RSSAC 请求正式行动，由主席把批准事项列入常规会议议程。

发布不是起草者自行完成的最后一步。现行规则下，每个根服务器运营者在 RSSAC 有一票；发布文件需要达到法定出席并跨过 75% 的特别多数门槛。批准后，工作人员才准备和发布正式文件。

因此，这条链上存在两种不同的作者权力。Caucus 决定第一份完整证据叙事长什么样；RSSAC 决定这份叙事是否可以成为机构建议。前者能塑造讨论，后者掌握授权边界。

进入起草室之前已经发生一次权力分配

本次取证时，Caucus 公布的成员页显示 115 条结果，RSSAC 正式成员页显示 24 条结果。这只是网页名册数量，不能当作活跃人数或表决票数。但它说明一个基本事实：承担多数起草工作的专家池，比能够正式行动的委员会大得多。

成员委员会掌握第一道筛选。RSSAC000v10 要求其评估申请人是否熟悉 RSSAC 工作、是否能投入时间，以及能否带来有价值的技能和经验。该委员会本身由 RSSAC 任命。当前加入页面列出的成员是 Shailesh Gupta、Dave Lawrence、Jeff Osborn 和 Ken Renard。

程序的两条路径并不对称。如果成员委员会决定不推荐申请人，申请人的名字不会提交给 RSSAC。委员会主席逐案处理申诉，申请人在同一十二个月内不能重新申请。如果委员会决定推荐，工作人员将申请材料交给 RSSAC，并给出一周决定时间；无人反对即获接纳，一名 RSSAC 成员提出异议就足以拒绝。申请人可以要求解释，也可以申诉，但由 RSSAC 主席逐案决定如何处理。

现有证据没有证明这种裁量被滥用。它同样没有公布申请总数、委员会阶段和 RSSAC 阶段各拒绝多少人、理由类别、解释请求或申诉结果。能够成立的批评不是“存在违法动机”，而是外部无法检验这套入口机制的实际结果。

这道入口与技术结论之间有直接联系。没有成为 Caucus 成员的人，不能以成员身份提出工作、参加起草或审阅。成员委员会不批准技术建议，却在建议出现之前决定未来证据池由谁组成。

可以从下方提出问题，不能绕过上方授权

现行程序允许 RSSAC 成员或 Caucus 成员在各自范围内提出工作事项。Caucus 项目需要一份工作说明，先在 Caucus 讨论和修改。RSSAC 随后可以再次讨论和修改，主席再决定是否要求 RSSAC 表决启动项目。

项目启动后，工作人员负责最初的组织，直到工作组产生负责人。如果负责人不是 RSSAC 成员，工作组还要指定一名 RSSAC 成员担任 shepherd。负责人协调贡献者、审阅者和观察员，并向 RSSAC 报告进度；RSSAC 如果认为进展不足，可以替换负责人或采取其他推进措施。

正在进行的 RSSAC001v3 项目把这一边界写得更具体。2025 年 4 月的工作说明要求重新评估根服务器运营者的服务预期。工作组可以认为没有必要发布新版本，但必须提前两周在 Caucus 主邮件列表通知。只要有人提出异议，是否关闭就交由 RSSAC 表决。如果形成新的 RSSAC001v3，正式发布同样需要 RSSAC 表决。

这是一种受委托的专业生产，而不是 Caucus 对 RSSAC 名义的所有权。项目可以在较大的专家池内生长，最后的制度动作仍在较小的代表机构内完成。

2018 年是基线，不是 2026 年判词

2018 年独立组织审查同时记录了正反两面。技术读者普遍认可 Caucus 文件的质量和可见度；审查者也估计，当时约 90 名成员中只有 25 至 30 人活跃，并指出 RSSAC 与 Caucus 边界不清、优先事项模糊、成员不活跃，以及 RSSAC 因决定谁加入或离开而对 Caucus 形成事实控制。

这些发现解释了后来为何需要改革，不能直接证明今天仍然如此。报告中的匿名访谈引语是被记录的感受，不是当前动机或行为的已证实事实。把 2018 年活跃率写成 2026 年数据，会越过证据边界。

第 6a 号建议要求建立更有效、更透明的流程，用于定义 Caucus 项目、吸纳和管理成员、管理工作并推广成果。2020 年实施报告称，实质性工作组讨论以及草稿和终稿审阅已经移到公开的 Caucus 邮件列表，成员委员会也在评估参与情况。报告同时说，结构调整仍依赖 Root Server System Governance Working Group 的进展。

2022 年最终进展报告从项目管理角度宣布第二轮审查实施完成，却继续把第 6a 号建议列为依赖项。ICANN 董事会在同年 9 月接受所报告的完成状态，同时要求 RSSAC 定期汇报两项依赖建议的进展。第三轮 RSSAC 审查后来被延期；当前状态页记录，董事会于 2025 年 5 月确认，组织审查继续推迟到首轮 Continuous Improvement Program 周期结束。

当前最强证据是 RSSAC000v10。它明确了工作提出、负责人和 shepherd、公开列表、成员复核、Caucus 与 RSSAC 两级审阅、异议和退出、正式行动以及发布步骤。这些内容回应了 2018 年的一部分问题。它没有给出当前参与率，也没有展示拒绝、申诉和草稿修改的结果数据。

所以结论必须带时间标记：可见程序已经改善，验证程序实际如何分配机会和影响的公开数据仍不完整。

“建议”不能在描述中被扩写成“命令”

ICANN 章程对 RSSAC 使用的是建议性动词：提供建议、沟通、评估风险、回应、报告和提出政策建议。所审阅的规则没有赋予 Caucus 或 RSSAC 运营根服务器、命令独立根服务器运营者、分配 ASN 或 IP 地址、改变 RIR 政策或制定 IETF 标准的权力。

RSSAC 文件也不当然约束 ICANN 董事会。RSSAC000v10 规定，文件获 RSSAC 批准后，可以在发布前向董事会提供 48 小时礼节性预览。ICANN 另有接收、理解、考虑、实施和关闭咨询委员会建议的工作流程。预览和状态流程证明事项被处理，不证明建议造成了决定，更不证明接受方受到强制。

号码资源持有人仍然有理由关注。根系统的服务预期、事件报告和韧性假设会影响网络运行环境。但权力和成本必须沿三个独立环节追踪：专家起草、RSSAC 正式建议、下游实际执行。任何一环都不能替代下一环的证据。

来源