Keith Moore moore at
Mon Feb 3 13:43:21 CET 2003

> Almost any working group has to
> now go through a much longer chartering process, fairly extensive 
> 'requirements' and 'framework' documents, before the working group is 
> even allowed to talk about protocol development. This is a process 
> change which was (I believe) never really discussed and isn't really 
> documented.

It's not a process change.  WG charters must be approved by IESG,
and working groups have never been given authority to work on things
that weren't in their charters.  

Now having said that, I'm very strongly of the opinion that we should
not be requiring working groups to do "requirements" documents. Or at
least, we need to be a lot more careful about differentiating between
"requirements", and "design goals" or even "problem definition".

All too often requirements documents end up being "wish lists". In
order to get consensus and to move on to the "actual work", anything
that someone might consider a requirement for the result tends to be
included as a "requirement" in some form, no matter how costly or
unrealistic it is.  Then when it comes time to do the protocol work the
requirements document is either ignored or (less often) used as a stick
to insist on unrealistic design constraints.  Sometimes there is an
effort to edit the "requirements" document so that it fits with the
protocol that was actually designed, in order to gloss over the fact
that the protocol design failed to meet legitimate design constraints.

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


More information about the Problem-statement mailing list