Hi, On 20 Aug 2024, at 14:11, Nick Hilliard <nick@foobar.org> wrote:
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Wessel Sandkuijl wrote on 20/08/2024 12:51: there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?).
Would someone from the RIPE NCC be able to provide some suggestions about how this situation could be addressed?
For reference, when creating an RPKI ROA the address space holder can also create ROAs with ASN without the ASN holder's permission. I always read route(6) and ROA data as "the address space holder permits this ASN to announce its space" and realise that the ASN holder might not even be aware of being given this permission. And there is indeed no way to indicate "I don't want to be given this permission" in either DB or RPKI. My view may also be different from other's. I understand that from a "keep the database clean" point of view it is annoying. Whether this is an actual (operational) problem has been argued both ways in the past, and I haven't seen any consensus. I'd love to see a discussion on that here. Cheers, Sander Speaking for myself, and as a long-time community member who understands that community guidance on things like this is important to the RIPE NCC :)