摘要

  • NRO 于 2026 年 9 月公布的推荐草案拟要求各 RIR 维护连续性与冗余程序，并在适当的数据托管或保护措施下，定期分享临时运营者维持服务所需的记录、数据、政策实施办法和系统。
  • 草案设置服务范围、激活与续期条件、每期 90 天的时限和事后公开审查，但它仍是推荐草案；本文没有证据表明发生过真实接管。

如果等到登记机构已经无法履职才准备连续性方案，往往为时已晚。Number Resource Organization（NRO）的新草案试图把部分准备工作前移：每个区域互联网注册机构（RIR）平时就要维护连续性和冗余程序，也要准备好在必要时供临时运营者使用的材料。

关键条款是《RIR 治理文件第三版推荐草案》第 4.1(m) 节。它要求 RIR 定期分享足以支持临时运营者履行服务职责的记录、数据、区域政策实施程序和系统，同时采取适当的托管或数据保护措施。这不是要求公开全部数据，也不是把所有系统自动转交给外部机构。

清单所指不只是数据库备份，还包括政策实施办法和系统。因此，连续性不再只是事故发生后的临时导出，而是平时就存在的操作准备关系。草案将 RIR 服务界定为号码资源委派，以及分配、登记、目录和相关技术服务，使资源持有人能够使用资源、外界能够获得准确的持有人信息。

准备工作有两种相反风险。数据太旧，临时运营者可能无法维持可靠记录；权限太广，则可能暴露敏感信息或赋予超出连续性需要的权力。条款提到托管与数据保护，却没有在本条中写明刷新频率、权限撤销程序或完整性测试。这些细节应在实施规则中变成可检查的控制。

90 天是续期节点，不是总期限

第 5.1 节规定，如果 RIR 因内部或外部原因无法充分提供全部或部分服务，可以由临时紧急运营者承接受影响部分。受影响的 RIR 可以为自身服务发起安排；另一条路径则由 ICANN 与其他 RIR 的三分之二同意，在可行时先与受影响 RIR 及其社群讨论后，发起或续期安排。

每一期原则上不得超过 90 天，除非依据同一条款续期。NRO 数字委员会的第三版修订说明称，新稿允许受影响 RIR 自行发起，把外部激活门槛从一致同意降为 ICANN 与三分之二 RIR 同意，并保留 90 天限制，以避免临时运作成为默认模式。因此 90 天是必须重新作决定的节点；只要续期获批，就不是累计总时限。

受影响 RIR 必须配合临时交接，并在运营能力恢复且经验证后保有接回相关服务的权利。发起方还可在安排期间或续期时扩大或缩小服务范围。草案设计了返回路径，却没有在这几句中说明由谁判定能力恢复、采用哪些测试、如何核对临时期间的登记变更，以及临时运营者的权限何时终止。

透明度程序要求 ICANN 尽快公开激活理由和范围，并尽可能及时启动与各 RIR 社群的沟通。安排结束后，RIR 与 ICANN 必须共同复盘，公开说明事件原因、承接服务、持续时间、返还过程、运营者表现、社群意见和改进建议。若事先没有定义清楚的衡量指标，复盘就难以对照承诺与实际表现。

紧急连续性不能与撤销 RIR 认可混为一谈。第 6 节把撤销认可设为独立程序：严重不合规者须先获得合理纠正机会；撤销后，服务责任按过渡计划转移，原 RIR 停止承担该地区的服务责任。应急安排只是临时替代部分服务，原 RIR 仍保留返还路径。第 6.9 节要求两种情形都具备集体转移准备能力，但并没有把它们变成同一个决策。

这仍是推荐草案

第三版尚未成为已采纳规则。NRO 执行委员会 7 月 28 日公告称，ASO 地址委员会已提交推荐草案，后续流程由 NRO EC 协调推进。AFRINIC 9 月 1 日发布的说明同时提供草案、修订对照和理由，并表示后续征询机会将由 NRO EC 公布。第 1.3 节还预期 RIR 与 ICANN 制定共同实施程序。

下一步最有价值的证据应是可操作的准备清单：哪些服务和系统纳入托管、数据多久刷新、如何验证完整性、谁能授权和查看访问记录、什么条件允许 RIR 接回服务，以及临时权限和副本何时销毁。桌面演练可以检验交接流程，而无需暗示真实生产服务已经中断。公开复盘还应分清哪些资料可用、哪些资料实际被调用。

这份草案的设计变化，是把连续性准备纳入日常运行。其效果取决于“定期”“足够”“适当保护”和“经验证”能否转化为可测试的安排。

来源

截至 10 月 15 日，NRO 流程时间表仍将最终定稿列为进行中：计划在 ICANN 87（10 月 17–22 日）、LACNIC 46（10 月 19–22 日）、ARIN 58 和 RIPE 93 更新进展；批准与采纳仍列在 2026 年第四季度。