"Adult supervision"

[Keith Moore]

> The claim was made that an AD would have to explain the same thing more
> than a dozen times.

and you were responding to a suggestion that I made about how to handle
something repeated 4 or more times.

> The inference I made was that this explanation would be sufficient to derail
> a working group effort.

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.  of course, it's easier
to blame the messenger for derailing the group than to admit failure.

> I suggest that anything so important DOES need to be documented.

you were insisting on more than documenting it, you were insisting on an RFC.

> >usually this isn't something that would kill working group efforts,  it's 
> >something that the working group should be doing in order to fulfill 2026 
> >requirements for standards-track document quality, but refuses to do.
> >
> Then it's documented in RFC 2026.

not in detail.  2026 says "no known technical omissions".  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.

> >eventually the more important things probably should be written up as
> >policy and published as RFCs.  but again, this can take several years.
> >If something is so important as to have drastic effects, then the IESG 
> >should darned well be able to get it published sooner. 

like it or not, RFCs are viewed as carved in stone, and RFCs that set policy
are thus subject to extreme scrutiny.  there's no need to do that to provide
direction to a small number of working groups, at least initially.  we need a
lighter weight way of communicating technical direction, one that allows
policies to evolve or be discovered rather than forcing an author to come up
with a policy that will be carved in stone.

> Or else the entire process is well and truly broken. 

maybe what's broken is the expectation that WGs should not have to accept
technical direction.

> If you wish to suggest that protocol documents need to document design
> decisions, then that is a subject where people can disagree, but I would
> tend to think they should not do so.  It could be that a companion 
> Informational document would be nice sometimes.

I probably agree.  the trouble is keeping them in sync.

Keith