Not a new voice, but C for me please. It avoids a bunch of corner cases that A introduces, but is far simpler and easier for everyone to understand than B. It also is more consistent with the original idea of a /16 limit, which gets us the simplification benefit for the vast majority of transfers while avoiding some concerns about making really large transfers too easy. We can always change /16 to something larger once we have experience with using it.
Scott > On Feb 9, 2017, at 9:39 AM, 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]> 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]> 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]> >>>> 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]> >>>>> 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]> 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]> 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]). >>>>>> > 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. >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> -- >>>> _______________________________________________________ >>>> Jason Schiller|NetOps|[email protected]|571-266-0006 >>>> >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|[email protected]|571-266-0006 >>> >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[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.
