Hi,
Thus you want to stick a different person/role in *every* allocation? I sure hope you will never have to change that or that you use role accounts.
There is still the -c Feature, therefor the 'handful' I had in mind only applies to the allocations we have which is 1 from Ripe and a few Lebacy B/C s.
Why do you not just use IRT?
Yes, but irt has one shortcoming (which maybe is a result of the approach, when irt was designed [1]): If I ( == LIR ) have some small customers, where I want to denote the abuse handling seperate from the LIR one. Now there are all the relevant persons in the DB. Th denote abuse-features with IRT, i have to create/maintain a seperate Object, to do int with a person/role I don't.
The prime reason, with which I agree, is that there is this 'mandatory' encryption field. Two things: - either RIPE can make it an optional field.
fine with that as well.
- people don't mail using it because they ignore it ;) I don't see automated tools encrypting anyways...
Another thing which might be considered is adding a 'abuse-mailbox' and 'spam-mailbox' to the IRT object, making everybody happy.
and a DoS-Mailbox, and a piracy-mailbox, and .... sorry I was carried away ;-) I just think, that adding an arbitrary number of attributes to denote special-features does not scale in this environment.
Any other 'issues' with IRT? (which doesn't require one to update *all* their objects. Of course replacing it is 'easy' with a shell one liner, request all the refered objects from whois and update them.
-c can/should still be there.
Checking your stats also shows that only 3x the amount of IPv4 inetnum's have a abuse@ line in comparison to the amount of objects with irt's. I think that reason awareness for adding IRT's is something which is something which is much higher on the priority list then and not inventing yet another object...
I fully agree on that as well. [1] irt/abuse in my opinion is something someone (=person/group) does, and not something that protects (=maintains) objects in the database. So I _personally_ think the maintainer approach is not appropriate for denoting any security-capability. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140