Hi Marco, everyone, my take would be as follows: The RIPE NCC could just send automated monthly/quarterly messages to ASN holders if the ASN has not been seen in the global routing table for more than 3/6/12 months. We could agree to this on the mailing list and this could be a process and not necessarily a new policy proposal, this process could also be adjusted every few years if needed. Just notifications, no other follow-up or requests for return. I’d see the message say something like: “ you received an ASN x months ago, this ASN has not been seen in use in the global routing table for at least 3/6/12 months. You can return it if you do not have any plans to use it. Just reply to this message and we’ll return it to the free pool. You can always come back and request an ASN from the RIPE NCC, should you have plans to use one.” The message would also include how it is good stewardship both by the RIPE NCC and the ASN holder to keep a clean registry by returning an unused ASN to the free pool. To be honest, in today’s environment, I don’t see why a differentiation between 16bit and 32bit ASNs still exist. If someone could tell me why a 32bit ASN can not be used today (even with 10 years old equipment), I’d appreciate it. Also, I do agree that a clean registry is a priority for the NCC and the community but I think work (FTEs) should be invested in this project only for the part where the holder wants to return it and some work needs to be done. In the number transfer world, low number ASNs are worth ‘more’ due to them being considered vanity numbers. However, I find it silly today to have different policies, restrictions or processes for 16bit vs 32bit ASNs. my 0.2c Elvis On Thu, Jun 8, 2023 at 22:25 Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
Thank you for the feedback received so far.
As Aleksi noted, there are indeed valid reasons why ASNs seem to be unused. We have some data on this from our AS Number Clean up project. When asked if the resource is being used, about 2/3 of ASNs have been returned, about 1/3 are expected to be used soon, and only a very small number have been used by transit providers or IXPs.
Of the more than 8,000 ASNs not visible in the routing system, about 52% are 16-bit ASNs.
As mentioned by Kaj, the members of RIPE NCC clearly voted against charging for ASNs. So we wanted to ask this working group if there are other ways to improve the situation? Something that falls under the authority of the RIPE community, such as developing RIPE policies or guidelines for Registration Services. For example, are you in favour of us being more active in trying to clarify the status of ASNs that seem to have been unused for a long period of time?
Kind regards,
Marco Schmidt Manager Registration Services RIPE NCC
On 08/06/2023 16:55, Nick Hilliard wrote:
Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Hi Marco,
There are good reasons to clean up unused ASN16s, as they are categorised by policy as scarce resources. There isn't a compelling reason to get as excited about ASN32s, other than to say that normal good stewardship practices should apply.
Unfortunately there is a disconnect between RIPE policy and RIPE NCC practice in regard to charges for ASNs. This is a real shame because paying for resources is one of the simpler ways of creating positive pressure to return them if they're unused. The community would benefit from the board re-thinking this.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
-- This message was sent from a mobile device. Some typos may be possible.