Summary

  • In June 2024, ARIN said that acceptance of a common IETF standard would trigger geofeed support in RDAP, ARIN Online and Reg-RWS, and that the community suggestion would remain open until the functionality was developed and deployed.
  • RFC 9877 became a Standards Track RFC in October 2025. It defines geofeed1, rel=geofeed and application/geofeed+csv, giving a server a precise way to advertise a geofeed capability.
  • ARIN’s current suggestion register still marks the request Open. A live ARIN RDAP help response captured on 12 September 2026 does not list geofeed1; one selected network response still carries a geofeed URL only in a registration comment.
  • Those observations do not prove inactivity or database-wide absence. They show why ARIN should publish a dated deployment receipt covering the trigger, each interface, legacy migration, bulk access, privacy, tests, rollback and final disposition.

The condition has changed; the public handoff has not

Standards dependencies are often honest reasons to wait. They prevent five registries from turning one intended feature into five incompatible dialects. But a dependency is also a clock. Once the named external event occurs, the explanation must change from “what are we waiting for?” to “what are we deploying, where, and how will users know?”

ARIN created exactly that clock in its answer to ACSP Suggestion 2024.10. The suggestion, submitted on 3 June 2024, asked for an optional geofeed field on network objects. At the time, an ARIN resource holder who wanted to advertise a canonical geofeed URL could put a phrase such as Geofeed [URL] into a free-form comment. The proposer contrasted that convention with typed fields elsewhere and argued that consumers should not have to parse prose for a machine-readable pointer.

ARIN’s reply four days later did more than acknowledge the idea. It said the five RIRs were collaborating in the IETF on an RDAP extension. “When the standard is accepted” was the trigger. ARIN would implement the change in RDAP and add the necessary functionality to ARIN Online and Reg-RWS. It also mentioned work on a consistent bulk RDAP download format. The suggestion, ARIN said, would remain open until the new functionality was developed and deployed.

That is a useful public commitment because it names a dependency, three products and a completion condition. It is not a release contract. ARIN did not define whether “accepted” meant working-group consensus, IESG approval, RFC publication, an inter-RIR profile or some later operational milestone. Nor did it publish a schedule. Still, once a Standards Track RFC exists, the ambiguity is no longer harmless bookkeeping. Users need to know whether the trigger fired and what follows from it.

RFC 9877 supplies more than a field name

RFC 9877 was published in October 2025. Its importance is not that it makes every server implement geofeeds. It does not. Its importance is that it gives an implementing server a registered vocabulary and a client-visible promise.

The RFC defines three related pieces. The link relation geofeed identifies the purpose of an RDAP link. The media type application/geofeed+csv identifies the target representation. The extension identifier geofeed1 lets a server advertise that it hosts geofeed URLs for IP network objects. IANA’s RDAP Extensions registry now contains that identifier and points to RFC 9877.

The conformance token carries the strongest operational meaning. A server that uses geofeed1 must include it in the rdapConformance array of its help response and of lookup or search responses containing IP network objects. When that server possesses a geofeed URL for a particular object and is able to return it, the response must include the corresponding link. A client that sees the token can therefore interpret an absent link more confidently: the server has declared the extension and would have returned an available URL unless a constraint required omission.

There is an important restraint. RFC 9877 also allows a server to use the registered relation and media type without claiming geofeed1. RDAP already permits registered link relations in ordinary responses. The token adds a server-wide capability signal; it is not the only lawful way for a typed link to appear. This distinction prevents a simple probe from becoming a reckless claim about an entire registry.

Two live responses show a state, not a verdict

On 12 September 2026, ARIN’s live RDAP help response advertised a substantial set of capabilities: the base RDAP level, the NRO profile, CIDR support, ARIN origin-AS data, RIR search and search-result extensions. It did not advertise geofeed1.

That is a clean observation. It means the captured help response did not claim the RFC 9877 extension at that moment. It does not show whether code exists in a branch, whether ARIN Online contains a private pilot, whether an inter-RIR dependency remains, or whether ARIN deliberately plans to use a registered link without the extension token. A help response is public protocol state, not a window into a backlog.

A second response makes the transition problem tangible. The selected network object for 154.54.100.0/22 contains a Registration Comments remark with Geofeed ai.net/geofeed.csv. Its rdapConformance array has no geofeed1. Its link objects are self, alternate and up; none has rel=geofeed.

This example was chosen because it exhibits the comment convention described by the community suggestion. It is not a random sample. One object cannot tell us how many ARIN records contain such comments, how many typed links may exist elsewhere, or whether holders still maintain the referenced files. It certainly cannot tell us whether the locations asserted in that file are correct. The narrow fact is enough: the old publication path is present in at least one live response after the RFC exists.

The value of that observation is architectural, not accusatory. Any deployment of a typed field must decide what happens to the prose that came before it.

A conference sentence opens a reconciliation question

The chronology has another loose end. During ARIN 57 in April 2026, ARIN’s engineering update described work on geofeed and RPKI directory-service enhancements and said it was “going through the IETF right now.” By then RFC 9877 had been published for roughly six months.

Several explanations could fit. The speaker may have meant another related specification, an NRO profile, continuing implementation coordination, or simply a slide whose standards language was stale. The public transcript cannot choose among them. It also cannot prove that engineering had stopped. What it can do is show that the public explanation had not been reconciled with the published RFC.

That distinction matters in institutional systems. An obsolete dependency can remain in a roadmap after it ceases to be the real constraint. If so, operators cannot tell whether the current gating item is product design, security review, legacy-data cleanup, inter-RIR agreement, capacity or priority. A correction need not be embarrassing. A one-line note identifying the actual dependency would be more informative than leaving an old standards clock running.

The hard part begins after the JSON key is known

It would be easy to reduce implementation to emitting a link. That would miss the largest operational decision: who is allowed to create the pointer, how is it validated, and what happens to legacy comments?

ARIN controls at least five surfaces in this chain. ARIN Online provides the human editing path. Reg-RWS provides the machine editing path. RDAP publishes the result to consumers. A migration process decides whether existing comment-form references remain prose or become typed data. A bulk service decides how high-volume users collect the resulting pointers without turning individual RDAP queries into a scraping system.

Each surface can reach a different state. A field might be editable in ARIN Online before Reg-RWS exposes it. RDAP could publish a registered link before the help response claims the extension. A bulk snapshot could lag ordinary lookups. Legacy comments might coexist with typed links. Calling the feature “deployed” without an interface matrix would collapse these differences.

Migration is especially resistant to automation. A comment can contain one clean URL, several candidate URLs, instructions around a URL, an obsolete reference or a string that merely resembles the convention. Silently extracting all of them would grant structured authority to text never reviewed as a field. Ignoring every comment would preserve two discovery systems indefinitely and leave clients guessing which one wins.

A safer migration begins with an inventory, not a rewrite. Count candidate comments. Classify them as clean, ambiguous, multiple, unreachable or out of scope. Ask the resource holder to confirm where authority is uncertain. Define precedence when both a typed link and a comment exist. Preserve a rollback path. Record how more-specific network objects affect selection, because applying a broad feed over a more-specific pointer can change the location decision for addresses below it.

Authentication does not convert a location claim into a measurement

RFC 9632, published before RFC 9877, describes how geofeed data can be found through RPSL and how a file may be authenticated with RPKI. It deliberately calls authentication optional. It also notes privacy considerations and warns that ordinary RDAP should not become the bulk-retrieval mechanism.

These cautions define the limits of the new interface. A resource holder supplies a geofeed URL. ARIN may publish the pointer in a typed link. An optional signature can help a consumer establish that the feed is authorized for the covered resources. None of those acts measures where a server, user or packet actually is. The file remains a publisher’s location assertion, interpreted by downstream systems according to their own policies.

Machine-readable discovery does increase reach. A consumer no longer needs a fragile parser for comments, and bulk collection can become more complete. That benefit also makes withdrawal, caching, update latency and privacy easier to get wrong at scale. If an old feed remains in a snapshot after a holder removes it, consumers need to know whether they have stale data or a still-authoritative record. If a more-specific feed appears, they need deterministic precedence. If a URL is withheld for regulatory or privacy reasons, an absent link needs a bounded interpretation.

This is why ARIN’s 2024 reference to a common bulk format deserves to reappear in the deployment record. It was not a peripheral promise. It separated a transactional protocol from a distribution product.

What a deployment receipt should contain

The missing artifact is small in concept: a dated document that binds the public commitment to observable product state. It need not disclose internal tickets or promise a flawless rollout. It should let a resource holder and an RDAP client answer the same set of questions.

Begin with the trigger. Name RFC 9877, any relevant errata and any inter-RIR profile ARIN treats as controlling. State the date on which ARIN judged the 2024 condition satisfied. If another specification remains a dependency, name it rather than continuing to use “the IETF” as a general holding area.

Then publish an interface matrix. For ARIN Online, Reg-RWS, RDAP help, RDAP network lookup and any bulk output, report whether the feature is in design, testing, available, default, deprecated or complete, with terms defined once. Record the exact rdapConformance token, relation and media type that clients should expect. Provide one positive test object and one negative case whose use will not expose a member’s private operating choices.

Document authoring rules. Who can add or remove a URL? Must it use HTTPS? What normalization occurs? Can a holder preview the RDAP representation? What happens when the URL is unreachable? Does reachability block publication, create a warning or remain entirely the holder’s responsibility? A validator should not quietly turn temporary network failure into removal of a registry pointer.

Add the migration ledger. Publish counts of candidate comments and disposition classes without exposing the URLs themselves. Explain which cases require holder confirmation, which remain untouched and when typed data takes precedence. Include a rollback condition so a migration fault can be corrected without erasing the original evidence.

Give every clock its own field: accepted edit, ARIN Online readback, Reg-RWS readback, RDAP visibility and bulk-snapshot inclusion. A service can be eventually consistent without being inscrutable. Consumers need a stated window and a snapshot time, not an impossible promise that all interfaces change at one instant.

Finally, join testing to governance. List fixtures for a valid link, no link, malformed URL, more-specific override, multiple-language links, a withheld response and a removed pointer. Record the deployment and rollback dates. Reconcile the ARIN 57 wording. When the evidence meets ARIN’s own completion definition, change ACSP 2024.10 from Open and link its final disposition to the receipt.

The receipt protects both sides of the interface

Without such an artifact, critics can overread a missing token as proof that nothing happened, while ARIN can overread private progress as sufficient evidence of completion. Both errors arise because code state, product state and public state are left to stand in for one another.

A receipt gives ARIN a bounded claim: this interface supports this standard in these response classes, under these migration and latency rules, as of this date. It gives users a bounded test. It also preserves uncertainty. A pointer is not a location measurement; a signature is not geographic truth; one live object is not a census; an Open suggestion is not a verdict on staff work.

The most credible ending may be mundane. ARIN could explain that the RFC was only one prerequisite, that another profile remains unfinished and that the help token will arrive later. Or it could show that some surfaces are already live and the public register simply lags. Either answer would improve the record because it would replace inference with an accountable boundary.

The standard solved a syntax problem. The remaining work is institutional: show when the dependency changed, who controls each interface, how old data crosses the boundary, and what a client may infer from the result.

Sources