Hi.
As the perpetrator, I want to make several observations about
the comments so far. I'm going to divide them into two (or
maybe three) parts, with different subject lines. It might be a
while before you see the others -- I'm trying to get some other
things done this week including a couple of document reviews
that I consider critical. Then I'm going to go back to lurking
and let the discussion continue.
First, there are a class of problems that, no matter how
paranoid or conspiracy-creative one gets, cannot be blamed on
the IESG (or any other element of "the leadership". That is the
tendency for the community to notice a problem, whine about the
problem without being very specific about it, and then, well,
repeat. We don't have even a hope of making progress without
getting specific proposals on the table for discussion. So,
I've generated some proposals in the form of
draft-klensin-nomcom-term-00 and
draft-klensin-stds-review-panel-00. One might even consider
draft-klensin-iana-reg-policy-01 to be part of the package,
although I, personally, consider it to be separate.
I am not nearly deluded enough to believe that these are ready
to go in their current form. Each contains, or more or less
deliberately ignores, details that will need sorting out. That
is what mailing list (and, if appropriate, meeting) discussion
is all about. I would suggest that, in that discussion, people
remember something that everyone who has implemented a
production application knows from that side of their lives:
while not spending enough time in design usually results in
unworkable garbage, one can spend forever in design and still
not get everything right. At some point, one has to find the
right balance point between "more design" and "implement the
thing and hope the design is good enough to permit fixing the
inevitable problems later". Finding that balance point is a
really tricky bit of work. But pretending it isn't out there is
not a recipe for anything good.
I would also ask that people try to avoid the temptation to, as
the saying goes, shoot fish in a barrel. It certainly is
possible to nit-pick these proposals to death, just as it is
possible to apply that remedy to almost anything else. If you
think that things are just fine now, say so -- don't waste your
time and everyone else's picking at the proposals. If you think
that things are not "just fine" but that these proposals don't
address the problem, please identify the problem better for us
and propose some solutions -- again, don't bother wasting your
time picking at these proposals.
One of the difficulties of writing any proposal of these types
around here is that a choice has to be made between
* writing a conceptual document, with little detail, and
having it attacked for not supplying the difficult
details and
* writing down the details, even if only as a proof that
there really are possible consistent sets, and having it
attacked because people don't like that particular set
of details.
In constructing these documents, I tried to find an in-between
point, slightly favoring the latter. But there is no in-between
point, so I expect to be attacked for both. Again, if you
believe there is a problem that needs solving and that something
of the general flavor of one or both of these might help, please
focus on the improvements that need to be made and where the
proposals miss the mark entirely, not on how many details were
either omitted or undesirably included.
Let me also go on record, right here, as not believing that
these proposals, or their likely offspring, are going to be
"magic bullet" solutions for anything. The IETF has, IMO,
gotten into a very complex situation here. Some of the causes
of that are external: changes in the role and perceived
importance of the Internet, more standards bodies wanting to get
into areas where previously only the IETF cared, economic
factors and shifts, more internationalization of everything, and
so on. The IETF either needs to figure out how to adapt to
those changing circumstances in some way or we should just give
it up, fold our tents, and go home. Adaptation includes a lot of
options, ranging from refocusing what we do to making really
fundamental changes in how we do it. And these proposals
address almost none of that, except by accident.
Now, what are they about? They are about making some basic
changes in how we manage ourselves and the standards process.
Either can be looked at in multiple ways -- more in a "half
empty or half full" sense than in a "solving lots of problems
one". Specifically:
One of them reduces IESG workload in the most effective way
possible -- by changing the job description to eliminate a big
chunk of the IESG's load and responsibilities. But, from a
different perspective, its goal is to solve (or at least
significantly improve) the very significant perceived problem
when ADs need to manage WGs, take responsibility for the
products they produce, and then act as the final evaluators of
those products. That is just a bad idea. There have been
comments in the community about that bad idea and its
consequences for years (not just in the Problem Statement
process, although the issue came up there two). To me, that
issue is more important than the workload -- the workload is a
problem we might approach in other ways. What we haven't had in
the years that this has been discussed is a specific proposal.
Now there is one. And, IMO, the discussion should be
(i) Given that a solution to the perceived problem will
probably require something at least this drastic, is the
problem real enough that we care? Or should we just
stop griping about it.
(ii) If some solution that separates functions is
desirable, is this the right one? If not, can it easily
be tuned into the right one, or can we get some
alternatives on the table?
The other one rearranges the way the nomcom considers
candidates. Certainly, it can be seen as a four-year term limit
proposal. Personally, I loathe term limits, for all sorts of
reasons. If term limits were my goal, I could have written a
much shorter and more focused document.
Instead of thinking about term limits, I think we have gotten
ourselves into a situation in which IESG membership is viewed as
a career goal and milestone. Companies want to have people on
the IESG because it is seen as enhancing their competitive
positions or prestige. We have created a situation in which
individual ADs are considered individually more expert that any
of the rest of us. While any IESG member (and his or her
organization) should feel properly complemented and honored by
the fact that the IETF will trust them with that sort of role,
that shouldn't get out of proportion and probably it has.
Again, while one might blame some of the consequences of those
situations on the IESG, the underlying driving issues are Not
Their Fault: we have gotten exactly what we wished for and
should be _extremely_ grateful that those who have been willing
to serve on the IESG now, or in recent years, have been able to
do so, to put up with it, and to do as good a job as they have
under intolerable conditions.
I suggest that it is time to change the perceptions, the
assumptions, and the rules. I think there are huge benefits to
the IETF to seeing IESG service as (to use an example that has
been cited before) more like jury duty in which one gives up
"real work" for a while to satisfy a short-term obligation to
the community rather than some version of the "highest position
one can have around here". I think there are huge benefits to
the IETF to have people with the experience and perspective of
serving on the IESG back in WGs, doing technical work, and
mentoring those with less IETF experience ... and getting them
there well before they burn out. A guideline about how rapidly
seats roll over is an almost-necessary component for getting the
advantages of that turnover. It is not a goal in itself, at
least for me.
To accomplish that, we need to reduce or otherwise significantly
change the workload, otherwise we won't have enough good
candidates (again, the nomcom-term draft isn't the only possible
way to do that, it is just the only specific proposal in recent
years that would do something more specific than handwaving or
ordering the IESG to mend their ways. We need to create the
clear expectation that this is a fixed commitment and that, when
it runs out, pressures on individuals from their companies to
hold onto the seats aren't going to accomplish much. We need to
have a selection and approval model that reduces or eliminates
the sense of "rejected by the community" when someone who was
willing to serve another term was removed -- IMO, that
particular perception is one of the key reasons why the number
of IESG (or IAB) members who have been involuntarily removed
from either body since we started up the nomcom and who have
then been of significant use to the IETF in the subsequent year
or two, can be counted on the fingers of one hand. And we need
to reduce or eliminate the problem of would-be candidates trying
to get permission from their organizations to volunteer, only to
be told that, despite the claims of privacy, it would be an
embarrassment to them and the company ("rejection by peers") if
they were not selected and, incidentally, almost no one wins out
against an incumbent unless, to paraphrase a recent off-list
conversation, that incumbent has obviously turned into a
drooling incompetent.
We also need to understand what lack of leadership depth really
means around here. If we have interest in an activity, but can
only find a half-dozen people willing to do actual work, we
consider it an exceptional case when we charter a WG. If we
have interest in a WG, but no one who is willing to chair the
thing, we may see some arm-twisting, but, if no chair can be
found, the WG doesn't get chartered. I don't believe in hard
and fast rules in either case, but the principles are clear.
While the suggestion in the document is, IMO, fairly bad (I just
wrote it, I don't have to like every word in it), we also need
to start thinking about areas in the same way: if we can't find
people who are willing and qualified to serve as ADs for a given
area, probably it is time to start asking some very hard
questions about that area's ability to do work, develop
leadership, and so on. If those questions cannot be asked (and
the nomcom today has no practical way to ask), then the idea of
rolling ADs over just won't work, regardless of the surrounding
structures.
Will the "nomcom-term" document fix those things? I don't know.
But it is at least a proposal that is on the table and intended
to address that set of issues and goals. The fact that it
imposes what are really "term guidelines"
There is also a metaquestion here, but it is probably worth a
separate note.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf