Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] AFRINIC Number Resources Transfer Policy

Chevalier du Borg virtual.borg at
Sun Nov 10 16:50:52 UTC 2019

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> a écrit :



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


> This proposal states in 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 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 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



Borg le Chevalier
"Common sense is what tells us the world is flat"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list