Summary

  • An APNIC 62 slide reports that APNIC supplied 3.0% of the “successful geofeed publishers” in a randomized set of 200,000 Whois-discoverable geolocation rows; ARIN supplied 21.6% and RIPE NCC 75.5%.
  • The slide groups by distinct netnames and excludes AFRINIC and LACNIC for technical reasons. It does not publish the eligible population, snapshot date, number of netnames, success rule or path from raw rows to the three bars.
  • The figures support a bounded observation about the composition of one included success set. They do not establish that only 3.0% of APNIC Members, resource holders, prefixes or networks have adopted geofeeds.
  • One-click publication may reduce interface friction, but its effect needs a versioned adoption receipt linking eligibility, discovery, validation, maintenance and downstream use.

The footnote changes the unit

APNIC appears as a thin green bar marked 3.0%. ARIN reaches 21.6%. RIPE NCC occupies 75.5%. The heading asks which RIR successful geofeed publishers come from, inviting the reader to see a regional adoption contest.

Then the footnote changes the object being counted. The dataset is a randomized set of 200,000 geolocation rows from geolocatemuch.com that were discoverable through Whois. The chart says it works “By Network IDs (distinct netnames).” AFRINIC and LACNIC are intentionally omitted for technical reasons.

Those details do not invalidate the chart. They define it. A geolocation row is not a publisher. A prefix can generate several rows, a feed can carry many prefixes, and several registry objects can point to one file. A netname is a label in registration data, not necessarily a stable organization identity across five registry systems. Deduplication is necessary, but the chosen key determines which apparent publishers merge and which remain separate.

The three displayed shares add to 100.1%. That is consistent with ordinary rounding to one decimal place and supplies no evidence of anything more. The consequential gap is elsewhere: the deck does not show how many distinct netnames sit behind each bar or how many eligible netnames, holders, prefixes or routed networks existed in each included RIR.

Composition is not prevalence

Suppose a sample contains 1,000 successful observations, of which 30 map to APNIC. APNIC’s share of that success set is 3.0%. If the eligible APNIC population were 60, the implied prevalence would be very different from a case in which it were 60,000. The numerator cannot answer both questions.

That is the distinction between composition and adoption. Composition asks: among the successes that survived this sampling and classification path, where were they registered? Adoption asks: among the eligible population in each region, how many publish a current, reachable, scoped and usable feed?

The APNIC Blog report calls the source a sample and says the data highlighted regional differences in geofeed adoption. The directional concern may be real. The chart does show that APNIC-labelled successes are scarce inside the included set. But it cannot, on the published information, measure the probability that an APNIC operator adopts compared with a RIPE NCC operator.

Two excluded RIRs make the boundary even clearer. Their absence was disclosed, which is good practice. It means the bars describe three included regions, not the RIR system. No conclusion about AFRINIC or LACNIC follows, and the missing technical paths may also reveal something about comparability of the underlying registration data.

“Successful” needs a state machine

The public geolocatemuch.com page describes discovery through Whois and offers a merged validated feed. It also explains why the join is not trivial: one file can contain multiple prefixes, multiple resource objects can point to the same file, and rows outside the encompassing registration object must be ignored.

The APNIC 62 deck does not define “successful publisher” on the chart. It could mean the reference was discovered, the URL was fetched, the CSV parsed, the row was within scope, the publisher’s authority was validated, the locality fields passed checks, or a downstream service used the result. Those are different states.

RFC 8805 defines the feed format and preserves consumer discretion. A consumer may treat the data as a hint, prefer another source and decide how to resolve discrepancies. RFC 9632 standardizes discovery and optional authentication. It can strengthen the statement that a resource holder authorized a feed; it does not turn a row into measured geography.

RFC 9877 carries the link into RDAP through geofeed1, a registered link relation and a media type. Fetching and using the data are expressly out of scope. The RFC does not prescribe a dashboard button, an eligible-population denominator or a downstream adoption metric.

One click can remove one kind of friction

Sid Mathur’s five-slide presentation asks RIRs to make publication of geofeed URLs “one-click” in their dashboards. The case for testing that idea is strong. Registries already authenticate account access and maintain the resource objects from which discovery begins. A guided interface could prevent spelling mistakes, apply scope checks, show privacy warnings and make a currently obscure mechanism visible.

The strongest case should be admitted. Operators should not need to learn an accidental command language merely to publish a standard URL. A well-designed form can reduce support cost and make the correct path the easy path.

But one click does not host or maintain the CSV, decide its intended location semantics, keep it current, prove its accuracy, or compel a commercial database to ingest it. It can complete a registry-side transition while every downstream state remains unknown.

The slide also says an informal APNIC WhatsApp community poll ranked “unsure how registry can help” as the number-two barrier. That is a useful commissioning lead, not a measured regional priority. The deck supplies no denominator, recruitment frame, question wording, response options, date or duplicate rule. It does not show what ranked first, how far apart the choices were, or whether respondents represented non-publishers.

A receipt for an adoption claim

A versioned measurement receipt would begin before the bar chart. It would record the snapshot time, source-file and code versions, 200,000-row sampling rule, raw and unique-prefix counts, Whois/RDAP discovery method, RIR mapping rule and every technical exclusion. It would name the success state and show the flow through discovered, fetched, parsed, in-scope, authority-validated, current and consumed.

For each RIR it would publish both numerator and eligible denominator under a common unit. If distinct netnames remain the unit, the receipt should explain their normalization and known cross-registry limits. If the unit becomes resource holders, files, prefixes or routed origins, the change should be explicit rather than smuggled into a label.

The product side needs its own join: dashboard capability and version, eligible accounts, attempts, successful publications, validation failures, maintenance after 30 or 90 days, and evidence that at least one consumer discovered the resulting link. Privacy-safe aggregates are enough. No member’s exact location or account history needs to become public.

The APNIC 62 report establishes that “The case for RIRs” was a Cooperation SIG presentation. It does not turn the speaker’s proposal into APNIC policy. The Blog likewise says its authors’ views do not necessarily reflect APNIC. That separation protects both experiment and accountability: a promising idea can be tested without first being described as an institutional commitment.

The 3.0% bar should therefore be kept, not discarded. It is a reason to investigate. Its footnote is the instruction not to overclaim. First show what entered the sample, what survived, what was excluded and what population could have participated. Then a later chart can tell whether a simpler registry interface changed adoption rather than merely changing the story told about it.

Sources

  1. APNIC Blog — IP geolocation at APNIC 62
  2. Sid Mathur — Self-published Geofeeds; the role of RIRs
  3. APNIC 62 conference report
  4. Geolocate much?
  5. RFC 8805 — A Format for Self-Published IP Geolocation Feeds
  6. RFC 9632 — Finding and Using Geofeed Data
  7. RFC 9877 — RDAP Extension for Geofeed Data