[arin-ppml] Proposed Editorial Change to NRPM (Formerly Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup)

[ARIN]

On 15 February 2018 the ARIN Advisory Council (AC) has requested that 
Draft Policy ARIN-2017-11: Reallocation and Reassignment Language 
Cleanup be classified as an editorial update to the Number Resource 
Policy Manual (NRPM).

The full text of the proposed editorial change is below and may be found 
at https://www.arin.net/policy/proposals/2017_11.html.

The process for editorial updates to the NRPM is found in Part One, 
Section 3.1, paragraph 3 of the PDP:

"Changes to policy that are purely editorial and non-substantial in 
nature are outside the scope of the full Policy Development Process and 
may only be made with 30 days public notice followed by the concurrence 
of both the ARIN Advisory Council and ARIN Board of Trustees that the 
changes are non-substantial in nature."

The community review period will close on 23 March 2018.

For convenience, a redline of the proposed changes to the current NRPM 
may be found at:

https://www.arin.net/policy/proposals/attachments/2017_11_Redline.pdf

The ARIN Number Resource Policy Manual may be found at:
https://www.arin.net/policy/nrpm.html

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)





Proposed Editorial Change to NRPM (Formerly Draft Policy ARIN-2017-11: 
Reallocation and Reassignment Language Cleanup)

2.5. Allocate and Assign

A distinction is made between address allocation and address assignment, 
i.e., ISPs are "allocated" address space as described herein, while 
end-users are "assigned" address space.

Allocate - To allocate means to distribute address space to IRs for the 
purpose of subsequent distribution by them.

Assign - To assign means to delegate address space to an ISP or 
end-user, for specific use within the Internet infrastructure they 
operate. Assignments must only be made for specific purposes documented 
by specific organizations and are not to be sub-assigned to other parties.

Proposed Editorial Change:

2.5 Allocation, Assignment, Reallocation, Reassignment
…
Allocation - Address space delegated to an organization directly by ARIN 
for the purpose of subsequent distribution by the recipient organization 
to other parties.

Assignment - Address space delegated to an organization directly by ARIN 
for the exclusive use of the recipient organization.

Reallocation - Address space sub-delegated to an organization by an 
upstream provider for the purpose of subsequent distribution by the 
recipient organization to other parties.

Reassignment - Address space  sub-delegated to an organization by an 
upstream provider for the exclusive use of the recipient organization.

Make the following editorial changes to section 3.2:

Current text:

3.2. Distributed Information Server Use Requirements[edit]

The minimal requirements for an organization to setup a distributed 
information service to advertise reassignment information are:

The distributed information service must be operational 24 hours a day, 
7 days a week to both the general public and ARIN staff. The service is 
allowed reasonable downtime for server maintenance according to 
generally accepted community standards.

The distributed information service must allow public access to 
reassignment information. The service may restrict the number of queries 
allowed per time interval from a host or subnet to defend against DDOS 
attacks, remote mirroring attempts, and other nefarious acts.

The distributed information service must return reassignment information 
for the IP address queried. The service may allow for privacy 
protections for customers.
For residential users, the service may follow ARIN's residential privacy 
policy that includes displaying only the city, state, zip code, and 
country. For all other reassignments, the service shall follow ARIN's 
privacy policy for publishing data in a public forum.

The distributed information service may return results for non-IP queries.

The distributed information service must respond to a query with the 
minimal set of attributes per object as defined by ARIN staff.

The distributed information service may include optional attributes per 
object that are defined locally.

The distributed information service must return results that are 
up-to-date on reassignment information.

Proposed Editorial Change:

3.2. Distributed Information Server Use Requirements

The minimal requirements for an organization to setup a distributed 
information service to advertise reassignment and reallocation 
information are:

The distributed information service must be operational 24 hours a day, 
7 days a week to both the general public and ARIN staff. The service is 
allowed reasonable downtime for server maintenance according to 
generally accepted community standards.

The distributed information service must allow public access to 
reassignment and reallocation information. The service may restrict the 
number of queries allowed per time interval from a host or subnet to 
defend against DDOS attacks, remote mirroring attempts, and other 
nefarious acts.

The distributed information service must return reassignment and 
reallocation information for the IP address queried. The service may 
allow for privacy protections for customers. For residential users, the 
service may follow ARIN's residential privacy policy that includes 
displaying only the city, state, zip code, and country. For all other 
reassignments and reallocations, the service shall follow ARIN's privacy 
policy for publishing data in a public forum.

The distributed information service may return results for non-IP queries.

The distributed information service must respond to a query with the 
minimal set of attributes per object as defined by ARIN staff.

The distributed information service may include optional attributes per 
object that are defined locally. The distributed information service 
must return results that are up-to-date on reassignment and reallocation 
information.

Make the following editorial changes to section 4.2:

Current text:

4.2.1.1. Purpose

ARIN allocates blocks of IP addresses to ISPs for the purpose of 
reassigning that space to their customers.

Proposed Editorial Change:

4.2.1.1. Purpose

ARIN allocates blocks of IP addresses to ISPs for the purpose of 
reassigning and reallocating that space to their customers.

Current text:

4.2.3. Reassigning Address Space to Customers

Proposed Editorial Change:

4.2.3. Reassigning and Reallocating Address Space to Customers

Current Text:

4.2.3.1. Efficient utilization

ISPs are required to apply a utilization efficiency criterion in 
providing address space to their customers. To this end, ISPs should 
have documented justification available for each reassignment. ARIN may 
request this justification at any time. If justification is not 
provided, future receipt of allocations may be impacted.

Proposed Editorial Change:

4.2.3.1. Efficient utilization

ISPs are required to apply a utilization efficiency criterion in 
providing address space to their customers. To this end, ISPs should 
have documented justification available for each reassignment and 
reallocation. ARIN may request this justification at any time. If 
justification is not provided, future receipt of allocations may be 
impacted.

Current text:

4.2.3.4. Downstream customer adherence

ISPs must require their downstream customers to adhere to the following 
criteria:

4.2.3.4.1. Utilization

Reassignment information for prior allocations must show that each 
customer meets the 80% utilization criteria and must be available via 
SWIP / RWhois prior to your issuing them additional space.

Proposed Editorial Changes:

4.2.3.4. Downstream customer adherence

ISPs must require their downstream customers to adhere to the following 
criteria:

4.2.3.4.1. Utilization

Reassignment and reallocation information for prior allocations must 
show that each customer meets the 80% utilization criteria and must be 
available via SWIP / RWhois prior to your issuing them additional space.

Current text:

4.2.3.5. ARIN approval of reassignments/reallocations

4.2.3.5.1. /18

All extra-large ISPs making reassignments of a /18 or larger to a 
customer must first have these reassignments reviewed and approved by ARIN.

4.2.3.5.2. /19

Small to large ISPs making customer reassignments of a /19 or larger 
must first seek ARIN's approval.

Proposed Editorial Changes:

4.2.3.5. ARIN approval of reassignments/reallocations

4.2.3.5.1. /18

All extra-large ISPs making reassignments or reallocations of a /18 or 
larger to a customer must first have these reassignments or 
reallocations reviewed and approved by ARIN.

4.2.3.5.2. /19

Small to large ISPs making customer reassignments or reallocations of a 
/19 or larger must first seek ARIN's approval.

Current text:

4.2.3.7.1. Reassignment Information

Each IPv4 assignment containing a /29 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2. Reassignment 
registrations shall include each client's organizational information, 
except where specifically exempted by this policy.

Proposed Editorial Changes:

4.2.3.7.1. Reassignment and Reallocation Information

Each IPv4 reassignment or reallocation containing a /29 or more 
addresses shall be registered in the WHOIS directory via SWIP or a 
distributed service which meets the standards set forth in section 3.2. 
Reassignment and reallocation registrations shall include each client's 
organizational information, except where specifically exempted by this 
policy.

Current text:

4.2.3.7.2.Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1 
within seven calendar days of assignment.

Proposed Editorial Changes:

4.2.3.7.2.Reassignments and Reallocations visible within 7 days

All reassignments and reallocations shall be made visible as required in 
section 4.2.3.7.1 within seven calendar days of reassignment or 
reallocation.

Current text:

4.2.4. ISP Additional Requests

4.2.4.1. Utilization percentage (80%)

ISPs must have efficiently utilized all allocations, in aggregate, to at 
least 80% and at least 50% of every allocation in order to receive 
additional space. This includes all space reassigned to their customers.

Proposed Editorial Changes:

4.2.4. ISP Additional Requests

4.2.4.1. Utilization percentage (80%)

ISPs must have efficiently utilized all allocations, in aggregate, to at 
least 80% and at least 50% of every allocation in order to receive 
additional space. This includes all space reassigned or reallocated to 
their customers.

Make the following editorial changes to section 6 to clarify language 
regarding current practices and requirements for reallocations and 
reassignments, and specifically to clarify that recording reallocation 
information is required where current language is ambiguous:

Current text:

6.5.2.1(e) Initial Allocations to LIRs, Size

For purposes of the calculation in (c), an LIR which has subordinate 
LIRs shall make such allocations according to the same policies and 
criteria as ARIN. In such a case, the prefixes necessary for such an 
allocation should be treated as fully utilized in determining the block 
sizing for the parent LIR. LIRs which do not receive resources directly 
from ARIN will not be able to make such allocations to subordinate LIRs 
and subordinate LIRs which need more than a /32 shall apply directly to 
ARIN.

Proposed Editorial Changes:

6.5.2.1(e) Initial Allocations to LIRs, Size

For purposes of the calculation in (c), an LIR which has subordinate 
LIRs shall make such reallocations according to the same policies and 
criteria as ARIN. In such a case, the prefixes necessary for such a 
reallocation should be treated as fully utilized in determining the 
block sizing for the parent LIR. LIRs which do not receive resources 
directly from ARIN will not be able to make such reallocations to 
subordinate LIRs and subordinate LIRs which need more than a /32 shall 
apply directly to ARIN.

Current text:

6.5.2.2. Qualifications

An organization qualifies for an allocation under this policy if they 
meet any of the following criteria:

a. Have a previously justified IPv4 ISP allocation from ARIN or one of 
its predecessor registries or can qualify for an IPv4 ISP allocation 
under current criteria.

b. Are currently multihomed for IPv6 or will immediately become 
multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments from allocation(s) 
under this policy to other organizations.

Provide ARIN a reasonable technical justification indicating why an 
allocation is necessary. Justification must include the intended 
purposes for the allocation and describe the network infrastructure the 
allocation will be used to support. Justification must also include a 
plan detailing anticipated assignments to other organizations or 
customers for one, two and five year periods, with a minimum of 50 
assignments within 5 years.

Proposed Editorial Changes:

6.5.2.2. Qualifications

An organization qualifies for an allocation under this policy if they 
meet any of the following criteria:

a. Have a previously justified IPv4 ISP allocation from ARIN or one of 
its predecessor registries or can qualify for an IPv4 ISP allocation 
under current criteria.

b. Are currently multihomed for IPv6 or will immediately become 
multihomed for IPv6 using a valid assigned global AS number.

In either case, they will be making reassignments or reallocations from 
allocation(s) under this policy to other organizations.

Provide ARIN a reasonable technical justification indicating why an 
allocation is necessary. Justification must include the intended 
purposes for the allocation and describe the network infrastructure the 
allocation will be used to support. Justification must also include a 
plan detailing anticipated reassignments and reallocations to other 
organizations or customers for one, two and five year periods, with a 
minimum of 50 assignments within 5 years.

Current text:

6.5.4. Assignments from LIRs/ISPs

Assignments to end users shall be governed by the same practices adopted 
by the community in section 6.5.8 except that the requirements in 
6.5.8.1 do not apply.

Proposed Editorial Changes:

6.5.4. Reassignments from LIRs/ISPs

Reassignments to end users shall be governed by the same practices 
adopted by the community in section 6.5.8 except that the requirements 
in 6.5.8.1 do not apply.

Current text:

6.5.4.1. Assignment to operator's infrastructure

An LIR may assign up to a /48 per PoP as well as up to an additional /48 
globally for its own infrastructure.

Proposed Editorial Changes:

6.5.4.1. Reassignment to operator's infrastructure

An LIR may reassign up to a /48 per PoP as well as up to an additional 
/48 globally for its own infrastructure.

Current text:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space 
allocations by providing appropriate documentation, including but not 
limited to assignment histories, showing their efficient use.

Proposed Editorial Changes:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space 
allocations by providing appropriate documentation, including but not 
limited to reassignment and reallocation histories, showing their 
efficient use.

Current text:

6.5.5.1. Reassignment information

Each static IPv6 assignment containing a /64 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2. Reassignment 
registrations shall include each client's organizational information, 
except where specifically exempted by this policy.

Proposed Editorial Changes:

6.5.5.1. Reassignment information

Each static IPv6 reassignment or reallocation containing a /64 or more 
addresses shall be registered in the WHOIS directory via SWIP or a 
distributed service which meets the standards set forth in section 3.2. 
Reassignment and reallocation registrations shall include each client's 
organizational information, except where specifically exempted by this 
policy.

Current text:

6.5.5.2. Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1 
within seven calendar days of assignment

Proposed Editorial Changes:

6.5.5.2. Reassignments and Reallocations visible within 7 days

All reassignments and reallocations shall be made visible as required in 
section 4.2.3.7.1 within seven calendar days of reassignment or 
reallocation.

Current text:

12. Resource Review

(...)

2. c) whenever ARIN has reason to believe that an organization is not 
complying with reassignment policies, or

Proposed Editorial Changes:

12. Resource Review

(...)

2. c) whenever ARIN has reason to believe that an organization is not 
complying with reassignment or reallocation policies, or