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: "ripede...@yahoo.co.uk" <ripede...@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 'any...@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
