[arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

Thu May 12 16:58:44 EDT 2016

Jason
It seems that the criteria you apply to demonstrated need presumes the existence of a free pool that must be “conserved” through traditional needs assessment methods. It overlooks the fact that going forward, we will be dealing exclusively with transfers. In other words, if companies overestimate their needs, due to “delusions of grandeur” or any other reason, they will have to pay dearly for that. Furthermore, the supply of those addresses will be coming from people who are, by definition, not in need of them at all. So on the whole, I find your arguments completely unconvincing. The only risk you have identified is that some small organization might pay for more than they turn out to need.

--MM

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Thursday, May 12, 2016 4:04 PM
To: David R Huberman <daveid at panix.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.

My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).

Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.
Extended this doubles the values.

This is also seems to be consistent with what I heard at the meeting:

"Kevin Blumberg:  The question was, to clarify for everybody, when it comes -- this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what -- when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?

John Curran:  It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.

When the AC has some free time, if it would like to unwind those, that would be greatly appreciated."

I trust ARIN is very good at finding fraud and abuse, however I think this change makes fraud and abuse (or as Owen put it simply having dreams of grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it much harder to catch as per Jonh's comments when discussing this policy.

"John Curran:  We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it's much more difficult to know whether or not someone has made a fraudulent request if we don't check shortly after we've assigned to them.

In other words, someone will find address space utilization within a year one way or the other. But whether or not they're valid for what we assigned is much easier to determine if they've made use of it within the first 30 days, or 30 days, 60 days, the immediate future."

Can staff comment do you apply the 25% need in 60 days to specified transfers?  Or is this ignored and obsolete?

__Jason

On Tue, May 10, 2016 at 6:10 PM, David R Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:
Jason,

1) The policy in last call removes a criterion that is not being applied
today.  Staff have criteria they use to judge 24-month need, and have been
applying it for years without coming back to us and telling us there's a
problem or deficiency.

2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
operate a network, and aren't attempting to defraud ARIN In any way. ARIN
staff have been fighting scammers for a very long time, and are very good
at it. They have measurable positive results in fighting fraud.

For those two reasons, I believe this policy should be adopted by the
board, and an obsolete criterion should be removed from NRPM.

David

> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
>  I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>    "When we [ARIN] ask organization for their forward
>     projections, we [ARIN] also ask them to provide details
>    to show how they've arrived at their projections. We [ARIN]
>    take into account factors such as new networks, locations,
>    products, services they plan on offering (and this includes
>    consideration of anticipated address utilization within the
>    first 30 days for end-users.)
>
>>From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:
>
>> As shepherd for this policy I welcome any additional last call
>> feedback for this policy.  It is especially important to speak up if
>> you feel there are any issues remaining that need to be considered.
>> But, even if you simply support the policy as written that is
>> important and useful feedback as well.
>>
>> The last call period formally continues through, Monday, May 9th, and
>> the AC will consider the feedback during its scheduled call on
>> Thursday, May 19th.
>>
>> Thanks
>>
>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> > send the following to last call:
>> >
>> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> > requirement in end-user IPv4 policy
>> >
>> > Feedback is encouraged during the last call period. All comments
>> should
>> > be provided to the Public Policy Mailing List. This last call will
>> > expire on 9 May 2016. After last call the AC will conduct their
>> > last call review.
>> >
>> > The draft policy text is below and available at:
>> > https://www.arin.net/policy/proposals/
>> >
>> > The ARIN Policy Development Process is available at:
>> > https://www.arin.net/policy/pdp.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > ARIN 2015-3 contributes to fair and impartial number resource
>> administration
>> > by removing from the NRPM text that is operationally unrealistic for
>> the
>> > reasons discussed in the problem statement. This proposal is
>> technically
>> > sound, in that the removal of the text will more closely align with
>> the
>> way
>> > staff applies the existing policy in relation to 8.3 transfers. There
>> was
>> > strong community support for the policy on PPML and at ARIN 36, which
>> was
>> > confirmed at ARIN 37. There was a suggestion to replace this text with
>> an
>> > alternate requirement. However, the community consensus was to move
>> forward
>> > with the removal alone.
>> >
>> > The staff and legal review also suggested removing RFC2050 references
>> and
>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> > community feedback was to deal with those issues separately.
>> >
>> > 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 criterion 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
>> >
>> > #####
>> >
>> > ARIN STAFF ASSESSMENT
>> >
>> > Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> > Date of Assessment: 16 February 2016
>> >
>> > ___
>> > 1. Summary (Staff Understanding)
>> >
>> > This proposal would remove the 25% utilization (within 30 days of
>> issuance)
>> > criteria bullet point from NRPM 4.3.3.
>> >
>> > ___
>> > 2. Comments
>> >
>> > A. ARIN Staff Comments
>> > This policy would more closely align with the way staff applies the
>> existing
>> > policy in relation to 8.3 transfers. Because there is no longer an
>> IPv4
>> free
>> > pool and many IPv4 requests are likely to be satisfied by 8.3
>> transfers,
>> the
>> > adoption of this policy should have no major impact on operations and
>> could
>> > be implemented as written.
>> >
>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>> obsolete
>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
>> (within
>> 30
>> > days of issuance) requirement.
>> >
>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
>> the
>> > references to RFC 2050 and the 25% requirement. Additionally, staff
>> suggests
>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
>> >
>> > B. ARIN General Counsel â€“ Legal Assessment
>> > No material legal risk in this policy.
>> >
>> > ___
>> > 3. Resource Impact
>> >
>> > This policy would have minimal resource impact from an implementation
>> > aspect. It is estimated that implementation would occur immediately
>> after
>> > ratification by the ARIN Board of Trustees. The following would be
>> needed in
>> > order to implement:
>> > * Updated guidelines and internal procedures
>> > * Staff training
>> > _______________________________________________
>> > 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.
>>
>>
>>
>> --
>> ===============================================
>> David Farmer               Email:farmer at umn.edu<mailto:Email%3Afarmer at umn.edu>
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: 612-626-0815<tel:612-626-0815>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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.
>>
>
>
>
> --
> _______________________________________________________
> 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.

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160512/3fc0f7d8/attachment.htm>