Re: [db-wg] [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
Dear Gert and other colleagues, After some off list clarification we see the point you are concerned with. The simplest case where an organisation manages all the abuse for all customers is easy to understand. In the real world this organisation has one or more internet resources and within the organisation there is a function (or role) that handles abuse complaints. So a real world picture is clear. Taking a member organisation as an example: member organisation / \ / \ internet abuse resources role This maps exactly to the new RIPE Database model: member ORGANISATION object / \ / \ INET(6)NUM member abuse objects ROLE object It is easy to see how to find the abuse handling role for any of these internet resources. The problem appears to be with the vision of what happens lower down in a network. After years of modifications the data model of the RIPE Database no longer reflects the real world. The relationships between objects are less than optimal. If you try to think of anything in terms of RIPE Database objects and relationships, it is not always obvious or clear. The implementation of the abuse-c proposal takes one small step to bringing the RIPE Database model closer to reflecting the real world, as outlined in the Database Groups presentation at RIPE 65. 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 By including the customers ORGANISATION object the same structure is modelled at any level. This is the basic structure of any organisation that manages internet resources. So now it is easy to see how to find this customers abuse handling role and also how to find the abuse handling role for any of the other customers. This structure can be repeated as many times as necessary at any point in a network. We don't have abuse contacts hanging off different object types. The principle of finding the abuse contact is always the same. That is what makes the model simple in all cases. Internet resources includes AUT-NUM objects as well, and an organisation can have multiple top level INET(6)NUM objects, but to keep the diagram simple I ignored them. I hope this helps to explain the reasoning behind this model. To help with practical administration the RIPE NCC will provide some easy to use tools initially so a customers details only need to be entered once and appropriate objects will be created and the references made. To remove this setup for a specific customer just delete the reference to the ORGANISATION object. The extended garbage cleanup process will delete any cluster of ORGANISATION, MNTNER, ROLE, PERSON objects that are unused. We will also provide more extensive tools for managing changes to contact data at any level across multiple objects. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 10/12/2012 14:42, Gert Doering wrote:
Hi,
On Wed, Dec 05, 2012 at 11:10:09AM +0100, Denis Walker wrote:
If at some point a customer chooses to do their own management of abuse handling for their assigned address space you simply create the ORGANISATION and abuse ROLE objects for this customer and add the "org:" reference to this customers assignment.
I'm not sure if I find this "simple", to be honest.
Being able to specify an abuse-c: in the ASSIGNED inet(6)num: object, and having the RIPE DB software honour that on queries - that is: not go to the allocation's org->abuse-c - would require less objects to be created, and thus, less effort and less opportunity for confusion.
Gert Doering -- NetMaster
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
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
participants (2)
-
Denis Walker -
Gilles Massen