[arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests

[Owen DeLong]

On Jan 28, 2010, at 12:30 AM, <michael.dillon at bt.com> wrote:

> 
>> What if the request is for a /14, and the biggest free blocks 
>> are all /24s?  Do you want to give out 1024 non-aggregatable 
>> /24s to meet their need for a /14? 
> 
> If the applicant has justified a /14's worth of space, and ARIN
> asks the applicant about 1024 /24s and the applicant says that
> they can indeed make use of them, then basically, yes.
> 
> When the shelves are bare, you either accept crumbs, or go to
> the new IPv6 supermarket.
> 
The question here isn't about whether or not the requestor should
accept crumbs, it's about whether the community is better served
by giving all the remaining crumbs to a small number of large
requestors, or, by giving some of the crumbs to a larger number
of (potentially smaller) requestors.

>> Or should they be offered 
>> a single /24 from the free pool, and given the option to get 
>> their /14 via transfer? 
> 
> Definitely not. The option to get a /14 via transfer is 
> something that needs to be raised before an applicant submits
> their application. ARIN needs to be clear about what blocks of
> what sizes, are on the shelf waiting.
> 
What's waiting on which shelf? ARIN will not have 100% visibility
into the transfer availability. The ARIN shelf, OTOH, may well
have rapidly varying contents such that a /14 was available when
the person inquired, but, no longer available by the time ARIN
received the application.

>> The latter is the outcome this 
>> policy would prefer, as it reduces fragmentation of the
>> IPv4 address space, and allows available blocks to be matched 
>> with a larger number of equivalent-sized requests, rather 
>> than having them all vacuumed up by a small number of large requests.
> 
> If that was the goal then a simple change to policy that
> states ARIN will only issue a single block which is the
> largest aggregate that fits within the applicant's approved
> size. That works today, and right up to the end.
> 
What if the requestor thinks ARIN is likely to reclaim a large
enough block and wants to wait for it? This policy allows the
requestor to choose to sit in the queue in case such a block
becomes available.

>> And what about when the last /24 is given out, but there are 
>> still requests coming in, and there is still small amounts of 
>> address space being reclaimed?  Do you think that all 
>> requests should be denied if the pool is empty, and the first 
>> request to come in after a block is reclaimed gets it?
> 
> Yes. ARIN is not an auction house or a second hand shop. The 
> transfer policy exists so that people can find those reclaimable
> blocks without bogging down ARIN with the details.
> 
But some address space gets returned to or reclaimed by ARIN
through various processes.  Should we really turn the address
distribution into a lottery based on timing your request to
match the arrival of resources? That seems far worse to me.

>> In that case, perhaps every requester 
>> could send in requests once a minute, all day every day, 
>> until a block becomes available.
> 
> Then ARIN can censure the requester and block their IP
> addresses from ARIN services. Meantime their competitors
> will be advertising to buy reclaimable blocks and win
> the day.
> 
Yeah, I think that the address application timing lottery that
you are proposing is extremely poor stewardship, regardless
of what set of rules you propose for preventing people from
making frequent enough entries to attempt to guarantee
a win.

Owen