[rpd] AFRINIC Number Resources Transfer Policy

[Chevalier du Borg]

I opposed this and any out of continent transfer policy at this time. I can
revise my choice when ALL RIRs have finish their free pool. Otherwise, this
policy can as well be call

"The AfriNIC Broker Support Policy"



Le mer. 6 nov. 2019 à 23:42, Owen DeLong <owen at delong.com> a écrit :


>

>

> On Nov 6, 2019, at 07:00 , Fernando Frediani <fhfrediani at gmail.com> wrote:

>

> This proposal states in 5.7.3.2 that "the source entities are eligible to

> receive further IPv4 allocations or assigments from AFRINIC". What is the

> logic on that ?

> If a organization is transferring its resources it means it doesn't need

> them anymore and therefore it doesn't make sense they can receive any

> further space from AFRINIC.

>

> Transferring out should not result in a permanent ban on acquiring more

> resources, but there should definitely be some hold-down time to prevent

> address cycling and speculation.

>



Why not?
Unless they can prove they retrieve the last block of address they
'transfer' (aka SELL), why should they get more from the community pool?
And again. I oppose this "The AfriNIC Broker Support Policy"





>

> Suggest that sources of resources for transfer be prohibited from

> acquiring additional resources for at least 24 months.

>

> It also proposes in 5.7.4.1 that "the transfer does not require approval

> from AFRINIC". Of course there must be a mutual agreement on both sides for

> a transfer to happen but the RIR must check everything and 'approve' that

> everything is correct and can happen. Furthermore the justification for

> coming 10 years it way to long and I've never seen it in any other place

> which for me doesn't make sense otherwise would clearly allow stockpiling

> which is one of the key things to be avoided in IP assignment since the

> very beginning.

>

> Agreed… Recipients of transfers should be subject to the same reviews as

> recipients of space from the free pool, IMHO. Further, local sources of

> resources for transfer should be validated by the RIR as the legitimate and

> uncontested registrant.

>

> For inter-RIR transfers, I would suggest the following:

> Source Entity should be verified by Source RIR according to that RIR’s

> policies and practices.

> Recipient Entity should be verified by Destination RIR according to that

> RIR’s policies and practices.

>

> This is the general approach taken in the existing inter-RIR transfer

> policies and will yield greatest compatibility with existing inter-RIR

> policies.

>

> The proposal also removes something fundamental to fix a historical

> mistake, with the removal o 5.7.4.3 which converts legacy transferred

> resources to non-legacy.

>

> Agreed…

>

> There should, in my opinion, be no such thing as legacy resources, only

> legacy registrations. An existing registration which existed before the RIR

> and has not been brought into contract with an existing RIR is a legacy

> registration. Any transfer or other transaction which involves a change in

> ownership of that registration should require that the recipient enter a

> contract with the RIR and that the new registration be non-legacy.

>

> If the authors can adopt these recommendations, I could support the

> proposal. Without them, I must oppose the proposal as written.

>

> Owen

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>



-- 
Borg le Chevalier
___________________________________
"Common sense is what tells us the world is flat"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/25a0e44e/attachment-0001.html>