Draft Policy 2010-6: Simplified M&A transfer policy

[Member Services]

Draft Policy 2010-6
Simplified M&A transfer policy

On 18 February 2010 the ARIN Advisory Council (AC) selected "Simplified
M&A transfer policy" as a draft policy for adoption discussion on the
PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "105. Simplified
M&A transfer policy". 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, followed by the text that was submitted by
the AC.

Draft Policy 2010-6 is below and can be found at:
https://www.arin.net/policy/proposals/2010_6.htm

You are encouraged to discuss Draft Policy 2010-6 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the 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 2010-6
Simplified M&A transfer policy

Version/Date: 23 February 2010

Policy statement:

Replace section 8.2 with:

8.2. Mergers and Acquisitions

ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions upon receipt of evidence that the new
entity has acquired assets that used the transferred resources from the
current registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.

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, or reclaim resources
as appropriate via the processes outlined in current ARIN policy (for
example, sections 4.6, 4.7, or 12 of the NRPM).

Add "In addition to transfers under section 8.2, " at the beginning of
section 8.3. Transfers to Specified Recipients.

Rationale:

This policy proposal: attempts to simplify the M&A transfer section of
the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy
Meeting (PPM) in Dearborn by clarifying that transfers can occur under
either 8.2 or 8.3 independently; and attempts to address the concerns
raised in the staff policy implementation report at the Dearborn PPM
(https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf)

The idea here is to simply say that ARIN will allow M&A transfers, and
to require the return of any number resources for which there is no
longer a justified need after the acquisition. Preferably that would
happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also
leaves the door open for ARIN to revoke space under NRPM 12 (Resource
Review) if necessary. By implication, future needs that would qualify
the organization for an allocation/assignment would likewise justify
keeping transferred space. In particular, see the language of NRPM
section 12, paragraphs 4 and 4a.

This policy also should dramatically increase the completion rate for
transfer requests, as the evaluation of whether space is efficiently
utilized after the transfer can occur in parallel, completely
independently of the transfer request, and can continue even if the
transfer request is abandoned.

The bulleted lists of acceptable documentation removed from the NRPM
should be maintained by ARIN elsewhere on the website, such as at
https://www.arin.net/resources/request/transfers.html

FAQ:

Q1: What about legacy resources?

A1: Resources subject to the legacy RSA are exempt from a number of ARIN
policies, such as usage justification. However, the recipient of
transferred resources must sign a standard RSA covering the received
resources. At that point, the resources lose their legacy status and
become subject to all ARIN policies, including section 12.

Q2: I'm not sure how NRPM 4.7 will come into play with this policy. Is
the aggregation policy actually applicable here? I understand how 4.6
would work, but just not making the connection with 4.7.

A2: If the organization is returning pieces of space, or, wants to
return multiple disparate chunks and get a single aggregate in the
process, that shouldn't be precluded. NRPM section 4.7 facilitates that.

Timetable for implementation: Immediate


#####


STAFF ASSESSMENT

Proposal: Simplified M&A transfer policy

Proposal Version (Date): 22 Dec 2009

Date of Assessment: 12 Feb 2010

1.	Proposal Summary (Staff Understanding)

ARIN staff understands that this proposal clarifies that a transfer
request can take place either at the time of the actual M&A activity, or
anytime after as long as the proper documentation is provided.  If the
number resources being transferred are not being utilized in accordance
with current ARIN policies, the proposal requires ARIN staff to work
with the requesting organization to return or aggregate the resources as
appropriate, using sections 4.6, 4.7, and 12 of the NRPM.

2. Comments

A.	ARIN Staff Comments

•	This proposal simplifies the M&A transfer criteria and clarifies
several things that may not be apparent with the existing policy.  It
better clarifies that 8.3 transfers are independent of 8.2 transfers and
it clearly states that ARIN will consider transfers after the actual M&A
has occurred as long as the proper documentation is supplied.

•	The proposal adds new, more directive criteria that says if staff sees
that the resources being transferred are not justified under any
existing ARIN policy,  staff must work with the recipient organization
to return, aggregate or reclaim the resources.  Based on staff
experience with M&A transfers, it is possible that these more stringent
requirements could deter organizations with v4 resources from initiating
transfers, thus ensuring that the WHOIS data remains stale and out of
date.  Past experience with M&A transfers has shown us that when we ask
for detailed utilization information and/or ask for unused or
under-utilized address space back, many organizations will simply
abandon their transfers.

B.	ARIN General Counsel

“This proposal poses no significant legal issues.”

3. Resource Impact

•	This policy would have moderate resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees.
•	The significant impact will be felt in the actual application of the
policy due to the fact that ARIN receives many transfer requests where
large blocks of IPv4 addresses are either completely unused or
significantly underused. In turn, staff would have to initiate dozens of
new audits per month as a result of completed transfers.  These audits
and their follow up activity are labor intensive and time consuming,
which will impact staff workload and could necessitate the hiring of
additional staff.

The following would be needed in order to implement:

•	Changes to guidelines
•	Staff training

4. Proposal Text

Replace section 8.2 with:
8.2. Mergers and Acquisitions
ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions upon receipt of evidence that the new
entity has acquired assets that used the transferred resources from the
current registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.

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, or reclaim resources
as appropriate via the processes outlined in current ARIN policy (for
example, sections 4.6, 4.7, or 12 of the NRPM).

Add "In addition to transfers under section 8.2, " at the beginning of
section 8.3. Transfers to Specified Recipients.

Rationale:
This policy proposal: attempts to simplify the M&A transfer section of
the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy
Meeting (PPM) in Dearborn by clarifying that transfers can occur under
either 8.2 or 8.3 independently; and attempts to address the concerns
raised in the staff policy implementation report at the Dearborn PPM
(https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf 



)
The idea here is to simply say that ARIN will allow M&A transfers, and
to require the return of any number resources for which there is no
longer a justified need after the acquisition. Preferably that would
happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also
leaves the door open for ARIN to revoke space under NRPM 12 (Resource
Review) if necessary. By implication, future needs that would qualify
the organization for an allocation/assignment would likewise justify
keeping transferred space. In particular, see the language of NRPM
section 12, paragraphs 4 and 4a.
This policy also should dramatically increase the completion rate for
transfer requests, as the evaluation of whether space is efficiently
utilized after the transfer can occur in parallel, completely
independently of the transfer request, and can continue even if the
transfer request is abandoned.
The bulleted lists of acceptable documentation removed from the NRPM
should be maintained by ARIN elsewhere on the website, such as at
https://www.arin.net/resources/request/transfers.html
FAQ:
Q1: What about legacy resources?
A1: Resources subject to the legacy RSA are exempt from a number of ARIN
policies, such as usage justification. However, the recipient of
transferred resources must sign a standard RSA covering the received
resources. At that point, the resources lose their legacy status and
become subject to all ARIN policies, including section 12.
Q2: I'm not sure how NRPM 4.7 will come into play with this policy. Is
the aggregation policy actually applicable here? I understand how 4.6
would work, but just not making the connection with 4.7.
A2: If the organization is returning pieces of space, or, wants to
return multiple disparate chunks and get a single aggregate in the
process, that shouldn't be precluded. NRPM section 4.7 facilitates that.