[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)

[Tobias Knecht]

Hi again,

>>> I think that an optional abuse-c person object is a better solution. It is far simpler
>>> for people to implement both at the RIR and the ISP/End-user level. People that
>>> want to provide an abuse contact can do so, and, people that do not want to provide
>>> one can expect abuse reports to go to their other contacts. I don't see this as an
>>> unreasonable situation as it has worked reasonably well in the ARIN region for
>>> some time.
>>
>> Okay. I suggest that somebody from the DB team at AfriNIC should say a
>> word about the difference of implementing a abuse-c and an IRT Object. I
>> think that might be pretty helpful. My idea was to use the IRT Object
>> because it is already in the database and just needs to be used.
>>
>> Creating an IRT Object is not more complicated as creating another
>> role/person object. And if there will be a good documentation, there
>> will be absolutely no problem in my opinion.
>>
> Sorry, I meant the complication from the end-user perspective, not from
> the AfriNIC perspective. I figure the AfriNIC staff is pretty smart and can
> handle either alternative pretty easily.

Ah okay. I misunderstood that. Sorry for that.

> I figure, at least from my perspective, everyone is already used to dealing
> with Person records, and, having one more optional field for specifying a
> person record (in addition to tech-c and admin-c, for example) parses in
> most people's brains fairly easily. Creating an IRT object that isn't in whois
> means some other creation interface everyone has to learn for creating
> other object in some other system which they then need to somehow
> link to this new required field in all their records.

Okay to be honest, I do not really care. The only thing what I want to
achieve is having a dedicated abuse object in the AfriNIC Database and
the possibility to get the information when ever I need it.

Another request by members was that there should be the possibility to
add some kind of object that contains 2 email addresses. One for
personal interaction and one for automatic abuse reports. My idea was to
ask for a abuse-mailbox attribute within the IRT Object. So that would
fix that request.

How would you do that with already existing objects? Lets think about
the abuse-mailbox attribute which can be part of every person or role
object. What I do not want to happen that there will be more than one
objects having an abuse-mailbox attribute. That would start the same
trouble we have a RIPE at the moment, that there are 15 possibilities to
put an abuse@ address and in some queries you find 10 of them with
different addresses.

So would it be able to create a special role object that has a mandatory
abuse-mailbox attribute, what I think makes sense, that can only be
linked to an abuse-c?

Or what would be another idea to handle these requests.

>>> If you need to query more than 250 abuse-c contacts per day from a given RIR,
>>> I would argue that you are probably doing something other than legitimate abuse
>>> reporting. As such, I do not see the whois query rate restrictions as a significant
>>> barrier.
>>
>> Wrong. Our spamtrap network receives around 15 million spam messages a
>> day and that is just because we do not want to spend more money to
>> receive more. That is all over round about 48.000 different AS Numbers
>> world wide just in May 2010. 10% of the AS Numbers are based in the US.
>>
> If your spam trap network is concentrating all of those messages into a single
> location to do the queries against whois, then, you should either be using the
> bulk whois policy to keep your own local copy of the data, or, you should be
> optimizing your system so that it doesn't have to query the same source from
> whois multiple times at the very least. 15 million messages probably didn't
> come from 15 million different places.

The bulk whois is not available at LACNIC, AfriNIC, APNIC (JPNIC, KRNIC,
...) and will be stopped due legal issues at RIPE pretty soon.

We are working with caches, what works pretty good now, but not
everybody wants to invest lots of hours in doing so if he just wants to
reports a decent number of reports.

15 million messages come from around 10 million uniq IP addresses.

But I think we can go down another road with issue. If we can not find
consensus on the IRT Object and are not able to stop the query
restrictions, I would propose to start a service like this:
http://labs.ripe.net/content/updated-heuristics-abuse-finder-service

That would probably be more easy than it is at RIPE, because if there is
only one object containing the abuse contact information it should be
really easy to get this done.

>> So in my opinion there is a need of unrestricted query access.
>>
> We can, perhaps, agree to disagree on this. To me, it sounds like a problem
> of application optimization which I would argue should not be used to place
> additional undue burden on the RIR whois services.

Okay lets agree on that. ;-)

Thanks,

Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100616/02ef7ea4/attachment.sig>