[rpd] AFRINIC Number Resources Transfer Policy

[JORDI PALET MARTINEZ]

Hi Chevalier,

 

I will suggest that you read them the other policy proposal, which I think is matching what you’re asking:

 

https://www.afrinic.net/policy/proposals/2019-ipv4-002-d2#proposal

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 10/11/19 19:55, "Chevalier du Borg" <virtual.borg at gmail.com> escribió:

 

 

 

Le dim. 10 nov. 2019 à 21:58, Jaco Kroon <jaco at uls.co.za> a écrit :

Hi Chevalier.

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

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

 

Agree 100%, 

Then you have no problems with wait till all RIRs are equal run out before we etablish full in and out transfer policy no?

 

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

 

 

All RIRs don't all have equal amount of free space. Big difference

 

 

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

 

While AfriNIC have free space, operators don't need it

When it run out, then we can allow transfer policy

 

 

Until that time, I oppose these "AfriNIC Broker Support Policy"

 

 

 

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 | A: Unit 201, Building 2B, Sunwood Park, Queen's Crescent Lynnwood, Pretoria
 
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> 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" 



_______________________________________________
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" 

_______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1303 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 1424 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1445 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 3907 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 10459 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/0fcf296f/attachment-0009.jpg>