[rpd] Proposal Update received: AFRINIC Number Resources Transfer Policy

[Fernando Frediani]

The merged entity is free to use the resources if it's within the 
region. For M&A Inter-RIR happen much less often and is something that 
impacts only that entity. Why pass over that situation and costs to all 
others ?

If someone is under a M&A scenario between regions renumbering is just 
part of this type of business and should be accounted as part of that 
business. Although it has some costs it is perfectly possible and doable 
with some planning. I have done plenty in different situations and I 
have survived. Nobody is stopping the entity to use the resources, as 
long they remain within the region.

I think allowing IPv6 transfers is less of the interest of the community 
and more of the interest of just a few and the implication is to pass 
over this costs to all.

Furthermore I will quote some words said by another person in another 
discussion in another RIR which I fully agree: "I do not think it to be 
a good idea.  Right now, without a policy change I can look at that list 
and know that 100% of each Block of IPv6 addresses is managed by the RIR 
listed. That allows for clean filter lists in IPv6 for those that choose 
to filter out abuse routes from other RIR's.  Allowing transfers will 
eliminate that clean fixed line that currently exists.  Also, return and 
renumbering has always been part of the policy since the beginning of 
IPv6 and should be enforced."

Best regards
Fernando Frediani

On 22/10/2019 17:25, Sylvain Baya wrote:

> {Cc: Ernest}

>

> Hi all,

>

> ...please see below (inline).

>

> Le lundi 21 octobre 2019, Fernando Frediani <fhfrediani at gmail.com 

> <mailto:fhfrediani at gmail.com>> a écrit :

>

>     Hello Sylvain.

>

>     I consider that the main motivation to allow transfers for IPv4 is

>     the scarcity. In normal

>

>     conditions, including a M&A the company would have to receive

>     resources in the new

>

>     RIR and do renumbering.

>

>

> Dear Fernando,

> I understand your arguments, but we must not force an entity, 

> resulting from a Merger|Acquisition,

> to act the way you described. It seems to me like going a bit out of 

> the scope of the PD-WG. The

> Merger|Acquisition entity should be free to use at least the Internet 

> resources they have legally

> inherited. Or am i missing something ?

>

> ...or it's not really the goal: treat the Merger|Acquisition case into 

> this single Draft Policy

> Proposal (DPP) ?

>

> Any author to clarify ? :-/

>

> An other thing : after reading the Staff comment as IAr (Impact 

> Analysis report) for this DPP and

> considering an explanation given by Ernest, i understand that there is 

> problem to solve within

> the Merger|Acquisition particular case before considering them as 

> potential beneficiary of this

> DPP.

>

>      Some people say that renumbering has costs, but that is part of

>     the business and should

>

>     be accounted as part of the whole transaction.

>

>

> ...IMHO, the Merger|Acquisition entity should be free to use your good 

> advice Fernando ;-)

>

>     Allowing IPv6 transfers has the potential to mess up with the way

>     it was distributed and is

>

>     allocated among all RIRs

>

>

> ...including RIPE NCC, yes and in that particular RIR, IPv6 transfers 

> are allowed ; including for

> Inter-RIR Transfers. And not only for the good of Merger|Acquisition 

> entities (In|Out of region).

>

>     (remember there are no Legacy IPv6) and also would have costs

>

>     for RIRs to adapt they systems in order to allow that, a cost that

>     would be of all members

>

>

> Thanks for this interesting information, hopefully we could have a new 

> IAr or a at least a Staff

> response about this affirmation.

>

> ...so, Ernest, can you consider contacting RIPE NCC Staff to provide 

> us with a kick response ?

> Thanks for your understanding.

>

>     in order to accomplish the need of just a few.

>

>

> Fernando, if we want a business stability into this region, preferably 

> we should understand

> Merger|Acquisition advantages more than something which could only 

> harm the greatest part of

> resource members of this RIR. To be clearer, i see Merger|Acquisition 

> scenarios inside AFRINIC

> region. That is why, i'm insisting for the authors to include IPv6 in 

> their $resource pool|definition.

>

> Also, the *few* you have mentioned below are not known right now :'-(

> ...then, any AFRINIC given resource member could become part of a 

> Merger|Acquisition scenario

> at any time...

>

> ...let me go further, in my analysis i also see, in fact, a potential 

> legal risk in regard to the RSA

> which seems to clearly grant Merger|Acquisitions entities with a kind 

> of *business continuity right*

> or guarantee. If i have read it correctly, though :-/

> Thanks.

>

> Shalom,

> --sb.

>

>     Regards

>     Fernando

>

>     On 21/10/2019 14:24, Sylvain Baya wrote:

>>     Hi all,

>>

>>     Le lundi 21 octobre 2019, Fernando Frediani <fhfrediani at gmail.com

>>     <mailto:fhfrediani at gmail.com>> a écrit :

>>

>>         [...]

>>

>

>

> -- 

>

> -- 

>

>    Best Regards !

>   Sylvain BAYA

>  cmNOG's Co-Founder & Coordinator

>    (+237) 677005341

>  PO Box 13107 YAOUNDE / CAMEROON

> baya.sylvain [AT cmNOG DOT cm]

>  abscoco2001 [AT yahoo DOT fr]

> http://www.cmnog.cm

> https://cmnog.wordpress.com

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

>   ‪#‎LASAINTEBIBLE‬(‪#‎Romains15‬:33):"Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ 

> soit avec vous tous!‪#‎Amen‬!"

> ‪#‎MaPrière‬ est que tu naisses de nouveau.

> ‪#‎Chrétiennement‬

>              « Comme une biche soupire après des courants d’eau, Ainsi 

> mon âme soupire après toi, ô DIEU! » (Psaumes 42 :2)

>

>

>

> _______________________________________________

> 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/20191022/e1be7926/attachment-0001.html>