[anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)

First of all, thank you for your great feedback.

>> On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
>>> On 10 nov 2010, at 11:30, Sander Steffann wrote:
>>>>> That being said, I still think a single canonical place to
>>>>> store abuse handling information is A Very Good Thing.
>>>> 
>>>> +1
>>> 
>>> Be careful of what you wish for, maybe somebody can produce the
>>> same stats as I did back in 2004:
>>> 
>>> - number of inet(6)num covered by IRT - number of inet(6)num
>>> covered by abuse-mailbox attributes - Number of inet(6)num
>>> containing a remarks field with the words 'complaint' or 'abuse'
>>> in it
>>> 
>>> Creating a 'single point' makes it implicit that others should
>>> disappear and you might throw away a load of data and you don't
>>> know what you will get back for it.
>>> 
>> 
>> I am missing your point here. These might be a lot of garbage data.
>> What is wrong about have ONE consistent way to publish abuse
>> contacts? Don't you find this "A Good Thing"?
> 
> 
> Also have a look at my and Leo's response from yesterday. From the
> discussion I get there are 2 problems:
> 
> 1) Poor data quality regarding points of contact 2) The fact that
> there are multiple places people store this info
> 
> This is about 2010-008, and to quote the summary:
> 
>> "This is a proposal to introduce a mandatory reference to irt
>> objects in the inetnum, inet6num and aut-num objects in the RIPE
>> Database. It provides a more accurate and efficient way for abuse
>> reports to reach the correct network contact and helps reporting
>> institutions to find the correct abuse contact information more
>> easily."
> 
> 
> This proposal clearly addresses problem number 2 and says nothing
> about 1.

Right. Because number 1 is clearly an AA-WG proposal and point 2 is more
a general thing. It would not make sense to put them all together and
leave out data accuracy of other part of the whois database.


> The point I am trying to make is that although the data quality might
> be poor, at least it's there. You shouldn't think easily about
> destroying it and as Sander indicates, migrating it might be hard.
> Further a migration of that data will keep the errors, so you end up
> with the same quality data. The only difference is, it is in one
> place.

Which would be positive and would solve problem number 1, the main
intention of this proposal.

> As Leo said yesterday. At the moment, if you encounter an IRT, this
> is somewhat an indication those guys (or gals) take it seriously and
> so you can expect the data to be correct and the people behind it
> responsive. To a certain point the same goes for the abuse-mailbox
> attribute. The single that people actually added this optional
> attribute means at least the spent some time thinking about it.

I disagree here. We see loads of wrong addresses in the abuse-mailbox
attributes. We do not see loads of them in IRT, because 280 IRT objects
do not give us a huge data base.

And again, you can not judge "only" on the fact, that something is
existing or not. We see as well loads of abuse@ addresses being
published in abuse-mailbox attributes blocking incoming spam reports
because the filter says  "This is spam!".

In my opinion and I have seen other people here suggesting the same
things, if we are thinking about reputation, we have to think about
several levels of reputation.

If the IRT object would be mandatory:

We could differentiate between networks having an IRT Object in place
and the networks that do not have them in place. --> Policy Ignorant

In the next level we could differentiate if the information is accurate
and if it is not, RIPE would have the chance to ask for corrections.

If they do not want to correct the wrong entries, we could say Unresponsive.

And so on ...

All this would give us a much better reputation.


> Or the other way around, if you don't want to be found you make sure
> to hide. Most contact fiels are optional so that is not as hard as it
> seems and the archives of this list contain multiple examples.
> 
> Now it may seem "a good thing [tm]" go make some or all of these
> fiels mandatory. But this is won't give any assurance that it's
> quality data.

Full Ack, but not part of this proposal.

> In fact as an argument against this proposal one might state that
> this has the risk of lowering the data quality. In the current
> situation if it's there, it's there because somebody did care. If
> this one makes it, it's there because it has to be.
> 
> If you pickup a broom and start sweeping the floor because you find
> it dirty and want things clean, it's likely you do a good job.
> Otherwise it would be a waste of your time and effort. In contrast,
> if I stick a broom in your hands and _tell_ you to sweep the floor,
> chances are you don't want to and do a poor job with the dirt ending
> under the carpet instead of in the bin where it belongs.

Seeing that it is dirty does not mean I like to clean up.
And on the other hand if you are a really picky person and ask me to
clean up does not mean that I am doing a bad job.

It probably tells me only, that I should do my job better or different.

But as long as I can not see the dirt I will not be able to decide if I
need to clean up.

> The fact that another proposal tries to fix the quality problem does
> not change this argument, that's another discussion. This one
> addresses the place issue and I personally think there is a risk this
> is harmful for the data quality as it currently is.

I do not get the part with the data quality?

You said  before:

>> Further a migration of that data will keep the errors, so you end up
>> with the same quality data. The only difference is, it is in one
>> place.

So where is the change for quality of data? You are talking about the
quality of work done behind the mandatory object, but not about the data
quality.

I would go that far and say, making the IRT Object mandatory will
improve data quality, because people caring about abuse, but forgot to
update the whois data, will correct it and keep it up2date more easily
because they have to change only one IRT object and not the remark or
abuse-mailbox attribute in 1234 handles.


Thanks again for your feedback,

Thanks,

Tobias

abusix.org





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20101110/04ab3039/attachment.sig>