Tony Hain <alh-ietf@xxxxxxxx> 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... > 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. But _this_ is the time when it's easiest to put areas of contention out-of-scope. 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. -- John Leslie <john@xxxxxxx>