Voting in IETF

Network Working Group Jacob Palme
Internet Draft Stockholm
draft-palme-voting-00.txt University/KTH
Category-to-be: Informational Sweden
Date: May 2002




Voting in IETF

Status of this Memo


This document is an Internet-Draft and is in full
conformance
with all provisions of Section 10 of RFC2026.

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/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.

Copyright (C) The Internet Society 2002. All
Rights Reserved.


Abstract

This memo discusses whether voting is useful or is not
useful in IETF work. The main conclusion is that
conventional decisive votings are usually not suitable for
IETF work, but that specially designed voting methods
could be an aid to IETF.


Mailing list

There is not yet any mailing list particular to this
topic.
To write

Further discussion of this memo can take place in the
mailing list
LANGTRANS@SU.SE.

Comments on less important details may also be sent to
the editor,
Jacob Palme .

To subscribe

To subscribe to this mailing list, send a message to
LISTSERV@SU.SE
which contains the text
SUB[SCRIBE] LANGTRANS address)>

To unsubscribe

To unsubscribe from this list, send a message to
LISTSERV@SU.SE
which contains the text
UNS[UBSCRIBE] LANGTRANS

To access mailing list archives

The archives are available for browsing from
http://salut.nu/forum/uno/6/1/
Use the browsing command "All messages" to get everything
written on a
single web page.


Table of Contents
1.1 Abstract
1.2 Mailing list
Table of Contents
2 Language Support in Existing Standards
3 Multi-Language Scenario
4 The Content-Translation-Of Header Field
5 The Content-Translator Header Field
6 Use of The Multipart/Alternative MIME Content
Type
7 The Translation-Request Header
8 Examples
8.1 Separate Original and Translated Messages
8.2 Sending a Message to a Translator Agent
from a Translation-Aware Mailer
8.3 Sending a Message to a Translator Agent
from a Non-Translation-Aware Mailer
8.4 Resending of the Message in 8.2 After
Translation
9 For Further Study
10 Security Considerations
11 Copyright and Disclaimer
12 Acknowledgments
13 References
14 Author's Address
Appendix A: A Discussion of Alternative Ways of
Handling Translation in E-Mail
Appendix B: An Investigation of Handling of
Multipart/Alternative in some Common Mailers in
November 2000 and November 2001


1 The Humming Method for Voting in IETF

An often cited IETF credo is "No Voting". In spite of
this, everyone who has been active in IETF standards work
knows that voting does occur fairly often, IETF has even
its own famous voting method, the humming method. With
this method, people hum instead of putting up their hands.
This means that people who are very sure of their opinion
can hum loader than those not so sure. The total hum of
all participants will thus count hums by those who are
very sure of their opinion higher than hums of those who
are not so sure. This does of course not work perfectly,
but is interesting because it attempts to overcome one
shortcoming of conventional voting.


2 Why is Conventional Voting not always Suitable in
IETF Work

Conventional voting usually involves specifying two or
more alternatives, and then asking how many people support
each alternative. If there are more than two alternatives,
the alternatives are sorted in some way so that each vote
only compares two alternatives. The alternative which gets
most votes is then the decision taken.

This conventional voting method has many disadvantages for
IETF work:

a) In standards work, it is better to think more
before a decision is made. Traditional voting has a risk
of making decisions too fast, not having considered all
options.

b) In standards work, each person is not equal. The
opinions of people who are known to have good technical
knowledge and sound opinions is counted higher than the
opinions of people who are known to often take extreme,
ill-considered views.

c) The goal of IETF decisions is "rough consensus"
which can be defined as "finding a solution which a large
majority of those who are known to have good technical
knowledge supports". Consider the following situation:

Solution A Solution B
----------------------------------
Very good 60 % 40 %
Good 0 % 60 %
Bad 0 % 0 %
Very bad 40 % 0 %

In the case described above, a conventional voting would
select Choice A, even though there is obviously rough
consensus for Solution B, but not rough consensus for
Solution A.


3 Why Voting may Sometimes be Useful in IETF

Most of the work in IETF is done through mailing list
communication between face-to-face meetings. This memo
only discusses voting in such e-mailed lists. Voting at
face-to-face meetings is a separate issue.

IETF has shown that technical standards work can be
progressed well through mailing list work. One large
advantage of mailing list work is that a decision is
reached gradually over many days. An expert can always
think about the issue and propose a new argument or a new
problem the next day. In face-to-face meetings, not making
a decision means that the decision is delayed until the
next face-to-face meeting, and this is a factor which can
force face-to-face meetings to make premature decisions
without fully considering the options and choices.

It is, however, a well-known fact, that progress in IETF
mailing lists is sometimes slow. There is, sometimes, a
tendency for the same arguments repeated over and over
again, without reaching a consensus. Sometimes, the result
is a vague standard which does not clarify clearly how the
designed protocol should work in the controversial case.
And such vagueness in standards is not good! Vague
standards imply the risk of different implementers
interpreting the standard in different ways, which might
cause interoperability problems.

The reason why work in mailing lists is slow is not fully
known, but one cause may be the lack of so-called
backchannels. Backchannels, such as body language, is a
way of showing the opinions in a group without having to
actually talk. In a mailing list, the only way to have
your view heard is to write a message. You could of course
only write a message saying "I agree" but often convention
requires you to explain why, even if the explanation is
only a repetition of what others have already written. If
you stop contributing to a discussion, because you feel
that your opinion and the arguments for it has already
been stated, then this may be interpreted by others as if
you have given up. Experts therefore feel a need to state
their opinion again, even if it is only a repetition of
what has been already said.

One extreme example of problems with decisions in mailing
lists is the issue of the "Reply-To" e-mail header in the
DRUMS IETF working group. This discussion caused thousands
of messages written during many months, and in spite of
this, no consensus was reached, and the final result was
just the kind of vagueness which should be avoided in good
standards.

(The problem with "Reply-To" is that it can recommend both
an address for reaching only the author of the replied-to
message, and an address for reaching a group, such as all
who got the replied-to message. The final result of the
DRUMS work, RFC2822, does not specify clearly which of
these alternatives is meant.)


4 What Kind of Voting Could be Suitable for IETF?


Considering the points made above, here are some
requirements on voting for use in IETF:

a) Voting should not be secret. The names of who voted
how should be displayed clearly in the results.

b) Voting should not be decisive. Voting should be
used to show the opinions of the experts in a working
group, in order to help their work along. But the actual
decisions should be taken by humans, not by a computerized
voting algorithm. Possibly "voting" is the wrong word,
because for many people it implies decisive voting. Maybe
the word "query" would be better than voting.

c) The voting procedure should give a nuanced view of
the opinions among the experts. Often a procedure where a
number of alternatives are listed, and each expert rates
each alternative on a scale from "very bad" to "very good"
might be suitable. In special cases, a voting form
suitable to the special case might be designed.

d) All reasonable alternatives, supported by some
competent experts, should be included in the voting
procedure. The voting should not be conducted in a way
which lets some competent experts feel that their view is
unfairly treated.

e) It is often good to have the voting continuous. By
a continuous voting is meant a voting procedure where
participants can, at any time, change their vote, and the
voting report will always show the latest, current, views.
Sometimes a breakpoint may be needed in order to get work
done, but even in such a case, it might be of value to see
if some experts have changed their opinion after the
breakpoint. If continuous voting is performed in parallel
with mailing list discussions, then the continuous vote
report will show how the views among the experts changes,
and will show when so many experts agree on a solution
that work should better continue on other issues.

f) For security issues, see chapter 6 below.


5 Implementation Issues

As in most technical work, there is no single possible
slution. One main choice is whether to use e-mail or a web
page to conduct the voting. The ideal solution should
perhaps allow both choices, so that every expert can
choose to vote either by e-mail or by the web page.

A voting system has two main phases:

- Definition if the vote form,
- The carrying out of the voting
- The result reporting.

In the definition phase, there should be built-in support
for the common kind of vote where a number of solutions is
listed, and each experts rates the solutions on a scale
from "very bad" to "very good". But also other formats, in
principle any customized html form may be used.

In the carrying out phase, experts should be able to vote
or change their vote at any time, and the result report
should also in most cases be visible at any time when
someone wants to check it, i.e. not wait until the end of
the voting time before displaying the result.

the result should be shown in a way which clearly shows
the names of the expert who gave their input. A suitable
format may be something like this example:

+----------+-------------+----------+-----------+----------+--
--------+
| Where | | | | |
|
|should we | | | | |
|
| meet? | Very bad | Bad |Acceptable | Good
|Very good |
+----------+-------------+----------+-----------+----------+--
--------+
| London | John Smith |Pete Nice | | Mary |
Stephen |
| | Andre Suoun | | | Strong |
Nicter |
+----------+-------------+----------+-----------+----------+--
--------+
| Paris | Mary Strong | | |
|John Smith|
| | Stephen | | | |
Andre |
| | Nicter | | | |
Suoun |
| | | | |
|Pete Nice |
+----------+-------------+----------+-----------+----------+--
--------+
| New York | Andre Suoun | |John Smith | |
|
| | | | Pete Nice | |
|
| | | |Mary Strong| |
|
| | | | Stephen | |
|
| | | | Nicter | |
|
+----------+-------------+----------+-----------+----------+--
--------+
| San Jose | | Andre | Stephen | Mary |
|
| | | Suoun | Nicter | Strong |
|
| | | | |John Smith|
|
| | | | |Pete Nice |
|
+----------+-------------+----------+-----------+----------+--
--------+

For security design issues, see chapter 6 below.


6 Security Considerations

There has been a lot of debate regarding the security of
Internet voting. The general consensus among security
experts is that Internet voting is so insecure, that it
should not be used. This debate, however, is based on
secret voting in large communities on political issues.
Security is much less of a problem in small communities
where the vote of each individual is not secret. Social
control, i.e. observation of what happens, will easily
show when something is wrong.

In IETF work, it may be enough with rather simple security
measures, such as that each expert (=member of the IETF
working group mailing list) is sent an individual e-mail
message, containing the URL of the voting page and the
loginid and password for this particular expert.

Security experts will surely say that there are lots of
risks with this method. However, note that the number of
active people in an IETF working group is usually less
than 100 experts, and that the result report (see chapter
5 above) shows how each expert has voted. If anyone tries
to falsify the result, the experts can immediately see
that their opinion is represented wrongly. A very advanced
cracker might give each expert a different view of the
result page, but this would soon be found out in the
mailing list.

Note that ordinary e-mail mailing lists are also not very
secure. A clever cracking can falsify the messages, but
this will not happen in practice because people will
immediately note that something is wrong.

The main security problems with voting is with secret
voting, which is neither needed nor desirable in technical
standards development.


7 A test implementation

With support from Terena, my university department has
developed an implementation of a voting system designed
according to the criteria explained above. Explanation and
instructions can be found at http://cmc.dsv.su.se/query/
and a test query can be found at http://cmc.dsv.su.se/test-
query/. This test-query is not as secure as described in
chapter 6 above, since a common password is used for all
voters. It was done in this way to avoid having to send an
individual login-id and password to all readers of this
document. Thus, the test-query can show most of the
functionality, but will have lower security.


8 Copyright and Disclaimer

The IETF takes no position regarding the validity
or scope of any intellectual property or other
rights that might be claimed to pertain to the
implementation or use of the technology described
in this document or the extent to which any
license under such rights might or might not be
available; neither does it represent that it has
made any effort to identify any such rights.
Information on the IETF's procedures with respect
to rights in standards-track and standards-related
documentation can be found in BCP-11. Copies of
claims of rights made available for publication
and any assurances of licenses to be made
available, or the result of an attempt made to
obtain a general license or permission for the use
of such proprietary rights by implementors or
users of this specification can be obtained from
the IETF Secretariat."

The IETF invites any interested party to bring to
its attention any copyrights, patents or patent
applications, or other proprietary rights which
may cover technology that may be required to
practice this standard. Please address the
information to the IETF Executive Director.

Copyright (C) The Internet Society (2000, 2001,
2002). All Rights Reserved.

This document and translations of it may be copied
and furnished to others, and derivative works that
comment on or otherwise explain it or assist in
its implementation may be prepared, copied,
published and distributed, in whole or in part,
without restriction of any kind, provided that the
above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified
in any way, such as by removing the copyright
notice or references to the Internet Society or
other Internet organizations, except as needed for
the purpose of developing Internet standards in
which case the procedures for copyrights defined
in the Internet Standards process must be
followed, or as required to translate it into
languages other than English.

The limited permissions granted above are
perpetual and will not be revoked by the Internet
Society or its successors or assigns.


9 Acknowledgments

Suggestions during the development of this memo has been
given by Harald Alvestrand, Bill Jansson, Larry Masinter,
Keith Moore and Henry Spencer.

10 References

Ref. Author, title IETF
status
---- ------------------------------------- -------
--
[1] J. Klensin: "Simple Mail Transfer Proposed
Protocol", RFC 2821, April 2001. Standard

[2] P. Resnick: "Internet Message Format" Proposed
STD 11, RFC 2822, April 2001. Standard

[3] M.R. Horton, R. Adams: "Standard for Not an
interchange of USENET messages", RFC official
1036, December 1987. IETF
standard,
but in
reality a
de-facto
standard
for Usenet
News

[4] N. Freed & N. Borenstein: Draft
"Multipurpose Internet Mail Standard,
Extensions (MIME) Part One: Format of elective
Internet Message Bodies." RFC 2045.
November 1996.

[5] N. Freed & N. Borenstein: Draft
"Multipurpose Internet Mail Standard,
Extensions (MIME) Part Two: Media elective
Types." RFC 2046. November 1996.

[6] H. Alvestrand: "Tags for the Proposed
Identification of Languages", RFC standard,
1766, February 1995. elective

[7] R. Fielding, J. Gettys, J. Mogul, H. Draft
Frystyk, T. Berners-Lee: Hypertext standard
Transfer Protocol -- HTTP/1.1, RFC
2616, June 1999.

[8] J. Palme: The Auto-Submitted, Work in
Supersedes and Expires Headers in progress
E-mail and Netnews, draft-ietf-
mailext-new-fields-14.txt, November
1998.

[9] J. Palme: The multipart/choices Work in
Content-Type. draft-palme-multipart- progress
choices-00.txt, December 2000.

[10] R. Troost, S. Dorner, K. Moore: Proposed
Communicating Presentation standard
Information in Internet Messages: the
Content-Disposition Header field, RFC
2183, August 1997.


11 Author's Address

Jacob Palme Phone: +46-763182595
Stockholm University/KTH
Skeppargatan 73 E-mail: jacobpalme@gmail.com
S-115 30 Stockholm,
Sweden

Appendix A:

Examples of two e-mail messages which only show agreement,
and which would not be needed with a voting facility:

---

From: "Bart Schaefer"
Date: Tue, 11 Nov 1997 13:17:38 -0800
Comments: In reply to Robert Elz
"Re: No comments in Message-ID/In-Reply-
To/References" (Nov 12, 7:23am)
To: Detailed Revision/Update of Message Standards

Subject: Re: No comments in Message-ID/In-Reply-
To/References
MIME-Version: 1.0
Status: U

I agree completely with Robert Elz's remarks in
<5814.879279791@munnari.OZ.AU>.

--
Bart Schaefer
Zanshin
http://www.well.com/user/barts
http://www.zanshin.com

---

To: Detailed Revision/Update of Message Standards

Subject: Re: No comments in Message-ID/In-Reply-
To/References
Mime-Version: 1.0
Date: Tue, 11 Nov 1997 13:28:50 -0800
From: John Beck
Status: U

schaefer> I agree completely with Robert Elz's remarks in
schaefer> <5814.879279791@munnari.OZ.AU>.

As do I.

-- John Beck, Internet Engineering group, SunSoft