Hello Chuck, Thank you for your response. Noted.
Kind regards, Anthony Ubah On Thu, Oct 15, 2020, 7:39 AM chku <c...@twnic.tw> wrote: > Dear Anthony, > > Thank you for sharing your proposal in the APNIC policy mailing list. > > We have reviewed your proposal text and confirm that it is compatible > with APNIC Inter-RIR transfer policy. > > Regards > Bertrand and Ching-Heng > Policy SIG Chairs > > > -----Original message----- > *From:*Anthony Ubah<ubah.tonyi...@gmail.com> > *To:*sig-policy<sig-policy@lists.apnic.net> > *Date: * Tue, 13 Oct 2020 16:01:02 > *Subject:* [sig-policy] AFRINIC Inter-RIR transfer Policy reciprocity > with APNIC_Resource Transfer Policy proposal > Hello APNIC, > > We are the authors of the Resource Transfer Policy, which is the inter-RIR > transfer proposal that has just reached consensus within Afrinic, and we > are reaching out to you so as to inquire about its reciprocity with APNIC. > > Your assessment and analysis of this matter would highly be appreciated. > > Please find below the proposal for your reference. > > We are looking forward to hearing from you. > > *Draft Below......* > > Resource Transfer Policy > > Authors: Anthony Ubah & Taiwo Oyewande > > Submission date: 21/09/2020 > > Version: 2.0 > > Amends: CPM 5.7 > > > > *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 number 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 a 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 operations 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 number 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 resource 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: > > > > 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 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 or any RIR member's account or from a Legacy Resource Holder. > > > > *5.7.3. Conditions on the source of the transfer5.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 a period of twelve (12) months > after a transfer is approved. Incoming transferred resource cannot be > transferred again for a period of twelve(12) months. > > *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 source and the recipient. > > > > *5.7.4. Conditions on the recipient of the transfer5.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 relevant policies. > > *5.7.4.2* The recipient must be an AFRINIC or any RIR member, legacy > holders in any region > > *5.7.4.3 *Incoming transferred legacy resources will still be regarded as > legacy resources. > > *Best Regards,* > > *UBAH ANTHONY* > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
