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
- [codec] Last Call: <draft-ietf-codec-opus-12.txt>… The IESG
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Kevin P. Fleming
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Jean-Marc Valin
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Kevin P. Fleming
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Cullen Jennings
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Cullen Jennings
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Ron
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Ron
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… Sam Hartman
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… SM
- Re: [codec] Last Call: <draft-ietf-codec-opus-12.… SM