Keith, John C, John L,
I am in agreement with you that the main issue is how well
WGs operate in terms of their timeliness, quality, and
relevance. Just by observing what happens around, you
can see that most of the wall time spent in the creation
of specifications goes to the WG. Or at least that is my
perception in cases I have been involved. (There are exceptions
of course and I don't mean that we should stop shortening
the IESG, IANA, and RFC Editor lead times. They are still too
long.)
Another component that affects IETF's output a lot
is pre-WG time. This is harder to measure, as we don't
have an easy metric for the world-has-a-problem to ietf-
has-a-wg time.
I tend to agree with John C that the IESG shares a
part of the responsibility for the good or bad WG operation.
But I don't actually don't think IESG is that visible during the
normal operations of a WG. This may again by just my
perception, but the chairs get a lot of freedom and
responsibility for managing the group.
But where IESG and IAB have most effect is pre-WG time,
the scope and even the existence of the group. I feel
this is an area that affects perhaps most what will happen
later. If we allow things to be taken up too early, we end
up in having research results that may or may not be taken
into use. If we resist the creation of a WG too long, the
world moves on and creates other solutions or vendor
specific solutions are used. If the right problems are
chosen, we have interested contributors. If the wrong
problems are chosen, progress will be slow and on the
shoulders of one or two individuals. Etc. Sometimes
we do well here. Sometimes we don't, and I have personal
experiences from at least two cases where we really
blew it for no good reason.
Keith, you have been advocating a model where the IETF
would be stricter in allowing what work be taken up, in
order to ensure that we can actually deliver. But I share
the same opinion as John L that we should rather try to
shape the IETF so that it can deliver what the world needs.
Part of the reason why I believe so is that despite its problems,
I think the IETF produces the best technology and highest
quality. I want to use IETF multimedia, IETF network access
control mechanisms, IETF security and not something else.
This won't be easy of course, but I think we can do it. We
are extremely good engineers and we've been able to produce
scalable technology and useful, complexity reducing
abstractions. Maybe time to apply some of that for our
organization as well?
--Jari
John C Klensin wrote:
Keith,
Let me offer a different perspective here as well and, in the
process, explain why I keep coming back to the IESG.
Going back almost to the dawn of IESG time, the IESG has had one
constant and primary responsibility. That is to manage the WGs
and the WG process. Under today's rules, they determine or
ratify which WGs get created, who chairs them and how they are
otherwise managed, what tasks and benchmarks go into charters,
how many and which documents a WG can work on at a time (and
whether they work on documents serially or in parallel), and
when to shut them down. They have _huge_ latitude in how to
manage WGs and the decisions they make about that management
process, including a wide range of options about reporting,
review of benchmarks, actions or the lack thereof when targets
are not met, and so on.
WGs, and WG leadership, have no independent existence: the IESG,
and under some circumstances, individual ADs can dispose of them
as needed.
Personally, I think that is as it should be. While the
community has periodically discussed constraints on WG behavior
and management (including one or two that I have written), none
have ever been approved: the IESG continues to be able to look
at WGs and their work on a case-by-case basis and to make
case-by-case decisions. My personal view is that they (the
IESG) should have a little more guidance from the community to
aid them in making tough decisions and to assure them of backing
when such decisions are made, but that wouldn't change the
essential nature of the situation very much.
But, from that perspective, there is no "WG problem" or "problem
WG". There is only an IESG management problem. Either the
number and complexion of WGs is such that the IESG can manage
them effectively, or it isn't. If it isn't, only the IESG can
be responsible. Either WGs are sufficiently well chartered and
managed so that the review processes we have work adequately
well or they aren't. Either way, the IESG bears ultimate
responsibility: they determine the charters, the management
structure, the review requirements or lack thereof at various
intermediate points, and so on.
I think we agree at least partially on this, because I certainly
endorse the position that we could use resources more
effectively if [we] exercised more care about which working
groups [were] chartered. But, again, the IESG makes those
decisions: all the community can do, at least under the current
structure, is to give them advice and feedback, both about
individual proposed WGs and charters and about keeping the
totals tolerable. But they are chartered to decide, and, if
they don't get it right, the problem belongs to them, not to the
participants in an ill-advised WG.
That isn't an easy job by any means. I assume that, for every
WG we have, there are at least a handful of members of the
community who believe that WG contains the most important work
the IETF is doing. But someone has to start making those hard
decisions and, as responsibilities are now handed out and groups
chartered, the IESG is the lucky group.
Now, it is reasonable to say "the IESG doesn't have bandwidth to
do that job well and still review documents for
standardization". But that statement doesn't fix the WGs. It
might be justification for moving document review to some other
body --presumably not delegated by the IESG but selected by the
Nomcom to fulfill that role. Or it might be justification for
the IESG shrinking back the number of WGs to the point that they
did have time and bandwidth to do both jobs well (and maybe even
have lives and day jobs). Or we might think about a management
structure that shifts the IESG's historical management function
wrt WGs elsewhere.
But it doesn't seem to me that saying "we have all of these out
of control WGs and need to concentrate on fixing them and not on
looking at the IESG" or even "focus our attention on WG
operation" is productive: if the WGs are not under control,
then, IMO, the IESG, as the body with the management
responsibility, needs to acknowledge that fact and then either
needs to fix it or make suggestions to the community as to how
we can fix it together. If they are not convinced that "working
group operations" is the problem, then there is either no
problem or an IESG problem.
john
--On Thursday, 28 April, 2005 09:17 -0400 Keith Moore
<moore@xxxxxxxxxx> wrote:
I believe the IETF could perhaps take on more work if it
improved the process by which working groups operate. This
would lessen IESG's burden by giving them better documents to
work with; it might also reduce the average duration of a WG,
making more room for others. The industry wouldn't mind that
either. One of the problems that some WGs have is that they
take on too many drafts, which both hinders the ability of the
working group to finish its more important work and imposes
additional burdens on IESG.
I also think that IETF could use its resources more
effectively if it exercised more care about which working
groups it chartered. For instance, IMHO we've wasted a lot of
effort trying to come up with short-term workarounds for NATs,
without any of them providing a migration path away from NATs.
If I understand some of Dave's and John K's comments, they
are willing to entertain thoughts on how to do things better
(& differently) in order to ensure that the IETF remains
relevant.
As am I. But I would like to see attention focused on working
group operation, which I believe is our biggest source of
problems.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf