On Mon, Jan 12, 2004 at 03:39:32PM +0100, Marco d'Itri wrote:
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. Not if the relevant IRT object is automatically returned for every inetnum query. This is what ARIN does, BTW.
Ok, but in that case we need to launch a campaign to get people aware of the irt object and how they should use it.
I think for this we can better stick to the most simple solution available. I think you should define better you requirements of simplicity...
IMHO you can define two groups of database users: - the relatively small group of techies who are updating the database and/or know how to use it and how to find specific information like incident response teams. - The large group of users who hardly know what the database is and why it is there and only want to get one piece of information: Where can I complain about this spam I got. For the first group everything is in place and working. As from my personal experience the second group doesn't understand how things work and how to read the information returned on a query and to be more specific admin-c, tech-c and especially changed attributes are not by default the best address to send complaints to as we already mentioned in the remarks section which got returned on the same query. Reading the remarks section which is used by most people to list abuse information is easy for the human reader, although I have came accross webinterfaces who didn't like the <address> notation most people use. But it's hard for a programmer to 'read' as it is not fixed format. Introducing the abuse: attribute as a single syntactically valid[1] email address on inetnum objects or the first level of objects it refers to makes it simple in the way that: whois ip-address | grep abuse: Will always result in a valid email address to send the complaint, without the need to walk to a tree of objects referring to each other and search for remarks fields pointing to the abuse desk or just collecting everything which includes an '@' and not even using uniq on them. Take it from the point of the non-professional "I'm sure this is easy to write in perl/php/shell/cobol/whatever" programmer who needs to query and parse the ripe database. MarcoH