[arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate
owen at delong.com
Wed Jun 11 02:32:18 EDT 2014
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).
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 :)
> On 10/06/14 01:13, Andrew Dul wrote:
>> 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
>> 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" (220.127.116.11) 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,
>> 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 18.104.22.168- 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 22.214.171.124- 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."
>>> a. Timetable for implementation: Immediate, possibly through board
>>> 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 126.96.36.199 and 188.8.131.52, as they're both currently very clunky.
>> 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:
>> Please contact info at arin.net if you experience any issues.
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML