<div><br></div>Yes it is. Are you expecting such a change to happen before or after? The recent fury of v4 policy <span></span>seems geared towards sooner. I think a moratorium is in order except for transfer related policy at this juncture. <div>
<br></div><div>Best,</div><div><br></div><div>-M<</div><div><br></div><div><br><br>On Friday, May 2, 2014, Jeffrey Lyon <<a href="mailto:jeffrey.lyon@blacklotus.net">jeffrey.lyon@blacklotus.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <<a>hannigan@gmail.com</a>> wrote:<br>
><br>
> All,<br>
><br>
> Why should entities get a break on a standard in existence and applied to all for years?<br>
><br>
> And why is tbe aggregate, in examples given, broken? ARIN already applies that to some applicants.<br>
><br>
> No support.<br>
><br>
> Support post exhaustion.<br>
><br>
> Best,<br>
><br>
> Martin<br>
><br>
>> On May 2, 2014, at 20:52, Jimmy Hess <<a>mysidia@gmail.com</a>> wrote:<br>
>><br>
>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <<a>JOHN@egh.com</a>> wrote:<br>
>>>> On Fri, 2 May 2014, Jimmy Hess wrote:<br>
>>><br>
>>> I think 95% is too high, if the previous example of 3 /24's at 100% and<br>
>>> 1 /24 at 75% is realistic.  That works out to 93.75% aggregate utilization,<br>
>>> not quite reaching the bar, so 90% might be a better threshold.<br>
>><br>
>> For 3 /24s   yes.      The difficulty here, is trying to pick a single<br>
>> utilization proportion that works regardless   of the aggregate<br>
>> allocation size, to allow for the loss of the oddball /26 or /27 that<br>
>> can neither be returned nor reused,    perhaps another method is in<br>
>> order  than presuming a single   aggregate utilization criterion  is<br>
>> the most proper.<br>
>><br>
>><br>
>> The more resources you are allocated,  the more opportunity to make<br>
>> your resource allocation efficient.    By the time you get down to a<br>
>> /26,   an entire  /24 is less than 0.4%.<br>
>><br>
>> Aggregate Resources Allocated                     Required Aggregate<br>
>> Utilization criterion<br>
>> more than a /25                                                75%<br>
>> more than a /22,                                               80%<br>
>> more than a /20                                                85%<br>
>> more than a /19                                                90%<br>
>> more than a /18                                                95%<br>
>> more than a /17                                                97%<br>
>> more than a /16                                                98%<br>
>> more than a /15                                                99%<br>
>><br>
>><br>
>><br>
>>><br>
>>> OTOH, /24's are pretty small and maybe that example was just for<br>
>>> illustration.  If people really in this situation have much larger<br>
>>> allocations, they would be easier to slice and dice and thus use (relatively)<br>
>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which<br>
>>> even if contiguous are hard to redeploy for some other use.  75% of a /16<br>
>>> would leave 16384 unused addresses, which could be utilized much more easily.<br>
>>><br>
>>><br>
>>> Personally, I don't much care since my company has its /24, and that's<br>
>>> probably all the IPv4 we'll ever need :-)<br>
>>><br>
>>><br>
>>> --<br>
>>> John Santos<br>
>>> Evans Griffiths & Hart, Inc.<br>
>>> 781-861-0670 ext 539<br>
>><br>
>><br>
>><br>
>> --<br>
>> -JH<br>
>> _______________________________________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> t... but IPv4 is already exhausted?<br>
<br>
--<br>
Jeffrey A. Lyon, CISSP-ISSMP<br>
Fellow, Black Lotus Communications<br>
mobile: (757) 304-0668 | gtalk: <a href="javascript:;" onclick="_e(event, 'cvml', 'jeffrey.lyon@gmail.com')">jeffrey.lyon@gmail.com</a> | skype: <a href="http://blacklotus.net" target="_blank">blacklotus.net</a><br>

</blockquote></div>