Subject: IETF procedures, the tradeoff between good sense and rule-following, and RFC 5742

From: John C Klensin <[email-masked]>
Date: Tue, 18 Sep 2018 13:59:59 -0400

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