Summary

  • On 13 May 2019, Jordi Palet Martinez submitted version 1.0 of IPv4 Inter-RIR Legacy Resource Transfers, AFPUB-2019-v4-001-DRAFT01. It was marked “Under discussion”, received no consensus at AFRINIC-30 on 19 June, and is not shown by the available record to have been adopted or implemented.
  • Draft 1 addressed a real weakness: AFRINIC maintained legacy registrations inherited from earlier registries even though the holders were outside the ordinary Registration Service Agreement chain. A sound transfer process needed to verify the current holder, check for a live dispute, coordinate with another RIR and update the registry consistently.
  • Those checks were not the same thing as the draft’s other consequences. It required an in-region recipient to demonstrate need and become a member subject to applicable policies and legal documents or service agreements, and it said legacy status would disappear in intra-AFRINIC and incoming inter-RIR transfers. It did not state the resulting status of outgoing legacy space.
  • The proposal did not create a transfer fee. AFRINIC’s February 2018 service guide supplied the relevant fee baseline: no transfer fee for a non-member legacy transferor, with applicable membership and allocation or assignment charges on the recipient side.
  • A private technical registry may charge transparent service costs and refuse to alter a record until identity and control are properly established. It cannot turn reliance on its ledger into sovereign authority, a final ruling on title, compulsory contractual annexation or a hidden surrender of legacy status.

L3 — The record that arrived without a contract

The administrative problem began long before the proposal. Some IPv4 and ASN registrations pre-dated the Regional Internet Registry system. AFRINIC later described how it inherited records from RIPE NCC, ARIN and APNIC for holders in its service region. It maintained those records even though there was no contractual relationship between AFRINIC and the legacy holder. The registry therefore possessed a database entry and provided related services, but that did not place the holder inside the ordinary chain of membership and Registration Service Agreement obligations.

That distinction could be easy to overlook when nothing changed. A stable row could remain useful to operators without forcing anyone to decide how much legal meaning the registry attached to it. A transfer request exposed every unresolved question at once. Who was entitled to ask for the entry to be changed? Was the request genuine? Did somebody else dispute control of the same block? If a recipient sat in another region, would the two registries publish compatible records?

And once the row changed, would AFRINIC describe the event as a correction of operational information or as the moment at which an inherited historical position was extinguished?

For the holder, the distinction affected more than administrative convenience. A stale or inaccurate registration could complicate due diligence, reverse-DNS administration, operational coordination and confidence at settlement. Yet an accurate registration obtained only by accepting new contractual exposure would carry a different price. For the recipient, dependable recognition mattered because the usefulness of an IPv4 block depends partly on other networks and service providers being able to associate it with the right operator.

For the wider network, the value of the registry lay in making one coherent account easier to trust than competing informal claims. Each interest favoured reliable verification. None, by itself, answered whether a private record keeper could make a new contract or a loss of legacy status the unavoidable toll for correcting its book.

AFPUB-2019-v4-001-DRAFT01 put that problem into a specific proposal. The official page identifies it as version 1.0 of “IPv4 Inter-RIR Legacy Resource Transfers”, authored by Jordi Palet Martinez and submitted on 13 May 2019. Its status was “Under discussion”, and it proposed amendments to article 5.7 of AFRINIC’s Consolidated Policy Manual. The draft’s problem statement said AFRINIC lacked an inter-RIR mechanism for legacy IPv4 transfers despite an existing market. It warned that transfers taking place outside an official process could cause registration history to be lost.

That concern gives the proposal its strongest justification: if control changes while the public record does not, the registry becomes less accurate precisely when users most need it.

The 13 May text recognised two broad transfer settings. An intra-RIR transfer placed both source and recipient in the AFRINIC service region. An inter-RIR transfer placed one party in that region and the other in the service region of another RIR. The direction of an inter-RIR transfer mattered. When AFRINIC was the source registry and the recipient was elsewhere, only legacy IPv4 resources could be transferred out under Draft 1. The text did not impose that same legacy-only restriction on resources entering the AFRINIC region.

The meeting record later summarised the design in the same direction: any kind of IPv4 resource could enter AFRINIC, but only legacy IPv4 could leave under this proposal.

That asymmetry was not a small drafting detail. It marked Draft 1 as a legacy-focused compromise rather than a general opening of all AFRINIC-held IPv4 resources to outbound inter-RIR movement. The author made compatibility claims about the surrounding RIR landscape: the proposal said it would permit bidirectional transfers with LACNIC and RIPE, limit exchanges with APNIC to legacy resources, and prevent exchanges with ARIN because of reciprocity wording. Those statements establish what the proposer claimed about compatibility.

They are not an independent finding that each other registry would necessarily have accepted a particular transaction.

The source-side checks were more straightforward. Draft 1 required the source to be the current rightful holder recognised by the relevant RIR. It also required that the source not be involved in a dispute about the status of the resource. These conditions addressed two elementary risks. A registry should not replace a record on the instruction of a stranger, and it should not present a disputed change as settled while it knows that competing claims exist.

AFRINIC’s own legacy-holder guidance describes the same practical need in service terms: it asks for evidence of holdership before making a WHOIS update and changes organisation and resource-registration details only after deciding that the requester is entitled to seek the change.

The later legacy-holder page cannot be treated as a verbatim record of every procedure in force on 13 May 2019. It has been updated since then. Its relevance is narrower and durable: AFRINIC itself acknowledges both parts of the anomaly, the absence of an ordinary contract with legacy holders and the need to verify entitlement before modifying a record. That combination supports strong authentication. It does not prove that authentication must culminate in a new contract, or that AFRINIC’s recognition finally decides underlying ownership.

Draft 1 also retained a twelve-month consequence for a transfer source. After a transfer, the source would not be eligible to receive further IPv4 allocations or assignments from AFRINIC for twelve months. In the proposed column, however, the text omitted the then-existing restriction based on receipt of an allocation or assignment during the preceding twelve months. The difference matters when reading the exact draft. The proposal cannot safely be summarised as merely carrying forward an unchanged timing rule; it kept the post-transfer restraint while leaving out the prior-receipt condition from the proposed text.

The recipient faced a different set of requirements. If the recipient was in the AFRINIC service region, AFRINIC would approve demonstrated IPv4 need under existing policies. If the recipient was in another RIR region, the destination RIR’s policies supplied the relevant criterion. Draft 1 further said that the recipient had to be a member of the relevant RIR and subject to that RIR’s policies and legal documents or service agreements. In practical terms, the proposal joined the registry update to an institutional entry condition on the recipient side.

The record would not simply name a new operational holder; for an AFRINIC-region recipient, it would place that recipient within AFRINIC’s contemporary membership and service relationship.

The most explicit status consequence concerned legacy classification. Draft 1 said that legacy IPv4 resources would no longer be regarded as legacy in an intra-RIR transfer. It said the same for an inter-RIR transfer coming into the AFRINIC service region. It did not state the resulting legacy status of a legacy resource transferred out of AFRINIC’s region. That silence must remain silence. It cannot be filled by importing a later view, guessing what another RIR would do or generalising the two express clauses into a universal rule. The exact 13 May document specified two cases and left the outgoing consequence unstated.

Fees require an equally careful separation of documents. Draft 1 did not create, set or collect a transfer fee. The contemporaneous service baseline comes from AFRINIC’s transfer guide labelled February 2018. Under that guide, a non-member legacy transferor paid no transfer fee. A recipient joining as a new member paid the annual membership fee and a once-off allocation or assignment charge; an existing-member recipient paid the applicable once-off charge and had to remain in good standing. Those terms show how AFRINIC then allocated service costs between the parties. They must not be rewritten as provisions enacted by the May 2019 proposal.

There is a sensible administrative logic to the fee asymmetry. Waiving a source-side transfer fee for a non-member legacy holder lowers one obstacle to bringing an inherited record into a formal, verifiable process. Recipient-side membership and resource-service charges can, in principle, pay for continuing services received by the recipient. But the available material contains no cost study demonstrating that the amounts precisely matched processing expense. It also gives no measured participation rate and no quantified effect on IPv4 prices or transaction volume.

The sound conclusion is therefore limited: transparent, cost-related charges can support registry work, while the sealed history here does not establish the financial incidence of the guide’s fee schedule in practice.

Draft 1 remained a proposal. At AFRINIC-30 on 19 June 2019, it was discussed alongside a separate comprehensive-scope proposal. The two should not be merged. The meeting minutes record the author saying that their content differed by one sentence, but their policy scope was distinct, and the legacy-only proposal retained its particular outbound boundary. Participants raised objections from the floor. The co-chairs found no consensus and returned both proposals to the mailing list. No consensus at that meeting means Draft 1 had not crossed AFRINIC’s own private policy-development threshold.

It does not turn the meeting into a legislature, nor does it imply that public authority would have arisen had participants agreed.

The official proposal page later included a staff assessment dated 20 July. Its placement can tempt a reader to flatten two records into one, but its statements belong to AFRINIC staff, not to the author’s exact 13 May wording. Staff understood transferred legacy space as falling under an RSA and losing legacy status, and staff identified implementation questions. The assessment recorded no comments from a legal adviser. It is relevant evidence of how staff interpreted the proposed operational consequences. It is not an enacted rule, a legal judgment or proof that a holder agreed with that interpretation.

The page records a last modification on 3 December and retains “Under discussion” status with a single revision-history entry. Nothing in the available record proves a later version of this draft, adoption, implementation or a completed transfer under it. No named legacy holder is shown to have lost status. No fee is shown to have been charged under the proposal. No court is shown deciding whether IPv4 addresses were property, and no commercial price or measurable liquidity loss is established. These limits do not weaken the analysis.

They keep it attached to what Draft 1 actually proposed and to the institutional choices visible in its clauses.