This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] Route object creation authorization
- Previous message (by thread): [routing-wg] Route object creation authorization
- Next message (by thread): [routing-wg] ACM BuildSys 2019 - Nov. 13-14 - New York City - Call for Workshops/Papers Reminder and Call for Posters/Demos/PhD Colloquium
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ripedenis at yahoo.co.uk
ripedenis at yahoo.co.uk
Tue Apr 16 13:42:06 CEST 2019
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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/routing-wg/attachments/20190416/e1adadbf/attachment.html>
- Previous message (by thread): [routing-wg] Route object creation authorization
- Next message (by thread): [routing-wg] ACM BuildSys 2019 - Nov. 13-14 - New York City - Call for Workshops/Papers Reminder and Call for Posters/Demos/PhD Colloquium
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]