[arin-ppml] ARIN-2012-3: ASN Transfers - Last Call

[Tom Vest]

On May 4, 2012, at 8:42 AM, Scott Leibrand wrote:

> Tom,
> 
> Can you elaborate on whether you see ASNs as a scarce resource, or whether you see conditions under which they might become scarce? From my perspective, the fact that there are 4 billion 4-byte ASNs, which (unlike IPv4 and IPv6) interoperate quite well with 2-byte ASNs, means that I don't see how your argument about cornering a market for a critical resource would apply in this situation. 
> 
> Thanks,
> Scott


Hi Scott, 

I think it would be best for you to direct that question to someone who actually thinks, or has at least argued, that the possibility of someone "cornering the market" is the greatest or only risk associated with privatizing ASNs. I could imagine what they might say, but since I don't personally believe that to be the case, and I have never in fact argued from that position (while I have actually tried to correct the same spurious association on this very list, and NANOG/new, and NANOG/old, on numerous occasions), I think I'll let someone else take a turn arguing on behalf of that apparently undying straw man.

If, as you suggest, four-byte ASNs interoperate quite easily with two-byte ASNs, then it doesn't sound like there's any particularly compelling need to introduce yet another scarcity-oriented distribution mechanism *at this particular moment*, when we're already facing a very profound, risky, and controversy-prone global transition in business and operational practices related to IP addressing. Choosing to add yet another layer of uncertainty/opacity/friction on top of the uncertainty/opacity/frictions that we've already embraced with IPv4 markets, which will themselves only compound the IPv6-related uncertainty/opacity/frictions that were perhaps unavoidable, is IMO a really bad, bordering-on-reckless idea.

That said, I can think of at least two ways that many/most concerns about the risks associated with ASN privatization could be assuaged by evolving facts on the ground, possibly in the near future: 

(1) Once it becomes clear that (a) established, two-byte ASN-holding operators in every service segment (including consumer access) have started to consistently accept four-byte ASNs, and put them into production rather than returning them for ASN16s, and (b) once it becomes clear that established, two-byte ASN-holding operators of all stripes are consistently offering non-discriminatory "most-favored-ASN-format" treatment to aspiring ASN32-based access/transit customers and peers, then we'll have some basis for confidence that four-byte ASNs are unlikely to be "rejected by the market." Only at that point will we actually *know* what can we only assume at this point, i.e., that there really are "4 billion [unallocated and operationally useful] ASNs, which (unlike IPv4 and IPv6) interoperate quite well," and thus that there is no broad risk of ASN-related scarcity/market manipulation, etc. [Note: alternately, we could simply wait until ASN32s originate the majority of traffic/routes, and the commercial practices of ASN16-only holdouts become irrelevant -- but that would obviously take much longer]. 

(2) Once it becomes clear that (a) established, IPv4-holding operators in every service segment (including consumer access) have started to consistently embrace and integrate IPv6, and (b) once it becomes clear that established operators of all stripes are consistently offering non-discriminatory "most-favored-address-format" treatment to aspiring IPv6-only access/transit customers and peers, then we'll be justified in assuming that IPv6 is unlikely to be "rejected by the market." At that point we'll actually have some basis for believing what at this point can we only hope, i.e., that the TCP/IP-based routing and addressing industry is, in fact, the first such system of its kind in human history to be highly resistant, or maybe even immune, to the sort of systemic (e.g., "adverse selection") problems that have caused all other, similar industries in recorded human history to (severely to catastrophically) fail on a semi-regular basis.

If you are right and my concerns are unfounded, then it seems like at least one if not both of those conditions should be satisfied in the relatively near future. IMO, once at least one of those milestones has been passed, *that* would be the right time to take up an ASN transfer proposal. Not before. 

Conversely, if neither happens anytime soon, then ISTM that it would be prudent to reconsider whether the stated and unstated assumptions underlying the arguments for ASN transfers are in fact valid.

TV


> On May 3, 2012, at 10:32 PM, Tom Vest <tvest at eyeconomics.com> wrote:
> 
>> 
>> On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote:
>> 
>>> On Thu, May 3, 2012 at 6:04 PM, Tom Vest <tvest at eyeconomics.com> wrote:
>>>> 
>>>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote:
>>>> 
>>>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph
>>>>> <christoph.blecker at ubc.ca> wrote:
>>>>>> Simple version: I do not support this policy as written.
>>>>>> 
>>>>>> Longer version:
>>>>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me).
>>>>>> 
>>>>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources.
>>>>>> 
>>>>>> Overall, I think more discussion is needed.
>>>>>> 
>>>>>> Cheers,
>>>>>> Christoph
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
>>>>>> Sent: April-30-12 10:19 AM
>>>>>> To: arin-ppml at arin.net
>>>>>> Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call
>>>>>> 
>>>>>> The ARIN Advisory Council (AC) met on 25 April 2012 and decided to
>>>>>> send the following draft policy to last call:
>>>>>> 
>>>>>> ARIN-2012-3: ASN Transfers
>>>>>> 
>>>>>> Feedback is encouraged during the last call period. All comments should
>>>>>> be provided to the Public Policy Mailing List. Last call for 2012-3 will
>>>>>> expire on 14 May 2012. After last call the AC will conduct their last
>>>>>> call review.
>>>>>> 
>>>>>> The draft policy text is below and available at:
>>>>>> https://www.arin.net/policy/proposals/
>>>>>> 
>>>>>> The ARIN Policy Development Process is available at:
>>>>>> https://www.arin.net/policy/pdp.html
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Communications and Member Services
>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>> 
>>>>>> 
>>>>>> ## * ##
>>>>>> 
>>>>>> 
>>>>>> Draft Policy ARIN-2012-3
>>>>>> ASN Transfers
>>>>>> 
>>>>>> Date: 14 March 2012
>>>>>> 
>>>>>> Policy statement:
>>>>>> 
>>>>>> In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources
>>>>>> and ASNs".
>>>>>> 
>>>>>> Rationale:
>>>>>> 
>>>>>> There are legitimate use cases for transferring ASNs, and no significant
>>>>>> downsides (identified to date) of allowing it.
>>>>>> 
>>>>>> Timetable for implementation: Immediate
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>> _______________________________________________
>>>>>> 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.
>>>>> 
>>>>> The problem with many proposals, this one especially, is that every
>>>>> situation is always looked at from the perspective of "is this
>>>>> technically required." I would argue that many look at every situation
>>>>> from the perspective of "would I benefit from this?" To be fair, most
>>>>> here do align "I benefit" with stewardship, but herein lies the
>>>>> problem.
>>>>> 
>>>>> PPML, policy meetings, etc. are highly dominated by "old school"
>>>>> engineers. I vote at ARIN elections, and consistently see speeches
>>>>> that detail how long each candidate has been supporting stewardship,
>>>>> how they helped pioneer the internet, and so forth. That's great, we
>>>>> love you for it and you command much respect from your peers. The
>>>>> problem that we now face in 2012 is that the community is
>>>>> substantially larger and more diverse than the representation within
>>>>> the ARIN policy community. Some quick observations:
>>>>> 
>>>>> - PPML is predominately engineers, most of whom are not involved in
>>>>> financial decision making for their organizations (or are from
>>>>> non-profits)
>>>>> - Attendees at ARIN meetings are predominately the same folks.
>>>>> - Given these observations, i'm willing to assume that those who
>>>>> actually vote at ARIN elections are mostly the same crew of old school
>>>>> policy makers.
>>>>> 
>>>>> What i'm attempting to argue is that this does not have to be a zero
>>>>> sum game. Just because this policy could benefit the management, bean
>>>>> counters, and marketing gurus of any given commercial enterprise does
>>>>> not mean that stewardship has been abandoned, that ARIN is becoming
>>>>> commercialized, or that we're somehow setting a bad precedent.
>>>> 
>>>> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are.
>>>> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument.
>>>> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible.
>>>> 
>>>> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2.
>>>> 
>>>> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind.
>>>> 
>>>> Thanks,
>>>> 
>>>> TV
>>>> 
>>>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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.
>>> 
>>> Tom,
>>> 
>>> I am not tracking on your example pertaining to ASN privatization. I'm
>>> in support of organizations being able to transfer their ASN
>>> resources, not in support of entities being required to petition
>>> telecom oligopolies to obtain resources. I am strictly in support of
>>> proposals that give our constituents more freedoms, not less.
>>> 
>>> IT/IS, management, and accounting are closely related, often
>>> intersecting disciplines. I strongly believe that the opinions stated
>>> by those opposed in this discussion thread are those of the former,
>>> not of the latter. All 3 (and probably some others) are ARIN
>>> stakeholders that must be represented. This is not to say that the
>>> needs of management and accountants must completely supersede those of
>>> IT/IS, but rather that those needs can be addressed in a manner that
>>> does not unduly burden others.
>> 
>> Hi Jeffrey, 
>> 
>> For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go for 
>> it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. 
>> 
>> As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor.
>> 
>> I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job  you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer:
>> 
>> 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market.
>> 
>> 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential.
>> 
>> 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor.
>> 
>> You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of (2) in favor of (3). And even if you can manage that,  you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. 
>> 
>> I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with (3).
>> 
>> If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status (1) or status (3), then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter.
>> 
>> In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy.
>> 
>> Any takers?
>> 
>> TV
>> 
>> 
>> _______________________________________________
>> 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.