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

[Brian Jones]

On Wed, Dec 6, 2017 at 1:36 PM Owen DeLong <owen at delong.com> 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 , theone at uneedus.com 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 (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.
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171206/5a5980b7/attachment.htm>