Re: [rtcweb] revisiting MTI

Gaelle Martin-Cocher <> Tue, 16 December 2014 19:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D7FC51A8727 for <>; Tue, 16 Dec 2014 11:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KuKFcinnMBH4 for <>; Tue, 16 Dec 2014 11:31:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 945151A8713 for <>; Tue, 16 Dec 2014 11:31:50 -0800 (PST)
Received: from (HELO ([]) by with ESMTP/TLS/AES128-SHA; 16 Dec 2014 14:31:44 -0500
Received: from ([fe80::fcd6:cc6c:9e0b:25bc]) by ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 14:31:43 -0500
From: Gaelle Martin-Cocher <>
To: Eric Rescorla <>, John Leslie <>
Thread-Topic: [rtcweb] revisiting MTI
Date: Tue, 16 Dec 2014 19:31:42 +0000
Message-ID: <>
References: <> <> <> <> <> <> <20141216150303.GT47023@verdi> <> <20141216152100.GU47023@verdi> <> <20141216162534.GV47023@verdi> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF3634AAXMB111CNCrimnet_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] revisiting MTI
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: Tue, 16 Dec 2014 19:31:54 -0000

I have little confidence that the choice between H265 and VP9 will be easier than it is today between VP8 and H264.
Are we going to multiply similarly performing codecs  going forward (in the spec or in practice) or be stuck with mandatory low performing codecs because we cannot make better decision?
Time frame for H265 / VP9  is up to two years from now
And possibly the timeframe for H.266/Dalaa is four years from now

This is one more drawback of the proposed text for MTI, not only it multiplies encoders and decoders to be supported but  can prevent the evolution of webrtc toward more advances codecs. (assuming we will not require 4 or 6 encoders and 4 or 6 decoders to be supported by every single endpoints. Two MTI seems largely enough, no?).


From: rtcweb [] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Subject: Re: [rtcweb] revisiting MTI

On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <<>> wrote:
Eric Rescorla <<>> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <<>> wrote:
> Needless to say, having WG consensus on the substance and letting the
> editor wordsmith the text is totally normal IETF process.

   In some cases, yes. IMHO, this is not one of them. YMMV...

Indeed it does, since I have *never* heard of such a case where
the editor had no discretion to change the text in purely editorial
ways (subject to WG consensus of course). Feel free to cite one
if you have one.

> I haven't heard anyone who was at HNL and in favor of the text on the
> slides object that Adam's text in the draft doesn't reflect those
> slides.

   Probably you haven't...

To the best of my knowledge it hasn't happened. Can you cite anyone
who has so objected.

> Besides, Eric isn't the WGC calling consensus.
> No, the chairs did here:
] From: Sean Turner <turners at<>>
] 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.

   Actually, as I read this more carefully, that isn't a consensus call.
Sean goes on to dismiss the objections he heard in the room:

He's addressing them. What exactly is the problem with this?

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

   Sean is specifically saying the "trigger" should be discussed

I don't read this this way at all, Rather he's saying that in the future we
can update the RFC. But yes, we can discuss the trigger on-list. Do you
have some substantive objection that wasn't raised in HNL and/or
hasn't been discussed to death here?

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

   This _is_ calling for consensus.

   But Sean omitted saying _what_ text; and agreed that the exact text
may not have been clear to those in the room.

Huh? The "proposed text" that was discussed in HNL is on the slide and
that's what's being referred to here. Adam edited text which is substantially
the same into the draft.

] If anyone has any other issues that they would like to raise please do
] by December 19th.

   (And folks have been doing so.)

   I have asked on-list for the exact text before raising my issues,
since my issues relate to the text, not the choosing to have two MTIs.

As I pointed out in my original message, that text is in Adam's draft.

Again, it's totally procedurally regular to have rough consensus on text in
the WG meeting and on the list and then have the editor edit in substantively
the same text to the draft. If you think there is some respect in which those
two blocks of text are not in fact the same, please point to it. Otherwise,
this is just dilatory.

> And this message clearly points to the slides above.

   I don't find it helpful to attack the people who raise issues. YMMV.

   But what EKR thinks really doesn't matter. He is not a WGC.

Ironic that you would complain about "attack"s in a thread where you
started out by attacking Adam Roach and here say "what EKR thinks
really doesn't matter"