I'm in agreement with most of what Dave said, so I will be brief and snip a
bit.
--Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Revelation.
As is becoming painfully regular, Pete Resnick once again took a
position that I under-appreciated until later.
First let me say that I appreciate your saying this and acknowledging what
Pete said. Thanks.
What I later realized was that Pete's comment was really about the
idea of a small, clean and generic mechanism. Even if it doesn't prove
all that successful for one requirement, it is likely to be useful for
another. This kind of robustness can be particularly important when
tackling a difficult problem and have no track record of success. That
is, in an area where we are all still learning how to attack the topic
effectively.
I agree with this idea. I would rather have something clean, small, and
generic (and risk having to extend or alter it later) than to have
something overly-complex. The key will be to see if it meets some minimal
goals for what we want most, in the kinds of checks we are most likely to
need and actually implement.
When dealing with a complex problem, in a complex system, it is just
too darned easy to create a complex, baroque and ultimately useless
solution. The way to fight against that outcome is to look for small,
incremental steps and make sure we understand them.
I think I agree with most of this. To me "incremental" implies "iterative"
or "broken up into many smaller parts". "Incremental" is attractive to me,
because it acknowledges that this proposal is not the Final Ultimate
Solution to the Spam Problem (or even the Forgery Problem). But I don't
think I would take it to an extreme of implementing what we know we need
NOW in many small parts.
It think that the paradigm we should be taking for dealing with spam
is to distinguish between:
Components -- small units of functionality
Mechanism -- Collections of components that form a whole capability
for doing something useful in the problem space.
Policy -- Rules for determining use of the mechanism
Service -- Mechanisms and policies combined to achieve something
useful in solving the problem.
This sounds pretty cumbersome, but the dangers of attacking all these
at once are confusion in the design and, ultimately, a solution that
don't get used or don't work. By separating them, we must discuss and
understand them _separately_. We must develop consensus on each,
without the distractions of the others.
These are useful categories, but I'm not going to reject ideas or
discussion that doesn't fall neatly into one category or another. I'm
concerned that a serious attempt to "over-structurize" the discussion might
bog it down to the point where nothing gets done.
There are also discussions we really DO need to have that involve multiple
subject areas. I like the idea of setting down our ideas in writing
according to groups like these, but the discussion can't confine itself to
only one at a time.
Thus we build a total service using pieces that we understand and
agree on, rather than essentially having to wave our hand over a whole
service proposal and do a single thumbs-up or thumbs-down popularity
contest.
For example, if we are going to do a DNS-based registration scheme,
then we should define it generically, so itt can be used for different
things. Then we should define a particular use for it. This is what
Pete is suggesting.
Agreed. One way to go about it is to take a proposal written for one
purpose and see how well it adapts to another purpose.
I agree sufficiently to be submitting a revised version of my own
proposal that separates the underlying components from its application
into a mechanism for MTA.Helo checking. (The policy of what to do with
that checking becomes yet-another discussion.)
Hey, you read my mind! Or you're one step ahead :)
Thanks
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>