摘要

  • GAC 成员或观察员无需取得 GAC 共识，即可在字符串确认日后的 104 天内提出预警。
  • 预警对申请没有直接影响，但申请人仍须决定沟通、提出变更、维持原申请或退出。

GAC 成员预警在 2026 轮次中处于一个重要的中间位置：它比一般政治关切更正式，却不是否决、拒绝，也不是 GAC 共识建议。ICANN 政府咨询委员会的成员或观察员可以用它指出一项被视为潜在敏感或存在问题的申请。

关切可能涉及国家法律或其他敏感问题，并须在通知中具体说明。预警应包含提交理由的书面解释、申请人可能如何处理关切，以及用于沟通的联系方式。发出预警不需要 GAC 达成共识。

104 天内的信号，不是直接决定

预警应在字符串确认日后的 104 天内提交。ICANN 表示，收到后会在切实可行的情况下尽快通知申请人。

《申请人指南》的边界十分明确：预警只是一份通知，对申请没有直接影响。不过，评估专家组可以考虑它；它也可能预示该申请后来会面对 GAC 共识建议或异议，但这两种后续机制都不以事先存在预警为必要条件。

这一区分可以避免两个相反错误。把预警当作无关紧要的通信，会低估一项正式风险信号；把它当作最终公共政策决定，则赋予了它并不具有的效力。

申请人仍有四条响应路径

ICANN 鼓励希望继续的申请人尽早与提出关切的一方直接沟通。申请人也可以尝试通过申请变更请求处理问题，可以选择不采取行动而按原申请继续，也可以退出；退出时适用相应退款时间表。

这些是选择，而不是结果保证。不沟通可能会、也可能不会导致 GAC 共识建议；沟通本身同样不能保证避免后续建议或异议。因此，记录应分别保存收到的关切、选择的响应、支持该选择的证据，以及后来实际发生的程序。

并非每项政府关切都是预警

GAC 成员也可使用向公众开放的渠道，例如申请评论论坛，或直接与申请人联系。通过这些渠道表达的关切本身不构成 GAC 成员预警。是否属于预警取决于既定程序，而不只取决于发言者身份或问题严重程度。

这对问责很重要。团队不应把公开评论、非正式沟通、预警、异议和 GAC 共识建议合并成一个笼统的“政府反对”状态。它们有不同来源、程序效力和下一步骤。

建立响应记录，但不要制造确定性

有用的控制面是一份五栏响应表：明示关切、其事实或法律依据、提出方描述的缓解方式、申请人选择的路径，以及沟通或变更请求的证据。它应保留日期和责任人，但不能仅凭对话就宣称问题已经解决。

这份响应表是 BTW 编辑建议，不是 ICANN 提交要求。ICANN 规定了预警程序并描述了响应选项，但未要求采用这份内部文件。预警本身也不能证明申请将被拒绝、继续或最终获得委派。

来源