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

Eric Rescorla <> Thu, 21 November 2013 19:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 683A11AE247 for <>; Thu, 21 Nov 2013 11:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0v6_En-UFU1G for <>; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 703671AE05C for <>; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: by with SMTP id k14so195155wgh.11 for <>; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id qb6mr7156472wic.8.1385061592185; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 21 Nov 2013 11:19:12 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Thu, 21 Nov 2013 11:19:12 -0800
Message-ID: <>
To: Harald Alvestrand <>
Content-Type: multipart/alternative; boundary=001a1134d2da320f2c04ebb4c8d4
Cc: "" <>
Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection 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, 21 Nov 2013 19:20:03 -0000

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


On Thu, Nov 21, 2013 at 11:11 AM, Harald Alvestrand <>wrote;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.
> 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.
>> 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.
>> 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 mailing list