Search RPD Archives
[rpd] Resources transfer policy Proposal
Anthony Ubah
ubah.tonyiyke at gmail.com
Fri Aug 30 12:55:46 UTC 2019
Hello Alain Aina and Co.,
In addition to my previous concerns, I find that with this new Resources
transfer policy proposal, Business, Eg. Internet Service providers and
other service providers (Example businesses offer as-a-Service products
like IaaS and PaaS, also FTTH/FTTP, etc.) would be restricted from
assigning IP addresses to customers without permission from AfriNIC.
Thus I suggest a full resource transfer policy is needed for effective
resource exchange.
Kind regards,
Anthony
On Fri, Aug 30, 2019 at 1:47 AM Anthony Ubah <ubah.tonyiyke at gmail.com>
wrote:
> Hello Alain Aina and Co.,
>
> There certainly is a need for a full resource transfer policy to attempt
> fixing some of the lapses in the current Intra-RIR transfer policy.
> Thus this is a very interesting proposal, a good one to say the least.
>
> I need a little clarity on some a little details;
>
>
> Section 2:
> Excerpt;
>
> *“The goal of this transfer policy is to help distribute resources from
> those who no longer need them to organizations that need the resources, but
> cannot obtain them from the AFRINIC free pools.”*
> Redistribution of resources in not remotely a responsibility of AfRINIC. I
> suggest you consider reviewing this statement. I feel the new policy will
> create an avenue for resources to be transferred organically in a
> transparent system.
>
>
> Section 3.6:
> The section describes the Conditions on the recipient of “resources”
> Excerpts;
>
>
>
>
>
>
>
>
>
>
>
> * “…..- Recipient that does not have prior resources must: ++ demonstrate
> a detailed plan for the use of the transferred resources(in the case of
> ASN, recipient must meet the criteria for assignment of ASN).- Recipient
> with prior resources must:++ demonstrate a detailed plan for the use of the
> transferred resources(in the case of ASN, recipient must meet the criteria
> for assignment of ASN).++ Show past usage rate.++ Provide evidence of
> compliance with AFRINIC policies with respect to past
> allocations/assignments.…..”*As widely quoted, AfRINIC IPv4 pool is
> expected to run out soon, unfortunately, I feel the above conditions
> creates a limiting factor and thus does not necessarily encourage massive
> resource inflow into the region as the region would hope for.
>
> My concerns include;
>
> 1. A new business with no existing regional resources might have
> difficulty or be forbidden from transferring resource into the region.
>
> 2. How can one satisfactorily demonstrate a detailed plan for the use
> of the transferred resources? Will business projections suffice?
>
> 3. Will past usage rate of a resource owner in another region suffice?
>
>
>
> Thanks for the good work put in, in this proposal.
>
> Kind Regards,
>
> Anthony
>
On Thu, Aug 29, 2019 at 1:00 PM <rpd-request at afrinic.net> wrote:
> Send RPD mailing list submissions to
> rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
> rpd-request at afrinic.net
>
> You can reach the person managing the list at
> rpd-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
> 1. Resources transfer policy Proposal (ALAIN AINA)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Aug 2019 11:36:28 +0000
> From: ALAIN AINA <aalain at trstech.net>
> To: rpd at afrinic.net
> Subject: [rpd] Resources transfer policy Proposal
> Message-ID: <74B25009-9B77-4793-9446-BB7E94CE6760 at trstech.net>
> Content-Type: text/plain; charset=utf-8
>
> Dear community
>
> A new policy proposal named "AFRINIC resources transfer policy" is
> submitted for discussions. This proposal obsoletes the current IPv4
> transfer within AFRINIC service region policy, defines rules for
> transfers of IPv4 and ASNs within the region and between AFRINIC service
> region and other regions.
>
> The policy allows a category of resources to be transferred out of the
> region, another category of resources to be transferred inside and denies
> the transfer of certain resources.
>
> We expect this to be a response to a harmonised policy which addresses
> some of the limitations of the intra-rir policy and proposes a solution for
> an inter-rir transfer which minimizes the foreseen risks of uncontrolled
> outflow of resources.
>
> The co-authors
>
>
> =====================begin=================
> Draft Policy Name: AFRINIC Number resources transfer policy
> ID: (Assigned by AFRINIC)
> Submission Date: 29 August 2019
> Version: 1.0
> Author(s): (a) Name, (b) Email address, (c) Affiliation, if applicable
> Gregoire Olaotan Ehoumi, gregoire at ehoumi.net, independent
> Mukhangou Noah Maina, noah.maina at seacom.com, SEACOM
> Komi Elitcha, kelitcha at djesido.africa, Independent
> Adeola A. P. Aina, alain.aina at wacren.net, WACREN
>
> Sections of Policy Manual affected
>
> Obsoletes: IPv4 Resources transfer within the AFRINIC Region (Section 5.7
> of the CPM)
>
> 1. Summary of the problem being addressed by this proposal
>
> AFRINIC IPv4 pool is expected to run out soon. Some entities may need IPv4
> space to support their IPv6 deployments, especially to support transition
> mechanisms, which AFRINIC may not meet. The current Intra-RIR policy in
> force at AFRINIC allows entities to receive unused IPv4 address from other
> members solely within the AFRINIC region, based on justified needs.
> Considering the limited IPv4 space initially made available to AFRINIC
> (AFRINIC managing only 7.23 /8 with a very low ratio of IPv4 addresses per
> Internet users), there will therefore be a need to allow for unused IPv4
> from other regions to move into AFRINIC service region ? this without
> necessarily depleting AFRINIC's slim amount of IPv4 addresses by
> transferring space out of the region.
>
> The current Intra-RIR transfer policy allows all types of IPv4
> allocations/assignments to be transferred, including IPv4 from special
> purpose blocks (reserved blocks for IXPs and DNS root ops, Last /8, etc.)
>
> The current intra-RIR transfer policy does not cover ASNs while there are
> cases where transfers of ASNs among AFRINIC members is desirable.
>
>
> 2. Summary of how this proposal addresses the problem
>
> This new policy defines a set of rules to allow transfer of IPv4 addresses
> and ASNs within AFRINIC service region and between AFRINIC service region
> and other regions by specifying what categories of resources are eligible
> for transfer, the location of parties (sources and recipients) and the
> conditions to be met.
> The policy segregates the resources in different categories and defines
> which transfer rules applied to each category.
>
> Only Legacy resources and resources previously transferred from other
> regions will be transferable out of the AFRINIC service region.
>
> It also states the following:
>
> Number resources are non-transferable and are not assignable to any other
> organisation unless AFRINIC has expressly and in writing approved a request
> for transfer. AFRINIC is tasked with making prudent decisions on whether to
> approve the transfer of number resources.
>
> IPv4 addresses and ASNs can be transferred only in accordance with the
> following policy. AFRINIC does not recognise transfers outside of this
> policy and its predecessor and requires organisations holding such
> resources to return them to the appropriate registries.
>
> The goal of this transfer policy is to help distribute resources from
> those who no longer need them to organisations that need the resources, but
> cannot obtain them from the AFRINIC free pools.
>
> AFRINIC recognizes the following types of transfers:
> - merger, acquisition or takeover,
> - between AFRINIC members,
> - between an AFRINIC member and a member of another RIR,
> - between a Legacy holder and an AFRINIC member,
> - between a Legacy holder and a member of another RIR.
>
> AFRINIC will process and record Inter-RIR resource transfers only when the
> counterpart RIR has an Inter-RIR transfer policy that permits the transfer
> of IPv4 address space and ASNs between its own region and AFRINIC.
>
>
> 3. Proposal
>
> 3.1 Definitions
>
> 3.1.1 ?Resource? refers to IPv4 Address space or Autonomous System Numbers.
> ?AFRINIC pool? means AFRINIC managed pool of IPv4 and ASNs, obtained from
> IANA (allocated and recovered) or through the ERX (Early registration
> transfers).
>
> 3.1.2 ?Special-Purpose pool? means the pool of resources currently
> reserved for Critical Internet Infrastructures (section 5.6.4 of CPM) and
> last /8 (section 5.4.1 of CPM).
>
> 3.1.3 ?Legacy resources? refer to resources allocated prior to the RIR
> system and tagged as Legacy by AFRINIC.
>
> 3.1.4 ?Others? means resources transferred from other regions through
> Inter-RIR transfer.
>
> 3.1.5 ?Inter-RIR transfer? means the transfer of resources from an AFRINIC
> member to a member of another RIR or vice-versa.
>
>
> 3.2 Marking of the resources
>
> AFRINIC pool == Regional
> Special-Purpose pool == Reserved
> Legacy == Legacy
> Others == Global
>
> 3.3 Rules and procedures for selecting resources eligible for transfers
>
> 3.3.1 If source and recipient are AFRINIC members, then allow ?Regional?,
> ?Global? or ?Legacy? for transfer and mark transferred ?Legacy? as ?Global?
>
> 3.3.2 If source is Legacy holder and recipient is AFRINIC member, then
> allow ?Legacy? for transfer and mark transferred resources as ?Global?
>
> 3.3.3 If source is Legacy holder and recipient is in another region, then
> allow ?Legacy? for transfer
>
> 3.3.4 If source is AFRINIC member and recipient is in another region, then
> allow ?Global? for transfer
>
> 3.3.5 If source is from another region and recipient is AFRINIC member,
> then allow ?Any?, and then mark the transferred resources as ?Global?
>
> 3.3.6 Irrespective of the source and recipient, if resource to be
> transferred is ?Reserved? then deny transfer.
>
> 3.4 Conditions on resources to be transferred
>
> - The size of the IPv4 address should be a minimum of /24.
> - The resource must qualify for type of transfer requested.
> - The resource will be covered by AFRINIC policies after transfer into the
> region.
>
> 3.5 Conditions on the source
>
> - Must be right holder of the resources to be transferred with no disputes.
> - If the source is from other regions, conditions on the source are
> defined in the counterpart RIRs transfer policy.
>
> 3.6 Conditions on the recipient
>
> - Will be subject to current AFRINIC policies.
> - Must sign RSA.
> - Recipient that does not have prior resources must:
> ++ demonstrate a detailed plan for the use of the transferred resources
> (in the case of ASN, recipient must meet the criteria for assignment of
> ASN).
> - Recipient with prior resources must:
> ++ demonstrate a detailed plan for the use of the transferred resources
> (in the case of ASN, recipient must meet the criteria for assignment of
> ASN).
> ++ Show past usage rate.
> ++ Provide evidence of compliance with AFRINIC policies with respect to
> past allocations/assignments.
> - If the recipient is in another region, the conditions on the recipient
> are defined in the counterpart?s RIR transfer policy.
>
> 4. Revision History
>
> v1 submitted on 29/08/2019 for discussions
>
> 5. References
>
> https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf
> https://www.potaroo.net/tools/ipv4/
> http://bgp.potaroo.net/iso3166/v4cc.html
> http://resources.potaroo.net/iso3166/ascc.html
> ftp://ftp.afrinic.net/stats/afrinic/transfers/
>
> ===================end=======================
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 155, Issue 27
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190830/3933e2a8/attachment-0001.html>
More information about the RPD
mailing list