I could live with this. Do you need help putting it into a proposal template?
Owen > On Sep 28, 2015, at 12:59 , Bill Buhler <[email protected]> wrote: > > OK, how about this: > > Small end users and ISPs are allowed to obtain IPv4 address blocks without a > needs test as long as the following criteria are met: > > a. The total size of their ARIN allocations at any time of the process > does not exceed a /20 if a ISP or /22 for an end user. > b. They cannot purchase IP address from the transfer market more than > three total times to reach this size, including the initial operation. > c. None of the addresses purchased can be transferred to any other > entity for twenty-four months following the date of the last transfer. > d. If the company ceases operations within the twenty-four month window > the addresses are automatically transferred to the ARIN free pool. After that > period of time regular transfer rights exist. > e. All subsequent allocations / transfers require regular needs testing > after the initial twenty-four month allocation window. > f. Eligible entities for this policy consist of ISPs and End users who > have a unique physical address in the ARIN region at the suite level. Meaning > if two companies share the same suite they are not eligible to both have ARIN > allocations. > > > ------------------- > > I believe that meets all of your concerns. I would prefer companies get > everything they think they will need in one operation, but I don’t want to > have fear drive them into buying the max amount just in case. > > Best regards, > > Bill Buhler > > From: Owen DeLong [mailto:[email protected]] > Sent: Monday, September 28, 2015 1:09 PM > To: Bill Buhler > Cc: Adam Thompson; [email protected] > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 28, 2015, at 11:50 , Bill Buhler <[email protected] > <mailto:[email protected]>> wrote: > > Thanks Owen for your thoughts, it sounds to me like we are getting a lot > closer to a compromise, would this be a sufficient circuit breaker: > > Small end users and ISPs are allowed initial and follow up transfers up to a > /20 for ISPs or /22 for end users from the market. These transfers can be > conducted in no more than three operations over a 24 month period. None of > the transferred addresses can be transferred to another entity for > twenty-four months following the date of the last transfer. If the company > ceases operations within that twenty-four month window the addresses > automatically become property of ARIN and are placed in the free pool. After > that period of time regular transfer rights exist. > > Property is a loaded term in this context. > > I would be OK with the proposal, but we would need to change “automatically > become property of...” to “are automatically returned to the ARIN free pool”. > > Also, you’re still allowing “follow up” transfers without needs testing. So > there’s ambiguity as to whether you mean follow-ups up to a total holding of > (/20,/22) or if you mean there’s a new (/20,/22) followup cycle each 24 > months. > > The former would be acceptable to me. The latter would not. > > > > All subsequent allocations / transfers require regular needs testing. > > Eligible entities for this policy consist of ISPs and End users who have a > unique physical address in the ARIN region at the suite level. Meaning if two > companies share the same suite they are not eligible to both have ARIN > allocations. > > > My reasoning of allowing follow up transfers is within the first two years, > but not allowing transfers out for twenty-four months from the last transfer > is it encourages companies to go for a small initial allocation rather than > buying their max possible size initially knowing that they next time they > will need to go through needs testing. > > I don’t see any reason to worry about this in the transfer market. We allow > for a 24 month need, so there’s no overall advantage IMHO to facilitating a > smaller initial transfer and allowing subsequent transfers without need, but > if people feel this is useful, I can live with it. Personally, I think it > just encourages fragmentation of the routing table without providing a > tangible benefit. > > Owen > > > > Any thoughts? > > Bill Buhler > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] On > Behalf Of Owen DeLong > Sent: Monday, September 28, 2015 11:11 AM > To: Adam Thompson > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > I’m not going to support anything that provides a blanket exemption from > needs basis. > > I will support a change which allows an initial > allocation/assignment/transfer of a minimal block of addresses (up to a /22 > for an end-user or up to a /20 for an ISP seems reasonable to me) so long as > it also includes anti-flip protections and some language preventing spinning > up related party entities strictly for address acquisition. > > I believe this would address most of the concerns expressed (other than those > seeking to eliminate needs basis altogether). > > Owen > > On Sep 26, 2015, at 19:48 , Adam Thompson <[email protected] > <mailto:[email protected]>> wrote: > > At this point, I support anything that looks like a compromise so we can get > *any* change in policy at all... So this looks like a decent compromise to > me. Yes, it'll have to be revisited in a couple of years' time; yes, the > specifics probably aren't perfect. The community can change those. The policy > can even be written such that ARIN staff can change them independently > (although this doesn't seem to be a popular model). > Insisting on perfection is just hamstringing the entire service region... > both the speculators *and* legitimate users. > -Adam > > > > On September 26, 2015 8:47:46 PM CDT, Brian Jones <[email protected] > <mailto:[email protected]>> wrote: > I find Bill's proposal an interesting middle ground approach. I do not > believe completely eliminating needs-based justification for addresses is the > correct thing to do. > > -- > Brian > > On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler <[email protected] > <mailto:[email protected]>> wrote: > Having watched this for the last couple of years let me make a couple of > observations / one proposal: > > There seems to be a lot of fear on both sides of this debate, on the needs > test side there seems to be a complete fear of monopolization of the IP > address space by those with deep pockets. > > On the other side there seem to be a couple of thoughts: > > 1. It’s a market, markets work best when freed from constraints that > increase the complexity of non-harmful transactions, and that allowing > companies to more freely exchange IP resources is not harmful. > 2. Not liking to justify future and current operations to a third > party / fear of rejection by this process. > > I may not have encapsulated both arguments well, and these have been hashed > over again and again for the last few years. So what is different today? ARIN > has allocated every last resource from the free pool, and has a long waiting > list. > > So what if we strike a compromise? What if some restrictions were put on > allocation size and frequency without a needs test and left only the truly > large or frequent transactions to do it. Something like this: > > Every legal entity can obtain up to a /22 from the transfer market every > year, in up to two transactions. They may not transfer these resources out of > their network within twelve months. Each legal entity has to occupy a unique > address (suite level) from any other entity in the ARIN database. > > All transfers larger than a /22 need to have needs based justification done > based on the current model. > > > If you wanted to speculate, you would need to spin-up dozens of entities all > with unique mailstops, and you would have to camp on the addresses for a > year. Meanwhile the small end users and ISPs could obtain up to a /22 of a > resource that with a lot of careful use of NAT would support a fairly large > public network. > > Best regards, > > Bill Buhler > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] On > Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 11:48 AM > To: Owen DeLong > > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > Owens comment from below: > “2. To the extent that there is supply, anyone who needs addresses can get > them already. Needs-based evaluation does not prevent those with need from > getting addresses… It prevents those without need from getting them.” > > Owen’s comment is absolutely false!!!!! It allows large organizing who > request resources to get what they need or something smaller. It allows > medium size organizations who request resources to get what they need or > something smaller. It allows small organizations who request resources to > get what they need or nothing, and there is no other source to get resources > if ARIN rejects a request, but the open market which Owen and others seem to > wish did not exist! > > It is time to fix this inequity and removing needs tests would be a big help > to small organizations who really need resources! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 <tel:770.656.1460> - Cell > 770.399.9099 <tel:770.399.9099>- Office > > ℠ Eclipse Networks, Inc. > Conquering Complex Networks℠ > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] On > Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea <[email protected] > <mailto:[email protected]>> wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel > that it's not worth changing -- the problem statement argument is weak at > best. > the outcome is that everyone that will need IP addresses will be able to get > them. Isn't that quite definitive and clear? > > Sure, except it isn’t actually an outcome of the proposal on many levels: > > 1. The proposal does nothing to guarantee a supply of addresses or even > increase the supply. > 2. To the extent that there is supply, anyone who needs addresses can get > them already. Needs-based evaluation does not prevent those with need from > getting addresses… It prevents those without need from getting them. > 3. The definitive outcome from the policy change, if there is such, is that > those without need will now be more easily able to acquire addresses, > potentially preventing those with need from acquiring them. > > > > It is potentially enabling organizations with more money than need gain more > resources, potentially at the expense of non-profit and educational > organizations who might not be able to raise cash for additional IPv4 space > [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations > will have the chance at getting some of the IP space from the market? And if > the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who > do you think will say: I'll give it for free to this educational organization > (because they have proven the need to ARIN) instead of giving it for money to > this commercial entity (that may or may not have a demonstrated need need for > it). > > > Contrary to your statement, there have been addresses returned to ARIN and > there have been organizations who chose to transfer addresses to those they > found worthy rather than maximize the monetization of those addresses. > > OTOH, having a policy like this in place certainly makes it easier to > manipulate the market to maximize the price. > > > I think we need to wake up. Keeping needs-based criteria in the policy will > only cause SOME transfers to be driven underground and block some others. > > I think claiming that those of us who believe needs-based criteria is still > useful are asleep is unwarranted. > > > Changing policy just to (potentially) improve the accuracy of a database > seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE > region. I would say it's not just potential, it is real and visible. > > Please provide the metrics on which you base this assertion. How was RIPE-NCC > accuracy measured prior to the policy change and to what extent was it > improved as a result of this policy change. What mechanism was used to > determine that the measured increase in accuracy was the result of the > particular policy abandoning needs-based evaluation? > > Owen > > > > Richard > regards, > Elvis > > > ________________________________________ > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> on behalf of > Dani Roisman <[email protected] <mailto:[email protected]>> > Sent: Thursday, September 24, 2015 6:20 PM > To: [email protected] <mailto:[email protected]> > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN <[email protected] <mailto:[email protected]>> > | To: [email protected] <mailto:[email protected]> > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <[email protected] <mailto:[email protected]>> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > <https://www.arin.net/policy/proposals/2015_9.html> > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like > to ask that in addition to any overall support or lack thereof, you also > review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any > refinements to the changes made which you think will improve this should > these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any > adjustments to the policy changes which, if implemented, would gain your > support? > > -- > Dani Roisman > _______________________________________________ > 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. > > > _______________________________________________ > 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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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]). 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.
