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 >
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: [rtcweb] Alternative decision process in RTCW… Eliot Lear
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: [rtcweb] Alternative decision process in RTCW… DRAGE, Keith (Keith)
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Ron
- Re: [rtcweb] Alternative decision process in RTCW… Michael Richardson
- Re: [rtcweb] Alternative decision process in RTCW… Maik Merten
- Re: [rtcweb] Alternative decision process in RTCW… Roger Jørgensen
- Re: [rtcweb] Alternative decision process in RTCW… Roberto Peon
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Leon Geyser
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Mary Barnes
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Martin Thomson
- Re: [rtcweb] Alternative decision process in RTCW… Silvia Pfeiffer
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Stephan Wenger
- Re: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Basil Mohamed Gohar
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Max Jonas Werner
- Re: [rtcweb] Alternative decision process in RTCW… John Leslie
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… cowwoc
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Richard Shockey
- Re: [rtcweb] Alternative decision process in RTCW… David Singer
- Re: [rtcweb] Alternative decision process in RTCW… Maik Merten
- Re: [rtcweb] Alternative decision process in RTCW… Harald Alvestrand
- Re: [rtcweb] Alternative decision process in RTCW… Silvia Pfeiffer
- Re: [rtcweb] Alternative decision process in RTCW… Randell Jesup