<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I see no reason to move the boundary for an ISP initial allocation from /21 to /24.<div class=""><br class=""></div><div class="">I certainly see no reason for “up to a /24” as there’s nothing smaller available and even if it were, it wouldn’t be useful in any foreseeable environment.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 18, 2018, at 2:21 PM, David Farmer <<a href="mailto:farmer@umn.edu" class="">farmer@umn.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">David, <div class=""><br class=""></div><div class="">The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy.</div><div class=""><br class=""></div><div class="">So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. </div><div class=""><br class=""></div><div class="">The current text of 4.2.2 is;</div><div class=""><br class=""></div><div class=""><div class="">4.2.2. Initial allocation to ISPs</div><div class=""><br class=""></div><div class="">All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization.</div></div><div class=""><br class=""></div><div class="">The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. </div><div class=""><br class=""></div><div class="">I propose we simplify that to the following;</div><div class=""><br class=""></div><div class=""><div class="">4.2.2. Initial allocation to ISPs</div><div class=""><br class=""></div><div class="">All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months.</div><div class=""> </div><div class="">Below is the policy update that results;<br class=""></div></div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">--------</div><div class=""><br class=""></div><div class="">Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers<br class=""><br class=""></div><div class=""><div class="">Problem Statement: </div><div class=""><br class=""></div><div class="">It was noted in the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow qualified ISPs an initial /21 for Section 8 transfers when they first apply and are approved under section 4. If an organization applies under section 8 first they are initially qualified for a /24, larger allocations require additional documentation as noted in 8.5.5.</div><div class=""><br class=""></div><div class="">Policy Statement:</div><div class=""><br class=""></div><div class="">Change section 4.2.2 as follows;<br class=""></div></div><div class=""><br class=""></div><div class=""><div class="">4.2.2. Initial allocation to ISPs</div><div class=""><br class=""></div><div class="">All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. </div></div><div class=""><br class=""></div><div class=""><div class="">Comments:</div><div class=""><br class=""></div><div class="">Timetable for implementation: Immediate</div></div><div class=""> </div><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 7, 2017 at 11:37 PM, David Huberman <span dir="ltr" class=""><<a href="mailto:daveid@panix.com" target="_blank" class="">daveid@panix.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto" class="">Thank you for the clarification. I think the staff practice is a reasonable approach and I don’t think change is needed in policy for this.<div class=""><br class=""></div><div class="">The updated Problem Statement reveals the real issue here - the one we need to figure out as a community. What to do about all the requests each month for IPv4 addresses under section 4? </div><div class=""><br class=""></div><div class="">Is it time to pass a policy to direct staff to no longer accept section 4 requests (except the ones they still fill like critical infrastructure)? I wonder what the downside of such a policy would be - anyone know?<br class=""><br class=""><br class=""><div class=""></div><div class=""><br class="">On Dec 7, 2017, at 11:47 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" target="_blank" class="">andrew.dul@quark.net</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">
<div class="gmail-m_7330969528827097710m_-7404073590307884808moz-cite-prefix">It was noted to me by ARIN staff, that
this updated problem statement doesn't accurately reflect ARIN's
current practice. Below I suggest another updated problem
statement.<br class="">
<br class=""><p class=""><strong class="">Problem Statement: </strong></p>
It was noted at the ARIN 40 Policy Experience Report, that there
is an inconsistency in the initial block size for ISPs. Section
4.2.2 notes that the initial ISP block size should be /21 whereas
the initial block size in 8.5.4 is noted as "minimum transfer
size" which is effectively a /24. This causes ISP organizations to
be approved for different initial block size depending on if they
first apply apply for a transfer directly under section 8 or if
they apply for a block under section 4. This policy is intended
to clarify this issue, by setting a consistent ISP initial IPv4
block size. It was noted that ARIN staff current operational
practice is to allow qualified ISPs an initial /21 for Section 8
transfers when they first apply and are approved under section 4.
If an organization applies under section 8 first they are
initially qualified for a /24, larger allocations require
additional documentation as noted in 8.5.5.<br class=""><br class=""></div></div></blockquote></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail-m_7330969528827097710gmail_signature">==============================<wbr class="">=================<br class="">David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">Email:farmer@umn.edu</a><br class="">Networking & Telecommunication Services<br class="">Office of Information Technology<br class="">University of Minnesota <br class="">2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank" class="">612-626-0815</a><br class="">Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank" class="">612-812-9952</a><br class="">==============================<wbr class="">=================</div>
</div></div></div>
_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.</div></blockquote></div><br class=""></div></body></html>