[arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by Prefix Size - Revised

[Martin Hannigan]

Scott,

That is a belief that we don't share. I think we have another one of
those 'fierce resistance' issues, IMHO. YMMV, of course.

Best,

Martin



On 6/18/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Martin Hannigan wrote:
>> Not in favor. Any change from first and first out based on the current
>> minimum allocation unit is a mid game change which is patently unfair.
>> Automatically changing the allocation size is quite different than
>> requiring a policy proposal _based on current conditions_.
>> Circumstances may chance the popularity of such a proposal. One could
>> argue that it too could be changed. Why not simply change the
>> allocation unit from meet to meet?>
>>
>
> Just addressing the practical, rather than philosophical, question, I
> think things will be changing fast enough at run-out that a maximum
> allocation unit changed by policy every 6 months will not have a
> beneficial effect.
>
> -Scott
>
>> On Thu, Jun 18, 2009 at 1:58 PM, Member Services<info at arin.net> wrote:
>>
>>> Policy Proposal 93
>>> Predicable IPv4 Run Out by Prefix Size
>>>
>>> The proposal originator submitted a revised version of the proposal.
>>>
>>> The AC will review this proposal at their next regularly scheduled
>>> meeting and decide how to utilize the proposal. Their decision will be
>>> announced to the PPML.
>>>
>>> In the meantime, the AC invites everyone to comment on this proposal on
>>> the PPML, particularly their support or non-support and the reasoning
>>> behind their opinion. Such participation contributes to a thorough
>>> vetting and provides important guidance to the AC in their deliberations.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> http://www.arin.net/policy/pdp.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> #####
>>>
>>>
>>> 1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size
>>>
>>> 2. Proposal Originator:  David Farmer
>>>
>>> 3. Proposal Version: 1.1
>>>
>>> 4. Date: 18 June 2009
>>>
>>> 5. Proposal type: new
>>>
>>> 6. Policy term: permanent
>>>
>>> 7. Policy statement:
>>>
>>> Create a new subsection in section 4 of the NRPM;
>>>
>>> 4.X Maximum Allocation or Assignment during and following
>>> Run-Out
>>>
>>> When ARIN receives its last /8, by IANA implementing section
>>> 10.4.2.2, a proportionally decreasing maximum allocation, and
>>> assignment, size will be put into effect.  The maximum
>>> allocation will be the next whole CIDR prefix less than or equal
>>> to one quarter (1/4) of the total ARIN free pool available at the
>>> time of each allocation, but no longer than the applicable
>>> minimum allocation.
>>>
>>> An OrgID may request additional resources when it can
>>> demonstrate it has properly utilized all previous allocations per
>>> applicable policies.  However, the total of all allocations
>>> received within the last three (3) month period and the current
>>> request, cannot exceed the current maximum allocation size.
>>>
>>> This maximum allocation size is applicable to allocations from
>>> the ARIN free pool only, and is explicitly not applicable to
>>> resources received through Transfers to Specified Recipients
>>> per section 8.3, or any other specially designated resources.
>>>
>>> 8. Rationale:
>>>
>>> This proposal is intended to ensure an equitable distribution of
>>> the remaining ARIN free pool resources once additional
>>> resources are no longer abundantly available from IANA.
>>> Equity is achieved by ensuring the available resources are
>>> spread among multiple organizations and that no single
>>> organization may monopolize all of the resources available
>>> through a single request, at least until the maximum allocation
>>> size has been reduced down to the minimum allocation size.
>>>
>>> Reducing the maximum allocation size in proportion to the
>>> amount of resources available should minimize, or possibly
>>> eliminate, the need to fulfill requests with multiple smaller
>>> blocks.
>>>
>>> The maximum allocation size is intended to apply to both ISP
>>> allocations and End-user assignments.
>>>
>>> The current maximum allocation size should be publish in real-
>>> time on the ARIN website, as it may change rapidly as the
>>> ARIN free pool resources are exhausted.
>>>
>>> Following the run-out phase, this proposal provides an
>>> equitable means of distribution of resources if or when
>>> additional resources become available after ARIN has initially
>>> exhausted such resources.  Such as if resources are returned,
>>> recovered by other means, or additional resources are
>>> obtained from IANA.  Further, whenever ARIN receives a
>>> sufficiently large amount of resources, this policy intends for
>>> the maximum allocation size to be increased accordingly.
>>>
>>> The intent of the second paragraph is to normally limit an
>>> organization to a single maximum allocation within a three
>>> month period.  However, saying it that simply opens the policy
>>> to gamesmanship in requesting less than a maximum
>>> allocation.  Requiring a maximum allocation to cover new
>>> requests and all allocations received in the previous three
>>> month period, should eliminate this kind of gamesmanship.
>>>
>>> There is a beneficial side effect of the second paragraph as
>>> stated, in the special situation when the maximum allocation
>>> size is increased, due to ARIN obtaining a sufficiently large
>>> amount of additional resources, an organization may receive
>>> additional resources earlier than the normal three month
>>> period.  But, only in this special situation and when an
>>> organization properly utilizes a previous maximum allocation in
>>> less than three months, may an organization receive additional
>>> resources in less than the normal three month period.
>>>
>>> Other ratios, such as one half (1/2) or one eighth (1/8) could be
>>> considered.  One eighth (1/8) would provide greater assurance
>>> of eliminating the need to use multiple blocks to fulfill requests
>>> and ensure a greater number of organizations receive
>>> resources.  However, one eighth (1/8) is more likely to be seen
>>> as rationing and an attempt to artificially extend the lifetime of
>>> IPv4.  During the ARIN XXIII policy discussion there seemed to
>>> be a consensus that attempts to extend the lifetime of IPv4
>>> resources would be undesirable.  While on the other hand, one
>>> half (1/2) is even less likely to ration resources, it would likely
>>> result in the resource being spread across significantly fewer
>>> organizations and increase the need to use multiple blocks to
>>> fulfill requests.
>>>
>>> Finally, combining the 3 month period with the one quarter
>>> (1/4) ratio provides roughly an annualized equivalent of the
>>> whole ARIN free pool being made available to a single
>>> organization.  While it is not possible for a single organization
>>> to receive the whole ARIN free pool within one year under this
>>> policy, it is a virtual certainty that multiple organization will be
>>> requesting resources, and that the ARIN free pool will not likely
>>> last a full year following the exhaustion of the IANA free pool
>>> anyway.  Therefore, the ratio one quarter (1/4) seems to strike
>>> a balance between making resources available with as little
>>> restriction as possible and ensuring an equitable distribution of
>>> those resources during and following the run-out phase.
>>>
>>> 9. Timetable for implementation:  Immediate
>>>
>>> _______________________________________________
>>> 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.
>>
>