<div dir="ltr">If we did this, I suspect what would happen for the foreseeable future is that all reclaimed space would be assigned out as /24s to everyone willing to accept a /24 to fulfil their request. Anyone who insisted on a larger block would get nothing, so there'd be no incentive to do so. That would have the effect of giving a small number of space to the largest number of organizations possible, which could be considered a feature or a bug (increasing the number of routes that have to go into the global BGP table).<div><br></div><div>-Scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 9:00 AM Jimmy Hess <<a href="mailto:mysidia@gmail.com">mysidia@gmail.com</a>> wrote:<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 dir="ltr"><div dir="ltr">On Mon, May 13, 2019 at 9:39 AM Tom Pruitt <<a href="mailto:tpruitt@stratusnet.com" target="_blank">tpruitt@stratusnet.com</a>> wrote:</div><div class="gmail_quote"><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_6384925539458160585gmail-m_-6301417524868978775WordSection1"><p class="MsoNormal">If those organizations were watching the list, and moving up, it is likely that they have made </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_6384925539458160585gmail-m_-6301417524868978775WordSection1"><p class="MsoNormal">business decisions based on that data with the assumption
 that they would get an allocation </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_6384925539458160585gmail-m_-6301417524868978775WordSection1"><p class="MsoNormal">at some point.   I believe the proposed allocation limit is being discussed as a method to </p></div></div></blockquote><div><br></div><div>Such speculations would not have been a very prudent to rely upon.  Anyway: there is likely</div><div>to not ever be a full /7,  so a /7 cannot be allocated, for example.  Some "natural" limit exists, </div><div>whether exactly known or not,  and there's no guarantee of anyone on the list ever</div><div>eventually getting filled.</div><div><div><br></div></div><div>Perhaps it should simply be that when ordering the wait list ---  All requests whether new or</div><div>still pending each XX day period,  say over 90 days will be considered simultaneously </div><div>on one date,  and in addition to being ordered by request date,  the requests are sorted</div><div>into buckets based on the number of total IP addresses requested, e.g.:</div><div><br></div><div>All requests that can be satisfied at their minimum size by a /24, /23, /22, /21, or less (for example) </div><div>in the entire waiting  list, and those larger being processed today shall each be sorted into a</div><div>corresponding "bucket"   with other requests that can be satisfied at that size.</div><div><br></div><div>All requests from every bucket of smaller sized requests shall be satisfied in at least their</div><div>minimum size  before considering requests in any buckets of larger size.</div><div><br></div><div><br></div><div>In this manner a "larger request" like a /20 could in theory be made,  but</div><div>even if that request was pending for  2 years:   all the  new  requests that can be</div><div>satisfied by /24 or less,  then /23 or less,  then /22 or less, then /21 or less  should </div><div>be considered and filled first.</div><div><br></div><div>So to have any chance of filling a massive allocation,  then that should mean the</div><div>waiting list has become essentially empty.....</div><div><br></div><div>--<br></div><div>-JH </div></div></div>
_______________________________________________<br>
ARIN-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="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://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.<br>
</blockquote></div>