摘要

  • 从9月1日起，ICANN的Open Data Platform及API将不再可用，旧网址会跳转；新页面允许任何人免登录下载现有CSV，依赖旧平台的用户须在截止日前更新流程。
  • “现在能否下载”与“以后能否证明下载了哪一版”是两项不同测试。公开的交接映射和发布凭据，可以把旧数据集身份连接到现址、定义版本、准确字节与更正链。

9月1日到来时，ICANN的公共数据会同时发生一次开放和一次收缩。

开放的是入口。新页面列出的CSV无需账户、API密钥或登录即可取得。收缩的是接口。原Open Data Platform和API将停止提供服务，依靠旧接口的程序必须改变。

ICANN并未突然行动。它在6月15日公布新页面，保留旧平台至8月底，让用户探索新入口并调整流程。8月27日又发出提醒：8月31日之后平台不再可用；从9月1日起API也不再可用，原网址将跳转到Open Data Initiative页面。ICANN给出的理由是简化访问，同时降低维护、数据存储和备份需求。

这些事实足以排除“秘密关停”的叙事，却还不足以形成一份完整的交接记录。公告告诉用户何时切换、从哪里重新开始；本文查阅的页面没有逐项说明每个旧目录身份、API依赖和功能在新环境中的明确去向。

免登录下载是实质改善

当前Open Data入口明确列出两类数据：Domain Name Marketplace Indicators（DNMI）和Security Response Waiver Requests（SRW）。链接指向可直接下载的文件。

DNMI Version 1.1包含16项仍在维护的指标，分为市场竞争、市场稳定和消费者信任三组。各组页面把年度更新的活跃指标和Version 1.0留下的归档指标分开列示。SRW页面则提供一个年度CSV，涵盖收到请求数量、涉及的gTLD和域名、请求提交时点以及豁免处理结果等五类衡量。

对于偶尔使用数据的读者、小型运营团队和记者，这种结构有明显好处。完整CSV可以用普通浏览器取得，用常见工具查看，也容易保存在本地。为了拿到公共文件而注册账户、生成密钥、处理配额，并不会增加数据本身的公共价值。

本文抽查的两个CSV在核验时均能正常返回。服务器响应包含Last-Modified和ETag等交付信息。这些字段有助于缓存和发现变化，但本文查阅的页面没有把它们定义为ICANN认可的发布身份，也没有用它们解释一项更正为何发生。

因此，访问解决的是即时问题：我现在能不能取得文件？可复现性解决的是长期问题：我取得的究竟是哪次发布、覆盖哪个时期、采用什么定义，后来又由哪条记录更正或取代？

旧平台承载的不只是下载

ICANN在2018年采购Open Data Platform时，公开目标包括开放许可、开放API、可靠且机器可读的数据，并把平台称为ICANN org与社群开展分析时可以使用的源系统。

旧平台的About页面进一步提出，数据应当可访问、可使用、及时、完整、可比较且可互操作，并能改善治理和社群参与。账户功能还包括保存分析、订阅数据更新、生成API密钥和查看配额。

这些能力没有一项要求ICANN永久保留同一家供应商。独立托管的平台有运营成本，机构可以选择更轻的技术路线。API也不天然比CSV更“开放”：需要获取完整快照时，一个简单文件可能比依赖服务器行为的复杂查询更容易保存。

问题在于接口改变会重新分配保存责任。API用户可能依赖数据集标识、字段选择、过滤、分页、通知或者机器可读目录。CSV用户需要知道同一路径上的文件究竟没有变化、形成新发布，还是因错误被替换。如果没有机构发布的说明，用户只能各自推断。

技术产品可以退休，数据身份不应随产品一起失忆。

旧目录四类，新入口两行，不能直接作减法

旧平台首页曾显示四个目录主题：DNMI、Identifier Technology Health Indicators（ITHI）、Registry Activity Reports以及Registrar Transaction Reports。当前Open Data入口显示DNMI和SRW两行，并说明未来会在可用时增加更多数据集。

四和二之间的差值，不是“数据消失”的证据。ICANN当前的Monthly Registry Reports页面仍可访问，并按顶级域名提供报告。ITHI也有独立仪表板，展示现有和历史指标。

能够成立的判断更窄：仅凭交接公告和当前入口，旧目录中的每一类并没有得到一张可直接核对的去向表。用户必须在不同页面之间重新发现关系。

Registry Reports的历史说明了这种关系为何重要。2021年，ICANN把Registry Functions Activity Reports和Per-Registrar Transactions Reports迁入Open Data Platform，并明确要求运行自动下载脚本的用户改用Open Data API。遵循了当年指引的人，现在需要再次改造同一条流程。

这并不能证明任何脚本已经失败。它证明的是依赖并非想象，而是ICANN公开建立和承认过的使用方式。

一张交接表可以诚实记录不同结果：某类迁到CSV页面，某类留在专用研究仪表板，某类回到主站报告库，某项查询能力没有等价替代。每一种处置都可能合理。让用户自己猜哪一种适用，才是连续性风险。

跳转保留路径，却不能标明版本

旧首页跳转到新入口，可以帮助人找到方向。它无法还原旧API查询的含义，也不能声明某个具体字节序列就是某期正式发布。

假设研究者引用当前RC 2.1文件。要使结论可复核，还需知道覆盖期、指标定义版本、发布时间、预期摘要值、行数，以及后来是否有更正取代了它。服务器的时间和实体标签可以提示缓存变化，但除非发布者明确赋予含义，它们并不是一份解释更正理由的公共决定记录。

这不需要另建一座复杂平台。最小方案由两部分组成：交接映射与发布账簿。

公开字段 回答的问题
旧数据族、目录标识和API路径 正在迁移的是哪项依赖？
当前权威地址与责任团队 现在到哪里取，谁负责？
处置状态与功能差异 是迁移、独立保留、合并、归档还是终止？
覆盖期、更新频率和定义版本 数值具体表示什么？
发布时间、预期摘要值和行数 哪个准确对象构成这一版发布？
更正与取代关系 如何保留旧版并解释新版？
许可、聚合边界与联系渠道 如何复用、受何限制、向谁质疑？

地址说明“在哪里”；发布凭据说明“机构对哪一个对象负责”；更正关系说明“记录如何变化而没有把旧版抹去”。这三件事不能由一次HTTP跳转替代。

公共数据需要可携带的机构记忆

对这次变更作出公平评价，不能把API美化，也不能把CSV贬低。免登录是真改进。降低维护成本可以是正当选择。本文查阅的证据也没有证明现有文件错误、不完整，或者旧数据类已经消失。

真正的问责测试是：当交付产品改变时，数据的公共身份是否还能继续。

一层轻量、供应商无关的记录，可以让ICANN将来再移动主机、更换存储或增加新接口，而无需重置历史。程序按照公开处置更新，研究按照命名版本引用，更正能够指向原发布而不是悄悄覆盖。

ICANN已经给出日期、新入口和总体理由。补上一张交接凭据，就能把“平台关闭”从一个需要猜测的断点，变成一次可以核验的连续性事件。

来源

  1. ICANN公共数据页面更新，2026年8月27日
  2. ICANN发布新的公共数据页面，2026年6月15日
  3. ICANN Open Data Initiative
  4. Domain Name Marketplace Indicators
  5. DNMI：Robust Competition
  6. DNMI：Marketplace Stability
  7. DNMI：Consumer Trust
  8. Security Response Waiver Requests
  9. 原Open Data Platform首页
  10. 原Open Data Platform的About页面
  11. ICANN 2018年Open Data Platform采购公告
  12. ICANN 2021年Registry Reports迁移公告
  13. 当前Monthly Registry Reports页面
  14. 当前ITHI仪表板
  15. DNMI RC 2.1示例CSV
  16. SRW M1-M5示例CSV