On Wed, 29 Mar 2017, denis walker wrote:

> 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.
>
> cheers
> denis
> co-chair DB-WG
>
>
> ______________________________________________________________________________________________________________________________________________________________________
> From: "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk>
> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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