Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Robert Elz <kre@munnari.OZ.AU> Thu, 24 December 2009 09:49 UTC

Return-Path: <kre@munnari.OZ.AU>
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 095BE3A67E1; Thu, 24 Dec 2009 01:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level:
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
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 EcQDQzb9+OnJ; Thu, 24 Dec 2009 01:49:40 -0800 (PST)
Received: from jade.coe.psu.ac.th (unknown [202.29.151.3]) by core3.amsl.com (Postfix) with ESMTP id 779323A67AD; Thu, 24 Dec 2009 01:49:39 -0800 (PST)
Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id nBO9lr79021633; Thu, 24 Dec 2009 16:47:55 +0700 (ICT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.3/8.14.2) with ESMTP id nBO9lGg1027662; Thu, 24 Dec 2009 16:47:23 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Roni Even <ron.even.tlv@gmail.com>
In-Reply-To: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com>
References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Dec 2009 16:47:16 +0700
Message-ID: <2401.1261648036@epsilon.noi.kre.to>
Sender: kre@munnari.OZ.AU
X-Mailman-Approved-At: Thu, 24 Dec 2009 04:53:43 -0800
Cc: codec@ietf.org, "'Tschofenig, Hannes (NSN - FI/Espoo)'" <hannes.tschofenig@nsn.com>, iesg@ietf.org, ietf@ietf.org
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
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: Thu, 24 Dec 2009 09:49:41 -0000

    Date:        Thu, 24 Dec 2009 08:50:30 +0200
    From:        "Roni Even" <ron.even.tlv@gmail.com>
    Message-ID:  <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com>

  | I am not sure but are you suggesting that the IETF will define the
  | requirements, metric and quality assessment requirements and all proposed
  | codecs should provide the results and then the WG will choose the best codec
  | bases without discussing the codec itself. This is what I would call a
  | selection process (at least in ITU terms).

The WG can decide how it wants to go about the process, I'd just prefer that
the charter not (effectively) rule out selection of something that already
exists with an assumption that something entirely new will be created.

  | The problem is that the IETF process allows anyone to contribute to existing
  | work hopefully leading to a better the end result.

Of course, but also be aware that there's no one definition of "better".
Something that can be defined quickly and used immediately might be much
better than something it takes 5 years to create and more to implement,
even if the invented one saves a little bandwidth or has better loss
recovery characteristics.

  | What about the change control, does it stay with the original contributor or
  | can the IETF modify the codec based on input from other parties, which means
  | that the codec may change by the IETF anyhow. 

The IETF will have change control over its protocol, of course, which may
cause it to diverge from that upon which it was originally based.  And yes,
everything changes with time.

kre