[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