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. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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) 9. Authors' addresses John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 john-ietf@jck.com Mike O'Dell President Compass Rose Labs 3143 Cobb Hill Lane Oakton VA 22124 v: 703-620-2265 f: 703-620-1779 e: mo@ccr.org Expires June 2003