Re: [codec] Last Call: <draft-ietf-codec-opus-12.txt> (Definition of the Opus Audio Codec) to Proposed Standard

Ron <ron@debian.org> Tue, 01 May 2012 01:40 UTC

Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A521E80F4; Mon, 30 Apr 2012 18:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu2obWOmrXZM; Mon, 30 Apr 2012 18:40:43 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id B8FEB21E8011; Mon, 30 Apr 2012 18:40:42 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAGQ+n095LXH5/2dsb2JhbABEr2aCf4EIggkBAQU6HCMQCw4KIwsUGA0kiB+6NZAsYwSIYoUvh2wBkEKCeA
Received: from ppp121-45-113-249.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.113.249]) by ipmail06.adl6.internode.on.net with ESMTP; 01 May 2012 11:10:40 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 68A224F8F3; Tue, 1 May 2012 11:10:38 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rcjKB0XYAb4z; Tue, 1 May 2012 11:10:37 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C8FD54F8FE; Tue, 1 May 2012 11:10:37 +0930 (CST)
Date: Tue, 01 May 2012 11:10:37 +0930
From: Ron <ron@debian.org>
To: Stephan Wenger <stewe@stewe.org>
Message-ID: <20120501014037.GA18009@audi.shelbyville.oz>
References: <6.2.5.6.2.20120430120153.0947ed48@resistor.net> <CBC4E0F3.867E4%stewe@stewe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CBC4E0F3.867E4%stewe@stewe.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: SM <sm@resistor.net>, "codec-chairs@tools.ietf.org" <codec-chairs@tools.ietf.org>, "codec@ietf.org" <codec@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [codec] Last Call: <draft-ietf-codec-opus-12.txt> (Definition of the Opus Audio Codec) to Proposed Standard
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, 01 May 2012 01:40:43 -0000

Hi Stephan,

On Mon, Apr 30, 2012 at 10:53:13PM +0000, Stephan Wenger wrote:
> The question of whether a section in the subject doc is
> the right place for such a grant has not yet been answered.
> My view on the latter: it's not.  One issue of having such a notice is
> that it expressly allows derivative work, possibly WITHOUT removing the
> IETF boilerplate and the TLP copyright notice first.

Except that the additional grant explicitly requires that:

 "redistributed modified works do not contain misleading author, version,
  name of work, or endorsement information."

And my understanding is that the sort of misrepresentations which you suggest
are already well protected against in established law.  So I don't think that
this would weaken the IETF's position in the event of such a thing happening,
and I'm not aware of any such problem occurring with any of the RFCs that are
already published containing such a grant.  Similarly there exist other RFCs
which already have external grants too, and there has been no hint of trouble
or an inability to prevent it if it arose with those either, has there?

If this clause becomes a blocker, then we should simply remove it, but in that
case it would be good to have clear reasons why it became a blocker, since the
things you say you fear here, I see as already being prohibited anyway.


I agree with you that this is an entirely separate issue to the validity or
other implications of any of the IPR claims though.  But on that note, have
you had any clarification from Huawei as to whether they believe their newly
acquired patent actually does read on this technology?  Last I had heard on
that there was some doubt and they were still studying it?  It would be nice
to have them officially clear that up.

Cheers,
Ron