Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Owen DeLong owen at
Wed Jun 16 00:45:24 UTC 2010

On Jun 15, 2010, at 12:35 PM, Tobias Knecht wrote:

> Hi Owen,
> thank you for your feedback.
>> 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.

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.

Also, you may have missed the subtlety where I was suggesting that the
correct place to bind this was the ORG record, not the child resource
records in most cases.

>> 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.

> 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.

>> Making the contact field mandatory has a number of implementation details not
>> considered by the author, such as interim database referential integrity issues (the
>> time during which some organizations do not have IRT objects and yet this is a
>> mandatory field). These are not insurmountable, but, I believe that it creates an
>> unnecessary burden without much benefit over the simple abuse-c field added
>> to the organization and possibly other object records.
> You are right about the integrity problem and as well that they are not
> insurmountable.
> Nevertheless I'm interested in the information from some AfriNIC DB
> people about the implementation periods.
I agree that is an interesting question, but, I hope you see that it is a separate
line of inquiry from my statement.


> Thank you
> Tobias

More information about the RPD mailing list