Subject: Re: [codec] Codec BOF approved, much work needed

From: Ron Even <[email-masked]>
Date: Fri, 19 Jun 2009 18:59:04 +0300

Cullen,

I looked at the agenda

1. Administrative (Chairs, 5 min)

  - Note takers, Jabber scribes

  - Agenda bashing

2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)

3. Proposed CODECs (TBD, 25 min)

  - Expect to have two or more drafts here

4. Charter Discussion (All, 40 min)

5. Decisions and HUMs (All, 5 min)

6. Conclusions and Next Steps (Chairs/ADs, 5 min)

And it looks to me that it starts with assumption that we will have a new
working group.

I am not sure that that this was agreed and yet I see no time allocated to
discuss the topic. I would expect that item 3 will be rational for doing
codec at the IETF considering that this work is done also by other SDOs that
the IETF is working with.

Now even if there will be such a WG starting with proposed CODECS is like
having a solution before the requirements. In other standard bodies
requirements are not just names but they also have values. So what is the
purpose of proposing codecs, do we need to select at the BOF which one will
be standardize, to me it looks like this should be done later.

Roni Even

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Cullen Jennings

> Sent: Friday, June 12, 2009 8:32 PM

> To: [email-masked]

> Subject: [codec] Codec BOF approved, much work needed

> I have approved the CODEC BOF proposal. However, we need a bunch of

> work to get ready.  Various people on IESG/IAB were not comfortable

> with the current charter and agenda so we need to work on theses

> before the meeting.

> A draft agenda/charter Jason provided are at

> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-

> bof/charter.txt

> After discussion with the IESG/IAB:

> I'd like to remove the "as Proposed Standard" from the charter text

> for both milestones and see how the discussion goes in the BOF before

> deciding which way this should go.

> I'd like to see more consideration around the issues of designing a

> codec that did a good job of mapping a real time stream onto IP

> packets. The way IP deals with packet loss and congestion has

> implications for designing a codec that works well over IP. I know

> some of the discussion I have had off list people talked about how we

> wanted a codec that supported adaptive bit rates that could change on

> the fly to be able to work well on an IP network.

> I will be working the folks to make sure the agenda has time to

> directly address the key topics which include (more may be coming):

> Will we be able to get qualified people to do and review the work?

> Key design goals of a new codec?

> Do we need a new codec or are there already ones defined that meet the

> needs?

> I have asked Jason Fischl  and Jean-Marc Valin to co-chair this BOF.

> Thanks,

> Cullen <RAI AD>

> _______________________________________________

> codec mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/codec

---

From: "Roni Even" <[email-masked]>
Date: Fri, 19 Jun 2009 22:04:33 +0300

Jaen-Marc,
Charter does not constitute the requirements from the codec or do you think
that what is in the charter are the requirements. 
I am also not sure what you mean when you are saying that presenting codecs
will prevent what you call kitchen sink/wish list requirements. Are the
codecs to be presented the only codecs allowed for the WG and if not then
why present them, better spend the BOF time on deciding if this work should
be done and if there is a consensus try to discuss how the WG will define
requirements and select a codec. I think that even for these topics the BOF
time will be too short

Roni Even

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Friday, June 19, 2009 9:52 PM
> To: Ron Even
> Cc: [email-masked]
> Subject: Re: [codec] Codec BOF approved, much work needed
> 
> Ron Even wrote:
> >
> > Now even if there will be such a WG starting with proposed CODECS is
> > like having a solution before the requirements. In other standard
> > bodies requirements are not just names but they also have values. So
> > what is the purpose of proposing codecs, do we need to select at the
> > BOF which one will be standardize, to me it looks like this should be
> > done later.
> >
> 
> I agree that discussing the requirements is very important, I just
> assumed that is was part of the "Charter Discussion" item. Regarding
> codec proposals, I think it's still a good idea to have that as a way
> to
> better focus the discussions. We don't have to choose any or the
> proposed codecs and if we do, it doesn't have to be in the form they
> have been submitted. What this does however is:
> 1) It gives us a base for discussion to avoid defining kitchen-
> sink/wish
> list requirements
> 2) It shows us some technology we have available right now, so that we
> can adapt it rather than starting from scratch
> 
> Cheers,
> 
>     Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 19 Jun 2009 16:38:59 -0400

Hi,

(again, see my original email in the quote below because the list didn't accept
it)

Quoting Roni Even <[email-masked]>:
> will prevent what you call kitchen sink/wish list requirements.

I want to avoid ending up with a list of requirements that looks like:
"high-quality music at 8 kbit/s" or "support bit-rates from 2 to 512 kbit/s".
It helps to have a reference of what's technologically achievable (even the ITU
codecs can serve for that), but it's also useful to have a reference of what we
could have in the relatively short term. For example, one way to proceed would
be to look at some actual proposals and ask "what more (or less) do we need
compared to this?". No, this is not exactly the way the ITU works, but if we
wanted everything to work like it does at the ITU, we wouldn't be discussing a
new WG.

Having actual proposals is also a good way to address the "there is no codec
expertise" argument against forming this new WG.

Cheers,

   Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Fri, 19 Jun 2009 23:50:20 +0300

Hi,
I think you are using more than one email address and this is why the
mailing list do not accept all your posting.

As for you response, If you do not have any real requirements, and I mean
ones that start with the application and gives quality values so how will
the IETF decide to approve some offering without knowing that it is better
suited than currently available codecs and recommend such a codec. This
looks more like rubber stamping some existing codec, I hope this is not what
the IETF does.
If you want to publish existing codecs ASAP like was done with iLBC, than do
informational RFCs and I am not sure why you need a WG for that. 

Roni Even

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Friday, June 19, 2009 11:39 PM
> To: Roni Even
> Cc: 'Jean-Marc Valin'; [email-masked]

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 19 Jun 2009 17:29:05 -0400

> mailing list do not accept all your posting.

Both addresses are subscribed. It's just an issue with the ietf mail server
rejecting email because a recent DNS update hasn't fully propagated.

> As for you response, If you do not have any real requirements

I am not suggesting that we shouldn't have requirements.

> and I mean
> suited than currently available codecs and recommend such a codec.

One of the issues that is fundamental here is that most of the "currently
available codecs" are simply not an option for Internet use at the moment.
There is a large range of applications that require clients to be downloadable
freely (either as open source, or just "free of charge"). Codecs such as
G.729.x, AMR-*, and G.718 are simply not an option, no matter what their
technical merits are. Just look at a few high-profile software such as Skype,
Adobe Flash, Google Talk, X-Lite, and many less known ones. None of these
support G.729 or AMR and as far as I know they can't add support without paying
royalties every time someone downloads the software. The codecs you'll see
being used are G.711, Speex, iLBC... or even GSM-FR. These are the "currently
available codecs" for most Internet applications. This is the real reference on
which we need to improve (not to say that we can't make something better for
Internal apps than the ITU codecs).

> This

I am not suggesting rubber-stamping a codec. I am merely stating that it's
easier to start from something that's already available and possibly adapt it
to suit our needs. Time isn't everything, but it also counts. It can be
weighted in like other requirements: "how much delay is feature X worth?"

Cheers,

   Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Sat, 20 Jun 2009 08:40:23 +0300

Jean-Marc,

I think this will cause a discussion , you are saying 
"Just look at a few high-profile software such as Skype, Adobe Flash, Google
Talk, X-Lite,"

As far as I understand these high-profile software clients are using
proprietary signaling so they can continue to use proprietary codecs. 
Why should the IETF help solutions that are not interoperable, and do not
show any interest with supporting free interoperability by publishing their
specifications with royalty free licenses.

Roni Even

> Sent: Saturday, June 20, 2009 12:29 AM
> To: Roni Even
> Subject: RE: [codec] Codec BOF approved, much work needed
> 
> > > > I am also not sure what you mean when you are saying that
> presenting
> > > codecs
> > > "high-quality music at 8 kbit/s" or "support bit-rates from 2 to
> 512
> > > kbit/s".
> > > It helps to have a reference of what's technologically achievable
> (even
> > > the ITU
> > > codecs can serve for that), but it's also useful to have a
> reference of
> > > what we
> > > be to look at some actual proposals and ask "what more (or less) do
> we
> > > need
> > > compared to this?". No, this is not exactly the way the ITU works,
> but
> > > if we
> > > Having actual proposals is also a good way to address the "there is
> no
> > > codec
> > > > > > Now even if there will be such a WG starting with proposed
> CODECS
> > > is
> > > > > > bodies requirements are not just names but they also have
> values.
> > > So
> > > > > > what is the purpose of proposing codecs, do we need to select
> at
> > > the
> > > > > codec proposals, I think it's still a good idea to have that as
> a
> > > way
> > > > > to
> > > > > 2) It shows us some technology we have available right now, so
> that
> > > we

---

From: Randell Jesup <[email-masked]>
Date: Sat, 20 Jun 2009 02:37:17 -0400

>specifications with royalty free licenses.

X-lite is a standards-based SIP softclient.

Skype *says* they're going to open up their new "Silk" codec; however
the available info in scant, and there's something in what little is
available that tends to imply they'll only provide you with a (Windows)
binary library, though they don't say so outright.

I filled out the form months ago for access; not even an acknowledgement.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 20 Jun 2009 09:29:29 -0400

Hi,

> specifications with royalty free licenses.

As far as I know, X-Lite uses SIP, while Google talk supports SIP and
XMPP. I'm not sure about Flash, but as far as I know you can use it
Speex API to do pretty much what you want (including a SIP phone). As
far as I know, Skype is the only app not to use open signalling
protocols. I still included it because the fact that it has a
proprietary protocol is pretty much orthogonal to the argument I am
making: for most Internet applications (open, proprietary), the standard
ITU codecs are simply not an option at all. If even these (presumably
deep pocket) high profile companies cannot use G.729 or AMR-* in their
clients, I don't see how smaller companies and open source projects
would be able to.

	Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Sat, 20 Jun 2009 17:13:13 +0300

Jean-Marc,
I think you are missing the point. A reason for a standard codec like for
standard signaling is to achieve interoperability between products coming
from different implementation giving the customer a choice. If the products
you list do not interoperate and do not try to address open interoperability
why do you need a standard codec. Get any free license codec available and
use it in those products, each can use a different one if they do not
interoperate on the signaling part. Making one of them a standard does not
buy the industry any value in this case.

Roni 

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Saturday, June 20, 2009 4:29 PM
> To: Roni Even
> >>> ones that start with the application and gives quality values so
> how
> >> will
> >> freely (either as open source, or just "free of charge"). Codecs
> such
> >> as
> >> technical merits are. Just look at a few high-profile software such
> as
> >> Skype,
> >> royalties every time someone downloads the software. The codecs
> you'll
> >> see
> >>> If you want to publish existing codecs ASAP like was done with
> iLBC,
> >> than do
> >> I am not suggesting rubber-stamping a codec. I am merely stating
> that
> >> it's

---

From: Christopher Montgomery <[email-masked]>
Date: Sat, 20 Jun 2009 11:30:51 -0400

On Sat, Jun 20, 2009 at 10:13 AM, Roni Even<[email-masked]> wrote:
> from different implementation giving the customer a choice.

That is a relevant point.

> If the products
> why do you need a standard codec.

This seems like an argument to be discussing this all within AVT---
which you also oppose.

As far as I can tell, your position can be boiled down to "I don't
want the IETF to be involved in royalty-free codecs or open transport
in any way."  Your position is noted.  Others disagree; to me it seems
like a wholesale abdication of interest in what will soon be the
supermajority of all traffic on the internet (if it is not already).
That would be everybody's loss.

[Hello from the Open Video Conference, BTW! :-]

> Making one of them a standard does not

It is important to point out that our responsibility is to more than
immediate business interests ('the industry').  Of course, the long
view benefits industry as well.

Monty

---

From: "Roni Even" <[email-masked]>
Date: Sat, 20 Jun 2009 18:53:35 +0300

Monty,
I am not sure why you are saying that my position  is " I don't want the
IETF to be involved in royalty-free codecs or open transport in any way".
This is not what I anm saying

What I am saying is that people coming to the IETF asking for royalty free
and open transport should support it with their technology before asking
others to provide it for their use.

Roni Even

> From: Christopher Montgomery [mailto:[email-masked]]
> Sent: Saturday, June 20, 2009 6:31 PM
> To: Roni Even
> Cc: Jean-Marc Valin; [email-masked]

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 20 Jun 2009 09:17:42 -0700

(subject changed)

Roni,

>In other standard bodies requirements are not just names but they also have values.

This may be a reason why the Darwinian Web is taking over :-)

"... details only become known to us as we progress in the [system's] implementation.
Some of the things that we learn invalidate our design and we must backtrack."
See for example http://en.wikipedia.org/wiki/Waterfall_model#Criticism

Avoiding the waterfall model is the main reason to explore existing codec proposals and new design options.

Requirements documents are useful as part of a continuing trial and error process, but are very damaging when dictated from the beginning.

Henry

On 6/19/09 10:59 AM, "Ron Even" <[email-masked]> wrote:

Cullen,
I looked at the agenda

And it looks to me that it starts with assumption that we will have a new working group.

I am not sure that that this was agreed and yet I see no time allocated to discuss the topic. I would expect that item 3 will be rational for doing codec at the IETF considering that this work is done also by other SDOs that the IETF is working with.

Now even if there will be such a WG starting with proposed CODECS is like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is the purpose of proposing codecs, do we need to select at the BOF which one will be standardize, to me it looks like this should be done later.

Roni Even

---

From: Christopher Montgomery <[email-masked]>
Date: Sat, 20 Jun 2009 13:49:05 -0400

> This is not what I anm saying

I apologize; I know only what I've read on the list and from the IETF
list archives.  It's been hard to escape the conclusion that you're
not and have not been particularly supportive of the idea in general.

> others to provide it for their use.

We (Xiph) are able and willing to do this.  I believe others are also
able and becoming more willing.  What I wanted to avoid doing was
pushing our specific codecs and transports as the only possible
solution as they're not.  We also have a next generation with the
first new codec ready to 'pop', and now is a wonderful time for it to
see wide, detailed review.  We're certainly adding everything we have
to the basket.

Monty

---

From: <[email-masked]>
Date: Mon, 22 Jun 2009 20:22:57 +0200

Hello Roni, All
 
ITU-T and 3GPP have already specified a wide portfolio of speech & audio codecs including Royalty Free codecs (for narrowband, wideband, superwideband...) with purpose to answer the needs of all conversational services (including new multimedia services over IP) and ensure end to end interoperability. Many of these codecs are already deployed and successfully used to answer the requirements of most of all voice services all over the world (over Circuit Switched, IP and Internet networks...). New extensions of these codecs have been or are being standardized to extend the quality towards very high fullband/stereo quality.

With respect to the end to end interoperability issue, this codec portfolio is even already too large considering the need to reduce networks additional costs and quality degradations due to transcoding operations.

Adding new IETF standardized codecs to this (with probably little or no coordination with other SDOs) would make no sense: those codecs would obviously compete with the ones from ITU-T or 3GPP and any other legacy codecs already widely deployed which would confuse the market, degrade the overall end to end voice&audio interoperability and quality and increase the transcoding costs in networks. 

Furthermore, IETF is not the place where sufficient codec expertise is gathered to standardize state of the art codecs (as in Technical Groups SA4 of 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standard Bodies would not help with creating quality codecs; this concerns not only the expertise and works needed for codec design but also all what is related to voice & audio quality assessment.

Best regards

Stéphane Proust

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Ron Even
Envoyé : vendredi 19 juin 2009 17:59
À : [email-masked]
Objet : Re: [codec] Codec BOF approved, much work needed

Cullen,

I looked at the agenda

  - Agenda bashing

 

Roni Even

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 22 Jun 2009 11:46:21 -0700

Hi Stéphane,

I am not sure how much you have followed the list, but did you notice the posts regarding one  of the top requirements to be royalty free,  to our best knowledge (IETF Note Well)?

Also this has been discussed at length; and credible and willing experts found
<IETF is not the place where sufficient codec expertise is gathered to standardize state of the art codecs...

Do we need to recap all these discussions?
The proposed BOF will definitely be very productive in the eyes of its proponents.
Strictly IMO, innovation cannot be suppressed on the Internet and it is fortunate when it can happen in the IETF.

Thanks, Henry

On 6/22/09 1:22 PM, "[email-masked]" <[email-masked]> wrote:

Hello Roni, All

Best regards

Stéphane Proust

Cullen,

I looked at the agenda

  - Agenda bashing

Roni Even

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 22 Jun 2009 16:02:49 -0400

Hi Stephane,

Quoting [email-masked]:
> ITU-T and 3GPP have already specified a wide portfolio of speech & audio
> codecs including Royalty Free codecs (for narrowband, wideband,
> superwideband...)

Actually, I'm not aware of any codec standardised by the ITU-T and 3GPP in the
last 10 years and that doesn't require the licensing of several patents. This
is one of the main problems we're trying to address here as patent-encumbered
codecs are seriously harming interoperability on the Internet.

> Furthermore, IETF is not the place where sufficient codec expertise is
> gathered to standardize state of the art codecs (as in Technical Groups SA4
> of 3GPP or WP3/SG16 of ITU-T)

As it is, we *already* have several people involved that have sufficient coding
expertise and that have already written at least 6 audio codecs (that I know of
-- possibly more).

> and duplicating the works within multiple
> Standard Bodies would not help with creating quality codecs; this concerns
> not only the expertise and works needed for codec design but also all what is
> related to voice & audio quality assessment.

Right now, all these nice ITU codecs are just not available for use in most
"Internet-based" applications. Can you find a single free VoIP client that
supports AMR-WB or G.729? Any Java applet that uses these codecs? Any browser
plugin? We need codecs that can be used without restriction. This is the
problem that we are trying to address with this new WG proposal.

Cheers,

   Jean-Marc

---

From: "Herve Taddei" <[email-masked]>
Date: Mon, 22 Jun 2009 22:07:32 +0200

Dear Henry,

> I am not sure how much you have followed the list, but did you notice the
posts 
> regarding one  of the top requirements to be royalty free,  to our best
knowledge > (IETF Note Well)?
I imagine he did and that is why he is pointing out to:
"ITU-T and 3GPP have already specified a wide portfolio of speech & audio
codecs including Royalty Free codecs (for narrowband, wideband,
superwideband...)"

> Strictly IMO, innovation cannot be suppressed on the Internet and it is
fortunate 
> when it can happen in the IETF.
I think one topic to discuss during the BOF meeting should be to understand
why the decision to not standardize audio/speech codecs in IETF taken a few
years ago should be changed. Here is part of the AVT charter: "The group
continues to be precluded from work on codecs themselves because of overlap
with the other standards bodies, and because the IETF does not have the
ability to effectively review new codecs."
Did this situation change? 

> Strictly IMO, innovation cannot be suppressed on the Internet and it is
fortunate 
> when it can happen in the IETF.
Innovation exists and not only in IETF. I think many codecs from other SDOs
have a lot innovation.

Best regards

Herve

Thanks, Henry

On 6/22/09 1:22 PM, "[email-masked]"
<[email-masked]> wrote:
Hello Roni, All

ITU-T and 3GPP have already specified a wide portfolio of speech & audio
codecs including Royalty Free codecs (for narrowband, wideband,
superwideband...) with purpose to answer the needs of all conversational
services (including new multimedia services over IP) and ensure end to end
interoperability. Many of these codecs are already deployed and successfully
used to answer the requirements of most of all voice services all over the
world (over Circuit Switched, IP and Internet networks...). New extensions
of these codecs have been or are being standardized to extend the quality
towards very high fullband/stereo quality.

With respect to the end to end interoperability issue, this codec portfolio
is even already too large considering the need to reduce networks additional
costs and quality degradations due to transcoding operations.

Adding new IETF standardized codecs to this (with probably little or no
coordination with other SDOs) would make no sense: those codecs would
obviously compete with the ones from ITU-T or 3GPP and any other legacy
codecs already widely deployed which would confuse the market, degrade the
overall end to end voice&audio interoperability and quality and increase the
transcoding costs in networks.

Furthermore, IETF is not the place where sufficient codec expertise is
gathered to standardize state of the art codecs (as in Technical Groups SA4
of 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple
Standard Bodies would not help with creating quality codecs; this concerns
not only the expertise and works needed for codec design but also all what
is related to voice & audio quality assessment.

Best regards

Stéphane Proust

De : [email-masked] [mailto:[email-masked]] De la part de
Ron Even
Envoyé : vendredi 19 juin 2009 17:59
À : [email-masked]
Objet : Re: [codec] Codec BOF approved, much work needed

Cullen,

I looked at the agenda

  - Agenda bashing

Roni Even

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 23 Jun 2009 09:00:55 +0200

Hi all,

if you plan to do something innovative and to develop a disruptive
technology, it is better to give it a new name. May be the naming of this
working group should be reconsidered. 

If it would not be named “codec” but something else like audio layer or xyz
protocol framework, we will have some advantages

First, we would not end up doing the old codec standardization and its old
traditions but try to think on how to achieve a superb interactive audio
transmission for all Internet users. We would get more freedom in going new
ways and need to fall into the trap that the traditional coding experts say:
“If you want to make a codec, you have it to do it like that…”

Second, the 3GPP and ITU codec guys would not worry as much. We could say,
“No we are not doing just a codec, we are developing the Internet’s audio
layer. It’s something different.” 

If this WG will then end up in rubberstamping CELT, adding some congestion
control or even a dejittering buffer, or following an entirely new, clean
slate design of a codec, is anyhow up to its proponents.

With best regards,

 Christan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Monday, June 22, 2009 8:46 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi Stéphane,

I am not sure how much you have followed the list, but did you notice the
posts regarding one  of the top requirements to be royalty free,  to our
best knowledge (IETF Note Well)?

Also this has been discussed at length; and credible and willing experts
found
<IETF is not the place where sufficient codec expertise is gathered to
standardize state of the art codecs...

Do we need to recap all these discussions? 
The proposed BOF will definitely be very productive in the eyes of its
proponents.
Strictly IMO, innovation cannot be suppressed on the Internet and it is
fortunate when it can happen in the IETF.

Thanks, Henry

Hello Roni, All

Best regards

Stéphane Proust

Cullen,

I looked at the agenda

  - Agenda bashing

Roni Even

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Jun 2009 23:09:03 -0700

Roni,

The primary goal of this BOF should be collecting the information that  
helps make an informed decision about if a WG should be formed or not.  
I certainly did not mean to imply by the agenda that there was any  
assumption that a WG would be formed.

I agree the charter below is far from ideal for collecting this  
information. I'm expecting the agenda to change, based on the list  
discussion, so we have time to talk about the key topics where  
community input is needed to drive the decisions about if a WG should  
be formed or not.

Cullen <RAI AD>

On Jun 19, 2009, at 8:59 , Ron Even wrote:

> I am not sure that that this was agreed and yet I see no time  
> allocated to discuss the topic. I would expect that item 3 will be  
> rational for doing codec at the IETF considering that this work is  
> done also by other SDOs that the IETF is working with.
>
> BOF which one will be standardize, to me it looks like this should  
> be done later.
>
> Roni Even
>
>
>
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Jun 2009 10:39:33 +0300

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am
suggesting this item since as far as I understand after iLBC publication the
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify for
approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.

I think that only after these topics, which looks to me like ground rules,
are addressed we can start discussing the content of the charter. 

Roni Even

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: [email-masked]

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 26 Jun 2009 12:48:09 -0700

Cullen,

Roni Even wrote
>>1. Should the IETF work on codecs?

These arguments have been repeated countless time on the list.
 There is not reason to waste precious BOF face-to-face time by regurgitating them again.
It definitely has the appearance legacy codec people will go to great length to keep newcomers out; and suppress even discussing the potential Internet and software technologies that could innovate voice codecs for use on the Internet.

Take for example the usage scenario of rich internet applications in the browser and/or desktop.
Countless new applications, business models and software development techniques for the web have made legacy codecs undesirable or even inapplicable for such as enabling voice for content providers, social networks, any type of business imaginable and for no-profits alike. Especially for non-profits.

For example, web sites for broadcasting sport events, political events or social network can have huge traffic surges that are often completely event driven. Traffic may practically disappear after the event.

Nobody can also predict the success (or otherwise) and traffic for any web site or web based service.
Moreover, nobody expects to pay for a browser and plug-ins.

 1.  Business models are different than they were for legacy codecs,
 2.  Technology is also vastly different, from every facet.

Let the agenda for the BOF explore and inform about this potential,
though I understand the stake legacy codec people have to suppress this information in the first place.

(My individual contributor hat on)
Henry

On 6/26/09 2:39 AM, "Roni Even" <[email-masked]> wrote:

Cullen,
Thanks,

Roni Even

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 26 Jun 2009 16:17:21 -0700

Hi Henry,

as you probably expect, I disagree.  It¹s not a waste of BOF time to discuss
whether the IETF should ³work on codecs².  However, I agree that this aspect
has received recently significant, probably even adequate, coverage on the
list, and unorganized repetition of the same arguments would not be overly
helpful, nor time-efficient.  Why not have the chairs, or the AD, summarize
the discussion here, and take an early humm on that question?
Alternatively, have the BOF hearing one advocate in favor, and one against,
and then take a humm?
Stephan

On 6/26/09 12:48 PM, "Henry Sinnreich" <[email-masked]> wrote:

> It definitely has the appearance legacy codec people will go to great length
> to keep newcomers out; and suppress even discussing the potential Internet and
> software technologies that could innovate voice codecs for use on the
> Internet.  
> 
> Countless new applications, business models and software development
> techniques for the web have made legacy codecs undesirable or even
> inapplicable for such as enabling voice for content providers, social
> networks, any type of business imaginable and for no-profits alike. Especially
> for non-profits.
> 
> For example, web sites for broadcasting sport events, political events or
> social network can have huge traffic surges that are often completely event
> driven. Traffic may practically disappear after the event.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Jun 2009 19:32:22 -0400

To put this a little differently, one of the primary uses for our 
face-to-face time is supposed to be to work out sticky questions that 
provoke lots of on-list discussion.

hence, the fact of the discussion, without clear resolution, is in fact 
a good indication that it would be a reasonable topic for the BoF.

And, looked at from the quesiton of what a BoF is for, it is to evaluate 
whether the work makes sense for the IETF, and if it makes sense, 
exactly what we should do.  Declaring that the BoF should not discuss 
the central topic on which there is significant disagreement seems very 
wrong.

Yes, it takes some organizing so that the discussion does not devolve 
into people shouting at each other at the microphone.  That does not do 
anyone any good.  But we (the IETF) have defined criteria for these 
things, and a careful discussion of whether
a) the purpose and capabilities match the criteria;
b) whether the stated purposes are achievable and reviewable in this 
community;
both seem to be dimensions worthy of explicit discussion at the BoF.

In my understanding, the use of BoF time for charter refinement, or even 
more clearly, for solution review, really needs to come after 
appropriate time has been given to the first dimension, if there is 
disagreement.
Of course different topics need different handling.  Some topics the 
real task for the BoF is to find a single problem that everyone agrees 
on (because folks have been, in some cases, talking about different 
problems under the same name.)  That does not appear to be the issue here.
Some BoFs need extensive discussion about the charter, because the folks 
pushing really want to solve more than can be done.  (Some folks like 
trying to drain the ocean.  We try to discourage it.)
But this case, the disagreement is very basic, and it would seem quite 
necessary and appropraite to address it with a significant portion of 
the BoF time.

Yours,
Joel

Stephan Wenger wrote:
>   Hi Henry,
> 
> as you probably expect, I disagree.  It’s not a waste of BOF time to 
> discuss whether the IETF should “work on codecs”.  However, I agree that 
> this aspect has received recently significant, probably even adequate, 
> coverage on the list, and unorganized repetition of the same arguments 
> would not be overly helpful, nor time-efficient.  Why not have the 
> chairs, or the AD, summarize the discussion here, and take an early humm 
> on that question?  Alternatively, have the BOF hearing one advocate in 
> favor, and one against, and then take a humm?  
> Stephan
> 
> 
> 
> 
> 
>     It definitely has the appearance legacy codec people will go to
>     great length to keep newcomers out; and suppress even discussing the
>     potential Internet and software technologies that could innovate
>     voice codecs for use on the Internet.  
> 
>     inapplicable for such as enabling voice for content providers,
>     social networks, any type of business imaginable and for no-profits
>     alike. Especially for non-profits.
> 
>     For example, web sites for broadcasting sport events, political
>     events or social network can have huge traffic surges that are often
>     completely event driven. Traffic may practically disappear after the
>     event.
> 
>         >  > And it looks to me that it starts with assumption that we
>         will have
>         >  > a new working group.
>         >  >
>         CODECS is
>         values. So
>         >  > > From: [email-masked]
>         [mailto:[email-masked]] On
>         >  > Behalf
>         >  > > Of Cullen Jennings
>         >  > > some of the discussion I have had off list people talked
>         about how
>         >  > we
>         >  > > wanted a codec that supported adaptive bit rates that
>         could change
>         >  > on
>         >  > > Do we need a new codec or are there already ones defined
>         that meet
>         >  > the
>         >  > > needs?
>         >  > >
>         >  > > I have asked Jason Fischl  and Jean-Marc Valin to co-chair
>         this
>         >  BOF.
>         >  > >
>         >  > > Thanks,
>         >  > >
>         >  > > Cullen <RAI AD>
>         >  > >
>         >  > >
>         >  > >
>         >  > >
>         >  > >
> ------------------------------------------------------------------------
>

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 27 Jun 2009 12:37:52 -0700

Stephan,

The idea of summarizing the discussion is excellent IMO.

Humming is not a good idea since it favors people with a travel budget to attend,
and also IMO favors groupthink.
When the demographics of attendees favors incumbent codec vendors, I like it even less :-)

Henry

On 6/26/09 6:17 PM, "Stephan Wenger" <[email-masked]> wrote:

Hi Henry,

as you probably expect, I disagree.  It's not a waste of BOF time to discuss whether the IETF should "work on codecs".  However, I agree that this aspect has received recently significant, probably even adequate, coverage on the list, and unorganized repetition of the same arguments would not be overly helpful, nor time-efficient.  Why not have the chairs, or the AD, summarize the discussion here, and take an early humm on that question?  Alternatively, have the BOF hearing one advocate in favor, and one against, and then take a humm?
Stephan

Cullen,

Roni Even wrote

Cullen,
Thanks,

Roni Even