Summary

  • RFC 9877 defines the geofeed1 RDAP conformance identifier and a rel=geofeed link for IP network objects.
  • A client should use authoritative RDAP bootstrap, follow bounded parent relationships, enforce prefix containment, and avoid treating HTTPS or a link alone as proof of every row.
  • Refresh intervals, optional RPKI signatures and privacy review remain operational controls rather than guarantees of accuracy or legal usability.

RDAP is the accountability layer for discovery. RFC 9224 bootstrap information can direct a client to the service authoritative for a resource registration; RFC 9082 then describes network lookup semantics in which the returned object is normally the most-specific covering network. That distinction matters. The object returned for an address may not carry the relevant geofeed link, while a less-specific parent may. RFC 9877 therefore allows bounded traversal toward a parent, not an unbounded search through a hierarchy.

The link itself has recognizable protocol shape: rel=geofeed, an HTTPS href, and preferably type=application/geofeed+csv. The registered media type helps identify the intended CSV representation. An object may expose zero or more links, typically zero or one; multiple language versions are contemplated and should use hreflang. These signals establish how a client can discover a feed. They do not prove that the publisher's rows are accurate, complete or current.

Scope is the hard boundary. A client using a discovered feed must ignore entries whose address range lies outside the range of the RDAP network object that carried the link. Prefix containment should be checked before a row influences routing policy, service localization, access control or analytics. A feed can be reachable over HTTPS and still contain an erroneous row; HTTPS protects the transport and endpoint connection, but alone does not authenticate authority over every prefix or every assertion in the file. Where available, an RPKI signature can add a useful validation signal, but it does not convert geolocation into ground truth.

RFC 9877 standardizes discovery and linkage. Fetching and using the data itself is outside its scope, so consumers must define their own acceptance, conflict and fallback rules. They should cache deliberately, refresh according to the guidance rather than perform frequent real-time RDAP lookups, and record which object, range, link and retrieval time supported a decision. A stale result is not made current by repeatedly querying the same authority.

Privacy is not an afterthought. IP geofeed data describes network ranges, but publishers must not expose an individual's location, and operators should assess whether granularity or combinations with other data create that risk. None of these RFCs establishes universal deployment, client adoption, legal permission in every jurisdiction, or a guarantee that a particular feed is safe to consume.

Sources