----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "John Leslie" <john(_at_)jlc(_dot_)net>; "Tony Hain"
<alh-ietf(_at_)tndh(_dot_)net>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Saturday, June 13, 2015 2:19 PM
--On Saturday, June 13, 2015 06:21 -0400 John Leslie
<john(_at_)jlc(_dot_)net> 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