[arin-ppml] Inter-RIR transfer Policy compatibility with Afrinic_Resource Transfer Policy proposal

[David Farmer]

I think it is questions of process, how would we feel if AFRINIC commented
on one of our policies on their policy list? Further, a staff evaluation is
a formal process because generally, RIR staff don't comment about a policy
proposal except through such a formal evaluation. There are very good
reasons, staff evaluations go through a formal process, staff should only
plan a very limited roll in the formation of RIR policy.  Yes, in some
situations this is inconvenient, but there is a strong reason for this
inconvenience, and why there is a PDP.

Thanks

On Mon, Oct 12, 2020 at 12:12 PM Mueller, Milton L <milton at gatech.edu>
wrote:

> John
>
> Would it be so difficult to send the ARIN staff evaluation to the list?
>
>
>
> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *John
> Sweeting
> *Sent:* Saturday, October 10, 2020 3:47 PM
> *To:* Anthony Ubah <ubah.tonyiyke at gmail.com>; arin-ppml at arin.net
> *Cc:* Taiwo Oyewande <taiwo.oyewande88 at gmail.com>
> *Subject:* Re: [arin-ppml] Inter-RIR transfer Policy compatibility with
> Afrinic_Resource Transfer Policy proposal
>
>
>
> Hello Authors,
>
>
>
> ARIN has provided AFRINIC staff our evaluation of the policy below. Please
> reach out to AFRINIC staff for ARIN’s evaluation.
>
>
>
> Thank you,
>
>
>
> John Sweeting
>
> CCO, ARIN
>
>
>
> *From: *ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Anthony Ubah <
> ubah.tonyiyke at gmail.com>
> *Date: *Saturday, October 10, 2020 at 11:56 AM
> *To: *"arin-ppml at arin.net" <arin-ppml at arin.net>
> *Cc: *Taiwo Oyewande <taiwo.oyewande88 at gmail.com>
> *Subject: *[arin-ppml] Inter-RIR transfer Policy compatibility with
> Afrinic_Resource Transfer Policy proposal
>
>
>
> Hello ARIN,
>
> 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 to inquire about its reciprocity with ARIN.
>
> Feedback of your assessment and analysis of this proposal would be highly
> 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 transf*er
>
>
> 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
>
> *5.7.4.3 *Incoming transferred legacy resources will still be regarded as
> legacy resources.
>
> *Best Regards,*
>
> *UBAH ANTHONY*
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201012/ea254f72/attachment.htm>