Hi.
After reading both the "IONs and discuss..." thread and last
month's discussion about the ION Experiment and RFC 4693, I want
to repeat something that at least some of us discussed
extensively during the NEWTRK period (and maybe the POISSON
period before that). Part of this has been said in the last few
days, but bears repeating in the current context.
Several of us have observed that the IETF is not very good at
writing precise procedural rules. Some of us would even claim
that history shows that we are fairly poor. Part of this is a
phenomenon often called "fighting the last war" -- we tend to
see a particular problem occur and then change the rules to deal
with that problem, even if the odds of its recurring are low.
Cumulatively, that results in procedures that have so many
specific cases that no one really understands them. Worse, we
can never anticipate all future cases that might need special
handling, so we either need to be continually revising any
precise rules or we need to tolerate simply ignoring them when
they seem inappropriate. None of those situations is good,
especially since cycles spent dealing with procedural issues are
generally cycles that are wasted (and not recoverable) as far as
the real work of the IETF is concerned.
Our best way out of the trap posed by our difficulties with
writing exact procedural documents and our inability to foresee
the future is to give the IESG a lot of discretion but, to use
Ted's language, hold them accountable. What I think I learned
during the NEWTRK work is that this means, in practice, that...
* Any update to 2026 or other core documents should
limit itself to principles, not procedures. We could
probably use a better statement of principles about the
general conditions under which the IESG is expected, or
permitted, to hold up a document. Getting down to the
"what is a DISCUSS and how they are administered" is
much too far into the procedural area.
* The community should expect that the IESG will figure
out procedural rules that work for it, that they will
announce those rules to the community, and that they
will be receptive to input about them.
* Whatever those rules are, the IESG may change them at
its discretion, but should be prepared for input to the
effect that the ADs must have better things to do with
their time. The things the IESG is not permitted to do
are to change the rules without telling the community or
to ignore the rules it has set. To borrow from specific
POISSON and NEWTRK discussions, games of "Gotcha" based
on "we know the rules and aren't going to tell you
enough that you can make predictions" are not a
legitimate activity.
* While one would hope that the IESG would be receptive
to informal community input and calibration, choices of
procedures can be appealed if necessary and exceptional
demonstrations of bad judgment are legitimate subjects
for discussion with Nomcoms and/or Recalls. Similarly,
once the IESG says "we do things this way" and gets
community consensus that the procedure is reasonable
(even if that consensus is interpreted from bored
silence), doing things in a different way is subject to
appeal.
* The community should never tolerate repeated
demonstrations of bad judgment. While such things have
been rare in the history of the IESG, community
tolerance for it tends to be interpreted as approval and
often causes things to get worse.
If we can't trust the IESG that much, or can't get people onto
the IESG who are of sufficient caliber that we _can_ trust them
that much.
What is interesting about all of this in the context of recent
discussions is that it makes little difference how the
procedural rules are stated or the medium in which they are
published. I would expect the IESG and appeals bodies to take a
statement about how the IESG intends to work seriously whether
it is shouted from the rooftops, embedded in an ION, turned into
a BCP, or chiseled in large letters on stone tablets. If that
is not the case, I think we have worse problems than an ION
versus BCP debate. Moreover, if the IESG were to go back to
whispering about policy changes, or even shouting them from
rooftops, rather than publishing things in some place
accessible, I would hope that the community would take serious
exception to that approach.
Some of this points out, once again, that BCPs are probably the
wrong mechanism for reaching consensus on and publishing process
documents, regardless of what we do with IONs.
Should we keep IONs and, if so, should we keep them in their
present form or so some tuning? Frankly, I don't care about
the specifics. But, if we get rid of them and the price is
either (i) to try to give BCP status to relatively informal
statements about interpretation of principles or (ii) to
encourage the IESG to keep its real procedures secret because
there is no place to put them, I think those would be
significant steps in the wrong direction.
best,
john
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf