Subject: negotiation and consensus-finding styles

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Dec 2015 15:04:10 +0200

This caught my eye (and some other people’s eye too, got some
people asking about it):

   "This simple negotiation tactic brought 195 countries to consensus"
   http://tinyurl.com/qb4oyq9

It is about the climate change negotiations. Government negotiations
are not my thing in general :-) but this article points to a specific
negotiation style, Indaba:

  https://en.wikipedia.org/wiki/Indaba

  "Instead of repeating stated positions, each party is encouraged
   to speak personally and state their “red lines,” which are
   thresholds that they don’t want to cross. But while telling others
   their hard limits, they are also asked to provide solutions to find
   a common ground.”

I’ve never heard of this particular technique before, have
other people run into it? Any experiences? Any more detailed
information? The reason that I’m asking is that it kind of sounds
like the way people should be voicing their opinions in an IETF
discussion, when that discussion is run in an optimal way.
Along with our rough consensus concepts, of course, and
drive to understand other people's positions.

Just wondering if this is essential what our rough consensus
process already is, or if there are further details that we could
consider learning from as well.

(And: as always, any process can by misused if the participants
do not care enough about the common good. I’m sure this
never happens in government negotiations :-) but in the
rest of the world… one example that I’ve seen in the IETF
is overstating hard requirements, e.g., making particular
solutions part of the requirements. Next time you discuss
something in the IETF, please take a moment to reflect
what your true needs are and what are just solution
space options. Take also a moment to understand
what the other people are saying, and try to build
that into what you are suggesting, finding ways for
other people’s needs to be also met.)

Jari

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Dec 2015 14:27:14 +0100

> drive to understand other people's positions.

I thought we were doing that -- chairs are eliciting these red lines by
asking questions like "who can live with XXX", "who cannot accept YYY", ...

The main observation remains: where there is contention, progress is
often not made in plenaries (translate: WG meetings), but in small focus
meetings (the real bar BOFs, or other ad-hoc/hallway meetings).  We do
occasionally make progress in WG meetings, but these are also a great
place for bullying and decisions based on social proof (as opposed to
technical considerations).

All that said, I still hope we are doing less "negotiation" than was
needed in Le Bourget, and focusing more on technical considerations.
Hope dies last...

Grüße, Carsten

---

From: [email-masked]
Date: Mon, 14 Dec 2015 06:49:56 -0800 (PST)

> other people run into it? Any experiences?

Having participants identify their "must have" versus "nice to have" versus
"don't care" items has been a common if not universal feature of the IETF WGs
I've participated in for as long as I can remember.

This is a helpful process but it is not a panacea. For one thing, there has to
be mutual understanding and common ground before this technique can be
effective.

> Any more detailed

> consider learning from as well.

This isn't the quite same a rough consensus, although there's clearly some
overlap.

But I'm afraid I don't see anything new here either.

				Ned

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 03:21:33 +0000 (UTC)

Ah, the Zulu indaba.

Ah, Shaka Zulu, who invented the iklwa (shortened assegai)to great success. The Alexander of Africa. Zulus weren'trenowned for their consensus with neighbouring tribes.

You do realise that the 'red line' is best drawn in yourenemies' blood, right? That should liven up and shortenthe queues for a microphone.

Perhaps you should try Swedish Fikas instead.

L. 
Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Jari Arkko <[email-masked]>
 To: IETF <[email-masked]> 
 Sent: Tuesday, 15 December 2015, 0:04
 Subject: negotiation and consensus-finding styles

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 01:22:02 -0500

> drive to understand other people's positions.

That is what I do.

The problem comes when folk don't accept that I might legitimately
have red lines and those red lines might have to take priority over
their preferences or whims.

Or alternatively, as happened to me on DPRIV, after attempting
to do something very similar a few years earlier, various browser providers
told me their red lines (page load latency cannot increase) which I
relayed to the group which promptly ignored them.

Deployment issues do create red lines for many parties whose buy-in
is often necessary to make a protocol successful.

> consider learning from as well.

No, a red line is not merely a preference. You have to be able to
back it up with concrete consequences. Back in 2001 I told the
DNSEXT group that they could have DNSSEC deployment in the
root and .COM within 12 months if they made one very minor
change. It took 3 years to get a decision on the change which was
refused. Then three years later it was accepted as part of another
proposal by which time the DNS was far more complex. We are still
far behind where we might have been in 2003 had some people
been willing to accept that the operator of the major DNS
infrastructure might legitimately reject a specification that would
introduce $15-$30 million in unnecessary costs.

The other problem is that quite often critical stakeholders are not
at the table. And rather than make the effort to bring them to the
table, this is seen as a good thing as the fewer people to argue,
the sooner the work will be complete.

> other people’s needs to be also met.)

That is why consequences are important. A tenfold increase in
data volume is a serious consequence and should be accepted as
justification for a red line. The fact that the browser market is
driven by competition to optimize page load latency gives
rise to consequences.

In general, a red line is not a personal constraint, it is an external one.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 11:51:10 -0500

> In general, a red line is not a personal constraint, it is an external one.

Another way to identify a genuine red line from a bluff is what
happens afterwards.

Right now we have a situation in which CABForum rules for managing the
WebPKI deliberately and intentionally violate a MUST in RFC 5280 Sec
4.2.1.10.

According to RFC 5280, a name constraint MUST be marked critical. The
industry explicitly rejected that approach and the CABForum has an
override that allows the CA to decide.

This is not an abstract dispute, conforming with RFC5280 causes a lot
of real world systems to break which is of course the sole point of
the critical flag. The only reason for marking an extension critical
is when the desired behavior is for relying parties that do not
understand the extension to reject the certificate.

The industry has decided that wherever possible, name constraints
should be used to limit the exposure of a CA or intermediate in the
case of breach or compromise. Marking the certificates critical would
have rendered them unacceptable.

There has been one positive outcome from the situation though. I did
use it in a private discussion with a former senior NSA employee as an
example of an instance where the disclosure of the NSA BULLRUN program
has materially damaged cyber security efforts. That person has
subsequently changed their position on crypto backdoors to oppose
them.

Even if it is the case that the opposition was not driven by a covert
NSA program, the suspicion that it might be is obviously damaging and
corrosive. My personal theory is that that particular set of slides
was actually written by a Major trying to make Colonel who was trying
to explain how his cyber-defense activities fit into a mandate for
cyber-attack.

I think that there is a need for some mechanism to correct the
situation in cases like these where a group in IETF came to a
particular decision and the actual users of the specification came to
a different decision and acted on it. No useful purpose is served by
insisting that the specification reflect a Working Group consensus
that has been rejected in the defacto Industry standard.

More generally, I see a rather important distinction between 'the
consensus is that we shall all do X' and 'the consensus is that you
must do X'. There is a particular style of 'consensus based' standards
making where a small group decide what they want to do and then use
some very sharp elbows to eliminate folk who might have a different
idea from the conversation. This is a particular problem with some of
the people who peddle consulting in 'IETF process' and whose metric
for success is speed to get their client's proposal published as an
RFC rather than establishing the industry support necessary to get the
proposal widely used.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Dec 2015 08:44:58 -0800

> ​<snip>​
​I think the point here is that in engineering contexts we talk about
constraints, rather than diplomatic "red lines".  If a deployable system
has a constraint (page load time cannot increase), then it is very
important that the constraint be clear to everyone working on the system.

But it is also clear that in the IETF engineering context, we have to look
at the engineering context outside a single implementation or protocol
exchange.  If we accept that not meeting a constraint will hinder
deployment, we have to look at the whole system to see how to meet it.
That may mean that work increases to cover both the core aim and the work
to meet the constraint.  If increasing the privacy of the DNS by setting up
cryptographic contexts increases latency in a naive implementation, then
the work to use long-lived connections or pre-emptive cache fill or other
latency-reducing tricks may have to be done along the way.

The tricky bit there is that the overall driver for the core work may have
to cover the implementation and deployment costs of the adjunct work, which
can be difficult to assess. This gets even harder, of course, when the
adjunct work shifts whose ox gets gored.

To put this another way, I think the IETF has ways of dealing with its
issues in ways which parallel Inaba style processes, but that they are
expressed more as constraints and re-contextualization in our world.

regards,

Ted