[rpd] AFRINIC Number Resources Transfer Policy

[Jaco Kroon]

Hi Chevalier.

Please allow me to be blunt.  That's short sighted.

We cannot transfer IN from other regions unless we allow OUT.

All the other RIRs require reciprocal *compatible* policies, which means
bi-directional transfers.

Not allowing this means we can't get resources in either.


Kind Regards,
Jaco Kroon
C.E.O.

*T:* +27 (0)12 021 0000 | *F:* +27 86 648 8561 | *E:* jaco at iewc.co.za
*W:* iewc.co.za <https://www.iewc.co.za/> | *A:* Unit 201, Building 2B,
Sunwood Park, Queen's Crescent Lynnwood, Pretoria


  	

Facebook <https://www.facebook.com/Interexcel/> Twitter
<https://twitter.com/Interexcel/> Google+
<https://plus.google.com/+InterexcelCoZaPTA/posts> LinkedIn
<https://www.linkedin.com/company/interexcel-world-connection/>

IEWC <https://www.iewc.co.za/> ULS Group <http://www.uls.co.za/>

On 2019/11/10 18:50, Chevalier du Borg wrote:

>

> 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

> <mailto:owen at delong.com>> a écrit :

>

>

>

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

>>     <fhfrediani at gmail.com <mailto: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 <mailto:RPD at afrinic.net>

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

>

>

>

> -- 

> Borg le Chevalier

> ___________________________________

> "Common sense is what tells us the world is flat"

>

> _______________________________________________

> 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/20191110/7df801ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ico-facebook.jpg
Type: image/jpeg
Size: 1302 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/7df801ff/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ico-twitter.jpg
Type: image/jpeg
Size: 1423 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/7df801ff/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ico-linkedin.jpg
Type: image/jpeg
Size: 1444 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/7df801ff/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ie.jpg
Type: image/jpeg
Size: 3906 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/7df801ff/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulsgroup.jpg
Type: image/jpeg
Size: 10458 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/7df801ff/attachment-0009.jpg>