[arin-ppml] Re-thinking Section 8.5.6

Fri Jul 21 21:02:56 EDT 2023

On Fri, Jul 21, 2023 at 6:16 PM Delong.com <owen at delong.com> wrote:

> On Jul 21, 2023, at 15:39, David Farmer via ARIN-PPML <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?

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.

> 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.

> 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.

> 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.

But I'm glad we agree the answer to that question is no.

> 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.

> Owen
>
>
> Thanks.
>
> On Thu, Jul 20, 2023 at 3:45 PM A N <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).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer 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).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>

-- 
===============================================
David Farmer               Email:farmer 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/17046ec0/attachment.htm>