[anti-abuse-wg] "abuse-c:" - a question....with no answers?

Colleagues
A couple of weeks ago I asked the question below. No one has yet responded. We need to resolve the issues around "abuse-c:", which means we must make some software changes. In order to make the right changes we need your feedback. If "abuse-c:" is nothing more than an email address tagged on to a resource then the changes can be very simple. The working group chairs can't make these decisions.  We need your input and direction...
I understand that this issue has been talked about so many times over several years...with no solution. This time we are determined to take some action. Whilst nothing is ever final, lets make this the last discussion on "abuse-c:" for a while.
cheersdenisco-chair DB-WG

      From: "ripedenis at yahoo.co.uk" <ripedenis at yahoo.co.uk>
 To: "anti-abuse-wg at ripe.net" <anti-abuse-wg at ripe.net> 
 Sent: Thursday, 16 March 2017, 18:14
 Subject: "abuse-c:" - a question....
   
Colleagues

I would like to ask the community a question that looks at a wider picture than the "abuse-c:" attribute itself. Depending on how people react to this question, it may impact the chosen path to solving the issue with documenting abuse contact details in the RIPE Database.

The current implementation for "abuse-c:" documents the default contact details for who handles abuse issues within an organisation that holds resources. If the email address is invalid or there is no response to a complaint sent to that address it is clear who the organisation is and there are other contacts related to this organisation.

Sometimes a resource holder delegates some responsibility for the management of (one or more of) their resource(s) to another person/organisation. This may be just the abuse handling. With the current database semantics it is not always possible to create a separate ORGANISATION object to document this responsibility. This issue has been described as 'How to reference the email address for the abuse reports for this resource?'.

The simple version of my question is 'Is it enough to only know the email address and an un-validated postal address for the abuse handler?'. An email address can be 'anyone at anybody.com'. This tells you nothing about 'anyone' or 'anybody'. It is a one directional channel to throw something down that may end in a black hole. If nothing happens, who was supposed to have this responsibility? Not everyone who uses this abuse contact information understands the RIPE Database structure, the resource hierarchy or the contractual responsibilities of the related parties. They may have searched online for who to complain to, got this email address and got no response. How do you take further action against an email address?

What I am working round to is explaining why the "abuse-c:" was designed the way it is. Where responsibility for handling abuse was delegated to another party (separate organisation or another internal department) we wanted to maintain a closely coupled link between the resource listing a contact and an organisation responsible or accountable for abuse handling. As it turned out this created the need for repetitive data in some cases and not being able to record the right details in some other cases.

The simplest solution that has been discussed in the past is to allow the "abuse-c:" attribute in resource objects. This does create some resource and data management issues. But these can be solved by providing resource managers with the right software tools. Now we get to the in depth version of my question. Do we need to maintain that close coupling in the database between who is responsible or accountable for handling abuse for a resource and their correct and validated (by the resource holder) contact details?

If the answer to this question is a simple 'no' then we can easily add "abuse-c:" attributes anywhere pointing to an email address and provide the resource managers with tools to maintain the data....job done.

If the answer is anything other than a simple 'no' and we believe abuse information consumers without an in depth knowledge of the database or industry need to easily understand 'who' claims to be behind an email address then we may need a more complex solution.

I hope this makes sense and look forward to comments and questions.

cheers
denis
co-chair DB-WG


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20170329/51a21b41/attachment.html>