Christian Rasmussen wrote: [SNIP]
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.
Correct.
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.
No, but let me explain below.
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).
In the current implementation the IRT and the LIR (maintainer) are supposes to be different groups of persons, whether they are part of the same organisation of not. The LIR cannot simply make the IRT responsible for its IP range, but the IRT has to authorise this, by counter-signing the request to add an mnt-irt attribute to the inet[6]num object. Otherwise any maintainer of an inet[6]num (which could be delegated) could simply make the inet[6]num object point to any IRT for abuse complaints. The current mechanism is to protect the IRT form being blamed for things they are not responsible for simply because "Evil Company" points a finger towards them. The "other organisations" are (future?) organisations like TI (http://www.ti.terena.nl/), in which IRTs can cooperate and establish trust relationships with eachother and with the RIPE community.
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.
That is exactly why there must be double authorization for the relationship between IRT and inet[6]num: to ensure correctness and mutual agreement.
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.
The object itself is not so complicated. The mechanism to create it is, and that has a purpose (see above). [SNIP]
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.
I agree that there must be a better mechanism than the comments in the inet[6]num and maintainer objects, but I'm still in favor of promoting the existing one and perhaps explaining it a little better. Regards, Menno Pieters -- Menno Pieters - Stelvio Postbus 215, 3740 AE Baarn phone: +31-35-5.429.324 / fax: +31-35-5.429.327 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/