摘要

  • 2026 年 9 月 1 日版《GNSO 操作程序》v3.8 纳入了 GNSO 理事会在 5 月 21 日批准的董事会撤回采纳程序。它只适用于实施尚未完成的有限、特殊情形；目前没有证据显示该程序已经启动。
  • 董事会应给 GNSO 理事会足够的对话时间，文本把约 60 天作为示例而非硬期限。问题在于，首份必须公开的董事会说明出现在董事会采取行动之后，最终文本并未把事前公众征询或实施审查团队参与列为必经步骤。

设想一项政策建议已经获董事会采纳，却处于实施中段。合同团队正在解释条款，工程团队正在开发系统，实施审查团队仍有未结问题，相关企业则已根据采纳决定安排预算。此时出现一项新事实，董事会认为原建议已不再符合 ICANN 或 ICANN 社群的利益，准备撤回此前的采纳。

治理难题并不是机构能否改变判断，而是受影响者何时能看到并质疑推动判断改变的证据。新规则要求董事会先与 GNSO 理事会对话，也要求董事会公开解释撤回决定。然而，两者之间存在第一次董事会行动，而规则没有要求在这次行动前先公开证据案卷。

这正是 GNSO 操作程序 v3.8 暴露的控制边界。把一个没有成文路径的空白变成正式程序，是实质进步。但行动后的透明说明，不能替代行动前可被检验的证据。

三个日期不能压成一个日期

GNSO 程序页面在 9 月 2 日更新，列出日期为 9 月 1 日的 v3.8。版本记录说明，合并文本纳入了 2026 年 5 月 21 日批准的附件 2《政策制定流程手册》和附件 5《GNSO 指导流程手册》，以及更早获批的附件 7；两个独立手册文件本身标注 5 月 11 日。除更新后的附件外，v3.8 的其他改动被明确描述为行政和编辑性质。

因此，5 月 21 日的理事会决议才是批准事件，9 月则是规则汇编的合并与公开事件。两者都不等于程序已被使用。已核查来源没有指出哪项建议目前正依照新程序被撤回。

2025 年战略规划会议报告提供了制度背景。董事会此前遇到已经采纳、后来又出现问题的建议，包括新通用顶级域后续程序的建议 20.6，而当时没有专门的撤回路径。这个历史解释了规则为何产生，却不能被写成 v3.8 的现行个案；本文也不评价建议 20.6 的政策是非。

新程序实际规定了什么

更新后的附件 2：PDP 手册第 16 节与附件 5：GGP 手册第 10 节采用几乎相同的顺序。撤回只应出现在有限且特殊的情形。一项建议已获董事会采纳、但实施尚未完成时，可以进入这条路径；一旦建议已经实施并生效，这条路径便不可用。

行动前，董事会应与 GNSO 理事会对话。最低要求包括：告知撤回意图、说明具体问题、交代理由与预期影响，并解释为何撤回是唯一或最佳选项。GNSO 理事会应有足够时间评估问题、要求进一步澄清。文本写的是“例如 60 天”，它提供判断尺度，却没有创设不可变的 60 天法定时钟。

实体判断包含两个环节。首先要有新信息或情势变化；其次，董事会还必须认定建议已不再符合 ICANN 或 ICANN 社群的利益。仅有变化并不足够，仅抽象援引机构利益而不说明证据基础如何变化，也不符合成文测试的结构。

首次表决门槛取决于建议最初在 GNSO 获得的支持。如果建议曾获 GNSO 超级多数支持，撤回需要三分之二董事会票；如果当时不足超级多数，董事会简单多数即可。

董事会执行撤回行动时，必须用一份 Board Statement 向 GNSO 理事会说明判断理由。这份说明及随附材料必须公开。之后，GNSO 理事会审阅说明、与董事会讨论，并决定确认还是修改原建议。由此形成的补充建议再回到董事会，后续门槛同样依照 GNSO 支持强度而定。

所以，这不是把单方面终局决定伪装成咨询。GNSO 仍保有正式回应权，董事会也必须处理补充建议。更窄、更准确的问题是证据时序：第一份被明确要求公开的材料，出现在第一次董事会行动之后。

公众意见提出的事前参与没有成为硬步骤

该程序经过了公众意见征询。征询期从 2025 年 11 月 20 日持续至 2026 年 1 月 22 日，共收到十份提交。意见摘要报告显示，参与者普遍支持设立一条罕用且有护栏的路径。

部分意见确实改变了最终文字。参与者建议把董事会“可以遵循”改成“应当遵循”，最终手册采用了后者；他们还建议在“新信息”之外加入“情势变化”，最终规则也吸收了这一点。

另一些要求没有成为强制程序。多名参与者建议，在撤回流程结束前设置有限的公众或社群征询期。注册商利益相关方组织、注册局利益相关方组织与 Tucows 支持强制征询相应实施审查团队；注册局一方还建议在可行时咨询原工作组。获批手册没有要求这些步骤。

不能据此断言未来程序会秘密进行。GNSO 理事可以征询各自社群，董事会可以提前公开材料，双方也可以主动邀请实施团队提供意见。证据只支持一个更克制的结论：这些开放动作属于选择，而不是第一次行动的成立条件。

“实施完成”是一条没有指定证明人的界线

资格界线表面上很清楚：一边是“实施尚未完成”，另一边是“已经实施并生效”。现实中的项目却很少整体越过同一条线。合同文字可能已经定稿，工具仍在开发；生效日期可能已到，迁移仍未完成；实施团队的问题仍未关闭，或者合规执行被延后。一项建议还可能属于一个相互依赖的建议包，而董事会只准备撤回其中一部分。

两本手册没有指定谁负责证明实施状态，也没有要求统一的资格证明文件或最低证据集合。这是文本层面的缺口，不是对 ICANN 内部工作缺失的指控。但它会影响治理，因为状态分类本身决定董事会能否使用这项特殊权力。

过早宣布“已经生效”，可能在新证据确有分量时封死撤回路径；把“尚未完成”维持过久，则可能允许董事会在注册局、注册商、申请人或用户已合理依赖既有规则后继续使用撤回路径。事后 Board Statement 能记录选用了哪种分类，却不能保证受影响方在首次表决前纠正它。

首次表决前应打开撤回案卷

缺少的工具是一份有边界、可版本化、并在首次董事会行动前公开的撤回案卷。它不必成为无限期咨询，也不必公开受法律特权或安全要求保护的细节。它只需把行使的权力与决策时点可用的证据绑定起来。

案卷至少应列明启动通知与时间、纳入范围的每项建议、范围外依赖项、原采纳决定及门槛、当前实施阶段，以及负责证明该阶段的指定保管人。资格证明不应只写一个状态词，而应指向带日期的证据快照。

案卷还应保存新信息或情势变化的来源、所称影响和已评估替代方案；董事会问题与 GNSO 回答应保留稳定版本；实施审查团队、原工作组和社群应有一个截止时间明确的证据提交渠道。敏感材料可以受限，但公开层仍应说明它的存在、保管人、受限理由与对判断的影响。

行动后，同一案卷继续承载首次表决、Board Statement、双方讨论、补充建议与董事会最终处置。纠正内容应作为新记录追加并指向被取代版本，而不是静默改写首次决策所见的材料。

这套案卷不是 ICANN 已经承诺的设计，而是我的编辑建议。它沿用 The Policy Mirror 对权力实际位置的追问、Running-Code Primacy 对可观察执行的要求，以及 Reality, Not Advocacy 区分事实与机构自述的纪律。

v3.8 正确承认：一项采纳决定不能让后来的事实消失。下一步同样朴素——不要让行动后的公开说明冒充行动前的可质疑性。证据窗口应在第一次决定仍能改变时打开。

来源