摘要

  • Review of Reviews 小组申请将最终报告交付时间延至 2027 年 3 月的 ICANN88，并在报告审议期间保留小组，回答问题。
  • 10 月进展文件提出了新的评审协调、参与能力和支持门槛安排；这些仍是方案，不能当作已经生效的规则。

一份评审报告发现政策有问题，接下来该谁改？这个看似顺理成章的问题，恰好是 ICANN 重做评审制度时必须处理的难处。让评审只能提意见，可能留下无人处理的结论；让评审直接改政策，又可能绕开原本有权制定政策的组织。

Review of Reviews Cross Community Group 正试着把两件事分开。它在 ICANN87 进展文件中明确提出：评审可以检验既有政策的效果，但不能代替政策制定程序。发现需要修改政策的问题，可以建议有关支持组织考虑，是否启动、怎样推进，仍由那个组织按自身程序决定。

这不是措辞上的洁癖。ICANN 的制度评审涉及问责、透明度和组织运行。谁提出问题、谁有权采取行动，决定了报告会推动改进，还是变成另一套竞争性的决策程序。

延期申请里，有两个不同的请求

10 月 5 日，Avri Doria、Chris Disspain 和 Manal Ismail 三位共同主席向提名团体发出申请：一是把最终报告的交付时间延至 ICANN88；二是在报告接受审议期间继续保留小组，以便答疑和解释。10 月进展文件注明，ICANN88 是 2027 年 3 月的会议。

小组想争取的时间，用于第二轮公开征求意见。第一版草案于 6 月 25 日进入公众意见程序，8 月 4 日截止，共收到 23 份意见，其中两份逾期提交。小组一边处理意见，一边继续调整设计；8 月 12 日就已通知提名团体，可能需要延期。

10 月更新的工作计划安排在 ICANN87 后公布第二版草案，处理反馈，再于 ICANN88 向提名团体提交最终报告、寻求支持。报告交出去，和建议获采纳，是两件事。这个时间表没有承诺董事会届时已经作出最终决定。

旧稿混淆过另一个日期：8 月 25 日是工作人员汇总公众意见的报告截止日期，并非小组最终报告的指定交付日。10 月文件确实说，最终报告原先预计在 8 月完成，但没有把它写成 8 月 25 日。

协调评审，不等于多设一个决策中心

新方案中的 Reviews Scoping Committee，负责协调评审范围等工作。10 月文件把它定位为提出建议、交由支持组织和咨询委员会认可的协调机构，而不是替这些组织拍板。董事会和 ICANN 执行机构在其中的角色，也被调整为联络角色。

方案还要求，在启动评审前，核实七个支持组织和咨询委员会中至少五个具备参与所需的能力。评审需要有人读材料、参加讨论、跟进实施；不能只在日程表上留出时间，却没有足够的人做事。把参与能力放到启动前核实，是这项设计试图解决的实际问题。

报告完成之后，同样有新的安排。未来的最终评审报告拟同时送交董事会及各支持组织、咨询委员会，后者有两个月决定是否支持每项建议或一组相关建议。方案提出，至少七个中的五个支持，才达到规定的社区支持门槛。

这里的“五个”针对未来制度。它不是此次延期申请已经适用的批准规则，也不能倒过来改写现行小组章程。读这类文件，最容易犯的错误，就是把设计中的程序提前当成已经能用的权力。

交报告以后，原本就不是立刻散会

保留小组的请求，也不意味着过去完全没有后续解释程序。已通过的章程规定，若董事会认为实施某项建议不符合全球公共利益，应说明理由并与小组展开对话；小组何时解散，则取决于提名团体主席或指定代表的通知。报告提交本身不会让小组自动消失。

章程对“参与”也有细致区分：提名成员，被视为支持章程；但成员以个人身份参与，是否支持最终建议，仍由各支持组织和咨询委员会决定。留下熟悉报告的人回答问题，有助于解释方案，却不能让这些人替其他组织表示同意。

还有一只独立运行的时钟。现行 ICANN 组织章程第 27.6 节，自 2026 年 6 月 10 日起暂停指定的几类评审义务，规定原则上十二个月后恢复，并列出例外条件、延长所需理由和二十四个月的总暂停上限。小组提出延期，不会自动重设这只时钟。

第二版草案真正值得关注的，不只是多了几个月，而是能否把发现问题、协调人力、表达支持和作出决定连成一条清楚的路径。报告作者留下来，可以让问题有人回答；谁有权接受答案并采取行动，仍须写得明白。

更正与更新，2026 年 10 月 25 日：区分公众意见汇总与最终报告的时间，补全三位签署人，并依据已通过章程修正“提交报告即结束”的理解。原网址和原始发布日期保留。