[arin-ppml] Re-thinking Section 8.5.6
Owen DeLong
owen at delong.com
Fri Jul 21 23:18:49 EDT 2023
> On Jul 21, 2023, at 18:02, David Farmer <farmer at umn.edu> wrote:
>
>
>
> On Fri, Jul 21, 2023 at 6:16 PM Delong.com <http://delong.com/> <owen at delong.com <mailto:owen at delong.com>> wrote:
>> On Jul 21, 2023, at 15:39, David Farmer via ARIN-PPML <arin-ppml at arin.net <mailto:arin-ppml at arin.net>> wrote:
>>
>> So, it sounds like we are talking about a policy aimed purely at ARIN members in the 4XL and 5XL fee categories.
> Not that I know of, but yes, that was the example cited in the request for discussion.
>> Furthermore, if an organization is large enough, the same statement could be made even with an 80% threshold.
>> So, let's do the math; if an organization has 5 /8s at 80% full, that is a /8 of free space.
> As a practical matter, think there are few (if any) organizations that have more than 2 /8s.
>> Also, a similar statement, relatively speaking, could be made about anyone in the XL or higher fee category having more than a /16 of free space.
>
> Sure, someone with 5 /24s at 80% utilization has a /24 worth of free space.
>
> These don’t seem like unreasonable ratios as a practical matter, however.
>
> Unfortunately, the inquiry said the following:
>> The crux of the issue is there are very large orgs that could have a /8 or more of unused space, yet still qualify for more based on the current policy ("must have efficiently utilized at least 50%"). Smaller orgs with more immediate needs are in competition for the space, and prices are driven up.
> By focusing the conversation on larger organizations, this seems to blame larger organizations for rising prices and says smaller organizations have more immediate needs. If we want smaller organizations with two /24s and only one used to be able to justify a transfer of a /24, we need to accept organizations with two /8s justifying the transfer of a /8. It's only fair. If we want to change everything to 80%, I'm okay with that, but how does that impact the situation as described in the inquiry?
Well, at 50%, an organization with 2 /8s could have an entire /8 available and still ask for more.
At 80%, they’d have to have 5 /8s to be able to ask for more with an entire /8 available.
You know, because math.
I was trying to bypass the poorly phrased problem statement and look for things that might make sense in terms of policy modification.
>> We could set a maximum transfer unit, change the percentage, or whatever. But unless someone has a way to detect futures contracts and make them illegal, it's not going to be that hard to work around any changes to the policy that we make.
>
> Sadly, this is true as well (though I think illegal is the wrong term here… PPML doesn’t make law, we make registry policy.). However, just because a policy isn’t 100% enforceable, doesn’t mean it shouldn’t exist. Virtually none of our policies are 100% enforceable. The vast majority of policy, like the vast majority of law depends mostly on voluntary compliance… Keeping honest people honest, so to speak.
>
> Yeah, illegal isn't right, but unless we can make it a policy violation of some kind to enter into futures contracts, I don't see how changes are going to be effective. Enforceable or not, nothing in the current policy limits or even discourages futures contracts.
This was largely because people objected to unenforceable policy, which if you will recall, I found to be a specious argument at the time and I still do.
Almost all policy is “unenforceable” to some extent under some circumstances. I would, personally, favor policy limiting or even prohibiting futures contracts for IP addresses.
>> We have the current policy because we wanted to make it easy for the small and medium guys to justify sizable blocks if they can justify them financially, as the market would add financial justification to the overall criteria.
>>
>> Yes, the same holds true for the big guys. Why shouldn't it? From a relative perspective, it's not any easier for the big guys. Their size and the absolute values involved just make it sound easier, but it's not.
>
> Because at each level, 16x as much space comes for 2x the price… The big guys are effectively getting a huge discount on dominating the market. True, that rule doesn’t apply to transfer pricing… In fact, the inverse used to be true (A /17 currently goes for about $43/address, but a provider that needs and qualifies for a /17 can still buy as many /24s as they want since we eliminated the single prefix provisions).
>
> You are mixing fees and the market price. Big or small, ARIN's fees are only a very small part of the equation.
I wasn’t mixing them, I was attempting to account for both.
>> Yes, the market is driving up the price for IPv4. That is what we expected. The answer is for people to start using IPv6. Not for us to try to manipulate the IPv4 marketplace by trying to pick winners and losers.
>
> I don’t think shifting the requirement for ALL organizations back up to 80% instead of 50% is picking winners or losers.
>
> Yes, but I don't think it will change the situation as it is described in the inquiry.
Math says it will in practical terms, though I agree that it is possible to concoct a theoretical organization that would not be impacted.
>> The rules are the rules, and let's have one set of rules: big, medium, or small.
>
> Absolutely agree with this. I’m not aware of any active proposal to do otherwise.
>
> What about? "should utilization criteria be tied to the size of the org, in other words tiered?"
> That is not what is implied by that, at least in my opinion.
Yeah, I didn’t find that question to have particular merit, so I didn’t dignify it with an answer. However, that’s not a active proposal, that’s a question. If someone wrote a policy proposal to do so, I’d almost certainly object to it.
> But I'm glad we agree the answer to that question is no.
Definitely.
>> It's not that I oppose making any changes, but I don't think any changes are going to be effective and fundamentally change the fact that IPv4 prices are going up and will continue to do so regardless of any policy changes we make. More importantly, I'm worried that making changes at this point will have unintended consequences.
>
> As far as I’m concerned the faster IPv4 prices go up, the better. People have had plenty of time and plenty of notice that IPv4 had limitations and IPv6 is readily available. My only regret in this situation is that there’s no way to transfer the true costs of maintaining IPv4 onto the laggards that are preventing the rest of us from moving on.
>
> As I said, I don't oppose changes, but specifically on the 80% threshold, I think that would have a larger impact on the smaller guys without an appreciable impact on the big guys, which is not the intended effect as I read the inquiry.
The simple reality is that the large guys have enough lawyers and enough ability to move stuff to RIPE or elsewhere to circumvent almost any policy limitations anyway, so I doubt that the situation can be made significantly better for the smaller guys unless they all tell the bigger guys they’re simply not going to keep doing IPv4 in places where the bigger guys kind of depend on that happening.
Owen
>
> Owen
>
>>
>> Thanks.
>>
>> On Thu, Jul 20, 2023 at 3:45 PM A N <anita.nikolich at gmail.com <mailto:anita.nikolich at gmail.com>> wrote:
>> On behalf of the ARIN AC Policy Experience Working Group, and in response to the Policy Implementation and Experience Report presented at ARIN 51, we're looking for input on a possible proposed revamp of NRPM Section 8.5.6 "Efficient Utilization of Previous Blocks".
>>
>> The crux of the issue is there are very large orgs that could have a /8 or more of unused space, yet still qualify for more based on the current policy ("must have efficiently utilized at least 50%"). Smaller orgs with more immediate needs are in competition for the space, and prices are driven up.
>>
>> The Working Group would like some input on this before drafting a proposal. Input or thoughts are welcome about:
>> - should the utilization be raised, and if so, to what threshold?
>> - should utilization criteria be tied to the size of the org, in other words tiered?
>> - any other thoughts.
>>
>> Thanks much!
>> Anita
>>
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>> 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 info at arin.net <mailto:info at arin.net> if you experience any issues.
>>
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE Phone: 612-626-0815
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952
>> ===============================================
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>> 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 info at arin.net <mailto:info at arin.net> if you experience any issues.
>
>
>
> --
> ===============================================
> David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20230721/e323baad/attachment.htm>
More information about the ARIN-PPML
mailing list