Understood your point. Thx. Regards, Masato Yamanishi
2015-02-26 18:19 GMT-06:00 Owen DeLong <o...@delong.com>: > I’m not opposed to qualifying some cases where private AS may also work, > because in those cases, frankly, I think most organizations will either use > a private AS rather than go to the trouble of applying, or, they may have a > good reason (future plans, etc.) for wanting to get a public AS and not > have to re-run all their peering sessions later. > > Owen > > On Feb 26, 2015, at 13:40 , Masato Yamanishi <myama...@gmail.com> wrote: > > Owen, > > I don't want to discuss too much details since I'm acting chair, > but I'm afraid that "unique routing policy" is vague and it may qualify > some usecases that private AS may also work. > So, what is the definition or understanding for "unique routing policy" in > ARIN? > > Masato Yamanishi > > Feb 26, 2015 3:14 PM、Owen DeLong <o...@delong.com> のメッセージ: > > 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 <myama...@gmail.com> 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 <o...@delong.com>: > >> 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 <osma...@yahoo.com> 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 <ske...@v4now.com> 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 >> ske...@v4now.com ; www.v4now.com >> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >> facebook.com/v4now ; <http://twitter.com/networkceoau> >> linkedin.com/in/skeeve >> twitter.com/theispguy ; blog: www.theispguy.com >> >> IP Address Brokering - Introducing sellers and buyers >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> > > >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
