Are you arguing that by removing the barriers that it would make it more difficult for Google to get more addresses? If not, then the point is moot.
thanks, -Randy ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton L mil...@gatech.edu wrote: > Really. Am I going to have to be the first to point out the irony of Google > employees complaining that companies with "deep pockets" and "the most > profitable services" will dominate the address market if we make minor > relaxations of need assessments? > > > > > What's wrong with this picture? Think, folks. > > > > > Isn't it obvious that companies like Google are in a very good position to get > the addresses they want - via less than transparent market mechanisms such as > options contracts and acquisitions? And isn't it possible that they might be > trying to prevent smaller companies from participating in the market by > throwing up artificial barriers? > > > > > All this talk of "fairness" overlooks the fact that it's more fair to have > simple, transparent bidding and less bureaucracy. Smaller bidders can easily > afford smaller chunks of numbers, and they benefit from the reduced > administrative burden and delays associated with pointless and restrictive > needs assessments. When I hear smaller ISPs who need addresses making Jason's > arguments, I might take them seriously. Until then, no. > > > > > > --MM > > > > > From: arin-ppml-boun...@arin.net <arin-ppml-boun...@arin.net> on behalf of > Jason > Schiller <jschil...@google.com> > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > +1 to what MCTim, Owen, and Vaughn said. > > In general I oppose transfers with no need. > > If there are "networks in need of additional IPv4 addresses", surely they > should > be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > I'd also rather not encourage one competitor in a business segment to be able > to > better stockpile addresses and for that to become a competitive advantage > against other providers in the space. Additionally if this is done in a wide > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > This policy would also allow for companies with the deepest pockets and the > most > profitable services to concentrate IPv4 space. I'm not sure that is more > "fair" > than the pre-existing framework for "fair". > > __Jason > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > vau...@swiftsystems.com > wrote: > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < o...@delong.com > wrote: > > > > > +1 — McTim said it very well. > > Owen > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwal...@gmail.com > wrote: > > I am opposed. > > If there are " networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > Regards, > > McTim > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsaw...@gci.com > wrote: > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked > this policy. > AC members and ARIN staff are looking for additional feedback, as well as your > position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this > week's > AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization > to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more > timely > fashion directly from the > current holder. The result is that the data visible in ARIN registry may > become > more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 > and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement > of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing > those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding > any > policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources > of > the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on recipient of the transfer" > from: > "The recipient must demonstrate the need for up to a 24-month supply of IP > address resources under current ARIN policies and sign an RSA." > to: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding > any > policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > ARIN) > have now been > exhausted, networks in need of additional IPv4 addresses have shifted away > from > the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that > need. Accordingly, the RIR's > primary responsibility vis-à-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the > past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and > that the transferring > organization has the valid authority to request the transfer, the transaction > completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML@arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML@arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps| jschil...@google.com |571-266-0006 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
