I-D ACTION:draft-blanchet-evolutionizeietf-suggestions-00.txt (fwd)

[Dave Crocker]

Marc,

Monday, December 2, 2002, 1:09:50 PM, you wrote:
Marc> FYI. a modest contribution. Marc.

Many thanks for offering specific suggestions to add to the dialogue
mix.  Some initial reactions to your i-d:


Marc>          New wg chairs MUST attend to wg chair "course"  on
Marc>          their first IETF meeting as chairs

Indeed. The primary purpose in creating the WG Chair training session
was to make sure that new chairs understand that openness and fairness
need to be balanced with making forward progress. Working groups seem
to miss this rather essential point, these days.


Marc>          S2: a wg SHOULD have 2 wg chairs

Forgive my using a specific example, but IMPP has always had 2 chairs,
albeit different sets for different years.  Having 2 chairs does not
seem to guarantee much.


Marc>          S3: before wg is started, the charter AND the requirement
Marc>          document SHOULD HAVE reached concensus.

Careful.  The idea that a working group should actually know what
problem it is solving and a fair idea of how to go about solving it,
BEFORE being chartered, is downright subversive to a lot of folks in the
IETF these days.  (I, on the other hand, think you are bang on.)


Marc>    o  P4:  Waiting for IETF meetings to identify/reach concensus
Marc>       sometimes delays too much the advancement of the working group.

Meetings are supposed to be for higher efficiency, but are not
supposed to be required.  We need to get back to a working focus being
list-based, without depending on the meetings.


Marc>       Judging concensus based on mailing list comments does not usually
Marc>       show the silent majority opinion.

Silence is its own vote.  Meetings filter according to travel budget.
If a participant does not participate, they have chosen not to be
counted.


Marc>          S4: A fair concensus tool between IETF meetings is required.
Marc>          An online voting tool to help sense concensus in the wg between

You are making a common error about IETF decision processes.  Note
the dictum that we do not "vote" and that our consensus is "rough".
We do not need better voting tools; we need a more diligent effort to
assess and assert rough consensus.

The idea behind rough consensus is that there is a strongly dominant
preference among the group, or at least, no strong minority
preference. (There is always *some* disagreement for any interesting
choice; the question is whether there is a significant constituency
for a particular choice.  If one appears to vastly outweigh others,
then there is rough consensus.)

An example of the flexibility that is afforded to working groups -- in
the name of making forward progress -- is that a chair may make a very
subjective assessment and assert it as a rough consensus decision.
If there is no strong constituency of objection, the decision carries.


Marc>          S5: have area experts

We need them, yes, but have not been having success getting and using
them.  So the hard part to your suggestion is making it practical.


Marc>    o  P6: Lack of transparency: design teams are perceived as a way to
Marc>       bypass the wg,

Marc, design teams are *supposed* to be closed.  They are supposed to
be self-selecting and, therefore, homogeneous.  Their job is to
formulate proposal details.  It does not matter how they go about
developing their text and it is actually destructive to insist that
their operation be public. (All that openness gets in the way of
efficient collaborative design.)  If there is some reason to need all
that openness then do all the design work in the full wg setting.

What *does* matter is whether their proposal is responsive to working
group review and change requirements.  That's a function of
accountability, rather than transparency.

If a design team attempts to coerce the process, it will not help to
make their work more open. The problem is with their needing to
understand that their work is *always* subject to wg approval and
modification.


Marc>          S6: Instead of using design teams, chairs ask many individuals
Marc>          to write a document on the subject matter,

That is often already done now.


Marc>    o  P7: Interim meeting are often called with not enough notice

Yes, this must be done correctly, but do you really think it is a
major problem with lack of IETF timeliness and productivity???


Marc>    o  P8: Some comments are lost without being addressed by document
Marc>       authors.

Yes, input must not be lost, but again I'm hard-pressed to see this as
a core problem.  It certainly has not been an essential failing of any
working group that I've participated in.


Marc>    o  P9: Room concensus request are often unclear and do not give good
Marc>       results.
Marc> 
Marc>       *  S9: any room concensus MUST use hands NOT humms.

Here again I believe you are misunderstanding the nature of these
assessment events. The reason humming is used is because the
measurement tool in *intended to be* very coarse. If the different
hums are close, there is no rough consensus.


Marc>    o  P10: Non-English speakers find it easier to read questions from a
Marc>       screen than to be sure they understand a spoken question.

This is a really excellent suggestion.  We certainly have all the
technology in the meeting rooms for this.

Separately, you are right that questions to the group are often not
clearly stated or generally understood. On the average, my sense is
that these situations self-correct pretty quickly during the
measurement event. After all, IETF participants are not known to be
shy about commenting when someone is being confusing...


Marc>       *  S11: If a wg chair or AD is an author of a wg doc, he should
Marc>          find a co-author and have his co-author make presentations.

The IETF has very flexible rules about this sort of thing. The idea is
that a working group can do whatever it feels is both fair and
efficient. A single wg chair who is also the document author is often
entirely acceptable, for simpler specification efforts.

For more complicated or more contentious efforts, more separation of
functions is needed. It is sometimes true that a wg chair must not
ever be an advocate -- and certainly not an author. Instead they must
focus on the wg process, with authors and others doing all the arguing
and lobbying.

d/
-- 
 Dave <mailto:dhc@dcrocker.net>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850