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

[AfriNIC-rpd] Re: Return of Policy Proposal RPD Mailinglist: Abuse Contact Information in the AfriNIC Service Region

Scott Leibrand scottleibrand at
Tue Jul 6 21:57:45 UTC 2010

So, stepping back from debate mode, does this accurately capture the 
majority of what we want to accomplish at this step?

  - Make it possible (and easy) for netblock holders to specify a 
dedicated abuse contact.
  - Store such abuse contacts in the database.
  - Make it possible for anyone to query for the abuse contact 
associated with an IP/netblock, without a 200-query limit.
  - Make netblock holders interacting with AfriNIC aware that they can 
now add a dedicated abuse contact, and encourage them to do so if they 
have such an address available.

I think I've seen a consensus around those items, at least...


On Tue 7/6/2010 2:40 PM, Tobias Knecht wrote:
> Hi,
>> That's fine by me, but, please keep in mind the following principle:
>> Duplication of the same data in databases is bad because it leads to loss
>> of synchronization of that data and poor maintenance practices.
> If the data would be there, we would not have to talk about the
> implementation of such. The data, a dedicated abuse contact information
> is not existent in the whois database at the moment. There are no abuse
> addresses in the whois database.
> We and several other reporting organizations have problems to deliver
> spam complaints to these contacts, because they use spam filters. And it
> is absolutely okay to use spamfilters on personal accounts. And there
> are only personal accounts, because there is no abuse@ object, were
> people can add a dedicated abuse@ address which for example is not using
> a spamfilter. There are no non personal objects available to use and do
> the right thing. And start using an abuse-c is not making it better. You
> are allowing the members to use personal objects and filter the
> complaints with a spamfilter.
> Personal Objects are completely different than the IRT Object. That's
> why RIPE is using them and that's why APNIC decided to use it. Because
> they are tailor made.
>> It is my belief that the IRT object would result in this type of duplication
>> and loss of synchronization regardless of the front-end implementation.
>> If not immediately (assuming a perfect initial implementation of the
>> front-end), then, likely in the longer term as the synchronization
>> requirement gets forgotten in some future update to the front-end.
> The point is, that we are not bringing up all our policy proposals at
> once, so we would like to go step by step. And the problem you are
> mentioning is not a problem of having a dedicated abuse contact object,
> it's more a problem of data accuracy and people forgetting about
> updating their objects.
> Just have a look at this:
> This would be the next step after the abuse contact object.
> Thanks,
> Tobias
> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list