Re: [rtcweb] Alternative decision process in RTCWeb

cowwoc <cowwoc@bbs.darktech.org> Fri, 29 November 2013 15:55 UTC

Return-Path: <cowwoc@bbs.darktech.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 1CC0F1ADEA3 for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 07:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCVtx0c0sJx for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 07:55:28 -0800 (PST)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id E6B491AE002 for <rtcweb@ietf.org>; Fri, 29 Nov 2013 07:55:23 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id tp5so16048327ieb.22 for <rtcweb@ietf.org>; Fri, 29 Nov 2013 07:55:22 -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:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gRoEWRkekSR35LyXEKiIbl+TDatXx2s470ywEl2QO8U=; b=CiISa4xao2qhEB1j8Klz2Y89drnFVSL2M8SGJ4rS4BHZYaN6892fIguwP21W1w0o86 +OMTyO/tBh2cN0Pf+I/+uwLkpeZleXkWWta0OIN2SE+he2nOCFfuxQZB/0SEUslReyyO 7eUEVk+dpYmF1YCWziBNFtombWagaOuLM6naa7K/FPJwmjb5L8CTpKNeL1vRYONmiJro F4Wk1MiBJN2ucwRzB3z00PYZ50Y3YKKauEkmh46KO3cKJmixDnVshPpSEkQ+Alv3hvcj dMm7ri+nQJNTVqpwE/bV/UeS0cJ1f87PLEdkWRfMjm1QGr+cqaoshG8XzfLq4qnSpiFg 4bNQ==
X-Gm-Message-State: ALoCoQnYYId0uB2VKwZaPt4pBVAy7s0T1MKOrREqmkKX/JiFvto9gVgiW+Mk7p8shhWA4EuQywUW
X-Received: by 10.50.82.10 with SMTP id e10mr6844343igy.58.1385740522637; Fri, 29 Nov 2013 07:55:22 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p14sm50845121igr.7.2013.11.29.07.55.21 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 07:55:21 -0800 (PST)
Message-ID: <5298B8BB.70307@bbs.darktech.org>
Date: Fri, 29 Nov 2013 10:54:35 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
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> <529850A4.606@googlemail.com>
In-Reply-To: <529850A4.606@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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 15:55:31 -0000

I'm in favor of this approach, with a fallback to voting if that fails, 
with a fallback to "No MTI" if that fails.

Gili

On 29/11/2013 3:30 AM, Maik Merten wrote:
> I very much agree with Ron here. Given that both H.264 and VP8 seem to 
> not be universally deployable by all participants in all scenarios I 
> guess many will agree that reaching consensus on one of those may not 
> be realistic.
>
> So it appears that we need $fallback (to be later used in something 
> like "all entities MUST implement $fallback" or "all entities MUST 
> implement at least two of {H.264, VP8, $fallback}" etc.). As far as I 
> can see following codecs have been mentioned as possible candidates 
> for $fallback:
>
> H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance)
>
> I don't remember seeing an exploratory discussion to determine what 
> (if any) codecs are considered to have "acceptable risk" (this is 
> different from "no risk", which may not be achievable). However, it 
> may take some time for each participant to make their own risk 
> assessment. Thus I very much like Ron's proposal of starting 
> discussion with the codec with the lowest perceived IPR risk and 
> trying to move to higher performance levels until substantial 
> indication shows up that the next step brings "unacceptable risk".
>
>
> Maik
>
> Am 29.11.2013 07:09, schrieb Ron:
>> 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
>>
>>
>> _______________________________________________
>> 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