<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I don't understand what you mean by "% space available related to % request fulfillment".</div><div><br></div><div>The only thing I could think of was essentially what we have today -- If 100% of what you request is available, you get it.</div><div>If less than that is available, you get what is left. Either of these regardless of the number of prefixes involved in fulfilling</div><div>your request.</div><div><br></div><div>Obviously you're suggesting something that could be a policy proposal, so, can you clarify what I misunderstood?</div><div><br></div>Since most laws against anti-competitive practices are geared towards preventing small numbers of massive organizations from blocking entry or competition by larger numbers of smaller entities, I believe that allowing a small number (or likely even 1 at some point) to garner all of the remaining space to the exclusion of a much larger number of smaller entities is unfair. As it already stands, 24 extra large organizations hold more than 80% of the address space issued in 2006 and 2007 (the only statistics I could find on the ARIN web site). I think the fair thing to do once ARIN starts receiving requests it can't satisfy with a single block is to start limiting the number of crumbs each organization may pick up at one time. Yes, this means that smaller organizations will continue to get the /20s and smaller that they ask for long after we can no longer hand out /9s. However, that's largely the result of the fact that there are more than 2 million /20s in each /9 more than anything particularly unfair.<div><br></div><div>As time goes on, the size of the largest crumbs will get progressively smaller. In reality, under this policy, the large organizations will take the largest crumbs early on leaving only smaller crumbs behind.</div><div><br></div><div>Should they be allowed to get an ever increasing percentage of the remaining crumbs at the expense of others?</div><div><br></div><div>It's clearly expressed in NRPM 8.3 that this is not the will of the community.</div><div><br></div><div>One of the few points of 2010-1 that received no opposition was it's provision to limit each entity to exactly 1 crumb. Here I'm offering 4 crumbs as an alternative strategy.</div><div><br></div><div>Otherwise, as it stands now, it's basically a lottery to see which x-large ISP picks up thousands of prefixes in one request to finish out the ARIN free pool.</div><div><br></div><div>Remember, there was some community support for proposals that said if your request can't be completely filled, you wait, too bad, so sad. I spoke out against those proposals because I felt they were unfair to large organizations. I believe current policy is unfair to smaller organizations. This policy is my attempt to strike a balance.</div><div><br></div><div><br></div><div>Owen</div><div><br><div><div>On Apr 28, 2010, at 6:29 PM, Hannigan, Martin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
<font face="Courier, Courier New"><span style="font-size:10pt"><br>
<br>
No need to assert a position on this, but I will say that the distribution method is severely lacking. Under this regime some will undoubtedly fulfill their requests entirely and others will not. <br>
<br>
The language that would be more suitable is something akin to pct of space available related to request fulfillment pct IMHO. Specifying hard limits may be anti-competitive, especially with the apparently hostile reason that you state for the creation of this policy “</span></font><span style="font-size:10pt"><font face="Monaco, Courier New">I believe there is a need for policy to prevent this kind of</font><font face="Courier, Courier New"> </font><font face="Monaco, Courier New">gathering of the last breadcrumbs by a small number of large</font><font face="Courier, Courier New"> </font><font face="Monaco, Courier New">entities.”<br>
<br>
Best,<br>
<br>
-M<<br>
</font><font face="Courier, Courier New"><br>
<br>
-- <br>
Martin Hannigan <a href="http://www.akamai.com/">http://www.akamai.com</a><br>
Akamai Technologies, Inc. <a href="x-msg://54/marty@akamai.com">marty@akamai.com</a><br>
Cambridge, MA USA cell: +16178216079<br>
ofc: +16174442535<br>
<br>
<br>
<hr align="CENTER" size="3" width="95%"><b>From: </b>Owen DeLong <<a href="x-msg://54/owen@delong.com">owen@delong.com</a>><br>
<b>Date: </b>Wed, 28 Apr 2010 14:38:13 -0700<br>
<b>To: </b><<a href="x-msg://54/policy@arin.net">policy@arin.net</a>>, arin ppml <<a href="x-msg://54/ppml@arin.net">ppml@arin.net</a>><br>
<b>Subject: </b>[arin-ppml] IPv4 Fragment Managemnt policy proposal<br>
<br>
</font><font face="Monaco, Courier New">At ARIN XXV, one of the discussions pointed out that under current<br>
ARIN policy, after IANA runout, a justified request for a /10 could<br>
(and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.<br>
<br>
I believe there is a need for policy to prevent this kind of<br>
gathering of the last breadcrumbs by a small number of large<br>
entities. As such, I offer the following proposal for the discussion<br>
of the community.<br>
<br>
Owen<br>
<br>
</font></span><font face="Monaco, Courier New"><font size="2"><span style="font-size:9pt">TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0<br>
<br>
1. Policy Proposal Name: IPv4 Fragment Management<br>
2. Proposal Originator<br>
a. name: Owen DeLong<br>
b. email: <a href="x-msg://54/owen@delong.com">owen@delong.com</a><br>
c. telephone: 408-890-7992<br>
d. organization: Hurricane Electric<br>
3. Proposal Version: 0.8<br>
4. Date: 2010-04-28<br>
5. Proposal type: New<br>
new, modify, or delete.<br>
6. Policy term: Permanent<br>
temporary, permanent, or renewable.<br>
7. Policy statement:<br>
</span></font><span style="font-size:10pt"><br>
Add the following to the NRPM as new sections 4.2.1.7 et. seq.<br>
<br>
Each time ARIN approves an IPv4 request which it cannot<br>
satisfy from 4 or fewer bit-aligned blocks of free address<br>
space, ARIN shall notify the requestor that there is<br>
insufficient free address space to meet their request and<br>
shall offer the requestor their choice of the following<br>
alternatives:<br>
<br>
a. They can have the largest 4 available bit-aligned<br>
blocks of free addresses.<br>
<br>
b. This section reserved -- (in case we implement the<br>
waiting list for unmet requests policy)<br>
<br>
c. They can seek resources through the directed<br>
transfer policy in section 8.3 of the NRPM.<br>
<br>
</span><font size="2"><span style="font-size:9pt">8. Rationale:<br>
</span></font><span style="font-size:10pt"><br>
When the ARIN free pool begins to diminish, the free space<br>
will become fragmented into smaller and smaller remaining<br>
contiguous spaces. This policy attempts to ensure that a<br>
large number of remaining disjoint small blocks are not<br>
consumed by a single large request.<br>
<br>
While this policy could be regarded as unfair to larger<br>
entities, it is consistent with the safeguards adopted in<br>
section 8.3 which require an exact match or full fill<br>
style of resource transfer. As such, I believe the policy<br>
is fair and in line with the consensus will of the community.<br>
<br>
</span><font size="2"><span style="font-size:9pt">9. Timetable for implementation: Immediate, although it has no<br>
</span></font><span style="font-size:10pt">actual effect until some time after IANA runout.<br>
<br>
</span><font size="2"><span style="font-size:9pt">END OF TEMPLATE<br>
</span></font></font><font face="Courier, Courier New"><span style="font-size:10pt"><br>
<br>
<hr align="CENTER" size="3" width="95%">_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="x-msg://54/ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="x-msg://54/info@arin.net">info@arin.net</a> if you experience any issues.<br>
</span></font>
</div>
</blockquote></div><br></div></body></html>