[rpd] AFRINIC Number Resources Transfer Policy

[Chevalier du Borg]

Le dim. 10 nov. 2019 à 21:46, Daniel Yakmut <yakmutd at googlemail.com> a
écrit :


> In the whole of these mix, can't we have the transfer of the resource to

> be temporal.

>

>  For example I have a pool of ipv4 resources that I am not utilising at

> the moment, I should be able to lease it out for a period say 24months or

> more. And if I have a need for the resource later, I should be able to

> retrieve it back without going to  the RIR for another allocation.

>



Because the resources were give to you base on NEED. If you no longer need
it, return it to AfriNIC and when you need it, go back for me.




>

> Furthemore after the retrieval and.i am still short of my current needs i

> can approach the RIR for new allocation I believe.

>

> The point is, my earlier leased resource can be used anywhere in the

> world, then how does all the current Inter RIR policies under discussion

> takes care of this situation.

>

> Simply

> Daniel

>

>

> On Sun, Nov 10, 2019, 5:54 PM Chevalier du Borg <virtual.borg at gmail.com>

> 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

>>

>

> On Nov 10, 2019 5:54 PM, "Chevalier du Borg" <virtual.borg at gmail.com>

> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191110/15f8579d/attachment.html>