Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB671AD8D5 for ; Thu, 28 Nov 2013 06:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4QX-N7Hy-ZT for ; Thu, 28 Nov 2013 06:11:44 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 05A181AD6BF for ; Thu, 28 Nov 2013 06:11:43 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Nov 2013 09:11:38 -0500 Received: from XCT110CNC.rim.net (10.65.161.210) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 09:11:38 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT110CNC.rim.net ([::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: <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> In-Reply-To: <52971935.50408@ericsson.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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? Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Thursday, November 28, 2013 5:22 AM To: John Leslie Cc: rtcweb@ietf.org 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 = >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >> >> 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, ] = > http://en.wikipedia.org/wiki/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 cu= rrently 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 ahe= ad 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 bl= ue sheets. Thus, the workable approach was to let people to provide the poi= nter 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 conside= red active in the WG. Thus the ones that been to a meeting, IRL or electron= ically 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 poi= nter or not. I agree that it is not possible to challenge another persons eligibility pr= ior to the balloting having completed and the list of who voted becomes ava= ilable. > = > ] 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 winne= r. If one doesn't mark all the option then that can't be guaranteed. We wan= ted 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 th= e IVR process prevents the ranking below "no MTI" to be used to determine t= he 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 noti= ce the issue when ballot is submitted shall contact the balloting individua= l 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 b= allots 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. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.