Colleagues, In June, the IESG performed a conflict review on a document from the Independent Submission Editor, following its interpretation of the procedure described in RFC 5742. The details of the draft involved are not particularly relevant to this note; what is important is that the review illuminated several issues with 5742 and perhaps how the IESG is doing business more generally. A long-standing principle about the IETF is that we put good sense and getting the right things done ahead of a rigid set of rules. We have repeatedly discovered that, when we try to specify rigid and exact rules, we manage to miss edge cases that later require either an effort to modify the rules (making them ever more complex and risking inconsistency) or that we simply ignore them or otherwise work around them. The IESG has traditionally been given a good deal of flexibility to carry out their work. What the community has expected, to preserve transparency and accountability, is for the IESG to carefully explain its actions and reasoning. For example, in recent years, many issues have been resolved and procedures adopted by "IESG Statements". However, RFC 2026 has never been updated to specify procedures for such statements and what can and cannot be done with them. The recent discussion about the definition and handling of "updates" is an example of that flexibility: whatever is to be done, the IESG proposed to do it by "statement", not a new process BCP, explained the proposed action, and invited community input on it. The conflict review evaluation [1] appeared to me to be the opposite of that approach, with the IESG taking the position that they were not allowed to reach any conclusions other than the statements listed in RFC 5742 and with the only explanation being a statement in the tracker that appears to at least some people to be inconsistent with the requirements of the relevant protocol specifications and their history. I tried to appeal on basis of the decision process and explanation (or lack thereof). The response to the appeal appears to me to have completely missed the point the appeal was trying to raise. However, it made at least two points of interest. One was that the IESG believes that it cannot respond to a conflict review request with anything other than one of the specific categories and text listed in 5742, additional comments in the tracker or elsewhere notwithstanding. The other was that, if I or anyone else believed that 5742 was insufficient or inappropriate, I/we should respond by proposing changes via the normal IETF process. draft-klensin-iesg-rfc5742bis, posted last week, is a response to the latter. It is intended to fine-tune some aspects of 5742 but, more important, restores the model of preferring flexibility and good sense over narrowly-interpreted and rigid rules --a model that at least some of us believed was intrinsic to what became 5742 when the community reviewed it. After reviewing the posted version of the I-D and having a few off-list discussions, it is clear that the -00 draft contains some language that is in need of clarification. An updated version should be posted before the end of this week, but the basic substance will not change. I hope that I'm not the only one who cares about these issues and the substitution of rigid rules and, essentially, IESG positions similar to "5742 made us do it", for flexibility when it is needed and clear explanations of decisions and what motivated them. If I am, I think the IETF is in deep trouble but, obviously, YMMD. best, john
