Summary

  • REx returns a transfer date of 2003-09-10 for three sampled /16 ranges that were already present in APNIC's 1 March 2003 statistics. The current value cannot mean their first appearance in those APNIC files.
  • Between the 9 and 10 September files, their date fields change from 20030214 to three original 1987 dates. Registry, economy, range, size and allocated status remain unchanged in that comparison.
  • REx's published 2023 methodology identifies resources using a start value and delegation date. Revising the second part changes that pair; whether this explains the current backend result remains unproven.
  • ERX documentation concerns a transfer of management responsibility. These examples establish no sale, change of ownership, routing event, outage, harm or misconduct, and are not an estimate of the tool's overall error rate.

The ranges stayed put; the dates moved backwards

Between APNIC's statistics files for 9 and 10 September 2003, three date fields went back to 1987. The address ranges did not change. Neither did the reporting registry, economy code, address count or allocated status. What changed was a small part of the description of the same three /16s. 9 September file, 10 September file.

That edit is interesting because a date can do more than describe a record. It can help a historical system decide which records belong together. A correction that improves the description of one resource can also change the route by which an analyst finds its earlier history.

The three ranges are 129.60.0.0/16, 129.78.0.0/16 and 129.94.0.0/16, each containing 65,536 IPv4 addresses. In REx's APNIC results captured on 3 September 2026, all three have the same transferDate: 2003-09-10. A separate query for the middle range returns that date too. REx APNIC results, individual range query.

An obvious reading would be that September marked their arrival in APNIC's statistics. That reading does not survive the archive. All three complete ranges were already in APNIC's file on 1 March. Their date field then was 20030214, the value still present on 9 September. APNIC's March file.

The result is precise but limited. The displayed September date cannot mean first appearance in the captured APNIC statistics. It does not follow that it is invalid under every possible meaning of transfer, or that the cause of the current value has been found.

Following the field, not guessing the handover

The older dates were not invented for the September files. They are visible beside the same ranges in ARIN's 1 January 2003 archive. The comparison below retains the eight-digit date values used in the records. ARIN January file.

Range ARIN, 1 January 2003 APNIC, 1 March and 9 September APNIC, 10 September
129.60.0.0/16 19870826 20030214 19870826
129.78.0.0/16 19871002 20030214 19871002
129.94.0.0/16 19871022 20030214 19871022

On 1 January, APNIC's file has no row covering any of the three complete /16s; its 1 February file also lacks them. By 1 March they appear in APNIC's file and have no covering row in ARIN's file. These are numeric range-containment checks, not searches for similar strings of digits. APNIC January, APNIC February, ARIN March.

Those snapshots establish several observed states, not a daily account of the handover. In particular, 20030214 should not be promoted into a verified transition day. A date written inside a row is not necessarily the day that row first appeared in a public file. Absence from a named statistics file is not absence from the Internet.

There is separate institutional context. APNIC's ERX transfer list explicitly includes the three ranges in an enumerated 129/8 group marked completed in January 2003. It does not say that the whole of 129/8 moved, and the group label supplies no exact day. ERX moved resource-management responsibility for early registrations to the appropriate regional registry; the list is not a record of sales. The overall project's February 2005 completion is a different measure from a particular group's completion. ERX range list, project explanation.

The project account and the statistics need not describe identical administrative moments. Their usefulness lies in preserving their respective claims, not in choosing whichever date makes the neatest narrative.

A join that depends on the thing being corrected

APNIC's 2023 explanation of REx says it identifies a resource through its starting value and delegation date. It reconstructs transfers from registry observations, handles conflicting appearances and represents an uncertain interval using its latest possible date. More specific transfer-log information can refine the inference. That is a documented design, not a claim to have inspected the current backend. REx methodology.

Under that identity rule, 129.78.0.0 paired with 20030214 is different from 129.78.0.0 paired with 19871002. The September revision makes APNIC's pair agree with the older ARIN pair. This is an observable matching issue, even though the range itself stayed constant between the two September APNIC files.

It supplies a plausible explanation worth testing: a reconstructed history may attach significance to when the original pair becomes recognisable again. It does not prove that this operation caused the current REx date. The backend, complete inputs, conflict resolution and per-row derivation were not inspected. The full September ARIN archive was not obtained. A complete replay across all relevant registries might establish a different sequence or an additional cause.

The distinction is more substantial than merely observing that two dates differ. Here, one of the dates participates in deciding what counts as the same historical resource. When an identity component changes, a comparison can acquire a new meaning without a corresponding new transfer of the address range.

That possibility is not a finding of a new transfer, or proof that none occurred on a particular day. It is a reason to ask how a derived date was assembled before using it as an event record.

Why inference remains worth having

REx makes dispersed historical observations searchable. That is useful work. For periods without complete event records, refusing all inference would leave a poorer account, not a purer one. APNIC also explains its uncertainty: the inspected current public About component continues to describe the use of the latest possible date and refinement by transfer logs. There is no basis here for alleging concealed methodology. REx.

The inspected resource component renders the returned transfer date. The sampled API rows contain that single value without interval bounds or a derivation field. This describes the inspected component and response, not every view the product may provide. It points to a practical distinction between explaining a method generally and exposing the provenance of a particular result.

Current holder labels have a boundary too. They identify what today's query returns, not every intervening holder or legal successor. No routing observations were used in this comparison. It establishes neither operational disruption nor a change in ownership, and it supplies no evidence of harm or misconduct.

Nor are three chosen examples a population study. They came from a page ordered by transfer date, not a random sample or a census. They can disprove a particular interpretation of those rows without supporting an error percentage for REx.

The lesson is to make correction compatible with historical explanation. An old allocation date may deserve restoration; an analyst may still need to know that the restored value entered a later file. Keeping both observations allows the past of the resource to be investigated alongside the past of its description.

Format references

The RIR statistics exchange specification and extended-file notes provide context for reading statistical fields. APNIC’s prop-142 transfer-log documentation is later event-log context, not evidence of a particular 2003 handover or of the current REx computation.