Hi, following up on my own message of earlier... I can't exactly say my questions were answered. Now, things have changed slightly, but the substance of my question / suggestion remains the same. If I've understood correctly, after the implementation of the NWI-5 (dealing with out-of-region address resources), changes were made to the rules for route object creation, so that route object creation should now in principle no longer be authorized by the originating AS, but rather by the address space holder. If that's correct, that's all fine. However, the new documentation for the route object creation authorization is at https://www.ripe.net/support/training/material/bgp-operations-and-security-t... so I have this question: * Why should an already-existing matching route be used to authorize the creation of a new route object, if the entire control over route object creation is supposed to now rest with the address space holder? In other words, why isn't the authorization in mnt-routes / mnt-lower / mnt-by in the inet(6)num object sufficient? Consider the transition scenario, and a common configuration, where an ISP is originating a route on behalf of the customer, and when the route object for the customer's address space was created, it would have been authorized by the mnt-routes of the AS object, and probably also only has the ISPs maintainer as mnt-by. Now, this route object acts as a blocker for allowing the customer to move to another ISP, and the customer is prevented from creating a new route object corresponding to the route the new ISP will originate -- the old ISP could (if so inclined) hold the customer hostage. I was told that this is mitigated by the "forced delete" functionality of the RIPE database -- it could be used by the address space holder to forcefully delete (how, exactly? Is there a "forcefully delete" function in the LIR portal? What about signed e-mail submissions -- any particular syntax?) the pre-existing route object, ref. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... (The documentation doesn't answer the parenthetical question above.) However, that can leave a time window where no route object is registered for the address space, and in a maximally pessimistic scenario that could create an operational problem with complete loss of connectivity... This would have been much simpler and easier to deal with if any preexisting route object did *not* play any role in the creation of a new route object. Can someone please justify why a preexisting matching route object should play any role in authorizing the creation of a new route object, especially with the previous authorization patterns of the objects involved? Best regards, - Håvard