And for having a usable, maintainable automated system, it is easier to take what is there (IRT is not really hard to figure out - it _is_ basically like a maintainer), and write the apprpriate tools for that; since you would have to write tools anyway.
I hope that makes sense.
It makes sense, but I have the feeling that the irt carries to much information or is to difficult for the average database user to use.
I would very much like a solution to this problem so if more LIRs would be willing to accept modifying the current irt object I could support some kind of compromise. The current irt object template: irt: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The following is a modified version: abuse [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The name: abuse is a much more common word, I don't really see the point in using a word that most normal user doesn't understand and maybe even some LIRs. I don't think physical address is strictly necessary since people only look for an email address, on the other hand its no bother to insert it.. (btw. shouldn't country be included as mandatory if address is included?) Signature and Encryption has to be optional, I only see a point with these attributes in case abuse is handled by a different department. Im sure other LIRs exists who doesn't need this. admin-c and tech-c, email is mandatory on role object = a mail address totally irrelevant to abuse/irt will show up if these attributes are included meaning people will send to these as well = back to square one. It doesn't help making them optional as I see it..? I don't see the reason for auth? If its absolutely necessary it can be optional. As it is now it should still be referenced from inetnum objects. The disadvantage is that all LIRs have to modify each and everyone of their inetnum objects, and this object will not have much value until all inetnums have been updated.. This is where the idea of having it in the maintainer object has its advantage.
That's why I proposed the alternative of creating more awarness of the irt object, what it does and how to use it, especially from the perspective of the bulk of the database users who just want some basic information on where to complain about a certain ip address.
I don't know how others handle this, but the company I work for has some seperation between 'security' and 'abuse'. The irt object will probably point to our security department who handle the more serious incidents or things which need a fast response. Our abuse dept only works during office hours but takes care of all spammers, virusses and other stuff as from experience most of the spam is done batchwise mostly the damage is already done and the only thing the abuse dept does is taking care it won't happen again by disconneting the user and make sure they fix their security holes.
The irt object doesn't allow for this seperation, you can create multiple objects and use remarks to explain where to send the complaint. This is the mechanism we already use on the inetnum and it doesn't work very well.
Im not sure its possible to solve this without getting into problems like people using the wrong address anyway. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net