<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="">Respectfully I reject your premise on the fairness.<div class=""><br class=""></div><div class="">Neither A, nor C prevent large organizations from getting more, they merely require that they use other less simplified provisions of the existing policy.</div><div class=""><br class=""></div><div class="">I think what I support is sort of a hybrid between A and C in that I believe you should be able to use the policy to transfer as often as you want, so long as your transfers within any 6 month period under this policy don’t exceed a /16. You’d still be able to transfer a /16 under this policy and then use other existing policies if you needed more.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 7, 2017, at 12:04 , Jason Schiller <<a href="mailto:jschiller@google.com" class="">jschiller@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I support B. </div><div class=""><br class=""></div><div class="">It puts added work on those who need more than a /16, or have a growth rate more than doubling every half yeah, but does not prevent organizations who need IP addresses from getting them.</div><div class=""><br class=""></div><div class="">I oppose A and C as they are unfair, </div><div class=""><br class=""></div>A. <div class=""> - unfairly penalizes large organizations that need more than a /16<div class=""> - unfairly penalizes organizations growing faster than double their current holding</div></div><div class=""> (especially new organizations that started with a /24 and have a growth rate greater than 512 customer per year)</div><div class=""><br class=""></div><div class="">C.</div><div class=""> - unfairly penalizes large organizations that need more than a /16</div><div class=""> - unfairly penalizes organizations growing faster than double their current holding</div><div class=""> - unfairly does not penalizes organizations growing faster than double their current holding so long as they need less than a /16</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">A > B or B > A?</div><div class=""><br class=""></div><div class="">I can't decide if A is less unfair because there is no carve out for organizations that need less than a /16. On one hand those needing less than a /16 are not treated unfairly as a special class, but as a result the number of organizations who need IP addresses that are rate limited is greater.</div><div class=""><br class=""></div><div class=""> Or if C is less unfair because it is unfair to have a carve out for the organization that need less than a /16 for exactly the opposite reasons.</div><div class=""><br class=""></div><div class="">__Jason</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <span dir="ltr" class=""><<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">We have a few options on the table and only a few voices in the discussion...<div class=""><br class=""></div><div class="">I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">1. demonstrate 80% utilization on average for all your IP space</div><div class="">2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years</div><div class="">2.1. this is limited to a /16</div><div class=""><br class=""></div><div class="">A. you can use this policy once every 6 months</div><div class=""><br class=""></div><div class="">B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.</div><div class=""><br class=""></div><div class="">C. you can use this policy to transfer a total of up to a /16</div><div class=""><br class=""></div><div class="">Where do you stand on A, B or C?</div><div class=""><br class=""></div><div class="">__Jason</div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <span dir="ltr" class=""><<a href="mailto:scottleibrand@gmail.com" target="_blank" class="">scottleibrand@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text. I would be equally fine with this text ("N<span style="font-size:12.8px" class="">o more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("</span><span style="color:rgb(80,0,80);font-size:12.8px" class="">An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")</span><div class=""><span style="color:rgb(80,0,80);font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="color:rgb(80,0,80);font-size:12.8px" class="">Thanks,</span></div><div class=""><span style="color:rgb(80,0,80);font-size:12.8px" class="">Scott</span></div></div><div class="m_-8135647067385460089HOEnZb"><div class="m_-8135647067385460089h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <span dir="ltr" class=""><<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simple to resolve for the 6-month horizon —<br class="">
<br class="">
… Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. …<br class="">
<span class="m_-8135647067385460089m_-5598678503246233445HOEnZb"><font color="#888888" class=""><br class="">
Owen<br class="">
</font></span><div class="m_-8135647067385460089m_-5598678503246233445HOEnZb"><div class="m_-8135647067385460089m_-5598678503246233445h5"><br class="">
> On Feb 3, 2017, at 07:19 , David R Huberman <<a href="mailto:daveid@panix.com" target="_blank" class="">daveid@panix.com</a>> wrote:<br class="">
><br class="">
><br class="">
> I thought of a possible problem with the anti-abuse language -- all versions of it. Let me talk it out.<br class="">
><br class="">
> An organization has a /19.<br class="">
> It has growing products, and wants another /19 for its 1 or 2 year need.<br class="">
> It wants to avail itself of the new language.<br class="">
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.<br class="">
><br class="">
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.<br class="">
><br class="">
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?<br class="">
><br class="">
><br class="">
> (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)<br class="">
> ______________________________<wbr class="">_________________<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" target="_blank" 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" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
> Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">
<br class="">
______________________________<wbr class="">_________________<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" target="_blank" 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" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.</div></div></blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<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" target="_blank" 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" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<span class="HOEnZb"><font color="#888888" class=""><br class=""></font></span></blockquote></div><span class="HOEnZb"><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="m_-8135647067385460089gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace" class=""><div class=""><span style="font-family: arial;" class=""><font color="#555555" face="'courier new', monospace" class="">______________________________<wbr class="">_________________________<br class=""></font><div class=""><font face="'courier new', monospace" class="">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@<wbr class="">google.com</a>|<a href="tel:(571)%20266-0006" value="+15712660006" target="_blank" class="">571-266-0006</a></font></div><div class=""><font face="'courier new', monospace" class=""><br class=""></font></div></span></div></font></div>
</font></span></div></div>
</blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace" class=""><div class=""><span style="font-family: arial;" class=""><font color="#555555" face="'courier new', monospace" class="">_______________________________________________________<br class=""></font><div class=""><font face="'courier new', monospace" class="">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>|571-266-0006</font></div><div class=""><font face="'courier new', monospace" class=""><br class=""></font></div></span></div></font></div>
</div>
</div></blockquote></div><br class=""></div></body></html>