Re: [rtcweb] Alternative decision process in RTCWeb

Ron <> Fri, 29 November 2013 06:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1508B1AE0EA; Thu, 28 Nov 2013 22:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oy-hWEvIuoqW; Thu, 28 Nov 2013 22:10:02 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by (Postfix) with ESMTP id C2DC71AE0CC; Thu, 28 Nov 2013 22:10:01 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 29 Nov 2013 16:39:57 +1030
Received: from localhost (localhost []) 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 ([]) by localhost (audi.shelbyville.oz []) (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 <>
To: Bernard Aboba <>
Message-ID: <20131129060936.GV3245@audi.shelbyville.oz>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <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)
Cc: IETF Discussion <>, Michael Richardson <>, "" <>, Ted Lemon <>, Eric Burger <>, Dave CROCKER <>, "" <>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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?