<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 29, 2010, at 3:50 PM, Hannigan, Martin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br><br>On 9/29/10 10:32 AM, "Chris Grundemann" <<a href="mailto:cgrundemann@gmail.com">cgrundemann@gmail.com</a>> wrote:<br><br><blockquote type="cite">I think the fact that ARIN Staff is concerned that this policy may<br></blockquote><blockquote type="cite">favor organizations who are granted reservations too much and Marty<br></blockquote><blockquote type="cite">believes that it does not go far enough to provide relief to those<br></blockquote><blockquote type="cite">same organizations illustrates that we have actually found a pretty<br></blockquote><blockquote type="cite">decent compromise.<br></blockquote><br>I don't think we are too far apart with respect to the concepts, it's the<br>mechanics and implementation that I have an issue with. In it's current form<br>I doubt that it is even implementable. Regardless, the reservation<br>mechanisms are hugely unfair to large and small networks alike.<br><br></div></blockquote>The alternative was to make it hugely unfair to small or large networks</div><div>in favor of the other. I would think that most people would call that</div><div>balance.</div><div><br><blockquote type="cite"><div>By reducing the allocation sizes only the larger reserved allocations are<br>significantly impacted. That impact is both planning and expense. The way<br>that the proposal reads to me is that if you make a reservation under a<br>class, you are assigned at min and could be max. If you are assigned the min<br>and the allocations are reduced based on inventory, you're good to go. If<br>you're reduced at the max, you're cut X% to insure that all reservations<br>over the lifecycle of the system are met. And everywhere in between.<br><br></div></blockquote>That's simply not true. In order for the larger reserved allocations to be impacted</div><div>more than the smaller ones, the smaller ones already have to be down to a /28.</div><div>I don't think it makes sense to try and issue addresses from ARIN in any smaller</div><div>chunks.</div><div><br></div><div>Let's look at some semi-realistic examples.</div><div><br></div><div>A<span class="Apple-tab-span" style="white-space:pre"> </span>An extra large organization qualifies for a reservation of a /18 per quarter</div><div>B<span class="Apple-tab-span" style="white-space:pre"> </span>A large organization qualifies for a reservation of a /20 per quarter</div><div>C<span class="Apple-tab-span" style="white-space:pre"> </span>A medium organization comes out to a /22</div><div>D<span class="Apple-tab-span" style="white-space:pre"> </span>A small organization works out to a /24</div><div>and</div><div>E<span class="Apple-tab-span" style="white-space:pre"> </span>an X-small organization works out to a /28</div><div><br></div><div>Multiplying each by 8 quarters (24 months)</div><div>A<span class="Apple-tab-span" style="white-space:pre"> </span>is a /15</div><div>B<span class="Apple-tab-span" style="white-space:pre"> </span>is a /17</div><div>C<span class="Apple-tab-span" style="white-space:pre"> </span>is a /19</div><div>D<span class="Apple-tab-span" style="white-space:pre"> </span>is a /21</div><div>and</div><div>E<span class="Apple-tab-span" style="white-space:pre"> </span>is a /25</div><div><br></div><div>Let's assume that the combined reservations in the other categories add up</div><div>such that this category is limited to a /16 total space available.</div><div>(This isn't a realistic limit under the proposed policy, but, a realistic limit</div><div>would require me to generate a much larger set of requestors to over-</div><div>subscribe the space.)</div><div><br></div><div>Obviously we can't fulfill all of the reservations from a /16, so, we</div><div>take one bit away from each reservation...</div><div><br></div><div>A<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /16</div><div>B<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /18</div><div>C<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /20</div><div>D<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /22</div><div>and</div><div>E<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /26</div><div><br></div><div>This still oversubscribes the space, so, we hack off one more bit...</div><div><br></div><div>A<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /17</div><div>B<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /19</div><div>C<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /21</div><div>D<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /23</div><div>and</div><div>E<span class="Apple-tab-span" style="white-space:pre"> </span>is now a /27</div><div><br></div><div>Everyone gets 1/4 of what they applied for and they all go away similarly</div><div>unhappy.</div><div><br></div><div>Now, let's say that instead of a /16, we had only a /18 left for this category.</div><div>Again, even more unrealistic to the policy, but, illustrative, nonetheless...</div><div><br></div><div>A<span class="Apple-tab-span" style="white-space:pre"> </span>would get reduced to a /19</div><div>B<span class="Apple-tab-span" style="white-space:pre"> </span>would get reduced to a /21</div><div>C<span class="Apple-tab-span" style="white-space:pre"> </span>would get reduced to a /23</div><div>D<span class="Apple-tab-span" style="white-space:pre"> </span>would get reduced to a /25</div><div>and</div><div>E<span class="Apple-tab-span" style="white-space:pre"> </span>would get reduced to a /28</div><div><br></div><div>Everyone gets 1/16th of what they qualified for, except E who gets 1/8 of what</div><div>he qualified for. Is this favoring E over all the others? Well, arguably, yes, but,</div><div>would the others gain anything at all if we gave E a /29 instead of the /28?</div><div>Actually... No... There wouldn't be enough there to give meaningful additional</div><div>space to any of the larger requestors anyway. You'd need at least 8 E-sized</div><div>organizations reduced to zero in order to even give D another /25.</div><div><br></div><div><blockquote type="cite"><div>//Examples<br><br>Assumptions: Normal member fees apply except when reservations reduced and<br>forced to the market aside from other requirements not addressed through<br>this proposal:<br><br> Cost $1,000 /32 <br> Need: /32<br> Assignments=Assn1/2<br><br> Assn1 Assn2 Addr Deficit Loss<br> Funded 10 100 $0<br> Reduce 10% 10 90 $10,000<br> Reduce 20% 10 80 $20,000<br> Reduce 30% 10 70 $30,000<br> Reduce 40% 10 60 $40,000<br><br></div></blockquote>I'm not sure I understand your table here, so, I won't comment.</div><div><br><blockquote type="cite"><div><br>If we didn't have the complexity issue, I'd support the proposal if we<br>implemented quarterly reductions which would be more fair. The quarterly<br>assignment would be based on demonstrated need:<br><br></div></blockquote>I would not be opposed to removing one quarter at a time rather than one</div><div>bit, but, I think numerically you arrive at roughly the same result.</div><div><br><blockquote type="cite"><div><br>Assumptions: Every address acquired through a transition proposal is a cost<br>savings to the network in a fair and equitable manner.<br><br> Cost $1,000 /32 <br> Need1: 10 Need2: 100<br><br> QTRS Need1 Need2<br> 12 120 1200<br> Reduced 4 8 80 800<br> Reduced 4 4 40 400<br><br> Max Total Savings: $120,000 $1,200,000 All quarters<br> Min Total Savings: $40,000 $400,000 All quarters<br><br>You might argue that the numbers are way disparate. Since the assignments<br>are need evaluated, the savings delta are not overly relevant. Unless we opt<br>to be communists[1].<br><br>If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly<br>model we push out far more v6 that we would with the reductions as well.<br>Theoretical priming of the v6 pump: more is better even if shorter..<br><br></div></blockquote>I suspect you mean one V4 /32 = one V6 /64, but, I hesitate to comment</div><div>on speculative interpretations of your intent.</div><div><br></div><div>I do think your estimate of $1,000 per /32 is speculative at best.</div><div><br></div><div><blockquote type="cite"><div><br><blockquote type="cite">An organization may request one reservation under each provision listed in<br></blockquote><blockquote type="cite">section 4.10.4. Once a reservation has been satisfied, another may be<br></blockquote><blockquote type="cite">requested.<br></blockquote><br>I'm not even accounting for the reservations in multiple classes.<br><br>Additional thoughts on leadership by such a proposal:<br><br>A. The minimum alloc is too low<br></div></blockquote><div><br></div>Raising the minimum allocation reduces the fairness to larger organizations</div><div>while simultaneously locking out a progressively larger number of smaller</div><div>organizations. As such, I felt it was best to bring it back to smaller numbers.</div><div><br><blockquote type="cite"><div>B. We need to pick transition technologies, and not pick all of them<br></div></blockquote><div><br></div>In general any effort at having ARIN pick technologies has been rebuffed by</div><div>the community. I'm not sure why you think this policy could somehow be an</div><div>exception.</div><div><br><blockquote type="cite"><div>C. Make IPv4 unattractive<br></div></blockquote><div><br></div>It already is and the costs of IPv4 depletion will make it more unattractive.</div><div><br></div><div>The problem isn't that IPv4 is attractive. The problem is that IPv6 isn't</div><div>attractive enough to get most people over the hump. I believe that</div><div>is a self-resolving problem, but, the problem is that many organizations</div><div>are not prepared for the transition and will, as a result, suffer a greater</div><div>level of pain than they would if they had prepared earlier.</div><div><br><blockquote type="cite"><div>D. Support continued growth as much as possible during transition<br></div></blockquote><div><br></div>This proposal seeks to do just that. However, the end reality is that there</div><div>are only 16.7 million addresses in the last /8. The only way to maximize</div><div>growth during transition is to leverage those addresses to as many</div><div>IPv6 hosts supported as possible. Realistically, that's why there is</div><div>such strong language protecting 4.10.4(c) (the remaining remnant of</div><div>the original 2010-13) in the policy. It provides the maximum leverage</div><div>of users served vs. addresses issued of any of the use cases in the</div><div>policy.</div><div><br></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><blockquote type="cite"><div>1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives<br>you the dots.<br><br></div></blockquote>It's not communism to believe that you should not give all of the</div><div>remaining space to the first person in line. I don't think anyone would</div><div>call Ticketron/Bass/etc. communists, but, even they do not allow</div><div>someone to walk up and purchase all of the tickets for a concert</div><div>that is expected to sell rapidly. Being first in line should not put</div><div>you at an overwhelming advantage over those behind you.</div><div><br></div><div>Owen</div><div><br></div><br></body></html>