Internet Video Codec
charter-ietf-netvc-01

[Ballot comment]
I don't know if the cat is too far out of the bag for this to matter, but

"1. Is competitive (in the sense of having comparable performance) with
current video codecs in widespread use."

has already piqued the interest of our dear friends at another SDO. Is it possible to pick a less interesting word than "competitive" here and elsewhere in the charter?

[Ballot comment]
- I'm supportive of this effort, but it requires one improvement first.
Like most IESG members, I spent some time on:

    In keeping with BCP 79, the WG will prefer algorithms or tools where there are
    verifiable reasons to believe they are available on an RF basis. In developing
    the codec specification, the WG may consider information concerning old prior
    art or the results of research indicating royalty-free availability of
    particular techniques.

Then I realized this text, further down:

    The working group shall heed the preference stated in BCP 79: "In general, IETF
    working groups prefer technologies with no known IPR claims or, for technologies
    with claims against them, an offer of royalty-free licensing." This preference
    cannot guarantee that the working group will produce an IPR unencumbered codec.

You should avoid these almost similar paragraphs and combine the text.

- Suggestion: Do you want to have a reference to OPUS in the charter, basically telling: "we want the same success, but for video this time."

[Ballot block]
I'm supportive of this effort, but it requires one improvement first.
Like most IESG members, I spent some time on:

    In keeping with BCP 79, the WG will prefer algorithms or tools where there are
    verifiable reasons to believe they are available on an RF basis. In developing
    the codec specification, the WG may consider information concerning old prior
    art or the results of research indicating royalty-free availability of
    particular techniques.

Then I realized this text, further down:

    The working group shall heed the preference stated in BCP 79: "In general, IETF
    working groups prefer technologies with no known IPR claims or, for technologies
    with claims against them, an offer of royalty-free licensing." This preference
    cannot guarantee that the working group will produce an IPR unencumbered codec.

You should avoid these almost similar paragraphs and combine the text.

[Ballot comment]
Suggestion: Do you want to have a reference to OPUS in the charter, basically telling: "we want the same success, but for video this time."

[Ballot comment]
As a sitting TSV AD, I applaud

"It should include, but may not be limited to, the ability to support fast and flexible congestion control and rate adaptation, ..."

Thanks to the group for going there. This seems uber important.

I'm balloting Yes with heartburn, based on this text:

"In developing the codec specification, the WG may consider information concerning old prior art or the results of research indicating royalty-free availability of particular techniques."

What I had assumed based on the BOF is that NETVC intends to use non-traditional techniques to (I'm quoting from the "DAALA coding tools and progress" slides at the BOF)

"Replace major codec building blocks with fundamentally different technology

"Be sufficiently different from existing approaches to avoid large swaths of patents"

as DAALA has done - at least, I assumed that was the point of showing these slides at the BOF.

Am I misunderstanding, or is NETVC back to using traditional approaches, where looking at old prior art matters more?

I agree with Martin's initial Discuss, and I mention that to thank you for the change into "seek cross-area review". I do see that as stronger than "liase with".

[Ballot comment]
As a sitting TSV AD, I applaud

"It should include, but may not be limited to, the ability to support fast and flexible congestion control and rate adaptation, ..."

Thanks to the group for going there. This seems uber important.

I'm balloting Yes with heartburn, based on this text:

"In developing
the codec specification, the WG may consider information concerning old prior
art or the results of research indicating royalty-free availability of
particular techniques."

What I had assumed based on the BOF is that NETVC intends to use non-traditional techniques to (I'm quoting from the "DAALA coding tools and progress" slides at the BOF)

"Replace major codec building blocks with fundamentally different technology

"Be sufficiently different from existing approaches to avoid large swaths of patents"

as DAALA has done - at least, I assumed that was the point of showing these slides at the BOF.

Am I misunderstanding, or is NETVC back to using traditional approaches, where looking at old prior art matters more?

I agree with Martin's initial Discuss, and I mention that to thank you for the change into "seek cross-area review". I do see that as stronger than "liase with".

[Ballot comment]
Two comments you should feel entirely free to treat as nits:

- The term "competitive" is used a couple of times. I get the gist
but that might add more scope for people unhappy with the WG
consensus to re-argue about performance measurements. (But
maybe they will anyway.)

- The BCP79 para says "verifiable" which sounds nice but might
also leave open too much scope for argument if someone insists
that the WG consensus is not based on verifiable reasons. Mostly,
the BCP79 conclusions reached by participants are not verifiable,
even if the facts presented to the WG that are taken into account
are verifiable. I think it'd maybe be better to say something like
"prefer algorithms or tools where there is rough consensus amongst
participants that those will in fact be available without
significant encumbrance on a royalty-free basis."

[Ballot comment]
Thank you for addressing my concerns.

A nit: there is one "RF" left in this paragraph
"In keeping with BCP 79, the WG  [...] on an RF basis."

[Ballot comment]
Thanks for sorting out my blocking concern.  I still have my minor comment:

<<
5. A collection of test results, either from tests conducted by the
working group or made publicly available elsewhere, characterizing the
performance of the codec. This document shall be informational.
>>

I'm really happy that the deliverables are, in general, specified in
terms of what will be delivered, and not how it will be laid out in
how many documents of what sort.  Thanks!

Related to that:
I strongly urge that we strike the last sentence in item 5.  Actually,
I prefer that we replace it with an explicit statement that the
collection might live in the working group wiki (or github, or
whatever), and might not be published as an RFC at all.  But I'd be
happy with just striking the reference to publishing a document.

[Ballot 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.

[Ballot 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.

[Ballot 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.
"

[Ballot block]
The IESG has discussed this issue on last week's informal call, and we
have asked the IAOC legal committee to comment.  We have some
response so far, and we're waiting for Jorge to weigh in.

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

We are pretty explicit, in general, that working groups do NOT
evaluate patents and other intellectual property, and there are good
reasons for that.  Some companies would have problems with their
employees participating in such discussions.  Discussions of that
nature can put people into positions where they become aware of
patents they otherwise would not, and that their employers would
prefer that they didn't.

I think that at the very least, we should loop the IAOC legal
committee and/or Jorge into this, and make sure they are/he is OK with
having anything about patent research information in a working group
charter.  I know that many companies do not allow their employees to
do patent searches and evaluations without explicit permission.

I worry that such a discussion will either make it impossible for some
people to participate, or cause some people's participation to
unintentionally violate their employers' policies.

[Ballot comment]
I certainly support this charter.  I have two concerns, one minor, one
not so minor.  The not-so-minor one is above, in the "discuss" box.

The minor one is here:

<<
5. A collection of test results, either from tests conducted by the
working group or made publicly available elsewhere, characterizing the
performance of the codec. This document shall be informational.
>>

I'm really happy that the deliverables are, in general, specified in
terms of what will be delivered, and not how it will be laid out in
how many documents of what sort.  Thanks!

Related to that:
I strongly urge that we strike the last sentence in item 5.  Actually,
I prefer that we replace it with an explicit statement that the
collection might live in the working group wiki (or github, or
whatever), and might not be published as an RFC at all.  But I'd be
happy with just striking the reference to publishing a document.