How do we start a new WG or list that focuses on reputation?
Mike Wolf
PeerConnect, Inc.
On 1/2/06, Barry Leiba <
[EMAIL PROTECTED]> wrote:
> Selamat tahun baru.
Bonne année to you too.
I agree with Dave sometimes, and disagree sometimes. For this note,
I agree with everything he says. I have a few things to add (though
as I went through it trying to add more, I realized how unnecessary
that was).
> Unless I have missed something quite basic, the proposed DKIM charter
> and the draft DKIM specifications do not include doing work on reputation
> services.
Just to add one to this:
Yes, that is correct. And if the WG be chartered and if I be a co-chair,
I will certainly declare any discussion of it to be out of scope. That
doesn't mean it can't come up here and there, as part of other discussions,
but we must not focus on it, taking time from the work to hand.
I, as do others, believe that some sort (or sorts) of reputation service
will be important, and should be developed. I see several ways to
approach it:
1. Recharter this WG after its primary work is done.
2. Start one or more new WGs for this, beginning the chartering process
as the DKIM work nears completion.
3. Work on some reputation services separately -- as I believe will happen
in any case -- and bring some of them to the IETF after some experimentation.
I think (1) is probably NOT the right way, but both (2) and (3) will work well.
>> role of reputation. To say this differently, many folks seem to think
>> you can choose a "reputation system" almost at random, and it's sure
>> to improve your signal/noise ratio
I don't think "many" people seriously think that, and hyperbole isn't useful
here. Most participants here (and I base this on what people have said) think
a *well designed* system will be very useful. That's why we should wait until
we've finished some of the other discussions that pend here, so that we may
take the time to design the reputation system(s) well.
>> As a practical matter, _many_ folks will prefer sorting through
>> 100 spams to losing one good email. I see darn little "market" for
>> anything which can't get it 99% right.
Actually, I have a good bit to say about this particular item in a paper
I'm writing for CEAS [and so here's a shameless plug for CEAS, the Conference
on Email and AntiSpam, and an urging to all to consider writing papers for
it: http://ceas.cc, and click on "2006 Call for Papers"]. The bottom line
is that the answer varies, and whatever infrastructure we have has to have
the flexibility to support the varying needs of different customers and groups.
> This seems to suggest a policy requirement for all IETF work, that it
> anticipate and document "obvious" abuses and specify the means of
> avoiding them.
>
> This feels more like a bureaucratic barrier to productive work, than a
> useful adjunct to the technical specifications work that the IETF tries
> to perform.
The suggestion seems so "obviously" reasonable that it's hard to imagine
why we shouldn't do it. And yet, as Dave points out, it could just pull
the reins tight on all IETF work.
Our focus has to be on making sure the specifications are clear. We can
(and we do) talk about some things we do NOT support and that you should
NOT do... but, "obviously", we can't possibly cover all the "don't"s, and
attempts to will fail, and will bring the process down with them.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________ ietf-dkim mailing list http://dkim.org
