[db-wg] Options for extending "abuse-c:"

On 09/05/2014 19:26, Gert Doering wrote:
> Hi,
>
> On Thu, May 08, 2014 at 12:03:02PM +0200, Denis Walker wrote:
>> I understood the subnet issue to mean an organisation has more than one
>> default abuse handling team within their organisation. For example they
>> may have three allocations and have a different abuse team for each
>> allocation. I did not expect an organisation to have hundreds of abuse
>> teams, so I don't think this solution would create too much of a
>> problem. The ORGANISATION object is not going to grow too large.
>>
>> For End User customers who are handling abuse, they are taking over part
>> of the management of that internet resource. They should therefore have
>> their own ORGANISATION object referenced from that resource and an
>> "abuse-c:" referenced from the ORGANISATION object. For this we are
>> offering the wizard solution that will create and delete these extra
>> objects as required.
> I pointed out in the past that creation of an extra organization object
> just to get an abuse-c: referenced is something I consider "too much
> hassle".  It's a "database people think so" solution.
>
> Having an optional abuse-c: in the more-specific inet(6)num: would
> be a nice and low-effort solution.

I think you are missing the point in both cases here. This is not "just 
to get an abuse-c referenced". The ORGANISATION object was added to the 
database back in 2004 for a reason. The database always showed 'what'. 
This was to show 'who'. The ORGANISATION object was designed to provide 
some information about 'who' manages and has control of and is 
accountable for Internet resources. When this responsibility is shared 
between organisations there should be ORGANISATION objectSSS to show the 
organisation details for these parties.

But as with so many ideas/designs/philosophies with this database no one 
thinks about how these principles can be enforced. The ORGANISATION (and 
ROLE) objects were introduced with certain ideas in mind. But no 
business rules were added to enforce those ideas. It is very easy to 
mis-use them. Then it becomes too much hassle to do it right. If there 
is a low effort way to do something, without any constraints, people 
will do it - even if it breaks the database model.

If you are not concerned with accountability in the database for 
management of Internet resources, we can do anything. Right now we have 
a default abuse handler for the LIR. We know who you are and you are 
accountable. Once you start adding abuse-c attributes all over a large 
network, referencing ROLE objects that we don't know who maintains (as 
MNTNER objects are pretty much anonymous), then we have lost a degree of 
accountability. It is very easy to hide behind an email address when you 
don't have to provide any other information in the public domain. What 
you want means all we have in the public domain for these End Users who 
manage the abuse reports for a resource is an email address.

So we don't have any information about the End User organisation who is 
now managing one aspect of this resource - abuse handling. We only have 
an abuse email address. How do you want the Abuse Finder service to 
work? What do we do when this End User does not respond? We can't return 
any further certain information about this organisation, like 
alternative email address, real address, phone number, company name, as 
we don't have anything. So do we return the LIRs abuse email? Do we 
start following chains of references of other objects (like we did 
before and get it wrong). For example the abuse ROLE object, it's MNTNER 
object, any referenced PERSON objects, their MNTNERs.....Should we give 
out the LIRs default abuse contact with the End User's contact at the 
same time, in case the End User address does not work?

When someone is held publicly accountable and has to provide additional 
information, which the LIR can validate as you know who the End User is, 
they are more likely to provide a working email address. We can always 
provide a low effort solution....but they have consequences.

>
>> We will also provide a management tool that will provide an overview of
>> all additional "abuse-c:" setups within your network.
> Nice and shiny query tools are also missing the point.  Creation of a
> needless object just to fulfill "abuse-c: may only be referenced from
> an organization: object" designs is not being made less effort by nice
> query tools.

Again you are missing the point here. Whatever solution we end up with 
means there will be many abuse contacts distributed over a network. The 
number of levels of indirection does not matter. The point is there are 
many of them spread across a large network. If you want to know where 
localised abuse contacts have been set up in your network (by whatever 
method we end up with), how are you going to find them? How can you get 
a clear overview of abuse handling in your network? Currently there is 
no query that gives you this overview. That is because queries return 
low level data, not high level information.

The reason abuse-c was introduced is because what we had before was an 
unmanageable mixture of earlier solutions. If we allow abuse-c to be 
distributed across a network without proper tools to manage it, then 
people simply will not manage it. It will become too much hassle. 
Contact references will be left when not needed because they have been 
forgotten and can't be easily seen. Reports will go to the wrong places 
and be ignored. In a couple of years time we will start again with a new 
idea to clean up the next problem. Modern interfaces and tools to manage 
information in a system like the RIPE Database are pretty much standard 
these days. That is why other systems don't need a full day training 
course just to teach the basics of how to enter data into a database, 
protect it and retrieve it.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Team

>
> Gert Doering
>          -- NetMaster