Updated reorg proposal, based on Monday's discussion

[Harald Tveit Alvestrand <harald@alvestrand.no>]

Some changes, some clarifications, some points marked <UNCERTAIN>.
Added a section of "problems" at the end, which is not for inclusion in the 
final version, but for not losing track of what people have mentioned while 
discussing it.

What do people think?

                      Harald

(BTW, the "is intended to address" section was EASY to write.....)

------------------------------------------------------------------
A reorg plan for IETF decision-making
--------------------------------------

This plan is intended to address the following issues 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

  2.6.1 Span of Authority
  2.6.2 Workload of the IESG
  2.6.3 Procedural Blockages
  2.6.4 Consequences of Low Throughput in IESG
  2.6.6 Concentration of Influence in Too Few Hands


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 (helps, by causing more of the strategy for the areas to be 
documented)
2.3 The IETF has Difficulty Handling Large and/or Complex Problems
   (helps, by causing more people to be responsible for the "big picture 
view")
2.6.5 Avoidance of Procedural Ossification (harms; 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 (helps, by putting more 
people in close contact with others through formal roles)

Outline
-------
The following changes are made to the function of the IESG:

- The number of people in the leadership is EXPANDED from the current 13
 to a number somewhere between 25 and 40.
- Each member of the decision-making group 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.
- Each "area council" is headed by one "area supervisor". The set of "area
 supervisors" together form a "technical leadership team".
- 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 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

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.

Area Council: WG management
---------------------------
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.

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>

The leadership team
-------------------
The leadership team, consisting of one area supervisor for each IETF area, 
the IETF Chair and the IAB chair, is responsible for:

- 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
- As part of maintaining that view, making final approval of WG charters, 
changes to WG charters and WG termination
- Document clearly what the approval criteria of the IETF standards process 
on documents are
- 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.

The executive function
----------------------
Other proposals for change have suggested creating an executive function to 
deal with administrative issues of the IETF. This is not described in this 
proposal, because the concerns are largely orthogonal to the structure 
described here.

Details
-------
All members of the leadership are selected by the nomcom for membership in 
an area.
The nomcom also selects which member is supervisor an area.
<UNCERTAIN>The supervisor may also be selected by the members of the 
council, or by other means. Yearly selection by the council? If a 
supervisor steps down, should the council or the leadership team be able to 
select an interim supervisor </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.

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:

- The number of people we trust with making decisions grows by a rather 
large amount.
- 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.
- 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.
- The issue of different review teams giving different feedback is 
important. Consistency is not something we want to lose.
- 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"?