[rpd] AFRINIC Number Resources Transfer Policy

[Chevalier du Borg]

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 <https://www.iewc.co.za/> | *A:* Unit 201, Building 2B,

> Sunwood Park, Queen's Crescent Lynnwood, Pretoria

>

>

>

> [image: Facebook] <https://www.facebook.com/Interexcel/> [image: Twitter]

> <https://twitter.com/Interexcel/> [image: Google+]

> <https://plus.google.com/+InterexcelCoZaPTA/posts> [image: LinkedIn]

> <https://www.linkedin.com/company/interexcel-world-connection/>

>

> [image: IEWC] <https://www.iewc.co.za/> [image: 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> 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 listRPD at afrinic.nethttps://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/296f69c0/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/296f69c0/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/296f69c0/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/296f69c0/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/296f69c0/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/296f69c0/attachment-0009.jpg>