Ah, the Zulu indaba.
Ah, Shaka Zulu, who invented the iklwa (shortened assegai)
to great success. The Alexander of Africa. Zulus weren't
renowned for their consensus with neighbouring tribes.
You do realise that the 'red line' is best drawn in your
enemies' blood, right? That should liven up and shorten
the queues for a microphone.
Perhaps you should try Swedish Fikas instead.
L.
Lloyd Wood
lloyd.wood@xxxxxxxxxxx
http://about.me/lloydwood
From: Jari Arkko <jari.arkko@xxxxxxxxx>
To: IETF <ietf@xxxxxxxx>
Sent: Tuesday, 15 December 2015, 0:04
Subject: negotiation and consensus-finding styles
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