On Sun, Jul 18, 2010 at 02:06:33PM -0700, Dave CROCKER wrote: > Speaking only for myself, I'll say that it's quite easy to go to many > IETF meetings, but never learn anything about IETF process. When someone > has the responsibility for choosing the people who manage the process, we > ought to focus on ensuring that level of knowledge. Hence the second > pool. I read the draft very quickly, and haven't absorbed it, but I have grave doubts about the premise above, which seems to be very important in justifying much of the additional process being proposed. To begin with, I have doubts that people who really haven't learned _anything_ about IETF process are going to be the ones who volunteer for Nomcom. They might not have the background that someone who has been involved since IETF 1 does. On the other hand, they're not likely to hanker for the old days of a teeny club where everyone knew every area, either. Second, let us suppose that we do eventually get a Nomcom that is in fact completely ignorant in the way the document suggests is possible (noting, of course, that it has actually never happened, and so we're fixing a theoretical problem). Why is that a disaster? It's not like the entire leadership of the IETF is replaced by a given Nomcom. In the worst case, what will happen is that we have a bad year. But there is nothing about the involvement of long-term participants that guarantees a non-bad year. They've in fact happened when we did not have a naive Nomcom. Moreover, perhaps such a Nomcom will cause more feedback to the Nomcom, as nervous experienced IETF participants realise that things they consider important are just not even things to think about for the Nomcom members. I think there are two things at work that undergird this proposal, and many of the other IETF process discussions I've observed. First of all, as protocol geeks we are prone to see any sub-optimal outcome as something that just needs better protocol design, so we are tempted to try to come up with a better specification. Moreover, a large number of IETF participants come from a culture founded around a written constitution, and so the assumption that more specific written rules is a natural one. I believe, however, that these process discussions are mostly harmful to the IETF. They lead to larger numbers of increasingly specific rules that later turn out to need exceptions, which exceptions cause another convulsion of the IETF consensus-forging machinery. Moreover, I think endless talk about how one operates is bad for any organization. (I grew up in Canada, and starting in the 1960s and extending well into the 1990s, we spent almost all our political energy talking about the Constitution.) Despite the claim in the draft that there are "serious problems" affecting the operation of Nomcoms, I'm not seeing what they are. The report from the 2009 chair suggested that there were some things that happened that made some people uncomfortable (and that's the only citation for the "serious problems" claim), but every one of them seemed to be addressable by action by the chair. We don't need more rules for this: we need the chair to do that work, as he or she apparently does year after year. In short, I don't think it is true that there is anything wrong with the current (admittedly low) experience requirements for the Nomcom, I don't see any evidence that someone more schooled in the ways of the IETF will necessarily benefit the Nomcom, and I don't see the evidence that the Nomcom needs more rules anyway. I also think that more process discussion is harmful to the IETF, and therefore I don't think this draft should be pursued. This is not to denigrate the contributions of the people who undertook it in the first place; but having uncovered that the arguments for more rules are weak, we should conclude that more work is not needed and stop doing the work, in exactly the way we would if we discovered that more protocol work would not help. Best regards, Andrew -- Andrew Sullivan ajs@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf