[rpd] Resources transfer policy Proposal

[Fernando Frediani]

Hello Alain

Let me contribute to this from my perspective.

- It was not clear to me if this proposal should start only when AfriNIC 
enters Phase 2 or after that, when the IPv4 pool is fully exhausted. 
Perhaps that should be explicit in the text.
- If it's during Phase 2 organizations can still receive blocks and use 
them also for IPv6 Transition, just smaller blocks up to a /22 every a 
couple of months.
- After Phase 2 is finished there is still a /12 Revered for Future Use 
and in my view should be used exclusively for New Entrants or for IPv6 
Transition Mechanisms with proper justification. For that a new policy 
will have to be presented at the time with these specific terms. These 
type of policies already exist and seems to work well on other RIRs 
around the world and is fair with new members in order to give then the 
bare minimal they can work from the very beginning.
- With that in place there will not be organizations with "no 
resources". For a while it will still be possible for a new African 
organizations to receive some IPv4 space, even small and limited but 
they will be able to have some directly from the RIR at least.

- I think limiting that only Legacy resources and resources previously 
transferred from other regions will be transferable out of the AFRINIC 
service region won't meet the reciprocity necessary from other RIRs in 
order it can happen. As I mentioned in another message I welcome a 
Inter-RIR bidirectional Transfer, but only after AfriNIC enters in Phase 
2 which when we will have enough elements to evaluate the new scenario.
- It mentions "AFRINIC has expressly and in writing approved" - What 
does that mean exactly ? Paperwork and an actual firm or just an email ? 
I trust AfriNIC as any other RIR will always make prudent decisions with 
regards these topics, but we, as policymakers have to give them the key 
points they must observe in order to be able to approve these transfers.

- This is in my view one of the most important points to make it very 
clear: Under the "Conditions on the recipient" must justify the usage of 
the resource being received. I believe that is covered under 
"demonstrate a detailed plan for the use of the transferred resources".

Best regards
Fernando

On 30/08/2019 09:55, Anthony Ubah wrote:

> 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 

> <mailto: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 

> <mailto:rpd-request at afrinic.net>> wrote:

>

>     Send RPD mailing list submissions to

>     rpd at afrinic.net <mailto: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 <mailto:rpd-request at afrinic.net>

>

>     You can reach the person managing the list at

>     rpd-owner at afrinic.net <mailto: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 <mailto:aalain at trstech.net>>

>     To: rpd at afrinic.net <mailto:rpd at afrinic.net>

>     Subject: [rpd] Resources transfer policy Proposal

>     Message-ID: <74B25009-9B77-4793-9446-BB7E94CE6760 at trstech.net

>     <mailto: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

>     <mailto:gregoire at ehoumi.net>, independent

>           Mukhangou Noah  Maina, noah.maina at seacom.com

>     <mailto:noah.maina at seacom.com>, SEACOM

>           Komi Elitcha,  kelitcha at djesido.africa, Independent

>           Adeola A. P. Aina, alain.aina at wacren.net

>     <mailto: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 <mailto:RPD at afrinic.net>

>     https://lists.afrinic.net/mailman/listinfo/rpd

>

>

>     ------------------------------

>

>     End of RPD Digest, Vol 155, Issue 27

>     ************************************

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190830/e2a0724e/attachment-0001.html>