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

[Brian E Carpenter]

(section 2.1)

>    The IETF has previously stated that it is not and does not wish to
>    become a Standards Determining Organization (SDO)

Has it? Where? When?

Also, SDO normally stands for Standards Development Organization.
(Evidence: this phrase gets 3130 Google hits, but Standards Determining 
Organization gets one hit.) This occurs at least twice in the draft.

Personally, I have always viewed the IETF as an SDO. I can't see what
other category to put it in. A clutter (as in "a clutter of cats")?

(section 2.2)

>    o  The IETF explicitly avoids developing test tools for verifying
>       that protocols meet its specifications.

This is out of place. It reads like a solution recommendation, not
a problem statement. I don't think there is any consensus that it is
a problem. In fact, I think many believe that it would be a problem for
the IETF to go anywhere near this.

What you might consider a valid problem statement is

    o  The IETF does not, in general, formally verify its specifications
       for correctness.

(A.2.1)

>       Most participants are initially selected to attend the IETF with a
>       view to the individual helping to ensure that some standard of
>       value to the employer is created and are supported at the IETF
>       with this end in view: To that extent, at least, they are beholden
>       to their employers so that the work that they carry out in the
>       IETF will generally support their employer's business, even when
>       the IETF tries to maintain the fiction that all participants
>       attend as individuals and their company affiliations are left
>       outside the hall.

I have a problem with the phrasing of the last sentence. It isn't accurate
and it implies a judgement. I think a better version is

      ... will generally support their employer's business, even though
      the IETF ethos is that people all participate as individuals
      and express only their own engineering judgements and opinions.

(in other words, we don't maintain any fiction at all; but we do disallow
statements of company position.)

(A.2.5)

>       The outputs from design teams and interim meetings appear to have
>       a disproportionate chance of becoming the final output of a WG.

It would be very strange if this was not the case. Design teams and
interim meetings are set up to accelerate progress. If their outputs
don't become WG outputs, they have failed. I have a hard time seeing this
as a problem.

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

Design teams are indeed selected (not self selected) by WG chairs, not
by an election. I don't see how it could be otherwise. It's annoying
not to be selected; it's happened to all of us. But that's life.
I think this problem is wrongly stated, and we shouldn't draw conclusions
from it.

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

The problem tends to arise with really boring but important documents, 
like MIBs. They will only get done by highly dedicated individuals or 
design teams, and nobody who can avoid it will ever review them.

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.

> 
>    o  Interim meetings are not as transparent as normal WG operations:
>       Scheduling problems and travel constraints limit the attendees and
>       reduce the input spectrum (Marc Blanchet; P7)

We could say the same thing about holding regular IETF meetings
in inconvenient locations. But on the other hand, we could say that
only meeting 3 times a year for a few hours seriously limits progress,
and reduces transparency because of clashes (because nobody can attend
two meetings at the same time). So *not* having enough interim meetings
is a problem.

Bottom line, I don't agree with A.2.5 being classed as a problem.
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.

(A.8)

>    o  We should act like the engineers we claim to be and measure things
>       to determine if there are problems (Frank Kastenholz)

I very much support this. In fact, I'd like to see the Appendix
fleshed out with more facts and measurements (such as the
work that's been done on draft->RFC latency). But not if this
introduces much delay, since we need to be done Real Soon Now.

   Brian