要約

  • ARINは2024年6月、共通のIETF標準が受け入れられれば、RDAP、ARIN Online、Reg-RWSにgeofeed機能を実装し、開発と展開が終わるまで提案をOpenにすると回答した。
  • RFC 9877は2025年10月にStandards Track RFCとなり、geofeed1、rel=geofeed、application/geofeed+csvを定義した。IANA登録も済んでいる。
  • 2026年9月12日に取得したARINの提案一覧では2024.10がOpenのままで、現行RDAP help応答はgeofeed1を掲げていない。選んだ一つのネットワーク応答ではURLが依然としてコメントに入っていた。
  • これは開発停止や全データベースでの未対応を証明しない。標準の発火条件、各インターフェース、旧コメント移行、バルク提供、プライバシー、試験、ロールバックを結ぶ公開の展開記録が必要だという証拠である。

完成した仕様と、終わらない但し書き

製品ロードマップの「標準化待ち」は合理的である。五つのRIRが同じ機能を別々の形で実装すれば、利用者はレジストリごとの例外をコードに埋め込むことになる。待つことで相互運用性を買えるなら、その時間には価値がある。

ただし「待つ」は外部イベントを条件にした状態である。イベントが起きた後は、同じ言葉は状態説明にならない。条件が満たされたのか、別の条件が残るのか、どの製品が試験中なのかを示す必要がある。

ACSP Suggestion 2024.10は2024年6月3日に提出された。提案は、ARINのネットワークオブジェクトに任意のgeofeed属性を加えることを求めた。当時の実務では、資源保有者がRegistration CommentsにGeofeed [URL]のような行を書き、利用側が自由文からURLを読み取る。提案者は、この方法を壊れやすいものとし、標準化された発見経路を求めた。

ARINは6月7日、五つのRIRがIETFでRDAP拡張に取り組んでいると答えた。そして「標準が受け入れられたら」、RDAPに変更を実装し、ARIN OnlineとReg-RWSにも必要な機能を加えるとした。RIR間で一貫したバルクRDAP形式の作業にも触れ、機能が開発・展開されるまで提案はOpenだと説明した。

期限は書かれていない。「受け入れ」がRFC発行なのか、IESG承認なのか、NROの運用プロファイルなのかも定義されていない。そのため、現在の状態から契約違反や遅延を断定することはできない。それでも、ARIN自身が外部の標準イベントを節目に選んだ事実は残る。

RFC 9877がクライアントに与える約束

RFC 9877は2025年10月にStandards Trackとして公表された。ここで標準が与えたのは、単なるJSONキーではない。リンク関係geofeedはリンクの目的を、媒体型application/geofeed+csvは取得先の表現を示す。拡張識別子geofeed1は、サーバーがIPネットワークオブジェクト用のgeofeed URLをホストする能力を表明する。IANAのRDAP Extensionsレジストリにも登録された。

サーバーがgeofeed1を使うなら、help応答と、IPネットワークオブジェクトを含むlookup/search応答のrdapConformanceにその識別子を含めなければならない。対象オブジェクトのURLを保持し、規制などで省略する必要がない場合は、対応するgeofeedリンクを返す。

この仕組みの利点は、リンクが「ない」場合にも境界が生まれることである。拡張を宣言したサーバーなら、クライアントは宣言された規則の中で不在を解釈できる。宣言がなければ、単にその応答にリンクがないとしか言えない。

さらにRFCは、登録済みのリンク関係と媒体型だけを使い、geofeed1を宣言しない実装も認めている。したがって、help応答のトークンは重要な観測点だが、トークンの不在から「どこにも標準リンクがない」とは言えない。この留保は弱さではなく、プロトコルに忠実な読み方である。

現行サービスから読めること、読めないこと

2026年9月12日に取得したARINのRDAP help応答には、rdap_level_0、NROプロファイル、CIDR、origin-AS、RIR検索など複数の項目が入っていた。geofeed1はなかった。確定できるのは、その時点のその応答がRFC 9877拡張を表明していなかったことだけだ。

内部の開発ブランチ、限定試験、ARIN Onlineの未公開画面、RIR間の合意待ちは見えない。Open状態も同様で、業務フロー上の公開ラベルであって、作業していないという証明ではない。

もう一つ、154.54.100.0/22の応答を選んで確認した。Registration CommentsにGeofeed ai.net/geofeed.csvがあり、rdapConformanceにgeofeed1はない。リンクはself、alternate、upで、rel=geofeedはない。

これは提案が問題にした旧方式を示す具体例である。母集団を代表する無作為標本ではない。ARIN内の全geofeedがコメント形式だとも、他のオブジェクトに型付きリンクがないとも言えない。URL先のファイルが最新か、認証済みか、地理的に正しいかも、この応答からは分からない。

それでも一つの判断材料になる。新しい型付き経路を導入するなら、既に公開されているコメントをどう扱うかという移行設計が必要である。

ARIN 57の一文は何を待っていたのか

2026年4月のARIN 57で、技術報告はgeofeedとRPKI directory servicesのRDAP拡張に取り組んでおり、「今まさにIETFを通っている」と述べた。RFC 9877の発行から約半年後である。

この一文だけで矛盾を決めつけるべきではない。別の関連文書、NROプロファイル、実装調整を指していた可能性がある。古い説明がスライドに残っただけかもしれない。会議録は社内の工程表ではない。

必要なのは責任追及ではなく、公開記録の整合である。「RFC 9877は成立済みで、現在はXを待っている」と一行追記すれば、多くの憶測が消える。標準化待ちという古い説明が、実際の製品判断を覆い隠す恒久的な表現になることを避けられる。

実装の中心はリンク生成ではなく移行である

ARIN Onlineは人が編集する面、Reg-RWSは自動処理の面、RDAPは公開する面である。バルク配布は大量利用者に別の時間軸で届く。同じ機能名でも、四つの面が同時に変わるとは限らない。

たとえばARIN OnlineでURLを保存できても、Reg-RWSが未対応なら自動運用は二重管理になる。RDAP lookupがリンクを返してもhelpがgeofeed1を宣言しなければ、サーバー全体の約束は弱い。バルクスナップショットが一日遅れれば、取引型の応答と集約データで異なる値が見える。

旧コメントの自動変換はもっと危うい。自由文には一つの明瞭なURLだけでなく、複数候補、説明文、失効したURL、似た単語があり得る。正規表現で拾った文字列を型付きポインターへ昇格させると、元の投稿者が与えていない権威をシステムが追加する。

移行はまず棚卸しにすべきだ。明瞭、曖昧、複数、到達不能、対象外に分類し、曖昧なものは資源保有者に確認する。コメントと新フィールドが併存するときの優先順位を定める。変換を戻せるよう原文と判断を残す。より具体的なネットワークオブジェクトが別のfeedを示す場合の選択規則も試験する。

認証された主張も観測事実ではない

RFC 9632はRPSLからgeofeedを発見する方法と、RPKIを使う任意の認証方式を説明する。認証は、対象資源について適切な主体がfeedを提供したかを確かめる助けになる。しかし、記載された都市に機器があることを測定するものではない。

資源保有者がURLを示す。ARINがポインターを公開する。署名が任意で出所を補強する。利用者が位置情報を採用する。四つの行為を一つの「正しい場所」に圧縮してはならない。レジストリは発見と出所の構造を提供できるが、物理世界の真実を保証できない。

機械可読化は大量取得を容易にする。これは利点であると同時に、キャッシュ、削除、より具体的なfeed、プライバシーの影響を拡大する。RFC 9632は通常のRDAPをバルク取得に使うべきではないとしている。ARINが2024年に共通バルク形式へ触れたのは、この分離が必要だからだ。

受け渡し記録の最小構成

まず標準の発火条件を固定する。RFC 9877、適用するerrata、必要なNRO/RIRプロファイルを列挙し、ARINが条件成立と判断した日を記す。残る依存があるなら名称と範囲を明示する。

次に製品別の表を置く。ARIN Online、Reg-RWS、RDAP help、IP network lookup/search、バルク出力ごとに、設計中、試験中、利用可能、既定、廃止予定、完了など定義済みの状態を示す。期待するrdapConformance、リンク関係、媒体型を記し、安全に公開できる正例と負例を用意する。

編集規則も必要だ。誰がURLを追加・変更・削除できるか。HTTPSを必須にするか。到達不能を保存拒否にするか警告にするか。保存前に生成されるRDAP表現を確認できるか。一時的な障害を自動削除の理由にしてはならない。

移行欄では候補コメントの件数と分類を集計し、個別URLは出さない。保有者確認が必要な範囲、型付きリンクとコメントの優先順位、元へ戻す条件を示す。

時間は一つにまとめない。変更受付、ARIN Onlineでの再読込、Reg-RWSでの再読込、RDAP公開、バルク収録を別々に記録する。最終的一貫性には時間窓が必要で、同時刻という演出は不要だ。

試験は有効リンク、リンクなし、不正URL、より具体的なオブジェクト、複数言語、返却制限、削除を含める。展開日とロールバック日を記録し、ARIN 57の表現を補正する。ARIN自身が定めた完了条件に達したら、ACSP 2024.10の状態を根拠文書へ結び付けて更新する。

公開記録は推測の上限を決める

geofeed1がないことから開発停止を推測するのも、内部でコードが動くことから全製品完了を推測するのも、同じ種類の誤りである。どちらも一つの状態を別の状態の証拠に使う。

受け渡し記録があれば、ARINは「この日、この応答クラスで、この規則により対応した」という狭く強い主張を持てる。利用者も同じ境界を検査できる。Openラベル、一つのネットワーク応答、URL、署名の意味を過大評価しなくて済む。

標準は構文を完成させた。ARINが次に公開すべきなのは、標準を実務へ移したという物語ではなく、その移動を再現できる証拠である。

情報源