Hi Martin, On Apr 21, 2015, at 1:20 PM, Martin Stiemerling <[email protected]> wrote:
> Martin Stiemerling has entered the following ballot position for > charter-ietf-netvc-00-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-netvc/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I am supportive to the chartering effort, but I believe that the cross-WG > review part is expressed too weak in this text part: > > "In completing its work, the working group will liaise with other > relevant IETF > working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and > other > IETF WGs that make use of or handle negotiation of codecs; W3C working > groups > including HTML, Device APIs and WebRTC; and ITU-T (Study group 16); > ISO/IEC > (JTC1/SC29 WG11); 3GPP (SA4); and JCT-VC." > > My text proposal: > > In completing its work, the working group will seek cross-WG review with > other relevant IETF > working groups, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and other > IETF WGs that make use of or handle negotiation of codecs; and liaise > with other SDOs, such as > W3C working groups including HTML, Device APIs and WebRTC; and ITU-T > (Study group 16); ISO/IEC > (JTC1/SC29 WG11); 3GPP (SA4); and JCT-VC. I see no problem with this since liaising with a working group is more or less equivalent to getting cross-WG review. I have made this change. Alissa > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please expand RF in this paragraph: > "The WG will prefer algorithms or tools where there are verifiable > reasons to > believe they are available on an RF basis over algorithms or tools where > there > is RF uncertainty or known active IPR claims with royalty liability > potential. > The codec specification will document why it believes that each part is > likely > to be RF, which will help adoption of the codec. This can include > references to > old prior art and/or patent research information. > " > > _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
