Hi,
This abuse-c inherits all the features of irt as well ... Except that crypto is optional. Fair enough.
Intentionally here (since it modifies existing object tempates - using mandatory here is not a good itea(tm))
... resulting in just one object for this area
I suggest we keep IRT for the purpose for which it was built, and make no changes to it (so it will be different from the role or person used we make available for abuse).
This might actually encourage the use of IRT objects, since it reduces the risk that CSIRTs will get abuse reports they mostly don't want. And IRTs may then be useful, so I don't support removing them.
Fair enough as well. (though I'd like to think about that a little more)
I think the 1-1 mapping is unnecessary; auto-copying is still possible.
You basically get that basically for free: All the attributes I added to person/role i conscider useful independently of this topic.
Can you confirm that the abuse-c: attribute can also refer to an IRT object for people who want to do it that way?
This goes against how i understand the database's logic. so No. The issue here is what I tried to point out before lunch: the mindset of irt being a maintainer is flawed. anf for that reason I originally proposed this migration irt-> person/role (wether te attribute is called abuse-c, security-c, irt-c, or whatever is a matter of taste)
Do we need a dedicated attribute in role and person? abuse-mail: [optional] [multiple] [ ]
This is the part that I was not sure of.
(or the name could be 'abuse-mailbox' as in Ulrich's example) Does the attribute need to be a lookup key like e-mail? (again as in the example)
probably yes.
Should we make the abuse-mail attribute mandatory for the object types concerned?
No - for the same reasons as with encryption above and:
But that might force us to use a new object type :-(
Return abuse-c by default as well The thing to return is not the name of the abuse-c reference; it's the abuse-mail attribute of the object referred to. Perhaps that's what you meant anyway?
This depends. Id. Like this discussed in the broader-sense of what the Database returns how. Would for example a comment above the Returned objects be useful: % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 131.130.7.32 - 131.130.7.47 mnt-irt: IRT-UK org: ORG-UK1-RIPE netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK6107-RIPE tech-c: UK3 abuse-c: UK3 mnt-by: AS760-MNT mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr@univie.ac.at 20020822 changed: uk@uk.atat.at 20040128 source: RIPE % % Administrative Contact: person: Ulrich Kiermayr address: Vienna University address: Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna address: Austria phone: +43 1 4277 14104 fax-no: +43 1 4277 9140 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK6107-RIPE remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: ACONET-LIR-MNT changed: panigl@cc.univie.ac.at 20010629 changed: kiermayr@cc.univie.ac.at 20020603 changed: ulrich.kiermayr@univie.ac.at 20020805 source: RIPE % % Technical and Abuse Contact: person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK3 remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: UK-MNT notify: Ulrich.Kiermayr@UniVie.ac.at changed: Ulrich.Kiermayr@UniVie.ac.at 20020723 source: RIPE In the classical whois inteface i se broblems modifing information presented. i.e. you should be able to put into the machinary exactly what the DB gave you in the query. (Otherwise tools migt break). But I see no problen in structuring this by means of comments (which are present on top anyway with the well denoted %-sign). or does RPSL prohibit this?
Return abuse-c by default as well (or include default -c i.e. return abuse-c from the least specific inetnum containing the ip in question).
wich in the above Idea means: % % Closest Match Abuse Contact: .....
Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else; so somehow we have to walk the database for them and not put the burden on them or their client software. I do not believe we can expect tool writers (eg SpamCop, geektools) to do that for us; I do not believe we can deploy a different whois client. We might get away with publishing a different server location (whois-for-the-masses.ripe.net? abuse.ripe.net?); or with putting this behaviour on whois.ripe.net and moving the present behaviour to a new address.
more of the first (because of what I stated above).
But don't we want to present the mail address derived from the _most_ specific inetnum (rather than the least)?
Sorry this was a typo. substitute least by most in my statement.
Change the -c flag to use abuse-c instead of mnt-irt.
Depends. -c is handy for both things i think. 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