[arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup

[theone at uneedus.com]

For the same reason as stated in comments to ARIN-2017-10, this proposal 
changes language in 6.5.5.1 which is before the ARIN Board regarding a 
change of the standard from /64 or more to /47 or more, or any size 
individually announced.

I suggest the author take into consideration the change of this section in 
ARIN-2017-5 before the ARIN Board, before any changes to this section 
are made.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Tue, 21 Nov 2017, ARIN wrote:

> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: 
> Reallocation and Reassignment Language Cleanup" to Draft Policy status.
>
> Draft Policy ARIN-2017-11 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_11.html
>
> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The 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,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup
>
> Problem Statement:
>
> The current text of NRPM uses the terms ‘reallocate’ and ‘reassign’ 
> in ways that are both internally inconsistent within NRPM and inconsistent 
> with the definitions of Reassignments and Reallocations as fields within the 
> ARIN database. Frequently the term ‘reassignment’ or ‘reassign’ is 
> used in NRPM as an umbrella term for both reallocations and reassignments. As 
> a result, someone familiar with the ARIN Whois database, but unfamiliar with 
> history of particular portions of NRPM and their intended meaning may 
> interpret certain NRPM requirements as applying only to reassignments and not 
> to reallocations. This is particularly problematic when it comes to SWIP 
> requirements and the requirement to record reallocations and reassignments 
> with ARIN, which under current text could be read to only apply to 
> reassignments.
>
> Policy Statement:
>
> Make the following changes to the definitions in Section 2.5
>
> Current text:
>
> 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 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.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>