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