要約

  • 2018年8月8日、AFRINIC理事会はAFPUB-2018-V6-004-DRAFT01を承認した。しかし現行の理事会決議登録簿はその行為をResolution 201808.448、承認済みの8月7～8日議事録はResolution 201808.449と記す。登録簿では201808.449が別件のAFRINIC-29開催地MoUに割り当てられており、公開記録の番号は両立しない。
  • 承認は実装完了ではなかった。Action Item 201808.22は承認通知、Action Item 201808.23はスタッフによる実装を別の後続作業として置いた。CPM v1.3が2018年11月1日付で6.8～6.8.4節を収録した後も、AFRINIC-29では経路広告と非分割に関する確認の自動化が未完了だと報告された。
  • 改定の有用性は明確である。IPv4 PIの保有歴がなくてもエンドサイトがIPv6 PIを申請できる道を開き、原則/48または正当化された場合のより短いプレフィックス、追加割り当て、初回割り当ての一度限りの是正を規定した。ただし、これは民間の登録サービスを整える規則であり、主権、立法、規制、警察、処罰、没収、公法上の裁定権を生まない。
  • 実務上の核心は「可決したか」だけではなく、「どの文面が、いつ方針書に入り、どの処理が利用可能で、何がまだ手作業または未実装だったか」である。番号、版、実装状態を混同すれば、ネットワーク計画、調達、移行、費用見積もりの前提が崩れる。

分析――一つの行為、二つの番号、四つの状態

この記録を読む出発点は、誤植を推測で直すことではない。現行の2018年理事会決議登録簿は、IPv6 PI Updateの承認をResolution 201808.448として掲げる。一方、承認済みの2018年8月7～8日理事会議事録は、議題9.3の同じ提案、すなわちAFPUB-2018-V6-004-DRAFT01の承認をResolution 201808.449と記載する。しかも登録簿の201808.449は、CEOにAFRINIC-29開催地のMoU署名権限を与える別の行為である。二つの資料は、同じ番号を別の行為に、同じ行為を別の番号に結び付けている。どちらかを黙って上書きすれば見た目は整うが、証拠の状態を壊す。

さらに、同年9月のResolution 201809.450は8月7～8日の議事録を修正付きで承認した。ところが、調べられる公表記録は修正の本文を示していない。したがって、修正が番号の食い違いに関係したと断定することも、関係しなかったと断定することもできない。少なくとも確認された一次資料にはResolution 201809.448という行為は存在しない。201809.448を正しい番号として書くのは、欠けた記録を埋めることではなく、資料にない第三の番号を作り出すことである。

番号の衝突は単なる書誌上の小傷ではない。運用者は、申請書、契約、社内承認、設備計画、監査記録で「どの規則が、いつ適用されたか」を再現できなければならない。その再現には、決議番号だけでなく、提案識別子、理事会日、議題、後続アクション、方針書の版、実装報告を組み合わせる必要がある。本件の安定した識別子はAFPUB-2018-V6-004-DRAFT01であり、企業内部の承認日は2018年8月8日である。番号に争いがあっても、この二点と議題9.3、Action Items 201808.22-.23を連結すれば、記録の鎖は相当程度たどれる。

しかし、その鎖は一つの瞬間に収束しない。第一の状態は提案とLast Callである。2018年3月28日に公開されたDraft 1はCPM 6.8の変更を対象とし、IPv6 PIを得るためにIPv4 PIの保有歴を事実上の入口とする問題、初回割り当ての計画が後に不適切になった場合の是正を扱った。AFRINIC-28の5月9日の討議では反対意見が一つ記録され、文面変更へ進む動きはなく、共同議長はLast Callへ送るとした。これは手続き上の進展ではあるが、理事会承認でも、マニュアル収録でも、サービス実装でもない。

第二の状態が2018年8月8日の理事会による企業内部の採択である。理事会は7～8日にモーリシャスで対面会合を開き、議題9.3でV6-004を扱った。公表された作用文は、PDPの完了、合意と共同議長からの付託に関する前文を置き、提案をratifyするという限定された内容である。議事録はSOが提案し、SIが支持したと記すが、この議題の直後には、直前二件に見られるような全会一致通過の明示文がない。票数も示されない。したがって、承認されたことは確認できても、全会一致だったとは書けない。

第三の状態は、版管理されたConsolidated Policy Manualへの収録である。CPM v1.3の改訂履歴は2018年11月1日付で、IPv6 PI Updateが6.8、6.8.1、6.8.2、6.8.3を変更し、6.8.4を追加したとする。この日付は、読める規範文がどの版に入ったかを示す。提案ページや議事録だけでなく、実際にサービス基準をまとめる版に条項が現れたという意味で重要である。しかし、文書への収録はソフトウェア、審査手順、スタッフ向け運用、申請者への案内のすべてが完成したことを自動的には証明しない。

第四の状態が実装である。承認済み議事録のAction Item 201808.22は、理事長にPDWG共同議長への承認通知を課した。Action Item 201808.23は、スタッフに承認済み方針の実装を課した。この分離自体が重要だ。もし理事会の承認がサービス機能を同時に完成させる自己執行的な行為なら、スタッフ実装を別の作業項目にする必要はない。8月21日の理事長告知も、スタッフが実装を進め、実装後にコミュニティへ知らせるという未来形を用いた。承認日を運用開始日と同一視する余地はない。

そして11月下旬、AFRINIC-29の報告はIPv6 PI Updateをなお「実装中」と位置付けた。残っていたのは、割り当てられたPI空間が経路広告され、分割して広告されていないことに関わる方針要件の確認を自動化する作業だった。この記述は、CPM v1.3の11月1日収録と矛盾するのではなく、文書状態と運用基盤が別物であることを示す。ただし、そこから「11月1日には一切の申請が処理不能だった」とも、「自動化以外はすべて手作業で利用可能だった」とも推定できない。公表記録は、中間期に各条項がどの程度手動処理できたかを示していない。

したがって、運用者が使える結論は狭く、しかし明瞭である。3月の提案は意図と文面の起点、5月のLast Callはプロセス上の段階、8月8日は理事会の企業内部承認、11月1日はCPM v1.3への収録、11月下旬は少なくとも一部自動化が未完了だったことの確認である。どれか一つを「全面的な発効」の瞬間と呼ぶのではなく、用途ごとに必要な状態を特定すべきだ。法務や監査が承認行為を問うなら8月8日、当時の掲載文面を問うならCPM v1.3、実際の処理可能性を問うなら実装通知や申請単位の記録が要る。

番号より強い同定方法

記録の不一致があるとき、最も堅牢なのは複数の独立した属性で同じ行為を指すことである。本件なら、提案名IPv6 PI Update、識別子AFPUB-2018-V6-004-DRAFT01、理事会日2018年8月8日、議題9.3、通知と実装のアクション項目、CPM v1.3の6.8～6.8.4節という組み合わせである。Resolution 201808.448とResolution 201808.449のいずれか一方を消すのではなく、「登録簿では前者、承認済み議事録では後者」と属性付きで保存する。これは曖昧さを増やす表現ではない。異なる資料が実際に異なることを、再検証可能な形で保持する表現である。

この方法は、番号の意味を軽んじない。むしろ、番号が果たすべき参照機能を真剣に扱う。識別子が衝突した場合、利用者はどの文書を引用したか、どの時点の版を読んだか、別の同番号行為と混同していないかを確認しなければならない。登録簿が201808.449を開催地MoUに割り当てる以上、「201808.449だけ」を検索キーにした社内記録は誤った文書へ結び付くおそれがある。反対に「201808.448だけ」に統一すれば、承認済み議事録の表記を引用した当時の記録が説明できなくなる。

Resolution 201809.450も万能の修復鍵ではない。それが8月議事録を修正付きで承認した事実は分かるが、修正箇所が見えない以上、番号訂正を裏付ける証拠として使うことはできない。公文書の欠落を「普通ならこう直したはずだ」という推量で埋めると、後の監査者は事実と編集上の仮説を区別できない。必要なのは、既知の衝突、未知の修正内容、確認できる共通の提案識別子を同じ記録面に載せることだ。

この差は、インターネット番号資源の運用では特に大きい。プレフィックスの割り当ては、DNS、ルータ設定、フィルター、証明書、アクセス許可リスト、監視、顧客への通知、調達契約と結び付く。どの基準で割り当てサイズを説明したか、後の拡張や是正がどの版に基づくかを再現できなければ、担当者の交代や上流接続先の変更時に余計な検証が発生する。正確な版と状態の記録は抽象的なガバナンス美学ではなく、障害と移行費用を減らす運用資産である。

方針本文が変えた入口

CPM v1.3に収録された改定の中心的な便益は、IPv6 PIの入口を古いIPv4 PI保有歴から切り離したことにある。対象は一つの管理組織に属するエンドサイトであり、申請者はLIRではなく、AFRINICのEnd User Memberとなり、必要性を説明し、十二か月以内の利用計画を示すことが求められた。これは誰にでも無条件でアドレス空間を渡す仕組みではない。同時に、IPv4時代の資格をIPv6の独立アドレス継続性の前提にする不整合を取り除いた。

初回割り当ては/48を基本とし、必要性が正当化されれば、数値上はより短く、したがってより大きなプレフィックスを認める構造だった。ここで「短い」を小さな割り当てと誤読してはならない。IPv6のプレフィックス長では、/47や/46のように数字が小さいほど包含する空間は大きい。申請者は組織構造、サイト数、アドレス設計、成長見込みをもとに、なぜ/48を超える規模が必要なのかを文書化することになる。

追加割り当てにも文書化が求められ、可能な場合は既存ブロックに連続する拡張が優先された。連続性には実務上の価値がある。経路をまとめやすくし、フィルターや監視設定を単純にし、社内のアドレス管理を理解しやすくするからだ。ただし「可能な場合」という限定を外して、常に連続拡張が保証されると読んではならない。アドレス在庫と割り当て履歴によっては、補完的な別ブロックが必要になり得る。

新設の6.8.4節は、初回割り当ての計画が現実に合わなかった場合に一度だけ是正する道を設けた。申請者は更新した計画を示し、可能なら同じブロックの延長を受ける。別の選択肢として、新しいブロックへ六か月以内にリナンバリングするか、補完的なブロックを保持する構成が示された。重要なのは、最初の予測が永久に正しいという虚構を捨て、変更に処理経路を与えたことである。設備追加、組織再編、拠点増加、設計変更は現実のネットワークで起こる。是正手続きは、その現実を登録記録へ戻すための安全弁となる。

一方、経路広告と非分割に関する文言は、登録サービスの狭い確認と、ネットワーク運用への一般的命令を区別して読む必要がある。AFRINIC-28の記録では、提案者はスタッフに経路監視を命じる趣旨ではないと説明した。後のAFRINIC-29報告は、経路広告と非分割のチェックに関する自動化が残っているとした。二つの記録から分かるのは、実装上の確認項目が存在したことまでである。常時監視の権限、違反者を処罰する権限、経路設計を一般的に命じる権限までは導けない。

「利用可能」を一語で処理しない

方針が「利用可能になった」と言うとき、その語は少なくとも三つに分解しなければならない。第一は、申請者が読める確定文面が存在すること。第二は、レジストリがその文面に基づく申請を受け付け、判断できること。第三は、必要なチェック、データ更新、通知が継続的かつ予測可能に実行できることだ。CPM v1.3の収録は第一を強く示すが、AFRINIC-29の報告は第三の一部が未完成だったことを示す。第二については、公表資料だけから全条項の可否を日別に復元できない。

この留保は、制度を無意味だと言うためではない。むしろ有用な制度を正しく使うために必要である。たとえば、申請者が11月初旬にネットワーク計画を作る場合、CPM v1.3の文面を参照できた可能性は高い。しかし、そのことだけから、申請画面、内部審査、経路確認、非分割確認、通知の全工程が自動化済みだったとは言えない。担当者が手作業で処理できた範囲についても、資料にない具体像を描くべきではない。

年次報告がV6-004を8月承認およびCPM 6.8～6.8.4と結び付けたことは、年間の大枠を確認する補助になる。しかし年次要約は、番号衝突を解決せず、自動化完了日も示さない。要約資料は詳細資料を置き換えない。運用の時系列を組むなら、提案ページ、会議記録、理事会登録簿と議事録、理事長告知、CPMの改訂履歴、AFRINIC-29の実装報告を、それぞれが証明できる範囲で重ねる必要がある。

実務上は、発効状態を二値ではなく状態票として持つ方がよい。提案公開、Last Call、理事会承認、方針書収録、手動受付、主要チェック実装、自動化、完了通知という欄を分け、確認できない欄は不明とする。本件では手動受付や個別申請の処理状況が分からないため、そこを空欄のまま残す。この「不明」は調査の失敗ではない。根拠のない肯定や否定を防ぐ、正確な運用情報である。