[arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS

[David Farmer]

On 3/30/12 11:54 CDT, Scott Leibrand wrote:
> On Mar 30, 2012, at 9:28 AM, Michael Sinatra<michael+ppml at burnttofu.net>  wrote:
>> You seem to be saying that it's not actual reputation that is being
>> traded, but some sort of misperception that ASNs in a certain number
>> range bring credibility.  So rather than trade on actual reputation
>> (which I would question in itself), you are advocating creating a market
>> where a fake perception of reputation is what's traded.  That doesn't
>> sound to me like a market that will efficiently allocate resources,
>> although it may efficiently allocate misperception.
>>
>> IPv4 number transfers make sense.  IPv6 number transfers do not.  I am
>> on the fence about ASN transfers, but it's arguments like these in favor
>> that are making me increasingly wary.
>
> IMO it's not about reputation, it's about ease of use. A shorter ASN is easier to remember, say, and recognize. When I was setting up peering at a former job, we needed a new ASN for the peering network, and had a few unused ASNs to choose from. We chose the one that was easiest for humans (22212). If we could've easily acquired a 3-digit ASN instead, that would've been even better.
>
> There are fewer than 9999 companies doing peering at IXs, and likely fewer than 999 that have more than a few dozen peers. IMO there's no good reason any of them should have to use a hard-to-remember random 5-digit ASN for peering if they don't want to.
>
> -Scott

This Human Factors based argument makes sense to me.  It is on par with 
making IPv6 allocations on nibble boundaries and the fact that IPv6 has 
zero suppression, because they also makes things easier for Humans. 
Until the Internet starts building itself, Human Factors are always 
going to be an issue to some degree or another.

Number are just numbers to computers.  However, when Humans interact 
with the numbers as part of the system, smaller or easy to remember 
longer sequences will be better and less likely to cause transcription 
or other Human based errors.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================