[arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks

Paul pmcnary at cameron.net
Fri Feb 19 16:09:14 EST 2016


However I was told by ARIN, a small ISP like me they could claw back any 
Legacy resources
I acquired outside of the ARIN system. The big guys aren't intimidated 
by this but we are.
The money required to even acquire 1 /24 is now big time. And lack of a 
direct allocation
of IPv6 for $500 is a major obstruction for small ISP's.

On 2/19/2016 3:05 PM, Steven Ryerse wrote:
>
> If ARIN does not have the resources to allocate because of runout, how 
> pray tell can an ARIN policy be used to corner the market?  You can’t 
> get blood out of a turnip. There is nothing to stop someone from 
> buying a Legacy block completely outside of ARIN now if they choose to 
> do that.  We know that current ARIN policies are not stopping brokers 
> from doing this - as there is a brisk business of blocks being traded 
> in one way or another.  You are just rearranging deck chairs on the 
> Titanic which has already sunk and is already at the bottom of the 
> sea.  I wonder if the fish down there really care where those chairs 
> are arranged?
>
> The common sense thing to do would be to modify ARINs policies to 
> encourage all transactions to go thru ARIN which would lead to more 
> supply for everyone.  This would be in line with ARIN’s mission to 
> further the Internet. Unfortunately common sense rarely prevails in 
> this community.
>
> /Steven Ryerse/
>
> /President/
>
> /100 Ashford Center North, Suite 110, Atlanta, GA  30338/
>
> /770.656.1460 - Cell/
>
> /770.399.9099- Office/
>
> Description: Description: Eclipse Networks Logo_small.png℠Eclipse 
> Networks, Inc.
>
> ^        Conquering Complex Networks ^℠ ^
>
> *From:*arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> *On Behalf Of *Jason Schiller
> *Sent:* Friday, February 19, 2016 1:08 PM
> *To:* Randy Carpenter <rcarpen at network1.net>
> *Cc:* ARIN PPML <arin-ppml at arin.net>
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating 
> needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks
>
> Removing barriers would allow companies with enough money to out right 
> buy more than a two year supply of IPv4 addresses if they believed 
> their likelihood of needing a longer time horizon justifies the cost.  
> They could complete the transaction, transfer the address space in 
> whole, and use as they desired over whatever time horizon they saw fit.
>
> This is different to a buying a future where money is paid to hold 
> IPv4 addresses, and make them available for sipping from in two year 
> (or less) sized increments under the ARIN transfer policy.  This 
> requires demonstrating efficient utilization of currently held 
> resources, and then only permits a maximum transfer of two year 
> supply, after which a new demonstration of efficient utilization of 
> currently held resources, and a new two year window can be established.
>
> This second approach has much risk associated.  Risk of the transfer 
> source going bankrupt, risk of the transfer source breaching the 
> contract, risk of the transfer source finding more favorable terms and 
> transferring the remaining future to another party, risk of the 
> transfer recipient having underutilization and have an inability to 
> get additional resources, risk of transferring the resources to the 
> wrong OrgID (realizing a new use case under one OrgID evaporates, and 
> a different new use case appears under a different OrgID).
>
> As such, the inherent risk of a future will likely limit the spend.
>
> Reducing or eliminating this risk will encourage the behavior.
>
> This is different than just paying money to get unlimited use of IPv4 
> resources outside of ARIN policy, with no transfer, and only a letter 
> of authority to route the space, a re-allocate or re-assignment SWIP, 
> or a public comment indicating who has the right of use.
>
> This third approach has the risk of the source going bankrupt and the 
> risk that the source could easily revoke the LOA, SWIP or public 
> comment, and ask providers to not route the IP space.  It has the 
> added reputation risk that the recipient of the IP space is acting 
> below board.
>
> As such risk is even greater than the previous case and will likewise 
> have a greater limitation on the spend.
>
> The final case is renting of IPv4 space.  This differs from the 
> previous case in that the spend is ongoing (e.g. monthly or yearly).
>
> The risk is similar to the previous case except if the IPv4 addresses 
> are revoked payment is stopped.  While the recipient has not lost 
> their future spend, they also may find themselves suddenly out of IPv4 
> space.  With the difficulty of renumbering, they may find they are 
> forced to pay predatory pricing from some period of time, and double 
> rent new IP space while they number out of the old (excessively high 
> cost) IPv4 space. Furthermore, if IPv4 space is not available for rent 
> at a reasonable price, they will be locked in to paying an 
> unreasonable price.
>
> Due to the uncertainty and possibility of lock in and predatory 
> pricing I would argue this arrangement is even more risky than the 
> previous arrangement if long term (think more than 2 years) use of 
> IPv4 is desired.
>
> ___Jason
>
> On Thu, Feb 18, 2016 at 11:29 PM, Randy Carpenter 
> <rcarpen at network1.net <mailto:rcarpen at network1.net>> wrote:
>
>
>     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
>     milton at gatech.edu <mailto:milton at 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-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net> <arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>> on behalf of Jason
>     > Schiller <jschiller at google.com <mailto:jschiller at 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 <
>     > vaughn at swiftsystems.com <mailto:vaughn at swiftsystems.com> > wrote:
>     >
>     >
>     >
>     > +1
>     >
>     > Sent from my mobile device, please forgive brevity and typos.
>     >
>     > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com
>     <mailto:owen at delong.com> > wrote:
>     >
>     >
>     >
>     >
>     > +1 — McTim said it very well.
>     >
>     > Owen
>     >
>     >
>     >
>     >
>     > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com
>     <mailto:dogwallah at 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 < lsawyer at gci.com
>     <mailto:lsawyer at 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
>     <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 at arin.net
>     <mailto:ARIN-PPML at arin.net> ).
>     > Unsubscribe or manage your mailing list subscription at:
>     > http://lists.arin.net/mailman/listinfo/arin-ppml
>     > Please contact info at arin.net <mailto:info at 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 at arin.net
>     <mailto:ARIN-PPML at arin.net> ).
>     > Unsubscribe or manage your mailing list subscription at:
>     > http://lists.arin.net/mailman/listinfo/arin-ppml
>     > Please contact info at arin.net <mailto:info at 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 at arin.net
>     <mailto:ARIN-PPML at arin.net> ).
>     > Unsubscribe or manage your mailing list subscription at:
>     > http://lists.arin.net/mailman/listinfo/arin-ppml
>     > Please contact info at arin.net <mailto:info at 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 at arin.net
>     <mailto:ARIN-PPML at arin.net> ).
>
>     > 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 contactinfo at arin.net <mailto:info at arin.net> if you experience any issues.
>     >
>     >
>     >
>     > --
>     > _______________________________________________________
>     > Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com> |571-266-0006
>     <tel:571-266-0006>
>     >
>     >
>
>     > _______________________________________________
>     > PPML
>     > You are receiving this message because you are subscribed to
>     > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     > Unsubscribe or manage your mailing list subscription at:
>     > http://lists.arin.net/mailman/listinfo/arin-ppml
>     > Please contact info at arin.net <mailto:info at 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 at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
> -- 
>
> _______________________________________________________
>
> Jason Schiller|NetOps|jschiller at google.com 
> <mailto:jschiller at google.com>|571-266-0006
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160219/4268040f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160219/4268040f/attachment.jpe>


More information about the ARIN-PPML mailing list