[arin-ppml] Policy discussion - Method of calculating utilization

[Scott Leibrand]

This seems to me like a reasonable operational practice for ARIN to use
to help prevent a run on the remaining free pool from organizations with
large quantities of existing space.

Are you trying to change this before free pool runout, or are you concerned
with making needs justification a bit easier for transfers once the free
pool is exhausted? I would support the latter, but not the former.

-Scott

On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
wrote:

> Friends, Colleagues,
>
> A couple of years ago I brought up an issue I had run into where the
> utilization requirement for new requests is being calculated on a per
> allocation basis rather than in aggregate. For example, if an
> organization has 4 x /22 and 3 of them are utilized 100% and the
> fourth utilized at 75%, that request would be denied. This is a bit
> out of balance as an organization with a single /20 utilized at 80%
> would have less efficient utilization but would be eligible to request
> additional space.
>
> The last time this was discussed it sounded as if the community would
> support a policy proposal to change this calculation to be considered
> in aggregate vs. per assignment. Does this remain the case?
>
> Thanks,
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
> skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>


-- 
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/f5fd9dca/attachment.htm>