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

[RJ Atkinson]

On Friday, Feb 28, 2003, at 07:55 America/Montreal, Brian E Carpenter 
wrote:
> (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")?

SDO does normally mean "Standards Development Organisation".

Some view IETF as a technology development organisation,
rather than a standards organisation.  I prefer to do so.

I'm not aware of any previous IETF statement "that IETF is not and
does not wish to be a SDO".  I like the statement and agree that it
would be an excellent statement to make, but I don't think IETF has made
it so far.

In short, please either edit the current text or add citation
to the instance where the statement was made in the past.


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

It is not fictional that I've *always* left my company affiliation
out in the hallway.  Cisco is the only employer that I've had that
had an issue with me taking that 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.

Agree with Brian.

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

Some design teams are self-selected.  Design teams are required to bring
their output back to the whole WG for review and consideration.  The
whole WG is entitled to change, ignore, or delete any of the design 
team's
outputs.  If a Chair is managing a WG in a manner that does not let the
whole WG do so, then that would be an appealable process violation under
RFC-2026.

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

Agree with Brian's points here.

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

Agree with Brian.  On more than one occasion, I've used the mailing
list of a WG to object to some "tentative conclusion" from some
sparsely attended interim meeting.  More than once, the rest of the
list supported that objection and the "tentative conclusion" was
dropped as a conclusion.  Existing rules say that list discussions
are pre-eminent over any in-person meeting.

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

Agree with Frank.  Don't agree that we should cease to act like 
engineers
just because of anxiety about delay.  That is not to suggest that
repeated senseless delays have any part of good engineering.  We do
need to avoid repeated senseless delays.

Ran
rja at extremenetworks.com