[ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs

[Owen DeLong]

DOH!!!  Maybe you guys should set the Reply-to on those. ;-)

Owen

On Aug 17, 2007, at 8:42 AM, Member Services wrote:

> Owen,
> Your response only came back to Member Services (info at arin.net).  
> Please post to PPML.
>
> Thanks!
> Erika Goedrich
> ARIN Member Services
>
> Owen DeLong wrote:
>> I am neutral on this policy.  I don't support it, but, I have no   
>> strong opposition
>> to it, either.
>> However, I do wish to address some of the items contained in the   
>> narrative.
>> First, I think it is absolutely essential that each RIR  
>> communicate  the impending
>> IPv4 free pool exhaustion to their constituency.  I believe this  
>> is  happening and
>> I do not believe this policy would affect that in any way.
>> Second, the assertion that current policy is a globally  
>> coordinated  policy
>> is absurd.  Each RIR sets its own policy for allocation and  
>> assignment
>> today.  All that is globally coordinated currently is the policy  
>> on how
>> the IANA allocates to RIRs.  While I don't mind dividing the last 5
>> /8s evenly amongst the 5 RIRs (perhaps this policy should state
>> the last N /8s where N is the current number of RIRs at the time N
>> is reached, but, I don't anticipate N changing from 5 between now
>> and then), I don't see the effect of this as being significantly   
>> different
>> from what will likely happen naturally in the course of current  
>> IANA- >RIR
>> policy.
>> What this policy achieves is that each RIR clearly knows when it has
>> received its last /8 from the IANA and knows which /8 that is.  If we
>> continue to follow current IANA->RIR practices, I believe that the  
>> IANA
>> and RIRs will have a pretty good idea when that point is reached as
>> well, with the possible surprise that some RIRs may receive one more
>> allocation round than they expected to.
>> Personally, I am much more concerned about the RIR policies to deal
>> with RIR Free Pool exhaustion process.  I'm pretty sure that IANA and
>> RIRs can handle the IANA free pool exhaustion appropriately under
>> existing policy, but, I don't regard this policy as harmful to  
>> that  process.
>> Owen
>> On Aug 17, 2007, at 8:19 AM, Member Services wrote:
>>> ARIN received the following policy proposal. In accordance with  
>>> the  ARIN
>>> Internet Resource Policy Evaluation Process, the proposal is being
>>> posted to the ARIN Public Policy Mailing List (PPML) and being   
>>> placed on
>>> ARIN's website.
>>>
>>> The ARIN Advisory Council (AC) will review this proposal at their  
>>> next
>>> regularly scheduled meeting. The AC may decide to:
>>>
>>>    1. Accept the proposal as a formal policy proposal as  
>>> written.  If the
>>> AC accepts the proposal, it will be posted as a formal policy  
>>> proposal
>>> to PPML and it will be presented at a Public Policy Meeting.
>>>
>>>    2. Postpone their decision regarding the proposal until the next
>>> regularly scheduled AC meeting in order to work with the author.   
>>> The AC
>>> will work with the author to clarify, combine or divide the   
>>> proposal. At
>>> their following meeting the AC will accept or not accept the  
>>> proposal.
>>>
>>>    3. Not accept the proposal. If the AC does not accept the  
>>> proposal,
>>> the AC will explain their decision. If a proposal is not  
>>> accepted,  then
>>> the author may elect to use the petition process to advance their
>>> proposal. If the author elects not to petition or the  petition  
>>> fails,
>>> then the proposal will be closed.
>>>
>>> The AC will assign shepherds in the near future. ARIN will  
>>> provide the
>>> names of the shepherds to the community via 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 Internet Resource Policy Evaluation Process can be found  
>>> at:
>>> http://www.arin.net/policy/irpep.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs
>>>
>>> Author: JPNIC IPv4 countdown policy team;
>>>                    Akinori MAEMURA
>>>                    Akira NAKAGAWA
>>>                    Izumi OKUTANI
>>>                    Kosuke ITO
>>>                    Kuniaki KONDO
>>>                    Shuji NAKAMURA
>>>                    Susumu SATO
>>>                    Takashi ARANO
>>>                    Tomohiro FUJISAKI
>>>                    Tomoya YOSHIDA
>>>                    Toshiyuki HOSAKA
>>>
>>> Proposal Version: 2
>>>
>>> Submission Date: 2007/08/17
>>>
>>> Proposal type: new
>>>
>>> Policy term:renewable
>>>
>>> Policy statement:
>>>
>>> 1) Distribute a single /8 to each RIR at the point when new IANA  
>>> free
>>>     pool hits 5 */8. This date is defined as "IANA Exhaustion Date".
>>>
>>> 2) It should be completely left up to each RIR communities to  
>>> define a
>>>     regional policy on how to distribute the remaining RIR free   
>>> pool to
>>>     LIRs within their respective regions after "IANA Exhaustion  
>>> Date".
>>>
>>>     Note 1: It is fine for an RIR to continue operations with the
>>>             existing policy if that is the consensus decision of the
>>>             respective RIR community.
>>>
>>>     Note 2: Address recovery and re-distribution of recovered  
>>> address
>>>             space is another important measure for  
>>> considerations, but
>>>             should be treated as a separate policy proposal from
>>>             distribution of new IANA pool.
>>>
>>> 3) RIRs should provide an official projection on IANA Exhaustion  
>>> Date
>>>     to the community through their website, at their Policy Meetings
>>>     and through any other effective means.
>>>
>>>
>>> Rationale:
>>> [current problem]
>>> There are two major issues in terms of address management if no   
>>> measures
>>> are taken for IPv4 address exhaustion.
>>>
>>> 1) Continue applying a global coordinated policy for  
>>> distribution  of the
>>>     last piece(s) of RIR's unallocated address block does not  
>>> match  the
>>>     reality of the situation in each RIR region.
>>>
>>>     Issues each RIR region will face during the exhaustion  
>>> period  vary by
>>>     region as the level of development of IPv4 and IPv6 are widely
>>>     different. As a result, applying a global co-ordinated  
>>> policy  may not
>>>     adequately address issues in a certain region while it could  
>>> be  work
>>>     for the others.
>>>
>>>     For example, in a region where late comers desperately need even
>>>     small blocks of IPv4 addresses to access to the IPv4 Internet, a
>>>     policy that defines the target of allocations/assignments of  
>>> IPv4
>>>     address space to be late comers would be appropriate in such   
>>> region.
>>>     This would allow availablilty of IPv4 address space for such
>>>     requirements for more years.
>>>
>>>     Another example comes from difference in IPv6 deployment rate.
>>>     For a region where IPv6 deployment rate is low, measures may be
>>>     necessary to prolong IPv4 address life for the existing   
>>> business as
>>>     well as for new businesses until networks are IPv6 ready. Some
>>>     regions may have strong needs to secure IPv4 address space for
>>>     translators.
>>>
>>>     A globally coordinated policy which addresses all the issues   
>>> listed
>>>     above to meet the needs for all RIR regions may result in  
>>> not  solving
>>>     issues in any of the regions.
>>>
>>> 2) LIRs and stakeholders remain unprepared for the situation if   
>>> they are
>>>     not informed
>>>
>>>     If LIRs and the community are uninformed of the exhaustion,  
>>> their
>>>     services and networks remain unprepared to face the  
>>> situation  at the
>>>     time of exhaustion.
>>>
>>> [Objective of the proposal]
>>> This proposal seeks to provide the following solutions to the  
>>> problems
>>> listed above.
>>>
>>> 1) RIR community should be able to define their own regional   
>>> policies on
>>>     how to assign the last piece(s) of allocation block in order to
>>>     address their own regional issues during the exhaustion period.
>>>
>>> 2) RIRs should provide official projection of the date when LIRs   
>>> will be
>>>     able to receive the allocations under the current criteria. The
>>>     criteria should remain consistent until this date in order  
>>> to  avoid
>>>     confusion.
>>>
>>> [Pros and Cons]
>>> Pros:
>>> + It allows each RIR community to define a policy on how to  
>>> distribute
>>>    the last piece(s) of allocations which best matches their   
>>> situation.
>>>
>>> + It helps LIR better informed of the date when they are able to   
>>> receive
>>>    allocations from RIRs under the current criteria and prepare  
>>> for  the
>>>    event.
>>>
>>> Cons:
>>> + Concerns could be raised about allocating a fixed size to all  
>>> RIRs,
>>>    that it artificially fastens the consumption rate of some RIR   
>>> regions.
>>>    However, its impact is kept to minimum by keeping the  
>>> allocation  size
>>>    to a single /8 which makes merely 3-4 months difference.
>>>
>>> + Concerns could be raised that explicitly allowing regional  
>>> policies
>>>    will encourage RIR shopping. However, this should not happen  
>>> if the
>>>    requirements within each region is adequately reflected in  
>>> each  RIR's
>>>    policy through PDP. RIR may also chose to add criteria to   
>>> prevent LIRs
>>>    from other regions submitting such requests.
>>>
>>>
>>> Timetable for implementation:
>>> Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy.
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the   
>>> ARIN Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>>> ARIN  Member Services
>>> Help Desk at info at arin.net if you experience any issues.