<div dir="ltr"><div><div><div>I think that the pilot projects, testbeds or trainings are/could be already covered by the temporary assignments for which I think this proposal was not intended to change anything.<br><br></div>I think that one 16bit ASN per LIR limit is not prudent as LIR != route end point, this notion that LIR is also "end customer" or the sole user of the network has been established in the last few years with the last /8 policy where I guess most of the new LIRs are actually also the route end point for their allocation, but if you look back LIRs were/are the middle-man between RIR and end customer which actually (could) need their own ASN so the need for the 16bit ASN exists at a third party and not directly with the LIR.<br><br></div>I guess the need for 16bit ASN and with that requirements to get a 16bit ASN should stay unchanged but on the other hand the limitations for 32bit ASNs could be more relaxed.<br><br></div>Uros<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 8:59 AM, Wilfried Woeber <span dir="ltr"><<a href="mailto:Woeber@cc.univie.ac.at" target="_blank">Woeber@cc.univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">David Huberman wrote:<br>
<br>
> Thank you, ytti.<br>
><br>
> So let's start with the basics.  Does the following text allow the NCC to meet the needs of network operators today?<br>
><br>
> "A new AS number is only assigned when the network architecture<br>
<br>
</span>I would be more edxplicit and more flexible here, by adding e.g.<br>
<br>
or project<br>
<span class=""><br>
> has a need that cannot be satisfied with an existing AS number."<br>
<br>
</span>Looking at SDN stuff and pilot projects or testbeds, or even trainings<br>
or workshops, I can see the need to interconnect such projects with<br>
the 'real' net and to use globally unique AS numbers.<br>
<br>
I do understanf that "network architecture" can be interpreted as a<br>
rather wide and flexible term, but we should try to provide as good<br>
guidance as we can to support the evaluation of requests by the IPRAs.<br>
<span class="HOEnZb"><font color="#888888"><br>
Wilfried<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> There will be more policy text. But again, let's start with -- and agree on -- the basics.<br>
><br>
> Thanks!<br>
> David<br>
><br>
> David R Huberman<br>
> Principal, Global IP Addressing<br>
> Microsoft Corporation<br>
<br>
<br>
</div></div></blockquote></div><br></div>