This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)
- Previous message (by thread): [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)
- Next message (by thread): [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Wed Nov 10 13:45:42 CET 2010
On 10 nov 2010, at 12:05, Kostas Zorbadelos wrote: > 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. 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. 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. 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. 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. 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. Groet, MarcoH
- Previous message (by thread): [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)
- Next message (by thread): [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]