At 11:51 AM 3/8/2001 +0900, Jiwoong Lee wrote:
>Questions. Is it a good tradition to form a 'design team' in a WG and to
>let that group design something excluding the rest of the WG, and to
>accept the design result as a WG official opinion ?
Design teams are a solution (not the only possible one, or the only common
one) to the issue of size.
If you look in on the average working group, even if there are hundreds on
the mailing list and a couple of hundred in the average working group
meeting, you will find that there is a relatively small group, rarely more
than a dozen people, who are actively contributing to any given document.
This is not because the IETF is exclusive; it is because it is hard for a
large group to productively work on a document.
What tends to happen is that the working group stratifies. There are a
small number of people actively providing text, and they often have
specific expertise. If it's a MIB, several of the direct contributors have
probably written a MIB before. If it's a routing protocol, there's a good
chance that the contributors work for router companies or for people that
will be using the routing protocols. If it is something to do with Public
Key Infrastructures, they probably have strong credentials in the area.
There will be a larger group commenting on the text - ensuring that
capabilities important to them are included, noting problems they see, and
so on. But by and large, the folks on the list will be silent.
Why let silent majority? I think it's because they are interested more in
using the technology than developing it, and mostly want to know whether it
is actually going to be useful. If it is going well, they monitor and move
on. If it goes into the dumpster, they just move on. If it goes a little
awry, they will sometimes send individual messages to the list, and more
often take one or more of the principal protagonists aside, and say "wait a
second, what's going on here?"
Design teams are a formal designation for "the folks working hardest on the
technology". They are not the working group, and they don't speak for it.
But realistically, they are going to have a big impact on the document. The
working group will comment on and ultimately ratify their work, and if they
are not responsive to the working group's needs, the chair and the Area
Director need to know.
If you want to be part of a design team, tell the chair.
>Second one. Is it a good tradition not to ask consensus from the audience
>at the IETF meeting site, if the design team is made of 'core and active'
>members in it ?
Um, what? The recommendation to the IESG to adopt a specification as a
<mumble> standard comes from the working group, and represents a consensus
of the working group. Could you please give me - in private mail - the
context of such a question?
>Final one. Is it a good tradition to consume most of the meeting time in
>debating technical matters of an ID, between the AUTHORS of that ID?
Well, I would certainly hope that the authors have something to say on the
topic, but I would also hope that other voices were heard. The purpose of a
working group meeting is to work out, face to face with high bandwidth,
those issues which have been difficult in sort out by email, where most
work gets done.
>PS. What rights does a WG chair have ?
Would the RFC that defines working group procedure have any comment on
this? Have you read it?
>I hope this coming IETF meeting opens its door to all.
Goodness gracious. Let's try to imagine an IETF meeting that denied access
to somebody. Not that this hasn't been requested - there are a number of
folks who argue strongly that the IETF should limit its meeting size and
tell anyone who doesn't sign up in time that they're late, and you should
see this mailing list and my in-box when somebody can't get their body into
a meeting room associated with a mailing list of 50 people, spec'd for a
meeting of 200 people, and attended by 500...
