摘要

  • APNIC 于 9 月 1 日公开 NRO NC 的 3.4 版推荐草案、红线稿和说明文件。
  • 第 7.2 条拟规定：若某个 RIR 正处于临时紧急连续性安排之下，或去认证提案仍在待决，文件不得修订。
  • 官方说明的目的，是防止在困难时刻为特定情形仓促改写规则或降低要求；这仍是一份草案，并不证明存在紧急状态或已经生效的规则。

3.4 版中最值得注意的条款之一，篇幅反而极短。第 7.1 条拟要求，修订须在各自社区咨询后获得 ICANN 和所有 RIR 的一致同意。第 7.2 条再加上一道条件：当某个 RIR 处于 Temporary Emergency Continuity Arrangement 之中，或存在待决的 Derecognition 提案时，文件不得被修订。

APNIC 9 月 1 日的公告把这个文本放在准确的位置上：它是 NRO Number Council 推荐的草案，并附有红线比较稿和理由说明。公告没有宣布最终采纳、实施或任何个案的启动；也没有说任何 RIR 正在紧急连续性安排中、面临去认证，或已提出修订。

但这项条款的制度意图是明确的。理由说明称，它旨在防止为了应对特定情况而仓促修改文本，也防止在困难时刻稀释要求。这是一项窄而必要的防护。若一份规则正在规定如何处理紧急连续性或去认证，相关方不应在依赖它的同一时刻重新书写它。

第 5 条给出了适用边界。Temporary Emergency Continuity Arrangement 是为受影响 RIR 服务提供临时安排的机制。受影响的 RIR 可为其全部或部分服务发起这一安排；在尽可能与受影响 RIR 及其社区沟通后，ICANN 和其他 RIR 中三分之二也可以发起或续期。期限不得超过 90 天，除非依同一条续期；ICANN 应及时公布启动或续期的理由与范围。这些是可能启动的程序，不是已经发生的事件记录。

修订冻结是否有公共价值，取决于外部读者能否知道它是否正在生效。草案要求在若干节点发布信息，却没有给出一个面向读者的统一记录，把具体安排或提案与第 7.2 条的状态连起来。一份简洁的状态回执就足够：受影响的 RIR、事件类型、决定和生效时间、范围、原始公告链接、续期或结束状态、发布责任方与更正记录。它无须披露法律意见、敏感事故细节或谈判内容。

这不会让草案立刻成为有约束力的规则，也不能化解一场危机。它只会帮助读者区分“未来可能适用的保障”与“当前已经激活的冻结”。在制度文本很容易被误读为现实运行状态的领域，这一区分尤其重要。

来源