> On Sep 21, 2021, at 11:48 , Fernando Frediani <[email protected]> wrote:
> 
> Owen, you seem lately to be endeavoring tireless to make IP leasing something 
> normal and acceptable to most scenarios and make some weird reading of the 
> rules (not just in this RIR) to justify this view (your own view that 
> fortunately doesn't seem to match most of others) that IP leasing and fine 
> and is allowed freely while that is not always the case. There have been 
> different occasions where you stated that some practices are "100%" which 
> seems to be more your own personal reading than what it really is. A recent 
> discussion between your and John showed that some of your twisted words don't 
> necessary correspond to how ARIN understands and interprets the current 
> policies.
> 
Making it normal and acceptable would imply that I am seeking change. My point 
is that it is, in fact, already normal and acceptable and has been for many 
years. Traditionally, it is usually (though for many years not always) 
associated with connectivity services. In fact, I can offer several examples 
you likely already know of and don’t consider problematic, not the least of 
which is the circumstance where company A gets connectivity and addresses from 
provider B. Upon leaving provider B to get connectivity from provider C, A 
works out a contract with B where it pays a nominal fee to continue using the 
addresses and announcing them (as a more specific) through provider C while not 
maintaining any connection to provider B.

Like it or not, there is no distinction that can reasonably be made between 
this and any other lease of an address and this is a perfect example of a 
perfectly normal lease without connectivity associated.

I’m not advocating for a change to make leasing acceptable, I’m advocating for 
recognition that it’s been common practice among even the so-called legitimate 
LIRs for many many years (even before exhaustion
of the free pools in most RIRs) and that pretending it isn’t so or pretending 
that it is prohibited by existing policy is silly.

Remember, I have specifically expressed neutrality on Mike’s proposal. I truly 
neither support nor oppose it. I see it as unnecessary and irrelevant. I think 
it would clarify the situation and cause policy to be a more accurate 
reflection of reality.

If you can come up with a non-harmful policy proposal that actually and truly 
prohibits leasing, I will probably be neutral about that as well. While one of 
my clients has a strong opinion on leasing, personally, I do not.

I do have a strong desire for policy to be realistic. This half-measure of 
prohibiting leasing in context A while allowing it in virtually all other 
contexts (current staff interpretation of current ARIN policy) strikes me as 
ludicrous and baseless. I’ve already presented ways in which leasing can be 
effectively achieved while satisfying the policy text.
> Also you have been repeating endlessly that LIRs lease IP addresses. I never 
> heard people using this analogy to try to justify the bad IP leasing 
> practices that is done by those who are currently holding large amount of 
> unused address. What LIRs charge when they allocate IP addresses to their 
> *directly connected customers* is very different from those IP leasing 
> practices from n organization that doesn't build any Internet infrastructure.
> 
How so? Last I looked, many providers are charging $15/month per IPv4 address 
leased to their connectivity customers.
Currently, many leasing providers are charging as little as $3/month and more 
commonly $5.

Are you arguing that their lower prices are the problem? Please explain to me 
what, exactly, it is that you find so objectionable here?

Addresses are selling for a one-time fee of $30-$50 per address right now. Why 
on earth would anyone lease one at that price rather than simply buy it 
outright?

For leasing to be a viable business model, it needs to make sense to the 
leasing customer.
> While your a entitled to your different and preferred or business views it is 
> important to make it clear that some of them are not "that 100%" 
> correspondent to reality.
> 
Which views have I expressed that you feel are not conformant to reality? 
Where, exactly, do the separate from reality and in what way?

Owen

> Fernando
> 
> Em 21/09/2021 15:14, Owen DeLong via ARIN-PPML escreveu:
>> 
>>> On Sep 21, 2021, at 10:31 , Jon Lewis <[email protected]> 
>>> <mailto:[email protected]> wrote:
>>> 
>>> On Tue, 21 Sep 2021, William Herrin wrote:
>>> 
>>>> On Tue, Sep 21, 2021 at 8:07 AM ARIN <[email protected]> 
>>>> <mailto:[email protected]> wrote:
>>>>> Current ARIN policy prevents the use of leased-out addresses as evidence 
>>>>> of utilization.
>>>> OPPOSE.
>>>> 
>>>> Independent use of LIR-assigned addresses in BGP should be
>>>> discouraged. It pollutes the BGP table by requiring disaggregation of
>>>> neighboring addresses which might otherwise be efficiently routable.
>>>> 
>>>> Also unclear why we should pretend that LIRs do a better job enforcing
>>>> ARIN policy on address registrants than ARIN itself does. A LIR
>>>> leasing arrangement delegates that responsibility from ARIN without,
>>>> to my view, any good cause.
>>> Also apposed [and very confused].  Is this some kind of mistake or did 
>>> ARIN-prop-302 [to which I am apposed], which suggested a small edit to NRPM 
>>> 2.4, removing the language that suggested some connection between LIR->end 
>>> user IP assignment and network services provided by the LIR, somehow morph 
>>> into changes to 8.x affecting the transfer of number resources?
>> Section 2 defines terms.
>> 
>> If you change the definition of a term that section 8 depends on, it likely 
>> has policy implications for the application of section 8.
>> 
>> This change to section 2 would have implications for (at least) sections 4, 
>> possibly 5, 6, and 8 as currently written.
>> 
>>> ARIN-prop-302 seems to be an attempt to legitimize the practice of leasing 
>>> IP space, which seems to me has been a grey area, at least not supported by 
>>> the current definition of LIR in 2.4.
>> That’s exactly what it is. An attempt to recognize that leasing occurs, is 
>> normal every day practice, and treat it accordingly.
>> 
>> If you are opposed to this, then I suggest that someone should probably 
>> draft language that tightens up ARIN’s current tolerance of leasing as a 
>> secondary use for address after they have been used
>> for some primary purpose that involves connectivity.
>> 
>> I’ll also point out that current policy does allow for one to:
>>      1.      Obtain an aggregate (e.g. X.Y.0.0/16)
>>      2.      Announce aggregate
>>      3.      Lease chunks of aggregate to customers over GRE tunnels.
>> 
>> 100% legitimate.
>> 
>>      4.      Allow customer to announce more specific chunk to other 
>> providers over actual circuits.
>>      5.      Prepend the heck out of the aggregate announcement just in case.
>> 
>> 100% legitimate under current policy.
>> 
>> 100% valid to justify the need for additional addresses once all addresses 
>> are used in this fashion.
>> 
>> When you decide your business is large enough, you are free to turn off the 
>> tunnels if you wish, the fig leaf is no longer required under current policy.
>> 
>> This proposal eliminates the need for the fig leaf in the first place.
>> 
>>> Does anyone else find it odd that "2. Definitions" defines end-user and 
>>> LIR, but not ISP?  2.4 does say that LIRs are generally ISPs.  When are 
>>> they not ISPs, and when they're not ISPs, what are they?
>> A variety of other things:
>>      Cloud service providers
>>      Datacenter providers
>>      Web Hosting providers
>>      VPS providers
>>      VPN Services
>> 
>> The term ISP is ambiguous and does not cover all cases where an organization 
>> needs to be able to issue addresses to customers and register those
>> reallocations and reassignments, so the term LIR came into existence.
>> 
>> LIR is a specific term meaning an organization that issues addresses to 
>> customers for use in their networks. Admittedly, in most cases, LIR is 
>> somewhat
>> synonymous with ISP in that the relationship between an LIR and its 
>> customers usually also involves the LIR providing connectivity to the 
>> customer in
>> some form or other. This is not always the case and current policy does not 
>> preclude the use of addresses without connectivity, but it does not allow
>> ARIN to count that utilization as “utilized” when considering a new 
>> application.
>> 
>> Again, I have no dog in this fight, personally. I don’t care whether 302 is 
>> adopted or not. It will not impact me in any way.
>> 
>> As such, I attempt to clarify the existing situation for people to make an 
>> informed judgment on the proposal as written.
>> 
>> I will say that either this policy, or one which actually prohibits leasing 
>> should move forward because the current policy situation is simply absurd,
>> as demonstrated above.
>> 
>> Owen
>> 
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected] 
>> <mailto:[email protected]>).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml 
>> <https://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact [email protected] <mailto:[email protected]> if you experience any 
>> issues.
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to