Dave, Scott,
At the risk of repeating what a few others have said in
different form, a few observations. Please understand that
these comments come from someone who has been more consistently
and loudly critical about even a hint of IESG arrogance and
assertions of their power than either of you and who has
formally proposed a significant number of ways of dealing with
those problems --real or imagined-- than, I think, anyone else
in the community... none of which proposals have gone anywhere.
I believe that, ultimately, the IETF has to pick IESG members
who can do the job of evaluating documents and consensus about
it and then let them to do that job. And we had better pick
people to do that job who technical judgment and good sense we
trust. If we can't do that, then we are in big-time, serious,
trouble: trouble from which no set of rules or procedures can
rescue us. Much as it makes me anxious, I think we ultimately
need to let an AD raise a Discuss because he or she has a bad
feeling in his or her gut... and pick people who will use that
particular reason with considerable care and who will challenge
each other and work to understand the objection and either
better document it or remove it as appropriate.
If that discussion is abused in particular cases, I think it
means that we need more appeals and, if there is a pattern, more
recalls. In a long-term tradition of the IETF that we seem to
be losing, we may also need more specific, focused, public abuse
(in plenaries and otherwise) from the community, not just from
regular complainers and microphone-hogs. What we don't need is
more rigid rules that either try to anticipate every
circumstance or that give too strong a presumption to the wisdom
of a too-homogeneous WG, especially at a time when fewer and
fewer documents seem to be getting widespread community review
during Last Call.
In that context, I can only applaud this document, not as a set
of rules that the IESG has to follow, but as one that informs
the community about the mechanisms the IESG is using.
Information is good. And, if the IESG discovers that it needs
to update that information every time its membership changes (or
every time they discover something isn't working and make an
adjustment according), I'd consider that a sign of good health:
at least it would show that, at least in this area, historical
rules and behavior patterns are not constraining current
thinking to the extent that replacing IESG members doesn't bring
about change.
At the risk of giving a sales pitch, my other proposals have
been intended to reinforce the model above: I think it is always
going to be hard, in our community, to find IESG members who are
good at doing these kinds of technical evaluations and sensitive
to the issues involved and who are also outstanding managers,
cat-herders, bureaucrats, finance experts, and experts on
organizational behavior. So I have sought to separate some of
those roles. I think that long terms on the IESG tend to breed
detachment from the community and a tendency to put IESG
judgment ahead of that of the community and I don't think we can
solve that with more rules about IESG behavior. So I have
sought to give Nomcoms guidance about terms, to change the
nomination/appointment model, and to make the recall mechanism
more effective in practice. And I have sought ways to simplify
the job and reduce the workload in the hope that we can go back
to treating a term or two on the IESG as an obligation that the
right sorts of people owe the community, rather than a position
to be sought and in the more general hope of broadening the pool
of people who are willing to serve.
The fact that my proposals for change have not been instituted
tells me that the community does not see a serious problem and
doesn't believe that changes are needed. While I believe that
the lack of acceptance of changes has been IESG recalcitrance
and efforts to protect the authority and ways of working with
they are familiar and comfortable, I don't think that changes
the conclusion: the community has ways, however unpleasant, for
imposing changes that have community consensus but that it IESG
doesn't like and has chosen to not use them. I disagree, but I
think the consensus-in-practice is fairly clear and I have to
accept that.
To me, it is in the areas of adjusting IESG scope,
responsiveness, and membership that we need to do our tuning,
not by trying to restrict the IESG to particular ways of doing
its technical evaluations or the statements ADs can make about
specifications submitted for approval and especially what
arguments an AD can use for forcing the rest of the IESG to take
a harder look and initiate an in-depth discussion (internally
and, if appropriate, with the community). More hard rules about
how the IESG does its technical evaluation work won't, IMO, help
us in the common, ordinary, cases and, when an exceptional one
arrives, such rules are likely to force the IESG into making the
wrong decisions and doing the wrong things and thereby hurt the
IETF and the Internet.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf