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 <solutions@alvestrand.no>





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]