IP range for lease

Mon Jul 10 16:18:55 UTC 2023

>
> To summarise, if there is no longer a need, please
> do either one of the following three things:
>
> 1| send it back to the RIR;
> 2| change the word *lease* to *transfer* and
> announce your willing to transfer the INRs you hold.
> 3| do not hesitate to discuss your alternatives with
> the RIR's Staff. They are paid to support you!
>

While those are probably the most altruistic things that could be done,
almost nobody does those any more.

Too much grey area with respect to property rights (or lack thereof) as
they relate to INRs. Until there is more concrete case law on the matter,
which isn't likely to happen in most of our careers, monetizing it will be
the rule.

On Mon, Jul 10, 2023 at 10:00 AM Sylvain Baya <abscoco at gmail.com> wrote:

> Dear NANOG-ers,
> Hope this email finds you in good health!
>
> Please see my comments below, inline...
>
> Le jeudi 6 juillet 2023, Owen DeLong via NANOG <nanog at nanog.org> a écrit :
>
>> 
>> 
>> 
>> 
>> Karin,
>>
>> Opinions regarding leasing vary throughout the industry. In my opinion,
>> since the shift to provider assigned addresses during the CIDR efforts in
>> the mid 1990s, the majority of addresses have been leased in one form or
>> another.
>>
>>
>
> Hi Owen,
> Thanks for your email, brother.
> ...do you mean that such activity was supported by
>  a policy? or it was just a disruption of a principle
> which is fundamental; in order to guarantee that
> the common INRs (Internet Number Resources)
> are fairly distributed and not easily stockpilled?
>
>
>> The only thing novel here is the leasing of addresses independent of
>> connectivity services.
>>
>>
> So! it's a leasing of something not owned? and it
> became worse with the idea of Monkey(ing it)-In-
> The-middle (MITM)...
>
> What's the difference, please?
>
> Are you trying to change a definition, in order to
> convince this community that this sad practice
> was started at the very beginning of the INRs  distribution?
>
> What's your understanding of "need-based"?
> Why are they stocking INRs without any need to
> properly use it?
>
> ...imho! the waiting list would be less longer with
> those INRs withing the free pools.
>
>
>>
>> However, once the RIRs and their communities normalized the sale of
>> addresses through directed transfer policies, I think this was an
>>
>>
> Any RIR's policy you can share, to support your say?
>
>
>
>>
>> inevitable next step in the devolution of IPv4 into a monetized asset.
>>
>>
> What's the relation between leasing INRs and
> transfering it?
>
> Brother, you know that:
> * an INR transfer is a one time change in holdership
> * where leasing INRs is a proof that there is no
> longer any need of the community's resource held.
>
> ...imho! the communities chose a good approach
> in support to those who maintain Internet services
>  and build the Internet infrastructure. It should be
> seen as an exceptional rule, not the usual...because
>  it's an alternative when need ends.
>
> ...the other alternative, consistent with the principle,
>  is not the leasing of INRs; but the returning.
>
>
>
>>
>> It doesn’t help that the earliest and most prolific adopters of this form
>> of leasing have been snowshoe spammers.
>>
>>
> It helps to better understand how bad is the thing :'(
>
> ...please, do consider the following scenario:
>
> |1. you have a fundamental principle for INRs distribution within the
> regional RIR
> |2. for each resource holder, the RIR is responsible
> to enforce the Policy Manual
> |3. a resource holder receives some INRs from a
> regional RIR
> |4. that resource holder stops to comply to the
> principle in "1"
> |5. the INRs delegated to that resource holder are
> not used according to the community-based Policy
>  Manual
> |6. in order to justify its use, that resource holder
> assign part of the delegated INRs to its clients
> |7. the clients are asked to comply the the Policy
> Manual; including the fundamental principle in "1"
> |8. .
>
> How shall it end?
>
>
>
>>
>> However, there are leasing agencies that insist on getting proper
>> justification from their customers and have strong anti-abuse policies.
>>
>>
> Great! btw! what's their need? who need a MITM
> in the process, when it's possible to simply transfer
> the resource or simply send it back to the free pool?
>
>
>>
>> I would strongly encourage you to seek out such an organization to
>> partner with if you choose to lease your addresses as there are a number of
>> pitfalls you can encounter otherwise.
>>
>>
> ...risks are either ways! would you recommend
> to someone to put its private keys within one
> else personal's computer?
>
> Hi Karim,
> To summarise, if there is no longer a need, please
> do either one of the following three things:
>
> 1| send it back to the RIR;
> 2| change the word *lease* to *transfer* and
> announce your willing to transfer the INRs you hold.
> 3| do not hesitate to discuss your alternatives with
> the RIR's Staff. They are paid to support you!
>
> Thanks.
>
> Shalom,
> --sb.
>
>
>
>>
>> Owen
>>
>>
>> On Jul 3, 2023, at 08:25, Noah <noah at neo.co.tz> wrote:
>>
>> 
>> Hi KARIM,
>>
>> Considering the fact that IPs are requested on need-basis by resource
>> holders to number your own networks/systems and that of your clients?
>>
>> Any reason why MEKTEL would want to offer IPs for lease?
>>
>> Cheers,
>> *.**/noah*
>>
>>
>>
>> On Mon, Jul 3, 2023 at 6:16 PM KARIM MEKKAOUI <amekkaoui at mektel.ca>
>> wrote:
>>
>>> [...]
>>>
>>
>
> --
>
> Best Regards !
> __
> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/
> >
> __
> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec
> vous tous! ‪#‎Amen‬!»
> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
> après TOI, ô DIEU!»(#Psaumes42:2)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230710/a004251d/attachment.html>