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

Thu Feb 9 11:39:22 EST 2017

Owen,

After reading your mail, I noticed I artificially shortened the text for
C.  It should have been what you described as your preferred choice.

Re-asking the question for clarity (and hopes of getting new voices).

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 equaling 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 every 6 months

Where do you stand on A, B or C?

On Wed, Feb 8, 2017 at 3:35 PM, Owen DeLong <owen at delong.com> wrote:

> Respectfully I reject your premise on the fairness.
>
> Neither A, nor C prevent large organizations from getting more, they
> merely require that they use other less simplified provisions of the
> existing policy.
>
> I think what I support is sort of a hybrid between A and C in that I
> believe you should be able to use the policy to transfer as often as you
> want, so long as your transfers within any 6 month period under this policy
> don’t exceed a /16. You’d still be able to transfer a /16 under this policy
> and then use other existing policies if you needed more.
>
> Owen
>
> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com> wrote:
>
> 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 <(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/20170209/fd671889/attachment.htm>