Summary

  • An external compatibility table found four different failures in the transfer handoff proposed by AFPUB-2019-V4-003-DRAFT02: ARIN and APNIC objected to its source-compliance rule, RIPE NCC objected to its receiving-RIR initiation sequence, and LACNIC identified both mismatches despite not requiring reciprocity.
  • The correct identity of the instrument is essential. AFPUB-2019-V4-003-DRAFT02 was submitted on 13 August 2020; 8 October 2021 belongs to the separate AFPUB-2020-GEN-006-DRAFT02 lineage.
  • Draft 2 was proposed, discussed, assessed and archived. Neither a conditional rough-consensus announcement nor last call made it adopted, ratified, implemented or operational.
  • AFRINIC could legitimately authenticate and update the records for which it was responsible, coordinate with a compatible RIR and prepare dependent systems. It could not waive another registry's rules or turn management discretion into a substitute for compatibility.
  • A credible alternative would have been a versioned, pairwise compatibility certificate specifying who authenticates each party, where a request starts, which policy version applies and how all registry and routing-security records change atomically.

L3 — Four receiving rails that did not align

The most revealing artefact in the Draft 2 record is a table of answers from four other regional Internet registries. AFRINIC's proposal described a route for resources to move into and out of its service region. Yet when the proposed route reached the institutions that would have to complete the other half of the movement, each connection exposed a mismatch. The apparent lane on one registry's page was not an executable lane between two registries.

ARIN's response went to a sentence about the source. Draft 2 said that the source should be the current rights holder of IPv4 resources registered with any RIR and should comply with the receiving RIR's policies. ARIN regarded that condition as incompatible with its inter-RIR policy. APNIC reached the same basic conclusion. Its assessment said the relevant wording was shared by Draft 2 and Draft 3 and found the arrangement incompatible, particularly because it required the source to comply with the receiving registry's rules.

RIPE NCC identified a different point of failure. Section 5.7.5 told the transferring party to send the request to the receiving RIR, using a standard template and an official transfer agreement. After the receiving RIR approved, that registry would notify the transferring RIR, the source and the recipient, and the resources would be transferred. RIPE NCC's procedure began instead at the RIR where the resources were then registered. It therefore considered the Draft 2 sequence incompatible and not implementable. The disagreement was not about the aspiration to permit movement.

It concerned the first authoritative act: which registry receives a request when the source record and the means to verify its holder sit elsewhere.

LACNIC did not impose a reciprocity requirement, so its response is especially useful. The absence of a reciprocity demand did not make the design fit. LACNIC still said that requiring a source to comply with the other RIR's policy made little sense, and it found that the proposed receiving-RIR initiation did not match other inter-RIR arrangements. In other words, removing one possible policy barrier did not repair the operating sequence. A registry could be open in principle and still be unable to perform the handoff as drafted.

Those four answers were tied expressly to AFPUB-2019-V4-003-DRAFT02. They were not generic verdicts on all resource transfers, nor findings that every later version would fail. Compatibility attaches to text: to the clause in force, the direction of movement, the kind and status of resource, each registry's current policy and the actual steps used by its staff. Change one of those inputs and the test must be run again.

That precision begins with the proposal's identity. The Draft 2 examined here is the Resource Transfer Policy numbered AFPUB-2019-V4-003-DRAFT02, version 2.0, submitted on 13 August 2020 to amend section 5.7 of AFRINIC's Consolidated Policy Manual. A planning record paired that identifier with 8 October 2021, but the later date belongs to a different proposal, AFPUB-2020-GEN-006-DRAFT02. The identifiers and dates cannot be blended. A compatibility conclusion attached to one instrument cannot migrate to another merely because both deal with number-resource transfers.

The same restraint applies to institutional status. Draft 2 was proposed, discussed, assessed and eventually archived. It was presented at AFRINIC-32 on 17 September 2020. On 21 September, a co-chair summary announced conditional rough consensus and last call, identified an ARIN-related reciprocity concern and required amendments. Those were stages in a private policy-development process. They did not, alone or together, put the text into the manual, secure Board ratification or produce an implemented transfer rule. The appearance of Draft 3 on the same date confirms that the text was still moving.

Later drafts remain later drafts, while the separate proposal submitted in 2021 remains separate. The subsequent ratification of a third draft in that other lineage supplies no missing implementation evidence for this Draft 2.

What the proposal was trying to make movable

Draft 2 began from a genuine gap. The existing arrangement did not support a two-way inter-RIR mechanism. The proposal sought transfers within the AFRINIC region, into it and out of it, and its problem statement referred to IPv4 addresses and AS numbers. It offered a more open commercial surface than a regime of permanent regional captivity: it removed the existing 12-month waiting constraints and proposed no upper limit on the quantity transferred, allocated or assigned when sender and recipient had reached a mutual agreement, subject to current policy.

The draft did not abandon every check. For an incoming transfer, AFRINIC would retain a need-based evaluation and approve the recipient's IPv4 need under policies then in force. For an outbound transfer, the text said that the transfer must follow the receiving RIR's policy. The recipient could be any party that reached a transfer agreement with the sender. Transferred IPv4 legacy resources would cease to be treated as legacy resources. These provisions reveal an attempt to combine mobility, eligibility review and a defined change of registry status.

But the clauses did not settle who could establish the facts on which those decisions depended. AFRINIC staff asked why a source should comply with a receiving RIR with which the source had no relationship. They also said source-holder verification could not be completed if the source filed directly with the receiving RIR rather than the registry holding the source record. That is the same structural break later visible in the counterpart responses.

The receiving RIR might be competent to assess its intended recipient, but it did not thereby acquire the records, relationship or authentication means required to establish the source's control.

The staff assessment found additional uncertainty. It asked whether the proposed standard template was globally accepted. It found no guideline for resources under dispute and warned of repeat-allocation abuse. It identified a conflict between recipient clauses 5.7.4.1 and 5.7.4.2: broad wording allowed any party with a transfer agreement, while the staff reading of an AFRINIC-region recipient required AFRINIC membership and a needs assessment. The assessment also noted that ASNs appeared in the problem summary but not in the operative IPv4 clauses.

That drafting gap mattered because a statement of purpose does not by itself provide executable rules for a different resource class.

Each issue touches the handoff, not merely the prose. A disputed prefix cannot safely change registration state without an agreed way to preserve the dispute. An undefined template cannot be assumed to carry the evidence every counterpart requires. A conflict about recipient eligibility leaves staff without a stable decision rule. Mentioning ASNs without operative treatment leaves unanswered whether the same checks, statuses and dependent records apply. Unlimited quantity does not remove the need to know which precise objects are moving and which ledger is authoritative at each instant.

The machinery behind a policy sentence

AFRINIC's staff assessment made the operational surface unusually visible. An inter-RIR transfer would potentially require changes to the MyAFRINIC transfer tool, reverse DNS, RPKI route origin authorisations, transfer logs and the ticketing system. Staff anticipated process review, coordination with RIRs that had compatible policies, more member-services capacity and software-engineering work. A text that says resources “would be transferred” therefore compresses a series of linked acts.

The registry record has to move from one coherent state to another. Source control must be authenticated. Recipient eligibility and any applicable needs test must be decided by the institution with the relevant rule and relationship. The two RIRs need a message they both recognise as approval. Registration information must change without creating a moment in which both registries appear authoritative or neither does. Reverse DNS delegation and RPKI state must follow the intended holder. Public transfer history and internal tickets must preserve what happened and why.

If one dependent change fails, the organisations need a rollback state that does not duplicate recognition or strand the resource.

This is why the four replies cannot sensibly be read as invitations for AFRINIC management to make exceptions. A manager can direct work inside AFRINIC's legitimate operating remit. Management can ensure that an AFRINIC-held record is verified, that AFRINIC's systems are ready and that staff exchange agreed evidence with a counterpart. It cannot make ARIN accept a source condition that ARIN's policy does not recognise, make RIPE NCC start a case at the wrong end of its procedure or create an authentication relationship between a source and a receiving registry by assertion.

The practical exposure falls on operators even when the record proves no completed loss. NRS's account of transfer practice emphasises the importance of registry accounts, approval, membership status, documentation and the policy applicable at the relevant RIR. LARUS adds the infrastructure operator's perspective: governance decisions can affect continuity and transaction planning quietly, through the records and dependencies on which networks rely. Applied carefully here, those perspectives show why an ambiguous handoff creates diligence, delay and continuity risk.

They do not prove that Draft 2 caused an outage, a rejected transaction, a price loss or harm to a particular customer. The available record proves a design incompatibility and the work that implementation would have required, not a production incident.

The fair reading, and its limit

The strongest benign account deserves to be stated without qualification games. The authors saw a real economic and operational problem. IPv4 scarcity increased the value of being able to move resources across regional systems. AFRINIC had an intra-regional route but lacked the two-way inter-RIR route the proposal sought. Draft 2 tried to loosen quantity and waiting constraints while preserving needs review for incoming resources and policy compliance for outgoing transfers. It tried to describe a request, an agreement, an approval and notification sequence across five institutions whose language and procedures were not identical.

Counterpart replies take time, and a drafting error does not establish capture, bad faith or a plan to expand institutional power.

That account explains why the proposal was worth attempting. It does not turn a non-matching interface into a working one. A portability promise that stops when another registry opens its procedures is not yet portability. The answer was neither to abandon movement nor to let a manager approve around the mismatch. It was to freeze the exact version, ask each counterpart to test each direction and correct the handoff until both sides could execute the same authoritative change. Compatibility was the missing engineering property.