Internet DRAFT - draft-elkschul-conflict-problem
draft-elkschul-conflict-problem
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]
