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

[michael.dillon at bt.com]

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

In the real world, talking about real crumbs, or at least food,
they give all the crumbs to a few strong members of the community
so that those members can apply their energy to getting more 
food to save others from starvation. Of course not all communities
are so clever, and some of them ration out the crumbs, praying
for a miracle and then they all die together.

I suggest that it is not ARIN's business to decide what better
serves the community, since ARIN is not lord and master of the
community, but its servant. ARIN should only try to be reasonably
fair, not make heroic efforts whose outcome could be worse, and
whose outcome is certainly unknowable.

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

So what? ARINs job is to manage its own shelf, not commandeer everyone
else's.

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

That's life. When the cupboard is bare, it is bare. Finito la commedia.
It would be wrong of ARIN to publish the available IP address blocks
as any kind of a guarantee, but it is right to publish availability
information as a snapshot of what WAS AVAILABLE at the time the report
was produced, which may be a few hours out of date. No need to publish
more than daily data.

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

What if pigs might learn to fly by growing silk ears. Requestors
might want to sit in the silk purse queue and wait for a flying
sow to appear over the horizon.

Far better for them to get down to the rag market and haggle over
the price of an old silk dress that could be reworked into a silk
purse.

In other words, if you look at the ARIN available blocks and it
seems that there is a significant risk that you will not get what
you need, then don't waste any more time with ARIN, and hunt 
out in the wild for potential transfer blocks.

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

By that stage IPv4 address allocation is already a crap shoot
regardless of what ARIN does. It's like aid distribution in 
disaster areas. The aid organizations try to do it in an orderly
way by giving tokens to mothers or every 10th person or whatever.
But once that person with the goods is out of view, who knows
what happens. In one case they were hoping to seed a market
by giving it to every 10th person, but they started a riot
instead. The lesson is that you cannot orchestrate human 
behavior to the nth degree, not in Haiti and not in the IPv4
address allocation arena. Back off and let nature take its
course, which in the case of ARIN is deployment of IPv6
everywhere. We need more humility instead of thinking that we
can engineer solutions to every problem. Many problems are
beyond engineering, otherwise we would already be living in
a technocracy, not a democracy.

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

DoS attackers deserve what they get. 

I gather you would rather see a system where people apply to 
ARIN once, demonstrate their need once, and get their choice
of whatever addresses are on the shelf, 
or a chit to be used when they find addresses in the market,
or a place in a waiting list for reclaimed addresses on the shelf,
or some combination of the three.

Let's see, little ISP needs a /22 and applies to ARIN. They are
approved but there is only one /24 on the shelf. Little ISP 
says, we'll take it, plus a chit for another /24, plus a place 
in the queue for two more /24s. If they are unhappy with the
results of their market search, ARIN lets them exchange the 
chit for another place in the queue, behind their original
queue postion for two /24s.

That could work. How could it be done with a simple policy that
doesn't overmanage the situation?

--Michael Dillon