Jeffrey, Let's be clear without political statements. I suggest we stamp all new v4 proposals "post exhaustion implementation" from here. Aside from the MAU reduction, I can't imagine anything else worthy of the effort.
Agree or not? Best, -M< > On May 2, 2014, at 21:25, Jeffrey Lyon <[email protected]> wrote: > >> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <[email protected]> wrote: >> >> Yes it is. Are you expecting such a change to happen before or after? The >> recent fury of v4 policy seems geared towards sooner. I think a moratorium >> is in order except for transfer related policy at this juncture. >> >> Best, >> >> -M< >> >> >> >>> On Friday, May 2, 2014, Jeffrey Lyon <[email protected]> wrote: >>> >>> On Sat, May 3, 2014 at 10:12 AM, Martin Hannigan <[email protected]> >>> wrote: >>>> >>>> All, >>>> >>>> Why should entities get a break on a standard in existence and applied >>>> to all for years? >>>> >>>> And why is tbe aggregate, in examples given, broken? ARIN already >>>> applies that to some applicants. >>>> >>>> No support. >>>> >>>> Support post exhaustion. >>>> >>>> Best, >>>> >>>> Martin >>>> >>>>>> On May 2, 2014, at 20:52, Jimmy Hess <[email protected]> wrote: >>>>>> >>>>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <[email protected]> wrote: >>>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: >>>>>> >>>>>> I think 95% is too high, if the previous example of 3 /24's at 100% >>>>>> and >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >>>>>> utilization, >>>>>> not quite reaching the bar, so 90% might be a better threshold. >>>>> >>>>> For 3 /24s yes. The difficulty here, is trying to pick a single >>>>> utilization proportion that works regardless of the aggregate >>>>> allocation size, to allow for the loss of the oddball /26 or /27 that >>>>> can neither be returned nor reused, perhaps another method is in >>>>> order than presuming a single aggregate utilization criterion is >>>>> the most proper. >>>>> >>>>> >>>>> The more resources you are allocated, the more opportunity to make >>>>> your resource allocation efficient. By the time you get down to a >>>>> /26, an entire /24 is less than 0.4%. >>>>> >>>>> Aggregate Resources Allocated Required Aggregate >>>>> Utilization criterion >>>>> more than a /25 75% >>>>> more than a /22, 80% >>>>> more than a /20 85% >>>>> more than a /19 90% >>>>> more than a /18 95% >>>>> more than a /17 97% >>>>> more than a /16 98% >>>>> more than a /15 99% >>>>> >>>>> >>>>> >>>>>> >>>>>> OTOH, /24's are pretty small and maybe that example was just for >>>>>> illustration. If people really in this situation have much larger >>>>>> allocations, they would be easier to slice and dice and thus use >>>>>> (relatively) >>>>>> efficiently. 75% of a /24 leaves just 64 addresses (a /26) unused, >>>>>> which >>>>>> even if contiguous are hard to redeploy for some other use. 75% of a >>>>>> /16 >>>>>> would leave 16384 unused addresses, which could be utilized much more >>>>>> easily. >>>>>> >>>>>> >>>>>> Personally, I don't much care since my company has its /24, and that's >>>>>> probably all the IPv4 we'll ever need :-) >>>>>> >>>>>> >>>>>> -- >>>>>> John Santos >>>>>> Evans Griffiths & Hart, Inc. >>>>>> 781-861-0670 ext 539 >>>>> >>>>> >>>>> >>>>> -- >>>>> -JH >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> t... but IPv4 is already exhausted? >>> >>> >>> -- >>> Jeffrey A. Lyon, CISSP-ISSMP >>> Fellow, Black Lotus Communications >>> mobile: (757) 304-0668 | gtalk: [email protected] | skype: >>> blacklotus.net > > Martin, > > My point is that we're already exhausted. We're in Phase 4, it doesn't > get much more exhausted than this. Are you suggesting that we wait > until there is a massive backlog of requests before supporting the > proposal? > > -- > 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.
