Re: [rtcweb] Alternative decision process in RTCWeb
Ron <ron@debian.org> Fri, 29 November 2013 06:10 UTC
Return-Path: <ron@debian.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1508B1AE0EA; Thu, 28 Nov 2013 22:10:04 -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 oy-hWEvIuoqW; Thu, 28 Nov 2013 22:10:02 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC71AE0CC; Thu, 28 Nov 2013 22:10:01 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl6.internode.on.net with ESMTP; 29 Nov 2013 16:39:57 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D19C24F8F3; Fri, 29 Nov 2013 16:39:38 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sF3sA9YHnPVO; Fri, 29 Nov 2013 16:39:36 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BE9FB4F902; Fri, 29 Nov 2013 16:39:36 +1030 (CST)
Date: Fri, 29 Nov 2013 16:39:36 +1030
From: Ron <ron@debian.org>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
Message-ID: <20131129060936.GV3245@audi.shelbyville.oz>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Mon, 02 Dec 2013 08:09:00 -0800
Cc: IETF Discussion <ietf@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Eric Burger <eburger@standardstrack.com>, Dave CROCKER <dcrocker@bbiw.net>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2013 06:10:04 -0000
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
- Re: Alternative decision process in RTCWeb Jari Arkko
- Alternative decision process in RTCWeb Gonzalo Camarillo
- Re: Alternative decision process in RTCWeb Eliot Lear
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Dave Cridland
- A few thoughts on processes WAS (Re: Alternative … Gonzalo Camarillo
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Eliot Lear
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Eric Rescorla
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Ted Lemon
- Re: Alternative decision process in RTCWeb Sam Hartman
- Re: Alternative decision process in RTCWeb Eric Rescorla
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Cullen Jennings
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Ted Lemon
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Tim Bray
- Re: Alternative decision process in RTCWeb Yoav Nir
- Re: Alternative decision process in RTCWeb Michael Richardson
- Re: Alternative decision process in RTCWeb Ted Lemon
- RE: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Carsten Bormann
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Roberto Peon
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Stephan Wenger
- Re: Alternative decision process in RTCWeb Roger Jørgensen
- Re: Alternative decision process in RTCWeb Harald Alvestrand
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Joel M. Halpern
- Re: Alternative decision process in RTCWeb Bjoern Hoehrmann
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Ofer Inbar
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb cb.list6
- Re: Alternative decision process in RTCWeb Ted Hardie
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Scott O. Bradner
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Paul Hoffman
- Re: Alternative decision process in RTCWeb Ted Hardie
- Re: Alternative decision process in RTCWeb Avri Doria
- RE: [rtcweb] Alternative decision process in RTCW… DRAGE, Keith (Keith)
- Re: [rtcweb] Alternative decision process in RTCW… Mary Barnes
- Re: Alternative decision process in RTCWeb Cullen Jennings (fluffy)
- Re: [rtcweb] Alternative decision process in RTCW… Ron
- Re: Alternative decision process in RTCWeb cb.list6
- Daughter of CODEC (was Re: Alternative decision p… Eric Burger
- Re: Daughter of CODEC (was Re: Alternative decisi… cb.list6
- Re: Daughter of CODEC (was Re: Alternative decisi… Mary Barnes
- Re: Alternative decision process in RTCWeb Carsten Bormann
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Daughter of CODEC (was Re: Alternative decisi… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Pete Resnick
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Jari Arkko
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: Daughter of CODEC (was Re: Alternative decisi… Eric Burger
- Re: Alternative decision process in RTCWeb Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Martin Thomson
- Re: Alternative decision process in RTCWeb Ofer Inbar
- Re: [rtcweb] Alternative decision process in RTCW… Stephan Wenger
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Harald Alvestrand
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Eric Burger
- Re: [rtcweb] Alternative decision process in RTCW… Jim Gettys
- 0, 1, or many standards and their impact (or not) Eliot Lear
- Re: [rtcweb] Alternative decision process in RTCW… Hector Santos
- Re: 0, 1, or many standards and their impact (or … Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: Daughter of CODEC (was Re: Alternative decisi… Peter Saint-Andre
- Re: [rtcweb] Alternative decision process in RTCW… Jari Arkko
- Re: Daughter of CODEC (was Re: Alternative decisi… Gonzalo Camarillo
- Re: [rtcweb] Alternative decision process in RTCW… Eric Burger
- Re: Daughter of CODEC (was Re: Alternative decisi… Richard Barnes
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… David Singer
- Re: Daughter of CODEC (was Re: Alternative decisi… Cullen Jennings (fluffy)
- Re: A few thoughts on processes WAS (Re: Alternat… Eliot Lear
- Re: A few thoughts on processes WAS (Re: Alternat… Harald Alvestrand
- Re: A few thoughts on processes WAS (Re: Alternat… Dave Crocker
- Re: A few thoughts on processes WAS (Re: Alternat… Gonzalo Camarillo
- Re: A few thoughts on processes WAS (Re: Alternat… Spencer Dawkins at IETF
- Re: Daughter of CODEC (was Re: Alternative decisi… Timothy B. Terriberry