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-training-course/route-object-creation-flowchart.pdf

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-database-documentation/10-authorisation/10-13-force-delete-functionality

(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?