要約

  • 2026年8月30日付のAFRINIC公式データベースには、厳密な remarks: Geofeed HTTPS-URL 形式が3,790オブジェクトにある。ただしRFC 9632の対象となる inetnum と inet6num は3,573件である。
  • remarks形式は欠陥ではない。専用の geofeed: を実装していないレジストリ向けにRFC 9632が明示した互換方式であり、移行中の利用者は両形式を読めなければならない。
  • 現行のAFRINICアドレスオブジェクト定義には remarks: はあるが geofeed: はない。公開DBWGでは作業項目化と影響評価が求められたが、2026年8月までの公開記録に最終処理は見当たらない。
  • 必要なのは即時実装の号令ではなく、権限、検証、競合、既存データ、WHOIS/RDAP、プライバシー、認証、試験、撤回条件をまとめた有限の移行レシートである。

3,790は検索結果であり、3,573は意味を持つ集計である。

AFRINICが公開するデータベースダンプを厳密な文字列で数えると、remarks: の後に大文字小文字を区別した Geofeed とHTTPS URLが続く行は3,790件ある。ところがRPSLオブジェクト単位で分類すると、3,483件が inetnum、90件が inet6num で、合計は3,573件になる。

差の217件は、route に168件、route6 に41件、domain に5件、as-set に2件、organisation に1件ある。どれも文字列としては厳密な形だが、RFC 9632 がGeofeed探索を説明するアドレスオブジェクトではない。

この差を不正データの件数と呼ぶべきではない。備考欄には型がない、というだけである。登録者は運用連絡も、証明書も、注意書きも、Geofeedへのポインターも書ける。受け手が合図を知っていれば機械処理は可能だが、スキーマはその一行を他の文章から区別していない。

そのため本稿は3,573を見出しに置く。3,790はRPSL全体における文字列の広がりを示し、3,573は標準の文脈に沿うアドレスオブジェクトを示す。前者だけなら対象を取り違え、後者だけなら備考という汎用領域から意味がはみ出す現象を見落とす。

現行方式には、先に認めるべき合理性がある

専用フィールドがないことと、Geofeedが機能していないことは同じではない。

RFC 9632は、すべてのRIRが同時にRPSLを変更するとは想定していない。geofeed: がないデータベースには、厳密なremarks形式を定めている。さらに、全レジストリが専用フィールドへの移行を表明し、登録者の移行も完了するまでは、利用者が両方を処理することを求める。AFRINICのremarksを「旧式だから無効」と捨てる収集者の方が、互換性を損なう。

実利用も小さくない。3,573件のアドレスオブジェクトは106種類のHTTPS URLを参照する。状態別では ASSIGNED PA が3,461件、ALLOCATED PA が71件、ALLOCATED-BY-RIR が17件、ASSIGNED PI が13件、SUB-ALLOCATED PA が11件である。一つのファイルで複数プレフィックスを扱う運用者がいるため、URLの重複はそれ自体として異常ではない。

この数字から、URLが常に到達可能だとも、位置情報が正しいとも、全ての利用者が参照しているとも言えない。ただ、互換方式が現実の登録慣行になっていることは分かる。移行は、きれいなテンプレートを得るために既存の利用者を切り捨てる作業であってはならない。

AFRINIC側にも慎重になる理由がある。フィールドを一つ追加すれば、更新認証、Web入力、メール更新、バルクデータ、WHOIS、RDAP、バリデーター、文書、サポートが連動する。remarksと専用フィールドの双方があれば優先順位が必要になる。既存の表記揺れを自動変換するなら、元の意図を壊さない証拠が要る。

「標準に書いてあるから追加すべきだ」だけでは影響評価にならない。現行方式が有効であるほど、移行設計は具体的でなければならない。

専用フィールドが保証する範囲

RFC 9632は、remarks形式をRIRが形式的に検査できないと説明する。したがって、一つのアドレスオブジェクトには原則一つのGeofeed参照だけを置くという規律も、備考欄では強制しにくい。専用フィールドなら、HTTPS URLの形式、出現回数、二重登録、競合をデータベース側で扱える。

現行ダンプには、大文字小文字を問わずGeofeedらしいremarksを持つアドレスオブジェクトが3,592件あり、厳密形から外れる行は106件ある。Geofeed: のようにコロンを挟むもの、小文字のもの、HTTPを使うものが含まれる。各収集者が実際に拒否するかは別問題である。重要なのは、文章として格納された規則は、スキーマが止めないまま変形するという点だ。

ただし専用フィールドが検証できるのはポインターの構造であって、地理的事実ではない。

HTTPSは指定されたWebエンドポイントとの通信を保護し、そのエンドポイントの証明書を検証する。IPアドレス空間を代表する権限までは証明しない。RFC 9632が任意のRPKI署名方式を用意するのは、その別の層を補うためである。それでも署名は、ファイルと資源証明書の関係を強めるのであって、ファイル内の都市や国が常に正しいことを保証しない。

判断を混ぜないため、四つの問いに分けるとよい。

問い 主な仕組み 限界
これはGeofeedポインターか geofeed: または厳密なremarks 内容の正確さは分からない
URLへの通信は保護されるか HTTPS 資源を代表する権限は分からない
発行者はアドレス空間と結び付くか 任意のRPKI署名 現実の位置までは保証しない
位置は正確で安全か 運用検証、更新、プライバシー管理 レジストリのフィールドだけでは決められない

APNICのGeofeedフィールドを扱った既存記事は、リンク認証と位置の真実を区別した。本稿の中心はそこではない。AFRINICでは、そのリンク自体がまだ一般の備考から構造的に分離されていない。

公開の作業項目には公開の処理結果が要る

専用フィールドの提案は2025年10月、AFRINICのDatabase Working Groupに現れた。

10月27日、参加者は geofeed: の追加と資源保有者による更新を提案した。現行のremarks方式を説明しつつ、少なくとも自らのPI資源ではhostmasterの支援が必要だったという経験を記した。翌日、共同議長は2週間の議論期間を設け、スタッフに長所と短所を含む影響評価を準備するよう求めた。

11月14日、共同議長は反対意見がなかったとして、AFRINICスタッフに作業項目として受け取り、実装方法と影響評価を示すよう要請した。2026年4月6日には提案者が報告を求め、4月16日には共同議長が有効な作業項目かどうかの確認を再度求めた。4月17日には別の参加者も支持した。

確認した公開アーカイブでは、2026年1月、2月、3月、4月、8月にメッセージがあり、5月から7月の月別アーカイブはない。8月までのスレッド索引に、4月17日より後のGeofeed件名は見当たらなかった。

ここから言えるのは、「確認した公開DBWG記録には、その後の回答または処理結果がない」ということだけだ。内部チケットがない、技術検討をしていない、私的な対話がないとは言えない。公開メーリングリストは全ての仕事を映す監視カメラではない。

それでも、公開に作業項目化を求めた以上、公開に状態を返す価値がある。採用、延期、却下、他案件への統合、依存待ちのどれでもよい。結論を強制するのではなく、結論の所在を明らかにするのである。

PIの13件は「全員」を意味しない

提案者が述べたPI資源の更新問題には、限定した裏付けがある。厳密形式のGeofeedを持つ ASSIGNED PI アドレスオブジェクトは13件で、その全ての mnt-by に AFRINIC-HM-MNT が含まれる。下位の管理属性には資源ごとのmaintainerも見える。

この配置は、オブジェクトそのものを保護する主体と、より具体的な登録を管理する主体が異なり得ることを示す。だが、利用可能なサポート経路、例外、更新APIの認証判定まではダンプから分からない。13件を根拠に「全PI保有者が更新できない」と一般化してはならない。

必要なのは、状態とmaintainer関係ごとの更新権限表である。誰が追加、変更、削除、訂正できるのか。どのインターフェースを使うのか。直接認証できないとき、どこへ依頼し、どの番号で結果を追えるのか。権限を公開することは、無制限な自己更新を意味しない。むしろ、不正更新を防ぎながら正当な訂正を遅らせない境界を作る。

RDAPでは意味がまだ文章に閉じ込められている

160.115.0.0のAFRINIC RDAP応答には、GeofeedのHTTPS URLが含まれる。ただし場所は一般的なremarks descriptionである。rdapConformance は rdap_level_0、nro_rdap_profile_0、cidr0 で、geofeed1 はなく、標準のGeofeedリンクもない。

RFC 9877 は rel: geofeed と任意の geofeed1 拡張を定義する。サーバーはGeofeedリンクを返してよい。geofeed1 を宣言する場合、保有し公開可能なURLには対応リンクを返さなければならない。AFRINICは宣言していないため、現行応答をRFC違反とは言えない。

ここで見えるのは違反ではなく、構造化の選択肢である。人間は備考を読める。専用パーサーも文字列を探せる。一般のRDAPクライアントは、conformanceからGeofeed提供を予測できず、標準リンクとして扱うには独自解析が要る。データは存在するのに、意味の契約がインターフェースを越えていない。

結論を決めずに、決定を記録する

移行レシートには、少なくとも次を含めるべきだ。

  1. 作業項目ID、担当、受理日、状態、次回見直し日。
  2. 現在と目標のWHOISスキーマ版。
  3. 更新方法、バルクデータ、WHOIS、RDAP、利用者への影響評価。
  4. オブジェクト種別、状態、maintainer関係ごとの権限。
  5. 許容するHTTPS構文、件数、検証エラー。
  6. remarksと専用フィールドの共存・競合時の優先順位。
  7. 厳密形、表記揺れ、他クラスにある既存行の扱い。
  8. RDAP geofeed1 とリンク出力の判断。
  9. URL構文、HTTPS、RPKI、位置正確性を混同しない説明。
  10. 細粒度位置に関するプライバシー注意。
  11. 試験対象、互換性結果、訂正窓口、ロールバック条件。
  12. 実装または終了の版、日付、監視結果、未解決例外。

この記録は実装賛成票ではない。現行方式を維持する結論にも使える。まず厳密remarksの検証だけを強化する段階案にも、WHOISの後でRDAPを追加する案にも使える。必要なのは、公開された提案が無期限の現在形に留まらないことだ。

レジストリは、地理情報の裁判所になる必要はない。何を構造として認識し、何を単に運ぶのかを明確にする記録係であればよい。その節度を実装する最小単位が、専用フィールドと公開された決定履歴である。