Re: [rtcweb] Alternative decision process in RTCWeb

Basil Mohamed Gohar <basilgohar@librevideo.org> Fri, 29 November 2013 20:41 UTC

Return-Path: <basilgohar@librevideo.org>
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 261B31ADDAC for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 12:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XRVKL9TsDzrW for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 12:41:38 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA31ADBCA for <rtcweb@ietf.org>; Fri, 29 Nov 2013 12:41:37 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id D7B4265A278 for <rtcweb@ietf.org>; Fri, 29 Nov 2013 15:41:35 -0500 (EST)
Message-ID: <5298FBF4.6060909@librevideo.org>
Date: Fri, 29 Nov 2013 15:41:24 -0500
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <D4D5920A-E041-42E8-BB1C-1CB24FBEE3F4@nominum.com> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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, 29 Nov 2013 20:41:40 -0000

On 11/29/2013 01:09 AM, Ron wrote:
> On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
>>> On Nov 28, 2013, at 2:27 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> That tells me that the participants are not willing to live with losing and
>>> move on, and so no voting process will work either.
>>
>> [BA] The participants aren't willing to live with losing for business or
>> legal reasons that aren't within the jurisdiction of an IETF WG.  As an
>> example,  would an open source product that requires source code to be
>> provided without a license fee put that aside because IETF RTCWEB has agreed
>> upon H.264 as MTI?  Similarly, would a vendor who is concerned about
>> potential liability from incorporating VP8 put that concern aside because the
>> IETF RTCWEB WG has decided to make VP8 MTI?  
> 
> I think EKR said this more succinctly with:
> 
>  "it's important to understand that in in this case, many people more
>   don't want X than do want Y."
> 
> And I think you both have clearly identified the problem, and why voting
> is clearly not a solution to it.
> 
> 
> The blocking issue is that many people have valid reasons why they _can't_
> deploy one or more of the possible choices.  You can't possibly solve that
> by taking a poll of what the majority of people would _prefer_, ignoring
> all other people's blocking constraints.
> 
> 
> However I think we can still resolve this by following normal consensus
> procedures, and walking our way up from the least troublesome options to
> the most, and seeing at what point consensus actually breaks down.
> 
> 
>  1. Do we want an MTI codec?
> 
>    It's generally accepted there is consensus the answer to this is Yes.
>    We also have a list of codecs that we could possibly choose from.
>    It also seems generally accepted that IPR trouble is the least
>    negotiable  problem that is at the heart of many objections.
> 
>  So let's start where that problem is the smallest, at the very bottom:
> 
> 
>  2. Can anybody show a sustainable objection for why we _can't_ use H.261.
> 
>    If they can, we're probably doomed.  If they can't we have an initial
>    choice for MTI.
> 
> 
>  3. Can anybody show a sustainable objection for why <alternative>
>     can't replace H.261 as the MTI codec?
> 
>    If they can, lather rinse repeat through the other alternatives.
>    If they can't, we have a new baseline to ask this question of
>    for the remaining alternatives.
> 
> 
> Yes, this may take some time (but surely less than we've already spent),
> but it clearly separates the question of what people _can't_ do, from
> what they would prefer to do if they had their druthers.
> 
> We probably won't get the best possible codec as the MTI fallback,
> but we probably will get a decision that isn't fundamentally doomed.
> And that's fine, because people will still get their preferred codec
> through runtime negotiation if they use an implementation which does
> accept the risk of supporting it - and the safe interop fallback if
> it doesn't.
> 
> 
> Why would this one simple procedure not work to resolve the deadlock?
> 
>   Ron

This is as good or better than anything else I've seen mentioned so far.
 Definitely a +1 from me, not that we're voting or anything...;)


-- 
Libre Video
http://librevideo.org