The abstract does a wonderful job of explaining what this draft is about:
This specification provides the requirements and considerations for
WebRTC applications to send and receive video across a network. It
specifies the video processing that is required, as well as video
codecs and their parameters.
As far as where you should point your fingers:
- Sean Turner is the document shepherd.
- Alissa Cooper is the responsible Area Director.
2. Review and Consensus
I’d characterize discussions about this draft as a lengthy, lively, and spirited and that’s putting it mildly, but I also think if Chuck were representative of this then this meme would sum it up:http://cdn.meme.am/instances/500x/58865172.jpg. There has easily been in excess of 1,000 email messages about this draft and this draft has been discussed at many f2f meetings (IETF 81, 82, 85, 86, and 88) before the WG consciously decided to take an entire year off from discussing it before re-engaging around the IETF 91 timeframe.
From the start, VP8 and H.264 were the front runners though H.261, H.263, Theora, and Motion JPEG were also considered. From the 10,000 foot level, the draw to H.264 was its widespread support and the draw to VP8 was its BSD-like license and irrevocable free patent license on its bitstream format. Of course, VP8 was shown to be widely supported and the IPR “freeness” of VP8 was questioned (discussed in response to question #3 below). And, H.264’s widespread support was attacked based on the number of profiles and H.264’s licensing cost was described as “low”.
Of course, the topic that dominated the discussion was IPR. But, from the start everybody that this was going to be the case so there’s text to address it in the charter, i.e., there’s the possibly that an IPR-encumbered solution might be selected. See Section 3 for more on IPR issues.
Lest you think that the entire debate was about IPR, early on technical topics included video quality and performance as well as status of VP8 standardization, which BTW is moving its way through ISO. None of these topics however were interesting enough to maintain the WG's attention while the IPR debated raged.
As far as the consensus process goes, there were actually three attempts at reaching consensus. The first attempt did not result in WG consensus. After the 1st attempt failed, the WG explored an alternative decision making process (the 2nd attempt), which also was fodder for the IETF discussion list, based on this msghttp://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html. This too didn’t result in WG consensus but a couple of important topics did fall out: 1) it helped enumerate more options (i.e., it wasn’t just H.264 vs VP8) and 2) confirmed that the WG did in fact want to decide on an MTI codec.
Leading up to IETF 91, the chairs proposed a series of physical and vocal calisthenics, which can be found here:http://www.ietf.org/mail-archive/web/rtcweb/current/msg13358.html, that we thought would help the WG reach consensus (i.e., third time being the charm and all). But, Adam took the wind out of our sails with his so called “novel proposal", which can be found here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html. Based on list support for the proposal we modified our questions to refer to Adam’s text prior to the meeting. So at the 2nd RTCWeb session @ IETF 91 we had presentations from the draft author on the compromise text and from the VP8 and H.264 “camps” in support of the compromise. Then, we had an open mic session followed by some hums. The rough consensus in the room was to adopt the comprise text but there were some objections raised and I pointed these out in the message sent to the mailing list confirming the room’s consensus:http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html. After the allotted time elapsed (and a few hundred more emails), I determined that the consensus in the room was confirmed.
I’ll note that during the second WG consensus attempt, I purposely requested that the other two chairs step down from the podium and I, along with some help from my ADs, made the consensus call and it was later confirmed on the list.
I do not believe there is need for special attention from any directorate beyond the normal directorate reviews this draft will receive during the IETF LC.
3. Intellectual Property
Note: Because IPR concerns were discussed so frequently, Scott Brander presented the IETF’s IPR rules (http://www.ietf.org/proceedings/85/slides/slides-85-rtcweb-3.pdf).
The following is the answer I got when I queried Adam about the IPR:
I have disclosed all IPR that I am required to under section 6.6 of BCP 79 (i.e., none).
In the interest of full disclosure: although they do not cross the threshold of requirements under section 6.6; and, in fact, are so nebulous as to be nearly meaningless to report under section 6.1.3, there are three matters that I will point out for the sake of completeness.
Due to statements made at the microphone in Toronto, I am aware that there is possibly a patent or patent application covering the CVO technique cited in the video draft. I have not taken steps to verify these statements, and no disclosure has been filed against the draft on the topic.
Although no disclosures have been filed against the video draft on the topic, the fact that H.264 has patent encumbrances is widely accepted within the industry. Although most claimants guard the purported patent numbers as trade secrets, I do note that the following declarations are asserted against the H.264 RTP format required by the video document:
Although no disclosures have been filed against the video draft on the topic, the fact that VP8 has patent encumbrances is widely accepted within the industry, although the number and identity of companies holding relevant IPR is a matter of heated debate. I do note that the following declaration is asserted against the VP8 RTP format required by the video document:
And the following declaration is asserted against the corresponding bitstream:
Cullen pointed out that the MPEG LA patent list is available. You can search for "MPEG LA patent list" and get a link.
4. Other Points
***DOWNREF ALERT***: RFC 6386 is a DOWNREF. Please make sure to explicitly note this in the IETF LC and add it to the DOWNREF registry.
There are no requests of IANA in this document.
There are normative references to two IETF drafts, I-D.ietf-payload-vp8 and I-D.ietf-rtcweb-overview; the VP8 draft has been submitted the IESG for publication (i.e., it’s on Ben’s plate); the RTCWeb overview draft will be progressing immediately before this draft or at the same time (i.e., there’s no crazy dependancies here). Note that unlike many overview drafts this draft is standards track so there’ll be no downref issue.
There are normative references to specifications from ITU, IEC, and 3GPP but all are standards so there’s no concern about downrefs.
There may have been more messages sent about this 9-page draft than there are alphanumeric characters in it.