Hi, it looks like "things happened while I wasn't watching"... I've just had a run-in with the route object authorization rules as presently implemented in the RIPE database. I found the following flow chart documenting the authorization procedure: https://www.ripe.net/support/training/material/Routing-Security-Training-Cou... which is referenced from https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-i... The question I have is this: What is the policy reason for having a pre-existing route object play any role in authenticating the creation of a new route object, so that it in effect overrides any mnt-routes: fields of the corresponding inetnum object for the address space holder? When a customer who has his own address space and controls his own inetnum object, but lets his current ISP originate the route with the ISP's ASN as origin, but wants to move to another ISP, given the current rules, the current ISP is able to hold the customer hostage by refusing to create a new route object with a different ASN as origin. I would not have thought it was RIPE's role to raise and enforce such a barrier? I also can't quite comprehend why a route object would need the "mnt-routes" or "mnt-lower" attributes -- in an inetnum object I can understand the semantics of those, but in a route? Best regards, - Håvard