Re: [rtcweb] The Voting Process

Gaelle Martin-Cocher <> Thu, 28 November 2013 14:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FB671AD8D5 for <>; Thu, 28 Nov 2013 06:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k4QX-N7Hy-ZT for <>; Thu, 28 Nov 2013 06:11:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 05A181AD6BF for <>; Thu, 28 Nov 2013 06:11:43 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 28 Nov 2013 09:11:38 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 28 Nov 2013 09:11:38 -0500
Received: from ([fe80::fcd6:cc6c:9e0b:25bc]) by ([::1]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 09:11:37 -0500
From: Gaelle Martin-Cocher <>
To: Magnus Westerlund <>, John Leslie <>
Thread-Topic: [rtcweb] The Voting Process
Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo6w+CA///sJ7A=
Date: Thu, 28 Nov 2013 14:11:37 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <20131127175414.GA87911@verdi> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
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 14:11:52 -0000

Hi Magnus,

Is the proposal to reach consensus via a 3 steps approach disregarded?

-----Original Message-----
From: rtcweb [] On Behalf Of Magnus Westerlund
Sent: Thursday, November 28, 2013 5:22 AM
To: John Leslie
Subject: Re: [rtcweb] The Voting Process

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:

rtcweb mailing list
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.