[arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)

[Owen DeLong]

On Oct 1, 2010, at 9:46 PM, Hannigan, Martin wrote:

> 
> 
> Not to beat a dead horse, but...
> 
> 
> On 9/30/10 9:44 AM, "Owen DeLong" <owen at delong.com> wrote:
> 
>>> 
>>> I don't believe that we're saying anything different with respect to
>>> inequities. Look at it from this perspective; if you have 1M /28
>>> reservations and you have 1 x /18 reservation, in order to fulfill all or
>>> most of the /28's you'll eat away at the /18.
>>> 
>> And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
>> to give something to the /18 guy. Correct. Not giving the entire available
>> space to the first guy in line just because he got there a couple of hours
>> ahead isn't my idea of unfair.
> 
> 
> Let's look at populated sample pool with the minimum set to /25:
> 
> 50% = /25
> 40% = /24
> 5% = /20
> 5% = /18
> 
> Let's reduce the pool by 50%
> 
> 50% lose nothing
> 40% lose 128 addrs
> 5% lose 2,048 addresses
> 5% lose 8,192 address
> 
> Let's show cost @ $1,000 per addr to amplify the damage
> 
> 128 replacement addresses = $128,000.00
> 2,048 replacement addresses = $2,048,000.00
> 8,192 replacement address = $8,192,000.00
> 
You forgot to populate your "populated" sample... Let's try the exercise
again with a sample population...

Another reality being ignored, of course, is that by placing the minimum
at /25 (which isn't in accordance with the proposed policy, btw), you've
got some number of organizations that lose 100% just because they're
small. If we assume a similar sliding scale of escalating usage to what
you have depicted, assuming a total population of, say, 3,000 organizations,
I get the following adjusted figures:

40% = 	Nothing -- Too small to qualify		1,200 orgs
30% =	/25					  900 orgs				
22% = 	/24					  660 orgs
4% =	/20					  120 orgs
4% =	/18					  120 orgs

This gives us a total demand of:

1200 * 16	   19,200 addresses
 900 * 128	  115,200 addresses
 660 * 256	  168,960 addresses
 120 * 4096	  491,520 addresses
 120 * 16384	1,996,080 addresses

Total		2,790,960 addresses

Let's assume we only 1,395,480 addresses available.
You're still talking about 1,200 organizations that get nothing
being short 19,200 addresses in toto.

Yes, the 900 organizations at the bottom get their full 115,200
addresses while the next 660 organizations get half of their
demand at 84,480 addresses. The next 120 organizations still
get 245,760 addresses, and, finally, the largest consuming
120 organizations still suck down 998,040 addresses. The
remaining 19,200 addresses might get spread amongst the
organizations, but, since they can't really CIDR align that,
more likely there's not a practical way to do so.

Given that the total supplied for all the other classes is
only 445,440, it's hard for me to argue that the 120
organizations facing the largest shortage while still
taking twice that many addresses themselves are somehow
getting a raw deal compared to the other 2,880
organizations, the vast majority of whom got either nothing
or a 128 address share of 115,200 addresses.

Reality is you have to determine some mechanism for deciding who
does or doesn't get the remaining addresses. Currently, other than a /10,
it's straight first-come-first serve and I'm fine with that. However, if we're
going to start creating special end-game reservation profiles, then, just
being the first one to file a reservation shouldn't allow you to override
the interests of everyone who tries for an advanced reservation behind
you.

Remember, the whole reservation system was something added to the
policy outside of my initial intent, largely advocated by you.

In the end, regardless of what makeup addresses on the market cost
if they are even available, there is still some combination of organizations
that comes out 10,368 addresses short.

All we're doing is talking about how to rearrange the address shortage
deck chairs.

Obviously, the smaller the minimum, the closer to fair this becomes,
but, I believe it is thoroughly impractical to issue smaller than a /28
to organizations even from the end space.

If we change the scenario slightly and go with the minimum being
a /28, two changes occur...

1.	The 900 organizations that would get 128 addresses now get
	64 addresses.
2.	The 1200 organizations that would have gotten nothing now
	each get a /28.

As a result, there is a larger chunk of left-over space in the alignment
problem that remains in the transition pool for additional applicants.

The primary point to consider here is that you really have to put
a lot of smaller organizations against the wall in order to provide
another bit to even a single very large organization. Even if we
took all 57,600 "remainder" addresses and tried to back-fill
the /18 organizations needs, we'd still only fully fill 4/120 before
we used up all the available space.

> 
>>>> I do think your estimate of $1,000 per /32 is speculative at best.
>>> 
>>> What do you think that this cost is currently?
>>> 
>> Since I don't have any legitimate address trading data to back it up, and,
>> since to the best of my knowledge, no-one has exercised 8.3 as yet,
>> neither do you, I would argue that any number would be speculative
>> at best.
> 
> I chose $1,000 as an amplifier since it certainly draws attention and I
> think that based on what I know about the market, it's feasible.
> 
Sure, $1,000 is better for FUD than $1. I get that.

However, no matter what price you pick, we're still short the same amount
of address space with similar consequences.

Now, whose bottom line is more directly impacted?A very large organization
that gets 8,192 of the 16,384 addresses it needed and has to spend
some amount of money to come up with 8,192 more addresses, or,
the small organization that only got 64 of the 128 addresses they needed
to and has to make up that shortfall?

I think the impact as a percentage of revenue is roughly the same.

Yes, the organizations that only needed 16 addresses get a "free ride",
but, remember, those organizations probably needed more than
16 addresses anyway, that's just what they qualified for here.
Even though this is the largest number of organizations, they still
represent a tiny fraction of the address space consumed in the
policy.

The policy spreads the pain fairly evenly. Not in absolute dollar
terms, but, in dollar/organization-size terms.

> The data at the below URL is almost three years old, but still relevant with
> respect to a normative number:
> 
> http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3.
> Pdf
> 
Except this only describes black-market pricing (which is notoriously higher
than legitimate market pricing because it seeks to avoid normal restrictions
for whatever purpose). There is no data available on legitimate market
transfers because none have occurred as yet.

>>> 
>>> Not sure what the relevance of the follow-up is. No one is advocating that
>>> anyone be able to land grab. Any policy that allows that is deficient. I'm
>>> advocating that we abandon this proposal again.
>>> 
>> But you're opposing this proposal specifically because it doesn't
>> allow for the land grab.
> 
> 
> Why don't you build your own financial analysis of this proposal instead of
> speculating on motive then? I haven't even factored in the cost of capital
> needed or the accounting method to expense the addresses which would raise
> the costs higher.

See above...

> Hope that makes it clearer as to why I am opposing. There simply has to be a

> better way.
> 
OK... Propose it.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101001/68032b7f/attachment.htm>