摘要

  • 2026年5月12日公布的《注册数据政策》规定：经过认证的紧急请求须在两小时内获得收件确认，通常须在24小时内得到答复；只有在例外情形下才可说明理由并延至最迟72小时。
  • 答复可以是提供所请求的非公开注册数据，也可以是有理由地全部或部分拒绝。计时规则不会替代实质审查，不会排除适用法律，而且在身份认证机制生效之前还不会约束签约方。

假设一份格式完备的请求在14时抵达。到16时，收到请求的注册商或注册局运营方必须确认收件。通常到次日14时，请求人就应得到答复。若确有例外情形需要更多时间，接收方也必须在同一个24小时窗口内发出通知，说明原因和预计答复时间；最终期限不得超过收件后72小时。

这组时间点听起来像一份紧急披露令，但它并不是。每一个时限约束的是程序中的一步，而程序的结果仍可能是交付数据，也可能是有理由的拒绝。

首先要通过一道很窄的入口。《注册数据政策》第3.8节把紧急请求定义为合法披露请求的一个子集。请求必须来自“经认证的请求人”，并涉及对生命、严重人身伤害、关键基础设施或儿童剥削的迫在眉睫威胁，而且披露数据必须是应对该威胁所必需。仅在邮件主题写上“紧急”，并不能进入这条通道。

认证也不等于自行表明身份。第3.9节把经认证请求人限定为执法请求人或可信、主管机关，并要求其通过依ICANN共识政策实施的认证机制完成认证。新规则因而把公共讨论中常被混为一谈的两道控制分开：先确认请求人是谁，再判断这一具体请求是否必要、合法。

一般披露规则仍然适用。提交材料至少要列明请求人的身份与联系方式、所需数据项、请求人的法律权利、具体理由、善意声明，以及对所获数据进行合法处理的承诺。注册商或注册局运营方必须根据每一份格式完备请求自身的事实进行审查。

新时限改变的是这种审查可以悬而未决多久。普通披露请求依第10.5节，可在两个工作日内确认收件，并在确认后30个日历日内答复，例外情形除外。符合条件的紧急请求则适用第10.7节：两小时内确认，并在没有不当拖延的情况下于24小时内作答。

延期通道刻意设计得很窄。政策举出的例子包括影响基础设施可用性的不可抗力，以及涉及大量域名等导致的复杂性；法定假日、已安排的休假或出差则明确不能作为理由。运营方不能通过排班选择，把全天候紧急标准重新变成办公时间队列。

然而，“答复”并不等于“交付”。第10.6节保留了两种合规结果：运营方可以提供数据；也可以全部或部分拒绝，但须指明具体原因，并充分解释作出决定的路径。在适用时，还要说明如何权衡数据主体的基本权利与自由和请求人的合法利益。

这一边界很重要，因为对象是非公开注册数据。快速程序可以降低真实紧急事件中等待的代价，却不能为所有司法管辖区创造同一法律依据，不能证明每一个被索取的数据项都属必要，不能恢复公开WHOIS，也不会让ICANN变成决定警方调查的机关。收到请求的注册商或注册局运营方，仍对实质结论负责。

政策还有一个尚未闭合的重要开关。实施说明第11项规定，只有当ICANN全面实施一项建立请求人认证程序的共识政策后，第10.7节义务才会生效。ICANN在5月12日的公告中同样说明，紧急请求条款要等执法身份认证机制实施后才生效。7月23日更新的GAC意见状态记录也指出，24小时时限的执行仍在等待该机制。

因此，这是已经公布、但运营触发点延后的政策。若没有可信认证，快速通道可能奖励冒名者，或迫使运营方把最初几小时花在辨认请求人上；若没有答复时限，认证又只会产生一个可信但不具备紧急速度的队列。公开征询记录呈现的正是双轨方案：另行建设认证机制，同时以请求人已经完成认证为前提设定答复时限。

开关启动后，问责必须落在可检查的记录上，而不能只靠保证。第11.2节要求注册商和注册局运营方按正常业务记录惯例保留披露请求、收件确认和答复，以备ICANN审计等用途。这些记录可以证明两小时、24小时与72小时要求是否履行。它们本身不能证明披露或拒绝在法律上必然正确，却能让沉默变得可度量。

新时钟只有在被准确描述时才最有力量：它授权的是速度、程序结构和可审计的决定，而不是自动披露。

来源