[arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
David Farmer
farmer at umn.edu
Mon Mar 30 11:00:29 EDT 2009
On 30 Mar 2009 Bill Darte wrote:
> Or, the AC version could be discussed for adoption, but the original
> proposal text could be presented for contrast of course.
I agree, but I don't think that is what Raul was requesting.
> 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.
> >
================================================
=======
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