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

David Farmer farmer at umn.edu
Mon Mar 30 17:03:29 EDT 2009 

I don't read that Scott was saying that there is no consensus 
with regards to this Draft Proposal.  The AC made edits and 
moved the proposal forward to discussion for adoption, all be it 
with minimum consensus within the AC.  Even though I did not 
support moving this forward either the original or the edited 
versions, to the best of my understanding of the new PDP, the 
process was followed.

This exchange has been in regards to a Discussion Petition, to 
include the original version of the Proposal in the PPM for 
discussion for adoption, and that petition process by no means 
requires a consensus of the community it only requires 10 
people to support the petition.  

Further, personally I see some serious timing issues in the 
PDP process especially around the Discussion Petition.  The 
AC seems to be allowed to Publish Draft Proposals, after the 
deadline for a petition.  This seems problematic to me and 
several others I believe, the AC is collecting several tweaks we 
are going to suggest to the PDP, if you have suggestions send 
them our way.  

So while I do not support the original policy proposal as written, 
or even the edited draft policy, I do think it is unfortunate that 
Raul will not be able to petition, and what Scott proposes 
seems reasonable to me.

I will provide some comments on the text in a separate email.    

On 30 Mar 2009 Martin Hannigan wrote:

> Scott,
> 
> You indicated that there is no consensus with regards to this policy
> advancing.  Why is this policy advancing at all then?  Regardless of
> it being a global policy, there's no requirement to do anything other
> than to run this policy through the process fairly. Failing to succeed
> in that process is a sometimes expected result.
> 
> A perception may be starting to develop that this policy isn't being
> treated equally with regards to other policies I.e. continuing to be
> pushed for discussion without support.
> 
> 
> Best,
> 
> Martin
> 
> 
> 
> On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
> >
> > 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.
> >>>
> >
> > _______________________________________________
> > 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.
> >
> 
> -- 
> Sent from my mobile device
> _______________________________________________
> 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
================================================
=======

More information about the ARIN-PPML mailing list