On Sat, May 3, 2014 at 10:42 AM, Jimmy Hess <[email protected]> wrote: > On Fri, May 2, 2014 at 8:04 PM, Jeffrey Lyon > <[email protected]> wrote: >> Jimmy, >> I would not support scaling this beyond 80% except at the larger >> allocation levels (eg. perhaps /17 and shorter, aggregate). > > The essence of it is, that the 80% utilization criterion is ancient, > and before resource scarcity, before technical improvements such as > unnumbered interfaces, before host-based virtual hosting, and /31s > as point to point links. And a greater utilization requirement may > slow exhaustion. > > The number allows plenty of extra wiggle-room luxury, in addition to > the occasional oddball patch which can't be allocated even in an > efficient planned address allocation strategy, which the free > resources don't exist for, any longer. > > 80% in the aggregate criterion is unfairly strict against resource > holders that have a small total allocation size. And unfairly > lenient against resource holders that have a large total allocation > size. > > And removing the per-allocation utilization requirement would serve to > exacerbate this problem. > > For example, under the current rules a holder of a /10 equivalent, can > call their existing allocations "efficiently utilized", even if > there are most recent allocation, an entire contiguous /20s has been > completely untouched and unused. > > Whereas the resource holder that has a /20, cannot have a single > /23's worth untouched. > > -- > -JH
Jimmy, I think there is room to have that discussion but it should judged on its own merits, independent of a proposal to change the calculation *method*. Thanks, -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: [email protected] | skype: blacklotus.net _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
