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

Bill Darte BillD at cait.wustl.edu
Mon Mar 30 10:53:36 EDT 2009


Or, the AC version could be discussed for adoption, but the original proposal text could be presented for contrast of course.

bs

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ray Plzak
> Sent: Monday, March 30, 2009 9:45 AM
> To: David Farmer
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> A petition would be necessary.
> 
> Ray
> 
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Monday, March 30, 2009 10:39 AM
> To: Ray Plzak
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> 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
> ================================================
> =======
> 
> 
> _______________________________________________
> 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