Proposal

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: 

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

Revision History

AFRINIC Policy Impact Assessment

AFRINIC Staff Assessment

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.

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