要約

  • AFPUB-2026-ASN-001-DRAFT02は、新しく作るAFRINIC AS-SETの名前をASNから始まる階層構造にし、その根のASNに結び付いた認証情報で作成権限を確かめようとする。これは一意性と支配証明を守る、狭く機械検証可能な帳簿機能である。
  • この検査が証明できるのは、新規名を作る時点で申請者が根のASNを管理していたことまでだ。AS-SETのメンバーが正しいこと、経路起点が正当であること、あるフィルターを採用すべきこと、AFRINICが経路やネットワークを支配することは証明しない。
  • 既存の非階層名は改名されず、利用と編集が続く。誤削除された非階層名を個別に復元する例外は、決定的な規則へ裁量を戻す。判断主体、基準、証拠、再審、監査方法は、確認した資料には示されていない。
  • 2026年8月9日の証拠期限時点で、公式一覧は草案を「Under Discussion」、提案ページは「Last Call」と表示していた。採択通知、最終CPM本文、リリースノート、本番の受理・拒否試験は確認されていない。提案、採択、コード、運用は別の事実である。

名前の穴は、支配の許可証ではない

非階層AS-SET名には構造上の空白がある。AS-EXAMPLEのような文字列は、どのASNの管理者がその名を作ったのかを名前自体に刻まない。メンテナー資格情報による操作認証が正しくても、その資格情報の保有者と、名前が示唆するネットワークとの関係までは証明できない。同じ文字列を複数の自律したIRRがそれぞれ受理すれば、情報源ごとに管理者やメンバーの異なる同名オブジェクトが生じ得る。

ここで必要なのは、レジストリ権力の拡張ではない。帳簿の入口における狭い整合性検査である。名前を番号資源の支配証明に結び付け、無関係な者が他者のASNを根にした新規名を作れないようにする。その限りで、DRAFT02は正しい問題を扱っている。

だが、入口の検査を主権へ膨らませてはならない。AFRINICはAS-SET名を記録できる。重複や不整合を防ぐために作成要求を検査できる。どの認証が受理されたかを監査可能にできる。そこから、経路の所有、経路方針の正否、事業者の商業判断、接続相手の選択、フィルターの採否、ネットワークの正当性を決める権限は生まれない。

これは制度設計上の好みではなく、境界そのものである。レジストリは帳簿係である。帳簿係は記録する。調整する。一意性を守る。現実に従って帳簿を正す。帳簿を用いて現実を罰し、消し、所有することはできない。

草案が実際に検査しようとしているもの

提案されたCPM 7.8では、新しく作るAFRINIC AS-SETの第1要素をASに続くASN、第2要素をAS-で始まるAS-SET名とし、各要素をコロンで区切る。その後ろにはASNまたはAS-SET名を置ける。単純化した形ならAS123:AS-CUSTOMERSである。これは実在の登録や所有関係を示す例ではない。

重要なのは表記の外観ではなく、認証の鎖だ。最初の子を作る申請者は、根に置いたASNの認証情報で権限を示す。さらに深い子を作る時は、RFC 2622の階層モデルに従い、直上の親AS-SETのメンテナーが作成を認可する。根のASNから最初の集合へ、親集合から子集合へ、名前空間の作成権限をたどれる。

この検査は、共通層に置いてよい。理由は明確である。一意性、支配証明、衝突回避、記録精度という、独立したネットワークが協調するための最小条件に直接結び付き、同じ入力へ同じ結果を返す規則として実装できるからだ。ASNの認証を通せない者がそのASNを根にした最初の子を作ろうとすれば、通常経路は拒否する。親の認証を通せない者が深い子を作ろうとすれば、拒否する。ここに政策的な善悪判断は要らない。

狭い認証が強いのは、狭いままだからである。証明するのは、ある作成要求と、根または直上親の管理権限との関係だ。名前を構成するメンバーの正確性は証明しない。現在の経路起点は証明しない。経路を受け入れるべきかは決めない。接続関係を命じない。RPKIを置き換えない。ネットワーク事業者の判断をAFRINICへ移さない。

記録は現実を記述し、創造しない

AS-SETはIRRに記録され、事業者が集合を展開してフィルターや接続判断に利用し得る。しかし、稼働するルーティングの現実は、データベースの宣言だけで生まれない。各事業者がどのIRRを照会し、どの情報源を優先し、集合をどう展開し、どのフィルターを設置し、誰と接続するかによって現れる。

したがって、AFRINICの記録が正しいことと、AFRINICが経路を所有することは別である。AS-SET作成時のASN認証が正しいことと、AFRINICがその後の経路方針を裁くことも別である。データベース上の受理は、運用上の命令ではない。データベース上の拒否は、ネットワークの存在を消す判決ではない。

草案が守り得るのは、将来作られるAFRINIC AS-SET名について、帳簿上の根と認証上の根を一致させることだ。その一致は、利用者が新しい名前の由来を確かめる費用を下げ得る。意図しない同名集合や空集合を調べる作業を減らし得る。しかし、下流の事業者が情報源修飾を失い、旧名を使い、メンバーを誤り、キャッシュを誤って扱い、別の方針を採る可能性までは消さない。

記録の精度は必要である。だからこそ、記録の限界も正確でなければならない。帳簿が現実を記述するという原則を守るには、帳簿に書かれていないものを無効と呼ばず、帳簿に書かれたものを完全な運用真実と呼ばないことが必要である。

コミュニティ、Board、スタッフ、RSAは主権を作れない

提案者は提案できる。政策会合の参加者は議論できる。Boardは会社の内部機関として決定できる。スタッフは影響を評価し、採択後のシステム変更を実施できる。RSAは契約関係を定め得る。それぞれに役割はある。しかし、そのどれも、AFRINICをネットワーク上の主権者にはしない。

コミュニティ合意は所有権ではない。会合は立法府ではない。Board決議は、稼働する独立ネットワーク全体への主権委任ではない。スタッフ評価は、政策の採択でも、技術的稼働でも、経路方針への命令でもない。RSAは契約であり、インターネットの憲法ではない。長年の慣行、他機関からの承認、参加者の反復的な同意も、後から主権を発生させない。

この区別はDRAFT02を弱めない。逆に、その正しい価値を救う。AS-SET名の根をASN認証へ結び付ける規則は、AFRINICに広い統治権があるから正当なのではない。一意性と支配証明に必要な最小の検査であり、利用者が局所的に結果を確かめられるから有用なのである。

共通層に許されるのは、名前の構文、根の認証、親子の認可、衝突規則、監査可能な状態遷移である。共通層に許されないのは、どの事業モデルが好ましいか、どの経路方針が道徳的か、どの相手と接続すべきか、誰を処罰すべきか、非採用者を無効と呼ぶか、といった判断である。後者は帳簿機能ではない。

標準、提案、コード、運用を混ぜない

RFC 2622は、RPSLの階層名、コロンによる区切り、直上の親メンテナーが子の作成を認可するモデルを示す。同時に、登録手続きはRFCの範囲外である。したがって、階層構文が標準に存在することは、AFRINICがその構文を義務化した証拠ではない。

DRAFT02は、その構文と認証モデルをAFRINICの新規AS-SET作成に適用しようとする提案である。提案文が存在することは、採択の証拠ではない。採択が将来確認されても、それだけでWHOIS、MyAFRINIC、APIが同じ検査を実行している証拠にはならない。コードが配備されても、全入口で同じ拒否条件と監査記録が働かなければ、運用上の保証は完成しない。

順序は逆にできない。文書が現実を命じ、参加者が後から従うのではない。最小規則を実装し、検証し、実際の入口で動かし、事業者がその結果に依拠できるようになって初めて、文書は採用された現実を記述できる。提案は現実ではない。発表は現実ではない。コードが走り、同じ入力が同じ理由で受理または拒否されることが現実である。

公式表示が食い違う以上、採択を推定してはならない

DRAFT01は2026年5月15日に提出され、メーリングリストでの意見を受けたDRAFT02が6月8日に提出された。間隔は24日だった。AFRINICスタッフの影響評価は7日後の6月15日付で、提案ページはさらに9日後の6月24日にAF37で提示されたと記している。

しかし、2026年8月9日の証拠期限において、AFRINICの公式な二つの表示は一致していなかった。現行提案一覧は「Under Discussion」、提案ページは「Last Call」としていた。確認した公式資料には、食い違いを解く日付付き通知や議事記録がない。採択通知、最終CPM本文、WHOISのリリースノート、本番環境の受理・拒否試験も確認されていない。

この不確実性は、AFRINICに敬意を払うための形式的な留保ではない。帳簿と現実を分けるための証拠規律である。提案ページは、提案者が何を提案したか、スタッフが何を評価したか、ページがどの状態表示を掲げたかの証拠にはなる。提案が採択され、コードが配備され、全入口で動いていることの証拠にはならない。

日付も地位を創造しない。24日、7日、9日という間隔は、改訂、評価、発表の時間を示すだけだ。合意の強さ、正式なLast Callの開始、採択、実装完了を補わない。公式記録が矛盾する時、強い方の表示を選ぶことは分析ではない。

既存名を残すことは、過去の曖昧さを残すことでもある

草案は既存AS-SETへ三つの継続保護を置く。強制改名しない。非階層名の利用を続けられる。通常の編集を改名の契機にしない。すでに外部の設定、文書、ピアリング情報、自動処理から参照されている名前を一斉変更すれば、帳簿の整理が稼働中のネットワークへ破壊を輸出し得るからである。

運用継続を守るこの判断は、薄い共通層の原則に合う。レジストリは帳簿を整えるために、稼働するネットワークを人質にしてはならない。過去の名前が技術的に美しくないからといって、参照を切断し、事業者へ一斉移行を命じる権威はない。

同時に、既存非階層名を残す以上、過去の曖昧さは残る。新規名のASN根が検証可能になっても、旧名は同じ保証を持たない。外部IRRもAFRINICの規則に拘束されない。未来の入口は狭められても、過去の帳簿と他の帳簿は一度に書き換わらない。

これは草案の失敗ではなく、保証の境界である。継続性を守るために非遡及を選ぶなら、その代価を正直に記録しなければならない。「一意性が完成した」と言ってはならない。正確な説明は、「AFRINICの通常経路で今後作られる名前の根について、認証可能な一類型の保証を加える」である。

復元例外は、帳簿係が裁量権を手にする場所である

DRAFT02は、誤って削除された既存の非階層AS-SETを復元する場合を例に、個別例外を必須とする。AFRINICスタッフは、例外理由を記録することを提案し、復元またはrecallが運用上の抜け道となって目的を損ない得ると警告した。

ここが草案の最も危険な境界である。通常規則なら、根のASN認証または親メンテナー認証という、局所的に検証できる条件で答えを出せる。復元では、消えた文字列を以前の状態へ戻すのか、禁止された形式を新たに作るのかを誰かが判断する。確認した資料には、その判断者、適格基準、必要証拠、期限、再審、件数公表、監査方法がない。

継続性を守る救済は必要になり得る。だが、その必要性は、帳簿係へ自由裁量を与える理由にはならない。例外は、削除前オブジェクトとの同一性、旧メンテナーとの連続性、履歴、理由、時点を用いて、できる限り決定的に狭めなければならない。これは現行草案に既に書かれた要件ではなく、裁量を通常の作成経路へ変えないための分析上の必要条件である。

AFRINICが復元を認めても、経路を所有するわけではない。拒否しても、外部の設定や稼働するネットワークの現実を消せるわけではない。帳簿係にできるのは、どの状態を自らの帳簿に戻したか、その根拠と履歴を正確に記録することだけである。復元を処罰、恩赦、政策服従の手段へ変えた瞬間、狭い調整は裁量執行へ変質する。

比較資料が証明するのは、各地の行為だけである

APNICの公式記録はprop-151を実装済みとし、既存AS-SETを残しながら新規の非階層名を制限したことを示す。RIPE Databaseの公式記録は、リリース1.105で新規の非階層AS-SET作成を制限したこと、既存名は更新または削除できたこと、削除後の非階層名は公表された説明上再作成できなかったことを示す。

LACNICの公式技術記事は、ASNを根にした階層AS-SETの使用例を示す。しかし、確認したLACNIC自身の資料だけでは、すべての作成経路が非階層名を拒否する完全な執行規則までは立証できない。ARINの公式資料は、2025年の協議、番号資源政策の範囲外としての提案却下、将来機能一覧への追加を示す。導入を示さない。

公式資料から導入済みの執行を直接確認できた比較対象は、APNICとRIPE NCCの二つである。これはLACNICに執行がないという主張ではない。ARINが導入しないという予測でもない。証拠期限までに、何を直接確認できたかという記録にすぎない。

各地域の公式資料は各地域の行為の証拠である。AFRINICへ権威を移転しない。あるRIRの実装は、別のRIRによる統治の正当性を作らない。五つのRIRが似た文法を使っても、共同主権は生まれない。共通化できるのは、構文、認証、衝突規則、検証方法という最小の技術条件であって、地域組織の裁量ではない。

提案者の主張と、確認できる結論を分ける

提案者James Bensleyは、AS-SET名が五つのRIR運営IRRをまたいで一意ではなく、複数情報源を集約するリゾルバーが誤った集合または空集合を返し得ると述べている。さらに、AFRINICが提案を実装すれば、五つの主要RIRをまたぐAS-SET squattingが不可能になるという趣旨の主張をしている。

最初の仕組みは、RFCの名前空間設計と運用上の衝突例から理解できる。MANRSは、無関係なメンテナーが非階層名を作成できた一方、権限のないASNを根にした階層名の作成が失敗した例と、RADBとRIPEにまたがるAS-AMAZONの衝突を示した。ただし、その衝突が悪意によるものだったとは確認できない。

二つ目の世界的な結論は広すぎる。ARINは将来機能の段階で、LACNICの全作成経路における執行は確認できず、既存の非階層名は残り、AFRINIC自身にも復元例外があり、第三者IRRは草案の外にある。したがって、確認できる結論はもっと狭い。採択され、すべての作成経路へ一貫して実装された場合、DRAFT02はAFRINIC内部の将来の新規名について、ASN根を権限なく用いる余地を縮める。

AFRINICスタッフは、会員への影響を小さな学習負担と自動化またはツール更新と評価した。これはスタッフの見積もりであり、会員調査でも費用研究でもない。スタッフは六つのシステムを分類し、WHOISとMyAFRINICを直接変更、RDAPをWHOISからの反映、NetSuite、NMRP、RPKIを変更不要とした。この六という数は、開発工数、予算、試験量を示さない。

スタッフは作業をMyAFRINIC v2の後に優先するとし、当時のv2予定日を2026年11月15日とした。証拠期限から98日後だが、見込みであって納入の約束ではない。スタッフの発言は、スタッフがそう評価し予定したことの証拠である。採択、実装、効果、権威の証拠ではない。

IRR、情報源選択、RPKIは別の制御層である

IRRは経路方針の文脈を記述し、AS-SETは複数ASNを集合として扱う手掛かりを与える。RPKIは暗号学的な経路起点認証を扱う。DRAFT02はRPKIを変更せず、置き換えない。AFRINICスタッフもRPKIを変更不要と評価した。

また、利用者は情報源付き参照を使える。PeeringDBのGoogle LLCの公開記録は、ASN 15169とRADB::AS-GOOGLEを示している。これは、情報源とオブジェクト名を一緒に運べる一例である。他のIRRにある同名オブジェクトの現在の内容や所有を証明するものではない。

情報源修飾は強い反対論を作る。利用者が情報源を明示し、優先順位を固定し、集合展開を検査すれば、階層命名だけが曖昧さへの答えではない。草案は、メンバー精度、古いオブジェクト、外部IRR、リゾルバーの優先順位、RPKIの起点妥当性を直さない。ツール改修の費用に対し、AFRINIC固有の衝突件数、事故率、損失額、削減額も確認できない。

それでも、情報源修飾とASN根認証は同じ場所を守るものではない。前者は利用者が下流で曖昧さを解く。後者は帳簿の入口で、権限のない新規名の一類型を拒否する。転記、API、文書、設定の途中で情報源修飾が失われる可能性がある以上、入口の狭い予防線には独立した価値がある。ただし、その価値を一般的なルーティング安全や世界的な一意性へ拡張してはならない。

被害規模は未計測である

確認した資料には、AFRINICの非階層AS-SET総数、複数IRR間の同名衝突数、衝突が実害へ進んだ件数、損失額、例外件数がない。分子、分母、時系列がなく、発生率を計算できない。個別例と構造上の仕組みから、地域全体の事故率を推定してはならない。

同名衝突から障害までは一直線ではない。情報源の優先順位、集約方法、空集合時の処理、キャッシュ、フィルター生成、反映時点、相手側の設定が介在する。同じ衝突でも、一つの情報源へ固定した事業者と、複数情報源を集約する事業者では結果が違い得る。

したがって、草案を支持するために大災害を想像する必要はない。権限のない新規名を入口で拒否することは、損害額を誇張しなくても、一意性と記録精度のために説明できる。同時に、定量資料がない以上、事故削減率、金銭便益、世界的効果を断定してはならない。doctrineは証拠規律を免除しない。むしろ帳簿を真実へ従わせるため、帰属と不確実性を厳格にする。

NRS、Heng Lu、LARUS、BTW、MANRS、PeeringDBの位置

NRSは提言、調査、対話の場づくり、明示的に委任した会員の代表を行い得る。レジストリ、RPKI、WHOIS/RDAP、異議申立て、和解、選挙、資産保全、事業継続を運営しない。この境界を越えてNRSを代替レジストリのように描くことはできない。

Heng Luのdoctrineは本稿を支配する原則である。レジストリは帳簿係であり、記録は現実を記述し、創造しない。共通層は一意性、支配証明、記録精度、セキュリティ、相互運用、監査可能性に薄く限定される。後の変化は、提案や会議の宣言ではなく、実装、局所検証、稼働、採用によって現実になる。非採用は違反ではない。裁量的な処罰層を共通帳簿へ混ぜてはならない。

LARUSの資料は、レジストリ認証、IRR記録、稼働するルーティングが別の制御層であることを扱う。BTWの既存記事は、IRRの一般的な脆弱性、route object、情報源、古い記録、重複メンバーなど隣接領域を既に扱っているため、本稿はそこへ広がらない。MANRSは作成時認証と衝突の運用例を示す。PeeringDBは情報源付き識別子の利用例を示す。いずれも、AFRINICの採択、実装、ネットワークへの権威を作らない。

条件付きなのは効果であり、境界ではない

DRAFT02が採択され、WHOIS、MyAFRINIC、APIの全作成経路で同じ構文、根のASN認証、親メンテナー認証が実装され、例外が決定的かつ監査可能に狭められるなら、AFRINIC内部の将来の新規AS-SET名は、現在より強い支配証明を持ち得る。これは条件付きの技術評価である。

一方、AFRINICの境界は条件付きではない。コミュニティ合意が増えても、Boardが決議しても、スタッフが実装しても、RSAへ条項を加えても、AFRINICはルーティング現実の所有者にならない。政策違反というラベルだけでネットワークを罰する権威を得ない。事業者の経路方針を裁く権威を得ない。帳簿を使って現実を無効化する権威を得ない。

この草案の正しい姿は、統治の拡張ではなく、帳簿の自己限定である。AFRINICが検査してよいのは、新規名の構文と、その根または親を支配する証明である。利用者が決めるのは、どの情報源を信頼し、どの集合を展開し、どのフィルターを置き、誰と接続するかである。レジストリが正確であるほど、この分離は鮮明でなければならない。

帳簿係が世界を作ったのではない。帳簿係の仕事は、世界について嘘をつかないことである。

情報源