I support this policy. It aligns with the transfer policy better and clarifies initial allocation in section 4.2.2.
-- Brian E Jones [email protected] > On Jun 23, 2018, at 4:18 PM, Kerrie Vassall-Richards > <[email protected]> wrote: > > > Clarification to ISP initial allocation and permit renumbering > Proposal Originator > name: Jason Schiller > email: [email protected] <mailto:[email protected]> > telephone: 202-258-8863 > organization: Google LLC > Date: 02/01/2017 > Problem Statement: > > As discussed in more detail in ARIN-2017-9 and noted in the ARIN 40 Policy > Experience Report, the criteria to qualify for an initial block of address > space in 4.2.2 and 8.5.4 are seeming at odds with each other. At ARIN 41 the > community seemed to prefer the approach contained in this policy over the > approach in ARIN-2017-9, which was subsequently abandoned. > > Moreover, as the NRPM (2018-1) currently sits, 4.2.2 appears to state that an > initial allocation of up to a /21 could be granted without any more > justification than needed to qualify for a /24. Therefore, 4.2.2 should be > modified, allowing an initial allocation of only a /24 without any additional > justification and allowing an initial allocation of up to a /21 when > justified by a 24-month allocation plan. > > Policy Statement: > > Replace the current Section 4.2.2 with: > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's minimum > allocation size. > > All ISP organizations without direct allocations, direct assignments, > re-allocations or reassignments automatically qualify for a /24. These > organizations are exempt from requirements of showing the efficient > utilization of previously held IPv4 space. These organizations may qualify > for a larger than a /24 by documenting how the requested allocation will be > utilized within the request size specified in 4.2.4.3 > > ISPs holding re-allocations and/or reassignments must show the efficient > utilization of their resources consistent with the requirements in sections > 4.2.3 and 4.2.4 > > > Comments: > > The timetable for Implementation: Immediate > > Anything Else: > > This is an attempt to clarify the changes that came about from 2016-4. > It also aligns section 4.2 with current transfer policy. > It also re-established the understanding that ISP can renumber and return, > but putting the last section 4.2.2.1.4 into the ISP additional requests > section. This text is slightly modified to include returns to ARIN in > addition to returns to the upstream. > > > _______________________________________________ > ARIN-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: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ARIN-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: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
