I do not agree, I think this group is not 'charged' to do anything but research
into ways to mitigate spam (not stop spam) by developing methodologies
associated with "consent-based communication" and methods for enforcement of
policies associated with it by 'investigating the feasibility of (1) a single
architecture that supports this and (2) a framework that allows different to be
plugged in to provide different pieces of the solution.'
That is not a 'charge' to "stop spam" OR "stop spam by method X."
In fact I feel that is a fundamental flaw in many of these over-arching
dialogs. Where I see congruence however is in the desire of the group to
provide a solution that is easily deployed and desirable to use.
I would like to stress that my reading of the charter seems to indicate that
there is a requirement for interoperability of solutions or approaches
envisioned in this research activity in order to achieve (2) above. Whether
that is network or application interoperability, single-ended or double-ended
does not appear to be relevant at this moment as a framework has not yet been
developed nor a single architecture. NOTE I wrote 'at this moment' as this may
become an issue (or not) later on. You are both correct in pointing out
developing these types of solutions requires innovation AND standardization to
achieve the stated goals of the investigation activities. So it appears there
are two tracks for discussion.
I have stated this before - we are working without a net while we have no
requirements. Russell Brand and I are working on a format and presentation of
requirements and it may be helpful to vet those with this group (or not)
depending on how it impacts the performance of research toward a solution,
IMHO. In any event I hope that can clarify at a sufficiently abstracted level
a) the problem, b) the requisite component effects and c) the rationales for a
solution/method.
It does not appear many do know how to approach development of such a
framework, in a practical way, and perhaps all of the wrangling is warranted
but I am getting the feeling that most of this is posturing among this group of
very talented people. Again, I have stated this before. We know the problems
pretty well. Let's get on to the innovation and not continue down these
lengthy unproductive side-tracks.
The question that began this long back and forth was I think (in high level
terms): Will core or edge be better for developing an approach (DC). The
answer I think was: I don't think we can know that yet, we need more discussion
or some better examples (PHB). At least that is what I read into the
conversation.
There are other issues involved in developing a framework, e.g., in the subject
of this message; let's not forget them.
-e
On Tuesday, April 22, 2003 12:29 PM, Hallam-Baker, Phillip
[SMTP:pbaker(_at_)verisign(_dot_)com] wrote:
Again Dave, you are putting mechanism ahead of analysis.
This working group is charged with a purpose, to stop spam.
It is not charged with stopping spam by method X.
This group should not be proposing mechanisms that are worse
than non network based mechanisms.
Best practices statements have long been a feature of the
IETF and IRTF. These have rarely considered the purely interop
issues you are promoting.
Like many others in the IETF you appear to have the idea that
it is somehow your position to impart your learned experience
to this group. We are well aware of the issues you have raised,
you are not the first to have raised them.
Your intervention is understood to be well intended. Understand
that this is an area where interventions by individuals whose
interests lie in no solution being developed are likely.
What is needed at this stage is a FAQ which states the problems
identified with the frequently proposed solutions. So each time
we get another tourist comming to propose 'Sender pays' or
'making each person who sends me email play a little game' or
such we do not have to go through the whole education process.
I would like to propose that each proposal for a spam solution
that already appears on the list be required to start what
solutions it proposes to the problems identified in the FAQ.
So that the next person to suggest sender pays is expected to
explain what solution they propose for the infrastructure cost,
double ended deployment problem, the freerider problem, etc.
Phill
-----Original Message-----
From: Dave Crocker [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Tuesday, April 22, 2003 11:20 AM
To: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Spam Control Complexity -- scaling, adoption,
diversit y and scenarios
Folks,
There seems to be some confusion about the nature of a networking
standard.
Networking standards are very different from software development.
They specify conventions for inter-operation. That is, they provide
for some type of interaction that has functions and formats that are
pre-speicified (ie, standardized.)
So if this group has any interesting in doing work that leads to
networking standards that pertain to control of spam, it needs to
focus on conventions for interaction between Internet systems. That
is, protocols for relevant distributed functionality, and formats for
relevant shared information.
The list that Vernon produced provides some excellent examples. By
contrast, simply saying that there is a component somewhere in the
system -- such as a filter -- does *not* provide a useful example,
unless there is an indication of the types of conventions that should
be standardized, to permit the filter to do its job.
d/
TT> Dave Crocker wrote on 20 April 2003 02:19
"doubled ended" sounds like a dandy term. what does it mean?
if it means "at both ends" then i would be quite
interested to hear how
any enhancement that involves interoperability can be
useful if deployed
to only one component.
TT> Example 1:
TT> Email filteroing for viruses. Implemented at receiver's
end. Or at
TT> sender's end. Doesn't matter which. Doesn't have to
implemented at both
TT> ends for parties who wish to interoperate. Implement at
receiver's end only
TT> if you don't wish to interoperate with deliberate
transmitters of viruses.
TT> Example 2:
TT> Spam filtering using a reliable BL. Implement at
receiver's end. Implement
TT> at sender's end if you think of sender as including ISP
MTA as well as
TT> end-user MUA. But don't implement at receiver's end if
you don't want to
TT> interoperate with spammers.
TT> Frankly, I think your comment is crazy. I could go on
listing enhancements
TT> that can be applied at one end or at the other end or at
both ends and still
TT> allow all required interworking until I got writer's
cramp, and still would
TT> not have listed all the ones that I have seen implemented.
TT> Tom Thomson
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg