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

Scott Leibrand scottleibrand at gmail.com
Mon May 16 13:38:56 EDT 2016


Robert,
Do you support or oppose ARIN-2015-3?

-Scott

    _____________________________
From: Robert Jacobs <rjacobs at pslightwave.com>
Sent: Monday, May 16, 2016 10:32 AM
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy
To: Owen DeLong <owen at delong.com>, Jason Schiller <jschiller at google.com>
Cc:  <arin-ppml at arin.net>




Boy did you hit the nail on the head… thanks Jason as we are one of those who are hoping to ride out this transition period and continue to have IPV4 ip’s to feed our sales and expansion efforts…It is not a fun process right now keeping a steady supply of /22’s or /21’s coming in

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]On Behalf Of Jason Schiller
Sent: Friday, May 13, 2016 2:38 PM
To: Owen DeLong <owen at delong.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 highly confused now.

 

We have the 25% utilization check which really is the only verifiable 

check to rate-limit aggressively optimistic requests.

 

On one hand, ARIN does not check this figure.  As such the policy 

change is a no-op.

 

On the other hand the 25% utilization goal remains part of the 

policy and having no intention of complying is fraud.

 

ARIN could make random checks, or check all of them.

 

ARIN should check if they have reason to suspect there might

be fraud.

 

I know I worked very hard to get my recent end-user assignment

over 25% by the deadline.   

 

I know in my case the 25% number limited the size of the block.

 

I suspect there are a lot of honest organizations / people who are

trying to do the right thing while maximizing their requested size

within the constraints of policy.

 

So in that respect the policy change is not a no-op.

It would make it easier for end-sites who want to stay 

in compliance with policy to get more IP space by 

simply optimistically and aggressively accelerating their 

deployment plans by compressing a 5 or 10 year plan into 

two years.  Noting there is no harm, no foul if in two years

time the plans have changed, or a simply not achieved.

 

 

On another topic...  

Arguments that IPs are being locked up outside of the 

needs assessment and therefor we should remove the 

needs assessment all together suggests we should 

remove speed limits because so many people speed.

 

Ignoring the fraud aspect for a moment, stockpiling IP 

addresses that are registered to you is very different 

than a future in terms of risk profile.  Lowering the risk 

will encourage this behavior. 

 

 

If the IPs are in the free pool, or available on the transfer

market doesn't change the fact that the numbers are a 

limited and shared resource whose value comes from 

the insurance that the resource holder has exclusive 

claim to a unique set of numbers.  In fact I would argue

that the supply of IPs are more limited now then they 

ever were, especially for large blocks, and especially

for organizations that have been priced out of the 

market and as such stewardship is even more 

important.

 

 

Organizations that have "delusions of grandeur" and 

purchase "extra" IPs will not necessarily "pay dearly".

 

Sure it is a costly mistake to buy what turns out to be

a 50 year supply of addresses.  But the real window

is between the two years which is currently permitted

and the day when IPv6 has wide spread adoption 

such that a transit provider can offer IPv6-only service

and their customers are not inconvenienced, and 

content providers can offer IPv6-only service and not 

risk losing customers that cannot reach them.

 

The goal is to have enough IPv4 addresses to get 

through the transition period to when there is wide

spread support of IPv6, and if you can't secure that

much, than at least more that your competition in a 

given market segment such that you don't have a 

competitive disadvantage of offering a service that

can reach "most of the internet" and if it can reach

the IPv4-only Internet is will be through costly, and

possibly performance and security impacting 

translation middle boxes.

 

A small overage such as buying an 8 year supply 

when you only need a 4 year supply is easily 

justified as an insurance policy and preferable

to having bought a 4 year supply when you needed

an 8 year supply.

 

Nobody complains at the end of the year that they 

wasted a bunch of money on health insurance and 

didn't get sick all year.

 

___Jason

 

 

On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <owen at delong.com> wrote:

I see the policy itself largely as a no-op. I have no objection for it going to the board,

nor do I have any significant support for it to do so.

 

Owen

 

On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu> wrote:

 

Jason,

Even though the last call period formally ended May 9th, I try my best
to consider all feedback received for a policy even following the
formal last call deadline, and while I can't speak for directly for
other AC members, I believe most of them do the same.  However, when
feedback comes in late sometimes it might not get full consideration,
especially if it comes in immediately prior to one of our conference
calls.  To help avoid this I explicitly noted when AC would be
considering the feedback.  I will additionally note at this point it
is extremely important to get any additional feedback in ASAP to allow
the AC due time for its consideration prior to its May 19th conference
call.

As for the issues and questions you have raise, I believe John and
Richard have been answering your questions.  Further, I believe the
community consensus remains to move forward with removing the 25%
Immediate (30 day) use requirement for end users as this policy
suggests.  I would specifically ask anyone who disagrees and thinks we
need to consider the issues more to speak up ASAP.

Thanks.

On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com> wrote:



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> 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> 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).
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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 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).
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.





--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006




-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 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).
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.

 





 

-- 

_______________________________________________________

Jason Schiller|NetOps|jschiller at google.com|571-266-0006

 


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


More information about the ARIN-PPML mailing list