On Mon, Dec 14, 2015 at 8:04 AM, Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
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.
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.
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.
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.
(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.)
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.