"Adult supervision"

[Keith Moore]

> >I wouldn't call failure of a group to do the necessary background 
> >work "malice"
> 
> The words used in the past few messages are not about "failure of a 
> group", they are about "choices" of a group and "refusals" of a 
> group. Would "willful negligence" be preferable to "malice"? 

That's a legal term, and I don't know the precise meaning.  "negligence"
would certainly be valid.  There's a difference between choice and
intent. 

> still about a *willful* decision on the part of these people to 
> disregard something important, or (as in the house-building metaphor) 
> an act of such huge and obvious stupidity and ignorance that people 
> involved should not be allowed near *any* project. 

Why is it a huge and obvious stupidity in the case of building a
house, and not a huge and obvious stupidity in the case of building a
protocol which 10e8 or more people will use?  Houses are widely
familiar, of course, but we shouldn't assume that a widely-used protocol
design effort needs background work any less than building a house.

Or if you want a better analogy to an expensive and widely-used
resource, consider building a large span bridge without doing any
analysis of the effect of wind on the bridge.  My point is as long as we
are designing protocols like the Tacoma Narrows bridge was designed, we
shouldn't be surprised when these designs fail to take into account some
important consideration.  And WGs need to take responsibility for this
rather than expecting to be told every detail about how to do it.

> >>I have always taken this to mean that a Proposed Standard can't say 
> >>something like, "This protocol requires some way for the client and 
> >>server to rendezvous. It is left for future development to figure 
> >>out how to do that."
> >
> >I have always taken this to mean that a document that fails to 
> >address any important technical concern does not qualify for 
> >Proposed Standard.
> 
> If it meant that, then why bother with the whole paragraph? Why not 
> simply say (as you always seem to misquote it) "A Proposed Standard 
> should have no known technical omissions", full stop? 

because it's unreasonable to expect a single protocol to solve all of
the world's problems.   if SMTP is designed to relay and deliver mail,
that doesn't mean it's SMTP's job to authenticate message originators,
even though somebody could come up with an MTA-MTA protocol that tried
to do that.  in the email architecture authentication of originators (as
opposed to peers) is assigned to a layer higher than SMTP.

however there are implicit requirements, and IMHO resistance to attack
from reasonably anticipated threats fall into that category.  note that
these have changed over time, and probably will continue to change.

Keith