摘要

  • ICANN org 于 2026 年 9 月 18 日向 Reviews CCG 表示，记录显示 GNSO 和 ccNSO 在 2016 年正式采纳统一框架，但未发现其他 SO/AC 采纳或背书。
  • 董事会从未被要求审议和采纳该框架，因此不能仅凭文件推定董事会已同意其中描述的通用角色。
  • 现有 Reviews CCG 依赖 2025 年独立章程、SO/AC 提名与董事会批准；待补足授权的是未来 Structural Review 工作组，而不是当前小组。

两次采纳之后，记录停了下来

2016 年 10 月 13 日，GNSO Council 批准未来跨社群工作组的最终框架。决议要求在 ccNSO 也作出采纳后通知所有 SO/AC，并建议 ICANN 社群今后筹建 CCWG 时参考这套原则。11 月 7 日，ccNSO Council 通过第 123-07 号决议，采纳最终报告与框架，同时邀请各咨询委员会及 Address Supporting Organization 也予采纳。

这里出现了三类不同事实：两个机构作出正式采纳；其他机构收到通知；其中一些机构被明确邀请采纳。通知和邀请都不是采纳本身。

Reviews CCG 在 2026 年 9 月初讨论未来 Structural Review 时，要求 ICANN org 查明 CCWG 方法的现状。9 月 18 日的答复称，经查阅组织记录，ICANN org 不认为除 GNSO 与 ccNSO 外还有其他 SO/AC 采纳或背书了这套框架。因此，这份文件目前至多应视为参考点，不能视为已经得到验证、可直接用于召集跨社群小组的机制。

这是一项有边界的缺失结论。它说明正式记录里没有找到其他采纳或背书，不等于断言十年间从未有人引用、借鉴或非正式采用其中做法。能证明“影响”的材料，不能自动证明“授权”。

董事会的状态另有一条清晰记录。GNSO 历史页面把提交董事会审议前的公共评论与董事会决议均列为“不适用”。ICANN org 又说明，董事会没有被要求审议和采纳该框架，因此也没有通过这条路径同意文件所定义的董事会角色。

Version 1 授权的是一套建组程序

框架正文没有把自己写成对所有未来小组永久生效的硬性章程。它称自身为一般框架、社群共同形成的指导原则与最佳实践。真正的建组动作从一份具体章程开始：至少两个 SO/AC 必须各按自身正常程序采纳完全相同的章程，才成为该 CCWG 的章程组织。

因此，章程才是权力分配表。它应当列出章程组织、批准日期和决议；区分获任命的成员、开放参与者与观察员；说明董事会或 staff liaison 是否参加、以何种身份参加；规定共识、表决或其他决定方法、门槛、少数意见、争议升级、修改与关闭方式。

开放参与并未被排除。未获章程组织任命的志愿者可以参加会议与工作，但默认规则把正式共识判断限定在获任命成员之内。这样设计的价值，在于让证据入口尽可能开放，同时不让“进入房间”悄然变成“代表某机构作决定”。

交付物也必须返回授权源。每个章程组织依照自己的规则审议同一结果。除非章程另有规定，所有章程组织至少都不反对，文件才成为正式的 CCWG 共识输出。此后是否提交董事会、实施或进入其他流程，也须沿章程规定的路线进行。2016 年框架提供的是制作授权记录的方法，不是现成的全机构授权。

当前 Reviews CCG 的授权来自另一份章程

正在运行的 Review of Reviews Cross Community Group 不应被放进 2016 年的采纳缺口。它在 2025 年形成了独立的制度链。

其章程把各 SO/AC、董事会和 ICANN org 列为提名方。提名成员即被视为支持该章程。成员在组内以个人身份行动，并不代表提名方；最终是否支持提案，仍由各 SO 与 AC 决定。组内追求共识，组外则要求所有 SO/AC 各按自身程序表态。若有两个或以上 SO/AC 不支持，流程关闭。

2025 年 9 月 5 日，董事会批准该章程，并任命 James Galvin 与 León Sánchez 参加小组。董事会主席随后以信函确认两项决定。这些材料不改变 2016 年框架的采纳范围，却足以证明当前 Reviews CCG 拥有自己的章程、提名方式、外部支持门槛和董事会关系。

Structural Review 仍在设计授权入口

2026 年 6 月的 Review of Reviews 草案设想，未来 Structural Review 的后续阶段由一个采用既有做法的 Cross-Community Working Group 执行。9 月 1 日会议记录显示，成员希望保持开放参与，因为审查可能触及 ICANN 是否需要新组成部分、现有部分如何跨越孤岛、董事会结构以及整个机构是否适合其目的。

讨论范围很大，但会议同时要求查询 CCWG 的制度状态。9 月 18 日的答复没有否定未来跨社群小组，而是要求把过去由名称暗示的内容写进新设计：哪些或多少 SO/AC 批准章程，成员如何保持合理平衡，建议在提交董事会前需要多少机构背书，以及董事会若不采纳时必须启动何种对话。

把授权写成逐版本收据

未来小组启动前，可以用一份公开收据把章程与每项组织行为锁在一起。收据首先公布确切版本和哈希。随后为每个 SO/AC 分列状态：已审议、已采纳、已背书、反对或无行动，并附日期、决议与范围。另设字段说明该行为是否使机构成为章程组织、提名方、观察方，还是不承担角色。

成员任命权、成员与参与者的差别、内部决定门槛、少数意见与升级程序、最终交付物如何回到每个机构，也应在同一记录中。董事会一栏需要拆开 liaison、审议、拒绝时的对话、批准与实施，而不能只写“提交 Board”。章程若发生实质变更，应产生新版本和新的机构回执。

广泛参与能够改善 Structural Review 的知识与异议输入。它不能填补某个 SO/AC 尚未作出的采纳决定。最稳健的做法，是让 2016 年框架继续提供问题清单，再让新章程与新收据证明答案。

来源