Subject: [codec] Updated Charter Proposal Take 2

From: Jason Fischl <[email-masked]>
Date: Tue, 28 Jul 2009 20:17:55 +0200

Jean-Marc and I have put together an update to the charter based on comments
received privately and on the mailing list as well as input from Cullen and
Greg. 

The key updates are:
- added a motivation section
- clarified the IPR section
- added Codec Standardization Guidelines deliverable
- added more detail for all of the deliverables
- added specific milestones

--------------
DRAFT CHARTER:

Motivation:

There is interest and value in having widely, easily distributable and
accessible codec technology from the Internet community. Codec experts from
both within and outside the IETF community have expressed an interest in
contributing effort in this area. The IETF standards process provides a
model for producing standards that encourages transparent design and open
collaboration early on in the process. Any IETF codec designs that may
emerge will also benefit from input and review from other RAI working groups
and other areas of the IETF.

Goals:

The goal of this working group is to standardize audio codecs that can be
implemented, distributed, and used broadly, and be interoperable between a
wide set of interested parties. The group is chartered to work on audio
codecs for interactive communication over the Internet. Codecs optimized for
very low bit rates or for non-interactive audio are out of scope. The codecs
should address the following technical considerations:

* suitability for most fixed-point DSPs;
* medium- to high-quality speech at moderate bit-rate;
* high-quality music encoding at higher bit-rates;
* sampling rate profiles from narrow-band to full audio bandwidth;
* real-time adaptive bit rate;
* source-controlled variable bit-rate (VBR);
* low algorithmic delay;

Beyond technical considerations, IPR issues will be handled in accordance
with BCP 78 and BCP 79. Specifically, many existing codecs with the
technical attributes listed above are encumbered with licensing fees and
other IPR claims that make royalty-free and wide distribution and use across
the Internet community difficult. The working group will try to standardize
codecs that can be relatively freely and easily distributed, and employed as
much as possible. In doing so, it will adhere closely to these BCPs. More
specifically, "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." Note that in accordance with BCP 79, this working
group will not explicitly rule out the possibility of adopting technology
that does not meet these IPR requirements; the decision will be left to the
normal rough consensus of the working group.

Deliverables:

1) Codec Standardization Guidelines - that define a set of metrics which can
be used to evaluate a codec. These metrics would include complexity, quality
vs bitrate, algorithmic delay, packet loss performance and footprint. The
complete list will be specified in this document. An evaluation of these
metrics should be considered by the working group in trying to come to
consensus about proposed changes to one of the draft codecs. After a codec
is finalized, these guidelines will be used to characterize the codec. This
is an Informational track document.

2) Requirements Document - that defines the application requirements of the
resulting solution. The requirements will include the exact technical
considerations, the scenarios that are being addressed and the assumptions
about the Internet operating environment. This is an Informational track
document.

3) Algorithm descriptions for wideband Internet audio codecs. There MUST be
a text description of the algorithm as well as a reference implementation.
The reference implementation MUST be compliant with BCP 78 and BCP 79. The
text description MUST indicate those components of the encoder and decoder
which are mandatory, recommended and optional. For example, in some codec
definitions only the decoder is specified whereas others have bit-exact
specifications. This is a Proposed Standard document.

It is not necessary to produce a single codec that solves the entire range
of scenarios. A codec may be approved by the working group without
addressing all of the scenarios.

Milestones:

Jan-2010: WG LC on Codec Standardization Guidelines
Jan-2010: WG LC on Requirements
Jul-2010: WG LC on codec algorithm description(s) to IESG
Mar-2010: Codec Standardization Guidelines to IESG (Informational)
Mar-2010: Requirements to IESG (Infomational)
Jan-2011: Submit codec algorithm description(s) to IESG (Proposed Standard)

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Jul 2009 01:21:47 +0300

Hi,
I am a bit confused about the charter, it says that the group will
standardize audio codecs which means 1 to infinity. Yet there will be one
codec standardization guideline  document that will define the metric to
evaluate the codec. I am not sure where the values for this metrics are
specified is it here or is it in the requirement document.
The result is that either the values will be very vague or we will have many
codecs with similar capabilities - I fail to see how this achieves the
objective of being used broadly and be interoperable.

I see that the codec will be characterized after it is finalized. Does it
mean that we first publish a codec and afterward test the quality.

I do not see any mention of a document that will describe the tests and the
fail/pass requirements unless it is the guidelines that will be used to all
proposed codecs

I do not see any mention of a reference codec selection in order to evaluate
the quality of the proposed codec.

I find it strange that when talking about the open Internet environment and
with an objective to achieve a broadly used and interoperable solutions the
suggestion is to allow to standardize only the decoder side.

Thanks
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jason Fischl
> Sent: Tuesday, July 28, 2009 9:18 PM
> To: [email-masked]
> Cc: Jean-Marc Valin
> Subject: [codec] Updated Charter Proposal Take 2
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 28 Jul 2009 17:40:58 -0700

Hi,

I have two comments with respect to IPR and deliverable 3 (and a possible
hidden IPR aspect), and a third comment re timing.  Both IPR related
comments have been raised before, but let me re-iterate them:

First, it is my understanding that the language in the charter related to
IPR is in full compliance with the relevant BCPs, and, therefore, I cannot
have a hard objection based on process or policy violation.

Still, explicitly citing only one of many preferences and rules of BCP 79 is
clearly setting the tone in one direction, and may discourage contributions
by those whose business model is not overly aligned with this very section
of BCP 79 (but fully aligned with others).  It would be easy to selectively
quote other parts of BCP 79 supporting a completely different business
model.  For example, I could quote (in isolation) section 3.1: "General
Policy / In all matters of Intellectual Property Rights, the intent is to
benefit the Internet community and the public at large, while  respecting
the legitimate rights of others."  Or, to be more specific, wouldn't the
inclusion of the second sentence of section 8 (from which you have taken
only the first sentence) also create a more balanced picture?  It reads: "
But IETF working groups have the discretion to adopt technology with a
commitment of fair and non-discriminatory terms, or even with no licensing
commitment, if they feel that this technology is superior enough to
alternatives with fewer IPR claims or free licensing to outweigh the
potential cost of the licenses."

I continue to prefer not to mention the IPR topic at all (which is the norm
in IETF charters), or state the required compliance with BCP 78 and 79
without further commentary, interpretation, or citation.  Please consider
this input.

My second issue is a bit more subtle and (I fear) quite a bit harder to
understand (especially for those not at least somewhat familiar with open
source licenses), but may also be more critical.  It relates to the hard
requirement for code.  In parts, I have already discussed the problem in my
messages sent around 7/15, but let me explain once more.

At present, the RFC editor, per a requirement set by the IETF trust, inserts
a BSD-style license template into the source code.  This templates include a
phrase "[...] Redistribution and use in source and binary forms, with or
without modification, are permitted [...]".  There are scholars and
corporate lawyers (I personally know quite a few of the latter) suggesting
that this language---specifically the unqualified use of the term
"use"---may imply a patent license grant.  In my recollection, supported by
the private conversation I had around this topic, allowing such an implied
license was not the intention of the IPR WG at the time, but we may still
have it.  It would not be the first mistake we made in the RFC 5378 mess.

A few of us more sensitive to these matters have started discussing this
problem with the IETF trust.  I do hope that we can find a solution that
makes those of us sensitive to implied patent licensing comfortable.  There
are a number of ways how this can be done, but I think this is not the right
forum for this discussion.  Personally, I believe that all those ways
require some form of a public statement by the IETF trust and/or its lawyer.
At this point, no such statement has been made.

The charter currently requires source code for the codec.  Quoting from the
draft charter, section deliverable 3: "There MUST be a text description of
the algorithm as well as a reference implementation.  The reference
implementation MUST be compliant with BCP 78 and BCP 79."  I object to the
code requirement on the procedural ground that it may imply  the grant of an
implicit patent license by anyone contributing to the I-D and/or the code
part thereof, which can be seen an introduction of a royalty-free licensing
requirement through the back door.  This is currently a hard objection, and,
if the subject is not resolved, I will go down the appeals process.

However, I do hope very much that a viable solution can be found by the
trust, which may be anywhere from a good legal argument by the trust to
convince me that this is a non-issue to a change of the outbound license.
If the trust finds such a solution, I will promptly remove my objection.

As a quick solution to this mess, I would suggest the following change in
the charter language (which would give those parties interested more time to
work with the trust on a "permanent" solution---famous last words :-)
"There MUST be a text description.  There SHOULD be a reference
implementation, which MUST be compliant with BCP 78 and BCP 79."  If that's
not acceptable, then I would suggest to split documents: text description in
one standard's track RFC and a reference implementation in another, whereby
the reference implementation MUST be derived from the textual description.
This would allow interested parties to contribute to the text version only,
thereby practicing code hygiene and avoiding implicit patent licensing.

As said, I will remove this objection promptly as soon as a satisfactory
solution is found, at which point I would have no problem in going back to
the (technically sensitive) choice of requiring reference code.

Finally, the timing.  Rarely I have seen such unrealistically ambitious
milestone goals.  In other SDOs, setting the Terms of Reference (Codec
Standardization Guidelines and Requirements are the equivalent) is a process
that can take many years. In fact, it's the hardest part of the whole
exercise, as every interested party will try to fine-tune the requirements
to their preferred technology.  I have witnessed some of this maneuvering
even on this very mailing list.  This is not only an IPR game, it also
covers other very legitimate interests.  Attempting to run such a process in
half a year cannot lead to good results.  IMHO, it WILL lead to
rubberstamping.  Please give yourself at least a year for the requirements
and procedures work to get those right.  I don't care how quickly you speed
through the codec specs themselves.

Regards,
Stephan

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 29 Jul 2009 10:11:16 +0200

Dear Stephan Wenger,

> without further commentary, interpretation, or citation.  Please consider

Let me object your request. Mentioning the IPR topic is fair way of warning
all potential contributors that it will be very hard to include a solution
that requires the payment of license fees. 

At least I would vote for a codec that is believed to be license free
instead one that you have to buy even if the first performs slightly worse
than the second. To my understand, most of the other IETF folks will act
similar.

> At this point, no such statement has been made.

This concern might be valid. However, I do not think this will be an issue
if we can agree on a license free codec.

> requirement through the back door.  

Again, if we agree on an open development process with license free terms,
than the requirement of an open source reference implementation should not
be an issue.

> that can take many years. 

Doesn't the IETF work at "Internet speed" ;-)

> In fact, it's the hardest part of the whole
> even on this very mailing list.

Your point is right. I would suggest to include other parties such as the
AVT working group or user groups into the requirement definition. If you let
the codec developers write their own requirement document, if will end up in
rubber stamping. 

  This is not only an IPR game, it also
> through the codec specs themselves.

To my understanding, these dates are not hard deadlines. I am always a
friend of a tough schedule to motivate the contributors to speed up their
work.

With best regards,

 Christian

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 29 Jul 2009 10:46:14 +0200

Hello Roni,

> ...

To my understanding, the goal of the charter is provide one solution for the
Internet that might consist of one codec with multiple "profiles" or of
multiple codecs that are intended for different network conditions. 

Please allow me to explain the need for this requirement by comparing the
audio solution with TCP. As you know, TCP works well regardless of the
available bandwidth and scales from a few bytes per second to up gigabit
speeds. This feature of TCP is important because the Internet does not give
any guaranties on bandwidth. 

Similar, an audio solution for the Internet shall work in a wide range of
different network conditions because nobody can guaranty a minimal bandwidth
on the public Internet at all times. As TCP, an audio solution for the
Internet would try to achieve the best quality that is currently possible. 

More precisely,
1. At very low transmission delays and at very high transmission rates,
quasi-synchronous audio transmissions would allow distributed ensemble
performances having a close to perfect Hi-Fi quality.
2. At modest bandwidths, an interactive audio transmission of music and
speech shall be possible.
3. If the bandwidth gets lower, than an interactive speech transmission can
still be supported (at wide- or narrowband)
4. If transmission capacity hardly exists, one still can degraded the
quality of a telephone call to something like a push-to-talk (PTT) like
service having very high latencies (or use text messages instead).
Then, an Internet audio solution provides the best possible service quality
at the given network constrains. 

Also, the measures of quality requirements change with the available
transmission capacity. In case of
1.) you might want to measure quality with the MUSHRA tests given in ITU
BS.1534-1 (http://www.itu.int/rec/R-REC-BS.1534-1-200301-I/e). Also,
research literature (e.g. by Alexander Carôt or Chris Chafe) gives you
guidelines on the latency requirements.
At 2.) Again, the BS1534-1 can be used for the assessment of the music
quality. During the characterization of G.718, the ITU used the Absolute
Category Rating (ACR) for music, too. (refer to ITU-T P.800 and ITU-T
P.910).
3.) At low bandwidth music transmission cannot be support anymore but only
speech. Then, the classic procedure of the ITU Study Group 12 needs to be
considered (P.800 and others).
4.) In this case, only not the speech quality but understandability should
be considered. I do not know any standard on this but in research
literature, the performance of automatic speech recognition (ASR) systems is
usually taken a metric.

To my understanding these diverse requirements cannot be achieved with a
single algorithm but requires different codecs or different algorithmic
profiles in one common codec.

If multiple audio codecs are proposed, than the overlap between them should
be minimal. Nobody wins, if we have multiple different codecs for the same
network condition but all benefit on having a solution that is scalable and
reliable.

With best regards,

 Christian

---

From: Jason Fischl <[email-masked]>
Date: Wed, 29 Jul 2009 11:13:25 +0200

Hi Roni,

Thank you for thoroughly reviewing the updated charter. We have made minor
modifications to the charter to address the issues you point out. See below:

> objective of being used broadly and be interoperable.

Thanks for pointing this out. We have clarified that the guidelines define
the metrics but not the target values. The target values are defined in the
requirements. 

> mean that we first publish a codec and afterward test the quality.

This means nothing more than final testing has to be done after the codec is
finalized, or the final testing wouldn't be final. Of course, there will
also be continuous testing, as we have now clarified.

> fail/pass requirements unless it is the guidelines that will be used to all

Thanks, we have added that "A set of pass/fail requirements MAY be specified
in the requirements document".

> the quality of the proposed codec.

We have now mentioned an "optional reference codec".

> suggestion is to allow to standardize only the decoder side.

Thanks for pointing this out. We have clarified that "Any characterization
MUST be performed with the reference encoder. This is a Proposed Standard
document."

Basically, any codec that allows the encoder multiple axes of freedom on the
encode side tends to specify only decode as normative.  This is standard
practice in other SDOs (though not the only standard practice).

What is different (and what may have alarmed you) is that SDOs that make
decode normative also typically hold back all the 'good' encoders entirely
from the process, keeping them closed to be sold later.  We intend, and it
should be made clear in the document, that a high-quality reference encoder
must be described in detail and provided with the reference implementation. 
This fully open reference encoder will be the one used for characterization,
performance and comparative testing.

    Jean-Marc and Jason

---

From: Stefan Sayer <[email-masked]>
Date: Thu, 30 Jul 2009 02:21:41 +0200

Hello,

> without further commentary, interpretation, or citation.  Please consider
My objection here, for a very simple reason: There are other SDOs who do 
not try to standardize RF codecs, and while they have standardized very 
good codecs, they have until now failed to standardize a wideband codec 
which is widely used in the Internet, and for VoIP in general. The G722 
example (it is now royalty free, but in spite of its low quality one of 
the widest deployed, if not the widest deployed wideband codec for VoIP) 
shows that RF is one of the key requirements for widespread adoption in 
this situation. Thus, if possible, it makes sense to try to standardize 
a RF codec, and it is good to quote exactly that section from BCP79 in 
the charter.

Best Regards
Stefan Sayer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 Jul 2009 09:51:53 +0200

On Jul 29, 2009, at 2:40 , Stephan Wenger wrote:

> "use"---may imply a patent license grant.

Stephan, at a high level, I don't think this will poses a problem for  
this BOF. When selecting the BSD license, the IETF did not intent to  
include patents licenses as part of the "use". If there is a real  
problem with the BSD license possibly granting patent licenses, the  
obvious thing to do would be for the Trustees to "qualify" the meaning  
of "use" in the license. For purposes of this BOF, I think  we can  
assume that if there is any community consensus this is a problem,  
then it will be fixed.

That said, I'm glad to see input on questions such as: should the  
normative specification should be in source code or not; and if that  
decision would need to be in charter or be something that a WG might  
decide if was formed.

Cullen

PS - Clearly this would be the wrong mailing lists for discussion of  
the topic but I note Herald, the previous IPR WG chair, did not seem  
to share your concern.  I also note it's not clear if you actually  
believe this is an issue. I'd certainly be interested i knowing if you  
personally believed that it was likely that courts would interpret BSD  
this ways but it's pretty hard to decide how to evaluate the vague  
reporting of other unnamed peoples opinions. Anyways, all topics for  
another mail list.

---

From: stephen botzko <[email-masked]>
Date: Thu, 30 Jul 2009 06:41:33 -0400

I believe that normative source code is best for a number of reasons.  One
is ease of implementation (either using the reference code directly, or
being able to use it to validate the ported code).  Another is that it
assures that the characterization tests actually measure the standard's
performance.  Even if it is not officially normative, readily available
reference code becomes de facto normative, since most implementers will
simply use the code and ignore the text in the RFC.

Supplying test vectors is another possibility, but that is problematic for
floating point implementations.

Regards,
Stephen Botzko
Polycom

On Thu, Jul 30, 2009 at 3:51 AM, Cullen Jennings <[email-masked]> wrote:

> Stephan, at a high level, I don't think this will poses a problem for this
> BOF. When selecting the BSD license, the IETF did not intent to include
> patents licenses as part of the "use". If there is a real problem with the
> BSD license possibly granting patent licenses, the obvious thing to do would
> be for the Trustees to "qualify" the meaning of "use" in the license. For
> purposes of this BOF, I think  we can assume that if there is any community
> consensus this is a problem, then it will be fixed.
>
> That said, I'm glad to see input on questions such as: should the normative
> specification should be in source code or not; and if that decision would
> need to be in charter or be something that a WG might decide if was formed.
>
> Cullen
>
>
> PS - Clearly this would be the wrong mailing lists for discussion of the
> topic but I note Herald, the previous IPR WG chair, did not seem to share
> your concern.  I also note it's not clear if you actually believe this is an
> issue. I'd certainly be interested i knowing if you personally believed that
> it was likely that courts would interpret BSD this ways but it's pretty hard
> to decide how to evaluate the vague reporting of other unnamed peoples
> opinions. Anyways, all topics for another mail list.
>