On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts <[email protected]> wrote:
> My preference is to apply the policy change as written (with the minor > editorial change substituting "criterion" for "criteria".) > +1 -- Brian > > Thank you > Richard Letts > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of David Farmer > > Sent: Monday, February 15, 2016 9:23 PM > > To: ARIN PPML <[email protected]> > > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization > > Requirement in End-User IPv4 Policy > > > > As shepherd, I need additional feedback on this, I need a better sense of > > what the community wants here. > > > > Should we move forward more or less as-is, with a minor editorial change, > > substituting "criterion" for "criteria"? > > > > Or, does the community want to work on a way to address the concerns > > raised but Jason? > > > > Your input please. > > > > Thanks > > > > On 1/29/16 10:00 , Jason Schiller wrote: > > > McTim, > > > > > > WRT some other tangible and verifiable claim to show there was a real > > > commitment to use half the address space within one year... > > > > > > I think there are 3 choices: > > > > > > 1. Very vague > > > > > > Something like "there must be some tangible and verifiable claim to > > > show there was a real commitment to use half the address space within > > > one year and not just a future projection or business case" > > > > > > > > > 2. Open ended with some guidance for ARIN staff: > > > > > > Something like "there must be some tangible and verifiable claim to > > > show there was a real commitment to use half the address space within > > > one year and not just a future projection or business case. Some > > > examples include: > > > - list of equipment in hand to be numbered counting at least 25% of > > > requested IP size > > > - invoices showing equipment purchases demonstrating a commitment to > > > buy equipment to be numbered counting at least 25% of requested IP > > > size > > > - invoices showing equipment purchases demonstrating a commitment to > > > buy equipment to be numbered counting at least 50% of requested IP > > > size within one year > > > - lease agreements for real estate supporting equipment that is > > > appropratly sized to support equipment to be numbered counting at > > > least 50% of requested IP size > > > > > > 3. specific criterion > > > > > > ---- > > > > > > I don't know what it the right answer here, and suspect it has more to > > > do with what the community is comfortable with. > > > > > > On one end of the spectrum is choice 1. This allows ARIN to do the > > > right thing. But this also is not clear about what the community > > > expects, and ARIN may act in a way that is counter to what is > > > anticipated, and may seem like ARIN is being arbitrary or has too much > > > leeway to screw with requestors. > > > > > > The opposite end of the spectrum is choice 3. This sets a very clear > > > list of what qualifies. Hammering out that list may be very > > > difficult, and it is unlikely to be complete. This will leave little > > > or no room for ARIN to do the right thing and approve a request that > > > is justified, but not one of the criterion listed. > > > > > > Choice 2 is the middle ground. Where we have a not necessarily > > > complete list of criterion (so somewhat less difficulty in drawing up > > > the list) that creates a very clear expectation of what ARIN should > > > accept (and reduces the possibility that ARIN may act in a way that is > > > counter to what is anticipated, and may seem like ARIN is being > > > arbitrary or has too much leeway to screw with requestors) with > > > respect to criterion clearly defined, while also allowing ARIN to do > > > the right thing with similar types of proof that are not explicitly > > > listed as criterion (this has somewhat higher risk that ARIN may act > > > in a way that is counter to what is anticipated, and may seem like > > > ARIN is being arbitrary or has too much leeway to screw with > > > requestors, but less risk than option 1 as the criterion should serve > > > as good guidance) > > > > > > > > > So two open questions to the community? > > > > > > 1. Is the community most comfortable with: > > > A. totally vague and open-ended such as "there must be some > > > tangible and verifiable claim to show there was a real commitment to > > > use half the address space within one year and not just a future > > > projection or business case" > > > > > > B. A vague statement with some guidance as to some acceptable > > > forms of tangible verifiable proof of a real commitment to use half > > > the IP address within one year. > > > > > > C. A very clear list of what proof is considered acceptable > > > > > > > > > 2. If the community prefers B. guidance or C. a very clear list then > > > what sort of things would the community like to see on that list? > > > > > > > > > On Fri, Jan 29, 2016 at 8:27 AM, McTim <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > > > > > > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > I support the removal of the 30 day utilization as it is > > > unreasonable for any larger end-site, who may have a real need > > > for say a /16, with 65,000 desktops arriving on a loading doc > > > next week, but an inability to unbox, configure and deploy > > > 16,384 to the various office locations in 30 days. > > > > > > > > > agreed. > > > > > > However, this is the only provision that has a real, tangible, > > > and verifiable claim. Without this check justified need for > end > > > users simply becomes a 1 year future looking projection, and > > > with sufficient arm waving an easy end run around justified > need > > > for any end user with no IP space or if they are efficiently > > > using what they currently hold. > > > > > > > > > good point! > > > > > > I could get on board if the maximum sized block permitted on a > > > purely future looking projection was a /24 and you had to use > it > > > prior to getting more. > > > > > > > > > +1 > > > > > > I could certainly get on board if there were some other > tangible > > > and verifiable claim to show there was a real commitment to use > > > half the address space within one year. > > > > > > > > > Would this language suffice, or would we need a metric of some > sort? > > > > > > > > > Regards, > > > > > > McTim > > > > > > __Jason > > > > > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > Looks good to me Dave. I am okay with using criteria or > > > criterion, however using the strict definition it looks as > > > though criterion is the proper singular form. > > > > > > -- > > > Brian > > > > > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > The following is the proposed update for ARIN-2015-3: > > > Remove 30-Day Utilization Requirement in End-User IPv4 > > > Policy based on strong support in Montreal. > > > > > > Beyond deleting the 25% bullet as the policy says, > their > > > are editorial changes as follows to the remaining > > > text; > > > > > > - It looks weird to have single item bullet list, so > > > merge the two remaining sentence fragments into a > single > > > sentence. > > > - Change "are" to "is", since there is only one > > > remaining criteria > > > - Use of "criteria" as a singular is common usage, even > > > though technically it's plural. > > > - Resulting in "The basic criteria that must be met is > a > > > 50% utilization rate within one year." > > > > > > The remaining and resulting text for 4.3.3 is now > > > included in the policy text, for editorial clarity. > The > > > original staff and legal suggested removing the RFC2050 > > > reference and also pointed out that > > > 4.2.3.6 also has a 25% immediate use clause and a > > > RFC2050 reference. > > > > > > Feedback in Montreal was that deleting the 25% > immediate > > > use was a nice bite-sized change, and we shouldn't try > > > to do more than that with this change, so those changes > > > are not included at this time. > > > > > > Any additional feedback or comments are appreciated. > > > > > > Thanks > > > > > > --------- > > > > > > Draft Policy ARIN-2015-3: Remove 30 day utilization > > > requirement in end-user IPv4 policy > > > > > > Date: 27 January 2015 > > > > > > Problem Statement: > > > > > > End-user policy is intended to provide end-users with a > > > one year supply of IP addresses. Qualification for a > > > one-year supply requires the network operator to > utilize > > > at least 25% of the requested addresses within 30 days. > > > This text is unrealistic and should be removed. > > > > > > First, it often takes longer than 30 days to stage > > > equipment and start actually using the addresses. > > > > > > Second, growth is often not that regimented; the > > > forecast is to use X addresses over the course of a > > > year, not to use 25% of X within 30 days. > > > > > > Third, this policy text applies to additional address > > > space requests. It is incompatible with the > requirements > > > of other additional address space request justification > > > which indicates that 80% utilization of existing space > > > is sufficient to justify new space. If a block is at > > > 80%, then often (almost always?) the remaining 80% will > > > be used over the next 30 days and longer. Therefore the > > > operator cannot honestly state they will use 25% of the > > > ADDITIONAL space within 30 days of receiving it; > they're > > > still trying to use their older block efficiently. > > > > > > Fourth, in the face of ARIN exhaustion, some ISPs are > > > starting to not give out /24 (or larger) blocks. So the > > > justification for the 25% rule that previously existed > > > (and in fact, applied for many years) is no longer > germane. > > > > > > Policy statement: > > > > > > Remove the 25% utilization criteria bullet point from > > > NRPM 4.3.3. > > > > > > Resulting text: > > > > > > 4.3.3. Utilization rate > > > > > > Utilization rate of address space is a key factor in > > > justifying a new > > > assignment of IP address space. Requesters must show > > > exactly how > > > previous address assignments have been utilized and > must > > > provide > > > appropriate details to verify their one-year growth > > > projection. > > > > > > The basic criteria that must be met is a 50% > utilization > > > rate within one year. > > > > > > A greater utilization rate may be required based on > > > individual network > > > requirements. Please refer to RFC 2050 for more > > > information on > > > utilization guidelines. > > > > > > Comments: > > > a.Timetable for implementation: Immediate > > > b.Anything else > > > > > > -- > > > ================================================ > > > David Farmer Email: [email protected] > > > <mailto:[email protected]> > > > Office of Information Technology > > > University of Minnesota > > > 2218 University Ave SE Phone: 1-612-626-0815 > > > <tel:1-612-626-0815> > > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > > <tel:1-612-812-9952> > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are > subscribed to > > > the ARIN Public Policy Mailing List ( > [email protected] > > > <mailto:[email protected]>). > > > Unsubscribe or manage your mailing list subscription > at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact [email protected] <mailto:[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] > > > <mailto:[email protected]>). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact [email protected] <mailto:[email protected]> if you > > > experience any issues. > > > > > > > > > > > > > > > -- > > > > > _______________________________________________________ > > > Jason Schiller|NetOps|[email protected] > > > <mailto:[email protected]>|571-266-0006 <tel:571-266-0006> > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List ([email protected] > > > <mailto:[email protected]>). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact [email protected] <mailto:[email protected]> if you > > > experience any issues. > > > > > > > > > > > > > > > -- > > > Cheers, > > > > > > McTim > > > "A name indicates what we seek. An address indicates where it is. A > > > route indicates how we get there." Jon Postel > > > > > > > > > > > > > > > -- > > > _______________________________________________________ > > > Jason Schiller|NetOps|[email protected] > > > <mailto:[email protected]>|571-266-0006 > > > > > > > > > > > > _______________________________________________ > > > 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. > > > > > > > > > -- > > ================================================ > > David Farmer Email: [email protected] > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > _______________________________________________ > > 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.
