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

Owen DeLong owen at delong.com
Fri Jan 29 01:12:25 EST 2010

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

>> 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.
Depends on the cause of the food shortage.

> 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.
ARIN is the community's steward over the address space and it
is absolutely ARIN's role to balance the needs of the various
stakeholders in the community and develop policies that meet
the communities consensus of what best meets the community's
need with the application of sound judgment by those elected
by the community to that consensus.

The idea of fair depends a great deal on perspective in the
case in question. If you are the guy asking for a /14, then,
fair is to give you all the pieces necessary for you to have
address space equivalent to the /14. If your the guy who
put in the request for a /24 30 seconds after the guy who
asked for the /14, your idea of fair might be a bit different.

>>> 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.
ARIN can be somewhat clear about what is on ARIN's shelf, but,
from your statement above, it was unclear about whether or not
you expected ARIN to be clear about what was avilalble for
transfer, thus my question.

>> 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.
I agree, but, I also know that many web retailers I have worked
with are loathe to publish information about whether a product
is in stock before the customer has committed to the order because
race conditions such as these make for very unhappy customers.

>> 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.
Let's stick to talking about IP addresses.  To the best of my
knowledge, ARIN is not involved in the stewardship of
avian members of the porcine species or anything otherwise
related to the silk trade.

> 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.
Who are you to decide which is better for them? Why should ARIN
decide on their behalf?

> 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.
That's one strategy option. Not necessarily the only strategy.
Clearly it's the one you think is best, but, like LDAP, it is not
necessarily the best answer for everyone in every case.

>> 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.
Last I looked, we lived in a representative republic and not
a democracy. Even ARIN is run more like a representative
republic than a democracy. Democracy doesn't scale.

Nonetheless, I think that ARIN owes it to the community to
consider all the views on what is the most fair process for
distributing the last of the address space and any address
space reclaimed thereafter. This proposal clearly differs
from your view and your opposition is noted. However,
other views are equally legitimate.

>>> 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. 
Thought exercise: Under your proposed method, where does
one draw the line between DoS and legitimate efforts to have
your request hit the lottery? How many lottery tickets should
someone be allowed to request per what unit of time?

> 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.
My intent would be to say that you can get any one of the
above, not a combination... You can have the /24 on the
shelf and make due with that, you can have a chit for the
next /22 (or smaller) that is placed on the shelf, or, you can
use your chit as proof of justification for a transfer of up
to a /22.

> That could work. How could it be done with a simple policy that
> doesn't overmanage the situation?
I don't think policy has to be simple to be good. I think it is important
for policy to be as simple as possible, but, I also think that attempts
to make policy simpler than it needs to be cause greater problems.

I am not a big fan of ignoring problems just because they seem
too big or too complex. With thinking like that, we would not have
an aerospace industry, we would never have visited the moon,
and we will never make it to mars. Solving the difficult problems is
what makes engineering interesting. Policy development is a
combination of engineering and other disciplines in this case.
I look forward to continuing to work on these difficult problems.


More information about the ARIN-PPML mailing list