INTERNET-DRAFT                            John C. Klensin
December 10, 2002                             Mike O'Dell
Expires June 2003


                  IESG Overload and Quantity of WGs
                                          draft-klensin-overload-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This document represents an overview of an evolving technology area
and is not intended to evolve into a standard of any kind.

Copyright Notice

Copyright (c) The Internet Society (2000, 2001, 2002).  All Rights
Reserved.



Abstract

One of the key proposals in the PACT [PACT] draft is a limit on the
duration of Working Groups.  The authors believe that limitations of
that type are too constraining on IESG ability to manage working groups
and areas and that they will not be effective in practice.  We propose
an alternate restriction -- on the total number of working groups in an
Area -- that we believe will have a number of desirable effects (a
superset of those suggested with the PACT model) and that it is more
likely to operate as intended.




. Introduction

The authors share the concerns of the authors of the PACT draft [PACT]
that the IETF is not working as well as it could be and that the ability
to produce high-quality work on a reasonable schedule is declining.  The
question is what can be done to improve the situation within the
constraints of the current organizational model of the IETF.  Our

conclusion is based on observation of the IESG, and the IETF generally,
their processes and practices, our experience as area directors some
years ago, and conversations with more recent ADs.  That conclusion is
that the IESG is simply and observably incapable of performing its
management role effectively given its workload.  From that perspective,
many of the problems on which others have commented are just symptoms.
For example, working groups that do not meet schedules, that depart from
charters, and/or that drag on indefinitely without effective review can
be thought of, at least in part, as the result of inadequate monitoring
and supervision.  Very late input from the IESG to WGs about perceived
problems can, similarly, be attributed to IESG overload and the
consequent tendency to utilize last-minute review and feedback
mechanisms.

This document proposes a direct attack on that underlying problem:
limiting the number of working groups in each area to a number that can
be effectively managed.  It assumes that the current delays and
performance problems demonstrate that the current number of WGs is too
large and must be cut back for the IESG to become effective.  It also
assumes that the threshold for effective management is for an IESG that
is selected using the criteria we have always used for Area Directors
and that they are mortal human beings, most of whom have other jobs and
responsibilities.  The threshold might be higher if we turned most of
the IESG's role over to professional managers, but we believe that would
be too high a price to contemplate and would have other undesirable
effects.

We prefer limits on the number of working groups to global limits on the
duration or behavior of particular groups because limits on numbers
leaves the IESG with the flexibility to manage particular groups as
circumstances dictate.  At the same time, a numerical limit will create
significant natural pressure to eliminate disfunctional, non-performing,
or marginal groups (however the IESG and the community defines those
categories at any particular time) in order to create new ones.

The difficulties in a "limit the number of WGs" proposal are, of course
in the details of transition, of ongoing operation, and in mechanisms
for making exceptions when those are actually necessary.  The balance of
this document explores those details.


. Particular issues in imposing a numerical limit on WGs per area

2.1 How many WGs: How should the limit be set?

We start with the hypotheis that the IESG is severely overloaded, and
that the overload is significantly interfering with their ability to
lead and manage the process effectively, to maintain a broad view, and
to interact with WGs and WG products on a timely basis.  In addition to
our own observations, we have repeated heard the load level given as an
explanation of why things are delayed or fall through the cracks and of
why other things do not get attention in a timely fashion.  We also
believe that "too much load" is a cause of incomprehensible explanations
of AD objections to particular proposed documents.   Cutting back on the
number of WGs appears to us to be the only effective way to reduce the
load without either a significant reorganization of the IETF or of
making WG management rules that would constrain the IESG's ability to
respond flexibly and effectively to the needs of particular WGs.


There is no obvious and objective way to measure the number of WGs a
given area can handle.   For various reasons, the number may different
significantly among areas.  But it is fairly clear that all areas are
overloaded, and that too many WGs increases the workload on the IESG
overall, not just on the impacted area.   We therefore propose a target
of 75% of the number of WGs as of the end of IETF 55 for each area.
That number is more or less an arbitrary compromise between different
initial ideas.  We would expect that, once areas reach that target
level, there would be further review to determine whether they are
functioning well at that number, could handle a few more WGs, or should
be further limited.  And we would expect that those answers might be
different for different areas.

For the purposes of these measurements, temporary areas using ADs with
area responsibilities of their own do not count: the WGs in these areas
use up AD bandwidth.  Hence if there is a temporarly area with N working
groups and two ADs, the original areas for those ADs will each be
counted as having an additional N/2 (presumably rounded up) working
groups.

2.2 Reaching the target

Until the 75% target is reached in a given area, the area will not be
permitted to add a new working group unless it eliminates two.  A "no
new WGs at all" formula would almost certainly be excessive, but this
formula insures steady progress toward the target ceiling.  Once the
target ceiling is reached, the area can be managed according to AD
discretion and existing rules as long as the number of WGs does not go
above the ceiling.  Of course, there should be an exception procedure,
there should always be exception procedures.  We suggest that, since
excessive WGs add to the load of the entire IESG, and that load can
prevent things moving forward even if the relevant area is functioning
smoothly, permitting an area to add WGs over the ceiling (or in excess
of the "kill two, get one" rule) should require unanimous agreement of
the IESG and consensus by the IAB that the new group is architecturally
important.

2.3 New WGs and existing WGs.

Since this proposal is likely to make it quite difficult to add new WGs,
especially during the period in which the areas are moving toward the
target ceiling, we consider it desirable that the community, not just
the IESG, explicitly address the question of what types of work are
relatively more or less important, which groups are bogged down and not
accomplishing enough to justify their costs, and so on.  We see the
tendencies for small groups to argue that they want to do something and
therefore should be permitted to go ahead, independent of thinking about
overall IETF objectives, as one of the causes of an excessive number of
WGs today.  Therefore we suggest that every proposal to the IESG for a
new WG be required to contain an analysis (obviously non-binding on the
IESG) of which WGs were less important, or less likely to produce useful
results, than the proposed new group.

2.4 New areas

Should the IESG decide to create a new area, that area should be
allocated an initial ceiling on its number of WGs that is equal to the
average of the targets for existing (non-General) areas.  Since all
areas (other than the General one) now have two ADs, if a new area is

created with only one AD, it should start with a ceiling of half the
average of the target ceilings for the other areas.   Since addition of
a new area with a significant allocation for new working groups would
significantly increase overall IESG workload, as well as creating a
larger IESG and hence one in which it is harder to get consensus, we
believe that the IESG has more than adequate incentives to avoid
creating new areas lightly.


.  Some additional benefits to the IETF and IESG

As suggested above, a ceiling on the number of WGs would force the
entire community to pay more attention to the tradeoffs between speed
and quality.  That attention would cause serious pushback on ill-
conceived WGs that are likely to keep better-focused ones from being
chartered and would encourage more intense reviews of drifting WGs to
get them out of the way.  It would also encourage the community to focus
more clearly on the question of whether the IETF is really the best
place to do particular work.  By making the community sensitive to the
costs of ineffective working groups, it would presumably reduce the
overall pressures on the IESG to just let dubious WG proposals go
forward and to keep those WGs alive because a small and vocal community
wanted them.

And, of course, fewer WGs would give the IESG members more time to do
their work, especially monitoring the remaining WGs on a current basis,
providing timely feedback, and so on.

.  Security Considerations

This document suggests a changes in IETF procedures for the approval of
new working groups.  It has no security implications except that
reducing the number of WGs, as proposed, might permit better and more
contemporary attention to be given to security oversight as well as for
other topics and issues.

.  References

5.1. Normative References

None

5.2. Explanatory and Informative References

[PACT] Huston, G. and M. Rose, "A Proposal to Improve IETF
Productivity", work in progress (draft-huston-ietf-pact-00.txt, April
2002)


. Authors' addresses

John C Klensin
 Massachusetts Ave, #322
Cambridge, MA 02140
john-ietf@jck.com

Mike O'Dell
President
Compass Rose Labs
 Cobb Hill Lane
Oakton VA 22124
v: 703-620-2265
f: 703-620-1779
e: mo@ccr.org


Expires June 2003