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
- 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