Summary

  • IANA's IPv4 address space registry records AFRINIC against six /8 blocks in two forms: four ALLOCATED to AFRINIC with recorded dates in 2005, 2008, 2010 and 2011, and two marked "Administered by AFRINIC" with LEGACY status and a recorded date of 1993-05.
  • In the excerpt obtained, each entry is a tuple of block, designated registry, date, whois server and status; no entry names the resolution, agreement or decision by which any designation changed.

Six blocks, two verbs

The African regional registry appears in IANA's IPv4 Address Space Registry under two different designations, and the difference is not cosmetic. The excerpt returned in this review reads, in the registry's own field format:

041/8 AFRINIC 2005-04 whois.afrinic.net ... ALLOCATED 102/8 AFRINIC 2011-02 whois.afrinic.net ... ALLOCATED 105/8 AFRINIC 2010-11 whois.afrinic.net ... ALLOCATED 154/8 Administered by AFRINIC 1993-05 whois.afrinic.net ... LEGACY 196/8 Administered by AFRINIC 1993-05 whois.afrinic.net ... LEGACY 197/8 AFRINIC 2008-10 whois.afrinic.net ... ALLOCATED

That passage is a provider-reported excerpt of the registry page, not a full-page read; it is quoted here because the field format is the finding. Four blocks carry the bare designation AFRINIC with ALLOCATED status. Two carry the fuller phrase "Administered by AFRINIC" with LEGACY status, and both of those carry the same recorded date: 1993-05.

The arithmetic is the part worth pausing on. 1993-05 precedes 2005-04, the earliest ALLOCATED date recorded against AFRINIC, by roughly twelve years. The recorded date on the two LEGACY blocks therefore cannot be a date on which AFRINIC did anything. It is the surviving date of an earlier allocation, now attributed to a registry that did not exist when the date was set. A reader who takes the registry as a chronology of African registration will read those two lines as a fact about AFRINIC. They are a fact about the space, retained while the administrator column changed.

That distinction is what the narrative version of the handover collapses. Delegation of a block to a registry, and administrative designation of a block allocated long before that registry existed, are separate acts recorded in the same table. The registry is designed to answer one question — who does a holder contact — and answers it in both rows identically. The whois server is the same in all six entries. Practically, a legacy holder in 154/8 and a post-2005 holder in 041/8 are told to go to the same place.

A destination is not an authorisation

Here is the limit of the record, and it is a field-level limit rather than a matter of interpretation. In the excerpt obtained, every entry consists of five things: a block, a designated registry, a date, a whois server and a status. Nothing in that structure has a slot for the instrument. No entry cites a resolution, an agreement, a board decision or a policy under which a designation changed, and no entry names a body that authorised the change.

For most operational purposes that is sufficient, and it is worth saying plainly: the registry of record is not defective for omitting what it was never built to carry. A network engineer checking where to send a registration query needs the destination and the status, both of which are present. The deficiency appears only when the same table is read as a legal history, which is how it tends to be read after a dispute, when the question is not who holds the registration now but who had the authority to move it.

On that question the registry is silent in a specific and checkable way. It shows that administrative responsibility for 154/8 and 196/8 sits with AFRINIC. It does not show when that attribution was made, by whose act, or on what terms. The 1993-05 date cannot answer it, because it records the allocation, not the reassignment. A reader who wants the transfer instrument will not find it in this table, and the table's silence is not evidence that no instrument exists — only that this record does not contain it.

Three record sets that would settle it, and are not here

The documents that could answer the authorisation question are identifiable, and none of them was obtained in this review. They are: the predecessor registry's own governance records, at RIPE NCC's Executive Board minutes archive, where a decision to cease registering in the African region, if recorded in that form, would sit; the recognising body's records, at ICANN's Board resolution materials dated 8 April 2005, where recognition of the registry as regional for Africa would sit, separately from any transfer of records; and the registry's own published account, at AFRINIC's history page, which would be the natural place for a chronology of establishment and operational start.

The retrieval boundary, stated with its arithmetic: five retrieval attempts were made in this review, of which two ended as provider capacity failures with outcome unknown and three returned output. Within those attempts, four document classes were pursued. One was read — the IANA registry — and three were not obtained. The three unread classes are the RIPE NCC minutes archive, the ICANN resolution materials and the AFRINIC history page. That is the whole partition: four classes, one read, three not obtained.

No further split of those figures is asserted here, because the attempts overlapped classes and per-class attempt counts would not sum to the attempt total.

The consequence for this article is narrow and should be stated without hedging in either direction. What the recognition instrument of April 2005 says, what RIPE NCC recorded about African registrations, and what AFRINIC publishes about its own operational start are all not established here. The registry excerpt stands on its own as a document-level reading. Everything about the authorising acts stands unread.

Why a member should care which of the two they are looking at

The directory record behind this article is the RIPE NCC to AFRINIC Transition entry. What it names is a handover, and the ordinary reading of a handover is continuity: the same registrations, served by a new administrator, under an arrangement someone made. The registry of record supports the continuity half of that reading — same whois server, same holders, six blocks — and says nothing about the arrangement.

That gap matters most to the holders whose blocks are the oldest ones. A legacy registration is the kind of asset whose status gets questioned in exactly the situations where paperwork is demanded: a transfer request, a corporate succession, a dispute over whether a registry may re-price or revoke. At that point the question is not "who is my registry" — the table answers it — but "what instrument put my registration where it is, and what did that instrument permit". The table cannot answer that, and the three documents that might have are the three that were not obtained here.

This is a governance point rather than a technical one, and it is the reason the record deserves to be read closely instead of cited in passing. A registry's authority over existing holdings is durable in practice because holders keep renewing and keep querying the same whois server. Durable practice is not the same as documented assignment, and the two are routinely conflated in exactly the settings where the distinction is load-bearing. The registry of record shows the practice. It does not show the assignment.