Summary

  • AFRINIC's signed 28 August file showed ASN 329802 and a 4,096-address range beginning at 102.201.96.0 as available. The signed 29 August file instead shows the ASN as allocated and 102.201.111.0/24 as assigned.
  • Both new rows carry date 20260828, country code NA and opaque ID F36CF852. AFRINIC defines that ID as a holder identifier, so the same-file holder link is real.
  • Four remaining available ranges total 3,840 addresses. Adding the assigned 256 restores the previous 4,096 exactly, but arithmetic reconstructs an inventory change, not a cross-resource approval.
  • A privacy-safe issuance receipt could say whether the ASN and /24 were co-issued, merely became effective on the same date or were unrelated, without naming the holder or exposing an application file.

Two resources arrive on one line of sight

The 28 August extended statistics contain two uncomplicated availability records. ASN 329802 appears as one available autonomous system number. A separate IPv4 row starts at 102.201.96.0, counts 4,096 addresses and also says available. Neither row carries a date or a holder identifier, as one would expect for unissued inventory.

The next dated file changes both views. ASN 329802 is now allocated. The country code is NA, the date is 28 August 2026 and the opaque ID is F36CF852. A new IPv4 record assigns 256 addresses beginning at 102.201.111.0 with exactly the same country code, date and opaque ID.

The visual invitation is obvious: one organisation received an ASN and an IPv4 /24 together. The first half of that sentence is supported. AFRINIC's README says every record in a file with the same opaque ID is registered to the same resource holder. The second half—“together”—has more than one possible meaning. It could mean one application, one approval episode, two coordinated requests, two independent requests completed on the same date, or simply two state changes collected in the same daily projection.

The file does not choose among those meanings. Its restraint should become the reader's restraint.

The subtraction is exact

The IPv4 movement is unusually easy to audit from the public rows. A count of 4,096 addresses beginning at 102.201.96.0 is the range 102.201.96.0/20. The new assigned row contains 256 addresses, so it is 102.201.111.0/24, the last /24 inside that /20.

The 29 August file does not leave a vague smaller pool. It publishes four available remainders:

  • 2,048 addresses beginning at 102.201.96.0, equivalent to a /21;
  • 1,024 beginning at 102.201.104.0, equivalent to a /22;
  • 512 beginning at 102.201.108.0, equivalent to a /23;
  • 256 beginning at 102.201.110.0, equivalent to a /24.

Those four rows total 3,840. Add the new 256-address assignment and the result is 4,096, exactly the previous available count. There is no unexplained address gap in this transition.

The header supplies a second reconciliation. The total record count rises from 19,621 to 19,625. The IPv4 summary rises from 6,051 record lines to 6,055, because one available row is replaced by one assigned row and four remainder rows: a net gain of four. The ASN summary remains 4,350, because one available ASN row is replaced by one allocated ASN row.

This is evidence in AFRINIC's favour. The state projection is internally coherent at the exact boundary inspected. It does not show duplicate stock, a missing /24 or a count that can only be repaired by assumption. The accounting works.

It also demonstrates the limit of arithmetic. Numbers can prove that an IPv4 pool was partitioned cleanly. They cannot prove who requested the ASN, whether the ASN was needed for the same network, which approval came first or whether the two resource types shared an institutional decision.

A holder identifier answers one question

AFRINIC's format documentation is specific about the opaque ID. It is an in-series identifier that uniquely identifies one organisation or Internet number-resource holder. All records in the file with the same opaque ID are registered to that same holder. On the 29 August snapshot, the holder join between ASN 329802 and the /24 is therefore not speculation.

The identifier is deliberately not a public name. That design protects privacy while allowing related rows to be grouped. It is a useful compromise: researchers can see that two resources sit under one registry holder without learning an organisation name from the statistics file alone.

But AFRINIC warns that the identifier is not guaranteed to remain constant between versions of the file. It is not an immutable corporate identity, a legal ownership certificate or a universal account number. It describes the registry's current pseudonymous grouping in this reporting series.

Most importantly, the next rule does not say that every row sharing an opaque ID and date forms one event. It says that records may be held to be a single assignment or allocation when they are collated by type, opaque ID and date. Type is part of the key. An ASN record and an IPv4 record are different types.

That wording is sensible. A holder may receive several contiguous IPv4 ranges through one allocation, and same-type collation helps reconstruct the unit. It does not follow that every resource product visible under the holder on the same day came through a single request. The public format neither confirms nor denies the cross-type join.

Calling F36CF852 a transaction ID would therefore change the meaning of the field. It would turn a holder grouping into an event grouping. That can create two opposite errors: merge distinct cases because the holder is the same, or assume one approval's evidence applies to another resource type.

Date is not workflow time

Both new rows carry 20260828, although the changed projection is the file dated 29 August. That supports a registry date of 28 August for the allocation and assignment. It does not disclose the time of day or show when a request arrived, when evidence was complete, when a reviewer decided, when a fee cleared, when a database changed or when the public file was generated.

A daily report compresses those stages by design. A record can truthfully state the effective date without being a public case diary. The one-day comparison is sufficient to locate the transition between two snapshots; it is not sufficient to reconstruct its internal order.

The country code also has a bounded meaning. NA is Namibia, but the README says this field identifies the country where the resource holder is legally based and cannot reliably be used to map where the IP addresses operate. It supplies no evidence about routing origin, customers, equipment, traffic or the physical location of a network.

Nor does assigned prove use. The file shows a registry disposition. It does not show a BGP announcement, a Route Origin Authorisation, a WHOIS or RDAP activation time, reverse DNS, service traffic or a customer outcome. ASN 329802 is labelled allocated, not assigned; the IPv4 row is labelled assigned, not allocated. Preserving those verbs keeps the registry statement from becoming an operational story it cannot support.

The compact format has a strong defence

The strongest benign reading begins with the product AFRINIC actually publishes. The extended files are part of a joint RIR effort to provide consistent daily resource statistics. They are compact state summaries, not case-management exports. A small common format is easier to produce, compare and reuse across regions than a public replica of every registry's internal workflow.

Privacy is not a side issue. Publishing a stable request number next to every ASN and prefix could let observers reconstruct an organisation's application cadence, product launches or network plans. Revealing internal tickets, staff identities, need evidence or invoices would be disproportionate. The opaque holder ID already offers a controlled amount of linkage without naming the holder.

Nothing in the two files indicates misconduct. A member may quite ordinarily need an ASN and a /24. The same-day records may indeed result from one well-run request or two coordinated requests. The exact residual ranges suggest disciplined address accounting. The signed files and matching checksums make the evidence unusually strong for what they claim.

The problem is not that the public record looks suspicious. It is that its schema cannot settle a question readers will naturally ask. A good record should prevent both insinuation and overstatement. AFRINIC should be able to say “these were one issuance episode,” “these were separate decisions,” or “the public view intentionally does not link them” without forcing the holder ID to perform a job it was not designed to do.

The missing object is a cross-resource receipt

A proportionate receipt would begin with an opaque issuance-episode identifier distinct from the opaque holder identifier. It would list each resource type, start, size, previous state and resulting state. For the IPv4 component it would bind the source range and the exact residual ranges, preserving the clean subtraction already visible in the daily file.

The receipt should state the relationship between rows. Co-issued in one decision, separate decisions with a common effective date, and unrelated state changes are more useful than allowing a same-holder inference to float. A request class and policy basis can be published at a high level. Decision date, effective date and public-projection date should remain separate fields rather than being collapsed into one day.

Corrections need lineage. If a resource, date or relation changes, the public object should preserve what it superseded, who is accountable for the correction at an institutional level and when the replacement became effective. The holder's name, narrative application, invoice, staff identity and internal case notes can remain protected.

If a durable public episode ID creates too much correlation risk, there is a narrower alternative. AFRINIC could publish a signed co-issued relation between the two public rows, or a one-way cryptographic commitment that proves the rows share an episode without making the episode searchable across unrelated files. The technical design can be thin. The semantic distinction cannot.

What the two files can support

The evidence supports a modest, useful finding. Between the signed 28 and 29 August projections, ASN 329802 moved from available to allocated, and the final /24 of an available IPv4 /20 moved to assigned. The remaining IPv4 inventory reconciles exactly. In the later file, the ASN and /24 have the same date, country code and opaque holder identifier.

The evidence cannot show whether one application, approval or transaction joined the two resource types. It cannot show where the network operates, whether either resource is routed, or whether anyone suffered a delay or harm. It cannot turn ordinary issuance into a controversy.

This is why the distinction between holder and event matters. Accurate records do not need to expose private files or give a registry broader authority. They need to describe the state they publish and preserve the narrow joins required to reproduce a change. AFRINIC has published the holder join and the arithmetic. One small receipt would disclose whether it also has an issuance join.

Sources