Draft Policy ARIN-2012-8: Aligning 8.2 and 8.3 Transfer Policy

[ARIN]

Draft Policy ARIN-2012-8
Aligning 8.2 and 8.3 Transfer Policy

On 16 August 2012 the ARIN Advisory Council (AC) selected "Aligning 8.2 
and 8.3 Transfer Policy" as a  draft policy for adoption discussion on 
the PPML and at the Public Policy Meeting in Dallas in October.

The draft was developed by the AC from policy proposal "ARIN-prop-175 
Delete Section 8.2." Per the Policy Development Process, the AC 
submitted text to ARIN for a staff and legal assessment prior to its 
selection as a draft policy. Below the draft policy is the ARIN staff 
and legal assessment with the text that was reviewed. The text changed 
after the assessment.

Draft Policy ARIN-2012-8 is below and can be found at:
https://www.arin.net/policy/proposals/2012_8.html

You are encouraged to discuss Draft Policy 2012-8 on the PPML prior to 
the October Public Policy Meeting. Discussion on the list and at ARIN 
XXX will be used by the ARIN Advisory Council to determine community 
consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals 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 ARIN-2012-8
Aligning 8.2 and 8.3 Transfer Policy

Date: 5 September 2012

Policy statement:

Replace the first paragraph of section 8.2 with 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
number 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 IPv4 transfer size is a /24.
* The minimum IPv6 transfer size is a /48.

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.

Timetable for implementation: immediate


##########


ARIN STAFF ASSESSMENT

ARIN-prop-175 Aligning 8.2 and 8.3 Transfer Policy

Date of Assessment: 9 August 2012

1. Summary (Staff Understanding)

This draft policy attempts to align 8.2 transfers with 8.3 and 8.4 
transfers by adding some additional common criteria to 8.2.  It codifies 
the minimum size of address blocks that can be transferred; it requires 
the recipient of a transfer to sign an RSA; and it codifies the 
requirement that the source entity of the transfer be the current 
registrant and not be engaged in a dispute over the registration rights.

2. Comments
A. ARIN Staff Comments

Currently 8.2 is two paragraphs. This proposal modifies and adds to the 
first paragraph. The second paragraph is unchanged. Staff suggests 
leaving the second paragraph out of the proposal.

In the first bullet, where it says "source entity must be the current 
registered holder of the IPv4 address resources", staff suggests 
changing the words "IPv4 address resources" to number resources so that 
it includes IPv4, IPv6, and ASNs.
This proposal contains terminology that is not consistent with 8.3 and 
8.4.  Since policy alignment is one of the main purposes of this 
proposal, staff would suggest the following text for the second bullet 
for consistency, clarity and simplification:

* The recipient must provide evidence that they have acquired assets 
that used the resources. ARIN will maintain an up-to-date list of 
acceptable types of documentation.
The fifth bullet should say "minimum IPv4 transfer size."

B. ARIN General Counsel

Any change in NPRM 8.2 requires heightened legal scrutiny because 
literally hundreds of different disparate proposed 8.2 acquisitions may 
be considered within the next several years under the changed language. 
I have these comments.

First, the use of RSA in this case may need to permit issuance of an 
LRSA,  if the resources are legacy addresses that have not previously 
been the subject of an RSA.
Second, the following new language needs careful community review: "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"
Counsel believes this proposed language requires the 8.2 recipient to 
demonstrate that the number resources are part of an ongoing business 
that is being sold,  and that he number resources are utilized by the 
business. It would be unwise to adopt language in 8.2 that would 
arguably permit an 8.2 transfer where the number resources are the only 
genuinely valuable asset of the business that has any material monetary 
value.

If the number resources are the only genuinely valuable remaining 
material assets of the prior business which is now defunct, the transfer 
has to be considered under NPRM 8.3, not 8.2. If the community agrees 
that is the case, the language does not pose problematic legal issues.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:
Updated guidelines and procedures

4. Proposal Text

ARIN-prop-175 Aligning 8.2 and 8.3 Transfer Policy

Date: 31 July 2012

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