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

One more note.

I wasn't clear about if this is a global policy or a regional ARIN
policy - it is intended to be a global policy as it defines distribution
of IANA blocks.

izumi

Izumi Okutani さんは書きました:
> Thanks for your input Marla, and apologies for taking some time to reply.
> 
> Just to clarify our intention, we think this will help reduce confusion
> for distribution of the last few IANA blocks.
> 
> For example, if ARIN was planning to request for 2*/8 next month, but
> APNIC (or any other RIR) comes just before and IANA pool runs out as a
> result, ARIN will be left with 0 additional block it was counting on.
> This will also affect distribution of the last ARIN block within the
> region as you don't know which would be the last block until the last
> minute.
> 
> By pre-defining what each RIR will receive in advance (with the size
> which does not affect each RIR's exhaustion date), we think it helps
> solve this issue and minimize confusion at the time of exhaustion.
> 
> I see your point about section 2, so I'll remove it from my slides at
> the meeting. thanks. I'd also be happy to remove section 3 if it's an
> obvious fact which doesn't need to be shared.
> 
> 
> izumi
> 
> Azinger, Marla さんは書きました:
>> Here are my two cents:
>>
>> -I don't support this.  Let it run out.  Write a policy figuring out what IANA does once contiguous requests cant be met.
>>
>> -Section 2 needs to be removed.  It isn't policy and more a suggestion/guidance of things that RIR's should think about doing.
>> -Section 3 needs to be removed.  It isn't policy and more a staff requirement for RIR's.
>>
>> Cheers!
>> Marla Azinger
>> Frontier Communications
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Member Services
>> Sent: Friday, August 17, 2007 8:20 AM
>> To: ppml at arin.net
>> Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to
>> RIRs
>>
>>
>> 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.
>> _______________________________________________
>> 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.
> 
> _______________________________________________
> 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.