Re: [rtcweb] Proposed Video Selection Process

Marc Abrams <marc@mocet.com> Sat, 23 November 2013 16:49 UTC

Return-Path: <marc@mocet.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 5E7991AE02E for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 08:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5qyp3NlGML0X for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 08:49:51 -0800 (PST)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCA1ADF90 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 08:49:50 -0800 (PST)
Received: by mail-pb0-f54.google.com with SMTP id un15so2928982pbc.41 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 08:49:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OR1icsFgf/lkAtaC5RkMkjRGO5JN36VNVSHy4ST2qmM=; b=LMX2BtzBVSOTAKC79gAH9hgtKPjsh8T3Fd47hd0UNHhfLCLq3BG1x13jYIBlA73cTK M6o/x3rrxCPIOIJGMM8kyXEOP831TLjDicDDCNmLB7wSV6lUHYtb2wnhFT3Ja1sIsNMd Yzsu067wEI3g6sl3Av+EjczOKeRmEYCFCL0EcjF8V6c16WITi45qyHSn8kk5N7zxh0kz Rn9HCRdaCTBfjqo9ZclxRHgQDk7VHpP1uDcu4Ji/q2ozrVJihHCzlTjKkWhXwvtSzW4M pZD1TAX9quv3ywAJcffwBSWyzubRcibxxmnHlBgFhYBrNskgAf80ht5tmfgZpPR4W676 L15w==
X-Gm-Message-State: ALoCoQlTLNUt8Ndoy0m3EVDD80kSp1pcjVzUa1wI9GotPovnNaATjA0iJ+7mKJe2fafPhXAHG+pf
X-Received: by 10.66.231.42 with SMTP id td10mr1992728pac.144.1385225383168; Sat, 23 Nov 2013 08:49:43 -0800 (PST)
Received: from [10.0.1.20] (cpe-76-90-18-6.socal.res.rr.com. [76.90.18.6]) by mx.google.com with ESMTPSA id m2sm61251805pbn.19.2013.11.23.08.49.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 08:49:42 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE3ADCC7-F82E-4D51-95BA-43FC664D131A"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Marc Abrams <marc@mocet.com>
In-Reply-To: <52906876.4000509@bbs.darktech.org>
Date: Sat, 23 Nov 2013 08:50:43 -0800
Message-Id: <32E15D8E-642B-40B9-BBA3-9D5353B4E969@mocet.com>
References: <528E39F4.4010706@ericsson.com> <52906876.4000509@bbs.darktech.org>
To: cowwoc <cowwoc@bbs.darktech.org>
X-Mailer: Apple Mail (2.1827)
Cc: rtcweb@ietf.org
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: Sat, 23 Nov 2013 16:49:54 -0000

Really great points about non-browsers and native APIs. 

As much as we want to live in our browsers, native app support on mobile devices are the best way to distribute, monetize and enable app discovery for marketing and sales. If we truly want to encourage mass adoption of WebRTC technologies, this has to be a priority. 

As to native APIs, it would be much better for non-browser development and support to not have to reinvent the wheel in likely slightly incompatible versions of homegrown APIs. A native API would minimize interoperability problems and accelerate adoption as well.

marc
________________
Marc Abrams
+1-949-873-0501
marc@mocet.com


On Nov 23, 2013, at 12:33 AM, cowwoc <cowwoc@bbs.darktech.org>; wrote:

> Hi,
> 
> Here is a condensed response to the past 200+ posts :)
> Instant run-off voting
> I don't think that voting will solve all of the problems mentioned below, but if all other options fail (which we're close to) then I'm in favor of going ahead with the proposed process.
> Whatever process we agree to should end with a binding decision at the end (as opposed to more endless debate).
> People objecting to the very idea of voting (versus making the decision on a technical merit) miss the fact that this is no longer a technical debate.
> We have already agreed that both VP8 and H.264 are technically "good enough". The only remaining differences are of a political and licensing in nature.
> Voting will not solve (legitimate) licensing/IPR issues
> For example, mandating H.264 as MTI won't help Debian because they cannot count license units.
> We should brainstorm on how to remove these show-stoppers for all stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST implement 2 out of 3" approach is an example of how this can be done.
> Who should participate
> Either we should include anyone who posted on WebRTC mailing lists (rtcweb, public-webrtc, public-media-capture) or we should be try to be more inclusive by including anyone who merely subscribed to said lists.
> As was suggested, publishing the full list of all voters along with their votes should remove any doubt of fraud. If we notice that 5000 voters came from the same company, we can legitimately question whether they are all active or whether they attempted to stuff the ballot.
> Removing voting options
> I think it is vital that we leave all options on the table (however silly some might think they are) and see where the chips drop.
> I understand that some people object to a long list of options, but I'd rather err on the side of inclusivity than censorship. :)
> Non-browsers are equally important
> Most of the debate on this mailing list have centered around what the browsers will do, but if you've attended the WebRTC World conference over the past couple of years you will have noticed that a great number of demos are based on native applications (even more so as mobile adoption increases). There is a very strong interest in using WebRTC outside of the browser and any decision we make here should reflect that reality.
> Endless debates aren't free
> One thing that was evident at the conference is that many of companies are "moving beyond the specification".
> The longer we debate these issues, the more likely we are to end up with a specification that simply documents the de-facto standard laid out by early adopters.
> We need a higher-level Native API that mirrors the Javascript API
> It's become evident that many companies in the conference are re-inventing the same wheel: namely, they are reimplementing features found in the Javascript API on top of the Native API.
> Imagine how many developer years could be saved if the Native API provided some of these higher-level constructs. This ties into my earlier point that "non-browsers are equally important" to take into consideration.
>     Thank you for the interesting conversation. It was nice meeting many of you at the conference! :)
> Gili
> On 21/11/2013 8:51 AM, 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,
>> 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