[db-wg] abuse-c

  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.