This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] abuse-c: proposal
- Previous message (by thread): [db-wg] abuse-c: proposal
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ulrich Kiermayr
ulrich.kiermayr at univie.ac.at
Thu Jan 29 14:34:32 CET 2004
Randy Bush wrote: >>What is the difference between the following to answers from the >>database > > > the abuse-c: proposal does not require creation of a new object > type, the irt: object. it reuses the person: and role: objects, > as the semantics, "here is who you contact," are really the same. > > i don't think we want to differentiate the kind of people/groups > who handle abuse from those who handle tech/admin things. they're > all just contacts. Fair enough, thx. What I am afraid of is having 2 things basically doung the same irt and abuse-c. so maybe there is a way to 'merge' these two things (wild thinking of me): Looking at the difference between irt and roles in general, there are actually quite few: 1. Role lacks of the two pgp-attributes. Might it be worth to put them as optional into that templates? [I'd say probably yes, because it might be useful in other situations as well] 2. Protection against 'illegal' referecing. (Meaning "Hey UCD has a nice role for abuse, i reference this role in my inetnums as well") There we had a discussion in the context of the org object, putting a generalized machinery (mnt-ref, ref-nfy) in place. IMHO this _should_ be added (optional) to role/person anyway. 3. The -c flag: This could be incorporated with the irt as well. Or in a even more generalized way have a "whois -c abuse-c 131.130.7.44" returning the most specific inetnum containing an abuse-c, and maybe if useful extending the semantics to other attributes if useful. If those three things are incorporated, abuse-c has all the features irt has, except for the creation policy. But this is up to discussion anyway. I hope I make some sense here 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
- Previous message (by thread): [db-wg] abuse-c: proposal
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]