Re: "Discuss" criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]