<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=ES link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1>Hi Erik,<o:p></o:p><o:p> </o:p>Regarding your response on reciprocity: If we do that in AFRINIC, then, there is no reciprocity with ARIN, which is the bigger “donor”.<o:p></o:p><o:p> </o:p>I already tried several models, for both LACNIC and AFRINIC, and they didn’t work out. Finally, making a full reciprocal proposal in LACNIC worked and it was implemented already since last July.<o:p></o:p><o:p> </o:p>I also included a “security belt” in the AFRINIC proposal so the board can “control” if anything is going wrong by six consecutive months, to stop the policy … the community was happy initially with that, but later on, there were to other competitive proposals that make the people unhappy again …<o:p></o:p><o:p> </o:p>Point 5.7.4.3 is broken, the idea was “incoming transferred legacy resources will no longer be regarded as legacy”, because that’s what we have now already for intra-RIR (and this policy motifies that to become intra and inter).<o:p></o:p><o:p> </o:p><div>Regards,<o:p></o:p>Jordi<o:p></o:p>@jordipalet<o:p></o:p><o:p> </o:p></div><o:p> </o:p><o:p> </o:p><div><div>El 19/10/20 15:52, "address-policy-wg en nombre de Erik Bais" <<a href="mailto:address-policy-wg-bounces@ripe.net">address-policy-wg-bounces@ripe.net</a> en nombre de <a href="mailto:ebais@a2b-internet.com">ebais@a2b-internet.com</a>> escribió:<o:p></o:p></div></div><div><o:p> </o:p></div>Hi Petrit & Taiwo,<o:p></o:p> <o:p></o:p>Petrit, <o:p></o:p> <o:p></o:p>could you have a look at the following question from Taiwo in regards to the Afrinic policy proposal reciprocity with the current RIPE Transfer Policy. <o:p></o:p> <o:p></o:p>To Taiwo, <o:p></o:p> <o:p></o:p><personal view> <o:p></o:p>Personally I would argue if reciprocity should be desired for the Afrinic region, as long as AFRINIC still holds IP numbers to be handed out. <o:p></o:p>I personally would prefer the AFRINIC inter-rir transfer policy to be incoming from other RIR’s only, to avoid the AFRINIC space to be removed from the region. ( As I think Afrinic would need them more to develop its own inter regional growth. ) <o:p></o:p>Am I correct to assume that Afrinic at the current distribution rate would have about 30 months of IP space left ? So perhaps opening the bi-directional inter-rir transfers, could start once the AFRINIC region actually has no space left in its free pool. <o:p></o:p></end personal view> <o:p></o:p> <o:p></o:p>In the RIPE region, there is a 24 month transfer limitation on the resource that was transferred itself, there is no further limitation on either the leaving (source) or receiving (target) entity to engage in other transactions. <o:p></o:p> <o:p></o:p>On the point : <o:p></o:p><![if !supportLists]>Ø <![endif]>5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region<o:p></o:p> <o:p></o:p>The AFRINIC legal team might have to look if this is phrased correctly, as you can’t (shouldn’t be able ) to move Afrinic Allocated space to a Legacy space holder.. Afrinic allocated space should only be able to move to any of the other RIR members. Not directly to a Legacy holder. <o:p></o:p>Legacy space registered in the Afrinic region could go to any organisation, regardless if they are a RIR member. There might be other contractual requirements required in the receiving RIR.. as the RIPE legacy policy would explain for the RIPE region. <o:p></o:p> <o:p></o:p>I can see the intention, but that is not what the policy states. (or how I read it..) <o:p></o:p> <o:p></o:p>And on point : <o:p></o:p><![if !supportLists]>Ø <![endif]>5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.]<o:p></o:p> <o:p></o:p>If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ‘policy’ <o:p></o:p> <o:p></o:p>Regards,<o:p></o:p>Erik Bais<o:p></o:p> <o:p></o:p>Co-chair of AP-WG <o:p></o:p> <o:p></o:p><a href="https://www.ripe.net/publications/docs/ripe-682">https://www.ripe.net/publications/docs/ripe-682</a> - RIPE Transfer policy ( including intra and inter-rir transfers ) <o:p></o:p><a href="https://www.ripe.net/publications/docs/ripe-639">https://www.ripe.net/publications/docs/ripe-639</a> - RIPE NCC Services to Legacy Internet Resource Holders ( aka the RIPE Legacy services policy ) <o:p></o:p><a href="https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders">https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders</a> ( Services provided based on the type of contractual agreement with the RIPE NCC ) <o:p></o:p> <o:p></o:p> <o:p></o:p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Taiwo Oyewande <taiwo.oyewande88@gmail.com> Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Cc: Anthony Ubah <ubah.tonyiyke@gmail.com> Subject: [address-policy-wg] Policy Reciprocity<o:p></o:p></div><div> <o:p></o:p></div><div>Hello, I am a co-author 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 RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [<o:p></o:p></div><div> <o:p></o:p></div><div>Resource Transfer Policy<o:p></o:p>Authors: Anthony Ubah & Taiwo Oyewande<o:p></o:p>Submission date: 21/09/2020<o:p></o:p>Version: 2.0<o:p></o:p>Amends: CPM 5.7<o:p></o:p> <o:p></o:p>1. Summary of the problem being addressed by this proposal<o:p></o:p>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.<o:p></o:p> <o:p></o:p>2. Summary of how this proposal addresses the problem<o:p></o:p>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.<o:p></o:p>Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices.<o:p></o:p>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:<o:p></o:p>In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned.<o:p></o:p>Regarding resource transfer to other regions, only the following is mentioned:<o:p></o:p>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.<o:p></o:p>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.<o:p></o:p>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.<o:p></o:p>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.<o:p></o:p> <o:p></o:p>3. Proposal<o:p></o:p>CPM 5.7 will be modified by this proposal as follows: <o:p></o:p> <o:p></o:p>5.7 IPv4 Resources resource transfer<o:p></o:p> 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 transfer 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 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 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 relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region<o:p></o:p></div><div>5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O<o:p></o:p></div></div> ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. </body></html>