Resource Transfer Policy (Draft-3) Archived

1. Summary of the problem being addressed by this proposal

The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow a number of resources to be transferred from/to other regions. 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.

2. Summary of how this proposal addresses the problem

With the exhaustion of IPv4, several regions have adopted transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions.

Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operation while reducing prices.

Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow a number of resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual:

In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned.

Regarding resource transfer to other regions, only the following is mentioned:

5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered.

The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied.

The lack of a clear guideline of resources transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region.

Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination.

3. Proposal

CPM 5.7 will be modified by this proposal as follows:

Current	Proposed
5.7 IPv4 Resources transfer within the AFRINIC Region Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.	5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.
5.7.1 Summary of the policy This policy applies to an organization with a justified need for IPv4 resources that cannot be satisfied by AFRINIC.	5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region.
5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC member's account or from a Legacy Resource Holder in the AFRINIC service region.	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.
5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current rights holder of the IPv4 address resources recognized by AFRINIC, and not be involved in any dispute as to the status of those resources.	5.7.3. Conditions on the source of the transfer 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.
5.7.3.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC for a period of 12 months after a transfer approval.	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.
5.7.3.3 Source entities must not have received a transfer, allocation, or assignment of IPv4 number resources from AFRINIC for the 12 months prior to the approval of transfer request. This restriction excludes mergers and acquisitions transfers.	5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient.
5.7.4. Conditions on the recipient of the transfer 5.7.4.1 AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force.	5.7.4. Conditions on the recipient of the transfer 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. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.
5.7.4.2 The recipient must be an AFRINIC member, subject to current AFRINIC policies and must sign the Registration Services Agreement for resources being received.	5.7.4.2 The recipient can be any party who reaches an agreement of resource transfer with the sender.
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.	5.7.4.3 Transferred legacy resources will still be regarded as legacy resources.
	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. 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. 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. 5.7.5.3 When the receiving RIR approves the transfer, the resources will be transferred to the recipient.

4. References

Inter RIR-policies are adopted in RIPE, APNIC, LACNIC and ARIN. The record of these regions shows that Inter RIR facilitates smooth coordination and operation between RIRs.

The current proposal’s model is based on RIPE’s Inter RIR policy at :

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/inter-rir-transfers

Revision History

Date	Details
21 Sept 2020	Version 3: AFPUB-2019-V4-003-DRAFT03 - Section 5.7.3.2, and 5.7.4.3, have been updated.
13 Aug 2020	Version 2: AFPUB-2019-V4-003-DRAFT02 - Section 5.7.3.1, 5.7.4.1 and 5.7.4.3 have been updated.
30 Oct 2019	Version 1: AFPUB-2019-V4-003-DRAFT01 - Submitted for discussion

AFRINIC Staff Assessment

Date of Assessment	Relevant to Proposal
13 Oct 2020	AFPUB-2019-V4-003-DRAFT03

1.0 Staff Understanding of the Proposal

This policy proposal introduces a two-way inter-RIR transfer policy, thereby allowing IPv4 resources to be transferred within, into and out of the AFRINIC service region.

The conditions are interpreted as follows:-

A) for transfers within the region, i.e intra-RIR transfer

• The source entity must be the current holder of the IPv4 resource that is to be transferred.

• The source entity who is posting a transfer request must also provide a resource transfer agreement

• The source entity shall comply with the policies of the receiving RIR.

• There is no limit to the size of the resources transferred.

• Transfer source can request resources from AFRINIC after 12 months has elapsed, from the date of the previous transfer.

• There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient.

• Since according to Section 5.7.4.3, Transferred legacy resources will still be regarded as legacy resources, if a source is transferring legacy resources to a resource member, it is not clear as to whether recipient must justify the IPv4 needs in accordance with AFRINIC policies.

• In case non-legacy resources are being transferred by a source, the Recipient of a transfer must justify the IPv4 needs and shall be required to be an AFRINIC member.

• Therefore the recipient of a transfer if not yet an AFRINIC member shall have to apply for membership and undergo a needs-based assessment before a transfer is approved.

• Since according to Section 5.7.4.3, Transferred legacy resources will still be regarded as legacy resources, if the source is transferring legacy resources to an organisation that is neither an AFRINIC member nor a Legacy Resource Holder, it is not clear as to how AFRINIC shall handle such requests. Legacy Resource holders were inherited when AFRINIC was set up in 2005. The current business rules & bylaws only allow resource members to be registered in the AFRINIC WHOIS database.

B. for transfers from AFRINIC to another RIR (inter-RIR transfer)

• The source entity must be the current holder of the IPv4 resource that is to be transferred.

• The source entity who is posting a transfer request must also provide a resource transfer agreement

• The source entity shall comply with the policies of the receiving RIR(see clarification request)

• There is no limit to the size of the resources transferred

• A transfer source can request resources from AFRINIC after 12 months has elapsed, from the date of the previous transfer.

• There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient. The transferring(Source) 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 recipient of the transfer shall be in compliance with the policies of the receiving RIR.

• The receiving RIR shall notify the source entity and the source RIR and recipient if the transfer is approved and the source RIR will then transfer the resources.

• It is not clear as to why the source entity shall comply with the policies of the receiving RIR when it operates in the service region of the source RIR.

• The recipient entity is interpreted to be different from the source entity and bound to comply with the policies of the receiving RIRs.

• By submitting a transfer request to the receiving the RIR and not its RIR, the verification about whether the source entity is the current holder of the resources cannot be done.

C. for transfers from another RIR to AFRINIC (inter-RIR transfer)

• The source entity must be the current holder of the IPv4 resource that is to be transferred.

• The source entity who is posting a transfer request must also provide a resource transfer agreement.

• The source entity shall comply with the policies of the receiving RIR.

• There is no limit to the size of the resources transferred.

• The transferring (Source) 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 receiving RIR shall notify the source entity and the source RIR and recipient if the transfer is approved and the source RIR will then transfer the resources.

Since according to Section 5.7.4.3, Transferred legacy resources will still be regarded as legacy resources, if a source from another RIR is transferring legacy resources to a resource member, it is not clear as to whether recipient must justify the IPv4 needs in accordance with AFRINIC policies as per Section 5.7.4.1

"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. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force.",

If source from another RIR is transferring legacy resources to an organisation that is neither an AFRINIC member nor a Legacy Resource Holder, it is not clear as to how AFRINIC shall handle such requests. Legacy Resource holders were inherited when AFRINIC was set up in 2005. The current business rules & bylaws only allow resource members to be registered in the AFRINIC WHOIS database.

In case non-legacy resources are being transferred by a source from another RIR, the Recipient of a transfer must justify the IPv4 needs and shall be required to be an AFRINIC member. Therefore the recipient of a transfer if not yet an AFRINIC member shall have to apply for membership and undergo a needs-based assessment before a transfer is approved.

Since AFRINIC has no relationship with the source of a transfer that exists outside its service region, it will not accept any communication from the source organisation(resource holder). It recommends that the latter correspond with its RIR who shall conduct the appropriate vetting of the transfer request received from its resource holder(member or legacy) according to its policies and established business practices. The source RIR shall then communicate with AFRINIC.

AFRINIC will then evaluate the request of the recipient organisation in accordance with its policies and if successful, coordinate the transfer with the source RIR.

1.2 Staff Need more clarification from Authors

1. Section 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? This statement is not clear as source entities exist in and are subject to the policies of either AFRINIC (intra) or another RIR(inter), which are the source RIRs. In the case, an inter-RIR transfer from another RIR to AFRINIC, the source entity in that RIR will have no relationship with AFRINIC. Can the authors clarify as to what they exactly mean here?

2. Based on Sections 5.7.3.1 and 5.7.4.1, is the proposal requiring that each RIR evaluate both the transfer source and the transfer recipient even though one of the transferring party is from another region?

3. Section 5.7.5.1 mentions 'The transfer shall be in compliance with the policies of the receiving RIR'. Can authors clarify if according to this policy, transfers will happen even if the source does not comply with its RIR's policies?

4. 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??

5. Is this policy's intention to have AFRINIC create new resource holders with legacy status in its WHOIS database, simply because the organisation purchased legacy IPv4 from the market?

1.3 Perceived Implementation challenges

1. 5.7.1 This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. - It is impossible to apply and enforce this policy on resources holders from other regions. AFRINIC nor any other RIR have no mandate to evaluate organisations whose resources are domiciled in another RIR. Furthermore, this is not in line with the ICP2 document and the bylaws as these define the scope of AFRINIC's service region and resource holders from other regions are out of scope.

2. 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. - It is not possible to apply and enforce RIR policies on an Organisation domiciled in another region.

3. 5.7.4.2 as written, practically conflicting with 5.7.4.1. What would happen if only 5.7.4.2 is met and policy condition 5.7.4.1 is not met?

4. 5.7.4.3 Transferred legacy resources will still be regarded as legacy resources. - Can't happen for incoming legacy space and the recipient is not a resource member nor a legacy holder as the current Bylaws doesn't permit the creation of legacy resource holders in the WHOIS. Legacy holders were just accepted and created at the start to accommodate migration from other RIR's.

5. 5.7.5.1 . 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) - It can't be implemented as written, all RIR's have stated that they don't directly communicate with resource holders from another region, each RIR deals with the transferring party in their region and maintains Inter-RIR communication only at RIR level only.

6. 5.7.5.2 After the receiving RIR approves the transfer, it will notify the transferring RIR, the transferring party and the recipient. - It can't be implemented as written, all RIRs have stated that they don't directly communicate with resource holders from another region.

1.4 Reciprocity with others RIRs

This section has been added to document reciprocity/compatibility with the others RIRs inter-RIR policies, once AFRINIC has received their assessment.

RIR	Response
ARIN	ARIN has responded that the Resource Transfer Policy is not compatible with their inter-RIR transfer policies because of the following statement therein - “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.” would require a source in the ARIN region to comply with AFRINIC RIR policies.
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.”
LACNIC	First of all, LACNIC doesn´t demand reciprocity in the inter-RIR policy. However, there are some aspects which are important to consider: "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" LACNIC´s policy manual doesn´t request to the source organization to be in compliance with the other RIR policies. It wouldn´t have much sense to request that. 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.
RIPE NCC	Section 5.7.5 makes the policy not compatible with the RIPE policies and procedures and not possible to implement. For Transfers from AFRINIC to RIPE NCC: Since this policy states that the transferring party needs to contact the RIPE NCC. The RIPE NCC can not verify if he is the actual holder of the resources or if these resources comply with the policies in AFRINIC. (This is a requirement of the RIPE Policies) The RIPE NCC procedure states: "For transfers to the RIPE NCC service region, the RIPE NCC will be notified by the relevant RIR and contact the relevant party within the RIPE NCC service region."For Transfers from RIPE NCC to AFRINIC: The policy states that the transferring party should contact the receiving RIR(AFRINIC in this case). This is not compatible with the RIPE Policies which state that when transferring Internet number resources to another RIR, the RIPE NCC will follow the transfer policies that apply within its own service region. The RIPE NCC procedures state: "The transfer request is always initiated by the transferring party. The transferring party must send a request to the RIR where the Internet number resources are registered at the moment the request is made.”

2.0 Staff Comments On Areas of Impact

If the proposal reaches consensus:

2.1 Impact on Systems

1. The Transfer tool on MyAFRINIC will require further adjustments to accommodate inter-RIR transfers

2. Reverse DNS impacts to be considered (for majority /8s)

3. RPKI ROAs

4. Transfer logs

5. RT (AFRINIC Ticketing System)

2.2 Impact on Processes and procedure

1. Processes and procedures will require a review.

2. Coordination with the RIRs who have compatible inter-RIR transfer policies will also be required

3. Contractual agreements updates will be required

2.3 Impact on Operations

1. Resource Transfer evaluation are resource-intensive and MS department would require additional staffing needs to facilitate officiate and timely evaluations

2. Resources will also be required in the software engineering team to implement the transfer on the AFRINIC systems.

2.4 Impact on AFRINIC financials

Incoming legacy transfers (intra and inter) will not result in membership increase, while AFRINIC resource members transferring their resources to other RIRs will trigger a reduction in membership numbers.

2.5 Legal Assessment

At the outset, it is worth stating that there is no statutory bar for AFRINIC to ratify an Inter-RIR transfer policy if the need does arise, more so that such policy exists at the other RIRs.

However, the caveat is that, if and whenever the Board will be called upon to ratify the aforesaid policy, the latter will have to ensure that the decision is taken in line with the duties of directors as laid down in the Companies Act. For instance, one of the duties is that directors shall, at all times, act in the best interests of the company.

So what does the phrase "act in the best interests of the company" involve? Although there is no statutory guidance to that phrase, yet it may be interpreted to mean that the decision in question must, inter-alia, ensure that the company remains solvent at all times as well as ensuring continuity and sustainability of the business. "Solvent" means that the company is able to meet its debt and liabilities including but not limited to the payment of operational expenses etc.

3.0 Implementation

Implementation of policy, if ratified, will be done on myafrinic 2.0