INTERNET-DRAFT N. Elkins EDCO, Inc. H. Schulzrinne Intended Status: Informational Columbia University Expires: May 12, 2019 November 8, 2018 Conflict Resolution within a Working Group: Problem Statement draft-elkschul-conflict-problem-00 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 80-20 or 70-30 for a prolonged period. This wastes time and energy and may have a lasting impact. 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 May 12, 2019 [Page 1] INTERNET DRAFT Conflict Problem Statement November 8, 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 May 12, 2019 [Page 2] INTERNET DRAFT Conflict Problem Statement November 8, 2018 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conflict about Design Details . . . . . . . . . . . . . . . 5 1.2 Fundamental Disagreement and Competing Goals . . . . . . . . 5 1.3 Cultural Issues . . . . . . . . . . . . . . . . . . . . . . 5 2. Current Methods of Communication . . . . . . . . . . . . . . . 6 2.1 Writing an Internet Draft . . . . . . . . . . . . . . . . . 6 2.1.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Shortcomings . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 N. Elkins Expires May 12, 2019 [Page 3] INTERNET DRAFT Conflict Problem Statement November 8, 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 consensus within the group. These methods 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 80-20, 70-30 or even 50-50 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. Much of the productive work of the IETF is in the conversations that participants have with each other, some lasting for many years. 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 are important in an organization such as the IETF. Having said that, conflict is important. It is only by speaking 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 N. Elkins Expires May 12, 2019 [Page 4] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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 or competing goals 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 reach consensus. 1.3 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 N. Elkins Expires May 12, 2019 [Page 5] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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 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?") N. Elkins Expires May 12, 2019 [Page 6] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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 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 N. Elkins Expires May 12, 2019 [Page 7] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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 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 N. Elkins Expires May 12, 2019 [Page 8] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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 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]. N. Elkins Expires May 12, 2019 [Page 9] INTERNET DRAFT Conflict Problem Statement November 8, 2018 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] 5.2 Informative References [IESG-DT] https://www.ietf.org/iesg/statement/design- team.html N. Elkins Expires May 12, 2019 [Page 10] INTERNET DRAFT Conflict Problem Statement November 8, 2018 Authors' Addresses Nalini Elkins Enterprise Data Center Operators, Inc. Carmel Valley, CA 93924 USA Phone: +1 831 659 8360 Email: nalini.elkins@e-dco.com URI: http://www.e-dco.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 May 12, 2019 [Page 11]