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

"Ben Campbell" <ben@nostrum.com> Wed, 27 January 2016 21:09 UTC

Return-Path: <ben@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 9877C1ACE03; Wed, 27 Jan 2016 13:09:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 CSplbYaF2ejH; Wed, 27 Jan 2016 13:09:49 -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 DA83A1ACDFB; Wed, 27 Jan 2016 13:09:49 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0RL9lwq097400 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2016 15:09:47 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 27 Jan 2016 15:09:47 -0600
Message-ID: <EF7A1BC5-B0E9-4787-95D2-D60B590E26DB@nostrum.com>
In-Reply-To: <56A92C39.7060206@nostrum.com>
References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/XmaqaG-B58Uqnro3DsEJkVALd6U>
Cc: codec-chairs@ietf.org, codec@ietf.org, ietf@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: Wed, 27 Jan 2016 21:09:51 -0000

On 27 Jan 2016, at 14:44, 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).

For the record, the rights grant in RFC 6716 covered the textual parts 
in addition to the code parts. Given that the code components are 
already covered by the BSD licensing option in the TLP, this seems 
mainly relevant to the textual parts.

I don't mean to refer to that as precedent; only to suggest that if 
people think it's not appropriate now, it might not have been a good 
idea then either.

>
> I do not think it is the right thing to do for this document.
>
> It would have been better if the document, or the shepherd's writeup, 
> spelled this issue out. For now, Ron's message at 
> <https://mailarchive.ietf.org/arch/msg/codec/5pl4RhroYqB9vLRnOyeIKOC8lkA> 
> is a good place to start - scroll down to the section starting "The 
> crux here is twofold."

Thanks for spelling it out now :-)

>
> RjS
>
>
>
>
> On 1/13/16 8:15 AM, The IESG wrote:
>> The IESG has received a request from the Internet Wideband Audio 
>> Codec WG
>> (codec) to consider the following document:
>> - 'Ogg Encapsulation for the Opus Audio Codec'
>> <draft-ietf-codec-oggopus-10.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to 
>> the
>> ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments 
>> may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>> This document defines the Ogg encapsulation for the Opus interactive
>> speech and audio codec.  This allows data encoded in the Opus format
>> to be stored in an Ogg logical bitstream.
>>
>> Please note that the document makes normative references to RFCs 3533 
>> and 4732, which are informational.
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>