ietf-mxcomp
[Top] [All Lists]

Re: Problem, System complexity -> Solution complexity

2004-04-06 16:46:33

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>