Conflict Resolution within a Working Group: Problem Statement
draft-elkschul-conflict-problem-00

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]