"Adult supervision"

[Keith Moore]

> > And WGs need to take responsibility for this
> > rather than expecting to be told every detail about how to do it.
> 
> The problem I am referring to is a meta-level higher than that.   In 
> the particular case I'm considering, the proponents of a particular 
> draft considered every one of the points that the "knowledgable person" 
> raised, and came up with a different conclusion than the "knowledgable 
> person" did.   It is not that they hadn't considered the design issues, 
> but rather that they did not agree about the tradeoffs.

It's not sufficient for the proponents of a draft to consider the issues by
themselves when those issues touch far wider concerns than those of the
proponents - they're not in a position to decide those tradeoffs by
themselves.  Nor should a single "knowledgable person" dictate the tradeoffs.
Rather, it's the proponents' and/or the group's responsibility to document the
concerns, propose tradeoffs, and get widespread review and buyin for those
long *before* settling on a solution.  The role of "knowledgable people"
should be to offer proposals and compromises that attract widespread buyin.

> Note that in this case the 
> matter didn't even go to the IESG - it was dropped before that, out of 
> a belief that it wasn't going to fly.

Surely it's better (in our current process) to have such things come up in the
context of working group than at last call?  Though we might agree that we
need to have those issues decided in a wider context long before that.

And what you seem to be implying is that the reason this wouldn't fly in IESG
was becase of the "knowledgable person's" objections.  But perhaps it's really
because IESG had similar concerns, and the "knowledgable person" was just
trying to be proactive in getting them addressed?

> We can't operate successfully if this is the process by which "bad 
> ideas" are rejected.   The answer has to be "here are the technical 
> reasons why you have to evaluate the tradeoffs this way, and here is 
> the process that we went through to determine that this way of 
> evaluating the tradeoffs is actually right, and not just my way."

We can't have narrowly-focused working groups making design decisions that
affect a broad spectrum of Internet interests and insisting on hard technical
objections for those that are rejected.  This won't produce workable
compromises between  disparate interests.  The onus needs to be on the
proponents to get widespread consensus for those tradeoffs.  Even then, the
group can't be the judge of consensus (since it's clearly biased), but it has
to work to obtain it.  That's the only approach that can hope to scale.

> I don't mean to criticize the IESG, the WG chair, or really even the 
> "knowledgable person" in this case.   I think everybody was trying to 
> do the right thing.   But unfortunately, the cost of controversy was 
> weighed much to high in the decision, and the value of solving the 
> problem in the best way didn't seem to have been weighed very much at 
> all.

I hope we'd all agree that we need to get widespread buyin on devisive issues
long before there's a significant investment in them, and our current process
doesn't really encourage that.  It's a lot more controversial to make changes
at a point that a WG is tired and there's expectation that the specification
is overdue - especially when vendors are already shipping it (which they
should not do, but it's hard to stop them).

> Keith has pointed out that it took a long time (four years) to advance 
> his draft.   It took me four years to advance the classless static 
> routes draft.   Ouch.   It would have been nice if we could have 
> accomplished the same level of quality work in less time, but in fact 
> every time the draft was held back, the outcome was a better draft.   I 
> suspect Keith's experience was similar.   My point is that sometimes 
> you just have to suck it up and spend the time to get your ideas down 
> on paper and get consensus on them, even if it takes a bloody long time.

I agree.  We can probably improve RFC turnaround a bit more (in addition to
what we have already done), but in order for the document series to be of high
quality we need to accept multiple cycles of review and comment, and that
takes work.  I'm not proposing we change that.  But neither do I think we
should insist that every bit of AD direction be published as an RFC.  We need
to accept that the RFC publication process is to heavyweight for some things.