Resource Transfer Policy (Draft-1) Archived

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.

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.

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.

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.

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.

A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.

5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. This paragraph will be removed.

5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. 5.7.5 Procedure of the resource transfer

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.

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.

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.

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

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.

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

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 are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy.

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.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. 5.7.5 Procedure of the resource transfer

5.7.4.3 Transferred legacy resources will still be regarded as legacy resources. 5.7.5 Procedure of the resource transfer

The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?

ARIN has responded that the Resource Transfer Policy is not compatible with their inter-RIR transfer policies because of the following statement therein

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?

RIPE NCC Section 5.7.5 makes the policy not compatible with the RIPE policies and procedures and not possible to implement.

Date Submitted 2020-08-13 Author(s) Refer to Proposal Tab Status Archived

21 Sept 2020 Version 3: AFPUB-2019-V4-003-DRAFT03 - Section 5.7.3.2, and 5.7.4.3, have been updated.

The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?

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. ”

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.

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.

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.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder.

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

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

A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.

A transfer from AFRINIC to another RIR must follow the relevant policies.

5.7.4.2 The recipient can be any party who reaches an agreement of resource transfer with the sender.

5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region

5.7.4.3 Transferred legacy resources will still be regarded as legacy resources. 5.7.5 Procedure of the resource transfer

5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources. 4. References

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.

5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources. 4. References

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

AFRINIC Staff Assessment (to be updated soon)