The proposed editorial changes do not conflict with the current language, nor do they present a conflict with the revised language that will occur if the board ratifies 2017-5. Staff can intelligently apply this update to the NRPM in either state without conflict or loss of fidelity in either case.
Owen > On Nov 21, 2017, at 15:48 , [email protected] wrote: > > 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 ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
