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

[Jeffrey Lyon]

First off, sorry for the top post. My mobile device is not compliant with
ppml norms.

As a practical matter, only 2 bit ASNs would typically be transferred, but
I don't see any reason to restrict transferability of any ASN.

Thanks, Jeff
On May 4, 2012 3:24 PM, "Owen DeLong" <owen at delong.com> wrote:

> ASNs in toto, probably not.
>
> Desirable ASNs, Vanity ASNs, and 2-byte ASNs (for whatever absurd reason),
> YES.
>
> Absent this issue in any of those categories, can you think of a single
> reason this policy would be desirable?
>
> Owen
>
> On May 4, 2012, at 5: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
> >
> > 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 f
>  o
> > r
> >> 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.
> > _______________________________________________
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120504/545dbe6a/attachment.htm>