摘要

  • ICANN 于 2026 年 5 月 12 日修订注册数据政策，为经认证的紧急请求写入两小时确认、24 小时答复和最长 72 小时的例外上限。
  • 同一政策的实施说明规定，第 10.7 节只有在 ICANN 完整实施建立请求者认证流程的共识政策时才生效。文本发布与义务启动是两个事件。
  • 执法机构认证机制意见组为概念验证提供技术和运营意见，并不制定政策。2026 年 12 月测试和 2027 年 3 月发布结论都不能自行成为生效日。
  • 认证只能证明限定范围内的请求者属性，不能自动证明紧急性、管辖权、合法依据、必要性或披露权。启动回执应把时钟与这些后续判断清楚分开。

政策先把时钟写清楚了

注册数据政策并没有把普通查询换一个“紧急”标签。第 3.8 节把范围限定为：请求来自经认证的请求者，涉及生命受到迫近威胁、严重人身伤害、关键基础设施或儿童剥削，而且披露数据对于应对该威胁具有必要性。第 3.9 节把经认证的请求者定义为，通过依照 ICANN 共识政策实施的认证机制完成认证的执法请求者或受信任、具备职权的机构。

第 10.7 节随后规定了可测量的流程。请求者还要单独声明请求属于上述紧急情形。注册商和注册管理机构在收到请求后两小时内确认；在没有例外的情况下，应当不受不当延误地在 24 小时内答复。如果发生例外，仍须在 24 小时内告知延期、说明理由和预期答复时间，最后期限不得超过收到请求后的 72 小时。

政策甚至排除了几种常见借口。不可预见且无法控制的事件，或一项请求包含大量域名而产生的复杂性，可能构成例外。法定假日、事先安排的休假和计划内出差则不构成例外。这不是一句“尽快处理”的愿望，而是由收件、确认、答复、延期通知和最终上限组成的责任链。

ICANN 的5 月 12 日公告说明了为什么需要明确时限。此类请求可能涉及生命、身体安全、关键基础设施或儿童保护，时间本身就是风险的一部分。用清楚的时钟要求合同方响应，具有正当的公共安全目的。

不过，看到大写的 MUST 并不能得出“现在已经可执行”的结论。

生效条件藏在时钟之后

政策的“紧急合法披露请求”实施说明写得很直接：第 10.7 节的义务，将在 ICANN 完整实施一项为请求者建立认证流程的共识政策之日生效。5 月公告也说，在执法认证机制实施之前，新语言不会生效。

这里至少有三个不同状态。规则可以被写入正式政策；要求写出时间线的 GAC 建议可以被认定已完成；对注册商和注册管理机构的合同义务仍可以等待前置条件。ICANN 的GAC 建议状态页恰好同时记录了后两项：董事会因 24 小时语言已经发布而关闭该建议项目，又注明该时间线的执行仍等待请求者认证机制。

这不是文字游戏。它影响谁可以合理依赖这条规则。执法机关如果只看到公告标题，可能认为 24 小时已经开始计算；合同方如果只看到实施说明，可能忽略将来的准备责任；合规系统如果抽取第 10.7 节而没有抽取生效条件，就会把尚未进入分母的案件标成违规。每一方都引用真实文本，却得到不同的运行状态。

还要避免另一个错误。注册数据政策整体已于 2025 年 8 月 21 日生效，等待认证的不是整份政策，而是 2026 年加入的第 10.7 节义务。准确的治理语言应同时说清：政策有效，紧急请求条款已发布，该条款的义务尚未满足专门的启动条件。

概念验证只能证明能做，不能替代授权

ICANN 已成立执法机构认证机制意见组，为通过注册数据请求服务（RDRS）或后继系统认证执法人员设计概念验证。公开时间表包括：2026 年 10 月展示 RDRS 线框变化，12 月开始概念验证测试，2027 年 3 月发布意见组结论。

这些节点能说明工程进展，不能自动改变政策状态。意见组页面明确说，它不是政策制定机构，不会提出政策建议。ICANN 的征集参与者文章把职责限定在技术和运营层面：如何同 RDRS 集成、验证哪些信息、流程如何设计、怎样保护隐私和安全、如何做数据最小化、透明度、问责、审计和日志。

一次成功的测试可以证明两个认证系统能够互操作，可以发现撤销信号传得太慢，也可以说明某个属性暴露了过多个人信息。它还可以检验用户体验和故障恢复。它不能凭工程结果取得“制定共识政策”的权力。

另一路由是 GNSO 的补充建议团队，它在未来标准化访问与披露体系中考虑请求者认可的政策问题。两条路线需要联络，因为工程会暴露政策选择；两条路线不能合并，因为意见组没有能力把选择变成合同义务。概念验证是证据，生效事件必须来自政策写明的权威链。

因此，12 月仍是测试月份，次年 3 月仍是结论月份。除非后续正式文件明确把某个事件认定为完整实施共识政策的生效点，否则这两个日期都不是第 10.7 节的启动日。

凭证证明“你是谁”，不证明“你应当得到什么”

共同认证机制的价值很现实。紧急请求到达时，注册商不必从头核实机构是否存在、经办人是否属于该机构、凭证是否仍有效以及持有人是否获准使用。可移植、可撤销、可审计的属性断言可以缩短前置检查。

问题在于，身份往往会借来不属于它的权力。一个人是经认证的执法请求者，不等于他陈述的威胁事实已经成立；机构具备某种身份，不等于对特定域名具有管辖权；凭证没有证明法律依据、必要性、比例性，也没有决定所有请求字段都应披露。

政策本身保留了这些关卡。请求者必须另行声明紧急情形。实施说明允许披露审查考虑管辖和适用法律。答复可以是全部披露、部分披露或说明理由的拒绝。第 10.8 节还允许针对滥用请求或请求者采取纠正措施。

所以，认证结果应该是一句范围很窄的话：某主体在某一时间、依据某个保障等级，具有列明的请求者属性。此后，合同方仍要决定请求是否符合政策和法律。认证机构不应同时判定紧急性、合法性和披露结果。否则，一个为了节省身份核查时间的技术层，会演变为跨司法辖区的事实裁判者，却没有相应的法律授权、救济和责任。

薄层设计更稳健：只验证各地独立决策者共同需要的最小属性；公开发行者、版本和保障等级；提供撤销、纠错和替换；尽量减少个人信息；然后把案件判断还给承担合同与法律责任的注册商或注册管理机构。

印度来函让权力边界变得可见

ICANN 首席执行官在 8 月 11 日给印度电子和信息技术部秘书的回函中，再次确认 24 小时要求的执行依赖适当的认证机制，并提到 GAC 公共安全工作组、执法代表和新意见组的相关工作。

同一封信还回应了印度提出的 15 日验证期和额外报告义务。回函没有把这些要求直接写成合同方责任，而是强调，新义务必须通过适当的政策或合同程序形成。根据 ICANN 章程，gTLD 政策开发和 PDP 管理属于 GNSO；首席执行官可以保障资源、支持进展和实施已经采纳的政策，却不能指定 GNSO 的优先事项或决定 PDP 结果。

这条链会让紧急事项显得缓慢，但它决定义务是否可执行。政府提出公共安全问题，GAC 提供建议，意见组测试技术，GNSO 处理政策，董事会依章程行动，ICANN 组织实施，合同方承担责任。跳过一个环节不会让权力缺口消失，只会把争议推到真正需要响应时。

认证项目的公开记录应当保留这张权力图。否则，一个测试界面可能看起来像是创设了只有政策才能创设的义务，一枚凭证又可能看起来像是批准了只有案件审查才能批准的披露。

启动回执要证明什么

Daniel Kade 提议，在第 10.7 节状态发生变化时，发布一份短小、可机读也可供人阅读的启动回执。这不是现行 ICANN 要求，也不是执法人员名册，更不是新的披露许可。

回执首先要绑定准确的政策版本和指纹、所依赖的共识政策、满足条件的正式事件、作出该事件的权威、日期、时间、时区以及规范来源。它还要列明适用的请求者类别、认证体系版本、保障等级、凭证具体证明的属性、撤销状态如何获取，以及哪些入口能启动时钟。

然后必须定义“收到”。是 RDRS 接受请求的瞬间，合同方系统接收的瞬间，还是工作人员打开案件的瞬间？重试产生两条记录时以哪一条为准？RDRS 故障后改走直接入口，时间如何继承？启动瞬间已经在途的请求适用旧状态还是新状态？24 小时很精确，如果起点含糊，精确只是表面。

回执还要绑定例外机制和合规分母：两小时确认、24 小时答复、24 小时内的延期通知、72 小时最终上限，以及不可作为例外的可预见人事安排。认证失败、格式不完整、启动前收到和有效认证后收到的案件不能混在一个统计池中。

最重要的是一条否定声明：凭证只证明列出的身份属性，不证明紧急性、管辖权、合法依据、必要性、比例性或披露权。回执可以公开规则和版本，但绝不能公开请求者个人、案件、目标域名或非公开注册数据。

衡量响应，不衡量“交出多少数据”

SSAC 的SAC122 摘要建议收集高层指标，包括请求数量、处理速度、垃圾或无效请求比例以及合同时间要求的完成情况。其较早提出的 30 分钟确认并未进入最终文本，最终的两小时规则应当优先；但按状态测量的思路仍有价值。

启动后，公开指标应从经过认证并由有效入口收到的紧急请求开始。认证失败、格式错误、未达到紧急标准、法律拒绝、补充信息请求、部分披露、完整披露、延期和系统故障要分别记录。确认时间、答复时间和最终解决时间也不能揉成一个平均数。

及时且有理由的拒绝，可能符合“响应”义务；最终披露也不能抹掉错过确认或答复期限的事实。披露率不是质量分数。把披露数量变成业绩目标，会把保护个人数据的判断扭成追求吞吐量的生产线。

证据边界

本稿依据注册数据政策、5 月公告、意见组页面与征集文章、GAC 建议状态、ICANN 对印度的回函、SAC122 和 RDRS 工作摘要。现有公开材料没有确定最终启动日期、身份服务提供方、联邦模式、保障等级、过渡规则或合规分母，也没有说 2026 年 12 月的概念验证会启动第 10.7 节。本稿不推断启动前无法通过其他合法流程处理紧急请求。启动回执和薄层认证是 Daniel Kade 的治理建议。

来源

  1. ICANN — 注册数据政策
  2. ICANN — 新增紧急请求要求公告
  3. ICANN — 执法机构认证机制意见组
  4. ICANN — 认证意见组征集参与者
  5. ICANN — GAC 建议状态
  6. ICANN — Kurt Erik Lindqvist 致 S. Krishnan
  7. SSAC — SAC122 执行摘要
  8. ICANN — RDRS 工作摘要