--On Saturday, June 13, 2015 06:21 -0400 John Leslie <john@xxxxxxx> wrote: >... >> 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... And that becomes another part of the problem. Historically, the IETF was an engineering organization that [also] produced standards. It is not a coincidence that "standard" or equivalent do not appear in our name. In part because of that history, we used to take the position that WGs were supposed to add value to a spec and that making IETF endorsement (often called "rubber-stampling") of a spec had little value and was mostly to be avoided. For better or worse, and as John Levine points out, things have evolved. Many WGs are formed only when someone (or some group) have a fairly complete solution in mind. The tendency in the last several years to drag out the WG-forming process so that it takes six months to a year or more reinforces that trend toward WGs that start with a solution (I applaud IESG efforts to more more toward a model of starting WGs, evaluating progress, and shutting things down that don't make it, rather than chartering only those that are certain of success). However, if a WG is started with a "solution" and a group of people behind it, there are some bad effects: (i) Attempts to challenge or change that "solution" can easily cause belligerent encounters. From the standpoint of those who created the solution, they have already done the work, reached agreement, and possibly even deployed that solution. Proposed changes (at least ones of any significance) look to them like either unnecessary delays and a waste of time or like attacks. If those proposals come to the WG, those making them are often made to feel uncomfortable enough (or hopeless enough about their efforts) that they go away, resulting in consensus by attrition. If they should up on IETF Last Call, we sometimes end up with unpleasantness on the IETF list, very bad feelings, or both. I agree with Ted that appeals are part of the solution and we don't have nearly enough of them, but, again, too many people see appeals in "we have already got a solution" scenarios as time-wasting attacks rather than a key part of making the consensus process work. (ii) Many other SDOs are mostly in the business of tuning and approving specifications, rather than doing the fundamental development work. When they do development, it is very often about revisions and often suffers from bad cases of second (or third) system effects with the resulting lousy technology. However, their processes are focused on approval mechanisms and making sure that they go correctly. We are not as good at that because our procedures, and much of our self-image, is still based around engineering with standards as a byproduct rather than approval and standardization. The difference creates friction points that may lead to uncomfortable discussion styles. > 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. Yes, but only if there is basic agreement about success criteria. We often invoke statements like "make the Internet work better" but they require a certain level of altruism. As soon as "promote my solution because I'm certain it is correct (or will make me or my organization lots of money)" or similar things become the primary success criteria for more than a very few people, it becomes harder to agree on when one has been successful and we have at least an approximation to Tony's zero-sum game... and, sadly, might benefit from procedures that are better designed to detect and resist narrow goals and success criteria. >... >> 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. I think that works well only when either there is clear intent to treat that "start" as a tentative or experimental document with "moving on" involving a review and revision step that would likely make changes, perhaps incompatible ones, in the light of experience. That is fairly close to how we originally defined Proposed Standard and reflects cultural assumptions that are much more common in engineering organizations than in organizations that are primarily standards bodies. >... best, john