John Leslie wrote:
Tony Hain <alh-ietf(_at_)tndh(_dot_)net> wrote:
If people disagree about the requirements to start with, it is very
hard to get consensus about any proposed solution.
Let me get back to that...
It becomes a zero-sum when it is a beauty contest or competing
implementation biased "one size fits all" outcome.
Almost inevitably, by the time we have enough folks to form a WG, there
is a potential "solution" nearing completion. In fact, more often than not
we
don't form the WG before it's complete. Many folks say that our
"successful"
WGs are those where the solution exists before we start...
NO! In fact those are the examples of failure of the consensus process.
Ramming an existing solution down the throat of people to get the
rubber-stamp of approval from the IESG is a complete failure.
Remove the "one-size-fits-all", or otherwise constrain the
requirements to a set with consensus (yes that means more requirements
documents), and you reduce the chance of a zero-sum outcome.
Constraining the requirements is likely the secret.
But human nature goes the other way.
Folks with a "solution" honestly believe everything it does belongs in
"requirements". Folks without a solution (yet) propose "wish-list"
requirements. It's _so_ easy to just throw them all into the document.
This mindset is an example of "refusal to listen" to the operational
requirements of others, but it also shows how the "one-size-fits-all"
imposition forces a zero-sum outcome. Many issues are similar enough at
their core that a generalized approach will cover them, while a
highly-tuned-to-a-subset existing "solution" essentially forces out issues
as "wish list" items and declared out of scope. Unfortunately the
one-size-fits-all mindset says that the excluded issues can't get a hearing,
because a solution that is "close enough" exists, unless those with the
issue can prove they are explicitly excluded by the existing spec.
But _this_ is the time when it's easiest to put areas of contention
out-of-
scope.
Splitting the WG is one way to handle the contention, but the one more often
used is "you don't fit in our solution, so get lost". Then people wonder
why the process looks like combat more than cooperation.
So I must disagree with Tony: if people disagree about requirements
early
on, it's the perfect time to work out how to constrain them.
Insist on "one-size-fits-all", or skip the requirements document, and
you almost ensure a zero-sum fight.
There are _many_ cases (in our history) without a requirements
document;
yet we managed quite nicely to constrain the requirements, simply by
agreeing that once we had something "good enough for a start,"
we should publish it and move on.
So I don't worry about "skipping the requirements document" -- I worry
about putting too much in it.
You can certainly put too much into a single set of requirements, but simply
throwing out things that don't fit in the existing solution is the wrong
answer. If the list gets too large, splitting the set and having parallel
specs or even WGs is the appropriate answer. The one-size-fits-all mindset
has to be purged.
Tony
--
John Leslie <john(_at_)jlc(_dot_)net>