BTW.Media
Daily editionStrategic Internet Intelligence
Sign InRegister

AFRINIC · RIR Watchdog

Resource Transfer Policy (Draft-1) Archived

Start here for the proposal-by-proposal record: what changed, why it mattered, who argued for what, how positions evolved, what was decided, and where the evidence still has gaps.

Source facts

Policy ID
AFPUB-2019-V4-003
RIR
AFRINIC
Official status
Unknown
Normalized status
Unknown
Introduced
Oct 30, 2019
Last source update
Oct 16, 2026
Coverage
Partial

Who actually shaped the debate?

1Total participants
1Discussion contributors
UnknownFormal actors
1Discussion messages
1Effective participants
100%Top-five discussion share
1People covering 50%
1People covering 80%

Policy evolution

DRAFT02
Unknown · Archived
Aug 13, 2020
Source facts ↗

Conditions on the transfer source · Draft 2 replaces the proposed explicit no-dispute condition with a requirement that the source comply with the receiving RIR's policies. This reports the clause as written, without assuming that external rules about disputes cease to apply.

Source facts −
5.7.3.1 The source must be the current rightful holder of the IPv4 address resources registered with any RIR, and not be involved in any dispute as to the status of those resources.
Source facts ↗
Source facts +
5.7.3.1 The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR.
Source facts ↗

Need assessment for incoming transfers · Draft 2 replaces the proposed no-needs basis and conditional ten-year plan with a needs-based evaluation for transfers into AFRINIC. This comparison concerns the proposed column, not the existing CPM conditions reproduced beside it.

Source facts −
5.7.4.1 The transfer does not require approval from AFRINIC. It shall be approved as long as two parties are on mutual agreement to transfer. This policy is based on no need basis. However, if a transfer happens between AFRINIC and a region where needs basis is imposed, a plan must be submitted to AFRINIC which includes a brief illustration of the use of 50% of the transferred resources in the coming 10 years.
Source facts ↗
Source facts +
5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources.
Source facts ↗

Rules for outgoing transfers · Draft 2 expressly requires transfers from AFRINIC to another RIR to follow the receiving RIR's policy. The earlier proposal generally relied on mutual agreement, with a conditional plan where a needs-based region was involved.

Source facts −
This policy is based on no need basis. However, if a transfer happens between AFRINIC and a region where needs basis is imposed, a plan must be submitted to AFRINIC which includes a brief illustration of the use of 50% of the transferred resources in the coming 10 years.
Source facts ↗
Source facts +
A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.
Source facts ↗

Treatment of legacy status · Draft 1 proposes deleting the clause that strips transferred IPv4 resources of legacy status. Draft 2 instead retains that clause in its proposed column. This is a change between proposed drafts, not a claim about any completed transfer.

Source facts −
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. This paragraph will be removed.
Source facts ↗
Source facts +
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. 5.7.5 Procedure of the resource transfer
Source facts ↗

RIR handling of a transfer request · Draft 2 directs the source's request to the receiving RIR and refers to that RIR's policies. Draft 1 instead routes the request to the RIR where the resources are registered and refers to that transferring RIR's policies.

Source facts −
If the two parties agree, the transferring party will send a request to the RIR with which the resources are registered, using a standard template and submit an official agreement of resource transfer to the involved RIR(s). The transfer shall be in compliance with the policies of the transferring RIR.
Source facts ↗
Source facts +
If the two parties agree, the transferring party will send a request to the receiving RIR, using a standard template and submit an official agreement of resource transfer to the involved RIR(s). The transfer shall be in compliance with the policies of the receiving RIR.
Source facts ↗

Staff assessment of ASN coverage · Draft 2 includes a staff warning that ASN transfers are mentioned in the summary but the operative clauses refer only to IPv4. The summary's reference to AS numbers already appears in Draft 1, so this assessment is not evidence of newly added operative ASN rules.

Source facts −
This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers.
Source facts ↗
Source facts +
ASN transfer is mentioned only in the summary of the problem but all text in the policy clauses refers to IPv4 only, this is confusing and will lead to misinterpretation. It is important to have ASN inclusion clearly stated in the policy text
Source facts ↗

Notification after transfer review · Draft 2 makes the receiving RIR notify the transferring RIR and parties after approval. Draft 1 makes the transferring RIR notify the receiving RIR and parties after deciding the request can proceed.

Source facts −
5.7.5.2 After the transferring RIR has reviewed the application and deemed that it is appropriate to proceed with the transfer, it shall notify the receiving RIR, the transferring party and the recipient.
Source facts ↗
Source facts +
5.7.5.2 After the receiving RIR approves the transfer, it will notify the transferring RIR, the transferring party and the recipient. The resources will be transferred to the recipient.
Source facts ↗
DRAFT03
Unknown · Archived
Aug 13, 2020
Source facts ↗

Disputed resources · Draft 3 restores an explicit prohibition on the source being involved in a dispute about the resources' status, alongside the receiving-RIR compliance requirement. Draft 2's proposed clause omits the explicit dispute restriction.

Source facts −
5.7.3.1 The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR.
Source facts ↗
Source facts +
5.7.3.1 The source must be the current rightful holder of the IPv4 address resources registered with any RIR, and shall be in compliance with the policies of the receiving RIR, and shall not be involved in any dispute as to the status of those resources.
Source facts ↗

Further AFRINIC allocations after a transfer · Draft 3 bars a transfer source from further AFRINIC allocations or assignments for 12 months after approval. Draft 2 instead permits further resources subject to current policy. The unchanged current-policy column must not be mistaken for the earlier proposed condition.

Source facts −
5.7.3.2 Source entities are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy.
Source facts ↗
Source facts +
5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for 12 months period after a transfer is approved.
Source facts ↗

Preservation of legacy status · Draft 3 changes the proposed clause so transferred legacy resources retain legacy status. Draft 2's proposed clause removes that status. The comparison does not itself determine the consequences for membership, registration or need assessment.

Source facts −
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. 5.7.5 Procedure of the resource transfer
Source facts ↗
Source facts +
5.7.4.3 Transferred legacy resources will still be regarded as legacy resources. 5.7.5 Procedure of the resource transfer
Source facts ↗

ARIN compatibility feedback · Draft 3's assessment records ARIN's negative compatibility response concerning the requirement on a source to comply with the receiving RIR's policies. Draft 2 already raised this as a staff clarification issue. This is historical feedback on that draft, not a present-day compatibility finding.

Source facts −
The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?
Source facts ↗
Source facts +
ARIN has responded that the Resource Transfer Policy is not compatible with their inter-RIR transfer policies because of the following statement therein
Source facts ↗

RIPE NCC process feedback · Draft 3's assessment adds RIPE NCC feedback that section 5.7.5 conflicts with its policies and procedures and cannot be implemented as written. Draft 2 had already requested clarification on the proposed standard template. This records historical feedback, not a newly enacted procedure.

Source facts −
5.7.5.1 speaks of using a standard template. Clarification is needed on this standard template - Is it a globally accepted standard template across all regions?
Source facts ↗
Source facts +
RIPE NCC Section 5.7.5 makes the policy not compatible with the RIPE policies and procedures and not possible to implement.
Source facts ↗

Conflicting captured submission dates · The Draft 3 page still gives 2020-08-13 in its details, while its revision history dates Version 3 to 21 September 2020. Draft 2's details and version history use August. The source conflict is retained; the comparison does not invent a corrected submission date.

Source facts −
Date Submitted 2020-08-13 Author(s) Refer to Proposal Tab Status Archived
Source facts ↗
Source facts +
21 Sept 2020 Version 3: AFPUB-2019-V4-003-DRAFT03 - Section 5.7.3.2, and 5.7.4.3, have been updated.
Source facts ↗

APNIC compatibility feedback · Draft 3's staff assessment records APNIC's negative compatibility response, particularly about applying the receiving RIR's policies to the source. Draft 2 had raised the underlying jurisdiction question without this reported APNIC response.

Source facts −
The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?
Source facts ↗
Source facts +
APNIC The APNIC inter-RIR policy is not compatible with the current text, especially “ The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR. ”
Source facts ↗

LACNIC feedback on the proposed procedure · Draft 3 records LACNIC's objection that the receiving-RIR-first request and notification procedure differs from how inter-RIR transfers were established. This is captured feedback, distinct from the proposal's own procedure and any later implementation.

Source facts −
5.7.5.2 After the receiving RIR approves the transfer, it will notify the transferring RIR, the transferring party and the recipient. The resources will be transferred to the recipient.
Source facts ↗
Source facts +
Paragraph 5.7.5 "Procedure of the resource transfer” states that the transferring party will submit a transfer request to the receiving RIR (Not the offering) and the receiving RIR will notify the transferring RIR once it approves the transfer". This is not in line with how INTER-RIR transfers were set up in any of the other RIR.
Source facts ↗
DRAFT04
Unknown · Archived
Oct 18, 2020
Source facts ↗

Eligible resource holdings · Draft 4 replaces the proposed description of any holder posting a request and supplying an agreement with resources held in an AFRINIC or other RIR member account, or by a legacy holder. This changes the eligibility wording; other applicable requirements are not inferred away.

Source facts −
5.7.2 IPv4 resources to be transferred – any resource holder who posts a transfer request to another party. An agreement of resource transfer shall be provided.
Source facts ↗
Source facts +
5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder.
Source facts ↗

Source jurisdiction requirement · Draft 4 removes the proposed requirement that the source comply with the receiving RIR's policies, while retaining rightful-holder and no-dispute conditions. This is a textual change, not proof that the earlier cross-RIR objections were all resolved.

Source facts −
5.7.3.1 The source must be the current rightful holder of the IPv4 address resources registered with any RIR, and shall be in compliance with the policies of the receiving RIR, and shall not be involved in any dispute as to the status of those resources.
Source facts ↗
Source facts +
5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR, and shall not be involved in any disputes as to those resources' status.
Source facts ↗

Holding period before retransfer · Draft 4 adds a 12-month prohibition on retransferring an incoming transferred resource. It retains the separate 12-month restriction on a source receiving new AFRINIC allocations or assignments.

Source facts −
5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for 12 months period after a transfer is approved.
Source facts ↗
Source facts +
5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. An incoming transferred resource cannot be transferred again for a period of twelve (12) months.
Source facts ↗

Applicable policies for outgoing transfers · Draft 4 changes the outgoing-transfer clause from the receiving RIR's policy to the relevant policies. The new phrase is broader but does not enumerate which policies apply.

Source facts −
A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.
Source facts ↗
Source facts +
A transfer from AFRINIC to another RIR must follow the relevant policies.
Source facts ↗

Recipient eligibility · Draft 4 replaces any mutually agreeing recipient with an AFRINIC or other RIR member, or a legacy holder in any region. The needs-based clause for transfers into AFRINIC remains.

Source facts −
5.7.4.2 The recipient can be any party who reaches an agreement of resource transfer with the sender.
Source facts ↗
Source facts +
5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region
Source facts ↗

Scope of legacy-status preservation · Draft 4 limits its express preservation of legacy status to incoming transferred legacy resources, whereas Draft 3 says transferred legacy resources generally. The comparison does not invent a status rule for outgoing transfers.

Source facts −
5.7.4.3 Transferred legacy resources will still be regarded as legacy resources. 5.7.5 Procedure of the resource transfer
Source facts ↗
Source facts +
5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources. 4. References
Source facts ↗

Detailed transfer procedure removed · Draft 4 omits the proposed 5.7.5 procedure, including the source's direct request to the receiving RIR and that RIR's notification steps. Its operative text ends after 5.7.4.3. This removes the draft's directions; it does not establish a replacement procedure.

Source facts −
5.7.5 Procedure of the resource transfer 5.7.5.1 The transferring party who holds the resources can initiate a transfer request between itself and an external party.
Source facts ↗
Source facts +
5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources. 4. References
Source facts ↗

No updated assessment established · Draft 3 includes a dated staff assessment and compatibility feedback. The retained Draft 4 page only says an assessment is to be updated. That placeholder is not evidence that the earlier concerns were resolved or that the revised proposal was approved.

Source facts −
AFRINIC Staff Assessment Date of Assessment Relevant to Proposal 13 Oct 2020 AFPUB-2019-V4-003-DRAFT03
Source facts ↗
Source facts +
AFRINIC Staff Assessment (to be updated soon)
Source facts ↗

Debate timeline

  1. Introduced

    Introduced

    Source facts ↗

  2. Official version

    DRAFT01

    Unknown · Archived

    Source facts ↗

  3. Official version

    DRAFT02

    Unknown · Archived

    Source facts ↗

  4. Official version

    DRAFT03

    Unknown · Archived

    Source facts ↗

  5. Official version

    DRAFT04

    Unknown · Archived

    Source facts ↗

Entities

Freshness: Stale
  1. Haruna Umar Adoga Only for Strategic Circle
    Discussion messages1
    First activitySep 17, 2020
    Last activitySep 17, 2020
    First explicit stanceSupport
    Latest explicit stanceSupport
    Stance changes0
    Viewpoint consistencyInsufficient evidence to assess consistency
    Other policies4
    Freshness: Stale

    Last research attempt: Oct 21, 2026

    Identity verified: Oct 21, 2026

    Federal University of Lafia · Current
    Haruna Umar Adoga is a Lecturer I, in the Department of Computer Science
    fulafia.edu.ng

    Verified public profiles

    Discussion messages
    1
    First activity
    Sep 17, 2020
    Last activity
    Sep 17, 2020
    First explicit stance
    Support
    Latest explicit stance
    Support
    Stance changes
    0
    Viewpoint consistency
    Insufficient evidence to assess consistency
    Other policies
    4

    First explicit stance: Support → Latest explicit stance: Support · Stance changes: 0

    Viewpoint consistency: Insufficient evidence to assess consistency

    He supports incoming resources to improve broadband access. He does not discuss outbound conditions; one statement cannot establish consistency over time.

    Resource Transfer Policy (Draft-1) Archived

    Assessment: Insufficient evidence to assess consistency · He supports incoming resources to improve broadband access. He does not discuss outbound conditions; one statement cannot establish consistency over time.

    Hi all, I am in full support of the Resource Transfer Policy, because it?s time for us, as a community to move forward and stop lagging behind, when compared to the other RIRS (in terms of number of available resources). Allowing the transfer of resources into our region will help with the current efforts of increasing broadband penetration in Africa.

    IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft 1 | Archived · Resource Transfer Policy (Draft-1) Archived

    Assessment: Insufficient evidence to assess consistency · He challenges a scarcity argument in one proposal and invokes resource availability in the other. This tension merits scrutiny, but different proposals and claims do not by themselves prove contradiction. He does not explain his preference between their rules.

    One of the false arguments (in my opinion) made by the author of the IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) proposal, is that new businesses are unable to get IP addresses, which is slowing down the growth of businesses in Africa. If we can have statistics that supports this claim, it will be helpful, as I am not convinced that not having this policy is hindering IP assignments to businesses in our region. I am however not in support of this proposal in its current draft.

    Hi all, I am in full support of the Resource Transfer Policy, because it?s time for us, as a community to move forward and stop lagging behind, when compared to the other RIRS (in terms of number of available resources). Allowing the transfer of resources into our region will help with the current efforts of increasing broadband penetration in Africa.

    1. Sep 17, 2020 · Support

      [rpd] RESOURCE TRANSFER POLICY

      Conditions:

      Supports the Resource Transfer Policy because inbound resources could help broadband expansion and reduce the perceived gap with other RIRs.

      This message does not discuss outbound-transfer safeguards or quantify the expected benefit.

      Hi all, I am in full support of the Resource Transfer Policy, because it?s time for us, as a community to move forward and stop lagging behind, when compared to the other RIRS (in terms of number of available resources). Allowing the transfer of resources into our region will help with the current efforts of increasing broadband penetration in Africa.

      Source facts ↗
    Per-policy stance timelines:AFPUB-2010-GEN-005 · Unknown · Insufficient evidence to assess consistencyAFPUB-2019-GEN-001 · Support with changes · Insufficient evidence to assess consistencyAFPUB-2019-GEN-006-DRAFT03 · Oppose · Insufficient evidence to assess consistencyAFPUB-2019-V4-002 · Oppose · Insufficient evidence to assess consistencyAFPUB-2019-V4-003 · Support · Insufficient evidence to assess consistency

    Total policy messages: 11

Sources and coverage

Official policy sources

Public discussion archives

  • afrinic-rpd
    Earliest captured
    Aug 4, 2004
    Latest captured
    Aug 25, 2026
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    11,102
    Known gaps
    0
  • www.afrinic.net
  • afrinic-africann
    Earliest captured
    Aug 3, 2026
    Latest captured
    Oct 22, 2026
    Last refresh
    Oct 19, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    1,900
    Known gaps
    2
  • afrinic-afripv6-discuss
    Earliest captured
    Aug 17, 2015
    Latest captured
    Sep 18, 2026
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    2,538
    Known gaps
    0
  • afrinic-announce
    Earliest captured
    Aug 18, 2015
    Latest captured
    Sep 18, 2026
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    2,497
    Known gaps
    0
  • afrinic-community-discuss
    Earliest captured
    Sep 11, 2015
    Latest captured
    Dec 29, 2019
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    3,209
    Known gaps
    0
  • afrinic-dbwg
    Earliest captured
    Sep 9, 2016
    Latest captured
    Oct 21, 2026
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    547
    Known gaps
    0
  • afrinic-dnssec-ops
    Earliest captured
    Aug 18, 2015
    Latest captured
    Dec 1, 2016
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    307
    Known gaps
    0
  • afrinic-icp2-review
    Earliest captured
    Apr 10, 2025
    Latest captured
    Nov 10, 2025
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-measurement-wg
    Earliest captured
    Feb 1, 2018
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    138
    Known gaps
    0
  • afrinic-mira
    Earliest captured
    Nov 17, 2020
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-ois-wg
    Earliest captured
    Sep 9, 2021
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-rpki-discuss
    Earliest captured
    Jan 15, 2016
    Latest captured
    Apr 23, 2026
    Last refresh
    Oct 25, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    154
    Known gaps
    0

Coverage

Partial
Earliest captured: Aug 4, 2004
Latest captured: Oct 25, 2026

Freshness

Freshness: Stale · Last refresh:

Known gaps

  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-rpd: Source coverage is incomplete. · The source boundary has not yet been reached.
  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-africann: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-afripv6-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-announce: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-community-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-dbwg: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-dnssec-ops: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-measurement-wg: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-rpki-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.