摘要

  • 第三版推荐稿允许受影响的 RIR 为自身服务启动临时交接；另一路径由 ICANN 与其他 RIR 中三分之二同意启动或续期。
  • 草案将临时安排限制在 90 天内，并保留服务能力恢复且经核实后由原 RIR 接回的权利；但谁能续期一个由 RIR 自行启动的安排，文本没有明说。

运营者可以临时接手，权限却不应靠猜

RIR 无法充分提供全部或部分服务时，RIR Governance Document 第三版允许由具备资质的 Temporary Emergency Operator 暂时承担受影响的工作。条文并未说这个运营方将取代 RIR 本身。它谈的是一组具体服务的临时交接，可能涉及号码资源委派、登记与目录维护，或使资源持有者及其他网络能够依赖最新记录的技术服务。交接范围可以只涵盖部分服务，也可以变化。

AFRINIC 于 2026 年 9 月 1 日转发了 ASO AC 推荐稿、对照版本和理由报告。NRO 页面把第三版标为 FINAL DRAFT；NRO 时间表记载，ASO AC/NRO NC 已于 7 月 28 日将推荐稿交给 NRO Executive Council。截至 10 月 14 日，最终化工作仍在进行，第四季度批准与采纳也尚未完成。因此这是面向整个 RIR 体系的规则提案，而非已经生效的操作规程。公告和草案都没有证明 AFRINIC 或任何其他 RIR 当前无法提供服务。AFRINIC 的公告只是转发了整套材料；分析依据是 NRO 发布的第三版文本及其理由说明。

两种启动路径

5.1(a) 是相对第二版的实质变化。受影响的 RIR 若无法充分提供全部或部分服务，可以为自身服务启动 Temporary Emergency Continuity Arrangement。第二版要求其他所有 RIR 与 ICANN 一致同意才可启动。第三版保留了外部协同路径：根据 5.1(b)，ICANN 与其他 RIR 中三分之二同意后，也可以启动或续期；在合理可行的情况下，启动前还应与受影响 RIR 及其社群讨论。

理由报告给出了运营层面的出发点。遇到自然灾害时，受影响的 RIR 可能需要自行触发安排；降低跨 RIR 协同门槛，也能缩短响应时间。但草案保留 90 天上限，理由是不能让临时安排变成默认运行方式。这个设计方向有其道理：在突发情况中，如果必须等更大范围的批准才能请求服务连续性支持，谁可以接管关键注册职能可能会迟迟不清楚。

然而，启动与续期不是同一个决定。5.1(a) 明确受影响的 RIR 可以自行启动；5.1(b) 则是唯一直接写出“启动或续期”并列条件的条款；5.1(c) 规定，安排不得超过 90 天，除非依照本节条件续期。条文没有明确说明，若安排是根据 (a) 由受影响 RIR 自行启动，是否可以由该 RIR 自行续期，还是必须转到 (b) 所说的 ICANN 与其他 RIR 同意路径。

至少有两种读法。一种读法是：既然只有 (b) 明确写出续期，所有续期都应经过该集体路径。另一种读法则认为，(a) 授予受影响 RIR 的启动权限，也包含续期最初由它启动的安排。5.1(f) 进一步提到，(a) 或 (b) 下的“相关启动方”可以在安排期间或续期时调整服务范围，这说明两条路径并非互不相关，但仍未回答谁可延长一个自我启动的安排。这里应被视为需要澄清的文本歧义，不能写成已经确定的法律结论，也不能据此断言 RIR 自行启动后不能续期。

服务范围变化，也是在分配权限

交接范围不会在启动日冻结。5.1(f) 允许相关启动方在安排期间或续期时增加或减少受影响服务。如果受影响 RIR 先启动安排，随后又由外部协同路径批准续期，草案就应说明：谁可以增加一项服务、缩小临时运营方的职责，或者改变后续工作的分工。

这不是文书管理问题。每一项交给临时运营方的服务，都会改变受影响 RIR 仍能直接控制什么；每一项归还服务，也涉及相应返还步骤，以及证明注册管理机构能够重新承担该工作的证据。5.1 开头所说的“无法充分提供”同样需要运营判断。公开决定至少应说明哪一项服务未达到充分提供的标准，以及将以什么证据判定其恢复；这并不要求公开密码、系统配置或其他敏感安全信息。

草案已有重要保障。5.1(d) 要求 ICANN 尽快公布启动或续期决定、理由和范围。启动后，应在合理可行时启动面向所有 RIR 社群的参与流程；续期后是否再进行额外的 RIR 社群参与，则由 RIR 自行决定。5.1(e) 要求受影响 RIR 配合临时交接，并保留在运营能力恢复且经核实后接回相关服务的权利。5.2 又规定安排结束后由 RIR 与 ICANN 联合复盘，公开说明事件缘由、服务内容、持续时间与返还过程，同时评估运营方表现、征求社群意见并提出改进建议。

这些安排提高可见度，也限定临时运营方的职责，却不能代替续期授权本身。社群可以提供第一手证据、技术知识和风险提示；草案所指明的机构，仍需对正式决定负责。参与与授权是相关但不同的事情。

共同程序应记录交接路径

1.3 允许 RIR 与 ICANN 制定实施程序，但也说即使尚无这类程序，文件中的条款仍可执行；各 RIR 可在总体义务之内自行决定如何合规。1.4 则要求各方按自己的程序作决定，包括适用的质疑或申诉渠道。统一的应急手册可以规定操作细节，却不应让人等到事件发生后才去推断谁有权批准续期。

一个精简的“权限路径记录”可以让草案变得可检验：启动所依据的条款与决策者、受影响服务、开始日期、90 天到期点、续期发起方与批准方、服务范围的变化及其授权者、讨论和公开记录、恢复能力的测试方式、验证者，以及事后复盘的负责人和日期。目的不是给每一步加一道审批，而是分清“某个 RIR 请求支援”与“多个机构决定继续或扩大服务交接”。

按 NRO 目前公布的时间表，第三版仍在最终化流程中，后续会议将发布进展，第四季度还要确定批准与采纳程序。下一稿可以用三个问题检验：依据 5.1(a) 启动安排的 RIR 能否自行续期？如果不能，5.1(b) 要求何种明确决定？启动路径变化时由谁控制服务范围？明确作答既能保留第三版追求的响应速度，也能让 90 天期限届满时的责任可追溯。

来源