Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)

Eric Rescorla <ekr@rtfm.com> Thu, 21 November 2013 19:20 UTC

Return-Path: <ekr@rtfm.com>
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 683A11AE247 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0v6_En-UFU1G for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 703671AE05C for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id k14so195155wgh.11 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VaYkkfz47rsmoZno9HVOsCuIKtRb+wsBjmxAuch8GpQ=; b=UO0A67otL1mkXjdNHf8HF/2ev0JQi87CMw/7UI2o1Y5xPHUmcYL2cXyuqo9ikknutE f11iXrjz64AHStxbK5WN3n7a9VnN0ddNKUQn4SNmeU9IQb9ZQrJjEVRGQK1mX+ds4AmH Ly4KwDiy4o3MhAvYQ323CZ4dk2DsVK+o12YbxdXLwQZQXRnrebMfmZ5WQp2ERt0Bkad6 74WOALS2oU/epaHDGdh5pSD+b5g+dKjw7h7j04Vmn7IZuQX8Oyyjlvr3XWtB5zcAN4PB oum4o7J9REx0rQpX41+Vz6JWZvv0YLvDw13J/HnkGWTroUU/DptHCVtNuO3tuRWvhGnp NtbQ==
X-Gm-Message-State: ALoCoQkPHsEeBL3p4CaRwAyPg4jt8tHFtgxIr0DdEqJwVHRM2zX4nVrDO7g9QLAE/2Hk2tqPGaCn
X-Received: by 10.180.221.38 with SMTP id qb6mr7156472wic.8.1385061592185; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 11:19:12 -0800 (PST)
X-Originating-IP: [63.245.220.224]
In-Reply-To: <528E5AF7.5080403@alvestrand.no>
References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 21 Nov 2013 11:19:12 -0800
Message-ID: <CABcZeBNuxnXoLO+oWdWTfcnkM-577MBDP5WYmhQTuoBdGKwqLw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="001a1134d2da320f2c04ebb4c8d4"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection 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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2013 19:20:03 -0000

In order to forestall the inevitable voting nerd thread, allow me to
point to:

http://en.wikipedia.org/wiki/Arrow%27s_theorem

-Ekr



On Thu, Nov 21, 2013 at 11:11 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> Forking this thread, and leaving aside all consideration of whether the
> IETF should do voting, whether the electorate is the right electorate for
> the decision and so on:
>
> I wonder if Instant Runoff is the right choice for this situation.
> Instant Runoff means that when you don't get a majority for anything, you
> drop the lowest-ranked candidate and distribute the ballots that had this
> as their #1 across the other candidates.
>
> This has the property that in a polarized situation, compromises may get
> dropped out of the running before the alternatives that they might serve as
> a compromise between.
>
> In this case, I'd favour a Condorcet-compatible method, such as Schulze;
> it provides the guarantee that if a choice is preferred by a majority of
> the participants over every other choice, it will always be chosen.
>
> http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method
>
>
> On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
>
>> WG,
>>
>> The WebRTC ecosystem needs to avoid interoperability failure to grow
>> optimally.  The RTCWEB working group took on the task of establish Audio
>> and Video MTI codecs as part of meeting that need. We have not succeeded
>> in finishing that task for video using normal IETF process, but it is
>> still important.
>>
>> We (WG chairs) are proposing that the working group consent to a method
>> that will establish an MTI, even if the MTI chosen does not have rough
>> consensus.  We would far prefer the normal IETF process, but it is not
>> proving workable for this selection.
>>
>> We initially proposed a method from RFC 3929 (external review team), but
>> now believe that the working group would not consent to that method.
>> Instead we are proposing a method that leaves the decision in the hands
>> of the WG.
>> google.com
>> 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.
>>
>> The steps in the proposed process are these (1-5):
>>
>> 1) Establish a final list of alternatives, based on the WG's input to
>> Gonzalo's email on the 13th of November that requires any additions to
>> provided by end of the 27th of November.
>>
>> 2) Establish those eligible to vote.  Any participant in the
>> working group process either electronically or in-person as of yesterday
>> (20th of November). 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
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> 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.
>>
>> 5) The selection is recorded in the drafts.
>>
>>
>> --- End of Process Proposal ---
>>
>> This message initiates the first step in the working group consensus
>> call process. Namely a one week comment and discussion period for the
>> above process.
>>
>> After that week the WG chairs will update, if necessary, the proposal.
>> Then using the normal IETF process in which anyone is eligible to
>> participate, the chairs will ask for (rough) consensus to adopt this
>> extraordinary process to achieve the working group's stated goals.  The
>> end date for this consensus call is 2-weeks after the announcement of
>> the consensus call.
>>
>> If the working group does not consent to using this extraordinary
>> process, we will hold a consensus call if the WG can accept
>> "WebRTC entities MUST support at least one of H.264 or VP8.".
>>
>> If there is failure to establish consensus even for this statement, the
>> chairs conclude that the WG can't establish what to say about a MTI
>> video codec.
>>
>> The WG Chairs
>>
>> Magnus Westerlund
>> Cullen Jennings
>> Ted Hardie
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>