Re: [rtcweb] Finishing up the Video Codec document

[Peter Saint-Andre - &yet <[e-mail]>]

On 11/25/14, 4:33 PM, Adam Roach wrote:
> I've updated the draft-ietf-rtcweb-video based on the minutes from
> Hawaii. Now that we have a clear path to success, I'd like to get the
> document finalized and published as quickly as possible. This means I
> need your feedback on the remaining open issues (1, 4, and 5, below). If
> you are CCed on this mail, it's because you took an action item in
> Hawaii, and I'm waiting to hear back from you.
>
> New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt

I have concerns about the future-oriented text:

       To promote the use of non-royalty bearing video codecs,
       participants in the RTCWEB working group, and any successor
       working groups in the IETF, intend to monitor the evolving
       licensing landscape as it pertains to the two mandatory-to-
       implement codecs.  If compelling evidence arises that one of the
       codecs is available for use on a royalty-free basis, the working
       group plans to revisit the question of which codecs are required
       for Non-Browsers, with the intention being that the royalty-free
       codec will remain mandatory to implement, and the other will
       become optional.

The if-clause in the last sentence establishes a trigger for revisiting 
the combination of VP8 and H.264 as MTI video codecs. But is that the 
only possible trigger? If so, I think the document is misguided.

The ideal solution to the video codec problem would be for the IETF 
community to create a truly unencumbered video codec, as it has already 
done for audio with the Opus codec. If the IETF (or some other standards 
development organization) were to develop such a codec, then I think 
that would be a sufficient trigger for revisiting the recommendations in 
this document, no matter what happens with the royalty-free status of 
VP8 and H.264.

I would strongly prefer that the document contain text recognizing that 
possibility.

Furthermore, this text about WebRTC Browsers sends the wrong message, I 
think:

       These provisions apply to WebRTC Non-Browsers only.  There is no
       plan to revisit the codecs required for WebRTC Browsers.

Certainly there is no active plan at this time to revisit the MTI codec 
issue (after all, we're still *visiting* the issue for the first time), 
but that's immaterial to the question of when it might be appropriate to 
do so. The current text reads as if there are no conditions under which 
the MTI codec issue would ever be revisited, and that's just wrong.

(A smaller but not insignificant issue is that the document talks about 
"the RTCWEB working group", "any successor working groups in the IETF", 
and "the working group" interchangeably. Yet can this document establish 
plans for successor working groups, or even future incarnations of the 
RTCWEB working group? Any plans related to future efforts will be set by 
WG consensus or IETF consensus, not for all time by this document.)

IMHO we need to either pull out the future-oriented text entirely (which 
has its own problems) or significantly improve it. I would be happy to 
propose text for the latter.

Peter

-- 
Peter Saint-Andre
https://andyet.com/