This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] "abuse-c:" - a question....
- Previous message (by thread): [anti-abuse-wg] Draft Agenda - AA-WG RIPE74
- Next message (by thread): [anti-abuse-wg] "abuse-c:" - a question....with no answers?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ripedenis at yahoo.co.uk
ripedenis at yahoo.co.uk
Thu Mar 16 18:14:13 CET 2017
Colleagues [Apologies if you receive duplicate versions of this email but my interaction with the RIPE NCC mailing lists is getting worse. Three attempts with gmail, yahoo and xs4all email accounts all failed to post this to the DB-WG so lets discuss it here...] 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/20170316/99c31897/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Draft Agenda - AA-WG RIPE74
- Next message (by thread): [anti-abuse-wg] "abuse-c:" - a question....with no answers?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]