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