Re: [rtcweb] Proposed Video Selection Process

Steve Donovan <srdonovan@usdonovans.com> Fri, 22 November 2013 14:23 UTC

Return-Path: <srdonovan@usdonovans.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 A86171ADF10 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 06:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level:
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 VyCV7hoLFd1W for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 06:23:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id D80A51AE142 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 06:23:23 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50758 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <srdonovan@usdonovans.com>) id 1VjrdU-0005HX-PA for rtcweb@ietf.org; Fri, 22 Nov 2013 06:23:13 -0800
Message-ID: <528F68CC.40106@usdonovans.com>
Date: Fri, 22 Nov 2013 08:23:08 -0600
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <F89641F6-BC91-4BF2-89CB-26F5C187A66A@apple.com> <528E7033.2090502@gmail.com>
In-Reply-To: <528E7033.2090502@gmail.com>
Content-Type: multipart/alternative; boundary="------------000409050107020200050403"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [rtcweb] 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: Fri, 22 Nov 2013 14:23:32 -0000

The conversation seems to have veered into an argument about the
alternatives and not the proposed selection process.  I'll attempt to
focus on the topic in the subject line.

I am personally uncomfortable with the process as proposed.  I am one of
those referred to as a "lurker" in previous emails.  This is my first
post to this mailing list.  I have, however, read hundreds/thousands of
emails sent to this list.  I have also signed the previous three rtcWEB
blue lists.  I have not participated in meetings via Jabber.

I do think it is very important for the WEBrtc ecosystem to have at
least one MTI video codec.  I am not an expert in video codecs.  I don't
care which codec is chosen but I do consider it very important that
there be at least one MTI codec. 

I do NOT think that inventing arbitrary criteria for determining if I am
eligible to vote is a good precedent to be setting in the IETF. 

I fully understand the desire to attempt to eliminate ballot-box
stuffing in this proposed process.  Especially after the rumors of
double humming during the hum/Jabber +1'ing in Vancouver.  Personally I
think it is a fools game to try to eliminate attempts to game the
system.  It is going to happen anytime there is as much passion tied to
the outcome as in this case.  Ballot box stuffing happens.  It happens
with humming -- witness the increase in meeting attendance for sessions
with important hums.  I happens with voting -- witness the problems
established entities/governments that have extensive experience with
running elections still have keeping elections free and fair.

I don't see the IETF, who has very little experience with voting, being
successful at running a free and fair vote.  I say this with utmost
respect for the IETF.  Much of that respect coming because it is built
on consensus, not voting.

How do I think the working group should move forward?  I see three
viable options:

1) A coin flip
2) Two modern MTI codes
3) MTI of h.261 plus a modern MTI codec

I like the coin flip options as it results in a lot less email from the
lobbyists.

Regards,

Steve

On 11/21/13 2:42 PM, Daniel-Constantin Mierla wrote:
> On 11/21/13 8:24 PM, David Singer wrote:
>> On Nov 21, 2013, at 10:26 , Peter Saint-Andre <stpeter@stpeter.im>; wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>>>
>>>> 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.
>>> I have the greatest respect for the chairs, but this is an engraved
>>> invitation for people to appeal whatever decision might be reached.
>>>
>>> More fundamentally: Voting? At the IETF?? Really?!?
>>>
>>> I sincerely hope we can figure out a better process…
>>>
>> Me too.
>>
>> For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a significant part of the population.  We don’t need just a mandate, we want the effect of an effective mandate.
> Same opinion here.
>
> IMO, it's very unlikely that only such voting will have proper 
> effectiveness and, more important, fairness. No matter 
> jabber/blue-sheets persons are allowed to vote or not, there was a lot 
> of activity on the mailing lists only from lobbyists. That said, it is 
> going to be a lot of influence from companies that bet on 'send many and 
> speak loud'. But there were many entities that preferred to speak with a 
> single and clear voice so far, not involving an army of email bots.
>
> Just dismissing everyone (people/companies/projects) that simply relied 
> on the usual 'consensus' policy, which doesn't require to step in front 
> unless the decision is likely to be what one doesn't want, does not look 
> fair at all. Many spent lot of time in actually doing work/implementing 
> webrtc specs so far.
>
> As highlighted before, the issue now is about selecting the voters. For 
> example, I see no reason not to allow anyone that was subscribed to any 
> webrtc mailing lists hosted by IETF and W3C - it is an indication of 
> interest more that many people that go at IEFT for touristic reasons. 
> Those that didn't actively participated in discussions so far on mailing 
> lists, they should eventually prove their involvement in other related 
> activities, with public references, such as:
>
> - implemented webrtc releated specs in an application or product
> - they participated to webrtc interop events
> - they presented on webrtc topic at some conferences out there
> - they wrote related IETF drafts
>
> Probably the list can continue with other activities ... but is clear 
> that the range of people interested in the topic is way larger. The 
> process of deciding who can vote might create a bigger issue than 
> deciding for vp8 or h264 (or other codec) with a flipping coin.
>
> Daniel
>