要約

  • AFRINIC-37 の議事録は、AS0 ROA の完全実装、番号資源移転の技術システム、abuse contact の内部技術実装を MyAFRINIC v2 の依存または後続作業として記録した。別の staff assessment は、Last Call にあった AS-SET 提案もポータルの後に配置した。
  • 四経路は同じ機能群ではない。三政策は批准済みだが AS-SET は未批准であり、RPKI、他 RIR との手順、内部検証、WHOIS、IRR という異なる接点を持つ。
  • ポータルが利用可能であることは、ポータルの状態しか証明しない。政策ごとに、正確な文書版、release baseline、試験、部分／完全の定義、有効化、例外、訂正、稼働後の観察を結ぶ受入れ台帳が必要である。
  • 共通基盤は重複開発や旧システム間の不整合を減らし得る。危険なのは共通化そのものではなく、一つの「公開済み」が Awaiting Implementation、内部試験、部分実装、手順整備中、未批准を覆い隠すことである。

ソフトウェアには、誰にでも理解しやすい節目がある。ログインできるようになり、画面が開き、操作が実行できる。政策の施行には、そのような一場面がない。権限を持つ文書が確定し、正しい版がシステムに反映され、対象となる利用者が手順を完了でき、誤った結果が履歴を消さずに訂正できて初めて、運用状態を語れる。

MyAFRINIC v2 は、この二種類の進捗を一つのプログラムに集めた。AFRINIC の公式資料には、少なくとも四つの政策経路が同じポータル節目の後、または部分的な依存関係に置かれている。工程管理としては自然である。しかし受入れ証拠としては粗すぎる。

第一の経路は未割当・未指定アドレス空間の AS0 ROA、第二は番号資源の移転、第三は abuse contact の検証、第四は新規 AS-SET の階層名である。最初の三つは確認資料で批准済み、四つ目は Last Call の提案だった。作用するシステムも、利用者も、外部相手も、失敗の意味も違う。

したがって「四政策が MyAFRINIC v2 に入ったか」と問うだけでは足りない。画面の存在、内部処理、機関間手順、政策権限を混同するからである。必要なのは、各経路が共有依存から、受入れ済みで責任帰属可能、かつ訂正可能な運用に移ったことを何が証明するかという問いである。

同じ工程に二つの期日表現

AFRINIC-37 議事録によれば、会合は 2026 年 6 月 24 日に開かれた。MyAFRINIC v2 の開発は 2020 年に始まり、複数年の予算・資源制約に直面した後、再始動した。6 月時点では 2026 年末までの go-live が見込まれ、scope creep を避けるために範囲を抑える必要があると説明された。

範囲管理は失敗の証拠ではない。会員の身元、権限、番号資源操作を結ぶポータルなら、広すぎる機能を一度に出すより、整合した基盤を限定的に試験する方が安全な場合がある。共通基盤によって、旧システムごとに異なる規則解釈を減らせる可能性もある。一方、議事録は具体的に何を外したかを示さない。四政策のどれかが削られたと推測してはいけない。

AfPIF 2026 のページは、MyAFRINIC v2 を会員向けセルフサービスポータルの全面刷新と説明する。user acceptance testing と live beta の前に、テスターや業務フロー面談の参加者を募っていた。これは準備と募集の証拠である。UAT 完了、beta 開始・完了、production 公開の証拠ではない。

AS-SET の staff assessment には、より具体的な 2026 年 11 月 15 日という期日がある。そこでは、資源が MyAFRINIC v2 に集中し、提案の実装はポータル完了後に優先されるとされた。6 月議事録の表現は、より広い年末である。この二つは矛盾を解消するために混ぜるのではなく、出所と粒度を保って記録すべきである。

11 月 15 日を四政策共通の約束に拡張することもできない。証拠の基準日には、まだその日が来ていなかった。公開済みとも遅延とも確認できない。期日は依存関係を示すが、受入れ結果を先回りして与えない。

AS0：「部分」の中身を先に決める

現行政策台帳は、AFPUB-2019-GEN-006-DRAFT03、RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space を批准済みかつ Awaiting Implementation とする。AFRINIC-37 議事録はさらに、改良版 KRILL による内部試験、同月末に見込まれた partly implemented と明示する beta、そして MyAFRINIC v2 に依存する「政策文どおりの完全実装」を区別した。

ここには少なくとも四状態がある。批准、内部試験、部分実装、文書どおりの完全実装である。これを「RPKI 機能あり」という一語にすると、公式記録が持っていた精度を失う。

AS0 の受入れには、対象オブジェクト、対象資源の範囲、除外例、誤った公開の検出と訂正、部分状態を終える条件が必要である。確認資料はこのマトリクスを示さず、予定された beta が実際に出たとも証明しない。空白を推測で埋めるべきではない。

将来の受入れ記録では、批准文書、MyAFRINIC v2 の baseline、関係する KRILL 状態、試験ケース、公開結果を結ぶ必要がある。内部試験は統制環境でのロジックを確かめる。会員の役割、統合、長期的な訂正まで自動的に証明しない。partly implemented は、存在するもの、欠けるもの、次へ移る条件を伴って初めて有用である。

移転：ポータル外の相手まで通して試す

批准済み政策の概要は、Number Resources Transfer Policy AFPUB-2020-GEN-006-DRAFT03 の批准を 2026 年 2 月 4 日とする。議事録は、intra-RIR と inter-RIR の移転を対象とし、他四 RIR との相互性が 4 月時点で確認されていたと報告した。Member Services は相手方と必要手順を対応付けており、技術システムは MyAFRINIC v2 後に優先される予定だった。

移転申請はポータルから始まっても、inter-RIR 移転はポータル内で完結しない。資格確認、書類、状態交換、判断、両側の登録更新、通知が続く。フォームが動くことは、すべての適格経路が責任帰属可能な結果まで進めることを意味しない。

逆方向の中間状態もあり得る。一般向け画面より先に、内部または手作業の手順が利用可能になる場合である。そのため、ポータルがないという理由だけで「未実装」と言うのも粗い。台帳は、手順対応済み・技術試験待ち、特定カテゴリのみ利用可能、内部経路はあるが会員 UAT 中、といった状態を許すべきである。

経路ごとに、前提条件、相手 RIR、試験ケース、判断点、登録結果、通知、再開または訂正方法を記録する必要がある。将来一件の成功例が公開されても、それはその条件の証拠であり、すべての移転カテゴリの証拠ではない。

ここで移転制限の実体的な是非を論じ直す必要はない。本稿の対象は、申請入口と、機関をまたいで受入れ済みの一貫した移転経路を分ける証拠である。

Abuse contact：受け入れるのはメールではなく状態遷移

同じ概要は、Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 も 2026 年 2 月 4 日に批准されたとする。AFRINIC-37 議事録では、内部システムの技術実装は MyAFRINIC v2 の展開完了後に優先される予定だった。

abuse-c 属性があり、メールを送れるだけでは完全実装にならない。対象レコード、検証開始、配信、応答、失敗、通知、訂正、例外、結果が始まる時点を区別する必要がある。

しかも、その状態遷移は支配的な文書版に結びつかなければならない。BTW には、古い Draft 2 とその結果連鎖を扱った別稿がある。その設計を Draft 7 に類推で移すことはできない。内部手順は批准文を具体化できるが、古い解釈や非公式解釈に静かに置き換えることはできない。

部分実装には複数の形がある。新規レコードだけを対象にする、通知は動くが訂正経路は未受入れ、内部手順は準備済みだが会員画面は未公開、といった状態である。範囲と終了条件が明示されれば、段階導入として合理的であり得る。すべてを「実装済み」に吸収すると見えなくなる。

AS-SET：技術準備は政策権限を発生させない

AFPUB-2026-ASN-001-DRAFT02 は確認台帳で Last Call だった。批准は確認されていない。staff assessmentは、新規の非階層 AS-SET を防ぐため、WHOIS の各作成経路と MyAFRINIC の IRR 画面に変更が必要だとする。既存オブジェクトは改名しない。

決定前の技術評価は妥当である。どのシステムに影響し、実行可能かを知らずに政策を決めるべきではない。しかし実行可能性は権限ではない。批准前の正しい状態は「提案を評価済み」であり、「政策を実装済み」ではない。

将来批准された場合、受入れは最終文書と発効時刻から始まる。その後、すべての作成経路を試す。MyAFRINIC で拒否されても、別の WHOIS 経路が同じ規則を適用するとは限らない。新規オブジェクトが正しく作れても、既存オブジェクトが変更されていない証明にはならない。二つの境界には別々の試験が要る。

政策経路 確認された状態 MyAFRINIC v2 との関係 残る受入れ証拠
AS0 ROA 批准済み、Awaiting Implementation、内部試験と予定された部分 beta 文書どおりの完全実装がポータルに依存 オブジェクト、範囲、部分／完全境界、訂正、有効化、継続公開
番号資源移転 2026 年 2 月 4 日批准、手順対応付け中 技術システムをポータル後に優先 経路・相手別 end-to-end 試験、判断、登録、通知、再開と訂正
Abuse contact 2026 年 2 月 4 日批准 内部技術をポータル完了後に優先 Draft 7 への結合、検証、通知、訂正、例外、結果の境界
階層 AS-SET Last Call の提案 WHOIS／ポータル変更を評価、優先は後 批准、最終文書、全作成経路、既存オブジェクト保護と訂正

公開できる最小の受入れ台帳

ソースコード、内部 ticket、会員書類、認証情報を公開する必要はない。必要なのは、状態を上書きせず追記する小さな台帳である。

最初の項目は政策名、識別子、版、権限状態である。これにより、議論中に準備したソフトウェアを後から誤った draft に帰属させずに済む。AS-SET は別の決定があるまで提案の欄に残る。

次は release baseline である。MyAFRINIC v2 はプログラム名であり、再現可能な版ではない。release ID または日付付き基準が、何を試したかを示す必要がある。patch が政策動作を変えたら、新しい事象を追加し、過去の受入れを書き換えない。

依存分類も要る。画面、WHOIS、IRR、RPKI、内部 workflow、データ移行、外部 RIR 手順を区別する。見える front-end の成功が、未試験の back-end や相手手順に完了を与えるのを防ぐためである。

さらに、前提条件、責任者、試験ケース、受入れ基準を記す。責任帰属は非難ではない。Registry Products は baseline、Member Services は移転経路、運用チームは公開や検証、政策手続は文書権限を証言できる。

試験参加者も重要である。内部試験は規則と統合、UAT は会員の役割と作業、beta は運用に近い相互作用を調べる。参加募集は結果ではなく、実験室の成功は会員受入れではない。

最後に、部分と完全、有効化の通知と時刻、例外、rollback、訂正、観察期間を定義する。ポータル可用性は基盤指標である。AS0 の範囲、移転経路、検証状態、全入口での規則適用は政策指標である。

一つの障害表示では足りない

共通プラットフォームは、正常・低下・停止という共通の言葉を持ちやすい。しかし四政策の例外は異なる。AS0 ではポータルが正常でも、期待オブジェクトが公開されない、または訂正が反映されない場合がある。測るべきは uptime だけでなく公開結果である。

移転の「待機中」は、書類不足、AFRINIC 審査、相手 RIR の状態、技術更新のどれでもあり得る。機関上の境界と次の行動を示さなければ、監査可能な状態ではない。

Abuse contact では、送信、配信、応答、訂正を分ける必要がある。技術信号が静かに政策判断へ変わってはならない。AS-SET では、批准前の有効化は権限問題であり、批准後は未適用の作成入口や既存オブジェクトの誤変更が実装問題になる。

したがって、四つの緑表示は四つの受入れではない。各行で「緑」が何を意味するかを定義しなければならない。個人情報やセキュリティ詳細を出さず、定義と集計結果を公開することはできる。

Release note と政策受入れを分離する

通常の release note は、製品に何を追加したかを示す。しかし、その動作が権限を得たか、全ケースを覆うか、外部手順を通るかまでは示さない。同じ機能を二つの関連記録に載せる必要がある。技術的なリリース構成と、政策上の受入れである。

技術記録は、画面、WHOIS ルール、IRR 統合、通知機構が baseline に存在すると言える。政策記録は、どの文書が動作を許し、いつ実際の行為を支配し、どのケースを通過したかを言う。この二重記録は余分な官僚制ではない。準備済みコードが早すぎる権限を持つことと、批准文書が動くサービスの錯覚を作ることを同時に防ぐ。

段階導入にも役立つ。基盤を先に公開し、政策機能を無効のままにすることができる。限定試験者だけに開くことも、移行期に手動訂正を残すこともできる。範囲、責任者、次の条件が明示されれば、どの選択も評価可能である。

有効化と観察期間も分ける。規則をオンにしたことは持続動作の証明ではない。AS0 は公開、移転は有効カテゴリごとの結果、abuse contact は通知と訂正、AS-SET は全入口の一貫動作を観察する。観察期間が、機能デモを手続証拠に変える。

資料が証明していないこと

確認資料は、MyAFRINIC v2 の production 稼働、UAT/beta 完了、AS-SET 批准、AS0・移転・abuse contact の完全実装を証明しない。停止、期限超過、試験失敗、移転拒否、無効連絡先、AS-SET 衝突、RPKI 経路影響も証明しない。

共有依存によって損害を受けた会員も、この記録には存在しない。架空の当事者を置けば、証拠設計は告発物語に変わってしまう。

AFRINIC はすでに精密な言葉を使っている。Awaiting Implementation、内部試験、partly implemented、手順対応付け、ポータル後の優先、Last Call である。これは台帳の骨格になる。あとは版、試験、訂正を結ぶ必要がある。

そうすれば MyAFRINIC v2 は共通基盤であり続け、四政策共通の施行証明にはならない。ポータル公開の後に、四つの受入れが始まる。

情報源