Summary

  • AFRINIC’s revision history says Version 3 of AFPUB-2019-V4-003-DRAFT03 changed only sections 5.7.3.2 and 5.7.4.3. The archive’s Details field gives 22 September 2020 as the submission date, while the revision history dates Version 3 to 21 September; the available record does not resolve that one-day difference.
  • The first change replaced Draft 2’s immediate source eligibility for further AFRINIC IPv4 allocations or assignments with twelve months of ineligibility after an approved transfer. The second reversed Draft 2’s loss-of-legacy-status rule, so transferred legacy resources would remain legacy.
  • Draft 3 retained the deeper compatibility problem. Its source rule still referred to compliance with the receiving RIR’s policies, and its procedure still directed the transferring party to the receiving RIR. Those provisions crossed institutional relationships: a registry was being asked to assess a foreign source it did not serve, while that source was being sent to a registry with which it might have no agreement.
  • AFRINIC’s staff assessment of 13 October 2020 recorded material incompatibility responses from all four counterpart registries discussed: ARIN, APNIC, LACNIC and RIPE NCC. Staff explained the ordinary division of work more simply—each RIR deals with the party in its own region, and the registries communicate with one another.
  • The most defensible reciprocal design is therefore narrow. The source registry verifies the source and the resource; the receiving registry verifies the recipient; the registries exchange authenticated confirmations, select one effective time and update their service records consistently. That protects uniqueness and continuity without inventing foreign-registry jurisdiction.
  • The two Draft 3 changes had plausible purposes. A waiting period could discourage immediate recycling of freely allocated space, and legacy preservation could avoid an automatic status penalty. But neither purpose proves that the reciprocal procedure worked, and the available record establishes no adoption, implementation, completed transaction, price effect or realised membership change.

A small redline with a large institutional test

Version numbers can create a misleading sense of forward motion. A new draft appears after a public meeting; clauses have moved; objections have been heard; a revision history records change. It is tempting to read the sequence as a problem gradually being solved. AFPUB-2019-V4-003-DRAFT03 does not support that easy story. Its significance lies precisely in the gap between what changed and what remained.

The proposal was an attempt to amend section 5.7 of the AFRINIC Consolidated Policy Manual, or CPM, with a reciprocal inter-RIR IPv4 transfer route. AFRINIC’s archive identifies the authors as Anthony Ikechukwu Ubah and Taiwo Oyewande. Draft 1 had been submitted on 30 October 2019. Draft 2 followed on 13 August 2020. AFRINIC-32 considered Draft 2 on 16 and 17 September, and its minutes preserve a dense cluster of questions about reciprocity, source eligibility, recipient need, legacy resources, disputed space and the proposed contact procedure.

That meeting record must be handled with care. It is evidence of the debate around Draft 2, not a debate on Draft 3. It records the authors’ explanation that reciprocity was required and records objections to asking a source to follow the receiving RIR’s rules, to initiating directly with the receiving RIR and to relying on a supposed standard template. It also notes discrepancies between some oral or slide descriptions and the posted text. The timing is close: Version 3 appeared within days.

But chronology cannot establish that a named intervention caused a particular edit, and the available materials do not explain why the authors chose exactly the two changes they made.

Even the date of Version 3 requires precision. The archive’s Details field says it was submitted on 22 September 2020. The revision history dates Version 3 to 21 September. There is no basis for silently choosing one and discarding the other. The responsible conclusion is that the official page preserves a one-day discrepancy, not that one date is certainly correct.

The revision history is much clearer on substance. It says Draft 3 updated only sections 5.7.3.2 and 5.7.4.3. That word “only” carries the analytical burden of the whole episode. Source compliance in section 5.7.3.1 and incoming-recipient need in section 5.7.4.1 had been changed in Draft 2. They remained part of the Version 3 text, but they were not Version 3 edits. Any account that describes those clauses as Draft 3 innovations would turn retained architecture into a new response and obscure why the compatibility defect survived.

The first change: a twelve-month pause for the source

Draft 2’s proposed section 5.7.3.2 allowed a source to remain eligible for further AFRINIC IPv4 allocations or assignments so long as it complied with current policy. Draft 3 replaced that position with a twelve-month period of ineligibility after an approved transfer. In practical terms, an organisation transferring resources away could not immediately return to AFRINIC’s allocation service for more IPv4 space.

There is a coherent benign rationale for such a rule. If an organisation recently obtained space from a free pool and quickly transferred it, then returned for another allocation, the allocation system could become a low-cost feeder for a transfer market. A waiting period can be understood as an anti-cycling condition attached prospectively to continued use of a private allocation service. It creates a cooling-off interval and may discourage strategic churn.

Yet the record sets strict limits on what can be claimed about that rationale. It contains no measurement of cycling, no estimate of how many organisations might be deterred, no quantity of address space preserved and no observed behavioural effect. The twelve-month term is therefore a rule with a plausible mechanism, not a demonstrated outcome. Nor does it decide ownership of the transferred resource. It concerns later eligibility for an AFRINIC allocation or assignment, not whether a private transaction itself is legally valid.

The distinction matters because anti-cycling measures can easily be described in language broader than their proper function. A private registry may define reasonable prospective terms for a service it provides. It does not thereby acquire a power to punish a former holder, confiscate an asset or regulate the wider market. The narrow question is whether temporarily delaying re-entry to the allocation service is proportionate to a documented scarcity problem, applied predictably and accompanied by clear reasons. Draft 3 supplies the term; it does not supply the empirical answer.

Nor should the twelve-month restriction be confused with reciprocal compatibility. It changes the source’s relationship with AFRINIC after a transfer. It does not tell AFRINIC and another RIR how to authenticate the same transaction, divide verification tasks or synchronise their records. A cooling-off period can be perfectly clear while the cross-registry bridge remains unusable.

The second change: legacy status survives transfer

Draft 2’s proposed section 5.7.4.3 said that transferred IPv4 legacy resources would cease to be legacy. Draft 3 reversed that consequence: transferred legacy resources would remain legacy. This was a direct and intelligible status change. Instead of making transfer the event that automatically extinguished a historical classification, the new text preserved that classification across the transaction.

That move answers a real concern. Legacy status may carry distinct service, contractual or historical implications, and an automatic loss of status can operate as a penalty on portability. Preserving the status removes one immediate deterrent embedded in Draft 2. It also avoids pretending that a record update can erase the historical origin of a resource merely because recognised control changes.

But here again, precision prevents overclaiming. Preserving legacy status in the AFRINIC proposal does not prove what another RIR would have done with a completed transfer. It does not resolve the receiving registry’s service terms, the recipient’s obligations or the treatment of the resource in every external system. Most importantly, it does not repair the sequence by which the two registries would verify and record the transfer. Historical-status continuity and procedural interoperability are different design problems.

The contrast between the two Draft 3 edits is revealing. One imposed a new temporal condition on the source’s future access to AFRINIC allocations; the other removed an automatic status loss from the resource. Each could be evaluated on its own terms. Neither rewired who was supposed to speak to whom in an inter-RIR transaction. Draft 3 adjusted policy consequences at the edges while leaving the central bridge intact.

The clauses that survived

The retained section 5.7.3.1 required the source to be the rightful holder registered with any RIR, to comply with the receiving RIR’s policies and not to be involved in a dispute over the resources. Several ideas were packed into one sentence.

Some of them belong naturally in a transfer protocol. The resource must be identified. The source must be the party recognised in the relevant registry record or must otherwise show authority to act. A genuine conflicting claim should not be ignored. These are checks against duplicate claims, mistaken identity and unauthorised action. They protect the integrity of the ledger and the continuity of service.

The problem was the direction of the compliance obligation. If the source was registered with one RIR and the recipient used another, requiring the source to comply with the receiving RIR’s policies treated destination rules as if they automatically governed a foreign party. Yet the receiving RIR might have no contract, account history, identity material or service relationship with that source. It was being assigned a vetting role without the evidence or institutional connection needed to perform it.

The text also retained a recipient-side arrangement that generated its own practical tension. A transfer entering AFRINIC was subject to a need-based evaluation, while a transfer leaving AFRINIC was to follow the receiving RIR’s policy. Elsewhere, the recipient could be any party with an agreement with the sender. AFRINIC staff read the breadth of that latter formulation as potentially conflicting with the preceding needs provision in some circumstances. Whatever policy case might be made for a recipient needs test, it remained separate from the identity of the registry that should verify the source.

Then came the procedural mismatch. Draft 3 directed the transferring party to send its request to the receiving RIR. After approval, the receiving RIR was to notify the transferring RIR and the parties. On paper, that may have appeared to create one doorway: begin where the resource is going, then send notice back. In institutional reality, it reversed the relationship through which reliable verification would normally occur.

The source registry knows the source. It maintains the relevant registration, can see account history, can check whether the resource is associated with that party, and is positioned to assess an active conflict flag. The receiving registry knows—or can establish a relationship with—the recipient. It can verify recipient identity and apply the terms of its own service. If the source instead begins at the receiving RIR, that registry has to obtain or recreate evidence held by the counterpart. At best, the design adds an unnecessary relay. At worst, it asks the wrong private institution to decide whether a stranger may act.

The October compatibility verdict

AFRINIC’s official Draft 3 page carries a staff assessment dated 13 October 2020. That assessment provides the clearest test of whether the two revisions had made the reciprocal bridge workable. The answer recorded there was not a subtle disagreement over drafting taste. Staff reported material compatibility objections from ARIN, APNIC, LACNIC and RIPE NCC.

ARIN and APNIC found the source-compliance clause incompatible. LACNIC said its policy did not require the source to comply with the other RIR. RIPE NCC found the section 5.7.5 initiation procedure incompatible and not implementable. The details varied, but the common structure was easy to see: counterpart procedures did not assign cross-region verification and first contact in the way Draft 3 expected.

AFRINIC staff articulated the ordinary division of responsibility. Each RIR dealt with the transferring party in its own region, and the RIRs communicated with one another. AFRINIC would not directly vet an external source with which it had no relationship. That explanation did more than identify a textual incompatibility. It named the institutional fact a reciprocal policy has to respect: the bridge connects registries, but it does not merge their customer relationships.

The assessment also identified implementation work across MyAFRINIC, reverse DNS, RPKI ROAs, transfer logs and ticketing, as well as process review, inter-RIR coordination, contracts, staffing and software engineering. These were not decorative administrative details. They were the systems through which recognised control and operational continuity would have to remain aligned. A policy sentence could announce reciprocity, but settlement required several records and services to change coherently.

Staff also anticipated possible financial and membership implications. Incoming legacy transfers would not increase membership, while outgoing transfers by AFRINIC resource members could reduce membership. That is an institutional projection, not evidence that such effects occurred. The available record establishes no realised membership decline, revenue loss, completed transfer or rejected transfer attributable to Draft 3.

The bounded conclusion is nevertheless strong. Draft 3 corrected two consequences inherited from Draft 2, but the staff assessment still found its reciprocal procedure materially incompatible with every counterpart RIR response recorded. The failure was architectural, not cosmetic: it placed responsibility across the wrong service relationships.