ISSUE: Goal of problem-statement document

[Randy Bush]

>>>    We, in line with many contributors to the mailing list, do not
>>>    believe that the process of problem resolution will be helped
>>>    by continued rework of the root issues in what would probably
>>>    be a vain attempt to achieve any sort of consensus.  Instead,
>>>    the general tenor and scope of the problems identified will
>>>    provide a guide in setting up the processes needed to resolve
>>>    the problems and provide input to the resolvers.
>> 
>> i always found this part particularly amusing considering it is
>> being pushed by the same folk who so strongly push for a classic
>> software engineering management view of the wg product process.
>> how can we think we will produce a good result if we do not first
>> define the needs and requirements well?
> 
> I can't speak for others, but my goal here was to avoid
> having to figure out what the IETF consensus was on a
> prioritized root cause list before moving on any root cause.
> This looked like death to me. I don't believe there are ANY
> scope limits on discussions about the relative priority of
> root IETF problems, unlike our normal engineering work.
> 
> So I thought developing a root cause list (which we have
> done, at least at some level) was sufficient, without spending
> time trying to determine priorities. I thought this was "good
> enough".

problem is that the statement in 1.3 does not say that.  the word
priority does not occur in 1.3.  again, it says very clearly

   We, in line with many contributors to the mailing list, do not
   believe that the process of problem resolution will be helped by
   continued rework of the root issues in what would probably be a
   vain attempt to achieve any sort of consensus.

i applaud the later attempts to get at the root issues.  but i
believe the above statement dilutes their importance and could
[unintentionally] be used to dilute attention to the root causes
when we try to find ways to work on the problems.

randy