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