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(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf