[db-wg] [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database

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
>
>