[ppml] Markets, pricing, transparency, 2008-2 / 8.3.9

Tom Vest tvest at pch.net
Mon Mar 17 15:44:48 EDT 2008


On Mar 17, 2008, at 1:15 PM, John Curran wrote:

> At 12:45 PM -0400 3/17/08, Tom Vest wrote:
>>
>> Therefore I strongly recommend that the community reject this
>> suggestion and get on with more realistic, sustainable alternatives.
>
> Tom -
>
>    Could you succinctly express such an alternative?
>
> /John

Hi John,

I'll try to be as succinct as possible.

To be viable, any solution will have to be able to maintain the  
"central registry" function over time.
(by this I mean basically reverse delegations accurately associated  
with whois entries that are accurately associated with real-world  
institutions).

There are multiple reasons why this is not optional, but I don't  
think they're particularly controversial (e.g., Geoff Huston also  
leads his presentation on APNIC's resource transfer proposal with the  
same requirement), so I'll skip them for now.

In order to maintain this function over time -- at least at the "good  
enough" level -- the address delegation function must either be self- 
maintaining, as it is currently thanks to the unitary/hierarchical  
address distribution chain, RIR membership model, incremental address  
delegations, annual membership renewals, and surrounding community  
activities,* or else there must be some top-heavy post-facto  
verification and enforcement mechanisms. No sensible person would  
want the latter whenever the former can do the job. So, the trick is  
to design a mechanism that will deliver the desired outcome -- in  
this case I am assuming only some productive recirculation of  
relatively underused IPv4 address space -- and also permit the  
preservation of that critical registry function, all using only the  
kind of levers/overhead that the community can embrace (e.g., the  
ones in place now), and not the kind that it will rejected outright  
(e.g., the kind that Randy will scold me about).

What sort of mechanisms might achieve this? Some kinds of  
implementations of Randy's oft-mentioned IP ebay might be able to do  
the job, e.g., if transparency can be maintained across all**  
resource transactions, and the data on all** transactions can be  
captured in the central registry. I happen to think that such a  
system would probably have unfortunate side effects (e.g., rapid  
deaggregation, pricing of many operator segments out of the  
existence, et al.), which may or may not be fatal. But those risks  
are understood and accepted, aren't they? I mean, wasn't the whole  
point of having all** delegation actions governed by the same rules  
and policies precisely to mitigate the risk that one community  
member's activities might undermine the whole system, or that some  
aspect of the aggregate results of all delegations might prompt  
community members to withdraw their support for the system, rather  
than trying to fix it? Once the checks go, the balances cannot hold,  
so I'm assuming that these risks are considered acceptable by  
advocates of market-based resource transfers.

If the risks are not acceptable, then I can imagine a community  
policy-driven mechanism of centralized IPv4 recirculation that is  
driven by, alternately, increased recurring membership fees that  
increment based on actual IPv4 holdings, which could be wholly offset  
by much larger bounties that resource holders might earn by returning  
fractional portions of their IPv4 stocks back to the central pool for  
re-delegation.*** Such a system cannot be described any more  
succinctly than the 2008-02 system, so I'll hold off on details  
pending expressions of actual interest. But I do think that such a  
system could be much more effective at providing transitional IPv4  
liquidity over the medium term, and also at preserving the central  
registry, while at the same time discouraging hoarding, speculation,  
massive inflation, closure of the industry to new entrants, external  
intervention, massive industry consolidation -- and also preserve the  
community/policy feedback loop -- and maybe even add marginally to  
the odds/pace of incremental IPv6 deployment.

The thing that makes this approach quite politically challenging is  
that it would require that we all accept -- and literally start  
"recognizing" the costs of the reality of IPv4 free pool exhaustion  
somewhat before the last day that denial is still possible. By  
design, the first and greatest costs would fall on the largest  
resource holders, but presumably as a group they are much better  
capable of absorbing those costs, and certainly more capable of  
numbering out of some sub-critical segments and thereby reducing the  
cash cost of participating in the system to zero*** (note: one has to  
assume this anyway in order to believe that they're still going to be  
around and growing after IPv4 exhaustion, so this shouldn't be  
especially controversial).

So, that's my alternative. I'm hoping that we can leverage the  
political/community capital that we've accumulated over the last  
decade-plus to avoid the economic mess that, I believe, is almost  
certainly waiting around the corner. I may be selectively naive about  
the political prospects of anything like this being acceptable. But  
even if that turns out to be true I'll consider the time well spent I  
can to help offset naivete about the economic prospects of  
decentralized, market-based resource transfers working as advertised.

TV


*Economists would describe these collateral activities as mechanisms  
that reduce or eliminate the need for expensive post-facto  
enforcement, and thereby help to reduce the overall "transaction  
costs" associated with maintenance of the central registry.

**In real world this always means "mostly all", but if you don't set  
the bar somewhere, the only realistic goal is "random outcome".

***I haven't tried to work out exact ratios, but for the moment  
imagine an arrangement where the added renewal cost for a /8 could be  
completely offset by the bounty for returning a /16.




More information about the ARIN-PPML mailing list