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

[Owen DeLong]

> On Apr 11, 2016, at 15:24 , John Curran <jcurran at arin.net> wrote:
> 
> On Apr 11, 2016, at 5:53 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>>> 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.
> 
> Alas, within the scope of ARIN’s mission, the best interests of the community are
> met by registry policy which is technically sound and facilitates fair and impartial 
> number resource administration (hence the reason I asked you to elaborate on
> those aspects, if any were applicable to your position.)
> 
>> 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.
> 
> Understood, however, we have folks who have expressed that higher-range 
> 4-byte ASN’s pose additional technical challenges to their operations, so that 
> remains an active point of discussion.
> 
> If ARIN were to issue AS numbers strictly from smallest to largest, is it your
> belief that those who feel they need lower-range AS numbers should engage
> in an NRPM 8.3 transfer to obtain such? (or would you also want policy change
> to prohibit that as an option?)

I’m not making any suggestions about the order in which ARIN issues AS Numbers.

I’m simply suggesting that we stop treating AS Numbers as anything other than a single
collective pool of 32 bit integers from which ARIN issues them.

High to low, low to high, or random order is fine with me. However, the community adopted
a policy that said ARIN is to treat them as a single pool of 32-bit identifiers and so long
as we continue to ask questions like this in the application process, it’s pretty clear that
policy isn’t being followed.

Owen

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