Minor comments on draft-ietf-problem-statement-00.txt

[Keith Moore]

> >    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.