[arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers

[Elvis Velea]

Hi Owen,

you were right, I mixed two different policy proposal numbers.

The stats I was asking for were for the 2014-14 policy proposal.

Kind regards,
Elvis

On 11/06/14 08:32, Owen DeLong wrote:
> 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.