[arin-ppml] Draft Policy ARIN-2018-2 :Clarification to ISP Initial Allocation and Permit Renumbering (Language improvement)

[Brian Jones]

I support this policy. It aligns with the transfer policy better and clarifies initial allocation in section 4.2.2.

--
Brian E Jones
bjones at vt.edu

> On Jun 23, 2018, at 4:18 PM, Kerrie Vassall-Richards <kerriearichards at gmail.com> wrote:
> 
> 
> Clarification to ISP initial allocation and permit renumbering
> Proposal Originator
> name: Jason Schiller
> email: jschiller at google.com <mailto:jschiller at google.com>
> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://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/20180815/8bf891c5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180815/8bf891c5/attachment.sig>