Why don't delete RIPE-NONAUTH at all?

If there is no legal use of it - there is no need to maintain it.

If there are legal use cases - you would create unpredictable operational problems, when the customer will set up an ROA, forgetting for a moment that provider is advertising its prefix for him, then he will fix ROA - but the route object will be already gone.

You have NTTCOM to register objects for your customers, some other Tier1 telcos also have similar service.

The lock of RIPE-NONAUTH and this policy forces smaller ISPs to pay an additional fee to RADB.

I agree with the idea to drop (freeze) 'invalids', but only if you are able to restore 'valids'.

пн, 15 окт. 2018 г. в 17:43, Job Snijders <job@instituut.net>:

On Mon, Oct 15, 2018 at 16:35 Alexander Azimov via db-wg <db-wg@ripe.net> wrote:
There is only one good thing about mistakes - if you can fix it.
Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked.
I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs.

Alex - just create the route object in the correct database.

Why help proliferate rogue or stale route announcements? It is outside RIPE’s scope to facilitate hijacks and increased risk to one business’ operations through incorrect routing information registration.

If you can’t create the route object, perhaps you aren’t authorized by the owner of the resource and have no business creating such objects.

This is no different than configuring the wrong DS records at the domain registry level, or generating TLS certs for the wrong hostname, or misconfiguring your firewalls or routers. Misconfigurations lead to issues - news at 11.

Kind regards,

Job