<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 1, 2010, at 9:46 PM, Hannigan, Martin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>Not to beat a dead horse, but...<br><br><br>On 9/30/10 9:44 AM, "Owen DeLong" <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't believe that we're saying anything different with respect to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">inequities. Look at it from this perspective; if you have 1M /28<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">reservations and you have 1 x /18 reservation, in order to fulfill all or<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">most of the /28's you'll eat away at the /18.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order<br></blockquote><blockquote type="cite">to give something to the /18 guy. Correct. Not giving the entire available<br></blockquote><blockquote type="cite">space to the first guy in line just because he got there a couple of hours<br></blockquote><blockquote type="cite">ahead isn't my idea of unfair.<br></blockquote><br><br>Let's look at populated sample pool with the minimum set to /25:<br><br>50% = /25<br>40% = /24<br>5% = /20<br>5% = /18<br><br>Let's reduce the pool by 50%<br><br>50% lose nothing<br>40% lose 128 addrs<br>5% lose 2,048 addresses<br>5% lose 8,192 address<br><br>Let's show cost @ $1,000 per addr to amplify the damage<br><br>128 replacement addresses = $128,000.00<br>2,048 replacement addresses = $2,048,000.00<br>8,192 replacement address = $8,192,000.00<br><br></div></blockquote>You forgot to populate your "populated" sample... Let's try the exercise</div><div>again with a sample population...</div><div><br></div><div>Another reality being ignored, of course, is that by placing the minimum</div><div>at /25 (which isn't in accordance with the proposed policy, btw), you've</div><div>got some number of organizations that lose 100% just because they're</div><div>small. If we assume a similar sliding scale of escalating usage to what</div><div>you have depicted, assuming a total population of, say, 3,000 organizations,</div><div>I get the following adjusted figures:</div><div><font class="Apple-style-span" face="Monaco"><br></font></div><div><font class="Apple-style-span" face="Monaco">40% = </font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">Nothing -- Too small to qualify</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> <span class="Apple-tab-span" style="white-space:pre"> </span></font></span><font class="Apple-style-span" face="Monaco">1,200 orgs</font></div><div><font class="Apple-style-span" face="Monaco">30% =</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">/25</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> 900 orgs </font></span></div><div><font class="Apple-style-span" face="Monaco">22% = </font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">/24<span class="Apple-tab-span" style="white-space:pre"> </span> 660 orgs</font></div><div><font class="Apple-style-span" face="Monaco">4% =</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">/20<span class="Apple-tab-span" style="white-space:pre"> </span> 120 orgs</font></div><div><font class="Apple-style-span" face="Monaco">4% =</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">/18<span class="Apple-tab-span" style="white-space:pre"> </span> 120 orgs</font></div><div><br></div><div>This gives us a total demand of:</div><div><br></div><div><font class="Apple-style-span" face="Monaco">1200 * 16</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">19,200 addresses</font></div><div><font class="Apple-style-span" face="Monaco"> 900 * 128</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">115,200 addresses</font></div><div><font class="Apple-style-span" face="Monaco"> 660 * 256<span class="Apple-tab-span" style="white-space:pre"> </span> 168,960 addresses</font></div><div><font class="Apple-style-span" face="Monaco"> 120 * 4096<span class="Apple-tab-span" style="white-space:pre"> </span> 491,520 addresses</font></div><div><font class="Apple-style-span" face="Monaco"> 120 * 16384<span class="Apple-tab-span" style="white-space:pre"> </span>1,996,080 addresses</font></div><div><font class="Apple-style-span" face="Monaco"><br></font></div><div><font class="Apple-style-span" face="Monaco">Total<span class="Apple-tab-span" style="white-space:pre"> </span>2,790,960 addresses</font></div><div><font class="Apple-style-span" face="Monaco"><br></font></div><div>Let's assume we only 1,395,480 addresses available.</div><div>You're still talking about 1,200 organizations that get nothing</div><div>being short 19,200 addresses in toto.</div><div><br></div><div>Yes, the 900 organizations at the bottom get their full 115,200</div><div>addresses while the next 660 organizations get half of their</div><div>demand at 84,480 addresses. The next 120 organizations still</div><div>get 245,760 addresses, and, finally, the largest consuming</div><div>120 organizations still suck down 998,040 addresses. The</div><div>remaining 19,200 addresses might get spread amongst the</div><div>organizations, but, since they can't really CIDR align that,</div><div>more likely there's not a practical way to do so.</div><div><br></div><div>Given that the total supplied for all the other classes is</div><div>only 445,440, it's hard for me to argue that the 120</div><div>organizations facing the largest shortage while still</div><div>taking twice that many addresses themselves are somehow</div><div>getting a raw deal compared to the other 2,880</div><div>organizations, the vast majority of whom got either nothing</div><div>or a 128 address share of 115,200 addresses.</div><div><br></div><div>Reality is you have to determine some mechanism for deciding who</div><div>does or doesn't get the remaining addresses. Currently, other than a /10,</div><div>it's straight first-come-first serve and I'm fine with that. However, if we're</div><div>going to start creating special end-game reservation profiles, then, just</div><div>being the first one to file a reservation shouldn't allow you to override</div><div>the interests of everyone who tries for an advanced reservation behind</div><div>you.</div><div><br></div><div>Remember, the whole reservation system was something added to the</div><div>policy outside of my initial intent, largely advocated by you.</div><div><br></div><div>In the end, regardless of what makeup addresses on the market cost</div><div>if they are even available, there is still some combination of organizations</div><div>that comes out 10,368 addresses short.</div><div><br></div><div>All we're doing is talking about how to rearrange the address shortage</div><div>deck chairs.</div><div><br></div><div>Obviously, the smaller the minimum, the closer to fair this becomes,</div><div>but, I believe it is thoroughly impractical to issue smaller than a /28</div><div>to organizations even from the end space.</div><div><br></div><div>If we change the scenario slightly and go with the minimum being</div><div>a /28, two changes occur...</div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>The 900 organizations that would get 128 addresses now get</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>64 addresses.</div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>The 1200 organizations that would have gotten nothing now</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>each get a /28.</div><div><br></div><div>As a result, there is a larger chunk of left-over space in the alignment</div><div>problem that remains in the transition pool for additional applicants.</div><div><br></div><div>The primary point to consider here is that you really have to put</div><div>a lot of smaller organizations against the wall in order to provide</div><div>another bit to even a single very large organization. Even if we</div><div>took all 57,600 "remainder" addresses and tried to back-fill</div><div>the /18 organizations needs, we'd still only fully fill 4/120 before</div><div>we used up all the available space.</div><div><br></div><div><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I do think your estimate of $1,000 per /32 is speculative at best.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What do you think that this cost is currently?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Since I don't have any legitimate address trading data to back it up, and,<br></blockquote><blockquote type="cite">since to the best of my knowledge, no-one has exercised 8.3 as yet,<br></blockquote><blockquote type="cite">neither do you, I would argue that any number would be speculative<br></blockquote><blockquote type="cite">at best.<br></blockquote><br>I chose $1,000 as an amplifier since it certainly draws attention and I<br>think that based on what I know about the market, it's feasible.<br><br></div></blockquote>Sure, $1,000 is better for FUD than $1. I get that.</div><div><br></div><div>However, no matter what price you pick, we're still short the same amount</div><div>of address space with similar consequences.</div><div><br></div><div>Now, whose bottom line is more directly impacted?A very large organization</div><div>that gets 8,192 of the 16,384 addresses it needed and has to spend</div><div>some amount of money to come up with 8,192 more addresses, or,</div><div>the small organization that only got 64 of the 128 addresses they needed</div><div>to and has to make up that shortfall?</div><div><br></div><div>I think the impact as a percentage of revenue is roughly the same.</div><div><br></div><div>Yes, the organizations that only needed 16 addresses get a "free ride",</div><div>but, remember, those organizations probably needed more than</div><div>16 addresses anyway, that's just what they qualified for here.</div><div>Even though this is the largest number of organizations, they still</div><div>represent a tiny fraction of the address space consumed in the</div><div>policy.</div><div><br></div><div>The policy spreads the pain fairly evenly. Not in absolute dollar</div><div>terms, but, in dollar/organization-size terms.</div><div><br></div><div><blockquote type="cite"><div>The data at the below URL is almost three years old, but still relevant with<br>respect to a normative number:<br><br><a href="http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3">http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3</a>.<br>Pdf<br><br></div></blockquote>Except this only describes black-market pricing (which is notoriously higher</div><div>than legitimate market pricing because it seeks to avoid normal restrictions</div><div>for whatever purpose). There is no data available on legitimate market</div><div>transfers because none have occurred as yet.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><br></blockquote><blockquote type="cite">Not sure what the relevance of the follow-up is. No one is advocating that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">anyone be able to land grab. Any policy that allows that is deficient. I'm<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">advocating that we abandon this proposal again.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">But you're opposing this proposal specifically because it doesn't<br></blockquote><blockquote type="cite">allow for the land grab.<br></blockquote><br><br>Why don't you build your own financial analysis of this proposal instead of<br>speculating on motive then? I haven't even factored in the cost of capital<br>needed or the accounting method to expense the addresses which would raise<br>the costs higher.<br></div></blockquote><div><br></div>See above...</div><div><br><blockquote type="cite"><div>Hope that makes it clearer as to why I am opposing. There simply has to be a</div></blockquote></div><div><blockquote type="cite"><div>better way.<br><br></div></blockquote>OK... Propose it.</div><div><br></div><div>Owen</div><div><br></div></body></html>