Summary

  • AFRINIC’s signed 7 September delegation snapshot marked AS36887, AS36911, AS36921 and 41.204.224.0/19 as reserved; the signed 8 September file marked all four allocated in Nigeria under one opaque holder identifier.
  • The allocation dates in the new rows remain in 2006. AFRINIC’s format defines those as first-allocation dates, not the date of the latest state change.
  • Current RDAP records all four as active under DIRECT ON PC LTD and shows registration events on 7 September 2026, followed by a shared 14:19 UTC last-change time.
  • None of those public surfaces says whether the transition was a correction, reinstatement, reassignment, review outcome or another authorised act. A privacy-safe resource-state transition receipt would close that narrow gap.

Four rows crossed the boundary together

The 7 September extended statistics file is unambiguous about the starting state. AS36887, AS36911, AS36921 and the 8,192-address block beginning at 41.204.224.0 all appear as reserved. The country field is ZZ; the date and opaque-holder fields are empty.

One signed file later, the 8 September snapshot gives the bundle a different public meaning. The country is Nigeria, the status is allocated, and every row carries F36DCCF2. The three ASN dates are 16 January, 4 August and 7 November 2006. The /19 carries 1 August 2006.

The dates are the trap. A reader scanning only the current file could reasonably see four old allocations. A reader diffing the two files sees a decision surface that changed in 2026. Neither reader is entitled to call it a new September allocation.

The old dates and the new events answer different questions

AFRINIC’s extended-file README defines the date as the date on which an allocation or assignment was made. Its exchange-format specification calls the product a current-state snapshot without transactional or historical detail. That is a coherent design: the file tells an analyst what state AFRINIC publishes today, not every step by which the registry arrived there.

The current RDAP objects supply a second clock. AS36887, AS36911, AS36921 and 41.204.224.0/19 are active under DIRECT ON PC LTD. Their registration events fall at 12:03, 12:06, 12:08 and 12:18 UTC on 7 September. All four show last changed at 14:19 UTC.

Those timestamps make the one-day snapshot change legible. They still do not name its class or authority. “Registration” is an RDAP event label, not an explanation of the underlying decision.

This is not the bundle’s first public reversal

The sampled record reaches further back. The 1 January 2021 file shows all four allocated with the same 2006 dates and holder token. The 2022 snapshot shows them reserved. The 2023 file restores the allocated rows. The 2025 file places them back in reserved, where they remain on 7 September 2026.

This sampling proves repeated changes in published state. It does not locate the exact day of the earlier changes, much less their cause. The opaque ID helps group rows within the series, but AFRINIC explicitly warns that such identifiers are not guaranteed to remain constant between versions.

The strongest defence is the format itself

It would be unfair to fault a snapshot for failing to be a case file. The public files are compact, machine-readable and signed. reserved and allocated have defined meanings. RDAP exposes a current organisation and current events. Preserving the 2006 dates may be exactly right if the registry is maintaining continuity rather than pretending that old resources were born again this week.

Nor should AFRINIC publish private correspondence, personal contacts, account details or protected legal material merely to satisfy curiosity. The evidence request is smaller. When a scarce resource bundle moves between two public states, the public record should say which kind of authorised transition occurred and which clock controls it.

A transition receipt can be small

A resource-state transition receipt could join the two signed snapshot hashes to a privacy-safe bundle reference, the old and new states, the effective time and the publication time. It could disclose a coarse class—data correction, reinstatement, reassignment, review outcome or another authorised category—without disclosing the underlying confidential evidence.

It should also state the authority used, why the 2006 dates remain correct, how the 2026 RDAP events relate to those dates, which public registry surfaces were reconciled, and where a later correction or reversal would appear. That is enough to keep chronology from swallowing accountability.

Sources