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] > <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 >
_______________________________________________ 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.
