On Wed, Dec 6, 2017 at 1:36 PM Owen DeLong <[email protected]> wrote: > 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 > > I +1 Owen's comments. It seems these changes could be made with or without ratification of 2015-5.
-- Brian > > 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.
_______________________________________________ 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.
