Christian,
>I have a lot of inetnum objects which I need the same abuse address for so I
>would REALLY appriciate not having to change each and everyone of them!.. :)
supporting that was one of the goals in the design of the IRT object.
All the (resources described by a set of) objects which are handled by
the same incident team or function just get linked to the same IRT object.
If you want to make any changes, then you update the info in _one_ place -
much like the maintainer approach.
And, the IRT structure supports hierarchy (for those resources which do
have a hierarchy :-)
It allows quite a few other things to be nicely described and
maintained, eg.
- giving key info if you want to use encryption for your complaint, or
verify the identity of the security contact you get an answer from
- decoupling of IP-Address management from operations ("rouitng") and
incident handling
- registering credibility info with this contact info, like the Trusted
Introducer, which was the first structure to use this machinery.
We are definitely still missing some things to make it fly high...
Things that come to my mind without doing a full inventory:
- make additional documentation available
(TF-CSIRT is actively working on this)
- try to get it deployed and _used_
(I'd look into the direction of the Anti-Spam folks to help with
this)
- maybe modify the default answer from the server for a whois query
(what would the impact be on the "other" users of the registry
data?)
- try to define complaint handling roles in a concise way to allow
selecting the "correct" contact from an object.
(this doesn't chance whether you put it into an inetnum or an IRT
object ;-)
(I guess there will be another attempt in Madrid next week to deal
with that amongst the incident handlers, and we may come back with
a proposal or at least an idea)
Wilfried.
