Re: [codec] draft test and processing plan for the IETF Codec

Peter Saint-Andre <stpeter@stpeter.im> Wed, 13 April 2011 18:07 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40A40E075D for <codec@ietfc.amsl.com>; Wed, 13 Apr 2011 11:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.296
X-Spam-Level:
X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V6NA7QEfMHu for <codec@ietfc.amsl.com>; Wed, 13 Apr 2011 11:07:17 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 31EE0E073E for <codec@ietf.org>; Wed, 13 Apr 2011 11:07:17 -0700 (PDT)
Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A354240D20; Wed, 13 Apr 2011 12:10:18 -0600 (MDT)
Message-ID: <4DA5E653.3020002@stpeter.im>
Date: Wed, 13 Apr 2011 12:07:15 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Botzko <stephen.botzko@gmail.com>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <4DA5A748.2050401@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF17ACA9B583@ESESSCMS0351.eemea.ericsson.se> <4DA5D328.3060504@stpeter.im> <BANLkTi=DkC8HFSFzQ8q=xWU+zVL7D_aazA@mail.gmail.com>
In-Reply-To: <BANLkTi=DkC8HFSFzQ8q=xWU+zVL7D_aazA@mail.gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070901090400020502050702"
Cc: "bens@alum.mit.edu" <bens@alum.mit.edu>, "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] draft test and processing plan for the IETF Codec
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 13 Apr 2011 18:07:18 -0000

On 4/13/11 11:57 AM, Stephen Botzko wrote:
> in-line
> Stephen
> 
> On Wed, Apr 13, 2011 at 12:45 PM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
> 
>     On 4/13/11 8:48 AM, Erik Norvell wrote:
>     > Hi Ben, all
>     >
>     > If the codec is not ready for testing, then I cannot see how it could
>     > be ready for standardization. To me the steps would be
>     >
>     > - freeze the codec when it is stable - test and evaluate - check if
>     > requirements are met a) if yes standardize b) if not do not
>     > standarize and rather go back and improve
>     >
>     > Informal testing should still be done during development to eliminate
>     > the risk of b).
> 
>     My understanding is that informal testing has already been done by quite
>     a few participants in this WG.
> 
>  
> Yes, and Erik is simply suggesting that should continue while the codec
> development is underway.

Yep, testing is good. Let's keep doing it. :)

>     > I also think the encumbrance of the codec is unclear at this point
>     > and I don't think rushing to finalize the standard would serve the
>     > purpose of this WG. Due to the encumbrance there may still be changes
>     > required which may affect the quality, and the final testing should
>     > begin after this has been resolved.
> 
>     We knew when we started this process that there might be encumbrances.
>     We even knew that there might be unreported encumbrances that would
>     emerge only after the codec was published as an RFC, or only after the
>     code was in use by companies who would be big targets for patent
>     lawsuits. I see no reason to delay publication until all possible
>     encumbrances have been resolved, whatever that means (as we all know,
>     patent claims are not resolved at the IETF, they are resolved in courts
>     of law).
> 
> 
> I think Erik was simply referring to the ongoing work already started by
> the codec developers [whatever-it-is that is being done in response to
> the Qualcomm declaration]. 
> It sounds like you are suggesting this work should be halted, and we
> should simply publish the current codec version???  It would be
> interesting to know who else would agree with that proposal.

I am suggesting no such thing. What I'm saying is that we could delay
publication *forever* if people want 100% assurance that Opus is
patent-clear. Since we know (and have always known) that we can't gain
such assurance, I'm suggesting that the WG needs to figure out how to
proceed.

My opinion is that delaying forever would be bad.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/