<div dir="ltr">As previously stated, we should revise 4.2.2 to be consistent with 8.5.4.<div><br></div><div>The changes proposed in 2016-3, 2016-4, 2016-5 were all part of a package</div><div>that intended to:</div><div><br></div><div>- create a slow start for transfers (double what you have) - 2016-3</div><div>- create a boot strapping for tranfers (first /24 with no justification) - 2016-5</div><div>- remove efficent utilization or immedate (30 day) need for ISP initial - 2016-4</div><div>- create a boot strapping for initial ISP (first /24 with no justification) - 2016-4</div><div>- sync initial ISP w/ no resources, desiring greater than /24 w/ transfers - 2016-4</div><div><br></div><div>It is my belief as one of the originators that there was no desire to remove the</div><div>the time horizion requirement for ISP initial (except for a /24).</div><div><br></div><div>It is my belief as one of the originators that there was no desire to remove the<br></div><div>requirement that ISP with IPv4 space from their upstream need to demonstare</div><div>efficent utilization.</div><div><br></div><div>I beleive these are all a side effect of removing the 2.2.2 subsections.</div><div><div><br></div><div>2016-4 is not clear that the sub sections will be removed.</div></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, Feb 1, 2018 at 11:42 AM, 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">As previously stated, IMHO, we should revise 8.5.4 to be consistent with 4.2.2.<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 31, 2018, at 13:18 , David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_-584698022399658291Apple-interchange-newline"><div><div dir="ltr">There seems to be a bit of controversy on the direction to take this policy. Therefore as the shepherd, it would be helpful to hear from additional community members regarding this policy. <div><br></div><div>Do you support or oppose the policy as written? </div><div><br></div><div>Do you think the inconsistency described in the Problem Statement should be corrected?</div><div><br></div><div>If yes, should it be corrected by revising by section 8.5.4 to be consistent with section 4.2.2, as proposed by the current text?</div><div><br></div><div>Or, as an alternative by revising section 4.2.2 to be consistent with section 8.5.4?</div><div><br></div><div>Are there other alternatives to correct the inconsistency to be considered?</div><div> </div><div>Other suggestions or comments?</div><div><br></div><div>Your additional feedback and participation are appreciated, thank you.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 7:42 AM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The following has been revised:<br>
<br>
* Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers<br>
<br>
Revised text is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2017_9.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/pr<wbr>oposals/2017_9.html</a><br>
<br>
You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/pd<wbr>p.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/pr<wbr>oposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers<br>
<br>
Problem Statement:<br>
<br>
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.<br>
<br>
Policy statement:<br>
<br>
Replace section 8.5.4;<br>
<br>
8.5.4. Initial block<br>
<br>
Organizations without direct assignments or allocations from ARIN qualify for the transfer of an initial IPv4 block, a /24 for assignments or a /24 up to a /21 for allocations.<br>
<br>
Comments:<br>
<br>
Timetable for implementation: Immediate<br>
<br>
Anything Else:<br>
<br>
The ARIN 40 Policy Experience Report is available at;<br>
<br>
Slides: <a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf" rel="noreferrer" target="_blank">https://www.arin.net/vault/par<wbr>ticipate/meetings/reports/ARIN<wbr>_40/PDF/PPM/sweeting-policy-ex<wbr>perience.pdf</a> <br>
<br>
Transcript: <a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5" rel="noreferrer" target="_blank">https://www.arin.net/vault/par<wbr>ticipate/meetings/reports/ARIN<wbr>_40/ppm1_transcript.html#ancho<wbr>r_5</a><br>
<br>
Video: <a href="https://www.youtube.com/watch?v=QVsfVMG_6fA" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=QVsfVMG_6fA</a><br>
<br>
Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant portion of the report, questions from the audience follow.<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" 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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-584698022399658291gmail_signature">==============================<wbr>=================<br>David Farmer <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 <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>=================</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 <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</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>