[arin-ppml] 2016-3 Revisited - anti-abuse clause

[Jason Schiller]

I support B.

It puts added work on those who need more than a /16, or have a growth rate
more than doubling every half yeah, but does not prevent organizations who
need IP addresses from getting them.

I oppose A and C as they are unfair,

A.
  - unfairly penalizes large organizations that need more than a /16
  - unfairly penalizes organizations growing faster than double their
current holding
    (especially new organizations that started with a /24 and have a growth
rate greater than 512 customer per year)

C.
   - unfairly penalizes large organizations that need more than a /16
   - unfairly penalizes organizations growing faster than double their
current holding
   - unfairly does not penalizes organizations growing faster than double
their current holding so long as they need less than a /16


A > B or B > A?

I can't decide if A is less unfair because there is no carve out for
organizations that need less than a /16.  On one hand those needing less
than a /16 are not treated unfairly as a special class, but as a result the
number of organizations who need IP addresses that are rate limited is
greater.

 Or if C is less unfair because it is unfair to have a carve out for the
organization that need less than a /16 for exactly the opposite reasons.

__Jason

On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com> wrote:

> We have a few options on the table and only a few voices in the
> discussion...
>
> I'd like to quickly outline the options, and see if we can get more people
> to weigh in and either note they object to one or more options, are
> ambivalent to one or more options, or support one or more options (with
> some preference).
>
>
> 1. demonstrate 80% utilization on average for all your IP space
> 2. get pre-authorization for 1 or more transfers up to double your current
> holdings over then two years
> 2.1. this is limited to a /16
>
> A. you can use this policy once every 6 months
>
> B. If you need to use this policy more than once every 6 months you need
> to also demonstrate growth equalling half what you have transferred since
> you last used this policy.
>
> C. you can use this policy to transfer a total of up to a /16
>
> Where do you stand on A, B or C?
>
> __Jason
>
>
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
>> That would be a significant improvement on the current ("An organization
>> may only qualify under 8.5.7 once every 6 months.") text.  I would be
>> equally fine with this text ("No more than a total of a /16 equivalent
>> may be transferred under these provisions within any 6 month period." or
>> similar) or with Jason's ("An organization may only qualify under 8.5.7
>> once every 6 months, unless they can also demonstrate growth of IPv4
>> utilization of at least half of the amount of specified transfers since the
>> previous transfer pre-authorization or approval.")
>>
>> Thanks,
>> Scott
>>
>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> Simple to resolve for the 6-month horizon —
>>>
>>> … Such that no more than a total of a /16 equivalent may be transferred
>>> under these provisions within any 6 month period. …
>>>
>>> Owen
>>>
>>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>>> >
>>> >
>>> > I thought of a possible problem with the anti-abuse language -- all
>>> versions of it.  Let me talk it out.
>>> >
>>> > An organization has a /19.
>>> > It has growing products, and wants another /19 for its 1 or 2 year
>>> need.
>>> > It wants to avail itself of the new language.
>>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>>> >
>>> > It closes the deal with Buyer A first, and transfers at ARIN using the
>>> proposed language.
>>> >
>>> > How does it use any version we've discussed (Jason's various
>>> proposals, the current text, etc) to transfer the space it buys from Buyer
>>> B?
>>> >
>>> >
>>> > (In all discussion, yes, you can always use the other sections of 8.5,
>>> but let's stick to the spirit of this policy language, which is meant to
>>> help smaller and mid-size networks double their holdings without needs
>>> testing.)
>>> > _______________________________________________
>>> > 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.
>>>
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>> _______________________________________________
>> 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 <(571)%20266-0006>
>
>


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