John Leslie wrote: > 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... 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@xxxxxxx>