Re: discussion style and respect

[t.p. <[e-mail]>]

----- Original Message -----
From: "John C Klensin" <[e-mail]>
To: "John Leslie" <[e-mail]>; "Tony Hain" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, June 13, 2015 2:19 PM
>
> --On Saturday, June 13, 2015 06:21 -0400 John Leslie
> <[e-mail]> 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
>