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