Summary

  • AFRINIC’s archived standard files named 10, 11 and 12 September 2026 are byte-identical. Each carries internal serial 20260910 and a period end date of 10 September; the extended files repeat the pattern.
  • Equal content cannot distinguish an intentionally unchanged daily result from reused output or a stalled source. A small, versioned release receipt could disclose that distinction without exposing member records.

The calendar moves; the dataset does not. A downloader requesting AFRINIC’s standard delegation file for 10 September receives exactly the same bytes as one requesting the files named for 11 or 12 September. Each is 491,382 bytes. Each has SHA-256 digest 54b0cfb6c962fe41815728ef9bff5950cece5fcdd7ab17b94cc3875e68378e07. Each begins with an internal serial of 20260910, declares 9,947 records and ends its stated period on 10 September.

This comparison, captured on 14 September in Asia/Shanghai, establishes one public content identity behind three calendar filenames. It does not establish why the content stayed the same. That difference is the news: the publication surface carries several dates but no public release-level explanation connecting them.

The format gives dates different jobs

The RIR Statistics Exchange Format published in AFRINIC’s directory is unusually explicit. Registries are to produce these files daily. The dated suffix is the producing registry’s local date on which the file was produced. The header serial, separately, identifies the file within that registry’s series. The end date describes the period. The latest name must point to the most recent file when updated.

Those are not interchangeable clocks. Nor is the web server’s modification time a substitute for any of them. The frozen 2026 index lists the file named 10 September with a modification time on 11 September, the 11 September name on 12 September, and the 12 September name on 13 September. The HTTP responses supplied correspondingly different modification metadata. That is evidence about the served objects, not an authoritative account of when a generator ran or what source state it checked.

The root directory adds another layer. It names delegated-afrinic-20260913, yet lists a modification time of 10 September. Downloading that object returns the same standard payload. The current latest alias does too. A later name, a later archive modification time and a newer internal version therefore do not travel together in this sample.

The comparison survives the companion files

The repeated content is not limited to one header or one file class. The extended files named 10, 11 and 12 September, plus their current alias, are each 992,722 bytes and share SHA-256 66f1d06b8f272cbb3f2da3260b73a63cb7b1cd132ad770851dc2e2864ac9eb75. They retain serial and end date 20260910 and declare 19,651 records. The extended format adds resource-state and holder information; it does not add a public explanation of this publication episode.

The three dated MD5 companions are also identical. Independent calculation matches the value they publish, 568a689f01216f94af0b174514fd3903. The three detached OpenPGP signature objects are identical as well. No local verification of those signatures is claimed here.

These are useful controls. The matching checksum reduces the question of accidental transport corruption in the captured standard payload. Identical signature objects show that the public companion bytes were reused too. Neither tells a consumer whether a new daily validation occurred. Even a mathematically verified signature would bind content to a key, not explain why that content appeared under a later calendar path.

The 9 September standard file provides a modest control: it has a different digest and a 9 September serial while retaining the same declared record count. Content identity, version identity and count must be compared separately. A stable total does not mean every row stayed stable; identical complete bytes do mean the captured rows stayed identical.

No change is a result. It needs an observation date

A registry may legitimately have nothing new to report on a particular day. It may also deliberately republish a reviewed result. Reusing a payload need not be suspicious or wasteful. But a consumer needs to know whether “unchanged” means the underlying state was checked through a new cutoff, or whether the previous output was served without a new check.

The files alone cannot choose between those possibilities. They do not reveal a generator run, an upstream cutoff, a replay instruction or a correction waiting to be issued. It would be equally unwarranted to call the registry broken and to treat the newer filename as proof that every underlying source was freshly examined.

The practical risk is a false freshness signal. A collector keyed by URL can store three apparent daily observations that are really one dataset. A collector keyed only by serial can collapse them into one observation and lose the fact that later publication paths appeared. The first exaggerates independent daily evidence; the second erases release history. Neither is cured by counting records or checking the checksum again.

Preserve both identities

Consumers can already retain the requested URL, retrieval time, returned metadata, internal serial, period end date and digest. That makes their own observation reproducible. They should label this sample as identical captured content under later names, not “no allocations since 10 September” or “three days of confirmed service failure.”

AFRINIC could supply the other half with a small release receipt: release-event identifier, dated path, internal serial, digest, byte count, publication time, source-state cutoff, validation status and a coarse reason class for unchanged or reissued content. A correction should link to the prior release rather than silently overwrite its history. No private member dossier is needed.

Evidence boundary and sources

This is a frozen public-file comparison, not a report from AFRINIC’s internal systems. It proves equality of the captured standard and extended objects and describes the published naming rules and server metadata. It proves neither missing allocations nor an outage, incorrect registry data, backdating, misconduct or operational harm. A later replacement may change the public result; that is why release history matters.