Re: [codec] Codec guidelines and requirements drafts

Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> Sat, 05 September 2009 14:59 UTC

Return-Path: <jean-marc.valin@usherbrooke.ca>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57E53A684B for <codec@core3.amsl.com>; Sat, 5 Sep 2009 07:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Level:
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNg8xGTivuEM for <codec@core3.amsl.com>; Sat, 5 Sep 2009 07:59:56 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id E3E7A3A67FE for <codec@ietf.org>; Sat, 5 Sep 2009 07:59:55 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: text/plain; charset="ISO-8859-1"
Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KPI006W13RPBOD0@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Sat, 05 Sep 2009 09:50:14 -0400 (EDT)
Message-id: <4AA26C95.8090504@usherbrooke.ca>
Date: Sat, 05 Sep 2009 09:50:13 -0400
From: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
To: Alexander Chemeris <Alexander.Chemeris@sipez.com>
References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com>
In-reply-to: <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com>
X-Enigmail-Version: 0.95.2
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] Codec guidelines and requirements drafts
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2009 14:59:56 -0000

Alexander Chemeris a écrit :
> Here are the second part of my notes on drafts, non-technical part:
> 
> 1) It should be clearly defined, that codec evaluation MUST be done for
> several languages, taking into account diferent types of them - e.g. tonal
> languages, caucasian languages, etc. If we aim at creating a world-wide
> codec, it should work good for more then English and few european
> languages.

I think this actually belongs to the requirements, but otherwise I
totally agree that this is currently missing.

> 2) Section 2, bullet 4: "Once a sufficient number of proposals has been
> received...". It should be clearly defined when it this "sufficient" number
> is reached. I actually don't like the word "sufficient", because it's not
> clean, sufficient for what is meant here.

Will try and come up with something clearer. In any case, it's not that
much about numbers as it is about having all the "building blocks"
required. Any thoughts?

> 3) Some time frames must be defined. At least it should be clearly
> stated that the effort aims at providing working codec in 1yr, 5yrs,
> 100yrs, etc. Taking into account the size of the goal, it might take
> indefinite time to achieve and should be limited.

Someone more knowledgeable of the IETF process can correct me if I'm
wrong here, but my understanding is that the time frame belongs to the
charter "milestones" section.

> 4) In Section 3.1:
>    A more subtle aspect is the information leak that can occur when the
>    codec is used over an encrypted channel (e.g.  [SRTP]).  For example,
>    it was suggested [wright08] that use of source-controlled VBR may
>    reveal some information about a conversation through the size of the
>    compressed packets.  This would have to be investigated when
>    standardizing a codec.
> At least it sohuld be specified how it's planned to be investigated? What
> is should be the result of such investigation? Actually I don't see why
> it should be done in the scope of this effort.

I think this is where cross area review is useful. I assume that in the
worst case, we would end up with using only CBR for SRTP.

Cheers,

	Jean-Marc

> 
> On Fri, Sep 4, 2009 at 23:06, Jean-Marc
> Valin<jean-marc.valin@octasic.com> wrote:
>> Hi,
>>
>> As a follow-up to the codec BoF in Stockholm, a group of interested IETF
>> participants has been working on how to move forward regarding this work at
>> the IETF.  As a result, today we have submitted two Internet-Drafts:
>>
>> (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt
>> (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt
>>
>> We welcome feedback on these drafts on the codec@ietf.org list.
>>
>> Cheers,
>>
>>        Jean-Marc
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>
> 
> 
>