Just in case it wasn't clear, I oppose as written as it has no teeth and can easily be an end user end-run around justified need.
I support the change with some teeth so it is not likely to be an end-run around justified need. __Jason On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones <[email protected]> wrote: > > > > > 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. > -- _______________________________________________________ Jason Schiller|NetOps|[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.
