<div dir="ltr">Can you clarify the problem (I'm confused).<div><br></div><div>What I expect to happen and an ISP under 4.2.2 can get an initial allocation of between a /24 and a /21 inclusive. </div><div>They will be slow started because they have no history. They can get a 2 year supply, and will need to make it </div><div>80% utilized before they can come back for more..</div><div><br></div><div>Utilized means:<br></div><div><br></div><div>- If an IP block is allocated/assigned to a customer and one of the following is true:<br></div><div> - the customer can show justification for 25% utilization in 30 days 50% in 1 year</div><div> - the customer can show a discreet multi-homing requirement each /24</div><div> - the residential market area IP block is at least 50% utilized</div><div> - the residential market area is TPIA and</div><div> - initial assignments to each piece of hardware is the smallest possible</div><div> - additional assignments to each piece of hardware only made after 80% utilization</div><div> - additional assignments to each piece of hardware is not more than a 2 year supply</div><div><br></div><div>Then that space is considered 100% utilized</div><div><br></div><div>IP space in use by the ISP is counted as utilized.</div><div>This includes network and broadcast addresses for subsets in use.</div><div><br></div><div><br></div><div>Under 8.5.4</div><div>They can transfer pre-approval for a /24 no questions asked if they have no direct IPv4. </div><div><br></div><div>If they have a direct IPv4, or want pre-approval for more than a /24 then they</div><div>need to show how they will use 50% of the requested space in 24 months.</div><div><br></div><div><br></div><div><br></div><div>What is weird is post last /8, ISP could only get a 90 day supply on slow start and then</div><div>had to come back. So request for ARIN space were 1/8 the size (90 days) of what could</div><div>be request on the transfer market (2 years). We adjusted this back to a two year supply to </div><div>mirror the transfer window of time and simplify things (which I opposed at the time, </div><div>but now that it is changed standby it).</div><div><br></div><div>___Jason</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 7:33 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">We could also simplify section 8 to state that the minimum transfer size is /24 and that initial requests for transfer are governed by officer attestation limits unless a larger size is needed.<span class="HOEnZb"><font color="#888888"><div><br></div><div>Owen</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jan 18, 2018, at 4:32 PM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_-2398906738544701596Apple-interchange-newline"><div><div dir="ltr" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br class="m_-2398906738544701596Apple-interchange-newline">Looking at this a little more closely;</div><div><br></div><div>Section 8.5.4 has a common size for both initial allocations and assignments or in other words an initial transfer size of /24.</div><div><br></div><div>Whereas in section 4 the initial allocations and assignments sizes differ; with section 4.2.2 having an initial ISP allocation size of /21 and section 4.3.2 having an initial end-user assignment size of /24.</div><div><br></div><div>So, I believe the easiest way to harmonize section 4 and 8 is to harmonize section 4.2.2 with section 4.3.2 at /24.</div><div><br></div><div>Otherwise, we need to make section 8 more complicated and distinguishing between initial allocations and assignments sizes.</div><div><br></div><div>So which way should we go?</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong<span class="m_-2398906738544701596Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span><span class="m_-2398906738544701596Apple-converted-space"> </span>wrote<wbr>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Well, section 4 doesn’t govern transfers since we decoupled it anyway, so I’m not sure if we want to make staff behavior consistent or not. I would argue that moving the transfer boundary to /21 would make more sense than moving the section 4 boundary to /24, if we are going to synchronize them.<div><br></div><div>However, as you point out, transfers are governed by 8.5.5 and only free pool is governed by section 4 unless section 4 is referenced by section 8.</div><div><br></div><div>As you may recall, I opposed this decoupling because of the confusion and disparity in protocol I expected to result. Now we’re exactly where I predicted we’d be.</div><div><br></div><div>Owen</div><div><br></div><div><div><blockquote type="cite"><div>On Jan 18, 2018, at 3:03 PM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_-2398906738544701596m_-6368037822852161994Apple-interchange-newline"><div><div dir="ltr">From the updated problem statement: 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><br></div><div>Again, whether a change in policy or staff practice, what do we want to happen?</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong<span class="m_-2398906738544701596Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span><span class="m_-2398906738544701596Apple-converted-space"> </span>wrote<wbr>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">The existing language “up to a /21” is consistent with staff allowing you to obtain a /24 via transfer.<div><br></div><div>Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language.</div><div><br></div><div>Owen</div><div><br><div><blockquote type="cite"><div>On Jan 18, 2018, at 2:37 PM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-interchange-newline"><div><div dir="ltr" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Owen,</div><div><br></div>Yep, that was an editing error, it should have been; <div><br></div><div><div>4.2.2. Initial allocation to ISPs</div><div><br></div><div>All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of 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="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span><span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span>wrote<wbr>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">I see no reason to move the boundary for an ISP initial allocation from /21 to /24.</div></blockquote><div><br></div><div>Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then?</div><div><br></div><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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><br></div><div>Owen</div><div><br><div><blockquote type="cite"><div>On Jan 18, 2018, at 2:21 PM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623gmail-m_-518916427042525628Apple-interchange-newline"><div><div dir="ltr">David, <div><br></div><div>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><br></div><div>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><br></div><div>The current text of 4.2.2 is;</div><div><br></div><div><div>4.2.2. Initial allocation to ISPs</div><div><br></div><div>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><br></div><div>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><br></div><div>I propose we simplify that to the following;</div><div><br></div><div><div>4.2.2. Initial allocation to ISPs</div><div><br></div><div>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><div>Below is the policy update that results;<br></div></div><div><br></div><div>Thanks</div><div><br></div><div>--------</div><div><br></div><div>Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers<br><br></div><div><div>Problem Statement: </div><div><br></div><div>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><br></div><div>Policy Statement:</div><div><br></div><div>Change section 4.2.2 as follows;<br></div></div><div><br></div><div><div>4.2.2. Initial allocation to ISPs</div><div><br></div><div>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><br></div><div><div>Comments:</div><div><br></div><div>Timetable for implementation: Immediate</div></div><div> </div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 11:37 PM, David Huberman<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>></span><span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span>wr<wbr>ote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">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><br></div><div>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><br></div><div>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><br><br><div></div><div><br>On Dec 7, 2017, at 11:47 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>> wrote:<br><br></div><blockquote type="cite"><div><div class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623gmail-m_-518916427042525628gmail-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><br><p><strong>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><br></div></div></blockquote></div></div></blockquote></div><br><br clear="all"><div><br></div>--<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><br><div class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623gmail-m_-518916427042525628gmail-m_7330969528827097710gmail_signature">==============================<wbr>=================<br>David Farmer <span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><br><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g" target="_blank">2218 University Ave SE</a> <span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span>Phone:<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell:<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>=================</div></div></div></div>______________________________<wbr>_________________<br>PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">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" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>Please contact<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><a href="mailto:info@arin.net" target="_blank">info@arin.net</a><span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span>if you experience any issues.</div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><span class="m_-2398906738544701596m_-6368037822852161994gmail-HOEnZb"><font color="#888888"><div><br></div>--<span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><br><div class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623gmail_signature">==============================<wbr>=================<br>David Farmer <span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <span class="m_-2398906738544701596m_-6368037822852161994gmail-m_-8174756350665526623Apple-converted-space"> </span><br><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g" target="_blank">2218 University Ave SE</a> <span class="m_-2398906738544701596Apple-converted-space"> </span>Phone:<span class="m_-2398906738544701596Apple-converted-space"> </span><a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell:<span class="m_-2398906738544701596Apple-converted-space"> </span><a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>=================</div></font></span></div></div></div></div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><span class="m_-2398906738544701596HOEnZb"><font color="#888888"><div><br></div>--<span class="m_-2398906738544701596Apple-converted-space"> </span><br><div class="m_-2398906738544701596m_-6368037822852161994gmail_signature">==============================<wbr>=================<br>David Farmer <span class="m_-2398906738544701596Apple-converted-space"> </span><a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <span class="m_-2398906738544701596Apple-converted-space"> </span><br><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g" target="_blank">2218 University Ave SE</a> <span class="m_-2398906738544701596Apple-converted-space"> </span>Phone:<span class="m_-2398906738544701596Apple-converted-space"> </span><a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell:<span class="m_-2398906738544701596Apple-converted-space"> </span><a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>=================</div></font></span></div></div></div></div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div>--<span class="m_-2398906738544701596Apple-converted-space"> </span><br><div class="m_-2398906738544701596gmail_signature" data-smartmail="gmail_signature">==============================<wbr>=================<br>David Farmer <span class="m_-2398906738544701596Apple-converted-space"> </span><a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <span class="m_-2398906738544701596Apple-converted-space"> </span><br>2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>=================<span class="m_-2398906738544701596Apple-converted-space"> </span></div></div></div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto: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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>