[arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate

[Owen DeLong]

I believe this comment is about 2014-14 (Removing Needs Test from Small IPv4 Transfers) rather than 2014-17.

Can you please confirm that and, if so, repost it in the appropriate thread?

The comments below seem unrelated to 2014-17 (Change Utilization Requirements from last-allocation to total-aggreagate).

Owne

On Jun 10, 2014, at 13:27 , Elvis Velea <elvis at velea.eu> wrote:

> Hi Andrew,
> 
> after an other read of the policy proposal, I now understand that removal of demonstrated need from policy would be a secondary effect. You were actually trying to reduce the load on the ARIN Registration Department's work and reduce approval time.
> 
> I am wondering if ARIN RS staff could actually produce some statistics showing how work-loaded they are (these may already be available online, but I don't know how to get to them).
> 
> Something in the lines of:
> - for the tree sizes discussed here: /24, /20 and /16 + total
>    - number of requests per month
>    - average time until initial response
>    - average number of mails sent in the request by ARIN staff
>    - average time needed for approval
>    - number of requested sizes that were reduced and by how much
> 
> We could then form an opinion on how much would this proposal impact on one side, the organisations that make the requests, and on the other side, ARIN staff.
> Off course, removing the DN from small requests may create more workload for ARIN as number of transfer requests will increase :)
> 
> cheers,
> elvis
> 
> 
> On 10/06/14 01:13, Andrew Dul wrote:
>> Hello,
>> 
>> Thank you to those of you who were able to participate at the PPC last
>> week at NANOG.  Below are some thoughts based on the feedback I heard.
>> 
>> I heard some support for this policy with the caveat that this policy
>> would allow some organizations to apply for address space sooner.  Some
>> postulated that the downside to this policy would be short and likely
>> small for the remainder of the free pool, but it would also make it
>> easier to qualify for transfer space sooner on the transfer market.
>> 
>> I heard that this policy shouldn't impact organizations which currently
>> use the MDN 4.5 policies and that the current MDN policy does not have
>> the same issue as it uses a 80% per site metric to meet utilization
>> requirements.
>> 
>> The other issue which is related to this draft that I heard at the PPC
>> was that ARIN in the past year or so updated its operational practice to
>> more closely follow the current policy of " efficiently utilized all
>> previous allocations" (4.2.4.1) and this is also making harder for some
>> organizations to meet utilization guidelines at the time of request for
>> additional space.  Do other organizations also believe the new
>> operational practice is an issue and the policy should be changed?
>> 
>> As I stated at the PPC, so far I've seen a little support for this and
>> some opposition for this proposal, but at this point not enough to move
>> it forward to a recommended policy based on the current feedback.  If
>> you support this policy, please post your support to the mailing-list
>> otherwise as the policy shepherd I will likely be recommending that the
>> AC abandon this draft at a future AC meeting.
>> 
>> Thanks for your input,
>> Andrew
>> 
>> On 5/16/2014 1:21 PM, ARIN wrote:
>>> ## * ##
>>> 
>>> 
>>> Draft Policy ARIN-2014-17
>>> Change Utilization Requirements from last-allocation to total-aggregate
>>> 
>>> Date: 16 May 2014
>>> 
>>> Problem Statement:
>>> 
>>> Utilization requirements 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.
>>> 
>>> Policy statement:
>>> 
>>> Section 4.2.4.1- Change text to read: "ISPs must have efficiently
>>> utilized all previous allocations, in aggregate, to at least 80% in
>>> order to receive additional space. This includes all space reassigned
>>> to their customers. Please note that until your prior utilization is
>>> verified to meet the 80% requirement, ARIN can neither process nor
>>> approve a request for additional addresses."
>>> 
>>> Section 4.3.6.1- Change text to read: "End-users must have efficiently
>>> utilized all previous assignments, in aggregate, to at least 80% in
>>> order to receive additional space, and must provide ARIN with
>>> utilization details. The prefix size for an additional assignment is
>>> determined by applying the policies found in Section 4.3 of the NRPM."
>>> 
>>> Comments:
>>> 
>>> a. Timetable for implementation: Immediate, possibly through board
>>> action.
>>> b. Per originator, This does not currently extend into MDN (aka
>>> 4.5.4), and I'm not really sure how to reconcile it against 4.5.5, but
>>> OP expressed some concern that there may be undue restrictions there.
>>> It might be better served by a separate proposal.
>>> c. There should probably also be an attempt to clean up the language
>>> between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.