[arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries

Mon Mar 30 10:39:24 EDT 2009

Ray,

I am probablly missreading something in the PDP, but I'm not 
sure how that is possible.  At least without a successful 
petition, I believe the only text that can be discussed for 
adoption is the Draft Policy created by the AC.

On 30 Mar 2009 Ray Plzak wrote:

> The PDP provides for both proposals to be discussed in the PPM.
> 
> Ray
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Sunday, March 29, 2009 11:41 PM
> To: Raul Echeberria
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
> 
> Raul,
> 
> I have no problem discussing the original proposal, but based on the
> PPML discussion to date, and what I've heard in discussions, IMO the
> original unamended proposal has almost no support, and is extremely
> unlikely to gain consensus in the ARIN region.  If anyone favors the
> original proposal, please speak up.
> 
> Based on our estimation of the consensus in the ARIN region, the AC
> amended the proposal to give it a better chance of passing, while
> preserving as much of the original proposal as possible. I would
> welcome additional feedback on the balance we attempted to strike,
> either here or in San Antonio.
> 
> Thanks,
> Scott
> 
> On Mar 29, 2009, at 7:25 PM, 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 follo
> > wing:
> >
> > * 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.
> > rin.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.
> > ny 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.
> _______________________________________________
> 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.

================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======