<div dir="ltr">Comments in line.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 3, 2017 at 1:49 PM, Mike Burns <span dir="ltr"><<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</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"><div lang="EN-US"><div class="gmail-m_-7610612583602955175WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Hi Alison,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">We have done 400+ transfers and have never heard of this problem from any buyer.</span></p></div></div></blockquote><div><br></div><div><div>1. Going forward, organizations requiring a /15 or less per year would likely just use the simplified </div><div>doubling approach (2016-3) , as such this policy proposal would not be helpful </div><div>(and current policy not a problem).</div></div><div><br></div><div>2. This problem would only impact organizations that are large enough to have their own relationship with </div><div>ARIN.   The organization's internal struggle with creating a justification that they can stand behind, </div><div>and meet ARIN requirements would generally be kept internal to such an organization.  I expect</div><div>these organizations would have already secured pre-approval prior to engaging an outside organization</div><div>to complete a transfer.</div><div><br></div><div>3. This problem has only emerged since the implementation of ARIN-2016-6 which occurred on </div><div>02/21/2017.  Transfers prior to this date could have been justified under slow start in section 4.</div><div><br></div><div>- How many of the 400+ transfers has the approval been completed post 02/21/2017?  </div><div><br></div><div>- Of those, how many transfer are larger than a /16? <br></div><div> (or the transfer in question brings the org to over a /15 worth of transfers in the previous</div><div>  1 year rolling window)</div><div><br></div><div>- Of those, how many have you consulted on putting together the justification for transfer approval?</div><div><br></div><div>So yes, I am not surprised that in your 400+ transfers you have not seen this as an issue.  </div><div><br></div><div>Thant doesn't mean it is not an issue.   </div><div><br></div><div>While I expect that well over 90% will make use of either NRPM 8.5.4 or 2016-3 </div><div>(maybe even as Owen suggests 2016-3 "obviates the need for [2017-1] by and large."),</div><div>there are still a small number of requests that are for larger than a /15 per year.</div><div><br></div><div>To not address that small amount of requests suggests we as a community do not</div><div>care about their need.</div><div><br></div><div>Prior to  02/21/2017 those requests had the option to base their two year need solely</div><div>on the recent past consumption rate.  These requests will now be forced to use a </div><div>purely future looking projection, with no clear guidance on what justification ARIN </div><div>will accept, or how much additional information, back and forth discussion, and time</div><div>will be required, nor the ability to predict the likelihood that a request should or should</div><div>not be approved.</div><div><br></div><div>Google is a data driven company. </div><div>   </div><div>In a data driven company it may be easier to simply base a future looking growth on a</div><div>real measure of current consumption rate, knowing that this will necessarily result in a</div><div>short fall because you are only requesting IP addressed based on the current rate, and</div><div>not the current growth rate.  </div><div><br></div><div>In the absence of real data, people will often guess.  Some people guess better, some </div><div>worse.  Some guesses are based on intricate algorithms, real data, and Fermi maths, </div><div>others are just what feel right.  Either type can be multiple orders of magnitude off, or </div><div>in the right ballpark.</div><div><br></div><div>Do we really want to encourage data driven companies who previously requested less IP</div><div>space then they needed because their requests have always been based on a real </div><div>measure of consumption, and not addressing speculative growth, to instead require them</div><div>to guess about the future?  Especially noting that if they guess too low, the penalty is</div><div>running out of IPs, and if they guess to high there is no penalty (except if they buy a </div><div>surplus and end up with IPs that were bought which go unused)?  </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-7610612583602955175WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Buyers are far more concerned with ensuring supply and what it will cost.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">I don’t see the value in more Section 8 clutter.</span></p></div></div></blockquote><div><br></div><div>I would encourage you to no think of this as more clutter in section 8, but rather addressing </div><div>a justification that was previously support under section 4, and now has to be mirrored into</div><div>section 8 to continue to support the legitimacy of this type of a request in order to address</div><div>over-pruning. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-7610612583602955175WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Anybody in the world with any sort of concern about demonstrating need by whatever arcane formula can avail themselves of the needs-free policy in RIPE.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Open an account there, buy what you need, use them anywhere. Plus no transfer fees!</span> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-7610612583602955175WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">That’s the workaround.  Even better would be to address this problem through excision of the needs test from ARIN transfer policy, rendering the NRPM  simpler, easier to use, and less cluttered by pointless artifacts from the free-pool era.</span></p></div></div></blockquote><div><br></div><div>We attempted this with 2016-3 where the needs justification was simplified, and it has </div><div>been addressed for those organizations that need less than a /15 per year.</div><div><br></div><div>Initially there was no cap on this proposal, but the community pushed back, and said </div><div>we don't need to make things more simple for large organizations.  That, and a severing</div><div>transfers from section 4 resulted in removal of the option to use slow start.</div><div><br></div><div>So now we have to deal with adding slow-start complexity (for large ISPs) to transfer</div><div>policy.</div><div><br></div><div>Please note, this does not add any new required test, nor would it force anyone who</div><div>qualifies under the current policy to get rejected.</div><div> </div><div>If you oppose this on the grounds of less clutter, then I suggest you should have </div><div>provided more support for moving 2016-3 forward without a cap.</div><div> </div><div>___Jason</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-7610612583602955175WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">So I don’t support the proposal in its revised form.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Regards,<br>Mike Burns<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:11pt;font-family:calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:calibri,sans-serif"> ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@<wbr>arin.net</a>] <b>On Behalf Of </b>WOOD Alison * DAS<br><b>Sent:</b> Wednesday, May 03, 2017 1:35 PM<br><b>To:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br><b>Subject:</b> [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates<u></u><u></u></span></p></div></div><div><div class="gmail-h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif">The ARIN Draft Policy 2017-1 shepherds working with the original author have updated the problem statement and added clarification to section 8.5.5.  The AC would like feedback on the proposed updated problem statement and modification to 8.5.5. We encourage community members to comment on the proposed updates.  <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif">Problem Statement (revised):<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;background-color:yellow">Some number of organizations may be uncomfortable making speculative forward projections (that are now required under NRPM section 8 for purposes of transfer request approval) and prefer that there be available a more certain approach based solely on extrapolation of their existing IPv4 number usage trend.</span><span style="font-size:10pt;font-family:arial,sans-serif"><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif">And adding the following text to the end of 8.5.5<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;background-color:yellow">Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request.</span><span style="font-size:10pt;font-family:arial,sans-serif"><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"> </span><span style="font-size:10pt;font-family:arial,sans-serif"><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif">Thank you!<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:arial,sans-serif"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"> </span><span style="font-size:10pt;font-family:arial,sans-serif"><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"> </span><span style="font-size:10pt;font-family:arial,sans-serif"><u></u><u></u></span></p></div></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"><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></div>