INTERNET-DRAFT N. Elkins Inside Products, Inc. H. Schulzrinne Intended Status: Informational Columbia University Expires: June 8, 2019 December 5, 2018 Conflict Resolution within a Working Group: Problem Statement draft-elkschul-conflict-problem-01 Abstract At the IETF, we currently use a set of methods to communicate a point of view, to solicit input, to resolve conflict and attempt to obtain consensus within the group. These methods include: writing an Internet Draft, discussion on email lists, discussion at face-to- face, interim or virtual meetings, and design teams. At times, these methods fall short. People become entrenched in their positions. A Working Group may be split for a prolonged period wasting time and energy. There may be a lasting impact. While the authors support rough consensus, the collateral damage of this process, at times can be considerable. This document discusses the benefits and drawbacks of each of the current methods of communication focusing solely on their efficacy at conflict resolution. A companion document will propose some solutions including alternative methods of conflict resolution. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html N. Elkins Expires June 8, 2019 [Page 1] INTERNET DRAFT Conflict Problem Statement December 5, 2018 Copyright and License Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. N. Elkins Expires June 8, 2019 [Page 2] INTERNET DRAFT Conflict Problem Statement December 5, 2018 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conflict about Design Details . . . . . . . . . . . . . . . 5 1.2 Fundamental Disagreement and Competing Goals . . . . . . . . 5 1.3 Values-Based Conflict . . . . . . . . . . . . . . . . . . . 6 1.4 Cultural Issues . . . . . . . . . . . . . . . . . . . . . . 6 2. Current Methods of Communication . . . . . . . . . . . . . . . 6 2.1 Writing an Internet Draft . . . . . . . . . . . . . . . . . 6 2.1.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Shortcomings . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Discussion on Email Lists . . . . . . . . . . . . . . . . . 7 2.2.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Shortcomings . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Discussion at Face-to-Face or Interim Meetings . . . . . . . 8 2.3.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Shortcomings . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Design Teams . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Shortcomings . . . . . . . . . . . . . . . . . . . . . . 10 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Normative References . . . . . . . . . . . . . . . . . . . 10 5.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 N. Elkins Expires June 8, 2019 [Page 3] INTERNET DRAFT Conflict Problem Statement December 5, 2018 1 Introduction At the IETF, we currently use a set of methods to communicate a point of view, to solicit input, to resolve conflict and attempt to obtain rough consensus within the group. Our current methods of communication include: writing an Internet Draft, discussion on email lists, discussion at face-to-face meetings, discussion in virtual meetings, and design teams. However, at times, these methods fall short. People become entrenched in their positions. A Working Group may be split for a prolonged period. This wastes time and energy and may have a lasting impact. For example, unresolved conflicts may cause the Working Group to miss its milestones, and, in more extreme cases, the personal working relationships within the Working Group may fray. In even more extreme cases, participants that feel that their view was not properly considered may file an appeal with the IESG or may even take their work to another standards organization, creating competing and conflicting standards. This document discusses the benefits and drawbacks of each of the current methods of communication. A companion draft will propose some alternative methods of conflict resolution. These methods should be used if the current methods do not produce the desired result. Questions arise as to who might determine when that point is reached and the procedure for making sure these conflict steps are followed or enforced. The first step may be to experiment with some new methods, and if they are successful, then to move to integrate them into the life of the community. This document does not propose to overturn the rough consensus [RFC7282] for making decisions. We would like to discuss the problems that happen during the process of coming to rough consensus to see if we can make the process better. Much of the productive work of the IETF is in the conversations that participants have with each other, some lasting for many years. As an example, this particular draft is the result of a conversation between the authors. These conversations and relationships sometimes end up as RFCs on a particular topic or in changing viewpoints of people who are leaders in their field. Disruption and corrosive communication keeps us from doing the best, most innovative work in the best environment. Group harmony and cohesiveness as well as encouraging diverse viewpoints are important in an organization as important to the Internet ecosystem as the IETF. Having said that, conflict is important. It is only by speaking N. Elkins Expires June 8, 2019 [Page 4] INTERNET DRAFT Conflict Problem Statement December 5, 2018 openly and clearly about the engineering matter at hand, can we get the best resolution. But, when conflict goes on too long, is too harsh, and appears to be going nowhere, then good people get discouraged. Conflict is inevitable when there are competing goals. Yet, if it were just an engineering cost / benefit discussion, conflict resolution would be simpler. The reader may wish to reflect on conflict within their own family or company. We humans bring emotion to conflict resolution. There are many psychological articles written on conflict resolution. Many people have jobs as professional arbitrators. If conflict resolution were so simple, these people would be out of work. Having said that, fundamentally different views, competing goals or values inherently cause tension. This will be discussed in more detail in the next section. 1.1 Conflict about Design Details Some conflicts are about the content or structure of a particular field in the protocol (ex. QUIC SPIN bit, IPv6 prefix /64 or not /64). At times, these conflicts can be resolved by having the parties discuss the issue privately or by creating a design team. This can work well, unless there is a fundamental disagreement of values or competing goals. See next section. 1.2 Fundamental Disagreement and Competing Goals The conflict may be rooted in a fundamental disagreement about both the nature of the problem and the nature of the solution. Often, these are fundamentally different views of what the design requirements, likely use cases and future environments are going to be. A classic case is the generality vs. performance or backward- compatibility vs. elegance/simplicity trade-off. These type of arguments are about values, not just the best design for a particular, agreed-upon, design objective. Competing goals may be that applications wish to be able to modify their code easily. The transport layer may wish to have control over large amounts of unneeded data impacting other traffic. While enterprises may wish to monitor and diagnose problems in both applications and transport. There is an inherent tension with competing goals. What seems to happen today is that each "side" sees the value and rationale for its own goals quite clearly while discounting the goals of others. For both the above, new solutions may shorten the time and effort to N. Elkins Expires June 8, 2019 [Page 5] INTERNET DRAFT Conflict Problem Statement December 5, 2018 reach consensus. 1.3 Values-Based Conflict Protocols have impact on what can and cannot be done on networks. These considerations are sometimes the most hotly debated issues. Values-based conflicts can include: enabling freedom of speech or assembly vs. protection of life and safety. Some of these discussions are held in the HRPC group as well as during the process of each draft but these are difficult issues and often it seems easier for many to simply ignore them. 1.4 Cultural Issues IETF participants are all over the world. So, methods for conflict resolution must take this into account. People all over the world need to be able to see and comment. As the IETF transitions to a more and more multicultural set of participants, any methods of conflict resolution must take this into account. 2. Current Methods of Communication In discussing the following methods, we are looking at them only in the sense of how good are they at resolving conflict. There may be many other benefits or shortcomings to each method. These aspects will not be discussed here. 2.1 Writing an Internet Draft Writing an Internet Draft means that you write down a specific technical argument or proposal in concrete terms. Drafts are not all intended to become RFCs, some are a starting point for a discussion about the topic. There is a relatively well-understood process of different kinds of drafts, use cases, actual protocol changes, gap analysis, and so on. The kinds of drafts that are needed in particular when there is an area of high conflict are problem statement or use case drafts which distill and explain issues. 2.1.1 Benefits Having a written document helps clarify misunderstandings. People involved in the discussion can ask for clarifications. Fundamental concepts can be verbalized. Even that in itself can be a large step forward in coming to a final resolution. Having a written document also means that you can communicate with N. Elkins Expires June 8, 2019 [Page 6] INTERNET DRAFT Conflict Problem Statement December 5, 2018 people all over the world. This is essential as IETF participants are in many countries. 2.1.2 Shortcomings Some drafts are better than others. Some people write better than others. Some people address core issues better than others. In the companion solution document, we will discuss some proposals of how to write such a draft well, so that it helps make progress. For example, it can help if the chair or working group formulates a series of questions that both sides try to answer, or create a set of test cases ("How does your approach solve X?") 2.2 Discussion on Email Lists Much of the discussion on any problem take place on the email list of the Working Group in question. These email lists are open to all who choose to subscribe. They are public. The language used is English. 2.2.1 Benefits People all over the world can participate in an email conversation. Writing things down forces you to try to be clear so that others can understand you. A record is preserved of what was said. It is sometimes easier to say and hear unpleasant things when you do not have to respond immediately. You can think and write back at your convenience when hopefully you have had some time to reflect on what is being said. Admittedly, some people do not take advantage of the time to reflect and react thoughtfully as well or as often as they might. 2.2.2 Shortcomings Email discussions can be dominated by small groups of people. Sometimes people do not want to participate because they feel that the discussion is between people who know each other well and communicate in shorthand. This is a strength and a weakness. It is normal that people who have been very involved in a topic for many years will communicate in shorthand. It takes time for a newcomer to understand the history. Discussions are also basically engineering meetings so it is normal to speak in acronym-ese. On a logistical notes, due to the limits of email text, either you get deeply nested quoting that are hard to follow or a single email discusses several different issues. The email subject line should N. Elkins Expires June 8, 2019 [Page 7] INTERNET DRAFT Conflict Problem Statement December 5, 2018 be updated if the conversation drifts but not all participants follow this. When a discussion concludes, it is hard to know whether a conclusion has been reached or people are just worn out. In the case of having an accurate record of proceedings, what can happen is that there is a spate of emails and then there is a face to face meeting where hallway and Working Group discussions happen which are not all documented. So, then it is not clear how the original issues were resolved unless you are a very active participant or were at the f2f meeting. On email lists, people can do a "hit-and-run". That is, with the distance provided by email lists, some people feel free to say things more harshly than they might in a face to face encounter. There is sometimes a tendency to "pile on" - ten people responding with the same criticism. Some feel that sheer volume or number of posts will win the argument. Bikeshedding is defined by Wikipedia as follows: "Parkinson's law of triviality is C. Northcote Parkinson's 1957 argument that members of an organisation [sic] give disproportionate weight to trivial issues. He provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task." Email list discussion lends itself quite well to bikeshedding unless stopped by a participant. In the solution draft, we will discuss some options such as keeping an issue list or tracker and suggesting one of the Working Group chairs (or, a neutral party) summarize the discussion, indicating next steps ("Alice has agreed to draft text explaining the approach she just informally summarized.") or at least try to distill the viewpoints. Active engagement by one of the chairs can help, in general, e.g., by trying to calm down participants or encourage separating issues. 2.3 Discussion at Face-to-Face or Interim Meetings Much of the work of the IETF happens at face to face or interim virtual meetings. This document concentrates on conflict resolution, so we will discuss only that aspect. In this regard, we will group N. Elkins Expires June 8, 2019 [Page 8] INTERNET DRAFT Conflict Problem Statement December 5, 2018 face-to-face and interim meetings together as the conflict resolution aspects of both appear to be quite similar. Within a meeting, however, there are differences between the public Working Group meeting and more informal small-group meetings. At the formal meeting, there is the presentation of the topic itself and the microphone line. 2.3.1 Benefits To get the people who care about the issue all in the same room, virtual or otherwise, can be invaluable. Sometimes the discussions in the Working Group itself are to the point and resolve problems quickly that may have taken much longer had it been on an email lists. Hopefully, most of the people who care about the issue are at the meeting so the discussion accurately reflects the needed viewpoints. People can also meet informally in the hallways, over meals, or beverages and talk to each other. This all sometimes works very well. The microphone line can be a fair way to allow any interested participants to comment. 2.3.2 Shortcomings Some people posture at the microphone line in the Working Group meeting. This can be a problem particularly in a very contentious issue. The small group meetings can become echo chambers. That is, people cluster with those who agree with them, reinforcing their viewpoint, and the notion that others who disagree with them are misguided. Often, the presentations are so detailed that people who have not had a chance to follow the discussion can't really understand the argument. While everyone *should* read the I-D, in practice, many people do not, so it seems helpful to provide sufficient background that new voices can be hear. 2.4 Design Teams RFC2418 defines Design Teams as follows: "6.5 Design Teams It is often useful, and perhaps inevitable, for a sub-group of a N. Elkins Expires June 8, 2019 [Page 9] INTERNET DRAFT Conflict Problem Statement December 5, 2018 working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole." [RFC2418] Further clarification on design teams is provided by an IESG statement [IESG-DT]. 2.4.1 Benefits Design teams can work well when there is a very defined problem to be solved. 2.4.2 Shortcomings In the case of a larger issue, then design teams may end up being split in the same proportion as the larger group as the fundamental issue has not been addressed. In practice, design teams vary in their effectiveness. It has been reported that some people assigned to the design team do not attend the meeting. This is not likely to be helpful in resolving the situation. 3 Security Considerations There are no security considerations addressed in this document. 4 IANA Considerations There are no IANA considerations addressed in this document. 5 References 5.1 Normative References [RFC2418] Bradner, S. "IETF Working Group Guidelines and Procedures", RFC 2418, September 1998. [RFC7282] Resnick, P. "On Consensus and Humming in the IETF", RFC 7282, June 2014. N. Elkins Expires June 8, 2019 [Page 10] INTERNET DRAFT Conflict Problem Statement December 5, 2018 5.2 Informative References [IESG-DT] https://www.ietf.org/iesg/statement/design- team.html Authors' Addresses Nalini Elkins Inside Products, Inc. Carmel Valley, CA 93924 USA Phone: +1 831 659 8360 Email: nalini.elkins@insidethestack.com URI: http://www.insidethestack.com Henning Schulzrinne Columbia University/Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu N. Elkins Expires June 8, 2019 [Page 11]