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/db-wg@ripe.net/
[db-wg] abuse-c
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
MarcoH
marcoh at marcoh.net
Mon Jan 12 14:36:12 CET 2004
On Mon, Jan 12, 2004 at 09:55:06AM +0100, Shane Kerr wrote: > On of the problems that was identified when the irt object type was > defined is that there are a lot of meanings of "incident" that the "irt" > could be responding to. The same applies to an "abuse-c:" attribute. > Does abuse mean spam? DoS? Illegally trading movies? E-mailed viruses? > Pornography? Gambling? Hijacking address space? > > Do you have different desks for these different types of abuses? If so, > does it make sense to have different contacts for them? (History shows > this doesn't matter too much - as users tend to send to every e-mail they > can find. But in the future, it would make modifying output of tools to > only display relevant information easier.) That's why I proposed a simple attribute only containing 1 single email address where people can send their complaints. It will mostly end-up being abuse at isp for every single inetnum. It's harder to maintain, but easier to delegate abuse handling for a specific inetnum to a certain part of the company or even to the enduser. If you define a abuse-c: as a person/role object, you still have the problem that people need to resolve it and then possibly get multiple addresses. So the problem doesn't get solved and we can just stick with the irt-object. I think for this we can better stick to the most simple solution available. Grtx, MarcoH
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]