ICANN 的 21 天 SSE 异议期应保存哪些记录？

摘要

SSE 决定到达后，团队自然会问：这个结果是否正确？但在回答之前，时限已经开始运行。第一步应当保存打开时限的事件，而不是等待法律、技术和业务团队形成统一意见。

ICANN 的公开 FAQ 表示，申请人在收到评估结果通知后的 21 天内，如果认为评估小组出现事实、程序或系统错误，可以提出异议。《申请人指南》7.10.4 节使用了另一种可操作表述：异议可在 SSE 决定传送之日起 21 天内提出。

这两段材料都说明窗口很短，但指向两个可观察时间点。稳妥做法是同时保存 ICANN 显示的传送时间，以及申请人控制的邮件或门户系统实际接收、展示通知的时间。时区、消息标识、渠道、门户事件和首次访问记录也应一并保存。

同时保存并不意味着接收时间必然延长期限。它只让组织能够按更保守的依据计算截止日，并在日后解释计算过程。

决定很快会被改写成工单、演示文稿或管理层邮件。这些材料有助于协作，却不能成为事实原件。第一天记录应保存决定或报告的原始字节、文件名、下载路径和 SHA-256 完整性哈希，同时记录被评估字符串、相关变体、结果类别、决定标识和适用的指南版本。

哈希的证明范围很窄：它能说明后来审阅的文件与最初保存的文件一致。它不能证明 ICANN 在某个时点传送了文件，也不能证明决定正确。传送事实需要消息或门户日志；决定正确性则需要在规则允许的范围内提出理由。

《申请人指南》规定，异议按“明显错误”标准评估。除非原评估小组没有遵循既定程序，或没有考虑、征求必要的重要证据或信息，异议服务提供者必须接受原决定。FAQ 还明确提到事实、程序或系统错误。

因此，第一轮内部审查不应只写“我们不同意”。每个候选理由都应形成独立条目：被质疑的决定段落是什么，哪项事实前提可能错误，哪道程序可能遗漏，什么重要信息没有被考虑，或者什么系统行为可能影响结果。

每条理由都要连接适用规则和材料来源。没有来源的理由仍是假设；没有对应理由的材料只是一份档案。未验证事项可以保留，但必须被标记为待核实，不能伪装成已确认事实。

第一是传送事件，包括发送方、接收目标、渠道、时间、时区和消息标识。第二是实际收到的通知，包括受控系统接受或展示通知的时点及首次访问记录。第三是权威决定原件，包括文件、哈希、结果、字符串和稳定引用。

第四是规则快照：适用指南版本、具体章节及用于理解期限和理由的官方 FAQ。第五是理由与证据账本：每个潜在错误单独成行，记录决定段落、规则、证据、来源、负责人和核验状态。第六是期限与提交记录：保守截止日、内部批准、最终提交字节、提交哈希、发送时间和回执。

六个对象应通过稳定标识相连，但不应被合并进一个不断覆盖的文档。分析可以变化，原始通知和决定不能变化。

指南表示，SSE 小组将在申请人提交异议后的 30 天内传达结论。提交事件由此打开第二条链：提交文件、接收回执、预期结论日、过程通信及最终结论。

如果发现事实、程序或系统错误，SSE 将在考虑异议结论的情况下重新评估；如果未发现错误，原结果维持。无论进入哪一分支，第一天记录都能说明最初异议针对什么、依据什么，以及后续结论是否回应同一组理由。

官方材料确立了期限、审查标准、结论时间和条件后果，却没有规定本文建议的六对象数据结构，也没有提供 2026 年异议成功率、改判率或足以预测结果的已完成申请案例。

哈希、截图或内部审批也不会自动使异议及时或有说服力。它们用于保存来源和组织记忆，不能替代正式提交规则或专业判断。

Heng Lu doctrine 在这里只是规范性视角。它关于稳定身份、来源和可核验状态转换的要求支持保留完整记录链，但不能作为 ICANN 行为或小组结论的事实证据。

真正的治理测试是：负责人更换后，新接手者能否不用依赖口头记忆，回答组织收到什么、何时收到、适用哪条规则、主张何种错误、最终提交了哪些字节。