[rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives )

Emil Ivov <emcho@jitsi.org> Thu, 28 November 2013 21:03 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 882641ADF9B for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 13:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 14LHIqKiB3YC for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 13:03:42 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2E3511ADA5D for <rtcweb@ietf.org>; Thu, 28 Nov 2013 13:03:41 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so6754731wgh.17 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 13:03:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ro5KfhwkDlrlLlQEwsW6Xkw0YSwBp/rBOITwxPG9Eg=; b=m3xRQIG8u/WKj7Rm7NpJyDgqHzWwxtMPPf2B69o3Fn6rALe/jKoTIaC6Q9jZ+EdGGA KuUIn9IO4/Af4YXLwJKeBtApqdRrUoB4zJGq1wsMAJB8n1fSrTvnIyHQRXR4+WQ2xPBQ W41Z7tbrKQYJhgYOScDsr0h/KDX3RrP9KLXcAaFA2AwrJ3yZKYvsBB0BSP8wjN49IolF LqRckLjlp/u0mHCZTxOhYJbCnmWTQPDhO+bQa44yydSCSiI4AZE3L3PrJ65vd6EJhTDY O/8+xrycZUYNj2cIXNQbDqlS6orwEXr06PwrkQFGPwhyOV7AQ/dq+GbAD3ZONFuC4TBV TLTQ==
X-Gm-Message-State: ALoCoQk58cj5j//0WJWKBVSQBk8NKgCU99+IiH/AJeKCRst4p9jL/z1ulIw6L8M/rHOrOCK3eDBq
X-Received: by with SMTP id m12mr4087104wiw.9.1385672620389; Thu, 28 Nov 2013 13:03:40 -0800 (PST)
Received: from camionet.local (neu67-4-88-160-65-79.fbx.proxad.net. []) by mx.google.com with ESMTPSA id b7sm85603409wiz.8.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 13:03:39 -0800 (PST)
Message-ID: <5297AFA8.5000107@jitsi.org>
Date: Thu, 28 Nov 2013 22:03:36 +0100
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: cowwoc <cowwoc@bbs.darktech.org>
References: <CEBBC7E7.1F4ED%mzanaty@cisco.com> <529680EF.4010908@jitsi.org> <5296BA5E.20801@bbs.darktech.org>
In-Reply-To: <5296BA5E.20801@bbs.darktech.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives )
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, 28 Nov 2013 21:03:44 -0000

On 28.11.13, 04:37, cowwoc wrote:
> I've heard objections along the lines of "IETF does not vote. We reach
> consensus by evaluating the technical merits of each argument and choose
> the one with the least number of objections".

Note that these are not just a matter of ideology there are very 
practical reasons why voting can't be properly implemented here.

More on that below.

> My counter-argument is that this isn't a technical question

Then there is NO reason for it to be answered by the IETF.

> (we've
> reached consensus that both VP8 and H.264 are "good enough" from a
> technical point of view). This is a legal and political question.

Exactly the kind of questions that the IETF does NOT handle.

>> I haven't seen anyone explaining how any possible constituency would
>> be defended
> That is a legitimate concern, but I believe that with additional
> discussion we'll be able to reach a consensus on it.

No we won't. We can't. Determining constituency is a very laborious 
process that should have been completed while setting up the body that 
will be taking the decision. To be more specific, it should in the very 
least be in our charter.

It has to be clear in advance that voting is a possible outcome of all 
discussions. It has to be clear who will be allowed to vote and, just as 
importantly, who won't be. A good practice would be to then contact 
potentially interested parties and inform them of the process and voting 
conditions so that they can choose to get involved and make sure they 
satisfy those conditions.

The rules that are currently being presented are EXPLICITLY PREVENTING 
people from getting involved in the process and becoming a part of the 
vote from now on. This is such a glaring deficiency that I am amazed we 
are still discussing the option.

The rules that have been presented basically sound like: "here are the 
people that we think will produce the result we are looking for"

Now, I would never assume that our chairs would attempt to game a 
process that they are proposing to us. I am simply convinced the 
pressure of choosing an MTI has made them overlook the problems.

>> You seem to assume that rough consensus necessarily lies somewhere. It
>> doesn't. Sometimes people agree to disagree.
> Anyone who feels this way should feel free to vote for "No MTI".

Voting "No MTI" is a very different position than not agreeing with a vote.

>> What if 30% objected to voting as a third choice?
> I suspect that if a substantial number of people vote for "No MTI" then
> it would warrant further investigation. I can't comment on what the
> actual threshold should be.

No one could. Not here.

>> Or it may be game theory in action. It's an entirely new land where
>> the IETF has not ventured before. Doing so now cannot work! A vote in
>> the IETF is only a reason to contest the results forever and discredit
>> the work of this group.
> I don't agree. Giving up on MTI because of we have multiple good options
> and a very polarized community would be like throwing out the baby with
> the bathwater.

I don't necessarily agree with that but if people think an MTI is of 
utmost importance and a vote is the only way to get it, they can then 
simply achieve that in any of the multiple bodies that allow for this 
(e.g. W3C) or simply establish a new one that will.