Minor comments on draft-ietf-problem-statement-00.txt
moore at cs.utk.edu
Fri Feb 28 10:36:31 CET 2003
> > Issues derived from Mailing list:
> > o Design Teams introduce lack of transparency. They are perceived as
> > a way to bypass the normal working of the WG, to push forward the
> > opinions of a (self-)selected subgroup and as closed fiefdoms
> > which are not selected in an open fashion (Marc Blanchet: P6)
> I didn't notice this comment originally, and I have to disagree. It's
> an illusion to think that any document is ever genuinely produced in a
> WG as a whole, except for very small WGs (that almost don't exist any more).
> All real documents are produced by a small team. An official design team
> is the *most* transparent way to do this, because at least the people
> doing it are explicitly identified.
I've certainly seen design teams (ab)used in the way that the document says.
In some WGs the chair does his/her best to give the impression that the design
team's work can be reviewed and tweaked, but not seriously questioned. Too
few WG participants realize that this is a violation of process, or that they
have the right to form their own design teams, or to make proposals as
individuals, with equal consideration given to such proposals.
> Design teams are indeed selected (not self selected) by WG chairs, not
> by an election. I don't see how it could be otherwise.
*some* design teams are selected; others are self-selected.
> > o Design team work is rarely challenged or subjected to external
> > quality control by the rest of the community in the same way that
> > more publicly constructed documents are tested (Elwyn Davies)
> I doubt if that's true.
I would say "sometimes not challenged..."
Firstly, I don't believe there is any such thing
> as a publicly constructed document. Secondly, key documents get
> analyzed to death wherever they come from.
> Example: RFC 3248 is the output of a design team. The WG rejected
> it totally for standards track; RFC 3246 is the standards track
> document, with completely different authors.
yes, that does happen occasionally. it may need to happen more often,
especially when the design team doesn't have a good understanding of the
problem it needs to be working on.
> So I think the conclusion that design teams *cause* lack of transparency
> is false. I think the real problem here is that boring but important
> documents don't get analyzed properly, and that is the quality control
> issue again and nothing to do with design team transparency.
so one way to discourage review of your document is to make it long, boring,
or difficult to read :)
> It's just a fact of life: work done in design teams or interim
> meetings is more likely to survive review by the WG than
> individual submissions discussed in a 10 minute slot at a "normal"
> meeting. And probably that is because it's better quality work.
sometimes it's because the design team has done a good job and the work is of
better quality. sometimes it is because the design team is too-widely
presumed to have authority to dictate the solution. trying to make it either
all one thing or the other is probably misleading.
More information about the Problem-statement