<HTML>
<HEAD>
<TITLE>Re: [arin-ppml] IPv4 Fragment Managemnt policy proposal</TITLE>
</HEAD>
<BODY>
<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="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="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="policy@arin.net">policy@arin.net</a>>, arin ppml <<a href="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="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="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="info@arin.net">info@arin.net</a> if you experience any issues.<BR>
</SPAN></FONT>
</BODY>
</HTML>