Subject: discussion style and respect

From: IETF Chair <[email-masked]>
Date: Fri, 5 Jun 2015 01:14:32 +0300

I have participated in several threads recently where the discussion
has gotten heated, personal, or unnecessarily polarised.

Please remember to take a pause before using unnecessarily polarised
words or emotional content, condescending or combative discussion style,
being dismissive of other people’s points of view, or using ad hominem
arguments. The IETF code of conduct (RFC 7154) says: 

  The IETF strives … to create and maintain an environment in which every 
  person is treated with dignity, decency, and respect. People who participate
  in the IETF are expected to behave in a professional manner as we work
  together to develop interoperable technologies for the Internet.

This applies to all of us. And we all can fail occasionally, but we need to learn
from our mistakes. Maybe all of us can take a moment and review our
recent discussions and see what we could do to improve going forward.

There are many obvious reasons why we need to stay professional and
respectful in our discussions. We are an open organisation that should
be welcoming, open for new ideas and different viewpoints. We have
a lot of respected technologists and as such we need to set an example
not only for our technical excellence but our ability to discuss and
accommodate broad views. We also get many new proposals and
new people. Please keep an open mind in new discussions, and
do not get offended if others have differing needs or views. People
sometimes have different interests.

There is also the matter of efficiency: occasionally we see discussions
that deviate from the core topic, such as discussions that devolve into
a discussion of the discussion itself. This isn’t always helping us get to a
reasonable conclusion. And a good discussion environment attracts
more participants; negative environment pushes them away. Of course,
it is absolutely essential that we all are able to criticise proposals and
express concerns. Neutral tone works usually best: I prefer A over B
because … ” or "I believe there is a concern in C because …”

At any one time there are hundreds of questions in front of the IETF.
When we are polite, respectful, informative, and help each other
understand, we can get to conclusions faster. And more importantly,
to the right conclusions.

Thanks,

Jari Arkko, IETF Chair

---

From: Michael StJohns <[email-masked]>
Date: Thu, 04 Jun 2015 20:15:41 -0400

Jari has done a good job about talking about speaker responsibilities in the IETF.  I don't totally agree with his approach or conclusions, and I do somewhat object to the use of the Chair's bully pulpit to impose a specific approach, but those are quibbles.  But speaker responsibilities are only half of the story.

What I'd like to do is talk about *listener* responsibilities, which I believe to be as important as the speaker responsibilities discussed by Jari.

The general mantra of the IETF is :

"Be conservative in what you send, be liberal in what you accept." 

That applies across all of our protocol design.  But there's a human interaction equivalent:

"Don't annoy anyone unnecessarily, and don't be easily annoyed.".

Jari covered the "Don't annoy anyone unnecessarily"  piece, let me address the other part.

The IETF is a multi-cultural organization and each speaker has at least 20-30 years of acculturation in their own culture driving their manner of speaking and interaction.  It's fine to say "behave in a professional manner" as Jari suggests, but what that is differs from culture to culture.  In a multicultural organization, you need to start out with the assumption that what's being said is not meant to demean or degrade you and even if you believe it was, you need to, as a professional, seek for the technical content and ignore the emotional content.

As a listener in the IETF, my belief is that you need to first assume a lack of malice on any speaker's part and you should listen for the technical content and to mostly ignore the emotional content.  E.g. it really isn't all about you and you should not be taking things as a personal attack, or even an attack upon your culture.  And if you're not sure, feel free to ask questions as to what was meant.

In the IETF, we benefit (and have benefited) from a robust discussion style.  Granted, the IETF has a style that's on the extreme side of robust, but it has served us well over the years in getting to the mostly correct technical solution for any given problem.   

Finally,  - and this is firmly my opinion rather than established fact - the IETF is not a Least Common Denominator sort of organization.  If we restrict our abilities, and our discussions to a style which is acceptable always to everyone, we throw a way a great deal of our strength.  Not everyone one in the world will find the IETF an amenable organization to work within, but that is just the reality of the situation rather than an attempt at exclusion or selection.

The IETF has a unique culture that is a melange of the styles of the participants going back to its founding.  That culture changes as the participation changes, but not quickly and not always smoothly.  Any given participant should not assume that the IETF culture will be accepting of their approach, customs, or discussion style, and should be prepared to adapt themselves to the IETF's culture rather than vice versa and should not be surprised if their views are not always immediately accepted.  Over time, their participation will tend to reform the IETF's culture, but it will not happen quickly and it may not happen in ways they expect.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 10 Jun 2015 16:40:38 -0400

In answering private mail on my posting on this topic, I came up with a half-baked theory that I decided should probably be shared with the list for comment.  The following is a quote from a private response I sent on this topic.

Side comment - my thoughts on behavior.  Almost every other technical standards body in the world has voting at either the individual, organization or country level with respect to whether or not a particular element, thought, scheme or device gets standardized.  We do not.  
Through "consensus", we include things that are strongly presented, vigorously defended, said by people with gravitas applicable to the technology[, technically good], and not shouted down.  It may be that the style of interaction that you're complaining about is more related to the "consensus" process than to any other element.   If may be that if you want to change the confrontational style, you're going to have to change the way things become standards. 
The above is proposed for discussion, not a strongly held belief on my part (as of yet).  But, it may be that "Standardization by combat" is what we're all about and that to change that would require changing the fundamentals for the IETF.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jun 2015 22:25:35 +0100

On 6/10/2015 9:40 PM, Michael StJohns wrote:
> Through "consensus", we include things that are strongly presented,
> vigorously defended, said by people with gravitas applicable to the
> technology[, technically good], and not shouted down.  It may be that
> the style of interaction that you're complaining about is more related
> to the "consensus" process than to any other element.   If may be that
> if you want to change the confrontational style, you're going to have to
> change the way things become standards.

In spite of formal voting, some other standards groups either explicitly
or implicitly use a unanimity (not 'rough) consensus model.  Still, they
do not suffer anything approaching quantity of rude and disrespectful
behavior that we tolerate and, arguably, condone.

Adult, respectful behavior occurs when it is required.  We don't require
it.

Not really.

d/

ps.  Periodic, generic -- albiet heartfelt -- pleas for better behavior
might be necessary, but they have had no effect -- ever -- in almost 30
years.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Jun 2015 17:40:31 -0400

If we have descended to the point that combative behavior is necessary 
in order to advance ideas here, then in my opinion we need to figure out 
a way to change that. Being willing to shout loudly and in other ways be 
rude ought not be a requirement for successfully advancing good ideas.

Yours,
Joel

On 6/10/15 4:40 PM, Michael StJohns wrote:
> In answering private mail on my posting on this topic, I came up with a
> half-baked theory that I decided should probably be shared with the list
> for comment.  The following is a quote from a private response I sent on
> this topic.
>
>     Side comment - my thoughts on behavior.  Almost every other
>     technical standards body in the world has voting at either the
>     individual, organization or country level with respect to whether or
>     not a particular element, thought, scheme or device gets
>     standardized. We do not.
>     technology[, technically good], and not shouted down.  It may be
>     that the style of interaction that you're complaining about is more
>     related to the "consensus" process than to any other element.   If
>     may be that if you want to change the confrontational style, you're
>     going to have to change the way things become standards.
>
> The above is proposed for discussion, not a strongly held belief on my
> part (as of yet).  But, it may be that "Standardization by combat" is
> what we're all about and that to change that would require changing the
> fundamentals for the IETF.
>
>
>
>
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 10 Jun 2015 21:41:56 +0000

The biggest problem with this approach is that it tends to work more for people who 
are good at winning arguments, using whatever tactics they choose, over those who
are right - on those occasions when the two are not the same.

Not all bright people are able to overcome an innate introversion to the extent that
is required to be successful in a shouting match.

And some of the brightest would rather see us flounder as a group while they take
their arguments elsewhere.

Just a thought...
--
Eric

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, June 10, 2015 5:26 PM
To: Michael StJohns; IETF Discussion Mailing List
Subject: Re: discussion style and respect

On 6/10/2015 9:40 PM, Michael StJohns wrote:
> if you want to change the confrontational style, you're going to have 
> to change the way things become standards.

In spite of formal voting, some other standards groups either explicitly or implicitly use a unanimity (not 'rough) consensus model.  Still, they do not suffer anything approaching quantity of rude and disrespectful behavior that we tolerate and, arguably, condone.

Adult, respectful behavior occurs when it is required.  We don't require it.

Not really.

d/

ps.  Periodic, generic -- albiet heartfelt -- pleas for better behavior might be necessary, but they have had no effect -- ever -- in almost 30 years.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 10 Jun 2015 17:58:01 -0400

Let me try this again.

1) Is my description of the IETF process reasonably close to reality?  E.g. does the consensus process contribute to "Standardization by Combat"?

2) If my description is not exactly correct (or always correct), how does reality differ from this description?

3) If my description is correct, can the process be changed without changing the fundamental nature of the IETF?

A few comments in line.

>are right - on those occasions when the two are not the same.

So is this a characteristic of the IETF or not?  Never, Sometimes, Always?  

In any event, it's not about who's right, its about what's useful to solve the problem.  Which causes problems when there are many ways to solve the problem, each reasonable, and each supported by its own choir.

>is required to be successful in a shouting match.

Counter point:  Not all bright people are able to understand that they are not always the fount of all wisdom and that shouting out their brilliance will not necessarily accomplish what they want to accomplish.  However, the current model does deal with this set of behavior reasonably well.

>their arguments elsewhere.

This sounds suspiciously like "they'll take their toys and go play somewhere else"?  Which isn't really good behavior for adults IMHO.

Mike

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Jun 2015 14:45:57 -0800

On 6/10/15 1:58 PM, Michael StJohns wrote:
> Let me try this again.
> 
> 1) Is my description of the IETF process reasonably close to reality?
> E.g. does the consensus process contribute to "Standardization by
> Combat"?

In theory it should not - consensus processes, done well,
are highly collaborative.  There's not really room for
one side winning and all other sides losing.  That said,
we typically do consensus very poorly.  It probably is the
case that we often do standardization by combat, but that's
because of who we are and how we manage our processes even
though it's basically antithetical to consensus decision-making.

I think it comes down to a few things: 1) bad chairing, 2)
we do a bad job socializing new participants, and 3) a
lot of our participants aren't willing to concede any
points.  The third issue is, I think, a combination of
our poor work socialization new participants and a lot
of newer participants having employment incentives around
"winning" at standards work.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Jun 2015 18:48:25 -0400

> E.g. does the consensus process contribute to "Standardization by

Sometimes.  Not Always.

>
> 2) If my description is not exactly correct (or always correct), how
> does reality differ from this description?

 From where I sit, the difference lies in how the chairs manage the 
process when things get rough.

>
> 3) If my description is correct, can the process be changed without
> changing the fundamental nature of the IETF?

There may well be ways to improve the process.  Pete Resnick's efforts 
to clarify what we mean by rough consensus are probably an 
(unfortunately necessary) step towards such improvements.

Yours,
Joel

>> The biggest problem with this approach is that it tends to work
>> more for people who are good at winning arguments, using whatever
>> tactics they choose, over those who are right - on those occasions
>> when the two are not the same.
>
>
> In any event, it's not about who's right, its about what's useful to
> solve the problem.  Which causes problems when there are many ways to
> solve the problem, each reasonable, and each supported by its own
> choir.
>
>
>> Not all bright people are able to overcome an innate introversion
>> to the extent that is required to be successful in a shouting
>> match.
>
>
> Counter point:  Not all bright people are able to understand that
> they are not always the fount of all wisdom and that shouting out
> their brilliance will not necessarily accomplish what they want to
> accomplish.  However, the current model does deal with this set of
> behavior reasonably well.
>
>
>
>> And some of the brightest would rather see us flounder as a group
>> while they take their arguments elsewhere.
>
> This sounds suspiciously like "they'll take their toys and go play
> somewhere else"?  Which isn't really good behavior for adults IMHO.
>
> Mike
>
>
>
>> Just a thought... -- Eric
>>
>> -----Original Message----- From: ietf
>> [mailto:[email-masked]] On Behalf Of Dave Crocker Sent:
>> Wednesday, June 10, 2015 5:26 PM To: Michael StJohns; IETF
>> Discussion Mailing List Subject: Re: discussion style and respect
>>
>>> Through "consensus", we include things that are strongly
>>> presented, vigorously defended, said by people with gravitas
>>> applicable to the technology[, technically good], and not shouted
>>> down.  It may be that the style of interaction that you're
>>> complaining about is more related to the "consensus" process than
>>> to any other element.   If may be that if you want to change the
>>> confrontational style, you're going to have to change the way
>>> things become standards.
>>
>>
>> In spite of formal voting, some other standards groups either
>> explicitly or implicitly use a unanimity (not 'rough) consensus
>> model.  Still, they do not suffer anything approaching quantity of
>> rude and disrespectful behavior that we tolerate and, arguably,
>> condone.
>>
>> ps.  Periodic, generic -- albiet heartfelt -- pleas for better
>> behavior might be necessary, but they have had no effect -- ever --
>> in almost 30 years.
>>
>> -- Dave Crocker Brandenburg InternetWorking bbiw.net
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Jun 2015 19:04:49 -0400

--On Wednesday, June 10, 2015 16:40 -0400 Michael StJohns
<[email-masked]> wrote:

>...
> individual, organization or country level with respect to
> whether or not a particular element, thought, scheme or device
> gets standardized.  We do not.   Through "consensus", we
> include things that are strongly presented, vigorously
> defended, said by people with gravitas applicable to the
> technology[, technically good], and not shouted down.  It may
> be that the style of interaction that you're complaining 
>...

Mike,

An observation that is a little bit orthogonal to your remarks
but that may also contribute enough to the behavior patterns
people are noticing to be worth recording....

Almost every other technical standards body in the world also
has an admissions and/or application procedure of some sort,
usually including organizational or governmental endorsement of
the applications and sign-off on the associated conditions.
Those procedures are expected to guarantee a certain level of
ability to simulate adult behavior as well as at least some
minimal level of expertise in the subject matter.  They also
establish some level of accountability: if someone misbehaves,
they can be kicked out (not merely, e.g., prevented from posting
to a mailing list or three for a while) and, whether explicitly
or merely by reputation, the sponsoring organizing can be
negatively impacted.

For better or worse, the IETF has no equivalent form of
accountability, or mechanism (effective or not) for filtering to
distinguish between people with knowledge and experience in a
particular area and those who merely have strong opinions.  In
other bodies, the filtering arrangements tend to favor a certain
level of orthodoxy in proposals and standards relative to
introduction of new ideas.  

The IETF model of insisting that anyone can participate and that
everyone who does participate does so strictly as an individual
tends to avoid that orthodoxy and associated constraints but
also avoids the advantages of enforceable rules, e.g., that one
either behaves like an adult professional or gets out (or
doesn't get in).  

I'm not persuaded that our model of reaching consensus is
necessary to being open to innovative ideas, but there is almost
certainly some interaction.  At the same time, if we develop our
own forms of orthodoxy (as we often seem to be doing of late)
and enforce them through out decision-making processes, we end
up with one of the major liabilities of most of those other
standards bodies without the obvious advantages.

best,
      john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jun 2015 14:22:59 +1200

>> E.g. does the consensus process contribute to "Standardization by

I think, specifically, that our rough consensus process is not conducive
to compromise between alternatives, whereas "voting (consensus preferred)"
does tend to lead to compromises. By "compromises" I mean things like
the ATM cell's payload size being the arithmetic mean of 32 and 64,
or the OSI Network Layer having two incompatible protocols. So it may
be a feature, not a bug, that our process discourages compromise.

When we have to choose between distinct alternatives, the next point
applies:

> From where I sit, the difference lies in how the chairs manage the process when things get rough.

Exactly. And things can get rough quickly and unexpectedly.

> There may well be ways to improve the process.  Pete Resnick's efforts to clarify what we mean by rough consensus are probably
> an (unfortunately necessary) step towards such improvements.

True, but things can get very heated way before there is any real
question of a consensus call. This isn't at all easy for WG Chairs
to control, especially between meetings.

    Brian

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jun 2015 21:52:48 -0500

On Wed, Jun 10, 2015 at 04:40:38PM -0400, Michael StJohns wrote:
>                                                [...].   If may be that
> to change the way things become standards.  [...]

Adversarial good, confrontational bad.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 10 Jun 2015 20:29:25 -0700

> 1) Is my description of the IETF process reasonably close to reality?
E.g. does
> the consensus process contribute to "Standardization by Combat"?

In the sense that people often believe there can be only one "winner", then
the process is inherently combative. The wars between OSPF & ISIS are a good
example of the combative nature, as well as the wrong-headed thought that
there is only one possible "winner". 

> 
> 2) If my description is not exactly correct (or always correct), how does
reality
> differ from this description?

>From what remains of fading memories, this is a periodic problem primarily
focused around personalities that don't play well with others in the
sandbox. Jim Bound in fatigues in Danvers keeps coming to mind here, but
SNMP was not a quiet timeframe either. 

> 3) If my description is correct, can the process be changed without
changing the
> fundamental nature of the IETF?

To the degree that the IESG tries to drive the mantra "only one approach",
you either have combat over differing ideas or you consider changing the
process to be vote based. When the IESG gets out of the way and allows the
market to decide by publishing all substantive approaches, you can end the
combat fairly quickly (OSPF/ISIS). 

> >The biggest problem with this approach is that it tends to work more
> >for people who are good at winning arguments, using whatever tactics
> >they choose, over those who are right - on those occasions when the two
are
> not the same.

Periodically 

> 
> In any event, it's not about who's right, its about what's useful to solve
the
> problem.  Which causes problems when there are many ways to solve the
> problem, each reasonable, and each supported by its own choir.

Most of the time there is a fundamental agreement about what the problem is,
and this is compounded by a disconnect from the operations community. When
JoMan split off and operators started sending vendors to solve their
problems, the actual problem got lost along the way, and the result was a
bias toward what would work best for that vendor's product lines. The IETF
worked best when the operators, researchers, and developers all sat around
the same table and talked about what was needed, possible, and implementable
in a given timeframe. It doesn't work as well without one component of that
set. The "doesn't work as well" aspect gets amplified whenever there is a
winner-takes-all situation, yet none of the proposed solutions solve all
possible problems.

> 
> 
> >Not all bright people are able to overcome an innate introversion to
> >the extent that is required to be successful in a shouting match.
> 
> 
> Counter point:  Not all bright people are able to understand that they are
not
> always the fount of all wisdom and that shouting out their brilliance will
not
> necessarily accomplish what they want to accomplish.  However, the current
> model does deal with this set of behavior reasonably well.

Third point: not all highly opinionated people are as bright as they think
they are (but maybe that is a subset of your point ... ;)

> 
> 
> 
> >And some of the brightest would rather see us flounder as a group while
> >they take their arguments elsewhere.
> 
somewhere
> else"?  Which isn't really good behavior for adults IMHO.

Well, some would argue that people who are unwilling to listen to others are
not behaving like adults either. There is plenty of less-than-adult behavior
to point at over time. 

Maybe the Note Well should be updated to have a paragraph about Respect, not
assuming that the other person is attacking you just because they disagree,
... etc. It would at least be a placeholder for a WG chair to point if
behavior starts getting out of hand. As an adjunct, maybe an informational
RFC to the IESG would be helpful. Recognizing that while consensus on the
minimum is a goal, reminding them that "one size does not fit all" seems to
periodically be necessary (https everywhere).

Tony

> >Just a thought...
or
> implicitly use a unanimity (not 'rough) consensus model.  Still, they do
not
> suffer anything approaching quantity of rude and disrespectful behavior
that we
> tolerate and, arguably, condone.
> >
it.
> >ps.  Periodic, generic -- albiet heartfelt -- pleas for better behavior
might be
> necessary, but they have had no effect -- ever -- in almost 30 years.
> >
> >--
> >Dave Crocker

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Jun 2015 23:49:40 -0400

On Jun 10, 2015, at 5:40 PM, Joel M. Halpern <[email-masked]> wrote:
> If we have descended to the point that combative behavior is necessary in order to advance ideas here, then in my opinion we need to figure out a way to change that. Being willing to shout loudly and in other ways be rude ought not be a requirement for successfully advancing good ideas.

Indeed, to the extent that people think shouting is the way to get things done here, that is an indication of brokenness, not of best practice. What we want is for shouting to be useless, and reason to be the only effective method of getting what you want. Of course, that lets out any means of getting what you want if it is unreasonable, which may be part of the problem... :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Jun 2015 23:54:44 -0400

> 1) Is my description of the IETF process reasonably close to reality?  E.g. does the consensus process contribute to "Standardization by Combat"?

No.   It makes it difficult for people to get what they want without winning on the merits, at least in principle, and the desire to get what we want without winning on the merits is what leads to this combativeness you are referring to. 

> 3) If my description is correct, can the process be changed without changing the fundamental nature of the IETF?

I would argue that the current move in the direction of less combative discourse is a fundamental change to how the IETF works, and it is a good change.  The fact that combative discourse ever produces an outcome that rewards those who engage in it is a very serious process failure.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Jun 2015 23:56:58 -0400

> "winning" at standards work.

Yup.  And being a good chair is hard, and not particularly pleasant unless you get off on fostering consensus. Of course, that is rather rewarding,,,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Jun 2015 06:56:41 +0200 (CEST)

> E.g. does the consensus process contribute to "Standardization by 

I don't know how much it contributes, but there is also widely differing 
ways of "doing business" in the IETF depending on what WG we're talking 
about, and what people populate it.

There are working groups where the mailing lists are basically silent 
apart from draft announcement postings and administrativa, everything else 
is done behind the scenes in private. Then there are groups where a lot of 
the discussions are done in public and basically "brainstorming" is done 
on the mailing list.

So it all depends on what your personal style is, if either of these fits 
you or not. I know people who refuse to participate in "let's brainstorm 
in front of the whiteboard" style of working, and prefer to go home and 
sit for a day and write document/presentation, to present their views.

We're always going to see friction between different personalities, 
cultures etc, and how they prefer to work and express themselves. We need 
to cater to all, so we need to find ways of working that doesn't exclude 
anyone. I tend to think that we do this, but we're never going to avoid 
having friction when all these people are interacting and have differing 
views, ways to express these views, and who often believe strongly in 
these views.

So I tend to think of the IETF consensus process the same way as 
democracy, it's bad, but all the other alternatives are worse, so let's 
try to work with what we've got and try to make the most of it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jun 2015 07:03:03 +0200

On 6/11/15 5:49 AM, Ted Lemon wrote:
> Indeed, to the extent that people think shouting is the way to get
> things done here, that is an indication of brokenness, not of best
> practice.
It's not just shouting.  It's gaming and in some cases filibustering.  
Last year I was witness to one of the most shameful displays of
leadership I have ever seen involving both.  Chairs need to pick up on
that and act quickly to stop it.  In the case I witnessed it was
actually WORSE because the chairs interpreted the filibustering as a
change of consensus.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jun 2015 01:21:14 -0400

On Jun 11, 2015, at 1:03 AM, Eliot Lear <[email-masked]> wrote:
> In the case I witnessed it was

Did someone submit an appeal?  That too is an important part of the consensus process, when it goes wrong.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jun 2015 07:30:13 +0200

No.  He just walked away from the process.  He wasn't even in the room
at the time when it happened, because not everyone can go flying to far
away places to participate.  It was not one of our finest moments.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Jun 2015 08:46:34 +0300

> On Jun 11, 2015, at 12:58 AM, Michael StJohns <[email-masked]> wrote:
> 
> Let me try this again.
> 
> 1) Is my description of the IETF process reasonably close to reality?  E.g. does the consensus process contribute to "Standardization by Combat”?

Perhaps. But the best tactic for winning this kind of combat in the IETF is not to shout louder than others. The best tactic is to get a small group around you (preferably not all from the same company), insist on your position and refuse to budge. Then wait it out until your opponents grow tired and walk away.

It is up to chairs to prevent this kind of outcome. I mean, we think of tenacity as a good quality but it shouldn’t override all others. One way is to encourage reaching consensus quickly. Long discussions tend to favor the tenacious.

Yoav

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Jun 2015 09:31:36 +0200

When our process goes bad in the ways we're currently discussing, it's
"consensus by last man standing" - the process of driving away all the
others may involve insults, tenaciousness or just a huge amount of
patience (and funding).

The result is a specification that some people ignore because it's a
stupid spec, and some people ignore because it's a result of a process
they walked away from. This may be harmful to adoption.

When our process works well, the results are adopted in the Real World -
that's our *real* definition of success.

-- 
Surveillance is pervasive. Go Dark.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jun 2015 09:50:19 +0200

Hi Yoav,

> Perhaps. But the best tactic for winning this kind of combat in the IETF is not to shout louder than others. The best tactic is to get a small group around you (preferably not all from the same com…

That's exactly what I witnessed.  I am ashamed to say that I did not
myself say something more at the time (although I was in a very awkward
position to do so).

> It is up to chairs to prevent this kind of outcome. I mean, we think of tenacity as a good quality but it shouldn’t override all others. One way is to encourage reaching consensus quickly. Long dis…

It's also up to us as individuals to call out bad behavior, and for all
of us to recognize that just because something is said more than once
doesn't make it any more true (or false).  And so, my challenge to the
leadership: how shall we address this problem?  I'd like to at least
know that the problem is recognized.

Eliot

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Jun 2015 11:09:24 +0100

> On 11 Jun 2015, at 06:46, Yoav Nir <[email-masked]> wrote:
> 

Perhaps we need more coin tosses.

Tim

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Jun 2015 13:19:02 +0300

> On Jun 11, 2015, at 1:09 PM, Tim Chown <[email-masked]> wrote:
> 

Or basketball tournaments. These have the advantage of disqualifying anyone who can’t get 4 other people to support their idea.

Yoav

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jun 2015 09:40:53 -0400

> Perhaps we need more coin tosses.

I don't think we do.   I was not impressed by the outcome of the last coin toss I witnessed.   If you get to the point where a coin toss is the best way out of the situation, there's probably already a failure to foster consensus on the part of the chairs somewhere in the rear-view mirror, and of course a failure to be willing to participate in it on the part of the participants in the process.

---

From: Hector Santos <[email-masked]>
Date: Thu, 11 Jun 2015 15:42:20 -0400

I've called it Rough Consensus (RC) by Osmosis.  By filtering out 
contention, RC can be achieved  and the IETF has been 
pushing/highlighting current/new procedures to control contention. 
There is definitely a new higher level of intimidation and moderation 
going on.

IMO, RC was really great at a time and in areas where there was 
unknowns in the world.  Today, nearly after hundreds of thousands of 
30+ IETF-MAN-YEARS for technology development and well established, 
solid engineering understanding of operations and technical market 
places,  a RC decision can be harmful and/or just a bad wasteful idea 
for any particular group of people.

In my view, we have:

o Too many projects done by the same few people, lost of synergism.
o Too much fast tracking,
o Too much informational or experimental status docs pushed as standards,
o Too much lower quality of products,
o Too much "big vs small" battles.

The appeal potentials are higher because of the above and even that is 
being dealt with by doing more filtering. Many times apathy develops 
and so, you just "walk away."

I do believe you need to be able to move forward at times and such 
decision processes and tools are necessary. So I say, we have "too 
much" of it going on.  A balance is needed and that is where "fair" 
leaders can help.

--
HLS

-- 
HLS

---

From: Alia Atlas <[email-masked]>
Date: Thu, 11 Jun 2015 15:44:00 -0400

Hi Eliot,

On Thu, Jun 11, 2015 at 3:50 AM, Eliot Lear <[email-masked]> wrote:

> E.g. does the consensus process contribute to "Standardization by Combat”?
> > Perhaps. But the best tactic for winning this kind of combat in the IETF
> is not to shout louder than others. The best tactic is to get a small group
> around you (preferably not all from the same company), insist on your
> position and refuse to budge. Then wait it out until your opponents grow
> tired and walk away.
>
> > It is up to chairs to prevent this kind of outcome. I mean, we think of
> tenacity as a good quality but it shouldn’t override all others. One way is
> to encourage reaching consensus quickly. Long discussions tend to favor the
> tenacious.
>

One aspect is to work on improving and discussing how to handle consensus
issues for the WG Chairs.
Anyone who hasn't read through RFC 7282 really should.  In the Routing
area, we've been having
periodic Working Group chair training sessions.  You can see the
presentation and recording for the one
we did "On Consensus" at:
http://wiki.tools.ietf.org/area/rtg/trac/wiki/WGChairTraining .
We recently did one about "Civility in the Working Group" also to address
how to handle bad behavior.

It helps to have thought through scenarios before hand and have some plans
on how to handle it.
It can also be useful to discuss issues with those who are not involved.
In Routing, we try to have a
safe place for WG Chairs to do so with periodic WG Chair chats.

Those of us who participate in the IETF consider some values core to the
culture which enables successful
and relevant work.  Currently, those values are partially articulated in
the Tao, but we do not stand up and
applaud those who are doing good work or illustrating those values.   For
instance, on the consensus concerns,
in today's telechat was a webrtc draft that had a very contentious and
extended effort to pick a mandatory-to-implement
codec.  As described in the write-up, Adam Roach came up with a compromise
position (http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html)
that was able to resolve the conflict.

At the heart of the IETF, we do open, consensus-based engineering
standards.  To me, that means that we
have to be effective listeners willing to hear ideas from all
participants.  To me that means we need to consider
concerns based upon their technical and operational merit - not on how many
times or how emphatically they
are stated.   To me, that means that we develop standards that can be
usefully deployed and are aware of the
operational considerations and technical considerations that drive a
solution.

I would like to see the IETF continue to improve in being a supportive
community where there are ties of friendship and trust to help bridge
differences in technical opinion and perspective.

Regards,
Alia

---

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Jun 2015 12:17:52 -0800

On 6/11/15 11:44 AM, Alia Atlas wrote:
> One aspect is to work on improving and discussing how to handle 
> consensus issues for the WG Chairs. Anyone who hasn't read through
> RFC 7282 really should.  In the Routing area, we've been having 
> presentation and recording for the one we did "On Consensus" at: 

These are really nice - might be useful as a basis for a
working group chairs training track.  Right now there really
isn't such thing - the working group chairs training sessions
are useful and I think need to continue as is, but some sort
of training for new chairs seems valuable and might help us
avoid some of what's under discussion at the moment.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jun 2015 22:28:24 +0200

Alia,

That's a lot of good stuff, and I really appreciate your thoughtful
answer, and especially your rolling up your sleaves and addressing these
sorts of problems.  As I wrote, we all have a responsibility to call out
bad behavior.  Senior members of the community, ADs, IAB members and WG
chairs certainly should set an example in assisting chairs when things
get out of control.  That is- we can't place all the weight on WG chairs.

Eliot

On 6/11/15 9:44 PM, Alia Atlas wrote:
> Hi Eliot,
>
> On Thu, Jun 11, 2015 at 3:50 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Yoav,
>
>     >> On Jun 11, 2015, at 12:58 AM, Michael StJohns
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Let me try this again.
>     >>
>     >> 1) Is my description of the IETF process reasonably close to
>     reality?  E.g. does the consensus process contribute to
>     "Standardization by Combat”?
>     > Perhaps. But the best tactic for winning this kind of combat in
>     the IETF is not to shout louder than others. The best tactic is to
>     get a small group around you (preferably not all from the same
>     company), insist on your position and refuse to budge. Then wait
>     it out until your opponents grow tired and walk away.
>
>     > It is up to chairs to prevent this kind of outcome. I mean, we
>     think of tenacity as a good quality but it shouldn’t override all
>     others. One way is to encourage reaching consensus quickly. Long
>     discussions tend to favor the tenacious.
>
> consensus issues for the WG Chairs.
> We recently did one about "Civility in the Working Group" also to
> address how to handle bad behavior.
>
> It helps to have thought through scenarios before hand and have some
> plans on how to handle it.
> It can also be useful to discuss issues with those who are not
> involved.  In Routing, we try to have a
> Those of us who participate in the IETF consider some values core to
> the culture which enables successful
> and relevant work.  Currently, those values are partially articulated
> in the Tao, but we do not stand up and
> applaud those who are doing good work or illustrating those values.  
> For instance, on the consensus concerns,
> codec.  As described in the write-up, Adam Roach came up with a
> compromise position
> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html)
> concerns based upon their technical and operational merit - not on how
> many times or how emphatically they

---

From: Alia Atlas <[email-masked]>
Date: Thu, 11 Jun 2015 16:28:31 -0400

Melnda,

> avoid some of what's under discussion at the moment.

Thanks!  It's something that I feel is important to work on.  I think that
the IETF
tends to have people learn to be WG chairs by what I call the
"apprenticeship"
method.  New WG chairs are paired with an experienced one and picks up what
to do
and how things are done based on what they've seen while participating in
the
IETF.  On top of that, at least in Routing, we have a number of WG groups
and
their chairs that have been WG Chairs for a long time.  It can be useful to
discuss what's taken for granted - particularly as process changes or new
ideas
need to be emphasized.

It may not be apparent from the recordings, but we also have unrecorded time
to allow for frank conversation and that is sometimes quite useful for
discussing
specific examples.

I would be quite happy for these to get more and wider viewing and to be
useful
beyond the initial presentation.  That said, I do feel like part of the
benefit of these
is to enable conversations and strengthen relationships between the WG
Chairs
so that they can get support and advice from more people.

I'm intending to come to the EDUNEXT BoF at IETF 93 and am happy to talk
more about ideas.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 11 Jun 2015 16:32:55 -0400

Eliot,

On Thu, Jun 11, 2015 at 4:28 PM, Eliot Lear <[email-masked]> wrote:

> chairs certainly should set an example in assisting chairs when things get
> out of control.  That is- we can't place all the weight on WG chairs.
>

Thanks & I absolutely agree.  It's our community and organization and we
need to do the work to both call out bad behavior AND to call out and
praise good behavior as being praiseworthy.  I'm sure that we've all dealt
with culture issues in organizations - and if we want the IETF to have a
good culture that reflects values that help make it a productive and
enjoyable place to get work done, then it's up to us to encourage and
reinforce that.

Regards,
Alia

>> > Perhaps. But the best tactic for winning this kind of combat in the
>> IETF is not to shout louder than others. The best tactic is to get a small
>> group around you (preferably not all from the same company), insist on your
> position (
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html) that
> was able to resolve the conflict.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jun 2015 08:41:56 +1200

> avoid some of what's under discussion at the moment.

There has been a "WG Leadership"  tutorial from time to time in
the past; in fact it ran at IETF92 (for the first time since IETF86):
http://www.ietf.org/edu/process-oriented-tutorials.html#wgleadership

One of the things we need to discuss at the EDUNEXT BOF is whether
the traditional format of 90 minute tutorials on Sunday afternoon
is still useful, and whether it should be supplemented or replaced
by a suite of shorter videos and longer webinars that could be
available any time, any place.

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jun 2015 16:49:51 -0400

On Wed, Jun 10, 2015 at 5:58 PM, Michael StJohns <[email-masked]>
wrote:

> the problem.  Which causes problems when there are many ways to solve the

There is winning the argument and there is winning the outcome. And those
are certainly not always the same in IETF.

What worries me rather more is when the tactics that win an argument inside
IETF are completely different to those necessary for success outside.

The success of the Web was only partly due to technical differences. URLs,
404 not found were both important. But a much more important factor was
that the source code was put in the public domain without strings and
instead of trying to discourage commercial activity, we spent time and
effort trying to get them on board.

Now I see all sorts of proposals to do great things for privacy which begin
'first get rid of Google, Microsoft and Apple' as if this is a strategy for
success.

> somewhere else"?  Which isn't really good behavior for adults IMHO.

This is a volunteer organization. If people think they are being treated
unfairly, most will leave. IETF isn't this only game in town nor should it
try to be.

I am not aware of anyone who says they want the IETF to flounder but I know
quite a few folk who have packed up and left for venues where they feel
they get a fair hearing.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jun 2015 17:10:56 -0400

> o Too much "big vs small" battles.

I think we have far too little thought given to the big picture. The WGs
that have got the green light of late all represent incremental improvement
on existing protocols with the WGs chartered to do as little original work
as possible.

That is OK if you think the Internet is basically OK and just needs the
most minor tweaks here and there. Which might be true in the lower levels
but it certainly isn't the case in security or applications.

Right now we are in something of a transition point between XML based web
services and JSON. It would be a really good thing if IETF could come up
with a single house style for JSON based Web services so that there was
some sort of consistency in approach like there is with SMTP/NNTP/HTTP.
Instead it looks like we will just muddle through.

I am also rather skeptical of this idea that IETF is well adapted to cross
WG and cross area collaboration. Right now I am trying to persuade people
that OpenPGP fingerprints are a good idea. In fact they are a good idea as
a basic security primitive that we apply in DNSSEC, S/MIME, SSH and pretty
much anywhere we might want to describe a root of trust in a compact
machine and human readable form.

To date, nobody has told me this is a bad idea or that it isn't worth
considering or harmful. Instead the pushback is 'convince me that this is
necessary'.

How are we going to get convergence between work in different groups if
that is the attitude?

---

From: Larry Masinter <[email-masked]>
Date: Thu, 11 Jun 2015 23:57:11 +0000

1. Consider the possibility that some of the cases are deliberate trolling
http://en.wikipedia.org/wiki/Internet_troll#Corporate.2C_political_and_special_interest_sponsored_trolls

as an attack on the IETF and the Internet.
2. http://dilbert.com/strip/2015-06-07 is an anti-pattern:
(“misinterpret every comment you make as an absurd absolute and then attack it …”)

3. terse can be dismissive, dismissive can be rude
   but not always, and it’s better to encourage terse.

Larry

---

From: Doug Royer <[email-masked]>
Date: Thu, 11 Jun 2015 18:17:02 -0600

> http://en.wikipedia.org/wiki/Internet_troll#Corporate.2C_political_and_special_interest_sponsored_trolls

I have thought over the years, that the WG chairs need to be a bit more
aggressive when this or when aggressive posts continue.

Personal attacks should be responded to by the WG chair with a private
warning, then if they continue, banning them from the WG or all IETF lists.

The banning step should be a public WG notice so that those directly
effected and the observers that are often effected, know that it is
being stopped and not tolerated.

I have had another misrepresent my posts by non-clever editing (and flat
out fiction) and drag out a WG for months. Its why I no longer post
drafts. I almost had to file legal action to stop him. Fortunately his
employer wanted no part of it and they stopped him. It was almost
5-years later when an AG told me they wished they had stopped him.

Why not stop them when it happens? Is it a legal issue?

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Doug Royer <[email-masked]>
Date: Thu, 11 Jun 2015 18:28:53 -0600

On 06/11/2015 02:49 PM, Phillip Hallam-Baker wrote:

> I am not aware of anyone who says they want the IETF to flounder but I
> know quite a few folk who have packed up and left for venues where they
> feel they get a fair hearing. 

I have seen a company do this to a specific proposal when they did not
want competition to their overwhelming market share in the commercial
world. They gave tons of misinformation and convinced many they were the
experts. Surprise, their implementation works.

--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jun 2015 11:49:52 +0100

...
> either behaves like an adult professional or gets out (or

This is objectively wrong.

We have rules.  We have been known to enforce them.  The consequences
can (and have) include banishment.

That we do not have entrance qualifiers does not in any way relate to
whether we have suspension or termination rules, nevermind whether we
enforce them.

The core issues are that we do not adequately define unacceptable
behavior and we do essentially no enforcement, except in the most
extreme cases and for the most marginalized participant.

This effectively constitutes encouragement of recidivists.

d/

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Jun 2015 14:10:17 +0300

Let me just say that ‘standards by combat’ has not been my experience :-)
nor should it be our mode of operation.

Mike is completely right about 'strongly presented, vigorously defended,
by people with gravitas applicable to the technology’. And about our
consensus mode of operation. These are how we should be.

But it does not follow that aggressive argumentation or a war of ideas
is what we should be doing. Granted, there are always some people in any
organisation who want that sort of thing… egos… techies… need to
show superiority… cases of busy or poor management… social skills…
online discussion forums… people who thrive on creating controversy.

I started this thread because I saw two incidents, and I didn’t like them.
My overall experience is that those are still exceptions. My typical
experience in working on some topic is that the successes or my
personal gratification does not come through winning the other guy.
The most wonderful experience is when you find others with the
same issues and ideas, and you together build something that is
better than what you could have done alone. And that through several
people wanting the same thing, you have something that the market
wants, and it actually takes off. I see so many cases of that...

So I would like to agree with Melinda and others on the consensus
process being best as highly collaborative. The suggestion to re-read
Pete’s rough consensus document RFC 7282 from Alia is a really
good one.  +1 also on real world being our criteria of success (Harald).
And +1 to what Eliot said WG chairs and senior members of the
community leading the way.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jun 2015 09:18:20 -0400

> extreme cases and for the most marginalized participant.

This is definitely /a/ core issue. However, the anti-reason tactics that people have talked about previously are also an important and separate problem, which can only be addressed by working group chairs who do a good job of calling consensus. I mentioned appeals because we hardly ever get appeals that address failures of this sort. Appeals of this sort are not a bad thing, and we need more of them.  It should be embarrassing for us at the plenary if the IESG reports that they got no appeals, rather then embarrassing for them if they have to report that they got none, assuming there was something worth appealing that trimester.

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Jun 2015 11:37:55 -0400

--On Friday, June 12, 2015 11:49 +0100 Dave Crocker
<[email-masked]> wrote:

>> The IETF model of insisting that anyone can participate and
>> that everyone who does participate does so strictly as an
>> individual
> ...
>> also avoids the advantages of enforceable rules, e.g., that
>> one either behaves like an adult professional or gets out (or
>> doesn't get in).  

>...
> We have rules.  We have been known to enforce them.  The
> consequences can (and have) include banishment.

You may disagree but, when I describe the situation
"objectively" but from my perspective, I would restate the above
as:  We have rules.  They are mostly vague and subjective, but
probably that is inevitable.   We almost never try to enforce
them when they appear to be violated, at least beyond private or
low-key requests/ advice that someone shape up.   If someone
does not, the maximum penalty/ consequence/ community mechanisms
we have are denying someone posting rights to mailing lists and
requesting that they leave or not attend particular WG meetings.
Neither really constitutes banishment.   We also have a recall
mechanism for removing people from leadership position who have
gotten out of hand, a mechanism that has never been used to the
point of actually removing someone from office.  If used, that
mechanism would remove someone from a position, also well short
of banishment.

The use of PR bans under RFC 3683 could be objectively measured
with a bit of effort, but I'd guess those bans have been applied
to fewer than a handful of individuals.  The use of recalls to
the point of petitions being handed to the ISOC President and at
least a Recall Committee Chair being appointed could also be
counted, but I'm fairly sure that the number would be even
smaller.

It seems to me that those objective measures can be interpreted
in two ways.  One is that the rules (and potential for
enforcement to the extent it is needed at all) are working
really well, i.e., community and its participants are so well
behaved that nothing else is needed.  One needs to wonder why,
if that were the case, Jari's note was needed and we need to be
spending so many cycles on this discussion thread.  I think that
discussions on the IETF list that are about problems that don't
need solving are very expensive, but YMMD.

The other is that, in practice rather than theory, we don't have
effective rules and/or are either unwilling or unable to enforce
them (which was the point of that part of my note).  In that
regard, I observe that at least one individual, and I think two,
who have had posting rights revoked routinely show up with
postings on various IETF lists, more or less replicating the
behavior for which those rights were revoked.  If that is
"banishment", it is obviously not very effective.

> That we do not have entrance qualifiers does not in any way
> relate to whether we have suspension or termination rules,
> nevermind whether we enforce them.

No, it does not relate to whether we have such rules.  I didn't
intend to say that it did.   It does relate to how easily,
effectively, and conclusively those rules can be enforced, an
issue that has been discussed multiple times by others, most
notably Counsel during IPR applicability and enforcement
discussions.  I usually still think the tradeoff in favor of a
more open and accessible process is worthwhile, but I don't
think it is useful to pretend that it doesn't have costs, both
along the dimensions discussed on this list and those that are
obvious to anyone who has had to listen to some long rant by
someone who has no knowledge or understanding about what the
rant is about.

> The core issues are that we do not adequately define
> unacceptable behavior and we do essentially no enforcement,
> except in the most extreme cases and for the most marginalized
> participant.

I agree with that, noting Ted's comment about it being _a_ core
issue.  TO me, it is almost indistinguishable from what I said
in the note to which you objected.

FWIW, I also believe that we are far more often victim to
consensus by attrition than to direct interference with the
system or overt bad behavior.   I am perhaps just getting more
sensitive with age, but I believe that pattern is on the rise.
Consequently that risk and the behavior patters that tend to
induce it appear to me to be core issues too.

      john

---

From: Michael StJohns <[email-masked]>
Date: Fri, 12 Jun 2015 12:52:59 -0400

>nor should it be our mode of operation.

Hi Jari - 

I'm violating my own "no bumper stickers" rule I'm afraid with the "standards by combat" tag.  :-) Look for  T-Shirts soon!

 But in any number of groups over time I've seen exactly this behavior.  Still seeing this.  And it doesn't have to be shouting, or loud arguments in front of the mike, sometimes it's as simple as having a clique that wants one thing and presenting good technical arguments against fall in the face of the crowd of supporters for that one thing.  An overwhelming numerical advantage and "standards by combat" suggests that your opponent will cede the field.  Of course, there are our Don Quixote's and they will continue to tilt at windmills even when common sense would suggest they won't win.

>online discussion forums… people who thrive on creating controversy.

Blaming on the people is one approach - but ....

There's an old children's instructional tale about cutting a cake in a manner to prevent argument:

One child cuts the cake, the other selects the piece.

This is an example of a system that works in spite of  (or maybe because of) the selfishness of the participants.

My - let's not call it a theory, but an emerging hypothesis - is that the consensus process tends to incentivize confrontational approaches, especially when the difference between winning and losing may have real world implications for the participants in the form of compensation, recognition, product acceptance etc.   

The WG chairs can mitigate this somewhat, but in some cases the chairs are as much the problem as anything else in that their biases and goals favor one "side" or another.  It's hard to have a WG chair who is completely impartial,  but I don't know that that's a goal we should be pursuing.

My fondest desire would be to have a system that works in spite of (or because of) human nature regardless of the participant set and mostly gets the "right" answer for some definition of right.  I'm not opposed in principle to the current process, except that I think more "wrong" decisions are tending to creep in and I think it's related to the consensus process in some form.

I have no objective measures for "right", "wrong" and their relationship to the current process.  Unfortunately, neither does the IETF as a whole.  The paragraph immediately above is at best a feeling and at worst a premonition....

[Side note here - sorry:  A lot of this discussion has been of the form "what's good for our participants", when I think it needs to at least as much about "what's good for the IETF production of good technical standards".  The former is important, but more important - to me at least - are quality standards.   If we can do the latter while considering the former, I'm all for it, but if we do the former and ignore the latter, I think we're doing ourselves a big disservice.]

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Jun 2015 08:08:16 +1200

Mike,
On 13/06/2015 04:52, Michael StJohns wrote:
...
> My - let's not call it a theory, but an emerging hypothesis - is that the consensus process tends to incentivize confrontational approaches, especially when the difference between winning and losin…

I snipped this out of context to bring up another point we haven't really
focussed on: all this talk of winning and losing. My emerging hypothesis is
that treating a standards discussion as a zero-sum game, with winners and
losers, is a fundamental mistake that we all tend to make. We should always
be looking for a win-win. Probably the most important thing that ADs and
WG chairs could do to make our discussions more courteous is to remind
everybody of this whenever necessary.

I have a secondary hypothesis that the nature of the rough consensus
process makes people a bit more likely to behav as if they are in a zero-sum
game, but that is secondary and hard to prove.

     Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Jun 2015 19:25:48 -0700

Brian E Carpenter wrote:
> > My - let's not call it a theory, but an emerging hypothesis - is that the
> consensus process tends to incentivize confrontational approaches,
> especially when the difference between winning and losing may have real
> world implications for the participants in the form of compensation,
> recognition, product acceptance etc.
> 

I don’t believe that is necessarily a correct correlation. Getting consensus that a proposed solution meets the requirements is not necessarily a zero-sum effort. If people disagree about the requirements to start with, it is very hard to get consensus about any proposed solution. It becomes a zero-sum when it is a beauty contest or competing implementation biased "one size fits all" outcome. 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. Insist on "one-size-fits-all", or skip the requirements document, and you almost ensure a zero-sum fight. 

Tony

---

From: John Leslie <[email-masked]>
Date: Sat, 13 Jun 2015 06:21:54 -0400

Tony Hain <[email-masked]> 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...

> 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.

   But _this_ is the time when it's easiest to put areas of contention
out-of-scope.

   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.

--
John Leslie <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Jun 2015 09:19:08 -0400

--On Saturday, June 13, 2015 06:21 -0400 John Leslie
<[email-masked]> wrote:

>    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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Jun 2015 14:39:48 +0100

> We have rules.  They are mostly vague and subjective, but

They are not markedly more vague or subjective than is typical for this
topic.  The problem is with enforcement, not with the rules.

> We almost never try to enforce
> low-key requests/ advice that someone shape up.

It's worse than even that.  We never enforce them, unless the offender
is a recidivist we do not like.

For recidivists we do like, we give them the mild warning and never go
further, pretending each offense does not sufficiently cross the line or
is new and they only warrants another quiet, useless warning.

To add to this egregious model, we consider it justified to engage in
offensive behavior if the community does not like the target.  After
all, they were asking for it...

>     We also have a recall
> point of actually removing someone from office. 

Somewhat ironically, Nomcom regularly returns to office people who
regularly engage in offensive behavior.

> system or overt bad behavior.   

Possibly a worthy topic, but it's quite separate from the continuing
tolerance and even encouragement of grossly unprofessional conduct.

Again:

   We have rules concerning acceptable behavior.  We do not enforce
them.  Perhaps they need strengthening, but we aren't even using the
ones we have.

   A generic, public call for better behavior is always useless.  It
might make the speaker feel that they've done something useful, but they
never have.  Never.

   A quiet, private chastisement to an individual is always useless with
a recidivist.  We have quite a few of those.

   At a minimum, a first step in taking corrective action needs to be to
require the offender to initiate a public apology.  The community needs
to see that unacceptable behavior is not acceptable.  (The issue is not
that the community see that this is the result of disciplinary action;
it needs to see acknowledgement that the behavior was not acceptable.)

   For recidivists and anyone engaging in particularly extreme behavior,
we need to start taking more severe actions.[*] There needs to be an
plan of escalating consequences.  It needs to be applied.

   Nomcom needs to pay attention to candidates' persistent, offensive
behaviors.

d/

[*]  This includes for offenses we class as harassment, taken to the
Ombud.  To date, this has been an entirely ineffective channel.

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 13 Jun 2015 09:04:33 -0700

John Leslie wrote:
>    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.
> 
>    Folks with a "solution" honestly believe everything it does belongs in
> "requirements". Folks without a solution (yet) propose "wish-list" 

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.
> 
document;
> yet we managed quite nicely to constrain the requirements, simply by
> agreeing that once we had something "good enough for a start,"
>    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

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Jun 2015 13:57:46 -0400

Hmm.   I think that, while our vocabularies for describing the
issues are different, we are actually in almost complete
agreement.  Inline below.

--On Saturday, June 13, 2015 14:39 +0100 Dave Crocker
<[email-masked]> wrote:
 
> They are not markedly more vague or subjective than is typical
> for this topic.  The problem is with enforcement, not with the
> rules.

In practice, yes.  I think the form of some of the rules
contributes to the enforcement problem (and the "different rules
depending on we feel about the people" problem described below),
but there is no practical difference in behavior.

>> them when they appear to be violated, at least beyond private
>> or low-key requests/ advice that someone shape up.
> 
> It's worse than even that.  We never enforce them, unless the
> offender is a recidivist we do not like.

Technically, I don't thing "recidivist" [1] is the issue but
that the practical focus is on "we don't like" not on repeated
offenses.    Again, a difference in how the problems are
understood and described, no difference in practice.
 
> For recidivists we do like, we give them the mild warning and
> never go further, pretending each offense does not
> sufficiently cross the line or is new and they only warrants
> another quiet, useless warning.

See above and note that if may not really match the situation to
characterize "mild warning" as "punishment"

>...
>>     We also have a recall
>> mechanism for removing people from leadership position who
>> have gotten out of hand, a mechanism that has never been used
>> to the point of actually removing someone from office. 
> 
> Somewhat ironically, Nomcom regularly returns to office people
> who regularly engage in offensive behavior.

Yes, I had noticed that.  Somewhat separate topic, but
especially since the examples that various leaders set may be
more important than any amount of instruction about community
norms, the inability or unwillingness to understand these
issues, observe the behavior, and deal decisively with it may be
an even greater problem than others that have been more directly
part of this discussion.

> Possibly a worthy topic, but it's quite separate from the
> continuing tolerance and even encouragement of grossly
> unprofessional conduct.

I would agree except that, when someone can "win" by exhibiting
sufficient grossly unprofessional conduct to drive most of the
people who disagree out of the discussion and then claiming
consensus, it is one of the things that encourages that
behavior.  More generally, any time that someone exhibits
unprofessional conduct and that produces the results that the
person desired and does so without negative consequences to that
person, it reinforces the bad conduct.

> Again:
> 
> 
>    We have rules concerning acceptable behavior.  We do not
> enforce them.  Perhaps they need strengthening, but we aren't
> even using the ones we have.
>...

If I disagree about anything in your list, it is only because I
suspect that there might be a counterexample or two to some of
those cases.  I even know of a few.  On the other hand, I don't
think a change from "never" to "hardly ever" changes anything of
significant. 

>...
> [*]  This includes for offenses we class as harassment, taken
> to the Ombud.  To date, this has been an entirely ineffective
> channel.

Concur.  At the same time, to the extent to which the intended
model for dealing with harassment is to quietly educate and
correct the bad behavior, the greatest successes would be the
ones the community never hears about (see note [1] below).

best,
   john

[1]  Technically, the problem people you are referring to are
not "recidivists" and that may be exactly the problem. That
term, as I understand it, would normally apply to someone who
have been caught and punished already; the point you make below
is that we never, or substantially never, punish anyone we do
like (or, I'd suggest, have learned to tolerate, perhaps because
of some offsetting advantages like having interesting things to
say).  This distinction is important as long as a lot of the
community's thinking is tied to "try to get people to understand
the consequences of their behavior and reform" rather that 
punishment and the hope that it would either correct or deter
bad behavior.
Independent of the IETF, that model does not have a good record
of success.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Jun 2015 08:22:46 +1200

On 14/06/2015 01:19, John C Klensin wrote:

<snip>
>...   However, if a WG is

Yes, and this is certainly a very real situation. I've personally
experienced it in the past, and am currently experiencing it
(without belligerence, fortunately).

It calls for an open mind, a good understanding of the sunk cost
fallacy, and consciously neutral chairing.

> attrition.  

Yes; again, the chairs have to look out for people with alternative
proposals who are not being heard.

> If they should up on IETF Last Call, we sometimes
> or both.  

Indeed. The very term "last call" sets that up. By then, it's
really too late to avoid a mess.

Regards
   Brian

---

From: Melinda Shore <[email-masked]>
Date: Sat, 13 Jun 2015 13:36:19 -0800

> (without belligerence, fortunately).

I'm actually pretty ambivalent about this one.  I'd much
rather see things coming in that are relatively well-baked
than see proposals that are just problem descriptions.
It seems to me to be a more productive use of energy to
negotiate engineering differences than it is go try to
figure out whether or not a given problem statement reflects
an actual problem that somebody is really experiencing, or
if there's the ability to come up with a useful solution.
Yes, it can be heated and horrible (and I actually left the
IETF for several years in part because of my experience
along these lines in one particular working group), but
I think we're better off figuring out how to deal with
these situations than we are going with the problem statement/
use case/gap analysis model, which is really beginning to
annoy me as unproductive, slow, and unmoored to much that's
useful.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Jun 2015 17:46:47 -0400

I find myself in the middle on this.
Spending a lot of time on use case documents, and deciding which use 
case documents you will adopt (the answer usually being all) is not 
productive.
But not having agreement on the problem, or conversely having agreement 
on the solution whatever the problem really is, also produces veyr bad 
results.

We have, many times, managed to thread our way in between these various 
extremes.  From what I have seen, that usually works better.  (It also 
helps if there are actually enouhg people willing to do the work.)

Yours,
Joel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Jun 2015 18:25:42 -0400

> fallacy, and consciously neutral chairing.

One of the structural problems in the industry is that most of the hard
core technologists use Linux while most of the end users work on Microsoft
or OSX. That has some very significant consequences that I don't think are
widely appreciated.

I deliberately have a hybrid environment where I use Windows for
development, Mac for personal and Linux for the machine shop. I don't do
that because I believe each is best suited for those tasks, I do it to
avoid being biased.

Working from a Linux mindset has the consequence that the network protocol
stack is very fluid. Use of a new transport option in an application
setting, use of raw DNS records is completely natural. The fact that 5% of
the deployed base can make such changes with ease blinds folk to the fact
that it is a five to ten year deployment lag on Windows or OSX.

What possibly saved us in the past is that Microsoft saw itself as the
industry leader and put a lot of resources into maintaining that role. In
particular being aggressively proactive in deployment of IPv6, IPSEC, PKIX
and other specs. They have not played that role since Bill Gates stood down
as CEO however and that has consequences.

In the security area, one of the structural problems is that there are folk
who believe that the commercial cryptography industry is the enemy and that
they have absolutely nothing of value to contribute. So rather often it is
necessary to introduce ideas in ways that the source isn't known so that
they aren't shot down.

---

From: [email-masked]
Date: Sat, 13 Jun 2015 18:59:41 -0400

You should never spend time discussing whether to accept use cases. 

Use cases should only be prioritized. 

Sent from my iPhone

> On Jun 13, 2015, at 5:46 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Spending a lot of time on use case documents, and deciding which use case documents you will adopt (the answer usually being all) is not productive.
> But not having agreement on the problem, or conversely having agreement on the solution whatever the problem really is, also produces veyr bad results.
> 
> We have, many times, managed to thread our way in between these various extremes.  From what I have seen, that usually works better.  (It also helps if there are actually enouhg people willing to do the work.)
> 
> Yours,
> Joel
>

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 13 Jun 2015 20:59:04 -0700

Melinda Shore wrote:
> >> started with a "solution" and a group of people behind it, there are
> >> some bad effects:
> > experienced it in the past, and am currently experiencing it (without
> > belligerence, fortunately).
> 
> I'm actually pretty ambivalent about this one.  I'd much rather see things
> coming in that are relatively well-baked than see proposals that are just
> problem descriptions.
> It seems to me to be a more productive use of energy to negotiate
> engineering differences than it is go try to figure out whether or not a given
> problem statement reflects an actual problem that somebody is really
> experiencing, or if there's the ability to come up with a useful solution.
> Yes, it can be heated and horrible (and I actually left the IETF for several
> years in part because of my experience along these lines in one particular
> working group), but I think we're better off figuring out how to deal with
> these situations than we are going with the problem statement/ use
> case/gap analysis model, which is really beginning to annoy me as
> unproductive, slow, and unmoored to much that's useful.

If a research team brings in a prototype and 'throws it over the wall' to le the WG refine it, I agree. All too often though a product team brings in a beta, and expects a rubber stamp of their soon to ship product. Those are the times that get heated, because changing the 'requirements' means slowing down the release.

I understand that many people hate the requirements/problem-statement/use-case documents, but without those the spec has no goals. Granted people driving a given solution will have a set in their head, but if you really expect consensus, and particularly if you expect the wider IETF to understand the context, it has to be documented and agreed on by the WG. Contention rooted in a difference of opinion about the requirements / use-cases can be dealt with by letting each faction solve their favorite subset. Saying 'there can be only one true way' will force heated discussions.

Tony

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 14 Jun 2015 09:44:51 +0200

a strong +1 to this summary.
Best regards, Tobias

---

From: t.p. <[email-masked]>
Date: Sun, 14 Jun 2015 09:13:00 +0100

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 25 Jun 2015 11:11:16 -0700 (PDT)

This has been a very interesting discussion but I think
its focus on action/behavior and "standards by combat"
(I will buy that t-shirt!!!) has distracted from what I
think is a very important point Mike made, which was:

"Don't annoy anyone unnecessarily, and don't be easily annoyed."

I think the second half of that sentence is just as important
as the first. It is very easy to misinterpret an email and
that causes people to ascribe bad motives to the sender and
to disregard or reject the points being made, which creates
frustration and even more misinterpreted emails.

  I met someone in the bar at the last IETF who, when learning
my name, said something to the effect of "why are you such
an asshole?" And over a beer we discussed things that came
across wrong in email and ended up with an amicable "well
I might not agree with you 100% but I understand your points
and you are not the asshole I imagined you were."

  So it's good to focus on actions to avoid confrontation
and attacks it's also important to not forget our reactions
and to put what we read in the most generous light possible.

  regards,

  Dan.