Comments on the Problem Statement draft: Document structure

[Charlie Perkins]

Hello Brian,

If there are situations listed that aren't solvable problems,
then the document shouldn't contain them because the
solutionists will be wasting their time.

If there are problems that aren't listed, then I should think
they need to be listed if they are serious, but as you point
out a decision has eventually to made about whether the
serious problems have all been identified.

The editorial suggestions are typically easy to incorporate.
I don't think my editorial suggestions, or even substantive
comments, would materially delay the progress of this
document.  At least, I don't expect to be making any attempt
to delay the document.  I wish that I had been able to make
these comments much earlier, but better late than never.
Or, what in the heck is the purpose of Last Call??!

Regards,
Charlie P.


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