Latency

[john.loughney at nokia.com]

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