Hi Menno,
Well, except that the word 'abuse' may be a bit easier to understand than 'irt' for many non-RIPE-database-gurus, I do not see much difference between a reference to an IRT object or a reference to a person/role object. The big difference is that an IRT is usually better protected (see below) and provides more information.
The protection that the IRT gives over a person/role object includes: - It MUST be maintained, while a person or role object does not have to be; it can be completely unprotected. - Authorization from the IRT is required, before the IRT can be linked to the inet[6]num object. This is important so not all mail for a malicious company can go to another (or non-existent) address.
Moreover, if the IRT object is maintained by TRUSTED-INTRODUCER-MNT (or possibly other organisations of Incident Response Teams), it means the object's information has been verified and is verified on a regular basis.
We can agree that it would be preferable to have a special abuse-object with a mandatory maintainer attribute instead of just refering a role/person object, still the most important is that the whois database is an effectiv tool to locate an abuse address. Regarding authorization of the object, it could be done kind of the same way as a route object meaning maintainer has to be the same or can authorize the other. The LIR maintaing an address block is responsible for taking care of the related abuse cases. I see no problem in some LIRs outsourcing this to a third party (which I guess is what you mean by "other organisations of Incident Response Teams"), but I don't see it to be more trustworthy if a third party is involved than if the LIR takes care of it. But I do see it as a problem if such third party needs to be verified and such procedure makes this matter so complicated that almost no LIRs bother using it (as the case is today).
So we can start advertising the irt mechanism to both the LIR's and the people who migth come searching for an address to send a complaint to. I don't think it is very likely to hit a large public in a reasonable time.
Neither would another extra attribute, because people will still be sending their mail to ALL adresses found...
The current problem is that the majority of LIRs have chosen not to use irt, probably both because it haven't been announced enough and because it is too complicated. As soon as an attribute is implemented in most inetnum objects, meaning people have a reason to trust that an abuse address actually works, then people will stop using any other address, simply because the abuse address will work and the others will not.
Introducing an extra (mandatory) field in inetnum objects to hold the abuse address for that specific netblock and nothing more makes it much more easier for all those people who write automated process to get the information requested and not have to fallback to listing addresses in changed: fields as a possible way to complain.
If they can find the information in a person/role object, so can they in an IRT object. If the tool finds an mnt-irt attribute, just let it look for the contact information (address, phone, fax-no and e-mail) in the IRT object and display that to the user.
Yes, but thats not the point. Either the current irt object or a new and simpler abuse object implemented in most inetnum objects will be easy to retrieve abuse addresses from. The point is simply that it is much more realistic to implement a simple object than a complex one in most inetnum objects.
As such can this subject be put an the wg-agenda for ripe-47 ?
To formalize it a little bit I wan't to put forward the proposal to add an 'abuse' field to inetnum and inet6num objects.
Sounds like a good idea.
Personally, I would suggest promoting the current advanced mechanism instead of inventing something new.
The question simply is if ALL LIRs are ready/willing to implement the current irt object, its much more likely that the majority will implement a simpler version. The irt features can then be introduced at a later time once all inetnum objects have been updated. I would suggest a project be initiated like when encryption was made mandatory in maintainer objects. Abuse addresses in inetnum objects will not have much effect until they are implemented in all inet[6]num objects. Once the correct attribute has been decided it must be implemented ASAP. 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