[rpd] Resources transfer policy Proposal

[Anthony Ubah]

Hello,

I agree with Taiwo Oyewande. Like I once commented, I feel AfriNIC's role
is being overstretched.
Quoting from the proposed policy (Below), I think it introduces more snags
to a process that should be otherwise smooth and seamless.
AfriNIC does not have the resource to micromanage transfers and this will
certainly leave the region with a frustrating process to cope with.

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

Basically I maintain that 2-way transfer of resources is critical, and it
is imperative for Afrinic to be looped-in for the sole purpose of good
Booking.

*Best Regards,*

*ANTHONY *

E-mail: anthony.ubah at goldspine.com <anthony.ubah at gloworld.com>.ng


On Thu, Sep 5, 2019 at 9:04 AM <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. Re: Resources transfer policy Proposal (Fernando Frediani)

>    2. Re: Resources transfer policy Proposal (Taiwo Oyewande)

>

>

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

>

> Message: 1

> Date: Wed, 4 Sep 2019 13:11:08 -0300

> From: Fernando Frediani <fhfrediani at gmail.com>

> To: rpd at afrinic.net

> Subject: Re: [rpd] Resources transfer policy Proposal

> Message-ID: <bf55c33f-7c88-88dd-a4e4-51c5b10764b6 at gmail.com>

> Content-Type: text/plain; charset=utf-8; format=flowed

>

> Hi Lee

>

> On 04/09/2019 12:00, Lee Howard wrote:

> >

> > <clip>

> >

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

>

> The way I see is the a newcomer wouldn't want (or be able) to build a

> IPv4 network when he is receiving only a /22, but to use most of these

> 1024 addresses for transition mechanisms as he wouldn't have a escape

> anyway. The difference from a dedicated policy for IPv6 transition

> mechanisms is that it gives a little more flexibility to that

> organization to grow and stabilize itself. Then if beyond that they

> still need more address they can go to market.

> A dedicated IPv6 transition policy is more toward those who already have

> some allocation from the RIR and it works in even smaller portions of

> addresses as it is in ARIN for example.

>

> Fernando

>

> >

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

> >

> > _______________________________________________

> > RPD mailing list

> > RPD at afrinic.net

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

>

>

>

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

>

> Message: 2

> Date: Thu, 5 Sep 2019 09:03:45 +0100

> From: Taiwo Oyewande <taiwo.oyewande88 at gmail.com>

> To: Fernando Frediani <fhfrediani at gmail.com>

> Cc: rpd at afrinic.net

> Subject: Re: [rpd] Resources transfer policy Proposal

> Message-ID: <827067E2-C1C6-4E7D-855E-0E98277912B5 at gmail.com>

> Content-Type: text/plain;       charset=utf-8

>

>

> Dear all,

>

> I appreciate the well coordinated reply by the co-authors.

>

> Based on my previous comment, I am still of the opinion that transfer of

> resources within the region should be less stiff. Afrinic is an Internet

> registry for Africa centred at distributing Internet number resources and

> having an updated ledger of its distributed resources. With this, Number

> resources should be able to move freely within the region as long as a

> valid need is shown and a written notification is sent to AFRINIC to update

> her books for proper and up to date record keeping. The decision making

> process in this proposal is time consuming and can affect business

> operation.

>

> Kind regards

> Taiwo

>

> > On 4 Sep 2019, at 17:11, Fernando Frediani <fhfrediani at gmail.com> wrote:

> >

> > Hi Lee

> >

> >> On 04/09/2019 12:00, Lee Howard wrote:

> >>

> >> <clip>

> >>

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

> >

> > The way I see is the a newcomer wouldn't want (or be able) to build a

> IPv4 network when he is receiving only a /22, but to use most of these 1024

> addresses for transition mechanisms as he wouldn't have a escape anyway.

> The difference from a dedicated policy for IPv6 transition mechanisms is

> that it gives a little more flexibility to that organization to grow and

> stabilize itself. Then if beyond that they still need more address they can

> go to market.

> > A dedicated IPv6 transition policy is more toward those who already have

> some allocation from the RIR and it works in even smaller portions of

> addresses as it is in ARIN for example.

> >

> > Fernando

> >

> >>

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

> >>

> >> _______________________________________________

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

>

>

>

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

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>

>

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

>

> End of RPD Digest, Vol 156, Issue 6

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

>

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