Network Working Group H. Alvestrand Internet-Draft Cisco Systems Expires: July 2, 2003 January 2003 A two-level structure proposal for IETF management draft-iesg-alvestrand-twolevel-00 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 Internet-Draft will expire on July 2, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document gives the outline of one possible way to structure the work that is presently carried out by the IESG. It is provided to the community in order to solicit commentary and inspire more ideas. The IESG has discussed this proposal, and much of the material is the result of those discussions, but the IESG has not reached consensus on this or any other proposal at the time of publication. Comments are welcome, and can be directed to the editor, the IESG, or to the solutions mailing list Alvestrand Expires July 2, 2003 [Page 1] Internet-Draft Two Level Management January 2003 1. Introduction This document shows one way to structure the management work of the IETF in a way different from the current IESG process. The structure proposed is a two-level management structure, which retains responsibility for WG management and document approval, but where many decisions are taken by a subgroup of the leadership, rather than being taken by either an individual AD or the entire IESG. This plan is intended to address the following issue in draft-ietf- problem-issues-02: 2.6 The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF in particular the subsections o 2.6.1 Span of Authority o 2.6.2 Workload of the IESG o 2.6.3 Procedural Blockages o 2.6.4 Consequences of Low Throughput in IESG o 2.6.6 Concentration of Influence in Too Few Hands More details on the relationship between the problems and the proposal follows after the description of the plan. This document deliberately does not address anything about the organizational relationships of the IETF, the procedures followed by working groups, the form of the standards track or the role of the IAB. This is not because these issues are unimportant, but because this has been written in the belief that it makes sense to discuss this issue separately, and that focusing on this one issue will make the document easier to read and comment on. Alvestrand Expires July 2, 2003 [Page 2] Internet-Draft Two Level Management January 2003 2. Outline The following changes are made to the function of the IESG: o The number of people in the leadership is EXPANDED from the current 13 to a number somewhere between 25 and 40. o Each member of the leadership is a member of TWO kinds of subgroups: * An "area council", charged with overseeing the management of the document development process and the working groups * A "review team", charged with approval of documents for one area. o Each "area council" is headed by one "area supervisor" and a "vice supervisor". The set of "area supervisors" together form a "technical leadership team". o Each "review team" is headed by the "area supervisor" for the area, and consists of one member from each other area, and one member from the IAB. Diagrammatically, for an IETF with 3 areas, and fully filled areas: Leadership Team Area 1 Area 2 Area 3 Area Supervisor Area Supervisor Area Supervisor Area 1 Area 1 Area 2 Area 2 Area 3 Area Council Review Team Area Council Review Team Area Council Review team Alice Charlie Charlie Alice Eric Bob Bob Eric Dave Frank Frank Dave IAB1 IAB2 IAB3 [UNCERTAIN]The inclusion of the IAB in review teams breaks the rule that this does not talk about the IAB. Comments on whether this is a good idea are invited. [/UNCERTAIN] Alvestrand Expires July 2, 2003 [Page 3] Internet-Draft Two Level Management January 2003 3. Terminology Leadership - All the people involved in the process described here. All the functions described here, except for those done by IAB members, are currently done by the IESG, so "IESG" is another possible name for this group. Leadership Team - The team of Area Supervisors and the IETF and IAB Chairs Area Council - the people running an area Review Teams - people doing document review. One team reviews each document. Alvestrand Expires July 2, 2003 [Page 4] Internet-Draft Two Level Management January 2003 4. The component bodies of the proposal 4.1 Area Council: WG management The Area Council consists of the area supervisor, the vice supervisor, and a number of area council members. The area council is jointly responsible for the management of IETF work related to the area it supervises. This includes all aspects currently managed by ADs, except for final approval of working group creation, charter change and shutdown, which rests with the technical leadership team. Each WG is expected to have a single council member who is its primary contact; normally, closely related WGs will have the same council member as primary contact. The area supervisor is expected to work chiefly on cross-WG matters. The vice supervisor is expected to be able to function as backup for the area supervisor, helping with area issues, and being able to function in the role of area supervisor when the sueprvisor is on holiday, incapacitated or unavailable for any other reason. 4.2 Review team: Document approval The review team is headed by the area supervisor, or (if desirable) a review supervisor designated by the area supervisor. It consists of one council member from each of the other areas. One council member may, if desirable, serve on multiple review teams for other areas; this may occur, for instance, where one area does not have enough activity to require a large council. The review team for an area is charged with doing cross-area final review of documents, and ensure that documents conform to the published requirements for the IETF publication form that working group and standards-track documents are held to, as well as being useful for the Internet. If a review team has consensus on approving a document or returning it to the WG, their decision is final (unless appealed); if a review team is unable to reach consensus on a document, the document may be forwarded to the technical leadership team, who can function as a backup review team for the documents. [UNCERTAIN] It may be valuable to add another area council member to the review team, as a backup to the review supervisor. [/UNCERTAIN] 4.3 The leadership team The leadership team, consisting of one area supervisor for each IETF Alvestrand Expires July 2, 2003 [Page 5] Internet-Draft Two Level Management January 2003 area, the IETF Chair and the IAB chair, is responsible for: o Having an overall view of the strategy of the IETF in addressing the challenges faced by the Internet where the IETF can provide useful input o As part of maintaining that view, making final approval of WG charters, changes to WG charters and WG termination o Document clearly what the approval criteria of the IETF standards process on documents are o Serve as a "buck-stops-here" final arbitration function when disagreement occurs within the IETF leadership about what the right thing to do on documents is. Alvestrand Expires July 2, 2003 [Page 6] Internet-Draft Two Level Management January 2003 5. Details All members of the leadership are selected by the nomcom for membership in an area. The nomcom also selects which member is supervisor and vice supervisor for an area. [UNCERTAIN]The supervisor may also be selected by the members of the council, or by other means. Yearly selection by the council? It's also been suggested that instead of nomcom selecting everyone, the leadership team can make selections to the area councils, based on recommendations from the area supervisor. This would not increase the load on the nomcom as much as envisaged here. [/UNCERTAIN] Special care should be taken that the composition of area teams and the leadership team results in functional teams. The composition of the review teams is decided by the leadership team. The whole leadership meets at "leadership retreats", held once a year, and once at every IETF meeting. Teleconferences in the review teams and area teams are expected to happen roughly once a month; the leadership team should meet every 2 weeks. Alvestrand Expires July 2, 2003 [Page 7] Internet-Draft Two Level Management January 2003 6. Discussion Among the important properties of the IETF is that the leadership is in daily touch with the stuff being worked on, and that the final technical approval rests in the hands of people with a wide range of perspectives, all grounded in a common vision for the Internet. This is something we have achieved today, by centralizing all process oversight and final approval to the IESG, and something we do not want to lose. This reorganization attempts to preserve this by keeping document review cross-area, and keeping the review in the hands of people who work actively in bringing the IETF work forward. It attempts to disambiguate the role of the AD (which is both being "WG advocate" and "process reviewer"), so that it is very clear when the members act in one role or the other. Finally, it attempts to reduce the overall load on individual IESG members; the total number of hours spent on IETF work will increase under this proposal, because all bodies need to spend significant time making sure they work well together, but this is thought to be a price worthy of the return. Problems: o The number of people we trust with making decisions grows by a rather large amount. o The training that happens today on the IESG is that people watch other people do review, and learn a lot from that, including level-setting on the difference between "important" problems and "unimportant" problems. o The learning effect of having to review documents from many different areas is substantial. If we review only docs from a single area, that's lost. A suggestion to circulate members between areas might help that, but also reduces consistency between review cycles when the membership of the review team for an area changes. o The issue of different review teams giving different feedback is important. Consistency is not something we want to lose. o If we improve the review this much, are we increasing people's tendency to "leave the nit-finding to the review", or are we encouraging them to "engineer to a known quality level"? Alvestrand Expires July 2, 2003 [Page 8] Internet-Draft Two Level Management January 2003 7. Relationship to the "problem" draft, in detail This plan is intended to address the following issues in draft-ietf- problem-issues-02: (NOTE: Must be updated to -04) 2.6 The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF This plan creates a larger management structure, and makes each task that needs to be done the responsibility of a smaller part of that management structure. Because there also needs to be time to consult within and between the parts of the structure, more man-hours will be spent in total, but the total ability to do work should be increased. The following subsections are addressed: 2.6.1 Span of Authority The problem document points out that the IESG is responsible for a lot of things, and does not distribute its responsibilities. The plan distributes the responsibilities among multiple groups. In particular, the work of document review and WG management is split; while it is kept within the same set of people, the people who manage a WG will no longer be directly responsible for the review of its documents. 2.6.2 Workload of the IESG The plan distributes workload among more people. The initial effort to set up the new structure will undoubtedly be relatively high, but once the system gets underway, the load on each individual within the new system should be significantly smaller. Given the larger number of people with the same type of role in WG management, it should also be easier to shift workload around in the case of people requiring, temporarily, more time for non-IETF things, rather than solving this by resigning their positions. 2.6.3 Procedural Blockages The plan changes the approval process in such a way that it is clearer when someone is acting in a reviewer role as compared to when that person is acting in a manager role. This should help perception of the procedural blocker issue. The plan depends on the percieved success and planned improvement of the ID-tracking tools to make sure the documents are tracked, and that comments that need addressing are recorded properly. In a less obvious effect, the fact that there are many more people at any time skilled in WG management and document review should mean that it should be easier to remove someone who is not up to the task, either by recall procedures or by informal means; the departure of one individual should not have that much influence on Alvestrand Expires July 2, 2003 [Page 9] Internet-Draft Two Level Management January 2003 the process. 2.6.4 Consequences of Low Throughput in IESG Again, the plan assumes that adding more manpower to the coordination role will mean that there is more manpower available to make sure inappropriate delays do not happen. It does nothing directly to address delays caused by working group or document author inaction. 2.6.6 Concentration of Influence in Too Few Hands The plan brings more people into formalized, relatively intensive interaction patterns. The hope is that these new people will bring their own affinity networks with them, and thus increase the total number of people who are known to the leadership. This should allow a larger recruitment base for positions of authority. The larger leadership group also means that there is less risk to the organization involved in choosing people for leadership positions - thus, the tendency to "only recruit from the previously trusted people" should be diminished. It will also have an effect on the following issues: 2.1: Participants in the IETF do not have a Common Understanding of its Mission This plan should help, by causing more of the strategy for the areas to be documented - this is required internally to make sure the leadership has a common understanding of what it is doing, and can thus more easily be made externally available. 2.3 The IETF has Difficulty Handling Large and/or Complex Problems This plan should help, by causing more people to be responsible for the "big picture view" that a cross-area review function implies. 2.6.5 Avoidance of Procedural Ossification It is likely to be harmful on this point; since it increases the need for written guidelines, it increases the need for vigilance in guarding against ossification. 2.6.7 Excessive Reliance on Personal Relationships It does not directly address this point, but it should help indirectly by putting more people in close contact with others through formal roles. This offers more opportunity for forming personal relationships from formal relationships, rather than relying on it happening the other way around. Alvestrand Expires July 2, 2003 [Page 10] Internet-Draft Two Level Management January 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand Expires July 2, 2003 [Page 11]