[db-wg] Proposal: Abuse-C as a Reference

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 at univie.ac.at       Tel: (+43 1) 4277 / 14104
PGP Key-ID: 0xA8D764D8                         Fax: (+43 1) 4277 /  9140