So it's back to what I said originally. You're claiming that an ASN is required in order to be a fully fledged member of the PI utilising community. You're also claiming that an ASN isn't an operational element anymore, that it's more like a license to be able to use PI space to it's fullest extend.
If it is true, then the only sensible way forward is to allocate them as you become a community member. So we're back to "Become an APNIC member, get an ASN" Is that really what people are saying and is it really a sensible thing here? -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) [email protected] To promote the Internet's benefits and uses, and protect its potential. On Sat, Feb 28, 2015 at 10:08 AM, David Farmer <[email protected]> wrote: > On 2/27/15 17:41 , Dean Pemberton wrote: >> >> On Sat, Feb 28, 2015 at 8:03 AM, David Farmer <[email protected]> wrote: >> >>> >>> Don't allocated one if they don't want one. But if they want one, and >>> they >>> already have PI, or getting new PI, then why say no? And its not >>> regardless >>> of need, more accurately in anticipation of future need. >>> >> >> Nope - you almost had me, but now you've lost me again, well done. > > > Sorry, let me try one more time. > >> What you are suggesting *IS* regardless of need, and thats what I >> think people are missing. >> If you are not required to demonstrate need to get something, then it >> is allocated regardless of need. >> I realise this might seem semantic, but policy is all about semantics. > > > On this we agree. > >> This 'anticipation of future need' stuff is at best ethereal and at >> worst a fallacy. Lets not forget that there is an almost zero barrier >> to entry with regard to ASN allocation should the member require one. >> I just don't subscribe to this "I may one day require one so give it >> to me now" > > > If you only look at it through the lens of the current multi-homing > requirement for an ASN then you don't need it, it is totally anticipatory > and only a future need, but that is self-fulfilling. I'm suggesting that > multi-homing is too narrow of a definition of need for an ASN. The PI > assignment and what every justified that should also equally justify the > need for ASN assignment. The PI assignment was intended to be portable, > also assigning an ASN simply is intended to facilitate that portability. > I'm saying that the need for portability is also a need for an ASN, if you > look beyond multi-homing. > >> It's the same as saying "I don't require an IPv6 allocation today, but >> I anticipate that at some point I'll need a /10. Just give it all to >> me now so that I don't have to make difficult design decisions later." >> >> If everyone gets one then I can live with that. What I can't live >> with is opening up a can of worms with a "I might one day need >> something so please allocate it now". It's a dangerous slippery >> slope. Today ASNs, Tomorrow IPv4, next day IPv6. > > > It's not that I only might need it, in my opinion it is fundamentally > necessary to fulfill the portability of the PI assignment. No need to move > the assignment within the routing system, no need for portability and no > need for an ASN. But, if you make a PI assignment without allowing me an > ASN you've limited its portability and the useability for its intended > purpose. Making a PI assignment implies to me, it can be picked up and > moved within the routing system, assigning an ASN is needed to facilitate > that movement. > > However, looked at through the lens of multi-homing, portability itself is > only a future need. You have to look beyond multi-homing, not abandon the > idea of need, to understand what I'm trying say. > > But, I probably only dug the whole deeper. :) So, I'll stop now. > > > -- > ================================================ > David Farmer Email: [email protected] > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
