[rpd] [pdwg] AFRINIC Number Resources Transfer Policy Version 1.0

[Wijdane Goubi]

Dear community,

The chairs are neither holding nor objecting to the publication of the
policy proposal.

In addition, necessity removes restriction, we have in our hands a specific
case which is the existing of a competing proposal that is still under
discussion which makes it a bit confusing and except for the fact of
wanting the best for the community, there is no single personal reason that
would let the co-chairs delay publishing the policy proposal.
As mentioned, it is going to be published as soon as possible, it is just a
matter of time and a matter of taking into consideration what benefits the
community.

I do believe that no time should be wasted either but removing the
confusion will not only benefit the community but it will also benefit the
authors themselves.

Furthermore, I believe that the work and efforts the co-chairs make should
be more appreciated and less underestimated.

Kind regards,
Wijdane

On Tue, 27 Oct 2020, 06:47 ABDULKARIM OLOYEDE, <oloyede.aa at unilorin.edu.ng>
wrote:


> Dear Noah,

> A Section of 3.4.1 of the CPM reads ... "The Working Group Chair(s) may

> request AFRINIC to provide an analysis (technical, financial, legal or

> other), of the impact of the draft policy proposal..."

> We are in the process of asking AFRINIC to provide us with

> an analysis/advice of how to handle this proposal since a competing

> proposal is already in the last call.

> The community is made up of volunteers whose time are very precious. We

> want to reduce community burnout as much as we can and avoid wasting any

> one's time. You would agree with me that if the proposal in the last call

> is ratified then discussing this other one would amount to a waste of time.

> We have earlier received an analysis/advice on this issue and we this

> morning received a more detailed analysis/advice on how to proceed with

> this proposal and we would like to discuss this with you (the authors) so

> that we are all on the same page going forward.  Please give us a time that

> is most suitable for you (the authors) and we arrange a zoom meeting.

> In the meantime, we shall continue to carry out the necessary

> background work on this proposal.

> Please accept our apologies for any delay in communicating this to you.

>  Thanks

> Co-Chair

> PDWG

>

>

>

>

> On Mon, Oct 26, 2020 at 1:25 PM Noah <noah at neo.co.tz> wrote:

>

>> Hi Co-chairs,

>>

>>

>> The PDP does not allow Co-chairs to approve draft proposals submitted to

>> the WG.

>>

>>

>> The draft proposal has been submitted and is under discussion as per

>> section 3.4 of the CPM and must be published by AFRINIC staff.

>>

>>

>> Can you please tell the WG what you want to discuss with the authors

>> during this call which we did try to discuss openly after you rejected our

>> motivated submission for version 3.0 with the reasons being that the

>> proposal had expired.

>>

>>

>> Cheers,

>> *./noah*

>> neo - network engineering and operations

>>

>>

>> On Mon, Oct 26, 2020 at 7:31 AM ABDULKARIM OLOYEDE <

>> oloyede.aa at unilorin.edu.ng> wrote:

>>

>>> Dear  Noah,

>>> It is not yet published because we are still looking into it and we are

>>> planning a meeting with the Authors sometime soon.

>>> Thanks and Regards

>>> Co-Chair

>>> PDWG

>>>

>>>

>>>

>>> On Sun, 25 Oct 2020, 19:20 Noah via pdwg, <pdwg at afrinic.net> wrote:

>>>

>>>> Attention PDWG Co-chairs,

>>>>

>>>> Any reason this proposal has not been posted online on the AFRINIC

>>>> website?

>>>>

>>>> *./noah*

>>>> neo - network engineering and operations

>>>>

>>>>

>>>> On Sat, Oct 17, 2020 at 4:03 PM Noah <noah at neo.co.tz> wrote:

>>>>

>>>>> Dear Working Group/Co-Chairs,

>>>>>

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

>>>>>

>>>>> Please find the proposals text below and also attached pdf format.

>>>>>

>>>>> Happiest Weekend,

>>>>> Noah on behalf of

>>>>> The Co-authors

>>>>>

>>>>>

>>>>> ================================================================

>>>>>

>>>>> Policy Name: *AFRINIC Number Resources Transfer Policy*

>>>>> ID: (Assigned by AFRINIC)

>>>>> Submission *Date: 17 Oct 2020*

>>>>> Version: 1.0

>>>>> Author(s): (a) Name, (b) Email address, (c) Affiliation, if applicable

>>>>>       Gregoire Olaotan Ehoumi, gregoire at ehoumi.net, independent

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

>>>>>       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.0 Summary of the problem being addressed by this proposal*

>>>>>

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

>>>>> from other members solely within the AFRINIC region, based on justified

>>>>> needs. Considering the limited IPv4 space initially made available to

>>>>> AFRINIC (AFRINIC manages only 7.23 /8s with a very low ratio of IPv4

>>>>> addresses per Internet user), there will therefore be a need to allow for

>>>>> unused IPv4 from other regions to move into the AFRINIC service region °V

>>>>> 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.0 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 the AFRINIC service region; and between the

>>>>> 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 resources in different categories and defines

>>>>> which transfer rules apply to each category.

>>>>> Only Legacy resources and resources transferred in from other regions

>>>>> will be transferable out of the AFRINIC service region.

>>>>> The policy also makes the following provisions:

>>>>> - Number resources are non-transferable 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

>>>>> this policy.

>>>>> - AFRINIC does not recognize transfers outside of approved transfer

>>>>> policies and requires organizations 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 organizations that need the resources, but

>>>>> cannot obtain them from the AFRINIC free pools.

>>>>> AFRINIC recognizes the following types of transfers:

>>>>> - merger, acquisition, takeover or consolidation,

>>>>> - between AFRINIC members,

>>>>> - between an AFRINIC member and an organization in another region,

>>>>> - between a Legacy resource holder and an AFRINIC member,

>>>>> - between a Legacy resource holder and an organization in another

>>>>> region.

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

>>>>> Currently, the other regions are APNIC, ARIN, LACNIC, RIPE NCC.

>>>>>

>>>>> *3.0 Proposal*

>>>>>

>>>>> Insert the following text into the CPM (numbering to be changed by

>>>>> staff as appropriate):

>>>>> 3.1 Definitions

>>>>> 3.1.1 "Resource" refers to IPv4 Address space or Autonomous System

>>>>> Numbers.

>>>>> "AFRINIC pool" means the 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

>>>>> resources distributed during the Exhaustion phases of the soft landing

>>>>> policy (section 5.4 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 transfers.

>>>>> 3.1.5 "Inter-RIR transfer" means the transfer of resources from a

>>>>> resource holder in the AFRINIC service region to an organization in another

>>>>> region 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 the resource to be

>>>>> transferred is "Reserved" then deny transfer. This restriction excludes

>>>>> mergers, acquisitions and takeover transfers.

>>>>>

>>>>> *3.4 Conditions on resources to be transferred*

>>>>> - The size of the IPv4 address prefix should be a minimum of /24.

>>>>> - The resource must qualify for the 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 the 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, the 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, the 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 counterparts RIR transfer policy.

>>>>>

>>>>> * 4. References*

>>>>>

>>>>> https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf

>>>>> https://www.potaroo.net/tools/ipv4/

>>>>> https://bgp.potaroo.net/iso3166/v4cc.html

>>>>> https://resources.potaroo.net/iso3166/ascc.html

>>>>> ftp://ftp.afrinic.net/stats/afrinic/transfers/

>>>>>

>>>>> ================================================================

>>>>>

>>>>> _______________________________________________

>>>> pdwg mailing list

>>>> pdwg at afrinic.net

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

>>>>

>>>

>>> Website <http://www.unilorin.edu.ng>, Weekly Bulletin

>>> <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal

>>> <http://uilugportal.unilorin.edu.ng/> PGPortal

>>> <https://uilpgportal.unilorin.edu.ng/>

>>>

>>>

> Website <http://www.unilorin.edu.ng>, Weekly Bulletin

> <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal

> <http://uilugportal.unilorin.edu.ng/> PGPortal

> <https://uilpgportal.unilorin.edu.ng/>

>

> _______________________________________________

> 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/20201029/d646119e/attachment-0001.html>