[arin-ppml] Updated Text for ARIN-prop-175

[Chris Grundemann]

Hail PPML,

As the primary shepherd for ARIN-prop-175 I am submitting new text
(along with a new title) for this policy (below). I believe (and the
originator has confirmed) that this text covers the intent of the
original proposal. See the updated rationale for more details. Your
feedback (or question) is welcomed and appreciated.

Cheers,
~Chris

----8<----8<----8<----

    Policy Proposal Name: ARIN-prop-175 / Aligning 8.2 and 8.3 Transfer Policy
    Proposal Originator: Harrison Grundy
    Proposal Version: 2
    Date: 10 July 2012
    Proposal type: New
    Policy term: Permanent
    Policy statement:

Update 8.2. Mergers and Acquisitions to the following:

ARIN will consider requests for the transfer of number resources in
the case of mergers and acquisitions under the following conditions:

* The source entity must be the current registered holder of the IPv4
address resources, and not be involved in any dispute as to the status
of those resources.
* The new entity (recipient) must provide evidence that they have
acquired assets that use the resources transferred from the current
registrant (source entity) such that their continued need is
justified. ARIN will maintain an up-to-date list of acceptable types
of documentation.
* The transferred resources will be subject to current ARIN policies.
* The recipient entity must sign an RSA.
* The minimum transfer size is a /24.
* The minimum IPv6 transfer size is a /48.

In the event that number resources of the combined organizations are
no longer justified under ARIN policy at the time ARIN becomes aware
of the transaction, through a transfer request or otherwise, ARIN will
work with the resource holder(s) to return, aggregate, transfer, or
reclaim resources as needed to restore compliance via the processes
outlined in current ARIN policy.

    Rationale:

The base intent here is to lower confusion, raise clarity, and level
the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
specified transfers and not all of the same rules can apply - but many
can and should. Therefor this policy change explicitly adds
requirements which do not exist in 8.2 policy text today: Source must
be the undisputed current registered holder, recipient must sign an
RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
IPv6.

Two requirements from 8.3 are intentionally left out:

First, timed restrictions: Since we are talking about selling
equipment and/or customers here, the fact that you just got addresses
shouldn't matter. And if your network grows after the sale, there's no
reason to stop you from getting more addresses soon after the merger
or acquisition. In fact in many cases, the source entity becomes part
of the recipient in this type of transfer - and they may well need
more addresses before 12 months have passed from the M&A activity.

Second, demonstrating a 24 month need is orthogonal in an M&A
transfer. Either the network purchased is using the addresses or it is
not. Future need is really not part of the equation.

    Timetable for implementation: Immediate

END OF TEMPLATE

-- 
@ChrisGrundemann
http://chrisgrundemann.com