I-D ACTION:draft-blanchet-evolutionizeietf-suggestions-00.txt
(fwd)
Marc Blanchet
Marc.Blanchet@viagenie.qc.ca
Mon, 09 Dec 2002 23:21:50 -0500
-- jeudi, d=E9cembre 05, 2002 19:09:05 -0800 Dave Crocker =
<dhc@dcrocker.net>
wrote/a =E9crit:
> Marc,
>=20
> Monday, December 2, 2002, 1:09:50 PM, you wrote:
> Marc> FYI. a modest contribution. Marc.
>=20
> Many thanks for offering specific suggestions to add to the dialogue
> mix.=20
thanks. The danger to put at the same time problem statements and
solutions, is that people think I'm going directly to solutions. Not
really, but I would prefer to have some finite amount of time for this work
and I'm hoping that this wg won't go for years on just stating problem
statements. I prefer to list problem statements that could have some
near-time-easy-to-implement solutions than to have more bigger problem
statements with no easy solution. I prefer incremental deployment than
large changes...
> Some initial reactions to your i-d:
>=20
>=20
> Marc> New wg chairs MUST attend to wg chair "course" on
> Marc> their first IETF meeting as chairs
>=20
> 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.
>=20
>=20
> Marc> S2: a wg SHOULD have 2 wg chairs
>=20
> 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.
Garantee is probably a heavy word. I won't claim any garantee for any of
the proposed solutions!
But in most cases, I think that having 2 chairs helps to move things
forward.
>=20
>=20
> Marc> S3: before wg is started, the charter AND the requirement
> Marc> document SHOULD HAVE reached concensus.
>=20
> 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,
sorry: charter and requirement does not imply that you have "a fair idea of
how to go about solving it", but
at least, you know and agree on what is the work to be done.
> 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.)
I hate to see working groups that spend a significant time on design and
then go back to requirements. In most cases, I see people leaving, tired,
frustrated, the wg is stalled, etc.... We should avoid going back to
requirements. By making a requirement to have requirements done before a wg
is formed, would, in my book, help to avoid the need to go back to
requirement later on. No perfect solution, but ...
>=20
>=20
> Marc> o P4: Waiting for IETF meetings to identify/reach concensus
> Marc> sometimes delays too much the advancement of the working
> group.
>=20
> 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.
you are right. but my experience in attending meetings is that this is the
(sometimes the _only_ ) place where chairs try to reach concensus.
And one of the reason is the next topic (no easy way to do this online).=20
>=20
>=20
> Marc> Judging concensus based on mailing list comments does not
> usually Marc> show the silent majority opinion.
>=20
> Silence is its own vote. Meetings filter according to travel budget.
> If a participant does not participate, they have chosen not to be
> counted.
agreed. Again, we need a way to better reach concensus online.
>=20
>=20
> Marc> S4: A fair concensus tool between IETF meetings is
> required. Marc> An online voting tool to help sense concensus in
> the wg between
>=20
> 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.
agreed. voting might not be the right word, but again, we need some tool to
help find concensus online without waiting for the next meeting.
>=20
> 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.)
>=20
> 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.
I agree. But not always as easy. Again, some tool to help find concensus
online will be valuable.
>=20
>=20
> Marc> S5: have area experts
>=20
> 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.
Lets give it a try by making this formal: before a wg is formed, we should
have area experts nominated.
Some of my suggestions make wg to start a little bit difficult. I would not
say that starting a wg is easy right now, but, in some ways, if we prepare
more before starting, the end result might be better. =20
>=20
>=20
> Marc> o P6: Lack of transparency: design teams are perceived as a way
> to Marc> bypass the wg,
>=20
> 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.
>=20
> 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.
>=20
> 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.
I would respond by saying that I agree 100% with your comment. BUT, I heard
_so_ many comments in so many working groups about bad perception about
design teams. And I have to agree.=20
Tell me the following difference:
a) X ietfers work together on a draft. They might be asked by the chairs to
do it, maybe not. does not matter. When they are ready, they publish the
draft and the wg can look at it.
b) a design team is "officially" formed by the wg, usually nominated by the
chairs. They go and do their work. They usually publish the draft and the
wg can look at it.
To me, the end result _is_ exactly the same. The difference is that a) have
no bad perceptions.
>=20
>=20
> Marc> S6: Instead of using design teams, chairs ask many
> individuals Marc> to write a document on the subject matter,
>=20
> That is often already done now.
right, and again, my point is that we should "officially" get rid of design
teams inside the process, to have a clear and perceived open process.=20
If many authors work as design teams when writing their documents, that is
up to them, but the ietf process is still crystal clear (well, or
clearer...)
>=20
>=20
> Marc> o P7: Interim meeting are often called with not enough notice
>=20
> Yes, this must be done correctly, but do you really think it is a
> major problem with lack of IETF timeliness and productivity???
;-)))
I will respond that an interim meeting not called within X days is not an
interim meeting.=20
>=20
>=20
> Marc> o P8: Some comments are lost without being addressed by =
document
> Marc> authors.
>=20
> 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.
I have a different experience, but probably not as wide as yours.
>=20
>=20
> Marc> o P9: Room concensus request are often unclear and do not give
> good Marc> results.
> Marc>=20
> Marc> * S9: any room concensus MUST use hands NOT humms.
>=20
> Here again I believe you are misunderstanding the nature of these
> assessment events.
no I'm not. I just say that the tool does not work for the intent.
> 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.
with:
- a co-chair that humms loudly in the mike (as I saw it before)
- some important noise in the adjacent rooms
- etc...
this goes nowhere to me. =20
Taking the inverse: what is the problem of restricting concensus request to
hands instead of humms?
>=20
>=20
> 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.
>=20
> This is a really excellent suggestion. We certainly have all the
> technology in the meeting rooms for this.
- actually from my own experience (in idn wg...), but came clearly as a
request from itojun in the v6ops wg recently.
>=20
> 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.=20
you are right, but very inefficiently and sometimes takes an hour to
converge. And then the meeting is over and the agenda is not done... :-(((
>After all, IETF participants are not known to be
> shy about commenting when someone is being confusing...
I have to say that this statement is not right. I would rephrase as:
- some IETF participants are not know to be shy about commenting ....
However, there might be a lot of IETF participants that are shy (for
thousands of reasons, like culturals, not-english speaking,
shy-because-you-know-that-the-other-well-known-guy-behind-you-will-really-k
ill-you-in-public-with-some-rant, ...) of doing so.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.
In some ways, your assumption is that in most cases, things work fine.
Might be true.
I think what I'm suggesting is a simple solution that would help to prevent
some important problems that are seen which makes contribution, fairness,
openness etc.. much more difficult to happen.
Thanks a lot for your comments.
Marc.
>=20
> d/
> --=20
> Dave <mailto:dhc@dcrocker.net>
> Brandenburg InternetWorking <http://www.brandenburg.com>
> t +1.408.246.8253; f +1.408.850.1850
>=20
------------------------------------------
Marc Blanchet
Viag=E9nie
tel: +1-418-656-9254x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
IANA,W3C,... standards.
------------------------------------------