[acm-tf] Draft of RIPE NCC Fuctionality Document

Hi all,

> On 13/Jun/11 17:06, Brian Nisbet wrote:
>> In conversation with Denis Walker from the NCC he let me know that he
>> had a document which proposed a way of dealing with some of the
>> matters the TF is dicussing. I'd like to share this with you today
>> (and, indeed, apologies for not sending it out to you sooner) and
>> discuss it on Wednesday. The document is a design approach based on
>> the current DB model that could form the basis for a policy
>> discussion.
> 
> I think working out this kind of stuff is exactly what a mailing list
> is optimal for doing, as participants can propose snippets of text and
> give +1/-1 feedback about them in order to reach consensus.  If Denis
> had posted this file to the list in May, we could have begun
> discussing it then.

If this document would have been accessible in May we would have posted
it earlier but there was a major need to change and simplify this
document before posting it.

> Foremost, the paper has a section named "What to do if no dedicated
> abuse handler found", but never actually spells what to do if it /is/
> found.  It obviously assumes people have (their own) knowledge about that.

Right. That's because this Task Force was build to find a way of
publishing abuse contact information in the whois and not create a best
practice document for abuse reporting.

> The document mentions "a web interface for the public to use
> directly."  I hope it doesn't refer to end-users.  IMHO end-users
> should just click This-is-Spam buttons.

I agree. Never the less you will not be able to leave end-users
completely out of scope. We already have the Abuse Finder
(http://apps.db.ripe.net/search/abuse-finder.html) and there was not a
problem at all with this tool and end-users. So I think offering a
webfrontend like this is needed and does not hurt anybody.

> I think the tool will mostly be used in scripts (for forwarding
> messages reported as spam to the right handler(s) --a process to be
> defined).  An interactive version would be fine, of course.

Absolutely. But again this can't be done in this Task Force.

> Care has to be taken for the "e-mail" attribute not to be misunderstood.

I agree. I would change this in the document and make the e-mail
attribute mandatory again and not optional. IMHO there is a need for an
email address for personal conversation and a need for an email address
for reports as well. And absolutely true, there must be a good
explanation in the documentation to clarify the difference between both.

> Abuse reporting is going to be a cooperative effort.  Defining abuse
> contact to be mandatory may result in abuse-mailboxes directly
> connected to /dev/null, a waste of resources for both setting up and
> running them.  Having TiS buttons directly do nothing in such cases
> would sort the same effect more cheaply.  OTOH, spam scoring tools may
> learn to take into account whether a message can be reported as spam
> or not, so I'd rather opt for auto-removal of non-functioning entries.

If we make it optional it will be used as a measurement of network
reputation. Which means people will use it as measurement to rate
incoming mail/whatever streams. If the rating is getting worse, people
will create it, link it to /dev/null just to get better reputation.

The only way to figure out if somebody is doing a good job with abuse
handling, is to look if the same problems occur over and over again or
if they get fixed.

But this is as well not a part of this Task Force.

Thanks,

Tobias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20110615/1c8d6553/attachment.sig>