Re: [rtcweb] confirming sense of the room: mti codec

Harald Alvestrand <harald@alvestrand.no> Mon, 08 December 2014 16:08 UTC

Return-Path: <harald@alvestrand.no>
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 0FC271A9143 for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 08:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 V-6AHYYv3ZjC for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 08:08:06 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C1C221A923D for <rtcweb@ietf.org>; Mon, 8 Dec 2014 08:05:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 142937C365B for <rtcweb@ietf.org>; Mon, 8 Dec 2014 17:05:50 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC-Bg5D5JfNn for <rtcweb@ietf.org>; Mon, 8 Dec 2014 17:05:48 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:603b:7836:2531:29df] (unknown [IPv6:2001:470:de0a:27:603b:7836:2531:29df]) by mork.alvestrand.no (Postfix) with ESMTPSA id DE4DB7C3658 for <rtcweb@ietf.org>; Mon, 8 Dec 2014 17:05:47 +0100 (CET)
Message-ID: <5485CC5B.2030104@alvestrand.no>
Date: Mon, 08 Dec 2014 17:05:47 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com>
In-Reply-To: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4_NtnOY2zXS7hp51kOmui_nM2lA
Subject: Re: [rtcweb] confirming sense of the room: mti codec
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: Mon, 08 Dec 2014 16:08:08 -0000

Since others who were present in the room are repeating their position
on the list, I'll do so too.

I support the rough consensus as presented by the chair.



Den 05. des. 2014 14:36, skrev Sean Turner:
> All,
> 
> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise."  The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]).
> 
> This message serves to confirm the sense of the room.
> 
> In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger:
> 
> 1) IPR:
> 
> Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations.
> 
> Response:  IPR concerns on this topic are well known.  There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation.  The sense of the room was still that adopting the compromise text was appropriate.
> 
> 2) Time:
> 
> 2.1) Time to consider decision:
> 
> Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person.
> 
> Response:  Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs.    More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.
> 
> 2.2) Time to consider text:
> 
> Objection: The proposed text [2] is too new to be considered.
> 
> Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago.  All decisions are confirmed on list so there will be ample time to discuss the proposal.
> 
> 3) Trigger:
> 
> Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification.
> 
> Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time.
> 
> 
> After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.  In keeping with IETF process, I am confirming this consensus call on the list.
> 
> If anyone has any other issues that they would like to raise please do by December 19th.
> 
> Cheers,
> spt (as chair)
> 
> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
> [3] The one that begins with "If compelling evidence ..."
> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>