Thanks for this, Dave.
Here are some thoughts from my perspective. I'm not sure I agree that we've
seen pattern of "well-intentioned but impractical" blocking Discusses from the
IESG, but I think we've seen some cases. I know I have erred at times :-) But I
think both the IETF and even me have learned over the years to do this a bit
better. And we need to continue to watch for this, or perhaps even come up with
better processes to defend against it.
I'd like to separate this phenomena a bit from the current draft, however. The
basic problem is that the discuss criteria [1] that the IESG currently lives by
states technical flaws are a valid reason for a Discuss. And that "technical
flaw" isn't defined in any manner. It is not limited to BCP guidance, for
instance. And even when there is a BCP, it almost never the case that there are
rules that can be followed blindly. Unfortunately, the beauty (or flaw) is in
the eye of the beholder. The raised concerned can range from ridiculous to
Internet damaging. Say, from trivial design choices to totally missing
congestion control in a situation where it would have been necessary. It is
difficult to devise hard rules about what constitutes a flaw and a valid
Discuss. And if it were possible, I'd have some more work for Henrik and a
quick IESG re-org in the works :-) For now, we are stuck with using good
judgement. Take that congestion control example - we often have to figure out !
if a particular concern applies in a specific setting. Congestion. Or security
- not all security functions are relevant at all layers, for instance. And
people might not agree where a specific case belongs to. One person may think a
change was uncalled for where another might think it was crucial for the
operation of the Internet.
And when there is an argument, the way we pretty much have to deal with these
cases is through (1) discussion (2) community consensus and (3) complaints,
appeals, nomcom, and recalls if nothing else helps.
FWIW, independent of this discussion I have personally reached the conclusion
that the IETF needs to be more careful about anyone's personal opinion
affecting the outcome. No one's personal preference should prevent informed
consensus opinion from going forward. The first two items in the discuss
non-criteria list are related to this, but could perhaps be stronger (they have
some caveats). My recommended process for discussing something that IETF has
informed consensus over is to take it up with the IETF and see what consensus
comes out of it, rather than (say) an AD saying we need to do this or else.
Jari
[1] http://www.ietf.org/iesg/statement/discuss-criteria.html