要約

  • Version 3の推奨草案は、対象RIRが自らのサービスについて一時移管を開始する道を加えた。別の経路では、ICANNと他のRIRの3分の2が開始または更新に合意する。
  • 90日の上限と、運用能力の回復を確認した後に対象RIRがサービスを再開する権利は明示されている。RIR自身が開始した移管を誰が更新できるかは明記されていない。

運用者の交代とRIRの交代は別の話だ

RIRがサービスの全部または一部を十分に提供できない場合、RIR Governance DocumentのVersion 3案は、適格なTemporary Emergency Operatorが対象サービスを一時的に担う仕組みを置く。条文はその運用者をRIRそのものに置き換えるものではない。対象になるのは、番号資源の委任、登録情報やディレクトリーの維持、それらを利用者や他のネットワークが信頼するための技術サービスなど、具体的な業務である。全部ではなく一部だけを移管することもでき、範囲も変わり得る。

AFRINICは2026年9月1日、ASO ACの推奨草案、比較用の新旧対照表、変更理由を共有した。NROのページはVersion 3をFINAL DRAFTと記載する。NROの工程表によれば、ASO AC/NRO NCは7月28日に草案をNRO Executive Councilへ提出した。10月14日時点で最終化は進行中で、Q4の承認・採択もこれからだ。これはRIR全体に関する提案であり、施行中の手順ではない。公告にも草案にも、AFRINICその他のRIRが現にサービスを提供できていないとの記載はない。AFRINICの告知は資料の共有を示すもので、分析対象の条文はNROのVersion 3本文にある。

開始の道は二つある

5.1(a)はVersion 2からの大きな変更だ。全部または一部のサービスを十分に提供できないRIRは、自らのサービスを対象にTemporary Emergency Continuity Arrangementを開始できる。Version 2では、開始に他の全RIRとICANNの全会一致が必要だった。Version 3の5.1(b)は外部合意による経路を残しつつ、基準を引き下げる。ICANNと他のRIRの3分の2の合意があれば開始または更新でき、合理的に可能な状況では対象RIRとそのコミュニティとの協議も行う。

変更理由は速度を重視している。自然災害では、対象RIR自身が連続性措置を始める必要があり得る。外部経路の基準を下げれば、対応も速くなる。一方、90日上限は、一時措置が恒常的な運営方法になることを避けるために維持された。この考えには実務上の説得力がある。必要な登録サービスの担当が定まらないまま、広範な承認を待つ時間を減らせるからだ。

ただし、開始と更新は同じ決定ではない。5.1(a)は対象RIRを自らの移管の開始者として明記する。5.1(b)だけが、開始または更新をICANNと他のRIRの3分の2の合意に結びつけている。5.1(c)は、この節の条件による更新がなければ90日を超えられないとする。そこで一つの疑問が残る。5.1(a)で始めたRIRは自ら更新できるのか。それとも5.1(b)の外部合意が必要なのか。文面には明示的な答えがない。

読み方は一つではない。更新を明記したのが5.1(b)だけなら、ここだけが示された更新経路だと解釈できる。一方、(a)で始める権限には、その措置を延長する権限も含むと読む余地がある。5.1(f)は、(a)または(b)の関連する開始者が、措置の期間中または更新時に範囲を変更できるとしており、二つの経路を完全に切り離してはいない。それでも更新主体は確定しない。これは最終文面で明らかにすべき草案上の曖昧さであり、どちらかの法的解釈が既に決着したという意味ではない。

サービス範囲の変更も権限配分だ

移管対象は最初の日に固定されない。5.1(f)は、措置の途中または更新時に対象サービスを増減することを認め、(a)または(b)の関連する開始者が必要と判断すると定める。対象RIRが始め、後から外部の集団が更新を認める場合、誰が機能を追加し、運用者の範囲を狭め、あるいは分担を組み替えられるのかを文面で示す必要がある。

これは帳票上の細部ではない。臨時運用者に渡すサービスが増えるたび、対象RIRが直接担う業務は変わる。サービスを戻すときには、その業務を再び担えることを確かめる手順と証拠が要る。冒頭の「十分に提供できない」という判定にも運用上の評価が関わる。決定記録には、どのサービスが基準を満たせなかったか、復旧を何で確認するかを残せる。認証情報やセキュリティ上の機微を公開する必要はない。

草案には重要な歯止めもある。5.1(d)は、開始・更新の決定、理由、範囲をICANNが速やかに公表するよう求める。開始後はすべてのRIRコミュニティへの関与をできるだけ早く始める。更新後に追加のRIRコミュニティ協議を行うかは任意だ。5.1(e)では対象RIRに一時移管への協力を求める一方、運用能力が戻り検証された後に該当サービスを再開する権利を保つ。5.2は終了後の共同レビューを義務付け、事情、提供サービス、期間、返還手順の公開、運用者評価、コミュニティの意見収集、改善提案を求める。

これらは臨時運用者の仕事を見えるようにし、範囲を限定する。だが、自ら始めた移管の更新権限を代わりに定めるものではない。コミュニティは証拠、技術知識、懸念を提供できる。正式な決定の責任は、草案が指定する機関に残る。

実施手順は引き継ぎの履歴を見せるべきだ

1.3は共同の実施手順を想定する一方、それが未採択でも条文の有効性は失われないとする。各RIRは共通の義務の範囲内で、自らの順守方法を決められる。1.4は、各機関の手続に従った決定と、適用される異議申立て・不服申立ての可能性を認める。共通の運用手引きで作業の詳細は補えるが、基本の権限配分まで緊急時に推測させるべきではない。

短い「権限経路記録」があれば、仕組みを検証しやすい。開始根拠の条文と決定者、対象サービスと開始日、90日目の期限、更新する者と承認者、範囲変更とその決定者、協議・公表の記録、RIRへ戻す能力の確認方法、事後レビューの担当者と日付である。各段階に新しい承認を加えるのが目的ではない。「対象RIRが支援を求めた」ことと「複数の機関が移管の継続や拡大を決めた」ことを区別できるようにするためだ。

NROの工程表では最終化が続き、RIRやICANNの会議で進捗を共有した後、Q4に承認・採択を行う予定だ。次版を読むときは、三つの点を確かめたい。5.1(a)で開始したRIRは自ら更新できるのか。できない場合、5.1(b)でどの合意が必要か。開始経路が変わったとき、誰がサービス範囲を決めるのか。90日目の責任を追える文面なら、迅速さと説明可能性を両立できる。

出典