要点

  • ARINの現行 entity/GOGL レスポンスは、Registration Commentsを返却対象のentity内に置き、サービス全体に関するnoticesを最上位に分けている。
  • RFC 9083はこの配置を意味の違いとして定義する。remarksはそれを含むオブジェクトクラスを、noticesはRDAPサービスまたはレスポンス全体を説明する。

配置も証拠の一部である

ARINの entity/GOGL エンドポイントが返す最上位オブジェクトは、objectClassName が entity、handleが GOGL である。その内部の remarks 配列にはRegistration Commentsがあり、abuseの申告や法的要請をどこへ送るかという連絡案内が記されている。一方、レスポンス最上位の notices にはTerms of Service、Whois Inaccuracy Reporting、Copyright Noticeが別々に収められている。

この違いは単なるJSONの見た目ではない。RFC 9083第4.3節では、noticeはRDAPサービスまたはレスポンス全体に関する情報、remarkはそれを含むオブジェクトクラスに関する情報とされる。両者はtitle、description、linksなど似た構造を使えるが、適用範囲は配置によって異なる。分析時には文章だけでなく、その文章までの完全なオブジェクトパスを保持する必要がある。

同じARINレスポンスの入れ子になったentityにも、それぞれ固有のhandleとroleがある。abuse roleを持つentityにもRegistration Commentsが存在するが、同じ見出しが複数回現れることは、内容がレジストリ全体の一つの規則になったことを意味しない。それぞれのremarkは、それぞれを格納するオブジェクトに属する。

オブジェクトの注記を全体方針へ拡張しない

Registration Commentsは実務上重要な手掛かりになり得る。ただし、ここから分かるのは当該オブジェクトが特定の連絡をどう案内しているかまでである。同じ案内がすべてのARIN entity、networkオブジェクト、資源レコードに適用されるとは証明できず、ARINの方針や法的手続の全体像を単独で示すものでもない。

さらに、連絡先の説明はネットワーク運用の証拠ではない。BGPトランジット、インフラの支配、サービスの稼働状況、実際の応答能力は別の問いであり、それぞれに対応する経路、運用、方針上の証拠が必要になる。object-scoped remarkの意味を広げて代用してはならない。

情報源