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 ([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.
_______________________________________________
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.
