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

Russ Housley <housley@vigilsec.com> Thu, 07 January 2010 16:46 UTC

Return-Path: <housley@vigilsec.com>
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 6FC603A6809; Thu, 7 Jan 2010 08:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.655
X-Spam-Level:
X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 p-yLTk44z3Ve; Thu, 7 Jan 2010 08:46:51 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 85E663A63C9; Thu, 7 Jan 2010 08:46:51 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 145269A4737; Thu, 7 Jan 2010 11:47:03 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lchPUKefK9fG; Thu, 7 Jan 2010 11:46:49 -0500 (EST)
Received: from [192.168.2.113] (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 705629A4726; Thu, 7 Jan 2010 11:47:02 -0500 (EST)
Message-ID: <4B460FF9.5020303@vigilsec.com>
Date: Thu, 07 Jan 2010 11:46:49 -0500
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: "Andrew G. Malis" <agmalis@gmail.com>
References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> <a123a5d60912241926l6f2255e3kc15d1d21573adeb9@mail.gmail.com> <B67FB114-FDA9-4431-A2E2-6ACF344B2EA7@cisco.com> <tslpr5p4hor.fsf@mit.edu> <024e01ca8da8$727e6a70$577b3f50$@us> <4b4380c6.0e1abc0a.5a80.ffffcd97@mx.google.com> <4B44119A.6020904@stpeter.im> <4B44154E.6070007@bogus.com> <8c99930d1001061459yacf631dtd8c3498faa1050d5@mail.gmail.com>
In-Reply-To: <8c99930d1001061459yacf631dtd8c3498faa1050d5@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 07 Jan 2010 08:54:45 -0800
Cc: codec@ietf.org, ietf@ietf.org, iesg@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, 07 Jan 2010 16:46:52 -0000

Andy:

>> Although this preference cannot guarantee that the working
>> group will produce an unencumbered codec, the working group shall
>> attempt to adhere to the spirit of BCP 79.  This preference does not
>> explicitly rule out the possibility of adapting encumbered technologies;
>> such decisions will be made in accordance with the rough consensus of
>> the working group.
 >
> I appreciate the potential difficulty of guaranteeing the unencumbered
> status of any output of this group. However, I would like this statement to
> be stronger, saying that this group will only produce a new codec if it is
> strongly believed by WG rough consensus to either be unencumbered,
> or freely licensed by the IPR holder(s), if any.

I do not think that anyone wants the outcome to be yet another 
encumbered codec.  I think these words are trying to say what you want, 
but they are also trying to be realistic.

Does the following text strike a better balance?

   Although this preference cannot guarantee that the working
   group will produce an unencumbered codec, the working group shall
   follow BCP 79, and adhere to the spirit of BCP 79.  The working
   group cannot explicitly rule out the possibility of adapting
   encumbered technologies; however, the working group will try to
   avoid encumbered technologies that require royalties.

Russ