<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hi</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On Wed, Nov 09, 2016 at 11:40:25PM +0100, Tobias Knecht wrote:<br>
> On another note I find it slightly strange, that in almost every threat<br>
> about abuse-c the topic of data accuracy is brought up, but policy<br>
> proposals like the abuse-c for legacy space has been withdrawn due lack of<br>
> consensus.<br>
<br>
</span>This is not a contradiction.<br>
<br>
Forcing legacy holders to add "something" to the database is not magically<br>
going to create "good quality data" for that something.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​I agree. </div><div class="gmail_default" style="font-family:monospace,monospace">The abuse-c was established to solve the challenge of cluttered places for abuse contact information. </div></div><div class="gmail_default" style="font-family:monospace,monospace">This btw is as well a data accuracy problem. Not knowing which of the fields to use and ending up with a wrong one.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The challenge still exists for legacy space.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As is the mandatory abuse-c today - it created "something" (so we can now<br>
tout how wonderfully complete our database is), but given that it was<br>
forced upon non-caring people, the *quality* of the recorded abuse-c:<br>
values is not necessarily better than it would have been for "if you care,<br>
please register an abuse-c:".<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​I agree as well. </div><div class="gmail_default" style="font-family:monospace,monospace">And again, not having a standardized place to publish abuse contact data will make the data accuracy solution much harder.</div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​We will always have people that will not care and we can only make it as hard as possible for them to not care.</div><div class="gmail_default" style="font-family:monospace,monospace">On the other hand, having a false or non existing abuse contact is already been used as a reputation metric.</div><div class="gmail_default" style="font-family:monospace,monospace">Just the fact that it does not make sense for this community does not mean it does not make sense for any other communities. ​</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For our data, the data quality is less good than before, as I find it far<br>
too annoying to register abuse-c: for customer networks where the abuse<br>
mails *could* be going directly (our parent abuse-c: points to our<br>
abuse handling team, so mails are going to be handled, but might take<br>
longer to reach the customer).<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">​I agree as well here. (3 out of 3 ;)​</div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​And yes abuse-c is not perfect and neither I nor anybody that was working on the proposal said it's gonna be perfect.</div><div class="gmail_default" style="font-family:monospace,monospace">That's why we have this conversation now and that's why we will hopefully have a proposal that will fix some of the shortcomings. </div><div class="gmail_default" style="font-family:monospace,monospace">BUT it should under no circumstances contradict the ideas and solutions that have been ​achieved by it so far otherwise we will run in circles as we already do in some points.<br></div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​​​The same is the point for legacy space. abuse-c is not solving this issue, so lets solve it.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">We might want to start solving things step by step instead of searching for the silver bullet and not getting anything done. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For many PI holders I have seen auto-generated abuse-c: ("forced!"), which<br>
bascically duplicates the normal contact info.  Yay.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​Before abuse-c was existing we saw 38% non deliverable reports in the RIPE region.</div><div class="gmail_default" style="font-family:monospace,monospace">​Meanwhile we are down to 12% </div><div class="gmail_default" style="font-family:monospace,monospace">Yay.</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​Thanks </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Tobias​</div><br></div><div><br></div></div></div></div>