[arin-ppml] Policy Proposal -- Normalize Free pool and Transfer justification periods

[Alexander, Daniel]

Are you referring to 2008-5: Dedicated IPv4 block to facilitate IPv6
deployment? If you are, I believe that proposal set aside A /10. Not THE
last /10. The intent would be that blocks reserved for dedicated use would
not be considered in this calculation. -Dan

On 1/23/12 5:29 PM, "Michael Sinatra" <michael+ppml at burnttofu.net> wrote:

>I would support that.
>
>I am at a conference now, but I am trying to remember when we hit the
>requirement for only being able to make micro-allocations for transition
>technologies.  Is that the last /10?
>
>On 1/23/12 2:25 PM, Alexander, Daniel wrote:
>> 
>> Does anyone share my opinion that the soft landing approach of three
>>month
>> allocations was a good idea, but the trigger may have been off? Instead
>>of
>> making all timeframes equal, would it make better sense to just tweak
>> section 4.2.4.4?
>> 
>> Replace:
>> 
>> "When ARIN receives its last /8, by IANA implementing section 10.4.2.2,
>> the length of supply that an organization may request will be reduced.
>>An
>> organization may choose to request up to a 3-month supply of IP
>> addresses." 
>> 
>> With:
>> 
>> "When ARIN's available pool of IPv4 address space is less than an
>> equivalent /8, the length of supply that an organization may request
>>will
>> be reduced. An organization may choose to request up to a 3-month supply
>> of IP addresses."
>> 
>> This was discussed in the past, but may be worth another visit. One
>> concern I have over prop-161 is it eliminates the soft landing that many
>> thought was a good idea.
>> 
>> Dan Alexander
>> Speaking as myself
>> 
>> 
>> On 1/13/12 5:41 PM, "Michael Sinatra" <michael at rancid.berkeley.edu>
>>wrote:
>> 
>>> On 1/13/12 1:06 PM, William Herrin wrote:
>>>> On Fri, Jan 13, 2012 at 1:05 PM, Owen DeLong<owen at delong.com>  wrote:
>>>>>     1. Policy Proposal Name: Normalize Free pool and Transfer
>>>>> justification
>>>>> periods
>>>>
>>>> Hi Owen,
>>>>
>>>> I OPPOSE this proposal in concept and in the particulars.
>>>>
>>>> The sole purpose of needs-based policy, the only one, is to suppress
>>>> frivolous consumption of a limited common resource. With transfers,
>>>> significant and growing sums of money change hands, a fact inherently
>>>> suppresses frivolous use. The need to suppress transfer-based
>>>> consumption with policy, if it exists at all, is consequently much
>>>> less than with free pool consumption.
>>>>
>>>> Just as the regulations which apply to a strip mine are not
>>>> appropriate when applied to a recycler, rules which are perfectly
>>>> rational for free pool allocations can be onerous and excessive for
>>>> transfers. "One size fits all" is entirely inappropriate here.
>>>
>>> Hi Bill:
>>>
>>> My hunch is that your implicit assumption is that the transfer market
>>> currently clears itself efficiently, or some close approximation
>>> thereof.  I disagree with that assumption, even if you don't hold it
>>>:).
>>>  I became especially aware of the problems arising from the uneven
>>> run-out and the issues surround ARIN's current "protection" of its free
>>> pool from the discussions in Philadelphia.  To be honest, there are a
>>> lot of issues that will be resolved once the RIRs' free pools run out
>>> and they transfer markets can operate with (relatively) low distortion.
>>>  I am not interested in speeding the run-out, but I am also not
>>> interested in the continued unnecessary protection of the free pool.
>>>As
>>> Geoff Huston pointed out, IPv4 addresses should be used.  The fact that
>>> Geoff comes from the the APNIC region does not skew my view of his
>>> opinion, BTW.
>>>
>>> Forcing ISPs to run up the price of IPv4 resources on the transfer
>>> market should not be a part of ARIN policy, but it unfortunately is at
>>> this point.  That hurts everyone.
>>>
>>> If it's not obvious already, I support Owen's proposal, and thank him
>>> for submitting it.  (I was going to propose the same thing during the
>>> Philadelphia meeting, but I was busy and/or lazy.  Sorry about that.)
>>>
>>> michael
>>> _______________________________________________
>>> 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.
>