[arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised

[Owen DeLong]

>> To be clear, the current policy is also 80%. The difference is that current policy requires 80% of your last block and "efficient utilization" of all other blocks (which is vaguely or not at all defined).
>> 
>> The proposed policy is to change that to 80% of all blocks in aggregate.
> 
> Totally understood of course.. I believe this will make it easier to abuse the system.  IMHO

If so, only by a very marginal amount. Especially when you consider the 3-month limit now in place.

>> I think it will have exactly the opposite effect, actually. I think it lowers the barrier for smaller entities and new entrants while keeping roughly the same effective requirements for larger incumbents.
> 
> Maybe if you can show how the barriers are reduced for smaller entities and new entrants, vs how they will be affected if the larger entities are enabled to get the remaining space faster?

Asked and answered earlier in the thread, but I will give it a shot...

If you have a collection of smaller blocks, it is much harder to get to 80% utilization in each one while still preserving contiguous free space to accommodate a larger-than-normal customer or a surge in customers. For example, if you have 3 /22s and have utilized all but a /26, three discontiguous /27s, and a two discontiguous /28s and a couple of /29s of the last one and all but a /29 of each of the other two and you have a customer come in who needs a /24, you're stuck. You need to find some other customer with a smaller need or some valid utilization for a small block or two in order to reach your 80% utilization on that last block.

OTOH, if you look at your overall situation, you're well past 80% overall.

This is not an uncommon scenario (in various forms) for small providers. The rules as they exist were written with minimum allocations of /20 and larger in mind at the time and smaller organizations mostly did not receive space directly from ARIN.

This has evolved over time and this part of policy has failed to keep up.

>>> I think we need another idea to come up..
>> 
>> Such as?
> 
> Hopefully the question will be answered, and the quicker we move on, maybe the quicker that will be answered.

We can agree to disagree. I think if we have a solution available that improves the situation for a number of community members while only offering a small potential for increased abuse (there are actually much easier ways to abuse the system if one desires to do so and they would yield much more address space), that we should do what we can until a better solution comes along.

>> Not to put too fine a point on it, but there are a number of smaller organizations that are really suffering from the current situation and this proposal would be a huge help to them. If you've got an alternative solution, then by all means, let's hear it. Otherwise, I think moving this one forward does more good than harm.
> 
> Okay, please show how this is the case?

See above. It's a rather contrived example, but the real world is much messier and much harder to explain in detail. Also, I don't happen to be working for such a provider at the moment, so I don't have a factual detailed account to present, but I assure you I have seen many of these first hand over the years.

Owen