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

I support the rough consensus reached in the meeting. I support those
willing to accept this compromise, and agree with the chair declaring that
was the dominant sense of the room. I also support those unable to
implement this compromise at this time for their stated reasons, in the
sense that I understand their reasons for their reasonable positions.
Despite the potential future importance of the current minority positions,
I think proceeding with this compromise propels WebRTC forward on an
important issue, because no other proposal has come remotely close to
achieving even rough consensus.

To reiterate another point from the meeting, there are technical
advantages to supporting multiple codecs. Dynamic discovery of local
capabilities, negotiation of remote capabilities, understanding how
different error resilience mechanisms can work (or not) with different
codecs, faster adoption of new (non-mandatory) codecs, easier path to
deprecating old (mandatory) codecs, etc. All those legs never get
exercised effectively in single-codec implementations, leaving land mines
in browsers, apps, services and sometimes even specs. They become easier
or free once the groundwork is laid for multiple codecs. While some have
argued against that extra complexity, I see it as essential for any
important standard.

Mo

On 12/5/14, 8:36 AM, Sean Turner <turners@ieca.com> wrote:

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