[arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
Raul Echeberria
raul at lacnic.net
Mon Mar 30 15:58:00 EDT 2009
Thanks,
Raúl
El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribió:
> Raul,
>
> Given that it's too late to initiate a separate discussion petition
> for the San Antonio meeting, I would like to assure you that I will
> do what I can to make sure that we get feedback from the community
> at that meeting as to the support for the original proposed text, as
> well as for the revised version. If there is a clear community
> consensus in favor of either language, my own personal opinion is
> that we'll be able to move the proposal forward, with any applicable
> edits, at that point.
>
> In order to prepare for such discussion, I'd welcome feedback from
> the PPML on the following questions:
>
> - Do you support the original proposed text of 2009-3, requiring
> return of any reclaimed space to IANA for redistribution? Why or
> why not?
> - Do you support the current modified text of 2009-3, requiring
> return of any reclaimed legacy space, but making optional the return
> of any non-legacy space? Why or why not?
> - Would you support some other revised version of 2009-3? If so,
> what would you want to change? (For example, we could make all
> returns optional, for both legacy and non-legacy space.)
> - If you oppose 2009-3 completely, do you believe that current
> policy is adequate, or would you support some other mechanism to
> allow for the reallocation of IPv4 blocks between RIRs?
>
> Thanks,
> Scott
>
> Member Services wrote:
>> Raul,
>>
>> According to the ARIN Policy Development Process the petition
>> period for
>> the upcoming San Antonio meeting closed on 13 March 2009. The
>> deadline
>> information was posted to PPML earlier this month, see the post:
>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>
>> The draft policy is under discussion, statements of support and
>> opposition are welcome and appreciated. Both the discussion on the
>> PPML
>> and at the Public Policy Meeting will be used by the AC to
>> determine the
>> community consensus regarding adopting this as policy.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> raul at lacnic.net wrote:
>>
>>> Dear all:
>>>
>>> This proposal is a proposal for a global policy. It means that the
>>> same
>>> proposal has to be approved in every region. They can be approved
>>> with
>>> some wording differences, but the spirit of the proposal should be
>>> the
>>> same.
>>>
>>> The proposal was the result of a long collaboration effort of
>>> senior staff
>>> members and board members of all the 5 RIRs and the original text
>>> is the
>>> one that is being considered in every region.
>>>
>>> As far as I know the authors of the proposal were not consulted by
>>> the
>>> ARIN-AC and based on exchanges among the authors in the past few
>>> days, I
>>> can say that in general the feeling is that the changes introduced
>>> by the
>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>
>>> My personal view is that changing the concept of a global policy
>>> proposal
>>> in one RIR means to avoid the approval of the policy. I strongly
>>> encourage
>>> ARIN to put the original proposal under consideration of its
>>> community as
>>> it is being done in the other regions. The proposal can be
>>> approved or
>>> not, That's part of the process, but it doesn't make sense to
>>> approve a
>>> different proposal. IMHO, the AC is able to put forward the new
>>> proposal
>>> for discussion if they consider that it is better, and in that way
>>> to
>>> start the process of discussion of a new global policy proposal.
>>>
>>> I have to confess that dealing with 5 different PDPs is not so
>>> easy. I
>>> don't know if a petition process should be started, If yes, please
>>> take
>>> this email as the request for initiating that process.
>>>
>>> Since this announcement was issued last Monday in the afternoon, I
>>> am not
>>> sure how the business days are counted, but I guess that I am
>>> still within
>>> the valid period.
>>>
>>> However, I think that as a practices, global policy proposals
>>> should not
>>> be changed by any advisory council or policy chair of one region
>>> due to
>>> the impact that to change the proposal produce in the global
>>> process.
>>>
>>>
>>> Best Regards,
>>>
>>> Raúl
>>>
>>>
>>>
>>> ---------------
>>>
>>>
>>>
>>> El 23/03/2009, a las 04:05 p.m., Member Services escribió:
>>>
>>> Draft Policy 2009-3 (Global)
>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>
>>> The following draft policy text is being posted for feedback and
>>> discussion on the Public Policy Mailing List (PPML).
>>>
>>> This draft policy was developed by the ARIN Advisory Council (AC)
>>> from
>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>> Registries. The AC has taken the proposal and developed it into a
>>> draft
>>> policy. The AC was required to submit text to ARIN for staff and
>>> legal
>>> assessment prior to selecting it as a draft policy. The assessment,
>>> along with the text that was assessed, is located below the draft
>>> policy.
>>>
>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
>>> Policy
>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
>>> for
>>> adoption discussion on the PPML and at the upcoming Public Policy
>>> Meeting.
>>>
>>> Draft Policy 2009-3 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2009_3.html
>>>
>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
>>> to the
>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
>>> and at
>>> the Public Policy Meeting will be used by the AC to determine the
>>> community consensus regarding adopting this as policy.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> All of the Draft Policies under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Draft Policy 2009-3 (Global)
>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>
>>> Date: 23 March 2009
>>>
>>> Policy statement:
>>>
>>> This document describes the policy governing the allocation of IPv4
>>> address space from the IANA to the Regional Internet Registries
>>> (RIRs).
>>> This document does not stipulate performance requirements in the
>>> provision of services by IANA to an RIR in accordance with this
>>> policy.
>>> Such requirements should be specified by appropriate agreements
>>> among
>>> the RIRs and ICANN.
>>>
>>> This policy is to be implemented in two phases.
>>>
>>> A. Phase I: Recovery of IPv4 Address Space
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors the
>>> IANA shall establish a mechanism to receive IPv4 address space
>>> which is
>>> returned to it by the RIRs, and hold that address space in a
>>> 'recovered
>>> IPv4 pool'.
>>>
>>> Each RIR through their respective chosen policies and strategies may
>>> recover IPv4 address space which is under their administration. At
>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>> address space recovered, and may return to the IANA any non-legacy
>>> address space recovered, in aggregated blocks of /24 or larger, for
>>> inclusion in the recovered IPv4 pool.
>>>
>>> During Phase I, no allocations will be made from the recovered IPv4
>>> pool. Return of recovered address space (as described above) will
>>> continue throughout Phase II.
>>>
>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors
>>> and a
>>> declaration by the IANA that its existing free pool of unallocated
>>> IPv4
>>> address space is depleted; Global Addressing Policy ASO-001-2
>>> (adopted
>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>> to
>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>
>>> 1. The following definitions apply to this policy:
>>>
>>> a. Recovered Address Space. Recovered address space is that address
>>> space that is returned to an RIR as a result of any activity that
>>> seeks
>>> to reclaim unused address space or is voluntarily returned to the
>>> RIR or
>>> is reclaimed by the RIR as a result of legal action or abuse
>>> determination. Recovered address space does not include that address
>>> space that is reclaimed because of non-payment of contractual fees
>>> whose
>>> reclamation date is less than 1 year at the time of the report.
>>>
>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>> unallocated IPv4
>>> address space held by an RIR to include recovered address space
>>> not yet
>>> returned less that address space that is committed in accordance
>>> with
>>> the RIR's reservation policy and practices.
>>>
>>> c. Aggregated address blocks. Aggregated address blocks are
>>> contiguous
>>> prefixes that can be aggregated on natural bit boundaries.
>>> 10.0.0.0/24
>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
>>> to form
>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>> contiguous prefixes that cannot be combined on a natural bit
>>> boundary to
>>> form an aggregated block.
>>>
>>> d. Legacy address space. IPv4 address space allocated or assigned
>>> prior
>>> to the creation of the RIR.
>>>
>>> 2. Allocation of IPv4 Address Space
>>>
>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>> defined as a 6-month period following 1 March or 1 September in
>>> each year.
>>>
>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>> boundary.
>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>
>>> c. In each allocation period, each RIR may issue one IPv4 request
>>> to the
>>> IANA. Providing that the RIR satisfies the allocation criteria
>>> described
>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>> composed of the smallest possible number of blocks available in
>>> its IPv4
>>> address pool.
>>>
>>> 3. IPv4 Address Space Allocation Criteria
>>>
>>> A RIR is eligible to receive additional IPv4 address space from
>>> the IANA
>>> when the total of its IPv4 address holdings is less than 50% of the
>>> current IPv4 allocation unit, and providing that it has not already
>>> received an IPv4 allocation from the IANA during the current IPv4
>>> allocation period.
>>>
>>> 4. Initial Allocation of IPv4 Address Space
>>>
>>> Each new RIR shall, at the moment of recognition, be allocated one
>>> (1)
>>> allocation unit by the IANA. If an allocation unit is not available,
>>> then the IANA will issue this block as soon as one is available.
>>> This
>>> allocation will be made regardless of the newly formed RIR's
>>> projected
>>> utilization figures and shall be independent of the IPv4 address
>>> space
>>> that may have been transferred to the new RIR by the already
>>> existing
>>> RIRs as part of the formal transition process.
>>>
>>> 5. Reporting
>>>
>>> a. All returned space is to be recorded in an IANA-published log
>>> of IPv4
>>> address space transactions, with each log entry detailing the
>>> returned
>>> address block, the date of the return, and the returning RIR.
>>>
>>> b. All allocated space is also to be recorded in this IANA-
>>> published log
>>> of IPv4 address space transactions, with each log entry detailing
>>> the
>>> address blocks, the date of the allocation and the recipient RIR.
>>>
>>> c. The IANA will maintain a public registry of the current
>>> disposition
>>> of all IPv4 address space, detailing all reservations and current
>>> allocations and current IANA-held address space that is unallocated.
>>>
>>> d) The IANA may make public announcements of IPv4 address block
>>> transactions that occur under this policy. The IANA will make
>>> appropriate modifications to the "Internet Protocol V4 Address
>>> Space"
>>> page of the IANA website and may make announcements to its own
>>> appropriate announcement lists. The IANA announcements will be
>>> limited
>>> to which address ranges, the time of allocation and to which
>>> Registry
>>> they have been allocated.
>>>
>>>
>>>
>>> #####
>>>
>>> ARIN Staff Assessment
>>>
>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
>>> Registries*
>>>
>>> *Proposal Submitted: 30 Jan 2009*
>>>
>>> *Revision Submitted: 05 March 2009*
>>>
>>> *Date of Assessment: 10 March 2009*
>>>
>>> * *
>>>
>>> I. Understanding of the Policy:
>>>
>>> *Staff Understanding of the Proposal:*
>>>
>>> Staff understands that this proposal would be implemented in 2
>>> phases.
>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
>>> address
>>> space (via policy or procedure) to the IANA and have the option of
>>> returning recovered non-legacy address space to the IANA. Phase 2
>>> would
>>> start after the depletion of the IANA free pool and would nullify
>>> the
>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
>>> The
>>> new IANA to RIR policy would allow each RIR to receive approximately
>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
>>> long
>>> as it meets the qualification criteria written in paragraph B2. IANA
>>> will be required to keep a log of all returned IPv4 address space
>>> and
>>> all issued IPv4 address space from the recovered pool, as well as
>>> maintain a public registry of the current disposition of all IPv4
>>> address space.
>>>
>>> II. Comments
>>>
>>> A. ARIN Staff Comments
>>>
>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>> Aggregation, which says “Transactions should only be accepted
>>> under this policy if they are in the interests of the community
>>> (e.g. they improve aggregation or result in a net reclamation of
>>> space).” Because the ARIN region holds the majority of the legacy
>>> address space, and most of the address space returned under this
>>> policy is legacy space, it would mean that there would be no “net
>>> return” of address space to ARIN. ARIN would essentially be
>>> exchanging legacy address space for non-legacy address space, and
>>> returning the legacy address space it received in the exchange to
>>> IANA, resulting in a net loss of address space in ARIN’s available
>>> pool.
>>>
>>> B. ARIN General Counsel Comments:
>>>
>>> The current basis of allocation of numbers was established in
>>> RFC's 2008
>>> and 2050 and is need based. If one region has greater needs than
>>> another, the current policy of IANA does not require equal
>>> distribution
>>> to all RIR's s. This proposed policy would establish a different
>>> political and not needs based method for allocating returned
>>> space. It
>>> would make each RIR an equal recipient of such space. But the
>>> level of
>>> need and economic activity between each RI R is not equal. This
>>> policy
>>> will tend to reallocate returned space away from where it is
>>> recovered,
>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>> current distribution principles. By equating the smaller economies
>>> and
>>> related needs of certain regions to the needs of other regions, like
>>> ARIN, that have greater day to day need, it in effect creates a new
>>> political order of distribution thru equal shares. It is possible
>>> sovereign governments in the regions with greater activity will not
>>> agree to such a revised distribution model. The proposed policy
>>> undermines the legal rationale for distribution.
>>>
>>> The policy also creates a powerful disincentive for any RIR,
>>> including
>>> ARIN, to undertake any financial expenditure of RIR dollars for
>>> programs
>>> intended to obtain returned space for reallocation. Currently ARIN
>>> is
>>> working towards policies such as the LRSA and 2008-6, intended to
>>> encourage returns and use of under utilized resources, but which
>>> cost
>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>> creates such a disincentive by leaving expenditures with a single
>>> RIR,
>>> who cannot benefit except to receive 20% of the returned space
>>> should be
>>> carefully considered.
>>>
>>> Finally, it is likely entities with number resources in the ARIN
>>> region
>>> may be willing to return those resources for uses in the region but
>>> unwilling to do so if 4/5 of such resources will be sent to other
>>> regions.
>>>
>>> III. Resource Impact
>>>
>>> The resource impact of implementing this policy is viewed as
>>> minimal. It
>>> is estimated that this policy could require up to 3 person months of
>>> effort to implement following ratification by the ARIN Board of
>>> Trustees. Because this implementation is not planned, it may preempt
>>> ARIN’s current project deployment schedule. It may require the
>>> following:
>>>
>>> * Modifications to existing registration procedures to include the
>>> handling of returned/reclaimed address space and the process of
>>> requesting additional address space from the IANA.
>>> * Staff training
>>>
>>> Text assessed:
>>>
>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>
>>> *Policy statement:*
>>>
>>> This document describes the policy governing the allocation of IPv4
>>> address space from the IANA to the Regional Internet Registries
>>> (RIRs).
>>> This document does not stipulate performance requirements in the
>>> provision of services by IANA to an RIR in accordance with this
>>> policy.
>>> Such requirements should be specified by appropriate agreements
>>> among
>>> the RIRs and ICANN.
>>>
>>> This policy is to be implemented in two phases.
>>>
>>> A. Phase I: Recovery of IPv4 Address Space
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors the
>>> IANA shall establish a mechanism to receive IPv4 address space
>>> which is
>>> returned to it by the RIRs, and hold that address space in a
>>> 'recovered
>>> IPv4 pool'.
>>>
>>> Each RIR through their respective chosen policies and strategies may
>>> recover IPv4 address space which is under their administration. At
>>> quarterly intervals, each RIR shall return any legacy address space
>>> recovered, and may return any non-legacy address space recovered,
>>> to the
>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>> recovered IPv4 pool.
>>>
>>> During Phase I, no allocations will be made from the recovered IPv4
>>> pool. Return of recovered address space (as described above) will
>>> continue throughout Phase II.
>>>
>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors
>>> and a
>>> declaration by the IANA that its existing free pool of unallocated
>>> IPv4
>>> address space is depleted; Global Addressing Policy ASO-001-2
>>> (adopted
>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>> to
>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>
>>> 1. The following definitions apply to this policy:
>>>
>>> a. Recovered Address Space. Recovered address space is that address
>>> space that is returned to an RIR as a result of any activity that
>>> seeks
>>> to reclaim unused address space or is voluntarily returned to the
>>> RIR or
>>> is reclaimed by the RIR as a result of legal action or abuse
>>> determination. Recovered address space does not include that address
>>> space that is reclaimed because of non-payment of contractual fees
>>> whose
>>> reclamation date is less than 1 year at the time of the report.
>>>
>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>> unallocated IPv4
>>> address space held by an RIR to include recovered address space
>>> not yet
>>> returned less that address space that is committed in accordance
>>> with
>>> the RIR's reservation policy and practices.
>>>
>>> c. Legacy address space. IPv4 address space allocated or assigned
>>> prior
>>> to the creation of the RIR.
>>>
>>> 2. Allocation of IPv4 Address Space
>>>
>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>> defined as a 6-month period following 1 March or 1 September in
>>> each year.
>>>
>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>> boundary.
>>>
>>> c. In each allocation period, each RIR may issue one IPv4 request
>>> to the
>>> IANA. Providing that the RIR satisfies the allocation criteria
>>> described
>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>> composed of the smallest possible number of blocks available in
>>> its IPv4
>>> address pool.
>>>
>>> 3. IPv4 Address Space Allocation Criteria
>>>
>>> A RIR is eligible to receive additional IPv4 address space from
>>> the IANA
>>> when the total of its IPv4 address holdings is less than 50% of the
>>> current IPv4 allocation unit, and providing that it has not already
>>> received an IPv4 allocation from the IANA during the current IPv4
>>> allocation period.
>>>
>>> 4. Initial Allocation of IPv4 Address Space
>>>
>>> Each new RIR shall, at the moment of recognition, be allocated one
>>> (1)
>>> allocation unit by the IANA. If an allocation unit is not available,
>>> then the IANA will issue this block as soon as one is available.
>>> This
>>> allocation will be made regardless of the newly formed RIR's
>>> projected
>>> utilization figures and shall be independent of the IPv4 address
>>> space
>>> that may have been transferred to the new RIR by the already
>>> existing
>>> RIRs as part of the formal transition process.
>>>
>>> 5. Reporting
>>>
>>> a. All returned space is to be recorded in an IANA-published log
>>> of IPv4
>>> address space transactions, with each log entry detailing the
>>> returned
>>> address block, the date of the return, and the returning RIR.
>>>
>>> b. All allocated space is also to be recorded in this IANA-
>>> published log
>>> of IPv4 address space transactions, with each log entry detailing
>>> the
>>> address blocks, the date of the allocation and the recipient RIR.
>>>
>>> c. The IANA will maintain a public registry of the current
>>> disposition
>>> of all IPv4 address space, detailing all reservations and current
>>> allocations and current IANA-held address space that is unallocated.
>>>
>>> d) The IANA may make public announcements of IPv4 address block
>>> transactions that occur under this policy. The IANA will make
>>> appropriate modifications to the "Internet Protocol V4 Address
>>> Space"
>>> page of the IANA website and may make announcements to its own
>>> appropriate announcement lists. The IANA announcements will be
>>> limited
>>> to which address ranges, the time of allocation and to which
>>> Registry
>>> they have been allocated.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>
More information about the ARIN-PPML
mailing list