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 -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473