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

[Martin Hannigan]

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