<div dir="ltr">Alyssa,<div><br></div><div>I agree with the general will of the community that a 30 day check for </div><div>ARIN allocations, and a 30 or 60 day check for specified transfers is</div><div>an unreasonably difficult metric to meet.</div><div><br></div><div>I suggested "<span style="font-size:12.8px">Removing the 25% / 30 day [60 day for transfers] </span></div><div><span style="font-size:12.8px">requirement without some </span><span style="font-size:12.8px">added test based on a current or past </span></div><div><span style="font-size:12.8px">measure of need to deflate a </span><span style="font-size:12.8px">purely future looking projection </span></div><div><span style="font-size:12.8px">seems too liberal." </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This would roughly amount to slow start, you get a two year supply</span></div><div><span style="font-size:12.8px">based on double what you used last year. </span><span style="font-size:12.8px">This is what ISPs are </span></div><div><span style="font-size:12.8px">held to.</span></div><div><br></div><div>I suggested that the 25% provision "is <span style="font-size:12.8px">the only provision that has </span></div><div><span style="font-size:12.8px">a real, tangible, </span><span style="font-size:12.8px">and verifiable claim. Without this check justified </span></div><div><span style="font-size:12.8px">need for end users </span><span style="font-size:12.8px">simply becomes a 1 [2 year for transfers] year </span></div><div><span style="font-size:12.8px">future looking projection, and with sufficient arm waving an easy </span></div><div><span style="font-size:12.8px">end run around justified need for any end user with no IP space </span></div><div><span style="font-size:12.8px">or if they are efficiently using what they currently hold." </span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I further suggested that "<span style="font-size:12.8px">I could get on board if the maximum sized </span></div><div style="font-size:12.8px"><span style="font-size:12.8px">block permitted on a purely future looking projection was a /24 and </span></div><div style="font-size:12.8px"><span style="font-size:12.8px">you had to use it prior to getting more." </span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">This would support an initial assignment for organization that have</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">no history of growth in the last two years. This would be the starting</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">point for slow start, and then would double is used in less than a year.</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I also said I could get on board if the following text was added to the policy:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">"there must be some tangible and verifiable claim to show there was a </div><div style="font-size:12.8px">real <span style="font-size:12.8px">commitment to use half the address space within one year and not </span></div><div style="font-size:12.8px"><span style="font-size:12.8px">just a future projection or business case"</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">And suggested we should have a discussion about if that provision should</div><div style="font-size:12.8px">be vague (as is above), specific (listing types of proof acceptable), or</div><div style="font-size:12.8px">opened ended (listing some of the types of proof as guidance). </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Response was:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1. - Why add text to IPv4 policy. </div><div style="font-size:12.8px"> - You already have to pay for IPv4, that should <span style="font-size:12.8px">be sufficient to avoid abuse. </span></div><div style="font-size:12.8px"><span style="font-size:12.8px"> - Besides we should all only care about IPv6</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"> - prefer as written</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2. - I am leaning towards an open ended verifiable claims.</div><div style="font-size:12.8px"> - Specific claims could also work.</div><div style="font-size:12.8px"> - We really need some guidance about what ARIN takes as acceptable</div><div style="font-size:12.8px"> justification in order<span style="font-size:12.8px"> </span><span style="font-size:12.8px">to move forward on getting an allocation approved</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">3. support as written</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">4. support as written</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">5. oppose as written</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"> - needs teeth</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">two support as written</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">one prefer as written</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">one leaning towards open ended tangible proof</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">one opposed as written without teeth</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">What is truly concerning to me is this belief that </span></div><div><span style="font-size:12.8px">the policy change is a no-op on the following </span></div><div><span style="font-size:12.8px">grounds:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">1. It does change the rules for ARIN allocations</span></div><div><span style="font-size:12.8px"> but who cares, there is a long waiting list and</span></div><div><span style="font-size:12.8px"> a trickle of space coming out there.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">2. It doesn't change anything for transfers as </span></div><div><span style="font-size:12.8px"> staff ignores this check anyway.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I was surprised that ARIN feels they cannot</span></div><div><span style="font-size:12.8px">complete a 25% check wrt specified transfers</span></div><div><span style="font-size:12.8px">due to lack of guidance.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I was further confused by the staff comment that </span></div><div><span style="font-size:12.8px">the </span><span style="font-size:12.8px">25% check is still part of policy and intentionally</span></div><div><span style="font-size:12.8px">violating it is fraud. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I further believe this change is not a no-op.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">1. Current policy prevents organizations who do not</span></div><div><span style="font-size:12.8px"> want to commit fraud from asking for too much.</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px">2. </span><span style="font-size:12.8px">Current policy prevents organizations who are </span></div><div><span style="font-size:12.8px"> afraid of a possible audit of the 25% number </span></div><div><span style="font-size:12.8px"> is likely to show them out of compliance from </span></div><div><span style="font-size:12.8px"> asking for to much.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">3. if it is a no-op then just leave the text in until</span></div><div><span style="font-size:12.8px"> we can find new text to prevent aggressively </span></div><div><span style="font-size:12.8px"> optimistic projections that circumvent need </span></div><div><span style="font-size:12.8px"> based </span><span style="font-size:12.8px">policy.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Without this text, or some other provision to limit </span></div><div><span style="font-size:12.8px">wildly optimistic growth claims, there is no way </span></div><div><span style="font-size:12.8px">to keep an end-user organization that wants to </span></div><div><span style="font-size:12.8px">remain in </span><span style="font-size:12.8px">compliance with policy from asking for </span></div><div><span style="font-size:12.8px">what is </span><span style="font-size:12.8px">likely much more than a two year supply.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Essentially the policy will be:</span></div><div><span style="font-size:12.8px">"End-users can get as much IP space as they want</span></div><div><span style="font-size:12.8px"> as long as they meet the 3 following requirements:</span></div><div><span style="font-size:12.8px">1. The average of their current holdings (if any) </span></div><div><span style="font-size:12.8px"> are above 80% used.</span></div><div><span style="font-size:12.8px">2. An officer of the company</span><span style="font-size:12.8px"> attests that the plan to </span><br></div><div><span style="font-size:12.8px"> use half the requested addresses in two years </span></div><div><span style="font-size:12.8px"> is not impossible to achieve. </span></div><div><span style="font-size:12.8px">3. They can afford to buy the addresses."</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Alyssa, your questions about what advice to give ARIN </span></div><div><span style="font-size:12.8px">about current policy is a very interesting question.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Unfortunately it crosses the transfer without needs</span></div><div><span style="font-size:12.8px">justification discussion, which complicates everything.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I don't know how you can craft the question to get at </span></div><div><span style="font-size:12.8px">the answer of what checks ARIN should do, without </span></div><div><span style="font-size:12.8px">falling into the wider discussion of should there be a </span></div><div><span style="font-size:12.8px">needs basis check at all. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The original proposal was to remove the 30 day check as </span></div><div><span style="font-size:12.8px">it was a burden. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It seems people who support specified transfers without </span></div><div><span style="font-size:12.8px">a needs based justification support this policy as this</span></div><div><span style="font-size:12.8px">moves things far along in that direction. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It seems others support this policy as it makes it possible</span></div><div><span style="font-size:12.8px">for an end-user organization to get addresses without </span></div><div><span style="font-size:12.8px">first using an up-streams IPs. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It seems yet another group believe the 30 day check to </span></div><div><span style="font-size:12.8px">be unreasonable, and taking it out is a no-op </span></div><div><span style="font-size:12.8px">(when it appears to actually limit requests in its current </span></div><div><span style="font-size:12.8px">form even with ARIN's current operating practices)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Unfortunately this is very complicated.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">__Jason</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> </span></div><div style="font-size:12.8px"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 6:42 PM, Alyssa Moore <span dir="ltr"><<a href="mailto:alyssa.moore@cybera.ca" target="_blank">alyssa.moore@cybera.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:small">Apologies in advance for jumping in at the last minute on a policy that's in recommended form, but I have a few questions and observations. <br></span><span class=""><div dir="ltr"><br><div style="font-family:'helvetica neue',helvetica,arial,sans-serif"><span style="line-height:1.5">1) The problem statement says:</span><br></div><div style="font-family:'helvetica neue',helvetica,arial,sans-serif">> First, it often takes longer than 30 days to stage equipment and start actually using the addresses.</div></div></span><span class=""><div dir="ltr"><div style="font-family:'helvetica neue',helvetica,arial,sans-serif"><font color="#212121" face="helvetica neue, helvetica, arial, sans-serif"><br></font>Earlier on, Jason says: <br><div>> "I know I worked very hard to get my recent end-user assignment <span style="line-height:1.5">over 25% by the deadline."<br><br></span></div></div></div></span><div dir="ltr"><div style="font-family:'helvetica neue',helvetica,arial,sans-serif">It is my understanding, Jason, that you're a proponent of some form of verification with teeth - presumably something more aggressive than the 1 year/50% that would still be included if 2015-3 passes muster, but you also concede that you had a difficult time meeting the current 30 day "deadline." <br><br>I could be completely off base because I haven't been following 2015-3 since its inception, but has there been any discussion of a test that sits somewhere between 25%/30 days and 50%/1 year? </div><div style="font-family:'helvetica neue',helvetica,arial,sans-serif"><span class=""><br>2) It seems 4.3.3 in its current incarnation<span> </span><i>doesn't have teeth to begin with </i>as it applies to transfers (which are really the only option in a post-depletion world.) <span style="line-height:1.5">John Curran says: </span><div><br></div></span><div><blockquote type="cite" 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"><span class=""><div>Such a requirement could only be applicable transfers to end-users who were demonstrating <span style="line-height:1.5">their 24-month need using NRPM 4.3.3, and</span><span style="line-height:1.5"> </span><b style="line-height:1.5">there is no clear interpretation for application of </b><b style="line-height:1.5">the "25% immediate utilization rate” language</b><span style="line-height:1.5">. As such, it is not directly considered during </span><span style="line-height:1.5">the process (as elaborated by Richard Jimmerson on the list); therefore none were “reviewed </span><span style="line-height:1.5">and verified explicitly” for that purpose.</span></div><div><br></div></span><div>Note that the language remains applicable (and organizations that attempt to transfer without <span style="line-height:1.5">having immediate utilization do run the risk of number resource fraud), but is not integrated </span><span style="line-height:1.5">into the end-user transfer review process as its extrapolation into that context is unclear. </span><b style="line-height:1.5">This is also why the staff and legal review for draft policy 2015-3 notes - "This policy would </b><b style="line-height:1.5">more closely align with the way staff applies the existing policy in relation to 8.3 transfers.”</b></div></blockquote></div><font face="helvetica neue, helvetica, arial, sans-serif" color="#212121" style="line-height:1.5"><br>[emphasis my own] <br></font><br><font face="helvetica neue, helvetica, arial, sans-serif" color="#212121" style="line-height:1.5">My understanding from these comments is that ARIN has not been doing 30 day check ups on transfers because </font><i style="line-height:1.5">staff has not received direction on how to apply the existing policy to transfers,<span> </span></i><span style="line-height:1.5">which would be the reason behind the staff assessment, "</span><span style="line-height:1.5">This policy would more closely align with the way staff applies<span> </span></span><span style="line-height:1.5">existing </span><span style="line-height:1.5">policy." To that end,</span> then, the policy in its current incarnation is not completely obsolete as some folks have claimed on the PPML. Staff simply don't have direction for application of the utilization rates. <span style="line-height:1.5"><br></span></div><div style="font-family:'helvetica neue',helvetica,arial,sans-serif"><span style="line-height:1.5"><br></span><div><span style="line-height:1.5">It seems there needs to be clearer consensus around what the action of ARIN staff ought to be a) in pursuing verification in the first place re: transfers and b) in cases where verification tests aren't met. </span>Should ARIN be automatically checking in at the 30 day or 1 year mark? If so, what does ARIN do if the 25%/30 days or 50%/1year tests aren't met? <span style="line-height:1.5">Should ARIN revoke the address space? Serve the offender notice? Are either of these ethical in a post-depletion world where folks have paid for address space?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">If the community is to give direction in these areas, should it be included in 2015-3, or in a separate problem statement? <br><br>Feel free to set me straight on all of this 'cause I'm a giant nooooob. </span></div></div><span class="HOEnZb"><font color="#888888">- Alyssa </font></span></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Fri, May 13, 2016 at 4:19 PM John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word">
On May 13, 2016, at 3:38 PM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>> wrote:<br>
</div><div style="word-wrap:break-word"><div>
<blockquote type="cite"><br>
<div>
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
I am highly confused now.
<div><br>
</div>
<div>We have the 25% utilization check which really is the only verifiable </div>
<div>check to rate-limit aggressively optimistic requests.</div>
<div><br>
</div>
<div>On one hand, ARIN does not check this figure. As such the policy </div>
<div>change is a no-op.</div>
<div><br>
</div>
<div>On the other hand the 25% utilization goal remains part of the </div>
<div>policy and having no intention of complying is fraud.</div>
<div><br>
</div>
<div>ARIN could make random checks, or check all of them.</div>
</div>
</div>
</blockquote>
</div></div><div style="word-wrap:break-word"><div><blockquote type="cite">...</blockquote>
</div>
<div>
<div><br>
</div>
<div>Jason - </div>
<div> </div>
<div> Are you referring to assignments or transfers? The above discussion</div>
<div> appears to mix requests of both types.</div>
<div><br>
</div>
<div> ARIN does check that end-user _assignment_ requests meet the</div>
<div> 25% immediate utilization requirement (as called for in the end-user </div>
<div> assignment policy.)</div>
<div><br>
</div>
<div> ARIN does not have clear guidance how the assignment criteria for</div>
<div> 25% immediate use is to be applied to transfers. ARIN can apply the </div>
<div> criteria with respect to transfer requests, but that would require some </div>
<div> additional policy clarity from the community to do so. </div></div></div><div style="word-wrap:break-word"><div>
<div><br>
</div>
<blockquote type="cite">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>So in that respect the policy change is not a no-op.</div>
</div>
</blockquote>
<div><br>
</div></div></div><div style="word-wrap:break-word"><div>
The policy change will not materially affected transfer requests, as noted</div>
<div> above. The change would effect processing of any end-user assignments</div>
<div> requests. (It is probably worth noting that end-users who presently qualify</div>
<div> for assignment of an IPv4 block are being added to a waiting list with a </div>
<div> rather low probability of timely fulfillment.)</div>
<div><br>
</div>
<div>Thanks,</div>
<div>/John</div></div><div style="word-wrap:break-word">
<div><br>
</div>
<div>John Curran</div>
<div>President and CEO</div>
<div>ARIN</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
</div></div></div><span class="">
_______________________________________________<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/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</span></blockquote></div></div>
</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>