[arin-ppml] ARIN 2-Byte ASN inventory and issuance

[Owen DeLong]

> On Apr 11, 2016, at 14:38 , John Curran <jcurran at arin.net> wrote:
> 
> On Apr 11, 2016, at 5:06 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> 
>> On Apr 11, 2016, at 12:24 , John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs 
>>> and come back explicitly asking for one ≤65535, are you suggesting that ARIN not hold
>>> these lower ones to be able to satisfy such requests?
>> 
>> Yes.
>> 
>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large.
>> 
>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole.
> 
> Just to be clear, you feel that ARIN registry policy which rapidly depletes the 
> lower range of 4-byte ASNs would be technically sound and facilitate fair and 
> impartial number resource administration? 

No. I believe that ARIN registry policy which ignores any previous distinction
between ASNs ≤65535 and ASNs ≥65536 is harmful. I believe that a policy which
makes no distinction and hands them out as if they were a single pool of 32-bit
numbers is in the best interests of the community.

At some point there will no longer be available ASNs ≤65535. So be it. That
date should neither be accelerated nor decelerated by ARIN policy.

> It would be helpful if you could explain how in some detail, given that there 
> appears to be sufficient number of lower range 4-byte ASNs for those who 
> require such for their operations, and further that the supply appears to be
> sufficient for quite some time (potentially till there is greater acceptance 
> and far fewer hurdles with the use of higher range 4-byte ASNs…)

So far, I haven’t seen so much a requirement as a convenience request for those
lower numbers.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160411/d9c0bc87/attachment.htm>