[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate
tvest at eyeconomics.com
Sat May 21 17:46:45 EDT 2011
Per your suggestion, I'm going to add to the to the list of anticipated adverse direct and indirect/unintended consequences that you started.
However, first I want to introduce a list of general consequences stemming from the exhaustion of the unallocated IPv4 reserves that may or may not be affected positively or negatively by your proposal, or by transfers in general. I think that that is only sensible way to start such an accounting, and I submit that *this* is the context against which your proposal (and all other transfer-related proposals, past and present) should be evaluated.
I'm introducing this now because of some recent off-list communications suggesting that a lack of context has made it difficult for some recent ppml subscribers to to interpret the discussion so far as anything more than the extension of a more general political argument into the address policy sphere.
I. Anticipated Consequences of Exhaustion of the Unallocated IPv4 Resource Pool
1.1. IPv4's status as a critical, non-substitutable -- a.k.a. "bottleneck" -- requirement for engaging in most kinds of "commercial Internet activity" (i.e., anything involving any combination of "high volume," "high reliability," or "managerial independence") means that the exhaustion of unallocated IPv4 reserves will effective close the only neutral channel for accommodating entry into the Internet industry -- which happens to be the same channel through which all current IPv4 address holders came to possess those IPv4 holdings.
1.2. The closure of the only neutral channel for acquiring IPv4 will change current IPv4 holders in two or possibly three important ways. First, it will leave incumbent IPv4 holders as the sole potential providers of the critical, non-substitutable, bottleneck resource without which competitive entry into any segment of the Internet services sector is impossible. This change in status will significantly boost the *absolute* bargaining power of all IPv4 holders over and above whatever level that they enjoyed in the pre-exhaustion period, with the *relative* gain in market power enjoyed by individual IPv4 incumbents varying by degree and potential duration based on the absolute size of their IPv4 reserves.
1.3 The exhaustion of the neutral IPv4 reserves will also affect incumbent IPv4 holders by constraining their traditional, IPv4-dependent mechanisms for attracting and integrating new customers and for accommodating the subsequent growth of existing customers. As these traditional mechanisms become increasingly constrained, incumbent IPv4-based service providers will be compelled to choose between several unappealing options, including
1.3(a) continuing to to provide current IPv4-based customers and services, but foregoing all other revenue opportunities,
1.3(b) freeing up IPv4 for ongoing customer/revenue growth by renumbering most of their own infrastructure with IPv6,
1.3(c) pursuing customer/revenue expansion by raising prices to push low-dollar customers to seek out alternate IPv4 providers and/or to accept smaller IPv4 assignments or other/second-best attachment options -- which today would include NAT, NAT4n, and IPv6,
1.3(d) taking a one-time windfall by liquidating all of their IPv4 holdings and reducing their subsequent service offerings to native IPv6-based customers that are supportable exclusively via native IPv6-based interconnections with accessible native IPv6-based peers and transit providers, or
1.3(e) liquidating as in d and then exiting the market.
1.4 IPv4-based incumbents that opt for any of 1.3(a-d) will be significantly affected in a third way by virtue of the fact that they will compelled to choose *on behalf of all of their customers* how to accommodate inbound and outbound IPv4 and IPv6 traffic exchanges between those customers and any/all networks that are managed by someone else. As long as internal customer demand for interaction with external IPv4-based resources remains high, accommodating demand for such interconnections will create a separate operational (i.e., non-revenue-generating) IPv4 requirement that will be in direct contention with other direct revenue-generating IPv4 assignments.
1.5 Each of the above options that are available to IPv4 incumbents may or may not incorporate an additional revenue stream from the fee-simple sale of IPv4 addresses to third parties. Although there are many other kinds of contractual vehicles that incumbent IPv4 holders might employ to monetize their non-assigned IPv4 reserves in an open transfer market, all of the others produce the same kind of direct customer-provider relations -- and whois responsibilities -- associated with 1.3(a-c) and thus may be ignored. Each fee-simple sale of IPv4 would absolutely reduce internal IPv4 reserves that are required to support current revenue-generating IPv4-based customers and any/all traffic exchanges between internal customers and off-net resources that involve IPv4 on either side. Under current conditions, each offering of fee-simple IPv4 would occur in a market in which aspiring industry entrants might be in contention with other incumbent IPv4-based service providers. Let 1.5(a) denote fee-simple IPv4 transfers between two incumbent, IPv4-holding service providers, and 1.5(b) denote fee-simple transfers between an incumbent, IPv4-holding Internet service provider and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant."
1.6 The approval of an IPv4 transfer market effectively created a new set of stakeholders whose actions could impact the price, availability, and status of IPv4, i.e., non-Internet service providers who can claim title to IPv4 addresses that were allocated under the old system but which are currently idle. Let 1.6(a) denote fee-simple IPv4 transfers between an IPv4-holding non-ISP and a incumbent, IPv4-based service provider, and 1.6(b) indicate a fee-simple transfers between an IPv4-holding non-ISP and a first-time IPv4 recipient, which if subject to a needs/"capability" test would make them a "new entrant."
1.7 The *absolute* bifurcation of market opportunities and bargaining power that will result from the disappearance of a neutral/open source for any kind of portable IP addresses that permit unconstrained (de facto global) interoperability will persist indefinitely unless/until one of three things happens:
1.7(a) the preponderance of IPv4 holders -- i.e., almost all of 1.3(a-c) -- individually choose to forego any potential service market advantages AND any potential future windfalls from IPv4 sales by enabling all of their customers to participate in both inbound and outbound traffic exchanges with native IPv6-based destinations on a transparent, ad hoc, demand-driven basis on par with current IPv4-to-IPv4 connections [note: this would also eliminate any relative advantage associated with IPv4, and thus effectively restore the status quo ante -- i.e., an open market in which possession of any/all IP addressing conferred the same capabilities and opportunities to all address holders]. Call this this "open-at-will" scenario.
1.7 (b) Fee-simple transfers of IPv4 address continue over an extended period, until eventually the market(s) reach a point where no service provider enjoys any market advantage over any other based solely on the distribution of IP addresses. This point might correspond to a moment in the distant future when the Internet industry hits the TCP/IP-imposed ceiling of 2^32 independent service providers each holding exactly one IPv4 address. Alternately, it might happen in the marginally less distant future, e.g., when the the population of post-allocation, fee-simple IPv4 buying, IPv6-based service providers grows so vast and powerful as to dominate the population of incumbent, pre-allocation fee-simple IPv4 selling service providers that they've been competing against in the interim. Call this this "decision-by-demographics" scenario.
1.7 (c) Insufficient fee-simple IPv4 acquisition opportunities at price points that are sustainable by aspiring competitive entrants causes the transfer market to fail. Incumbent IPv4 based service providers continue to accommodate new customer growth, albeit with varying combinations of IP4, IPv6, and private addressing that have no effect on IPv4's status as a critical, non-substitutable "bottleneck" for engaging in commercial Internet activities. The Internet becomes progressively more complex and expensive to operate, but it still works -- at least for the generation of service providers that predated the exhaustion of the unallocated IPv4 address pool. After that, anyone with an ambition to become an independent commercial Internet content or service provider just has to buy one of the incumbent providers. For everyone else, the Internet is closed. Call this the "numbers-as-land" scenario.
1.7 (d) Some new, as-yet unimagined technology that eliminates the IPv4-IPv6 incompatibility emerges, or alternately a new networking paradigm that is both widely regarded as superior to TCP/IP AND is as transparent to TCP/IP as TCP/IP is to physical media makes the whole problem go away. Call this the "saved-by-magic" scenario.
II. Suggested Adverse Consequences of Mike's Proposal to Eliminate Needs ("Capability") Testing
2.1 Market distortions will happen due to the selfish actions of speculators, including market cornering attempts.
2.2 Disaggregation will increase.
2.3 It is too radical a change, and change should appropriately come incrementally, like extending the length of the needs window.
2.4 It will make it easier for bad players like spammers to get addresses.
2.5 It will run the risk of actually making Whois less accurate.
2.6 Addresses will be used less efficiently if we only rely on price to drive their productive use.
2.x Others, forthcoming
III. Suggested Positive Effects of Mike's Proposal to Eliminate Needs ("Capability") Testing
3.1 Provides an incentive for more transactions to be registered by ARIN
3.2 Provides an incentive for legacy space to be brought under RSA
3.3 Provides for explicit protections against review audits for RSA holders after one year, bringing RSA rights more in accord with LRSA rights.
3.4 Reduces transaction costs for transferrers
3.5 Reduces ARIN costs for needs analyses
3.6 Aligns ARIN policy with most possible interpretations of the legal rights of legacy holders
3.7 Imposes a yearly limit on needs-free transactions intended to prevent cornering.
My own initial interpretation:
One immediate and direct effect of eliminating needs/"capability" testing would be to greatly expand the demand side of the IPv4 market in two way: by effectively legalizing the participation of market makers (a.k.a. "speculators") that have no direct material interest in Internet production themselves, and by enabling such speculators -- or anyone else, including incumbent, IPv4-based service providers -- to express potentially infinite demand for IPv4, limited only by whatever the (NDA-shrouded) market will bear.
As a very distant second order effect, the elimination of a needs/"capability" testing might also increase the supply of IPv4 -- but the only way that I can imagine how the proposed change might have that effect would be IF the newly-legalized speculators actually turn out to be *much better and much faster* than both incumbent IPv4 holders and aspiring new Internet service providers are both at locating and liberating idled IPv4, and at moving it back into productive use as quickly as possible. In other words, if the speculators could bring IPv4 to market at a price that is actually *below* what it would cost any actual network service provider to acquire it and bring it into useful service, then the delta between those two price points would represent 100% of the "supply premium" created by eliminating the needs requirement.
But in the real world, there's no way that that "supply premium" would be a positive number. Much more likely that it would be a very very large negative number.
And that negative supply contribution would be *on top of* the many and varied direct and indirect/unintended consequences that would result if this proposal were approved -- details of which I'll save for a later message...
On May 20, 2011, at 3:56 PM, Mike Burns wrote:
> Hello to the list,
> Per what Tom wrote at the bottom, I am all for considering the consequences of my proposal, intended or otherwise.
> So I believe the consequences we have considered, and please add to this list if you want, are:
> I figure we have addressed these issues enough, and that we are rehashing discussions to no additional benefit.
> And I have had the opportunity to address the intentions of the policy proposal, which are:
> And likewise we have fairly addressed these issues.
> Without considering (any more) the merits of those prior discussions, I would like to invite the consideration of any other potential benefits or consequences which we have not discussed.
> I am cognizant that this is proposal is a significant departure, and that the discussion of similar policy in APNIC consumed several years.
> I think we have covered pretty much all the bases in our relatively short but active discussion period, but I agree with Tom that we really should stretch our minds to consider all the potential pitfalls.
> So did we miss anything, or is there anything left to be said on the topics arrayed above? Any large loopholes or gotchas? Risks or threats we haven't considered?
> Maybe the increased/decreased exposure of ARIN to lawsuits?
> (I will admit to enjoying reading my own words. But as they are growing tiresome to me, they must be coma-inducing to you by now.)
> Of course I don't mean to cutoff any discussions about any topic, if you think there is more to add.
> ----- Original Message ----- From: "Tom Vest" <tvest at eyeconomics.com>
> To: "Chris Engel" <cengel at conxeo.com>
> Cc: "Mike Burns" <mike at nationwideinc.com>; <arin-ppml at arin.net>
> Sent: Friday, May 20, 2011 3:09 PM
> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate
> On May 20, 2011, at 1:24 PM, Chris Engel wrote:
>> Excising a particular section of this thread for the sake of brevity...
>>> Fair enough, you prefer to argue logic rather than facts:
>>> Please provide a negative proof that "logic" could never lead any future
>>> address user, potential address buyer, and/or potential address seller to
>>> conclude that registration would not advance their own private interests.
>>> Please provide a negative proof that "logic" could never lead any future
>>> address user, potential address buyer, and/or potential address seller to
>>> embrace "sales-friendly registration" but simultaneously reject
>>> "operationally relevant registration" (i.e., the kind that makes whois an
>>> appropriate subject of interest for community deliberation).
>>> Please provide a negative proof that "logic" will BOTH always lead all future
>>> address users, address buyers, and address sellers to self-maintain
>>> "operationally relevant registration" for themselves in perpetuity, AND that
>>> the attainment of that outcome by means of needs-free transfers could
>>> never have any unintended consequences that might be as serious or more
>>> serious than some marginal degradation of whois accuracy.
>> I don't think the above is a fair tactic for debate. You are asking Mike to prove a logical fallacy. Furthermore, when you start using words like "never" and "always" when discussing human behavior as benchmarks for judging the legitimacy of a system...your standards themselves appear absurd. If we applied the same standards for judging the appropriateness of a "needs" based policy, it would assuredly fail as well. Systems designed to regulate human behavior cannot achieve a uniformity of results approaching mathematical perfection, nor need they do so to be effective (IMO).
>> If you want to argue that it's likely a substantial number of individuals would have logical reasons for not wanting to maintain accurate registration under the policy Mike proposes...that's (IMO) a reasonable standard to base an argument on. Not sure whether I would agree with that proposition or not...but the standard is reasonable. Asking Mike to provide a standard of proof that couldn't allow for even a single exception isn't (IMO).
>> Christopher Engel
>> (Representing only my own views)
> Hi Chris,
> Thanks for the reactions. Of course you are right on this count. My apologies to Mike for demanding what is, technically, logically impossible to deliver.
> My intent was not to be merely hyperbolic, but rather to *strongly* suggest that we all engage our imaginations fully when considering the range of strategic responses that might seem to be "rational" from the perspective of any clever entrepreneur who may or may not have any long-term interest in what happens to the Internet or to others who count the Internet for their livelihood or anything else, once s/he is done. Granted, this year we're all operating in an environment that has been significantly shaped by the unintended consequences of last year's strategic adjustments to the previous year's entrepreneurial cleverness, and so on... I mean, who could have anticipated that DWDM might trigger changes in SFP policies that helped to ignite our first crash, or that widespread diffusion of P2P might prompt another shift in commercial strategy that could in turn precipitate a run on the ASN16 reserves?
> Suffice it to say that there are always plenty of smart people out there working out every conceivable new angle that might be exposed by the next change in policy and/or technology and/or market structure -- and in general, at most times, we all benefit tremendously from that fact. But that only remains true as long we do not, through omission or commission, open up any loopholes that are big enough to allow to whole industry to fall through, into who-knows-what. These days it's not really possible to doubt that such things can and in fact do happen from time to time.
> I submit that the removal of "capability" testing would not only represent an irreversible change, but also has the potential to create a number of potentially fatal loopholes. And so in this particular case, I recommend that we proceed only if/after we can first achieve a very high level of confidence that no serious risks or threats are immediately created thereby.
More information about the ARIN-PPML