Hi Havard (Sorry for not posting inline but yahoo doesn't allow for that option.) It is not quite a 'normal' delete. You are deleting an object using the authorisation from another, related, object. But not from any MNTNER on the object you are deleting. This is not possible in any other situation. Often when someone is given a sub-allocation the "mnt-by:" will be set to the LIRs MNTNER but the "mnt-lower:" may be set to the receiving organisation's MNTNER so they can make assignments. The sub-allocation could be split into two 'LIR PARTITIONED' objects, from which assignments can still be made. Then without this route creation flow, ROUTE objects could be created for the 'LIR PARTITIONED' objects. The first test would be for an exact matching INETNUM object. This would over ride any "mnt-routes:" set on the sub allocation object. cheersdenis co-chair DB-WG On Tuesday, 16 April 2019, 09:48:58 CEST, Havard Eidnes <he@uninett.no> wrote: 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 the LIR. Best regards, - Håvard