----- Original Message ----- From: "John C Klensin" <john-ietf@xxxxxxx> To: "John Leslie" <john@xxxxxxx>; "Tony Hain" <alh-ietf@xxxxxxxx> Cc: <ietf@xxxxxxxx> Sent: Saturday, June 13, 2015 2:19 PM > > --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. I have always seen that slightly differently (although my experience of the IETF only goes back 20 years). I always see the lack of 'Standards' in the name of the organisation as a dig at ISO, which, in the field of IT, produced such magnum opus as OSI while the IETF sneaked out TCP/IP on the QT. When teaching people about the IETF, I point out that the end point of the process is a 'Request For Comments'; this is the best we can do, now can you help us make it better? It is this openness that I think best characterises the IETF (but I still see it as a body that produces standards, along with IEEE and ITU-T). That openness does invite in people whose way of working is different and which can lead to an apparent lack of respect. I think I saw one of the two incidents that kicked off this thread but only think so because the reaction seemed out of proportion - perhaps I would think differently if I had seen both. Tom Petch >. 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 >