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/[email protected]/
[anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
- Previous message (by thread): [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
- Next message (by thread): [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Denis Walker
denis at ripe.net
Thu Dec 13 11:35:34 CET 2012
Dear Gilles, Yes you are absolutely correct. I was outlining a simplistic example where the only part of resource management the customer handled was abuse. In this case, if they no longer handled their own abuse there would perhaps be no need for any of these objects. In which case the easiest way to clean up would be to remove the reference to the ORGANISATION object and the database garbage collector would remove the unreferenced objects. But of course there may be other reasons why a customer needs an ORGANISATION object. In these ORGANISATION objects with "org-type: OTHER" the "abuse-c:" reference is optional. So when looking for the most appropriate abuse handler, the database logic will work up the hierarchy looking for the first ORGANISATION object with an abuse contact referenced. Thanks for pointing this out. Regards Denis Walker Business Analyst RIPE NCC Database Group On 13/12/2012 10:54, Gilles Massen wrote: > Dear Denis, > > On 12/11/2012 12:21 PM, Denis Walker wrote: >> When a customer wants to handle abuse for their part of a network, they >> are taking over part of the management of that internet resource. In >> reality the customer's situation is the same as the member's. >> >> member ORGANISATION object >> / \ >> / \ >> INET(6)NUM abuse >> objects ROLE object >> / \ >> / \ >> / \ customer ORGANISATION object >> / \ / \ >> / \ / \ >> other INET(6)NUM customer abuse >> customers object ROLE object >> INET(6)NUM >> objects > > There is one thing that worries me with the setup: if I understood you > correctly the appropriate (only?) way to remove a specific customer > abuse object (and let the parent LIR handle abuses) is to remove the > customer organisation object. However this would create a strong > dependency between the org and the abuse object: if another object would > be created that relies on the org object (like abuse-c does), you would > link its existence to the presence of an abuse-c - appropriate/wanted or > not. > > You could circumvent this limitation by adapting the logic so that not > each org object needs an abuse-c, but somewhere up the tree you need an > abuse-c, even if the 'closest' org hasn't one. Parsing wouldn't get > easier, though. > > Best regards, > Gilles > >
- Previous message (by thread): [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
- Next message (by thread): [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]