Summary

  • AFRINIC’s official database dump dated 30 August 2026 contains 3,790 RPSL objects with the exact fallback remarks: Geofeed HTTPS-URL; 3,573 of them are the inetnum or inet6num address objects covered by the RFC 9632 discovery model.
  • The fallback is not an error. RFC 9632 explicitly defines it for registries without a dedicated geofeed: field and requires consumers to understand both forms during migration.
  • AFRINIC’s live address-object schemas still list optional remarks: but no geofeed:. The checked public DBWG record contains a work-item and impact-assessment request, repeated follow-ups, and no later public disposition through August 2026.
  • A bounded migration receipt could state the work-item decision, authorized update paths, syntax and conflict rules, treatment of existing records, WHOIS/RDAP projection, privacy and authentication limits, test results and rollback evidence.

There are two true numbers in AFRINIC’s geofeed record, and confusing them explains the problem better than either number alone.

The official database dump last modified on 30 August 2026 contains 3,790 objects with the exact, case-sensitive line form specified by RFC 9632: remarks: Geofeed followed by an HTTPS URL. A line counter will therefore return 3,790. An object-aware parser asks a second question: what kind of object contains the line?

That second count is 3,573. It consists of 3,483 inetnum objects and 90 inet6num objects. Those are the address classes around which the RFC defines geofeed discovery. The other 217 exact strings appear in 168 route objects, 41 route6 objects, five domain objects, two as-set objects and one organisation object.

This is not evidence that 217 networks are broken. It is evidence that generic prose has no type boundary of its own. A remarks field can carry a geofeed pointer, a support instruction, a certificate, an abuse warning or almost any other text. The string acquires operational meaning because producers and consumers agree to recognise it, not because the database schema knows what it is.

That distinction is why the headline uses 3,573 rather than 3,790. The larger number describes exact textual placement across the RPSL database. The smaller number describes the address-object population relevant to the standard’s discovery mechanism. A registry that publishes both numbers should be able to explain why they differ. A researcher who publishes one number should not silently substitute it for the other.

The fallback is doing real work

The strongest defence of AFRINIC’s present design is not institutional convenience. It is interoperability.

RFC 9632 anticipated that not every RIR database would add a dedicated field at the same time. Where geofeed: is absent, the document defines the exact remarks form. Until every producer has declared support for the field and registrants have migrated their objects, consumers looking for geofeed URLs must understand both representations. A collector that rejected AFRINIC’s remarks form simply because another registry has a dedicated attribute would be the non-interoperable party.

The frozen dump shows that the fallback is not ornamental. The 3,573 address objects point to 106 distinct HTTPS URLs. Their status mix is dominated by 3,461 ASSIGNED PA objects, with 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI and 11 SUB-ALLOCATED PA objects. Repeated URLs are normal: one provider can maintain a single feed that covers multiple registered ranges.

Nothing in those counts proves that a location is right, that every URL resolves, or that a consumer uses it. They do prove adoption of a shared publication convention. Replacing that convention carelessly would impose costs on resource holders and collectors for the sake of a cleaner template. A schema migration deserves an impact assessment precisely because the fallback works.

AFRINIC may also have sound reasons for caution. A new field touches update authorization, web forms, e-mail updates, bulk exports, WHOIS clients, RDAP, documentation, validators and support procedures. It may expose old records whose syntax is tolerated by one collector and rejected by another. It can create conflicts when both a remarks pointer and a dedicated field exist. It can turn a superficially small database change into a multi-interface compatibility project.

The case for a dedicated field must therefore be better than “the RFC mentions one.” It must show how the field improves the record without breaking the installed convention.

A field can validate syntax, not truth

RFC 9632 draws a boundary that governance rhetoric often blurs. Ideally, RPSL has a dedicated geofeed: attribute. In its absence, the remarks form is valid. But the RFC also says the remarks form cannot be formally checked by the RIR. The schema sees text; it cannot natively enforce the recommendation that an address object have at most one geofeed reference or prefer the dedicated value when both forms are present.

The dump makes this limitation measurable. There are 3,592 address objects with a case-insensitive geofeed-like remarks line, but 106 such lines depart from the strict form. Some insert a colon after “Geofeed”; some use lowercase; some point to HTTP rather than HTTPS. This does not establish that every variant fails in practice. It shows that a convention stored as prose can drift without a schema-level rejection.

A dedicated attribute could reject malformed syntax, limit multiplicity, make conflicts visible and allow export interfaces to project the pointer as data rather than prose. It could also help support staff distinguish “the URL is syntactically invalid” from “the file contains a disputed location.” Those are useful improvements.

They do not make the registry an oracle of physical truth.

HTTPS authenticates the endpoint serving the file, provides integrity in transit and protects the connection. It does not prove that the party controlling that endpoint is entitled to speak for the IP range. RFC 9632 therefore describes optional RPKI signing for stronger resource authentication. Even an RPKI-signed file proves a relationship between a resource certificate and the signed data; it does not prove that every city, country code or coordinate in the file corresponds to where an address is actually used at every moment.

There are three separate controls:

Control Question answered Question left open
Dedicated database field Is this value a syntactically recognised geofeed pointer for this object? Does the publisher control the address space?
HTTPS Did the client reach the named endpoint with transport protection? Is that endpoint authoritative for the prefix?
Optional RPKI signature Is the signed file tied to a covering resource certificate? Are the location assertions operationally accurate and privacy-safe?

The existing BTW Article about APNIC’s geofeed field concentrates on the last two boundaries: a pointer and even stronger authentication do not make every location true. AFRINIC’s issue is earlier in the chain. Its schema does not yet distinguish the pointer from other remarks at all.

The public work item has no visible closing receipt

The change did not originate in this audit. It entered AFRINIC’s public Database Working Group in October 2025.

On 27 October 2025, a participant proposed that AFRINIC add the dedicated attribute and let resource owners update it. The message said the remarks fallback was the current method and described a specific pain point for PI resources: in the author’s experience, updating the relevant remarks required hostmaster assistance.

The next day, the DBWG co-chair opened a two-week discussion period and asked staff to prepare an impact assessment. On 14 November, after reporting no disagreement, the co-chair asked AFRINIC staff to take the proposal as a work item and advise how it could be implemented, including the assessment.

The public thread then went quiet until the proposer asked for a report on 6 April 2026. On 16 April, the co-chair asked staff to confirm that the request was an active work item and repeated the implementation and impact-assessment request. A participant added support on 17 April.

The checked public archive has message-bearing months in January, February, March, April and August 2026. It has no May, June or July archive, and the August thread index contains no later geofeed subject. The precise finding is narrow: no later response or disposition appears in the public DBWG archive checked through August 2026.

That is not proof that staff ignored the request. It is not proof that no engineer investigated it, no private conversation occurred or no internal ticket exists. A mailing list is a public record, not a window into every internal act. The accountability gap is the absence of a public closing object for a public work-item request.

A disposition can say “accepted,” “deferred,” “rejected,” “superseded” or “awaiting dependency.” Any of those can be defensible. Silence cannot tell an operator which one applies.

The PI observation is bounded but relevant

The original proposal’s PI claim should not be inflated. One participant’s experience cannot establish a universal workflow for every resource holder. The public dump can nevertheless test whether the described control pattern exists in current data.

It does. All 13 strict-form geofeed address objects with ASSIGNED PI status have AFRINIC-HM-MNT in mnt-by. They also show resource-specific maintainers in lower-level fields. That arrangement is consistent with a distinction between who protects the allocation object and who may create or maintain more-specific data. It does not, by itself, reveal every available update channel, every support exception or the exact authorization code behind AFRINIC’s update service.

The right implementation question is therefore not “are PI holders blocked?” It is: for each object status and maintainer pattern, who can add, modify, delete and correct the pointer, through which interface, under which authentication, with what service path when direct authorization is absent?

That table would be more useful than either a blanket promise of self-service or a blanket defence of hostmaster control. It would turn an anecdote into a testable operating rule.

RDAP shows the cost of leaving semantics in prose

The checked live AFRINIC RDAP response for 160.115.0.0 contains a valid-looking geofeed pointer. It appears inside a generic remarks description. The response advertises rdap_level_0, nro_rdap_profile_0 and cidr0. It does not advertise geofeed1 or expose a structured geofeed link.

RFC 9877 defines an RDAP geofeed link relation and the optional geofeed1 extension. A server may include geofeed links. If it advertises geofeed1, it must return the corresponding link when it possesses and can disclose a URL for the network object. AFRINIC’s checked response does not advertise the extension, so the absence of the link is not proof of noncompliance.

It is evidence of an interface choice. A human or a text-aware collector can recognise the URL in remarks. An RDAP client cannot infer from the conformance array that the server offers structured geofeed discovery, and it cannot treat the remarks description as the standard link relation without applying its own text parsing.

This is what schema debt looks like when it crosses protocols. The data are present. Their meaning remains implicit.

Publish the receipt before declaring the destination

The useful demand is not “implement immediately.” It is “make the decision and its consequences inspectable.” A geofeed schema-migration receipt should contain twelve bounded elements:

  1. the work-item identifier, responsible function, admission date, current state and next review date;
  2. the current WHOIS schema version and any target version;
  3. an impact assessment covering update methods, bulk data, WHOIS, RDAP and common collectors;
  4. a write-authority matrix by object class, resource status and maintainer relationship;
  5. the exact accepted HTTPS syntax, cardinality and validation errors;
  6. coexistence and precedence rules when remarks and a dedicated field appear together;
  7. an inventory of strict, variant and cross-class references and their migration treatment;
  8. the decision on RDAP geofeed1 and structured link projection;
  9. plain guidance separating pointer syntax, HTTPS endpoint identity, RPKI resource authority and location accuracy;
  10. privacy guidance for feed granularity and individual exposure;
  11. a test cohort, compatibility results, correction route and rollback trigger;
  12. a deployment or closure receipt with version, date, telemetry and unresolved exceptions.

This receipt does not predetermine implementation. AFRINIC could conclude that the installed fallback and current priorities justify deferral. It could phase the field in without migrating existing remarks. It could validate new strict-form remarks before changing the schema. It could add WHOIS support while postponing RDAP. What matters is that the public work item reaches a state operators can name and verify.

A registry database is at its best when it is a boring bookkeeper. Boring does not mean silent. It means every field has a defined meaning, every change has an accountable path, and the record does not ask prose to carry more institutional weight than prose can bear.