Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard

Robert Sparks <rjsparks@nostrum.com> Tue, 02 February 2016 20:51 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D012C1B30F9; Tue, 2 Feb 2016 12:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74tXRBvtVfou; Tue, 2 Feb 2016 12:51:45 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E188D1B3059; Tue, 2 Feb 2016 12:51:45 -0800 (PST)
Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u12KpcmR040803 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 2 Feb 2016 14:51:38 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local
To: Ron <ron@debian.org>
References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <56B116DA.9010507@nostrum.com>
Date: Tue, 02 Feb 2016 14:51:38 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160129031044.GB3153@hex.shelbyville.oz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/AvHV7QVM2mepzHfODu7akDOr7fg>
Cc: ietf@ietf.org, codec@ietf.org, codec-chairs@ietf.org, draft-ietf-codec-oggopus@ietf.org
Subject: Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Feb 2016 20:51:47 -0000

Ben's recent response to Tim captures the main point, but to reinforce 
what's said there:

We learned a lot as a community from going through the development of 
RFC6716, and there's been  strong sentiment expressed that we wouldn't 
do things like produce normative code again. I think if we were able to 
repeat the exercise fresh, knowing what we learned, that we also 
wouldn't have made this copyright change in just this way. However, the 
most relevant point is that with RFC6716 we at least had an exceptional 
condition to point to. This draft does not have that.

It is not clear to me how the things you are hoping to achieve with this 
extra language are not already available to you (under fair use for 
example). In the copy below, you elided my suggestion that the draft 
argue why the existing boilerplate is insufficient.

It _is_ fairly clear to me that the kind of change you're asking for is 
not really specific to this draft, though.
The community developed a set of acceptable boilerplate text blocks. The 
draft should use what we have, or convince the community that we need to 
change what we allow for RFCs.

RjS

On 1/28/16 9:10 PM, Ron wrote:
> Hi Robert,
>
> On Wed, Jan 27, 2016 at 02:44:41PM -0600, Robert Sparks wrote:
>> This document has an unusual feature that I think needs to be highlighted in
>> this last call.
>>
>> Section 13 instructs the RFC editor to:
>>>     In the Copyright Notice at the start of the document, the following
>>>     paragraph is to be appended after the regular copyright notice text:
>>>
>>>     "The licenses granted by the IETF Trust to this RFC under Section 3.c
>>>     of the Trust Legal Provisions shall also include the right to extract
>>>     text from Sections 1 through 14 of this RFC and create derivative
>>>     works from these extracts, and to copy, publish, display, and
>>>     distribute such derivative works in any medium and for any purpose,
>>>     provided that no such derivative work shall be presented, displayed,
>>>     or published in a manner that states or implies that it is part of
>>>     this RFC or any other IETF Document."
>> I understand why we did what we did for RFC6716 (the specification for OPUS,
>> where the additional grants were to deal with the code being normative).
>>
>> I do not think it is the right thing to do for this document.
> Could you spell out in a bit more detail what you see as being different
> for this document, and what your concerns are with either (or both!) the
> letter and the intent in this case.
>
> I really would like to understand your concerns, and if necessary have
> this evolve into language that does cover everyone's needs and fears as
> comprehensively as we can.
>
> We've got nearly 4 years behind us now with no terrible abuse of this
> grant having occurred for 6716, but if you think it's less than ideal,
> I'd like us to consider ways we can still improve on that.
>
>    Cheers,
>    Ron
>
>