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-boun...@arin.net [mailto:arin-ppml-boun...@arin.net]
*On Behalf Of *Jason Schiller
*Sent:* Friday, February 19, 2016 1:08 PM
*To:* Randy Carpenter <rcar...@network1.net>
*Cc:* ARIN PPML <arin-ppml@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
<rcar...@network1.net <mailto:rcar...@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
mil...@gatech.edu <mailto: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
<mailto:arin-ppml-boun...@arin.net> <arin-ppml-boun...@arin.net
<mailto:arin-ppml-boun...@arin.net>> on behalf of Jason
> Schiller <jschil...@google.com <mailto: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 <mailto: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
<mailto:o...@delong.com> > wrote:
>
>
>
>
> +1 — McTim said it very well.
>
> Owen
>
>
>
>
> On Feb 18, 2016, at 10:34 , McTim < dogwal...@gmail.com
<mailto: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
<mailto: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
<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
<mailto: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 <mailto: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
<mailto: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 <mailto: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
<mailto: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 <mailto: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
<mailto:ARIN-PPML@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 contacti...@arin.net <mailto:i...@arin.net> if you experience any
issues.
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschil...@google.com <mailto:jschil...@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@arin.net
<mailto: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 <mailto: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
<mailto: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 <mailto:i...@arin.net> if you
experience any issues.
--
_______________________________________________________
Jason Schiller|NetOps|jschil...@google.com
<mailto: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.
