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