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

Cullen Jennings <fluffy@cisco.com> Tue, 19 April 2011 14:51 UTC

Return-Path: <fluffy@cisco.com>
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 BAD1EE06BE for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 07:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 uz2ST9z+R7La for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 07:51:36 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 8F6FCE0664 for <codec@ietf.org>; Tue, 19 Apr 2011 07:51:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2780; q=dns/txt; s=iport; t=1303224696; x=1304434296; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mAWhFiKE6MLB8nkKCZPq3FVt8hb9z2H/Lx35g5v3iCI=; b=SJML4sIXLgFdr2k+JOu0L5XI7JunOEjeU1gPhAp+6ODUZGun9eCi6FK9 5AuIPKbSs++dTTSBc5ZRrh+0rk6kJow9qL94MM7dZbWhCe7J4BNV6lClR S61kUbcaizWzFGN7y/nxwgdEeSiDE8qEHRWDw0etLamKBxy/6Sy1+UwCo o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkwEAOugrU2Q/khLgWdsb2JhbAClKxQBARYmJYhvnyOcZ4VxBIVniCCDfA
X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="26305001"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2011 14:51:35 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JEpXgO003377; Tue, 19 Apr 2011 14:51:34 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC8BD1@LHREML503-MBX.china.huawei.com>
Date: Tue, 19 Apr 2011 08:51:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <39E897DF-CF5F-4CD1-A484-3A824B2D2AF8@cisco.com>
References: <C9CB2798.2A7EB%stewe@stewe.org> <6701DDCA-62E6-4257-8F32-AE127FE2DFDC@cisco.com> <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC8BD1@LHREML503-MBX.china.huawei.com>
To: Anisse Taleb <Anisse.Taleb@huawei.com>
X-Mailer: Apple Mail (2.1084)
Cc: "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: Tue, 19 Apr 2011 14:51:37 -0000

inline ...

On Apr 18, 2011, at 5:51 PM, Anisse Taleb wrote:

> Dear Cullen,
> I understand that there is no formal process in IETF to solve the issue of encumbrance of the codec. However, a large part of the debate about the work conducted here is related either directly or indirectly to the encumbrance of the codec. Even when it comes to testing and requirements, we have heard objections to comparing to state of the art codecs because they are encumbered. I do not have any solution to this, but my feeling is that a major part of the decision to publish a codec will be based on the level of encumbrance of the codec.

For pretty much any working group, the question in the end largely comes down to "is this draft ready to publish?". With this spec,  the questions of if opus is royalty free or not will be an important factor in many peoples decisions but it's not a topic the WG tries to directly deal with. The individuals will have to tackle that outside the IETF. Other factors that are important to the decision are how well does it meet the requirements, how well does it meet the needs of some market segment that may be different than what is in the requirements, is the draft good enough that it will lead to interoperable implementations, and does anyone want to use it. 

Many people in this WG have no desire for another codec that is not RF. Theses people are interested in how opus compares to RF codecs. If opus offers better perforce over existing RF codecs, and they people outside the IETF WG decide they believe opus has good odds of being RF, they will probably be in favor of publishing it. If either of those two condition are not meant, I would expect them to probably not be in favor of publishing opus. There are probably some people that are interested in opus regardless of if opus is RF or not. Those people are probably interested in how opus compares to both RF and non RF existing codecs. (As a side note, how opus compares to any codec is always interesting and useful to know but from the scope of the charter, I think that how it compares to RF codecs is a higher priority item for this WG) 

So I 100% agree with you that when individuals go and decide if they think we should publish a given draft, the probability of it being RF is likely to be a major factor in the decision for many people. The IETF wants to clearly point out to people the IPR disclosures that have been received, but the IETF does not want to be a place were we try and sort out the validity of the IPR. 

Hope that helps, 
Cullen

PS - Stephan is the IPR advisor for the WG and I hope he corrects me if I got any of the above wrong.