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 <[email protected]> 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 > > > > >
