摘要

  • ICANN 董事会于 2026 年 3 月 12 日通过第 2026.03.12.01 号决议，要求立即采用更新后的流程；GNSO 官网确认该流程已生效。
  • 2013 年版本要求工作人员在正式收到团体已批准的修订案后 10 个工作日内向相应董事会委员会提交报告，并在公众意见期结束后 30 个日历日内提交意见摘要。
  • 旧版本还规定：若两次董事会会议后仍无法作出最终行动，应说明原因与预计时间；四次会议、或合计六次排定会议后，修订案视为生效。
  • 2026 年版本改为由 ICANN 组织与有关团体协商“适当时间表”，并说明接洽所需时间可因文件复杂度和问题而异；旧有的日数与会议次数兜底均未重现。
  • 四份公众意见都总体支持更新，但注册商利益相关方团体明确要求保留审查时限。ICANN 组织最终选择逐案安排，而不是写入统一时限。
  • 最小化、可版本追踪的公开时间回执，可以让逐案弹性可审计，却不必把所有章程塞进同一截止日，也不必公开受法律特权保护的讨论。

旧流程有三层计时，而非一个总截止日

这次变化可以直接从两份正式文件中验证。2026 年 3 月文件明言，它取代董事会于 2013 年建立的流程。董事会在 3 月 12 日立即批准实施，目前 GNSO 的利益相关方团体与社群页面也把新版列为现行规则。

第一层计时发生在团体内部批准之后。根据 2013 年流程，ICANN 工作人员正式收到修订案后，应在 10 个工作日内完成分析，把团体提案与一份列明财政或责任问题的报告交给相应董事会委员会。这个期限不等于批准，却把“工作人员尚未完成报告”变成一个可检验的状态。

第二层发生在公众意见之后。意见期结束，工作人员须在 30 个日历日内向委员会提交摘要。它没有规定董事会何时一定表决，但规定了下一份公共决策材料何时应出现。

第三层约束董事会端的不行动。相应委员会应在下一次可用机会审查材料。若两次会议后仍无法完成最终行动，董事会须向受影响团体说明障碍，并给出最佳时间估计。若四次会议后仍不能行动，或者已经经历合计六次排定会议，修订案即视为生效。

旧制度并非完美的端到端服务承诺。本次查阅的证据也不能证明这些期限在十余年中总是现实、总能被遵守，或“自动生效”在复杂法律问题上永远安全。它的制度意义更窄：时间不是隐含的内部管理变量，而是流程文本中可见、可核对的属性。

新流程把时间移入个案关系

新版在更早阶段介入。利益相关方团体或社群开始修订时，应尽快通知 ICANN 组织支持团队，指定联络人，并可与 ICANN 组织共同制定适合该项工作的时间表。章程与操作程序模板把《ICANN 章程》、GNSO 操作程序及相关的问责工作流 2 建议带入起草。团体提出请求时，ICANN 组织可提前指出审查、治理和实施要求，以免问题等到成员表决后才出现。

团体依自身程序批准修订案后，ICANN 组织进行初审，辨识治理和法律方面的问题。若文件复杂或存在潜在问题，双方可以继续讨论；文本明确说接洽时间可能不同。ICANN 组织完成审查后，向适当的董事会委员会提交报告。委员会批准报告后启动公众意见，随后审阅意见摘要并向董事会提出建议。

最终权力没有变成工作人员的自由裁量。董事会仍须以简单多数承认修订案，或以三分之二多数拒绝并说明具体理由。承认构成批准，之后由相关团体正式采用并公布文本。

变化发生在各道关口之间。新版没有 10 个工作日的组织报告期限，没有 30 个日历日的意见摘要期限，也没有“两次会议后解释”和“四次或六次会议后视为生效”的规则。董事会决议的理由写得更清楚：适当时间表“不受流程约束”。时间从共同默认规则，变成 ICANN 组织与具体团体之间的一项个案安排。

这并不自动意味着问责倒退。一个标点或选举条款的修订，与把利益相关方团体注册为美国或其他法域法律实体，面对的税务、责任和治理问题并不相同。ICANN 解释说，文件日益复杂，需要更深入的审查；提前接洽还可能在成员表决前发现冲突，从而减少返工。因此，文本中公共时钟更少，并不排除某些个案实际上更快。

“四份支持”并不等于对时限设计毫无异议

公众意见记录需要同时保留两件事。四份提交都总体支持更新，董事会把反馈概括为支持并无不当。但是，对整套方案的支持不等于接受每一项设计。

注册商利益相关方团体欢迎提高透明度和提供模板，随后专门反对删除 ICANN 审查时间。它认为，没有预期周转期会使后续步骤含糊，也削弱及时批准的保障。它并未坚持旧的数字神圣不可变；如果实际需要，它愿意讨论延长现有期限。

ICANN 组织的摘要没有抹去这点。其回应不是说担忧不存在，而是选择了另一种制度答案：不在新流程设置统一时间，而由 ICANN 组织与每个 GNSO 团体为各案建立适当时间表。董事会组织效能委员会在建议通过前也重复了同一立场。

因此，准确表述不是“社群一致同意取消时限”。更精确的状态是：四方支持提前接洽、模板和流程更新；其中一方要求共同的时间保障；ICANN 决定采用逐案时间。

协商时间也应有公开界面

新版描述了可以协商的时间表，却没有要求用统一公共记录呈现它。文件没有要求保密，也没有证据显示 ICANN 打算让审查无限延伸。可验证的缺口只是：现行流程没有告诉读者到哪里查看最初时间表、当前阶段、延误责任、变更前后的估计和下一行动。

每项章程修订可以附上一张精简的时间回执，内容包括：

  • 团体名称、章程修订标识和不可变的文件版本；
  • 通知 ICANN 组织、团体内部批准和提交审查的日期；
  • 团体联络人，以及当前行动由哪个机构负责；
  • 各阶段协商窗口和最初的下一决策估计；
  • 当前阶段、进入日期，以及补充信息、暂停或退回起草状态；
  • 每次调整的日期、旧估计、新估计和可归责的理由类别；
  • 下一责任行动和复核节点；
  • 公众意见的开始、结束和摘要发布日期；
  • 委员会建议、董事会处置、正式采用和公布日期；
  • 最后核验时间与完整版本历史。

理由可以保持粗粒度：文件复杂、需要额外治理审查、法律实体问题、团体申请重新起草、依赖其他程序、处理公众意见或董事会议程安排。无需公开法律意见、保密税务材料、个人联系方式或闭门讨论内容。公开的是程序状态，而不是把外界变成法律团队的一员。

这张回执也不应把每个预测变成不可变承诺。估计代表当前规划，后来事实可以改变它。问责要求的是公开修改、标明谁提出新估计，并保留旧状态。可调整的时间表与不可见的时间表，差别就在这里。

Heng Lu 的“最小初始规范”原则为回执划定边界。共同层只需记录所有案件都需要的最少项目：状态、责任人、日期、变更理由和下一行动。某项法律或治理问题到底需要多久，仍由实际承担工作的人决定。薄而可验证的公共层不会把协调膨胀成中央许可，却能让地方判断留下证据。

证据没有证明什么

已查阅材料没有指出任何一项 2026 年新流程下的章程修订已经逾期。因此，不能据此声称当前存在积压、恶意、俘获或违约。材料也没有提供足够的历史绩效数据，用来判断 2013 年的期限在每个个案中表现如何。

提前咨询可能让新版更快；团体也可能自行公布时间表；ICANN 还可能增加说明材料。应以第一批完整个案检验这些可能，而不是仅凭规则文本预判结果。

公开回执同样不会改变法定权力。团体成员依自己的程序批准；ICANN 组织进行治理与法律审查；相应董事会委员会管理进入公众意见与提出建议的路径；董事会承认或拒绝。时钟本身没有表决权，也不能使有缺陷的文本自动正当化。

已确认的变化比丑闻指控更克制，却也更值得监测：ICANN 把时间从共同默认规则移入逐案协调。下一道问责题是，这种协调是否足够可见，让成员和公众能够区分正在进行的审慎判断与没有责任人的停滞。

资料来源

  1. ICANN：2026 年 3 月 GNSO 利益相关方团体与社群章程修订流程
  2. ICANN GNSO：2013 年章程修订流程
  3. ICANN 董事会：2026 年 3 月 12 日通过的决议
  4. ICANN 董事会：2026 年 3 月 12 日会议记录
  5. ICANN：更新流程的公众意见程序
  6. 注册商利益相关方团体提交的意见
  7. ICANN：公众意见摘要报告
  8. ICANN 董事会组织效能委员会：2026 年 2 月 23 日会议记录
  9. ICANN GNSO：利益相关方团体与社群
  10. ICANN 章程
  11. Heng Lu：最小初始规范、未来决定本地化与自愿采用