Hi Ed, Thanks for implementing this :) I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part. I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so. -Cynthia On Tue, Jun 29, 2021 at 11:27 AM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*.
This means that the cleanup job will run for the first time tonight.
* Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects.
See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included.
If you have any feedback, please let us know.
Regards Ed Shryane RIPE NCC