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 ]