To be clear, I’m proposing a 6 month sliding window.

Owen

> On Feb 9, 2017, at 08:39 , Jason Schiller <[email protected]> wrote:
> 
> 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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>> > <mailto:[email protected]>> 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 ([email protected] 
>> > <mailto:[email protected]>).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml 
>> > <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> > Please contact [email protected] <mailto:[email protected]> if you experience any 
>> > issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected] 
>> <mailto:[email protected]>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact [email protected] <mailto:[email protected]> if you experience any 
>> issues.
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected] 
>> <mailto:[email protected]>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact [email protected] <mailto:[email protected]> if you experience any 
>> issues.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|[email protected] 
>> <mailto:[email protected]>|571-266-0006 <tel:(571)%20266-0006>
>> 
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|[email protected] 
>> <mailto:[email protected]>|571-266-0006 <tel:(571)%20266-0006>
>> 
> 
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|[email protected] 
> <mailto:[email protected]>|571-266-0006
> 

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to