<div dir="ltr">Maybe fairness was not the word I was looking for...<div><br></div><div>I don't mind large organizations using a more difficult process or requiring greater proof, as was the case with the "less simplified provisions of the existing policy" wrt the ISP slow start policy of the ARIN pool. But slow start as it is currently written does not work well in the transfer market. So instead the specified transfer is granted based on some hand wavy, future looking prediction with unpredictable results.<br></div><div><br></div><div><br></div><div>Everyone should be able to use a process that is predictable, and not dependent on hand wavy future looking projections. </div><div><br></div><div><div><br></div><div>For ARIN Pool space, as an ISP, I could "slow start" if I have no history of utilization, or if my history of utilization is less than my current growth rate.</div><div><br></div><div>In the case of the former I start with a small block (initially /22, later between a /24 and /22).</div><div><br></div><div>In the case of the later, I start with a block size based on my previous year's run rate (initially a 2 year supply, then 3 month supply, and now again a 2 year supply).</div><div><br></div><div>I use up what I got. If I can use it in less time than the time window of space I am allowed to get I can double, if it takes the time window, I get that size again, and if it takes longer than the time window it goes down. (plus rounding up initially or down later.)</div><div><br></div><div>This approach is:</div><div>1. predictable</div><div>2. is based on A. actual demonstrable utilization, and B.the belief that growth will continue</div><div>3. does not require product folks to make some sort of hand wavy future projection</div><div>4. does not require ARIN to engage in back and forth in an attempt to assess the veracity of the projection</div><div>5. does not depend on a future looking belief which in the end cannot be tested, proven or disproven. </div><div>6. does not depend on a claim that if not met can simply be excused with "well, we missed" with no harm no foul.</div><div>7. does not reward more overly optimistic organizations with a greater over supply. </div><div><br></div><div>My desire is to permit everyone (end users and ISPs) to use a predictable, slow start mechanism in the transfer market.</div><div><br></div><div>My suggested transfer text differs essentially in three ways:</div><div><br></div><div>1. Demonstration of past utilization is slightly easier. </div><div> For ARIN IP space you have to show 80% utilization on average, and 50% on each block.</div><div> For the suggested text its 80% on average and growth equal to 50% of the space transferred. </div><div><br></div><div> - the 50% clause is to prevent someone with high utilization from getting IP space, not using it</div><div> and their now lower utilization still being high enough to get more IP space. </div><div> - the problem with this approach is someone may actually be growing, needing, and using the new</div><div> space but have a small historically under utilized block, say a deployment that got delayed. </div><div> - the growth equal to 50% of transferred space clause it to meet the intent of the policy while giving</div><div> flexibility to renumber</div><div><br></div><div>2. Historical growth may not be a good measure because growth may be rate limited waiting on a transfer.</div><div><br></div><div> - Basically the first block is "easy".</div><div><br></div><div> - We have a policy to let those with no space to get a /24</div><div><br></div><div> - For those with efficient utilization they can easily double (but not bigger than a /16). </div><div> If the org never grows it could have up to a 50% surplus after using this policy.</div><div><br></div><div> - Any org growing at less than the doubling rate will have trouble with the 80% on average re-certification, </div><div> and will not be able to get another block. </div><div> They could have up to a 50% surplus if growth stops shortly after using this policy</div><div><br></div><div> - Any org growing at more than the doubling rate needs and is using the space, and should be able to get more.</div><div><br></div><div> - An org's who is doubling in size, will have trouble with the 80% on average re-certification, when the growth</div><div> rate drops below doubling. </div><div> They may have up to a 50% surplus if growth stops right after they use this policy for the last time.</div><div><br></div><div> - An org's who growth rate is greater than a /16 over the time window (currently suggested as 6 months) </div><div> may have up to a /16 surplus if they if growth stops right after they use this policy for the last time.</div><div><br></div><div>3. An organization will also have to a pay fee for the IP space</div><div> - this is likely a significant deterrent for small organizations </div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 3:35 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">Respectfully I reject your premise on the fairness.<div><br></div><div>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><br></div><div>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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Owen</div></font></span><div><div class="h5"><div><br></div><div><div><blockquote type="cite"><div>On Feb 7, 2017, at 12:04 , Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>> wrote:</div><br class="m_861252537914913002Apple-interchange-newline"><div><div dir="ltr"><div>I support B. </div><div><br></div><div>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><br></div><div>I oppose A and C as they are unfair, </div><div><br></div>A. <div> - unfairly penalizes large organizations that need more than a /16<div> - unfairly penalizes organizations growing faster than double their current holding</div></div><div> (especially new organizations that started with a /24 and have a growth rate greater than 512 customer per year)</div><div><br></div><div>C.</div><div> - unfairly penalizes large organizations that need more than a /16</div><div> - unfairly penalizes organizations growing faster than double their current holding</div><div> - unfairly does not penalizes organizations growing faster than double their current holding so long as they need less than a /16</div><div><br></div><div><br></div><div>A > B or B > A?</div><div><br></div><div>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><br></div><div> 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><br></div><div>__Jason</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</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">We have a few options on the table and only a few voices in the discussion...<div><br></div><div>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><br></div><div><br></div><div>1. demonstrate 80% utilization on average for all your IP space</div><div>2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years</div><div>2.1. this is limited to a /16</div><div><br></div><div>A. you can use this policy once every 6 months</div><div><br></div><div>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><br></div><div>C. you can use this policy to transfer a total of up to a /16</div><div><br></div><div>Where do you stand on A, B or C?</div><div><br></div><div>__Jason</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <span dir="ltr"><<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</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">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">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">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><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">Thanks,</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">Scott</span></div></div><div class="m_861252537914913002m_-8135647067385460089HOEnZb"><div class="m_861252537914913002m_-8135647067385460089h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 2:22 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">Simple to resolve for the 6-month horizon —<br>
<br>
… Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. …<br>
<span class="m_861252537914913002m_-8135647067385460089m_-5598678503246233445HOEnZb"><font color="#888888"><br>
Owen<br>
</font></span><div class="m_861252537914913002m_-8135647067385460089m_-5598678503246233445HOEnZb"><div class="m_861252537914913002m_-8135647067385460089m_-5598678503246233445h5"><br>
> On Feb 3, 2017, at 07:19 , David R Huberman <<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>> wrote:<br>
><br>
><br>
> I thought of a possible problem with the anti-abuse language -- all versions of it. Let me talk it out.<br>
><br>
> An organization has a /19.<br>
> It has growing products, and wants another /19 for its 1 or 2 year need.<br>
> It wants to avail itself of the new language.<br>
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.<br>
><br>
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.<br>
><br>
> 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>
><br>
><br>
> (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>
> ______________________________<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>
<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.</div></div></blockquote></div><br></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" 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.<span class="m_861252537914913002HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="m_861252537914913002HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_861252537914913002m_-8135647067385460089gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="font-family:arial"><font color="#555555" face="'courier new', monospace">______________________________<wbr>_________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@goog<wbr>le.com</a>|<a href="tel:(571)%20266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_861252537914913002gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="font-family:arial"><font color="#555555" face="'courier new', monospace">______________________________<wbr>_________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@<wbr>google.com</a>|<a href="tel:(571)%20266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>
</div></blockquote></div><br></div></div></div></div></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>