> On Apr 11, 2016, at 15:24 , John Curran <[email protected]> wrote: > > On Apr 11, 2016, at 5:53 PM, Owen DeLong <[email protected] > <mailto:[email protected]>> 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
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
