要約

  • RFC 9877 は、IPネットワークオブジェクトに geofeed1 と rel=geofeed リンクを定義する。
  • クライアントは権威ある RDAP bootstrap、最具体オブジェクト、限定的な親オブジェクト探索を使うべきである。
  • プレフィックス包含、HTTPS、任意の RPKI 署名、更新間隔、プライバシーは、いずれも正確性そのものではない。

RDAP の役割は、まず発見先と登録責任を示すことだ。RFC 9224 の bootstrap は、資源登録に権威を持つサービスへクライアントを導く。RFC 9082 の検索では、通常、対象アドレスを最も具体的に包含するネットワークオブジェクトが返る。しかし geofeed リンクは、より広い親オブジェクトに付くことがある。そこで RFC 9877 は親への限定された探索を認めるが、階層を無制限にたどることは認めていない。

リンクは rel=geofeed、HTTPS の href、そして可能なら type=application/geofeed+csv を使う。登録されたメディアタイプは想定される CSV 表現を識別する。一つのオブジェクトには通常ゼロまたは一つのリンクがあり、複数の言語版には hreflang を使うことが想定される。これらは発見方法を定める信号であって、ファイルの行が正確、完全、最新、またはあらゆる法域で利用可能だと証明するものではない。

境界を決めるのはプレフィックス包含である。発見した feed を使う場合、リンクを持っていた RDAP オブジェクトの範囲から外れるアドレス範囲の行は無視しなければならない。サービスの地域選択、アクセス制御、経路ポリシーや分析に使う前にこの検査を行う。HTTPS は接続経路を保護するが、それだけで全プレフィックスへの権限や全行の真正性を証明しない。RPKI 署名があれば追加の検証材料になり得るが、位置の主張を確定した事実にはしない。

RFC 9877 の対象は発見とリンクであり、データの取得・利用そのものではない。利用者は受入れ、競合、フォールバックの規則を定める必要がある。頻繁なリアルタイム RDAP 問い合わせを避け、キャッシュと更新の規律を守るべきだ。オブジェクト、範囲、リンク、取得時刻を記録すれば、判断の根拠を追跡できる。繰り返し取得しても古いデータが新しくなるわけではない。

プライバシーも必須の検討事項である。ネットワーク範囲を示すデータであっても、公開者は個人の所在地を露出させてはならない。粒度や他データとの組み合わせを審査する必要がある。これらの RFC は、世界的な導入、クライアントの普及、正確性、完全性、または全法域での適法性を保証していない。

出典