Latency

[john.loughney at nokia.com]

Hi Harald,

You make a good point.  I think that if WG chairs & IESG members
at least contributed to/commented on such a document, perhaps
it would make the requirements phase of any WG go faster.

br,
John

> -----Original Message-----
> From: ext Harald Tveit Alvestrand [mailto:harald at alvestrand.no]
> Sent: 04 February, 2003 15:31
> To: Loughney John (NRC/Helsinki)
> Cc: problem-statement at alvestrand.no
> Subject: RE: Latency
> 
> 
> There seems to me to be an opportunity to do work here....
> 
> it's clear that we've had quite varying experiences with writing 
> requirements documents, and the documents we've produced have 
> been all over 
> the map from "the protocol should be useful for this 
> function" to "the 
> boojum must be distimmed by the doshes".
> 
> if someone were to volunteer to write an "IETF's guide to writing a 
> requirements document", with pointers to particularly good 
> examples of 
> processes that worked well or badly, we actually might manage 
> to identify 
> the useful tool and forget the time-wasting rathole.....
> 
> (this sounds awfully like a requirements document for requirement 
> documents.... the group now has the opportunity to step 
> straight into all 
> the ratholes previously identified - but might want to do so 
> based on a 
> draft, rather than on a discussion......)
> 
> (no, I'm not suggesting this as part of this WG's output. It 
> might be an 
> official output of the next phase, or not - but there seems 
> no harm in 
> trying to start....)
> 
>                          Harald
> 
> --On 4. februar 2003 06:30 +0200 john.loughney at nokia.com wrote:
> 
> > Hi all,
> >
> >> The push for "requirements" documents came from a 
> realization that many
> >> groups have suffered from a failure to identify or 
> constrain the problem
> >> they were trying to solve.  This remains a serious 
> problem.   But we
> >> need to stop asking for "requirements" and start asking 
> for "problem
> >> definitions".  "Requirements" should only be only one part 
> of a problem
> >> definition, and should be limited to things that are essential for
> >> technical (NOT market) success of the protocol (where 
> "success" is not
> >> only interoperation of the protocol itself but also 
> ensuring that the
> >> protocol does not break other things). Other parts of the problem
> >> definition might be called "goals" and "non-goals" and
> >> "considerations".
> >
> > One undocumented feature of Requirements docs is that it 
> often serves
> > as a good way to get a diverse group of people to speak the same
> > language.  I have noticed that when a new WG is formed, 
> many different
> > groups of people tend to try to push their own pet protocol, even
> > if there is no relation to the charter.  Also, people with different
> > appear, with different agendas and backgrounds.  It takes some time
> > before things get sorted out.
> >
> > Requirements docs should not, when used, be a 
> straight-jacket, but should
> > be a way forward, refining the WG scope and settling out 
> the future work.
> > This, alas, often does not happen & often WGs start to 
> breakdown even
> > in the early phase.
> >
> > John
> >
> >
> 
> 
>