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

[Jason Schiller]

John,

I am referring to both ARIN assignments and specified transfers to end-users
WRT policy.

It is my understanding that Specifies transfers to end-users  per 8.3
"The recipient must demonstrate the need for up to a 24-month supply
of IP address resources under current ARIN policies and sign an RSA."

My understanding is that the current ARIN policies, 4.3.3 and 4.3.6
apply equally to ARIN assignments and Specified transfers,
except that the time horizon of specified transfers is two years
(which happens to be double the time horizon of ARIN assignments).

I interpret this to mean that specified transfers are justified by 50%
utilization
in two years (instead of one).

With a doubling of the time horizon I think it is charitable and reasonable
to also double the 25% time horizon to 60 days (although one could argue
that number is based on immediate need, whose definition does not change
WRT specified transfers).

WRT checking, I am referring specifically to specified transfers.
(Thank you for making me clarify that, I see now how that is confusing).

It seems ARIN does not make the 25% check for specified transfers
making this policy a no-op.

At the same time there are organizations, who what to do the right thing,
who limit there end-user transfer requests to only four times what they can
deploy in 60 days.  Without the 25% check, those organizations will be able
to remain in policy, and transfer much more address space.  So in that sense
is NOT a no-op.

My real concern is that the possibility of a 30 or 60 day check is
sufficient to
limit wildly optimistic two year projections.

I am only going to ask for what I can commit to deploy in 60 days.  That
time horizon is sufficiently close that things have to be in motion to meet
it.  In the case of two years there can be a lot of hand waviness and
promise to commit resources in future quarters.  These promises are
easily made (and hence attest to) and easily broken (oh the plan changed).

Without some check (the 25% check or something else) then organizations
are free to make wildly optimistic  plans.  As long as the plan has a
possibility
of being completed within 2 years, then it is within policy.

As such a wildly optmistic plan for a 2 year deployment could easily result
in a 10 year supply of addresses for a reasonable growth.

___Jason





On Fri, May 13, 2016 at 4:11 PM, John Curran <jcurran at arin.net> wrote:

> On May 13, 2016, at 3:38 PM, Jason Schiller <jschiller at google.com> wrote:
>
>
> 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.
>
> ...
>
>
> Jason -
>
>    Are you referring to assignments or transfers?  The above discussion
>    appears to mix requests of both types.
>
>    ARIN does check that end-user _assignment_ requests meet the
>    25% immediate utilization requirement (as called for in the end-user
>    assignment policy.)
>
>    ARIN does not have clear guidance how the assignment criteria for
>    25% immediate use is to be applied to transfers.  ARIN can apply the
>    criteria with respect to transfer requests, but that would require some
>    additional policy clarity from the community to do so.
>
> So in that respect the policy change is not a no-op.
>
>
>    The policy change will not materially affected transfer requests, as
> noted
>    above.  The change would effect processing of any end-user assignments
>    requests.  (It is probably worth noting that end-users who presently
> qualify
>    for assignment of an IPv4 block are being added to a waiting list with
> a
>    rather low probability of timely fulfillment.)
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
>


-- 
_______________________________________________________
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/c1bd7714/attachment.htm>