[rpd] AFRINIC Number Resources Transfer Policy

Sun Nov 10 17:58:22 UTC 2019

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.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.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-0001.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-0002.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-0003.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-0004.jpg>