[rpd] Resources transfer policy Proposal

[Lee Howard]

On 9/3/19 8:21 PM, Fernando Frediani wrote:

> On 03/09/2019 19:29, ALAIN AINA via RPD wrote:

>> <clip>

>>

>> - Using  the /12  "reserved for future use”  solely for new comers 

>> and justified IPv6 transition

>>

>> Attempt to do so failed as archives on SL-bis and other related 

>> proposals can show.

>>

>> Recent SL-update policy approved at last PPM, put the /12 to the free 

>> pool to be used in phase2 and revoke the provision of board making 

>> decision on it.

>

> This can be perfectly done and there are already policies in place in 

> other RIR like LACNIC and ARIN in different way and in my view is a 

> great success the way it is applied. I just however don't think it's 

> something for now in AfricNic and there is no need to rush for it as 

> the region is not even in the Phase 2 yet and something like that is 

> only after Phase 2.


In my view, Phase 2 is only five months away, and I'd rather be prepared 
than surprised. Current policy says that last /12 goes into the regular 
pool, and we'll see how long it lasts.




> Newcomers are the most important to be privilege in my view in the 

> future for a question of fairness so make sure they are treated the 

> same way all others were in the past and give them a chance to exist 

> in the Internet without any artificial difficulties.

I mostly agree with you, but I think this can be handled as well by 
reserving addresses for IPv6 transition mechanisms.  A newcomer who is 
building an IPv4 network is saying they only want to grow for one year.

Lee


>

> Regards

> Fernando

>

>>

>> Hope this helps

>>

>> - Co-authors

>>

>>

>>

>>> On 31 Aug 2019, at 18:39, Taiwo Oyewande 

>>> <taiwo.oyewande88 at gmail.com> wrote:

>>>

>>>

>>> A resource transfer policy is required in AFRNIC, but what type of 

>>> transfer and when should these transfer be implemented are key 

>>> components to the success of such policy proposals as being discussed.

>>>

>>> An intra rir transfer policy is required in AFRINIC. The 

>>> requirements for a transfer in the intra- rir transfer section of 

>>> this policy proposals are somewhat stiff and can disrupt business 

>>> flow if implemented. Eg  a transfer of ip between an ISP and a 

>>> customer will have to wait for a written approval after AFRINIC 

>>> makes a “prudent decision”.

>>>

>>> Also, it is in my opinion that to achieve the said goal in this 

>>> proposals, a two-way inter-rir policy is required. Most RIRs with 

>>> transfer policy between regions are on the terms that the other 

>>> region has a two way transfer policy. E.g ARIN and RIPE-NCC.

>>>

>>> I recommend a two-way inter-rir policy that has safety caps as 

>>> recommended by some members of the community.

>>>

>>> Kind regards

>>>

>>>> On 30 Aug 2019, at 10:57, Sylvain BAYA <abscoco at gmail.com> wrote:

>>>>

>>>> Hi all,

>>>>

>>>> Hope you are well.

>>>>

>>>> Please see my comments below (inline)...

>>>>

>>>>> Le 8/29/2019 à 12:36 PM, ALAIN AINA via RPD a écrit :

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

>>>> Dear Alain,

>>>> ...i thank you and your co-authors for this interesting and

>>>> comprehensive work you have done.

>>>>

>>>> Really good draft !

>>>>

>>>>> =====================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.

>>>> ...unless failing under *CPM section 5.4.6.2* ?

>>>>

>>>>> 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.

>>>> ...real problem, but need a different draft policy proposal to address

>>>> it, unless you plan to have

>>>> the content of this draft policy proposal (if ratified at end) in a

>>>> specific new section for all Internet

>>>> Resource Transfers.

>>>>

>>>> For the latter i will suggest you to also consider IPv6 address space

>>>> into your Resources definition.

>>>>

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

>>>> Please explain me why not also IPv6 addresses ?

>>>>

>>>>> 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.

>>>> ...i have not seen this in section 3 below. Is it not mandatory ?

>>>>

>>>> Or is it just about what we are reading in RSA section 6. (d) (vi) ?

>>>>

>>>> Also, what do you mean by “prudent decisions” ? Could you clarify 

>>>> please.

>>>>

>>>>> 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.

>>>> ...almost the same comment as my preceeding :-/

>>>> Please can you elaborate on the expected impact of this ?

>>>>

>>>>> 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.

>>>> Noted !

>>>>

>>>>> 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.

>>>> ...have not seen in section 3. Why please ?

>>>>

>>>>> 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.

>>>> ...you might consider adding this condition :

>>>> • The resource must not fall under a situation on which it should be

>>>> returned to AFRINIC as

>>>> clearly stated by the RSA section 6. (d) (vii)

>>>>

>>>> Please tell me, might it be productive to also add the following

>>>> condition here ? or not ? Why ?

>>>> • MUST show past usage rate if applicable.

>>>>

>>>>> - 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.

>>>> ...question : how this draft policy proposal is dealing with a source

>>>> organisation which should normally return (see RSA section 6. (d) 

>>>> (vii))

>>>> such resources to AFRINIC ?

>>>>

>>>>> 3.6 Conditions on the recipient

>>>>>

>>>>> - Will be subject to current AFRINIC policies.

>>>>> - Must sign RSA.

>>>> Why not this alternative : MUST be an AFRINIC resource member in good

>>>> standing...

>>>>

>>>> Thanks.

>>>>

>>>>> - 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=======================

>>>> Shalom,

>>>> --sb.

>>>>

>>>>> [...]

>>>> -- 

>>>>

>>>> Regards,

>>>> Sylvain B.

>>>> <http://www.chretiennement.org>

>>>> __

>>>> Website : <https://www.cmnog.cm>

>>>> Wiki : <https://www.cmnog.cm/dokuwiki>

>>>> Surveys : <https://survey.cmnog.cm>--------²

>>>> Subscribe to Mailing List : 

>>>> <https://lists.cmnog.cm/mailman/listinfo/cmnog/>

>>>> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>

>>>>

>>>> <0x0387408365AC8594.asc>

>>>> _______________________________________________

>>>> RPD mailing list

>>>> RPD at afrinic.net

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

>>> _______________________________________________

>>> RPD mailing list

>>> RPD at afrinic.net

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

>>

>> _______________________________________________

>> RPD mailing list

>> RPD at afrinic.net

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

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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