Summary

  • AFRINIC's extended statistics moved from 6,064 to 6,066 IPv4 records between the 8 and 9 September 2026 snapshots.
  • One reserved block covering 2,048 addresses became three rows: 512 assigned addresses, followed by residual reserved blocks of 512 and 1,024 addresses.
  • The arithmetic conserves the whole block, while the representation changes from one row to three. That alone explains the net increase of two records.
  • Record count, address volume and state-transition count are different denominators. A trustworthy daily-delta product must preserve all three.

The easy headline is wrong

A counter moves from 6,064 to 6,066. On a screen devoted to scarce IPv4 space, “two more” almost writes its own headline. Two allocations, perhaps; two new blocks leaving the pool; another tick in the exhaustion story.

That reading does not survive contact with the records beneath the summary.

AFRINIC's extended file dated 8 September contains one row for 196.60.168.0, with a value of 2,048 and the status reserved. In CIDR terms, that is a /21. In the 9 September file the row is gone. Three rows occupy its address span instead. The first starts at 196.60.168.0, covers 512 addresses and is marked assigned. The next starts at 196.60.170.0, covers 512 and remains reserved. The third starts at 196.60.172.0, covers 1,024 and also remains reserved.

The conservation test is elementary and decisive:

Before After Addresses
one reserved /21 one assigned /23 512
one reserved /23 512
one reserved /22 1,024
Total Total 2,048

One line became three. The record counter therefore rose by two, even though the three after-rows describe exactly the same address volume as the single before-row. The summary is correct. The loose interpretation is not.

A count of lines is not a count of events

AFRINIC's own README supplies the critical definition. The header counts records after excluding version, summary and blank lines. Type summaries count record lines. It also warns that a summary count does not equal the total amount of resources. For an IPv4 record, the value field represents the number of host addresses.

This distinction matters because a daily diff can contain several kinds of change at once. In the same transition, 102.201.98.0/24 moves from an available row to an allocated row. That is a state change covering 256 addresses, but it replaces one row with one row, so its contribution to the IPv4 summary delta is zero. ASN 329808 also changes from an available row to an allocated row without changing the number of ASN rows.

The summary delta is therefore not an event ledger. It is the net result of insertions, removals, splits, merges and one-for-one state substitutions in a particular text representation. A parser may reproduce “+2” perfectly and still misdescribe what happened.

Nor does the opaque identifier on the assigned row solve the problem. It can help match records, but the public file does not define it as a transaction, request or approval identifier. The row supplies a registry state and a date. It does not expose payment, evaluation, policy reasoning, deployment or routing.

Reserved is a state, not a history

AFRINIC separately explains that reserved resources can arise from policy, temporary reservation or quarantine, and that those subtypes cannot be distinguished in the extended statistics. The organisation's resource-management page lists 196.60.0.0/16 as a policy-reserved example. That context prevents another careless leap: the daily row says reserved, but the label alone is not a chronology of the decisions behind this particular split.

The evidence can support a narrow statement. Between the two frozen snapshots, the published representation of the address span changed. One portion is shown as assigned and the remainder stays reserved. It cannot tell us from the file alone who requested the change, what approval path applied, whether the addresses were routed, or how the recipient used them.

That is not a weakness to paper over. It is the boundary that makes the evidence usable.

Build the delta table before the story

A serious monitoring system should carry three columns of meaning that a single headline number cannot hold.

First is record structure: which rows appeared, disappeared, split or merged. Second is resource volume: how many addresses each before-and-after set represents, with a conservation check. Third is state transition: available, reserved, allocated or assigned, without inventing a business event that the source does not record.

The unit of analysis should be the affected address span, not an isolated added line. For this case, the monitor would join the three 9 September rows back to the 8 September /21, show that 2,048 equals 512 plus 512 plus 1,024, and label the summary increase as a net row effect. It would list the separate /24 state substitution without pretending that its zero contribution to the counter means nothing happened.

This daily resource-delta table is an editorial proposal from Theo March, not a requirement announced by AFRINIC. Its purpose is modest: preserve the difference between what the registry published and what an analyst infers.

What the sources do and do not establish

The two daily files establish the recorded states, dates, values and change in row structure. The README establishes the meaning of the counters and IPv4 value field. AFRINIC's resource-management page establishes the reserved-state categories and their lack of differentiation in extended statistics. These sources do not establish a request history, approval decision, payment, legal title, routing announcement, deployment or error by AFRINIC. Detached signatures and the public key were preserved; the published MD5 sidecars were verified locally, while PGP verification was not asserted because a local gpg executable was unavailable.

Sources