"Adult supervision"

[Keith Moore]

> >working groups choose to be derailed.  a working group that refuses 
> >to understand the constraints on its solution space before investing 
> >significant effort in a solution, has nobody to blame but itself.
> 
> OK, so we are now talking about working groups that act out of 
> malice.

I wouldn't call failure of a group to do the necessary background work
"malice", any more than I would use the term "malice" to describe an
attempt to build a house without first surveying the lot, investigating
building codes, zoning laws, and restrictive covenants, and determining
requirements for space, access, power, heating, cooling, water, and
waste disposal, before drawing up a plan.  I can think of lots of other
terms to describe that kind of activity, but "malice" is not one that I
would choose.

> More likely what is actually true is that we have a large number of 
> working groups with a large number of new participants (and even 
> leaders) who do not understand bigger picture constraints on their 
> solution space. 

Yes, I'd probably agree with that.  Though it is really hard for me to
understand how you can expect to undertake an engineering exercise that
will affect hundreds of millions of users without at least trying to
understand the bigger picture.  That is, maybe you don't understand the
bigger picture when you start the work, but you should at least
understand that you need to understand the bigger picture before
starting the work.

> And (as Edward pointed out in another message) if you 
> want to take seriously the characterization of these less experienced 
> folks as needing "adult supervision", then I would suggest that it is 
> squarely the fault of the adults that they do not convey the 
> appropriate messages to the children in a way that the children can 
> understand.

Well I've always considered that term to be something of a wry joke, and
my gut response to the criticism of that term is really something like
"it's unrealistic to expect people to not try to have a sense of humor
in the face of hardship".  (And I do agree that the term can be
off-putting.)  But to continue the analogy, maybe what we have is a
scaling problem -- when there are a large number of children for each
adult, it's kind of difficult to give individual attention.  

I certainly agree that we need to find ways to better communicate big
picture needs, since what we have is clearly not working well.  I
suspect we'll have to get out of fire-fighting mode before we can find
time to do that, though.

> Can you (and the rest of us) make an attempt 
> to assume that working groups do these things out of a lack of 
> understanding and guidance, and that ADs do these things out of 
> frustration and overwork? 

This is very close to what I do assume, and I didn't indicate otherwise.

> [2026] says "no known technical omissions *with respect to the 
> requirements placed upon it.*"
> 
> >the detail says that (for example) "failure to provide 
> >authentication is a technical omission" or "failure to interoperate 
> >with the global Internet is a technical omission". you'd think 
> >things like this would be obvious, but groups will insist that they 
> >aren't.
> 
> Uh, sorry, but 2026 doesn't say that and, as far as I can interpret, 
> doesn't intend that. The paragraph in question says:
> 
>     A Proposed Standard should have no known technical omissions with
>     respect to the requirements placed upon it.  However, the IESG may
>     waive this requirement in order to allow a specification to
>     advance to the Proposed Standard state when it is considered to be
>     useful and necessary (and timely) even with known technical
>     omissions.
> 
> 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. 
Incompleteness in the spec is certainly one way to fail to address a
technical concern, but it's not the only way.   

(And by "address" I would not claim that a Proposed Standard has to
solve every known problem to everyone's satisfaction.  But pretending
the problem doesn't exist certainly isn't sufficient - the nature of the
tradeoff needs to be understood and agreed to.)

Keith