Re: Alternative decision process in RTCWeb

Dave Cridland <dave@cridland.net> Thu, 28 November 2013 12:17 UTC

Return-Path: <dave@cridland.net>
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 0A9711AE036 for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 04:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 lu5-hVGD8xR4 for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 04:17:40 -0800 (PST)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB701AE08D for <ietf@ietf.org>; Thu, 28 Nov 2013 04:17:40 -0800 (PST)
Received: by mail-oa0-f47.google.com with SMTP id k1so9020561oag.20 for <ietf@ietf.org>; Thu, 28 Nov 2013 04:17:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/DxTG7IBO1oP/cObPK8pFO5gLgOlHOPfbU7ZRkU6KE=; b=csLLcOUYqlWsr2aT/sGjKxH6m9WpbIRm79+nHFXwhAeE/BtouMuP03Da9KL4B6o+I8 LOYNOKUl2OB4QDyrGrTAuA9cWDJDEjEmHkL0xcNhtInpyD2w9/0wUWm60rUAfZYwJVl3 kLO0By1hqmd+yvsJZQIiZ9NadBA1VW9/MLObg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O/DxTG7IBO1oP/cObPK8pFO5gLgOlHOPfbU7ZRkU6KE=; b=g0lCZWZA/z/jEU8fXfABlA4da/b1lE84B03HHTlDTdCT2ie/BiXW76L2OE9EyFm0f8 Ka/6AfamXKljTjVbhbheYlCRLA6bkryiEztPIrtxOFCXY8qBmLle5B1y/AQ0V04EiCCa rVfw3Jvtr0F6cRT8FsI0VQy6eHkYrLePTLsH2Q/oBvYFwihuQ0FVWcbjPcyy0MEbWICG e1zcAEDPJ9xMz3Desv5pkrHOQikREuQo+F0tAvJ27cbxvs8wM4T8w7+d0+ExTvUI6JqH GzcB6kkHKCGolpjrKIJ6gSfHKacTOmmRhmmIuIxha6ORb91rBAjgce31maAJI0rRE6Lg N/2Q==
X-Gm-Message-State: ALoCoQmKichaysJf255EO5ZgTjPh4ySKuypwjFcphFR7iOwD9lwhpU31Wiyg9iiqd1lueH2+LtNK
MIME-Version: 1.0
X-Received: by 10.182.72.234 with SMTP id g10mr38396241obv.21.1385641059116; Thu, 28 Nov 2013 04:17:39 -0800 (PST)
Received: by 10.60.121.97 with HTTP; Thu, 28 Nov 2013 04:17:39 -0800 (PST)
In-Reply-To: <DDE4643D-62CD-4B12-B1BF-176A5AA4CED9@standardstrack.com>
References: <52970A36.5010503@ericsson.com> <529719D7.9020109@cisco.com> <CAKHUCzxjwMXzy6=9WdRPRRCunKsLm9JFuo6JavMtEC7Tbov8TQ@mail.gmail.com> <DDE4643D-62CD-4B12-B1BF-176A5AA4CED9@standardstrack.com>
Date: Thu, 28 Nov 2013 12:17:39 +0000
Message-ID: <CAKHUCzwf_1Kg0vvyKnC9yjsRSunvaRHrYEnPrfLdOsdFij4a7A@mail.gmail.com>
Subject: Re: Alternative decision process in RTCWeb
From: Dave Cridland <dave@cridland.net>
To: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/alternative; boundary="001a11c2e0641d786304ec3bb3de"
Cc: IETF Discussion <ietf@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: Thu, 28 Nov 2013 12:17:42 -0000

On Thu, Nov 28, 2013 at 11:29 AM, Eric Burger <eburger@standardstrack.com>wrote:

> More to the point, if the WG cannot come to IETF consensus, that itself is
> sufficient to let the IESG know the WG (a bunch of close experts) is not
> *READY* to select a single codec. If the WG is not *READY* to pick a single
> codec, neither is the IETF.
>
>
That's the point of my (1).

But in any case, much of the discussion is now centering around selecting
more complex choices, such as whether to implement any three of VP8,
Theora, and H.261, but only on Sundays in July (rain permitting).

My favourite exchange from this is
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09958.html by the
way.


> The proposal is DOA.
>
>
As someone merely following the debate rather than with a stake (or oar) in
it, that's my personal opinion too. I suspect a de-facto codec selection
will emerge within a year, and this will occur whether or not the IETF
mandates any particular option as de jure.

But I'm not involved, really, I'm only following along in my somewhat
obscure (but impressively titled) capacity of "XSF Future Jingle SIG
Chair". FWIW, the XSF formally gave up trying to pick an MTI video codec
some time back, *and* came to a parallel conclusion WRT audio too - both
decisions (XEP-0299 and XEP-0266) we'll be revisiting in the light of the
RTCWEB decisions. There was much excessive warmth in those discussions, too.


>
> BTW, per the rules, I am eligible to vote. Sigh.
>
>
That depends on whether the vote, or for that matter, the rules, are within
the jurisdiction of the working group, though.

Even assuming that is the case, it's not clear to me that there is a
consensus surrounding the voting rules - they've certainly yet to be
summarised in one place based on the discussion that has occurred so far.

There's so many points on which an appeal can be made, we'll all be spoilt
for choice.

Dave.