摘要

  • ICANN 2026 年《申请人指南》给申请人 21 天时间挑战字符串相似性评估决定，并要求挑战结论通常在提交后 30 天内传达。
  • 如果确认存在事实、程序或系统错误，SSE 将在考虑挑战结论后重新评估；错误获确认本身并不保证新的评估一定通过。

设想申请人收到一份挑战结论：它确认原先的字符串相似性评估确实有错。直觉上，这像是原决定已被推翻。按照 ICANN 公布的程序，它其实只是打开了下一道门。

挑战结论回答的是“原评估是否存在符合条件的错误”。重新评估回答的则是“考虑这些结论之后，正确的 SSE 结果是什么”。这两个问题有关联，却不是同一个问题。

如果把原决定、挑战结论和重新评估决定当成三份互不相干的文件，外部观察者很难判断错误是否真正得到纠正。若把它们保存为一条连续的决定链，申请人、评估人员和社群就能看到变化来自何处，同时不会把“确认错误”误读成“自动通过”。

规则规定的是一段流程，而不是一次性的上诉事件

2026 年《申请人指南》第 7.10.4 节对挑战设定了明确边界。ICANN 向申请人传达评估小组的决定后，申请人可在 21 天内提出挑战。评估挑战服务提供方按照“明显错误”标准审查挑战。根据指南，除非评估小组未遵循既定评估程序，或未考虑、未索取必要的重要证据或信息，否则挑战服务提供方应接受原评估决定。

指南还设定了第二个时钟：挑战提出后，评估小组应在 30 天内传达挑战结论。

ICANN 的公开 FAQ 用更简洁的方式描述理由：如果申请人认为评估小组犯了事实、程序或系统错误，就可以提出挑战。FAQ 与指南在后果上是一致的——一旦错误得到确认，字符串相似性评估将重新进行。指南还增加了关键的连接条件：重新评估必须考虑挑战的结论。

因此，流程可以拆成五个不同事件：

  1. ICANN 传达原始 SSE 决定；
  2. 申请人基于所主张的事实、程序或系统错误，在 21 天内提出挑战；
  3. 挑战程序形成结论，指南要求通常在提交后 30 天内传达；
  4. 若确认错误，SSE 依据挑战结论重新评估；
  5. 重新评估形成新的实质决定。

第四步与第五步不能合并。确认错误是重新考虑的入口，并不是新的实质结果。本文查阅的官方材料没有说，确认错误会自动把未通过变成通过、自动解除争用集合，或预先决定任何其他结果。

“明显错误”使挑战问题保持狭窄而具体

指南采用“明显错误”标准，意味着挑战不是无限制的第二次完整评估。列明的条件关注既定程序是否得到遵循，以及重要证据或信息是否得到考虑或索取。ICANN FAQ 还明确提到事实和系统错误。

这种边界并不会让挑战变得无关紧要。它使申请人必须更精确地表达问题：不是简单要求另一个决定者采用不同判断，而是指出足以重新打开评估的缺陷。

同样的精确性应延伸到记录。挑战应稳定引用原决定，逐项列出所主张的错误，并把相应证据与每一项错误关联。挑战结论应说明哪些主张得到确认、哪些未得到确认。重新评估记录则应表明，已确认的结论确实成为重新评估的输入。

这是治理建议，不是对 ICANN 当前公开数据格式的描述。官方材料确立了程序上的连接，却没有规定本文建议的公开数据结构。

确认错误与作出新决定回答的是两个问题

挑战结论问：第一次评估是否受到符合条件的错误影响？

重新评估决定问：在考虑挑战结论后，正确的 SSE 结果是什么？

区分两者可以避免两个相反的错误。第一种错误是把错误获确认当成申请人自动获得实质胜利，这超出了官方材料的承诺。第二种错误是公布新的决定，却不显示它与导致重新评估的结论之间有什么联系，从而无法检验错误是否真正得到处理。

一套衔接良好的记录可以同时保存两项事实：挑战在一个或多个错误理由上成立；重新评估仍然独立负责最终 SSE 结果。

未确认错误的路径说明状态标签为何不够

指南也明确规定了没有发现事实、程序或系统错误时会发生什么：原 SSE 结果继续有效。

但“继续有效”可能对应不同的运营状态。对于无错误规则涵盖的特定相似性或 Blocked Name 结论，申请不再继续。若结论是与另一个本轮申请字符串相似，申请仍留在争用集合中。

这说明，仅记录“挑战被拒绝”是不够的。拒绝解释了为什么原决定保留，却没有单独说明申请已经停止，还是仍在争用中。运营后果仍须回到原决定及其具体规则中读取。

同理，确认错误后的“挑战成立”也是一个过渡状态，而不是最终申请状态。

五个连接点可以让重新评估可追踪

最小而有用的决定链应连接五类对象：

  1. 原始决定：稳定标识、传达时间、被评估字符串和结果依据；
  2. 挑战提交：提交时间、错误理由、所引程序和证据；
  3. 挑战结论：稳定标识，以及每项理由被确认或否定的结论；
  4. 重新评估输入记录：实际交给评估人员的挑战结论、适用规则版本和评估材料；
  5. 新决定：稳定标识、结果、时间，并明确引用原决定和挑战结论。

这不要求公开受保护材料。敏感证据可以继续受访问控制，同时公开其存在、完整性哈希、提交时间及其在程序中的作用。重点不是公开每一个字节，而是保存各次决定之间的关系。

若重新评估结果没有变化，记录应能说明挑战结论确已被考虑，以及为什么它没有改变实质结果。若结果改变，同一条链也应能显示，是哪一项输入或程序纠正带来了差异。

申请人在第一天应保存什么

21 天期限从决定被传达时开始。申请人应把通知作为一个有时间戳的事件保存，而不只是下载文件并设置日历提醒。

第一天的记录至少应包括：决定的稳定标识和准确传达时间、被评估字符串、SSE 结果类别、适用指南版本和评估材料、分开的事实/程序/系统错误清单、每项错误的证据与来源信息、从传达事件计算出的截止时间，以及负责授权挑战的内部责任人。

这些记录不会替申请人决定是否挑战。它们只是确保申请人能在短时间内基于完整材料作出决定。

挑战提交后，申请人应把提交标识、实际提交字节、回执和时间保存在一起。挑战结论到达时，应逐项映射回挑战主张，而不是把它作为孤立信件归档。若进入重新评估，还应保存能够证明挑战结论已进入新评估的引用或记录。

治理检验的核心是连续性

流程透明度不取决于公布了多少份文件，而取决于获授权的观察者能否沿着状态变化理解决定，而无需从文件名和日期猜测关系。

官方材料证明了有边界的挑战程序、明确的时间窗口和有条件的重新评估。它们没有提供挑战成功频率、重新评估改变结果的频率，也没有提供任何具体 2026 年申请的实证情况。本文不作这些推断。

可以确定的结论更窄，却已足够重要：确认错误和纠正结果是两个不同动作，可信的系统应把它们连接起来。

Heng Lu doctrine 在这里可以作为规范性视角，但不能冒充事实证据。它强调来源、稳定身份和可复核的状态转变。用于 SSE 挑战时，这意味着不抹去原决定，不把挑战结论误当成最终结果，并让新决定保留完整沿革。

来源