Hi, Denis,

thanks for your follow-up.

> Firstly the 'forced delete' has nothing to do with the LIR
> portal. It is also indifferent to the authentication option you
> use (signed email, password, SSO). If you are the holder of an
> allocation or PI assignment then you can delete a ROUTE object
> for your resource or any more specific range using the MNTNER
> authentication on the resource object.

OK, so a "forced delete" is just a normal "delete" operation?
Not sure then why it deserves the "forced" tag...

> Why is authorisation still needed from a ROUTE object? I don't
> know much about how you guys structure your routing, but purely
> from the Database rules I can suggest this possible scenario
> (although it may not apply in practise). Suppose an LIR makes a
> sub-allocation to another organisation, but the LIR routes the
> whole of their allocation including the sub-allocation. The
> organisation holding the sub-allocation cannot choose to route
> their sub-allocation without the consent of the LIR as to
> create such a ROUTE object would need to be authorised by the
> LIR's ROUTE object covering the whole allocation.

That's normally what happens with PA address blocks.

However, I still don't understand why authorization via an
existing route object would be needed in that case -- all that
would be needed to express the stated restriction is either
mnt-lower or mnt-routes attributes in the enclosing address space
object (inet{,6}num), which is typically held and maintained by