Comments on the Problem Statement draft: Document structure

[Jeanette Hofmann]

On 7 Oct 2003 at 15:42, Brian E Carpenter wrote:

> Charlie has spent a lot of time on this draft. But (and I suspect I am
> repeating myself) I believe we are way beyond the point of diminishing
> returns with this document. I believe, although I have my own quibbles,
> that we should stop investing effort in polishing it. It is a document
> of *no* long-term value;

While I agree with you that polishing efforts don't increase the usefulness of 
the draft, I would hope that it does have some long-term value. After all it is 
the first document in many years that lists in a systematic way operational 
and structural problems of the IETF. As some have remarked during the 
process of putting this draft together, a relevant number of problems  was 
already known in 1992 around the Kobe events. The IETF has not much 
organizational memory, at least not in a written, systematic way. Likewise, the 
IETF's understanding of its own change seems rather anecdotical. In order to 
foster learning processes, drafts such as Elwyn's problem-issue statement 
should be ascribed a long-term value. 

I also don't mind a few repetitions and redundancies in the draft. They make 
the whole text more understandable for outsiders and newcomers, who might 
struggle with some of the problems discussed in the document. 

Jeanette 



 


 its value lies in triggering remedial action,
> and that is where all our effort should now go.
> 
>    Brian
> 
> Charlie Perkins wrote:
> > 
> > Hello folks,
> > 
> > I have some comments on the draft.  I'll break it down into
> > three different e-mail messages, because otherwise I am
> > afraid that many points might be lost.
> > 
> > I believe that the document structure causes the
> > document to lose effectiveness.  It can be improved by
> > some pretty basic reorganization:
> > 
> > - The "Changes" sections should be moved into an
> >    appendix (or multiple appendices)
> > 
> > - The "Acknowledgement" section (currently 1.4) should
> >    be moved to be the last section before the normative
> >    references.
> > 
> > - In Section (2), the first part of the section should
> >    itemize the list of root causes, e.g.:
> >    = Unclear Mission
> >    = Poor Use of Effective Engineering Practice
> >    = Standards Process Abuse
> >    = Workload exceeds available staffing levels
> >    = Unsuitable Management Structure
> >    = Poor WG dynamics
> >    = Inadequate Staff Preparation
> > 
> > This text should be placed before section 2.1.
> > 
> > I know that the IETF participants are "Staff", because
> > I have two IETF t-shirts that say so.  Also I would
> > strongly encourage _short_ formulations for the "root
> > causes", because long rambling formulations just don't
> > get the point across anywhere near as well.
> > 
> > A statement is made that the "Unclear Mission" root
> > cause is the "fundamental" cause.  I don't believe it.
> > I think it's much more a case of arbitrary procedures
> > applied selectively according to circumstance and
> > personal preference.  When I discuss with people at
> > the IETF, I may often hear a point of view that I don't
> > agree with.  But I rarely would characterize it as not
> > having a clue about mission.  Without formulating a
> > proposed "mission statement" to try to prove my
> > point, I would at least like to strongly suggest that the
> > characterization in section 2., preceding section 2.1,
> > is wrong.  If I had to pick out a more fundamental
> > root cause, it would be "Unsuitable Management
> > Structure", at least from the current formulation for
> > the set of root causes.
> > 
> > Thus, I would suggest demoting section 2.2 to be placed
> > _much_ later in section 2.
> > 
> > More in another e-mail coming shortly.
> > 
> > Regards,
> > Charlie P.
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> 
> NEW ADDRESS <brc at zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK