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]