ISSUE: Goal of problem-statement document

Bound, Jim Jim.Bound at
Sun Jun 8 09:44:06 CEST 2003

I agree with you Spencer.  If we have to have total consensus on root
cause it is death. I think when you see 5 or 6 bright people from
multiple vantage points say something is at the root it warrants at
least being on the list for now.


> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer at] 
> Sent: Sunday, June 08, 2003 12:45 AM
> To: problem-statement at
> Subject: Re: ISSUE: Goal of problem-statement document
> Dear Randy,
> I'm reading your note as carefully as I can, and see you are 
> asking that we understand needs and requirements well. I 
> agree, and want to focus on the definition of "well enough".
> Speaking only for myself, I agreed with our text (and may
> have suggested it) because I strongly suspected that the 
> engineering alternative was discussing each problem, 
> determining its root cause, and agreeing on a prioritized 
> list of root causes before we did anything.
> I would love to be wrong.
> 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".
> I would love to hear other opinions.
> Spencer Dawkins
> ----- Original Message ----- 
> From: "Randy Bush" <randy at>
> To: "Harald Tveit Alvestrand" <harald at>
> Cc: <problem-statement at>
> Sent: Saturday, June 07, 2003 4:21 PM
> Subject: Re: ISSUE: Goal of problem-statement document
> > >    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?
> > 
> > randy
> > 

More information about the Problem-statement mailing list