要約

  • バージョン3は、一時的緊急継続措置の開始後に全RIRコミュニティーとの参加プロセスを始めるよう求めるが、更新後の追加プロセスはRIRが選べるとしている。
  • 更新でも決定、理由、対象範囲の公表は必要である。外部から更新する経路では、ICANNと他RIRの3分の2の合意に加え、合理的に可能な場合は対象RIRとそのコミュニティーとの協議が要る。
  • 更新記録に累計日数、範囲変更、追加参加を行うか否かの理由を残せば、復旧を遅らせずに裁量を検証できる。

最初の90日と次の90日では、コミュニティー参加の条件が同じではない。

これは、AFRINICとNumber Resource Organizationが9月1日に公表した「RIR Governance Document Version 3」勧告草案の第5.1項にある、小さいが重要な切り替えである。草案は、地域インターネットレジストリがRIRサービスの全部または一部を十分に提供できない場合に、Temporary Emergency Continuity Arrangement（TECA）を設ける。適格な暫定緊急運用者が対象サービスを一時的に担う仕組みだ。

ただし、これは勧告された最終草案である。確認した資料は、採択、ICP-2の置き換え、発効のいずれも証明していない。AFRINICや他のRIRが現在TECAの対象だとも述べていない。

更新時に変わる一つの条件

第5.1項には二つの開始経路がある。サービスを十分に提供できないRIRは、自らのサービスの全部または一部についてTECAを開始できる。もう一つはICANNと他RIRの3分の2が合意する経路で、開始にも更新にも使える。その際、状況下で合理的に可能なら、対象RIRとそのコミュニティーと協議する。

一つの期間は90日を超えられない。ただし、同項の条件で更新できる。ICANNは、開始または更新の決定と、その理由、対象範囲を速やかに公表しなければならない。つまり更新そのものが非公開でよいわけではない。

参加には三つの面がある。開始後には、合理的に可能な限り早く、全RIRコミュニティーを対象とする参加プロセスを始める。対象RIRとそのコミュニティーは、開始または更新前の協議に関わる。ICANNは自らの定款と手続きに従ってコミュニティーに関与する。

ところが更新後については、RIRは追加のコミュニティー参加プロセスを「選択できる」と書かれている。最初の全地域プロセスは義務であり、次は裁量である。対象コミュニティーを無視できるという意味でも、公表義務が消えるという意味でもない。変わるのは、全RIRコミュニティーをつなぐ特定のフィードバック回路だ。

時間以外も変わり得るため、この境界は重い。第5.1(f)項は、TECAの途中または更新時に、暫定運用者が担うサービスの範囲を増減できるとしている。次の期間は単に長くなるだけでなく、最初とは異なるサービスを含み得る。条文は一期間を90日に区切る一方、確認した本文には更新回数の数値による累積上限がない。

速度には正当な理由がある

緊急継続措置が必要なのは、手続きの不完全さより遅延の害が大きい局面があるからだ。割り振り、登録情報、ディレクトリー、逆引きDNSなどは、運用能力が失われたときに長い協議を待てない。更新時点でも最初の全地域プロセスが続いており、意見がなお有効な場合もある。毎回すべてを機械的にやり直せば、雑音を増やし、戦術的な遅延を招き、復旧担当者の注意を奪いかねない。

草案には別の歯止めもある。更新の決定、理由、範囲は速やかに公表される。外部更新にはICANNと他RIRの3分の2が必要だ。合理的に可能なら対象RIRとコミュニティーとの協議も必要で、ICANN独自の関与も残る。終了後には第5.2項により、公開報告、暫定運用者の評価、コミュニティーからの意見、改善提案を含む共同の事後検証が行われる。

したがって、90日ごとの住民投票が答えではない。裁量をどう使ったかが分かる記録が答えである。

更新決定に添える小さな記録

各更新には簡潔な更新票を添えるべきだ。TECAの識別子、期間番号、決定主体、開始日と終了日、累計日数、暫定運用者、更新前後のサービス範囲、変更理由を記す。

対象RIRとコミュニティーにいつ連絡したか、協議が合理的に不可能だったならその限定的な理由も必要だ。直近の全RIRコミュニティー手続きへリンクし、新たな手続きを開いたかを示す。開かなかった場合は、従来の手続きが継続中だったのか、範囲に変更がなかったのか、復旧上の遅延が危険だったのか、それとも別の理由かを明記する。ICANN側の参加状況、復旧判定、次の決定期限もつなぐ。

認証情報、非公開の登録データ、攻撃に使える構成、保護された事故情報は公開票から外してよい。この票を更新の事前承認に変える必要もない。目的は、更新権限、参加状況、サービス範囲を同じ再現可能な記録に置くことだ。

バージョン2にも90日、コミュニティー参加、更新の概念はあった。バージョン3は更新経路を明示し、外部経路のしきい値を下げ、開始時の必須参加と更新後の任意の追加参加を本文で分けた。NROの理由書は、90日制限と透明性の保護を維持しながら、より速い対応を可能にする変更だと説明する。

その目標には説得力がある。しかし、緊急権限の時間制限は、時計をリセットするたびに履歴が残って初めて機能する。必須の公開プロセスが任意になるなら、再開しないという決定も緊急時の記録に含まれる。

情報源