摘要

  • ICANN董事会8月21日回函称，不应设置可能妨碍其依章程完成审查的固定最长期限；它转而承诺在每次ICANN公共会议前提供状态通报，并在会前董事会研讨会中把政策进度列为常设事项。
  • 通报频率不是决定历史。更完整的“建议—决定时钟”应保留收件、必需材料、关键问题、责任人、预期变更和逐项处置，同时明确联络人、caucus、员工分析与利益相关方对话都不能取代董事会的决定权。

ICANN用一套通报节奏，回应了社区对政策审议期限的要求。

5月25日，GNSO六个利益相关方团体与选区的负责人联名致函ICANN董事会主席Tripti Sinha。他们并非声称章程对时间只字未提。Annex A已经说，董事会应在可行情况下尽快讨论GNSO Council建议，最好不晚于收到Recommendations Report后的第二次会议。来信指出的是另一处空白：开始讨论的预期，不等于完成审议的期限。

联名方建议建立标准时限，可以同时使用“若干次董事会会议”和“最多若干个月”两种刻度，信中把六个月作为例子。他们还要求持续公开状态，把Consolidated Policy Scorecard放在更稳定、容易寻找的位置，并在董事会审议期间为GNSO Council与相关Working Group领导层提供澄清问题的渠道。

8月21日的回函同意“应更有可预期性”，但没有接受硬期限。董事会称，政策建议的性质与复杂度不同，固定的最晚完成日可能妨碍章程要求的审查。替代方案是公布预期时间与状态：每次ICANN公共会议前提供一次更新，在每次会前的董事会研讨会中把政策工作进度列入常设议程，并继续与GNSO Council及有关利益相关方团体审阅政策生命周期各阶段。

这不是文字上的微调，而是两种控制方式的选择。硬期限约束经过的时间；通报节奏约束机构必须在什么时候解释自身状态。后者可以约束前者，但前提是每次解释都积累证据，而不是用最新标签覆盖上一段历史。

来信中的两个案例已经越过董事会审议

5月来信点名两组当时仍在等待董事会完成审议的建议。IDN EPDP Phase 2的Recommendations Report在2024年12月送达，Transfer Policy Review的报告在2025年4月送达。到8月回函发出时，它们都已经改变状态。

6月7日，董事会通过了Transfer Policy Review的全部47项建议，也通过了IDN EPDP Phase 2的全部14项政策建议。两项决议都指示总裁兼首席执行官或其指定人员推进实施，但须服从优先排序，并考虑实施中出现的运营、技术、法律、安全或资源问题。

董事会的理由说明承认社区对审议时间与流程的担忧，也列出了它所考虑的材料，包括Final Report、公众评议记录、可行性分析、对GAC的通知以及各主题专属证据。这个结果没有消除早先的时间问题，却把两个“仍待决定”的例子变成可以复盘的已完成案例。

ICANN现行政策实施页面把两个项目都列入implementation queue。这个状态晚于“等待董事会行动”，却仍早于“实施已经开始”。排队不等于已经分配人员，不等于Implementation Review Team已启动，也不等于政策文本已经起草，更不等于合同义务已生效。

单看5月来信，读者可能误以为两组建议至今仍在董事会手中；单看当前实施页，又可能把争议误解为实施排队问题。只有把旧状态、6月7日的决定和新状态连在一起，才能看清权力在哪个节点实际移动。

“讨论”与“处置”不是同一条规则

Annex A的措辞有意保持克制。它要求董事会尽快开会讨论，最好在收件后第二次会议前进行；它没有规定董事会必须在那一次会议上批准或拒绝。本文核验的公开资料也没有证明每次有关讨论具体发生在何日，以及ICANN在这个条款下如何计算“会议”。

因此，不能把经过的日历时间直接写成章程违规。公开证据支持的结论更窄：现有规则在审议入口附近设有一项时间预期，却没有在出口设置固定上限。

这种弹性保护了一项真实责任。得到GNSO supermajority支持的建议具有很强的制度分量。依章程，董事会原则上应采纳，除非超过三分之二的董事认定采纳不符合ICANN community或ICANN的最佳利益。这一高门槛尊重自下而上的政策工作，却没有免除董事会检查合法性、可行性、安全、成本与公共利益的义务。

六个月到点自动通过，会破坏这项责任；无限期挂着“审议中”，又会使时间无法问责。治理不能靠在两种失败之间选一边，而应让机构说明时间花在了什么问题上。

对话可以补全材料，不能偷换授权

8月回函把Board liaison、与GNSO Council的主动交流和Board Caucus Group列为改善准备工作的工具。2025年的Board Readiness报告已经描述过这条断裂：传统上，董事会往往在PDP团队提交Final Report并解散数月后才开始深入考虑；最熟悉妥协、未采纳方案与措辞沿革的人已经回到本职工作，事后澄清变得困难。

提前提问确有价值。Board liaison可以在Working Group尚能回应时提醒章程、成本或实施方面的疑问。caucus可以组织董事的分析。ICANN员工可以整理公众评议、可行性与资源材料。Working Group领导者可以说明某段含糊是有意平衡，还是草拟时的缺口。

但这些角色都不应取得隐形修法权。联络人传递问题，不认定GNSO共识；员工报告提供依据，不取代建议；双边会议可以澄清既有文字，如果实质内容发生变化，则必须说明谁有权批准、是否应回到原政策机构。

董事会回函本身也守住了这条边界：互动可澄清记录、尽早暴露问题，但不能改变董事会与GNSO Council在章程下各自的角色。通过混合角色换来的速度，不是流程改进。

Scorecard回答“在哪里”，时钟回答“怎样到达”

ICANN称，Consolidated Policy Scorecard会定期汇集社区政策与其他成果的进度。它解决了真正的导航问题：读者不应为了确认一个项目的位置，逐页拼接往来函件、董事会会议资料、GNSO项目页和实施页面。

然而，“定期”仍可能只留下快照。假设项目从“董事会审议中”变成“实施队列”，新版scorecard可以展示新状态；如果旧版状态与转换事件没有被保存，它就无法说明董事会何时取得完整材料、哪项问题拖延了排期、预期日期为何调整，或某些建议是否被暂缓而其他建议获批。

同一个“pending”还可能包含完全不同的事实：公众评议尚未结束、GAC回复期未届满、可行性分析未完成、董事提出法律问题、研讨会已经排期，或者根本无人负责下一步。把这些情况压成一个词，会让状态表看似整齐，却无法分配责任。

这不意味着必须公开律师意见或安全敏感材料。公开记录可以只给出有限理由类别，例如法律审查、技术可行性、资源评估、公共政策意见、等待澄清或议程容量；保密理由失效后，再审查是否可增加披露。

建立“建议—决定时钟”

Daniel Kade提出的时钟从董事会收到权威Recommendations Report开始。它保存报告身份与指纹、GNSO表决、适用的章程路径和表决门槛。随后列出每项必要材料以及进入董事会记录的日期：公众评议、GAC通知、可行性分析和其他被明确要求的材料。

时钟必须区分协调者与决定者。它可以注明负责推动材料的liaison、caucus或员工owner，但把决定权清楚标在Board。它可以记录首次讨论与后续实质审议，却不把“有人参加会议”写成“已经形成结论”。

状态词汇应当窄而稳定：已收件、等待材料、可供审议、请求澄清、决定已排期、采纳、拒绝、暂缓、撤回或被取代。每一状态都要有证据日期、下一动作、责任人和预期。预期发生变化时，保留旧值并记录理由，不能只覆盖为最新日期。

作出决定后，时钟按每项建议而不是只按整份报告保存处置、表决、理由和实施条件。若采纳后进入implementation queue，则另建交接记录，明确“排队”和“已开工”的差别。

这不是用机械期限逼董事会表决。复杂建议有正当理由花费更长时间。时钟要求的只是：这些理由、责任与状态转换留下可检验的痕迹，而不是让社区从一连串礼貌但模糊的通报中猜测。

来源

  1. ICANN往来函件索引
  2. Tripti Sinha致Mason Cole、Rafik Dammak等，2026年8月21日
  3. Owen Smigelski、Mason Cole等致Tripti Sinha，2026年5月25日
  4. ICANN董事会2026年6月7日通过的决议
  5. 现行ICANN章程
  6. ICANN政策实施页面
  7. GNSO Board Readiness Small Team Final Report
  8. GNSO IDN EPDP项目页
  9. GNSO Transfer Policy Review项目页