Re: [rtcweb] Alternative decision process in RTCWeb

Leon Geyser <lgeyser@gmail.com> Fri, 29 November 2013 18:01 UTC

Return-Path: <lgeyser@gmail.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 B26D61AD6C1 for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 10:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qeKteKf8iShZ for <rtcweb@ietfa.amsl.com>; Fri, 29 Nov 2013 10:01:48 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AC0051ACCFC for <rtcweb@ietf.org>; Fri, 29 Nov 2013 10:01:47 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so7149904lab.32 for <rtcweb@ietf.org>; Fri, 29 Nov 2013 10:01:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RZgRZsAHoAJv/Z4AWdrBgm8CzDUsHyhi6ww7OWJzD4A=; b=aW8dvrswgODk7zw1w3Lj7hiF1xM4v07LUP6otAtHYRrUqVsE3hvj8QCGwRuaNLjK66 QSQV0jvBjTGMpvhCzBFwPA4L1sovO94w6Ssq4NCyigRrAnIG8VW377p6Udw6cpnF8sir jj2qEHUkRbxS84YTLgP6FYbrAs7PgTwAhfEURVh+g/r6epGySxph30SXTFitdJViV9kA jmvM1QLefnqB/XNgKtbKGj9h3ZfZ5sqHBYy8R3wqHBTJYXPgJgpx3Lz/2+Rqy7KfXtRV 9d1opBHr3tYVrQSwr2O5mKh5R4rtLVfbw1ZDpxmotN0ftUUMYASgsrNuGqMPDTlkoPIm mj2w==
MIME-Version: 1.0
X-Received: by 10.112.154.129 with SMTP id vo1mr2120027lbb.31.1385748105770; Fri, 29 Nov 2013 10:01:45 -0800 (PST)
Received: by 10.114.28.7 with HTTP; Fri, 29 Nov 2013 10:01:45 -0800 (PST)
In-Reply-To: <5298B8BB.70307@bbs.darktech.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> <5298B8BB.70307@bbs.darktech.org>
Date: Fri, 29 Nov 2013 20:01:45 +0200
Message-ID: <CAGgHUiR5x+GDUyyUA=KwuhbNif4eEBos4dvuhxEd9p0s2FYn+A@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=089e0115fb0897bb5e04ec549f95
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 18:01:50 -0000

I also agree what Ron said.


On 29 November 2013 17:54, cowwoc <cowwoc@bbs.darktech.org> wrote:

>
> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>