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

[Jason Schiller]

Alyssa,

I agree with the general will of the community that a 30 day check for
ARIN allocations, and a 30 or 60 day check for specified transfers is
an unreasonably difficult metric to meet.

I suggested "Removing the 25% / 30 day [60 day for transfers]
requirement without some added test based on a current or past
measure of need to deflate a purely future looking projection
seems too liberal."

This would roughly amount to slow start, you get a two year supply
based on double what you used last year.  This is what ISPs are
held to.

I suggested that the 25% provision "is the only provision that has
a real, tangible, and verifiable claim.  Without this check justified
need for end users simply becomes a 1 [2 year for transfers] 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."

I further suggested that "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."

This would support an initial assignment for organization that have
no history of growth in the last two years.  This would be the starting
point for slow start, and then would double is used in less than a year.

I also said I could get on board if the following text was added to the
policy:

"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"

And suggested we should have a discussion about if that provision should
be vague (as is above), specific (listing types of proof acceptable), or
opened ended (listing some of the types of proof as guidance).

Response was:

1. - Why add text to IPv4 policy.
    - You already have to pay for IPv4, that should be sufficient to avoid
abuse.
    - Besides we should all only care about IPv6
    - prefer as written

2. - I am leaning towards an open ended verifiable claims.
     - Specific claims could also work.
     - We really need some guidance about what ARIN takes as acceptable
        justification in order to move forward on getting an allocation
approved

3. support as written

4. support as written

5. oppose as written
    - needs teeth

two support as written
one prefer as written
one leaning towards open ended tangible proof
one opposed as written without teeth


What is truly concerning to me is this belief that
the policy change is a no-op on the following
grounds:

1. It does change the rules for ARIN allocations
    but who cares, there is a long waiting list and
    a trickle of space coming out there.

2. It doesn't change anything for transfers as
    staff ignores this check anyway.

I was surprised that ARIN feels they cannot
complete a 25% check wrt specified transfers
due to lack of guidance.

I was further confused by the staff comment that
the 25% check is still part of policy and intentionally
violating it is fraud.

I further believe this change is not a no-op.

1. Current policy prevents organizations who do not
    want to commit fraud from asking for too much.

2. Current policy prevents organizations who are
    afraid of a possible audit of the 25% number
    is likely to show them out of compliance from
   asking for to much.

3. if it is a no-op then just leave the text in until
    we can find new text to prevent aggressively
    optimistic projections that circumvent need
    based policy.


Without this text, or some other provision to limit
wildly optimistic growth claims, there is no way
to keep an end-user organization that wants to
remain in compliance with policy from asking for
what is likely much more than a two year supply.

Essentially the policy will be:
"End-users can get as much IP space as they want
  as long as they meet the 3 following requirements:
1. The average of their current holdings (if any)
     are above 80% used.
2. An officer of the company attests that the plan to
    use half the requested addresses in two years
    is not impossible to achieve.
3. They can afford to buy the addresses."


Alyssa, your questions about what advice to give ARIN
about current policy is a very interesting question.

Unfortunately it crosses the transfer without needs
justification discussion, which complicates everything.

I don't know how you can craft the question to get at
the answer of what checks ARIN should do, without
falling into the wider discussion of should there be a
needs basis check at all.

The original proposal was to remove the 30 day check as
it was a burden.

It seems people who support specified transfers without
a needs based justification support this policy as this
moves things far along in that direction.

It seems others support this policy as it makes it possible
for an end-user organization to get addresses without
first using an up-streams IPs.

It seems yet another group believe the 30 day check to
be unreasonable, and taking it out is a no-op
(when it appears to actually limit requests in its current
form even with ARIN's current operating practices)

Unfortunately this is very complicated.

__Jason














On Fri, May 13, 2016 at 6:42 PM, Alyssa Moore <alyssa.moore at cybera.ca>
wrote:

> Apologies in advance for jumping in at the last minute on a policy that's
> in recommended form, but I have a few questions and observations.
>
> 1)  The problem statement says:
> > First, it often takes longer than 30 days to stage equipment and
> start actually using the addresses.
>
> Earlier on, Jason says:
> > "I know I worked very hard to get my recent end-user assignment over
> 25% by the deadline."
>
> It is my understanding, Jason, that you're a proponent of some form of
> verification with teeth - presumably something more aggressive than the 1
> year/50% that would still be included if 2015-3 passes muster, but you also
> concede that you had a difficult time meeting the current 30 day
> "deadline."
>
> I could be completely off base because I haven't been following 2015-3
> since its inception, but has there been any discussion of a test that sits
> somewhere between 25%/30 days and 50%/1 year?
>
> 2) It seems 4.3.3 in its current incarnation *doesn't have teeth to begin
> with *as it applies to transfers (which are really the only option in a
> post-depletion world.) John Curran says:
>
> Such a requirement could only be applicable transfers to end-users who
> were demonstrating their 24-month need using NRPM 4.3.3, and *there is no
> clear interpretation for application of **the  "25% immediate utilization
> rate” language*. As such, it is not directly considered during the
> process (as elaborated by Richard Jimmerson on the list); therefore none
> were “reviewed and verified explicitly” for that purpose.
>
> Note that the language remains applicable (and organizations that attempt
> to transfer without having immediate utilization do run the risk of
> number resource fraud), but is not integrated into the end-user transfer
> review process as its extrapolation into that context is unclear.  *This
> is also why the staff and legal review for draft policy 2015-3 notes -
> "This policy would **more closely align with the way staff applies the
> existing policy in relation to 8.3 transfers.”*
>
>
> [emphasis my own]
>
> My understanding from these comments is that ARIN has not been doing 30
> day check ups on transfers because *staff has not received direction on
> how to apply the existing policy to transfers, *which would be the reason
> behind the staff assessment, "This policy would more closely align with
> the way staff applies existing policy." To that end, then, the policy in
> its current incarnation is not completely obsolete as some folks have
> claimed on the PPML. Staff simply don't have direction for application of
> the utilization rates.
>
> It seems there needs to be clearer consensus around what the action of
> ARIN staff ought to be a) in pursuing verification in the first place re:
> transfers and b) in cases where verification tests aren't met. Should
> ARIN be automatically checking in at the 30 day or 1 year mark? If so, what
> does ARIN do if the 25%/30 days or 50%/1year tests aren't met? Should
> ARIN revoke the address space? Serve the offender notice? Are either of
> these ethical in a post-depletion world where folks have paid for address
> space?
>
> If the community is to give direction in these areas, should it be
> included in 2015-3, or in a separate problem statement?
>
> Feel free to set me straight on all of this 'cause I'm a giant nooooob.
> - Alyssa
>
> On Fri, May 13, 2016 at 4:19 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/56269565/attachment.htm>