On Mon, Dec 14, 2015 at 8:04 AM, Jari Arkko <jari.arkko@xxxxxxxxx> 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.