摘要

  • ICANN 董事会9月6日批准为2026年新 gTLD 轮次签订系统开发与支持合同，决议于9月9日公布。公开文本提到系统功能、及时事故响应、稳定性和关键业务流程，但供应商、金额及多项理由被删节。
  • 董事会5月3日曾把增强随时候命支持限定在六个月：从4月30日申请窗口开放，延续至当时预计10月30日完成字符串确认，随后支持团队预计缩减并回到正常工作时间。
  • 公开资料不能证明两次决定采用同一供应商、同一合同或同一范围；却足以确认先前存在一条应当留下结果的时间边界。
  • 一页不涉敏感信息的退出测试，可以按功能记录正常保障基线、ICANN 内部责任人、交接证据、尚未关闭的例外、决定日期和下一次复核。

第二次授权，让“如何结束”成为问题

9月6日通过的董事会决议授权总裁兼首席执行官或其指定人员，为2026年新 gTLD 轮次签订系统开发与支持合同并支付款项。公开的“鉴于”条款列出四项用途：开发系统功能、保证及时事故响应、维持系统稳定、支撑关键业务流程。相关财政影响已纳入 FY27 及未来预算。

决议没有公布服务清单、值班时段、事故等级、期限、金额或供应商。一整段背景和部分合同信息以“机密协商信息”为由隐去。董事会还认定，这是一项无需公开征求意见的组织行政职能。

这些事实本身不说明异常。大型技术项目进入处理阶段，需要专业支持很正常；公开漏洞、账户或实时升级路径反而会伤害安全。真正的问题来自它与5月3日决议之间的时间关系。

5月的文本批准延长增强型随时候命支持合同，并给出一条清楚的运行叙事：4月30日申请窗口开放，到当时预计10月30日完成字符串确认，这六个月需求和复杂度较高，需要在正常工作时间之外也能快速处理事故。六个月结束后，支持团队预计缩减，只在正常工作时段提供服务。

这不是一个具有合同约束力的服务承诺，却是一条可以核验的公共预期。它划出了异常保障的起点、理由和预期终点。9月的新授权因此把重点从“是否需要支持”移向“怎样确认支持能够降级”。是所有功能同时回到正常时段，还是部分环节保留例外？若时间表变化，谁更新边界？若增强值班成为新基线，哪个决定明确承认了这一点？

不能把资料中没有写出的关系补上。5月理由称，当时的供应商经2023年10月 RFP 选出，已经交付 RSP 和 ASP 系统，并推动 TAMS 开发。9月决议没有说它延续同一供应商、同一合同或同一范围。退出测试应当跟踪 ICANN 必须接住的功能和责任，而不是跟踪一项未经证实的商业身份。

申请关闭，不等于系统工作结束

8月12日申请窗口关闭后，ICANN 报告收到超过1,600份主要申请，其中超过1,100份还包含替换字符串申请。这个数字只表示申请件数，不是系统交易数、并发量、工单数或事故数，不能拿来推算值班人力。

它仍然说明，后续处理不是收尾杂务。申请人旅程还包括行政检查、Reveal Day、社区意见、异议与申诉、字符串评估、申请人与申请评估、争用解决、签约、技术接入及委派。窗口关闭只是系统从接收材料切换到处理材料。

ICANN85 会前状态报告进一步展示了不同工作并不同步。2月时，TAMS 的 build 5 和用户验收测试已经完成，端到端集成测试开始；build 6、7、8则计划为后续评估和签约阶段补全功能。报告还分别描述项目治理、基础设施开发、业务落地、员工与供应商准备，以及财务、供应商管理、人力与法律支持。

因此，不能用一个日历日期为整套项目亮绿灯。申请接收可以稳定，评估功能仍可能在建设；某项流程可以完成交接，另一个环节仍需要夜间保障。安全的退出不应是一刀切，可信的继续也不应是一句“仍有需要”。两者都要落实到功能。

一页退出测试应回答什么

这份记录可以很短，并与5月和9月决议的稳定编号相连。ICANN 可按真实的大类列出申请处理、付款与行政检查、评估工作流、信息公开、签约或其他服务，不需要暴露系统结构。

每一行回答六个问题：

  1. 哪一部分保障属于临时增强，预期的正常时段基线是什么？
  2. 哪个 ICANN 内部角色负责验收，并有权决定缩减、延长或重新设计？
  3. 决定查看了什么类型的证据：恢复演练、开放缺陷、工作量预测、运行手册交接，还是定义清楚的值班数据？
  4. 哪些功能已进入稳态，生效日期是什么？
  5. 哪些例外仍然存在，理由是什么，何时复核？
  6. 下一次公开决定点在哪里？

“退出”并不预设“终止合同”。测试可以得出多种合乎治理的结论：全面回到正常时段；仅为某个功能暂时保留增强覆盖；内部团队完成接管，但在特定版本发布时保留专业支援；或者正式承认原有基线已经改变。关键是继续不再依靠惯性，而有证据、责任人和下一日期。

指标也要有边界。年度平均可用率可能掩盖最关键的短时窗口。工单数量若不区分事故、咨询、缺陷和计划变更，就没有可比较含义。先定义单位，再展示数字，比一张看似精确的仪表盘更有用。

商业保密不妨碍公开运行结果

ICANN 的文件信息披露政策以公开为原则，同时允许在存在充分保密理由时不披露，包括可能损害商业利益的资料。董事会材料发布惯例也说明，决议、初步报告和会议纪要依章程公开，但特定内容可以合理省略。

退出测试完全可以在这条界线内工作。供应商名称、报价、漏洞、账户、个人排班和实时事故处置手册保持保密；“评估工作流的增强覆盖延续至某日复核，由某个内部角色负责”则是可公开的治理状态。它不会成为攻击路线图，也不会削弱谈判。

合同与付款政策规定，单项义务超过75万美元须由董事会批准，首席财务官还须定期报告重大付款。9月金额被隐去，所以不能由这个门槛反推合同数值。更重要的是，财务批准回答“谁能作出承诺”，运行验收回答“临时保障能否转移”。前者通过，不会自动替代后者。

证据止步之处

现有资料没有报告事故、响应目标落空、宕机、入侵、服务不佳、预算超支、供应商锁定或交接失败。申请量不是系统负载。5月材料出现 TAMS、RSP 和 ASP，也不代表9月合同只涉及这些系统。

9月授权可能属于既定开发、另一阶段、不同范围，或者一项已经控制良好的过渡。它不证明 ICANN 放弃5月的缩减预期。本文要求的不是从删节处推导结论，而是让实际结论在时间边界到来时留下公开记录。

来源

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN：2026年9月6日董事会批准决议
  5. ICANN：2026年5月3日董事会批准决议
  6. ICANN：ICANN85 会前2026年新 gTLD 轮次状态报告
  7. ICANN：2026轮次收到超过1,600份新 gTLD 申请
  8. 新 gTLD 项目：2026轮次申请人旅程
  9. ICANN：文件信息披露政策
  10. ICANN：董事会、诉讼与问责程序发布惯例
  11. ICANN：合同与付款政策