Re: improving WG operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]