Yes, I was well aware of that. Is there anything you believe to be incorrect in 
my comments as a result? Otherwise, I’m not sure what you are getting at.

I believe a unique routing policy or multiple peers is sufficient justification.

Absent that, I believe that an entity which qualifies for PI and intends to 
multihome later should legitimately be able to obtain an ASN to simplify their 
build-out in anticipation of later multihoming. 

This last part, is, IMHO, the only change that should be contemplated vs. the 
current existing policy.

Owen

> On Feb 26, 2015, at 9:45 AM, Masato Yamanishi <[email protected]> wrote:
> 
> Owen and Usman,
> 
> In following comments, did you consider we are discussing "public" AS numbers?
> Since we are discussing "public" AS, we should have some kind of 
> justifications why it should be globally unique.
> 
> Regards,
> Masato
> 
> 
> 2015-02-25 18:39 GMT-06:00 Owen DeLong <[email protected] 
> <mailto:[email protected]>>:
> Usman, since an AS is defined as “A collection of prefixes with a common 
> routing policy”, what would you use one for if not to connect to other 
> autonomous systems? If you are connecting to a single other autonomous 
> system, then, arguably it is impossible for your prefixes to have a distinct 
> routing policy and you are, therefore, part of that other AS. If you are 
> connecting to multiple other autonomous systems, then, you are, by definition 
> multihomed.
> 
> If you have some better way to manage this, I’m all ears.
> 
> Owen
> 
>> On Feb 25, 2015, at 16:26 , Usman Latif <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> ASN is an identifier for an autonomous system - so theoretically speaking, 
>> an ASN should have no dependency on multihoming or single homing
>> However, what we need is a better way to regulate assignment of ASNs so 
>> their allocation doesn't become wasteful..
>> 
>> Regards,
>> Usman
>> 
>> 
>> On 26 Feb 2015, at 11:16 am, Skeeve Stevens <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> Hi Secretariat,
>>> 
>>> I would like to understand the policy/secretariats view on the 
>>> justification/requirements of subsequent ASN resource requests.
>>> 
>>> 
>>> 
>>> ...Skeeve
>>> 
>>> Skeeve Stevens - Senior IP Broker
>>> v4Now - an eintellego Networks service
>>> [email protected] <mailto:[email protected]> ; www.v4now.com 
>>> <http://www.v4now.com/>
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 
>>> <tel:%2B61%20%280%29414%20753%20383> ; skype://skeeve <>
>>> facebook.com/v4now <http://facebook.com/v4now> ;  
>>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>>> <http://linkedin.com/in/skeeve>
>>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>>> www.theispguy.com <http://www.theispguy.com/>
>>> 
>>> IP Address Brokering - Introducing sellers and buyers
>>> *              sig-policy:  APNIC SIG on resource management policy         
>>>   *
>>> _______________________________________________
>>> sig-policy mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
>> *              sig-policy:  APNIC SIG on resource management policy          
>>  *
>> _______________________________________________
>> sig-policy mailing list
>> [email protected] <mailto:[email protected]>
>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> [email protected] <mailto:[email protected]>
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to