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

Ron <ron@debian.org> Wed, 03 February 2016 05:35 UTC

Return-Path: <ron@debian.org>
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 ADB251A1B71; Tue, 2 Feb 2016 21:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 oTOKMoQ3f-dY; Tue, 2 Feb 2016 21:35:50 -0800 (PST)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77E1A1B6A; Tue, 2 Feb 2016 21:35:49 -0800 (PST)
Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Feb 2016 16:05:48 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 53AA4FFC9E; Wed, 3 Feb 2016 16:05:47 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QV9Q7TP7ZUaE; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id BA677FFAA4; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id A97C680470; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT)
Date: Wed, 03 Feb 2016 16:05:46 +1030
From: Ron <ron@debian.org>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Message-ID: <20160203053546.GP3153@hex.shelbyville.oz>
References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <56B17FC4.7000901@xiph.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/OHs18W9Y1AtQnw6nPP-loR43QTo>
Cc: "draft-ietf-codec-oggopus@ietf.org" <draft-ietf-codec-oggopus@ietf.org>, "codec@ietf.org" <codec@ietf.org>, "codec-chairs@ietf.org" <codec-chairs@ietf.org>, "ietf@ietf.org" <ietf@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, 03 Feb 2016 05:35:51 -0000

On Tue, Feb 02, 2016 at 08:19:16PM -0800, Timothy B. Terriberry wrote:
> Ron wrote:
> >And we are specifically not proposing to give *anyone*, open source or
> >otherwise, "the option to take an RFC and “run with it”" ...
> >
> >We're trying to find consensus on the best way to apply BCP 78 and the
> >options outlined in RFC 5377 to the needs of this document, in a way
> >that best matches the needs of its intended users to the best interests
> >of the IETF.
> 
> It seems to me like putting a BSD copyright header in an XML comment at the
> top of the XML source file and dropping Section 13 from the draft would
> resolve all of the issues, if everyone agrees that is an acceptable thing to
> do. Ron?

It leaves us with the issue of creating a perverse incentive for some
parties to prefer distributing the "non-rfc" version over the official
RFC - even when they themselves have not modified it and don't have
any direct plans to.  And in some cases, will force their hand, making
that the only version they can redistribute ...

But aside from that, I think it would cover the practical problems
which we currently see for implementors needing to use this in their
own work.  Which is the most immediate issue here.

It's not my first preference, and not what I think serves the IETF's
interest best, for all of the reasons I've outlined earlier in this
thread -- but if we can't get consensus for adding a RFC 5377 4.3
exception to add the "Rights Granted for Implementing" to it, and
nobody has a better suggestion, then I can accept this option as the
pragmatic way we should proceed here.


I think both options are in the scope of current recommendations to
allow, but I'll defer to peer review on that.