Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[ARIN]

Draft Policy ARIN-2015-9
Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 
transfers of IPv4 netblocks

On 17 September 2015 the ARIN Advisory Council (AC) accepted 
"ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, 
and 8.4 transfers of IPv4 netblocks" as a Draft Policy.

Draft Policy ARIN-2015-9 is below and can be found at:
https://www.arin.net/policy/proposals/2015_9.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2015-9 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

    * Enabling Fair and Impartial Number Resource Administration
    * Technically Sound
    * Supported by the Community

The ARIN Policy Development Process (PDP) 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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Draft Policy ARIN-2015-9
Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 
transfers of IPv4 netblocks

Date: 23 September 2015

Problem statement:

The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding 
transfer of IPv4 netblocks from one organization to another are 
currently a hindrance in ensuring database accuracy. In practice, ARIN 
staff are utilizing those polices to refuse to complete database updates 
which would reflect an accurate transfer of control / utilization of 
netblocks in cases where ARIN doesn't agree that the recipient 
organization has need, or more often where the recipient organization 
bypasses the ARIN registry entirely in order to secure the needed IPv4 
netblocks in a more timely fashion directly from the current holder. 
Additionally, the 8.1 introduction section includes a perceived "threat" 
of reclaim which serves as a hindrance to long-term resource holders 
approaching ARIN with database updates when transferring resources. The 
result is that the data visible in ARIN registry continues to become 
more inaccurate over time.

Policy statement:

This proposal is for the following language changes in the respective 
NRPM sections in order to eliminate all needs-based evaluation for the 
respective transfer type, and allow transfers to be reflected in the 
database as they occur following an agreement of transfer from the 
resource provider to the recipient.

Section 8.1 Principles:

- Strike the 3rd paragraph which begins with "Number resources are 
issued, based on justified need, to organizations. . ." since it mostly 
reiterates other sections of ARIN policy. All transfers are subjected to 
those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing 
this paragraph removes the perceived "threat" of reclaim which serves as 
a hindrance to long-term resource holders approaching ARIN with database 
updates, since in practice ARIN has not been forcibly reclaiming IP 
resources assigned to "failed businesses."

Section 8.2 Mergers and Acquisitions:

- Change the 4th bullet from:

"The resources to be transferred will be subject to ARIN policies."

to:

"The resources to be transferred will be subject to ARIN policies, 
excluding any policies related to needs-based justification or 
inspection of current or future utilization rate."

- Remove entirely the last paragraph which reads "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 or transfer resources as needed to restore 
compliance via the processes outlined in current ARIN policy."

Section 8.3 Transfers between Specified Recipients within the ARIN Region:

- Change the first bullet under "Conditions on recipient of the 
transfer" from:

"The recipient must demonstrate the need for up to a 24-month supply of 
IP address resources under current ARIN policies and sign an RSA."

to:

"The recipient must sign an RSA."

- Change the 2nd bullet under "Conditions on recipient of the transfer" 
from:

"The resources to be transferred will be subject to ARIN policies."

to:

"The resources to be transferred will be subject to ARIN policies, 
excluding any policies related to needs-based justification or 
inspection of current or future utilization rate."

Section 8.4 Inter-RIR Transfers to Specified Recipients:

- Change the introductory language from:

"Inter-regional transfers may take place only via RIRs who agree to the 
transfer and share reciprocal, compatible, needs-based policies."

to:

"Inter-regional transfers may take place only via RIRs who agree to the 
transfer and share reciprocal, compatible, policies."

- Change the 2nd bullet under "Conditions on recipient of the transfer" 
from:

"Recipients within the ARIN region will be subject to current ARIN 
policies and sign an RSA for the resources being received."

to:

"Recipients within the ARIN region will be subject to current ARIN 
policies, excluding any policies related to needs-based justification or 
inspection of current or future utilization rate, and sign an RSA for 
the resources being received."

- Remove entirely the 3rd bullet under "Conditions on recipient of the 
transfer" which reads "Recipients within the ARIN region must 
demonstrate the need for up to a 24-month supply of IPv4 address space."

Comments:

a.	Timetable for implementation: Immediate

b.	Anything else

As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and 
ARIN) has now been exhausted, networks in need of additional IPv4 
addresses have shifted away from the practice of receiving them from the 
RIR's resource pool. Instead, networks in need are seeking out current 
holders of IPv4 resources who are willing to transfer them in order to 
fulfil that need. Accordingly, the RIR's primary responsibility 
vis-à-vis IPv4 netblock governance has shifted from "allocation" to 
"documentation." In other words, the focus must move away from 
practicing conservation and fair distribution (e.g. following guidelines 
set forth in RFC2050) to ensuring an accurate registry database of which 
organization is utilizing a given netblock as a result of transfers 
which occur between organizations.

The RIPE registry can be used as a reference of one which has evolved 
over the past couple years to shift their focus away from 
conservation/allocation and towards database accuracy. IPv4 netblock 
transfers within that RIR consist merely of validating authenticity of 
the parties requesting a transfer. Provided the organizations meet the 
basic requirement of RIR membership, and that the transferring 
organization has the valid authority to request the transfer, the 
transaction completes without any "needs-based" review.