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