> Keith,
>
> Let me offer a different perspective here as well and, in the
> process, explain why I keep coming back to the IESG.
>
> Going back almost to the dawn of IESG time, the IESG has had one
> constant and primary responsibility. That is to manage the WGs
> and the WG process. Under today's rules, they determine or
> ratify which WGs get created, who chairs them and how they are
> otherwise managed, what tasks and benchmarks go into charters,
> how many and which documents a WG can work on at a time (and
> whether they work on documents serially or in parallel), and
> when to shut them down. They have _huge_ latitude in how to
> manage WGs and the decisions they make about that management
> process, including a wide range of options about reporting,
> review of benchmarks, actions or the lack thereof when targets
> are not met, and so on.
>
> WGs, and WG leadership, have no independent existence: the IESG,
> and under some circumstances, individual ADs can dispose of them
> as needed.
>
> Personally, I think that is as it should be.
[...]
> But, from that perspective, there is no "WG problem" or "problem
> WG". There is only an IESG management problem.
Without quoting your entire message, let me say that I do agree at least
partially with this. But while at least in theory, IESG has all of the
authority and mechanisms it needs to change working group behavior,
let me explain why, in practice, I don't think IESG can make the changes
that are necessary.
There are many things that IESG cannot do with working groups, for
a variety of reasons.
1. WG participants are "volunteers". For the purpose of this discussion
it matters not whether they are volunteering their own personal
time and energy or whether their employers are "volunteering" the
time and energy. The IESG can name WG chairs (assuming it can
find willing victims) but it cannot "hire" or "fire" participants
based on their qualifications, nor can it do much to create incentives
to fill particular positions with especially qualified people. This is
generally as it should be; however, it removes some of the mechanisms
by which managers in the "real world" produce high-quality output.
2. There is a considerable cultural inertia within IETF that largely
dictates how working groups operate, and which is extremely
difficult to change. For instance, community expectations include:
- If there is a BOF held and sufficient constituency identified for
a working group, the working group must be chartered.
- The working group gets to pick at least some of its own chairs.
- Charter prose that attempts to scope the working group or
dictate how the working group operates is irrelevant once the
working group is chartered.
- Charter milestones are meaningless (in the sense that they are
so poorly defined as to be useless - like publish version -00 of
document X) and irrelevant (in that their dates can be ignored).
- Certain charter requirements, such as (poorly named)
"requirements" documents, are viewed as meaningless hoops
to jump through rather than tools to help the working group
refine its scope and better understand its problem. Whenever
possible, requirements documents are written _after_ the
protocol specification, so that the requirements won't appear
inconsistent with the protocol.
- Discussion is held and decisions are taken on mailing lists, which
are largely unstructured. Any issue can be raised at any time;
any argument can devolve into a rathole and continue as long as
its participants want until it's explicitly terminated by the chair.
- 90% of meeting time consists of powerpoint presentations which
may or may not be relevant to the work currently being undertaken
by the group. The goal in scheduling the meeting is to allow as
many presentations as time permites. Any discussion taken during
presentations should consist of questions about the presentations.
Time remaining after presentations can be used for discussion,
if anyone is still awake.
- It's normal and acceptable for meeting participants to occupy
themselves during meeting time reading their mail, browsing the
web, chatting, or playing games on laptops. Wireless net access
is mandatory.
- Any document produced by a WG must be considered by IESG,
and IESG is required to either approve the document or tell the
WG, very specifically, what it takes to fix the document - even
if the document violates the terms of the charter.
- IESG should provide near-immediate turnaround on a WG's
document, no matter how long or poorly written it is.
3. Relatively few working group participants seem to have engineering
backgrounds or understand how to use engineering disciplines to
straightforwardly develop and refine a specification to the point
that there is high confidence that
- the goals and requirements are understood and sufficiently
precise,
- the specification satisfies those goals and requirements,
- the specification is unambiguous and complete,
- the specification is implementable, with reasonable effort,
in a way that permits interoperation of independent
implementations,
- the protocol defined by the specification is deployable and can
operate with reasonable efficiency for both the network and the
hosts that support it
- the behavior of the protocol when deployed on a large scale
is understood, including its effects on the net and other protocols,
and those effects are benign or beneficial
and that the design rationale and support for that confidence are
documented. To the extent that the confidence exists and is
justified, it is likely to have been developed via an awkward
and inefficient process that delayed the WG's output by months
or years.
Now, again, in theory IESG can specify all of this to the Nth degree,
and there are occasions where IESG has specified most of these things
(one at a time) and made them stick. But it is generally unable to
specify most of those things most of the time and make them stick.
It's possible to view this as a scaling problem, but I think it's more
enlightening to view it as a cultural or education problem. Our culture
hasn't developed or accepted the skill set that it really needs to do
work on this scale (even though some of the individuals do have
engineering skills, and others have intuition that serves them quite
well), and our culture has acquired a number of bad habits that are
counterproductive.
So I don't think that IESG is in a good position to fix these problems,
even though it is in a good position to implement the fixes once they
are understood and accepted by the community.
The real trick is getting the community to be willing to change its
way of operating, and getting the community to understand that
acquiring additional discipline in developing protocols will produce
better output more quickly - once we get used to it.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf