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

[Owen DeLong]

On Jul 6, 2010, at 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.
> 
There are contacts and contact records.

No, there isn't an ABUSE field in the existing ORG and Resource
records, but, there are contacts and contact records and structures
to hold contacts.

The problem with the IRT object is that it isn't linked data. Much of the
data contained in the IRT object is duplication of data that is elsewhere.

That's why I refer to the IRT object as a sledgehammer attempting to
destroy a mosquito. It's a large addition of data to resolve a small
hole in the current structure.

> 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.
> 
Yeah, I get that. I got it the first time. I still get it. I'm just saying that there's
one missing piece of data that you need (perhaps 2) which is the
ability to link resources to abuse report destinations for resource holders
that want to receive them.

> 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.
> 
And this is the crux of the problem. First, referring to them as "Personal"
objects is kind of misleading. They are "Contact" objects and can
contain a person or a role contact.

If we didn't already have contact objects, I'd probably agree with you about
the IRT object, but I'd still oppose making them mandatory.

> 
>> 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.
> 
The IRT object being used would create exactly the problem I am
describing. I'm not sure why you can't see the correllation between
the action (requirng an IRT object) and the result (duplication of
data and loss of synchronization).

> Just have a look at this:
> http://www.apnic.net/policy/proposals/prop-084
> 
> This would be the next step after the abuse contact object.
> 
I'm having trouble understanding how your next proposal is
supposed to somehow cause me to ignore the problems with
your current proposal.

Owen