On 30.01.2004 at 09:15, Ulrich Kiermayr wrote:
attribute "abuse-c:". The value of the attribute is a nic-handle: I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough... I would say it will be even a better solution to have only the mailadress there and no person object.
Problem is imho that a simple mail-address would only scale downwards [i.e. for those with few netblocks]. From the discussion it seems that irt only scales upwards [i.e. for the ones with many netblocks who are willing to understand the system without a priori saying 'it's too complicated]
Ok, opening up the can of worms: The question will then be: what abuse address do we write into the objects. In allocations for sure the contact of the LIR/Provider. But into the object of the customer networks? The address of the customer's abuse department? Or, here too, the one of the provider? Or both? And if we use the customer's abuse department's address, are we going forward and demand that this address will be mandatory and has to be given in the requests for new netblocks? And if we use both addresses, do we need tags for them to indicate the escalation level? Probably we should head in two directions simultaneously 1. A short term solution, using admin-c: <email> to better the current situation a little. 2. A longterm solution with a proper hierarchy, clear defined policy, and technically easy to administrate objects -> IRT.
Nowing that admin-c and tech-c seems to scale over the whole spectrum, it seems the most natural implementation to have abuse-c reference a (enhanced) person/role too.
Even though I would have to touch relatively many objects, I am still willing to got for the admin-c: <email>. Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/