Re: [rtcweb] The Voting Process

Magnus Westerlund <> Thu, 28 November 2013 10:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D8E0B1ADF34 for <>; Thu, 28 Nov 2013 02:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hi45Sx68giET for <>; Thu, 28 Nov 2013 02:21:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7CFA81ACCE5 for <>; Thu, 28 Nov 2013 02:21:43 -0800 (PST)
X-AuditID: c1b4fb32-b7f388e0000057e0-9b-52971935ab7b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 65.AA.22496.53917925; Thu, 28 Nov 2013 11:21:42 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 11:21:41 +0100
Message-ID: <>
Date: Thu, 28 Nov 2013 11:21:41 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: John Leslie <>
References: <> <> <> <> <> <> <> <20131127175414.GA87911@verdi>
In-Reply-To: <20131127175414.GA87911@verdi>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvra6Z5PQgg6WPmSzeXzjPaLH2Xzu7 A5PHkiU/mTyOzT3MHMAUxWWTkpqTWZZapG+XwJXxbvpCxoIJ1hWvznxjaWC8qNfFyMkhIWAi saLhOBuELSZx4d56IJuLQ0jgBKPExZ09LCAJIYHljBJLWotBbF4BTYk3DxYwg9gsAqoSyzoP M4HYbAIWEjd/NIINEhUIlrjau44Zol5Q4uTMJ2BzRATkJH6dfcAIYjMLqEvcWXyOHcQWFpCX +LHqLQvE4jdMEqsO7gZLcApoS9y4cwQowQF0nbhET2MQRK+exJSrLVBz5CWat85mhrhTW6Kh qYN1AqPQLCSrZyFpmYWkZQEj8ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMBwPrjl t9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6BGg465ypi63 2W1NwVEHt/C1azcsd91xLyy5XJi/IkDNmOXLm3bHxT8zN+/Zu2qLmoJ362aNqxMbOb35ihjf 9avuvfS18IrzXs79Sh+7EvaYaYeu2PZYdQYr620Bib1PS06vlEv9oPVn0cWgV/9jyp3zfi5d 0tnAviblsLu8i9Wj6btPbHL/ocRSnJFoqMVcVJwIACNWQ7w1AgAA
Cc: "" <>
Subject: Re: [rtcweb] The Voting Process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Nov 2013 10:21:46 -0000

Hi John,

On 2013-11-27 18:54, John Leslie wrote:
> Magnus Westerlund <> wrote:
>> For the proposed voting process see our previous message
>> As I stated, we chairs will need to update this based on the discussion.
>    I gather the WGCs intend to update that tomorrow.
>    While I would _much_ prefer not to mix discussion of the process
> with discussion of the alternatives, there are some really serious
> problems with this proposal.
>    First:
> ] 
> ] The method we propose is based on Instant-runoff voting,
> ], with the
> ] understanding that the choice will be the winner according to the
> ] Instant-runoff voting process.
>    Fail!
>    A reference to wikipedia is completely unstable unless it refers
> to the webpage retrieved at a particular time.

Yes, we will update our proposal to reference a particular date. The one
currently available.

>    It is the _intent_ of Wikipedia that the webpage may be modified
> at any time by any person: thus people retrieving the page on
> different days may receive different text. Those differences may be
> obvious or they may be subtle.
>    Second:
> ] 
> ] 2) Establish those eligible to vote.
>    What follows doesn't do that. It instead establishes rules for
> determining at some later time _whether_ an individual is eligible.

Yes, and the reason is that we realized what amount of work it would be
to gather a list of all that would be eligible in an list and publish
that ahead of time. Including the failure of the jabber log to capture
JIDs and no mapping to Full name and email address. The later problem
also exist for blue sheets. Thus, the workable approach was to let
people to provide the pointer that prove their eligibility.

> ] Any participant in the working group process either electronically
> ] or in-person as of yesterday (20th of November).
>    (That's where Magnus broke the sentence. Don't blame me...)
>    I merely raise the question of whether the process Magnus outlined
> is likely to match that goal.
> ] Who has participated in the Working group process will be anyone
> ] that can be identified from:
> ] - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
> ]   an interim meeting since the WG's creation.
> ] - posting of at least one email to the RTCWEB mailing list
>    Obviously missing from this list is persons subscribed to the
> mailing-list during some period. Those would ordinarily be considered
> participants.

Still our proposal in the updated version will be participants that
considered active in the WG. Thus the ones that been to a meeting, IRL
or electronically in the jabber room, or have sent an email to the list.

> ] The voter must at time of voting prove their eligibility, by pointing
> ] to the mail archive or a particular blue sheet/meeting. Please verify
> ] your own eligibility.
>    "Voter" is vague here. I take it to mean any person sending a ballot.

Yes, the balloting individual.

>    Thus there is no way of challenging a right to vote before the
> ballot itself is opened. I believe that is unheard-of.

The point was to have clear cut criteria for who are eligible.

>    It is, IMHO, strange to have no list of eligible voters to enable
> challenging eligibility (or absence from the list) before a vote is
> cast.

You as an individual can already now verify that you can provide such a
pointer or not.

I agree that it is not possible to challenge another persons eligibility
prior to the balloting having completed and the list of who voted
becomes available.

> ] 3) Start the the voting period. Those eligible and willing to vote send
> ] their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
> ] within two weeks using email. The vote collector will check when
> ] receiving a ballot the that the voter is eligible and send a
> ] confirmation email on receiving the ballot. During the balloting period
> ] the vote collector will keep all ballots secret.
>    (Just to prove I'm not leaving anything out.)
> ] Balloting:
> ] - The voter MUST rank ALL alternatives in their ballot from the most
> ]   preferred, marked with rank 1, the second most with 2, all the way
> ]   to the least preferred marked with rank N.
>    This is very unusual in Instant Runoff. There are always choices
> that a voter would vote _against_ regardless of the alternatives.
> This requires that a voter may be counted as in favor of something
> s/he completely opposes.

My understanding this was one of the few options in Instant Runoff
voting. We have selected full ranked to ensure that the voting will
provide a winner. If one doesn't mark all the option then that can't be
guaranteed. We wanted a voting process that would yield a winner.

I would note that No MTI at least can be used to indicate the options
that the balloter considered better or worse than no MTI. Although
nothing in the IVR process prevents the ranking below "no MTI" to be
used to determine the outcome of the voting.

>    (Further, it leaves open the "or else" question: what happens if
> a ballot doesn't exactly match that requirement?)

Then we propose the ballot will be discarded. The vote collector if he
notice the issue when ballot is submitted shall contact the balloting
individual and notify them of the issue. If not corrected ballot is
available by end of balloting period then it will be discarded.

> ] 4) When the voting period is over the ballot collector will publish the
> ] results as well as all ballots, including the voters name to the RTCWEB
> ] WG mailing list. This enables all voting individuals to verify that
> ] their ballot is unmodified. And allows anyone to verify the result of
> ] the vote.
>    Thus every detail of preference becomes public. Inevitably there will
> be some persons who are nervous about publishing so much detail. (I
> don't mean to imply that employers _would_ punish employees, merely
> that employees could understandably be nervous.)

Yes, we understand that as a potential issue. However, without making
the ballots public we don't see how we reasonably can ensure the voting
is done correctly and in a verifiable way.

> ] 5) The selection is recorded in the drafts.
>    Even when we get that wikipedia page "retrieved at a particular time,"
> it will contain half a dozen different rules for how the counting
> proceeds. I strongly recommend extracting the actual rules the WGCs
> intend to follow on this list (which will be archival).
>    Further, some person needs to be designated to interpret the rules
> during counting.

Noted, we chairs propose the vote collector will be arbiter. And the
normal IETF venues of appeal will be available for the arbiter's decision.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: