[arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

David Farmer farmer at umn.edu
Tue Feb 16 00:23:18 EST 2016


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 <dogwallah at gmail.com
> <mailto:dogwallah at gmail.com>> wrote:
>
>
>
>     On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller
>     <jschiller at google.com <mailto:jschiller at google.com>> 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 <bjones at vt.edu
>         <mailto:bjones at vt.edu>> 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
>             <farmer at umn.edu <mailto:farmer at umn.edu>> 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: farmer at umn.edu
>                 <mailto:farmer at umn.edu>
>                 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 (ARIN-PPML at arin.net
>                 <mailto: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 <mailto: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
>             <mailto: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 <mailto:info at arin.net> if you
>             experience any issues.
>
>
>
>
>         --
>         _______________________________________________________
>         Jason Schiller|NetOps|jschiller at google.com
>         <mailto:jschiller at google.com>|571-266-0006 <tel:571-266-0006>
>
>
>         _______________________________________________
>         PPML
>         You are receiving this message because you are subscribed to
>         the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>         <mailto: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 <mailto:info at arin.net> 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|jschiller at google.com
> <mailto:jschiller at google.com>|571-266-0006
>
>
>
> _______________________________________________
> 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.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
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
================================================



More information about the ARIN-PPML mailing list