ietf-mxcomp
[Top] [All Lists]

Re: Problem, System complexity -> Solution complexity

2004-04-06 09:45:52

On 4/6/2004 9:06 AM, Dave Crocker sent forth electrons to convey:

What I later realized was that Pete's comment was really about the
idea of a small, clean and generic mechanism.
Yes, I agree with this. I'd suggest simultaneous threads, each discussing a component, mechanism, policy or service.
We've hopefully nearly all got mail clients that understand threads.
If we have scope-limited threads, they're much easier to reference and refer to later, too.

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 hav[ing] no track record of success. That
is, in an area where we are all still learning how to attack the topic
effectively.
Case in point: I was discussing whether (assuming 2822 headers are being validated) Sender: or From: should be validated, and realized it isn't an "or". It's probably always a good idea to attempt From: validation, even if there's a Sender: that you also want to check; this is better than checking just the first of *Resent*:, Sender:, From:. (Why? Because perhaps the From: is a constant phishing target who wants to say never accept email with a From: in an email not from one of our MTAs.) (I wrote some pseudocode and further explanation around this if anyone is interested.)

BTW, I was wondering if the voting functionality of the kavi asrg website/system is available/would be useful in determining when rough consensus has been reached. But managing that is too much of a headache to be an improvement over reading and remembering arguments made.

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.