[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