Re: [rtcweb] Alternative decision process in RTCWeb

cowwoc <> Thu, 28 November 2013 17:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 460311ADED5 for <>; Thu, 28 Nov 2013 09:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z4wUynrUfncL for <>; Thu, 28 Nov 2013 09:56:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A7CCC1ACCE6 for <>; Thu, 28 Nov 2013 09:56:05 -0800 (PST)
Received: by with SMTP id tp5so14715698ieb.11 for <>; Thu, 28 Nov 2013 09:56:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0VphmmRkNniuiF9AfTlrs7YwZCQ0ig3dkK3Bj1yNlj4=; b=ESDbYjhhBfToI8s86Szll+38bYEoaZ5qaK1P55CxJkSBGwQlcfMFtcTrmrDi2jvCL+ F+Z2MH6cJ6p0BRCFuiohBeUuglgMmKHwd8sU9E8H5KvgUrds6JX6TsKx6I9tPRk+9VZf fCME7QPRE5G5YUylH2egq+a9ET57YcuF+/G7c+dzr0rPiqbNRA6mWENjmxUullMYteXO 0zMkpcupstX3GRpxvNAH3mjNvljoCXnbyngIGuGntTu9A6rJrFVhFxDNyhJFo2NIyu5+ hrsOuOAWIOeZhgBjlB/M1jbNPywBtVqsghB/LD7RVnqNKLuS9ct9TjaPBo0MLSzT09h/ s4sA==
X-Gm-Message-State: ALoCoQkA2ZukNvMft4dV43D6NqVN5/g6QILK30QggM6qTAZGfYYnOsHysEZzb24xwjhI/79FIzdX
X-Received: by with SMTP id c6mr2903963igl.47.1385661364711; Thu, 28 Nov 2013 09:56:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w4sm45936446igb.5.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 09:56:03 -0800 (PST)
Message-ID: <>
Date: Thu, 28 Nov 2013 12:55:17 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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 17:56:07 -0000

On 28/11/2013 10:34 AM, Ted Lemon wrote:
> On Nov 28, 2013, at 8:52 AM, Eliot Lear <> wrote:
>> While I appreciate the difficult position the chairs are in, I don't
>> agree with the approach and I believe it is inappropriate for the
>> working group to make such a decision.  Working groups don't vote.  Want
>> to change that process?  Better gain IETF consensus first.  And I will
>> argue against any such attempt.  There are plenty of other standards
>> bodies that do vote.  Go to one of them if that's what you want.
> One of the things to talk about here is the issue of voting versus a coin toss.   The advantage of a coin toss is that nobody can say it was gamed, because it's random—there is no process to blame if it doesn't go your way.   Voting, however, is somewhat predictable, and can be gamed.
> So the concern is that if the working group has consensus to vote, it's probably because interested parties have some reason to believe the vote will go their way.   They may be horribly mistaken, or they may be correct—that isn't the point.   The point is that they aren't actually okay with the outcome not going their way.
> So if the working group is willing to agree to a vote, and unwilling to agree to a coin toss, that says something _very important_ about the status of consensus in the working group.

The list we are preparing to vote on is an all-inclusive list. If you 
feel that a coin flip is a better option, you're going to need to 
compile an "all options being equal" list first.

If it's any consolation, I believe the fact that voting records will be 
open to the public (who voted and for what) will act to reduce gaming or 
at least enable us to detect it after-the-fact.

Which brings up the question: will the vote results be binding? Or will 
they act as a strong recommendation for a follow-up consensus call? :)