Re: [video-codec] Charter issues from BoF

Spencer Dawkins <spencer@wonderhamster.org> Thu, 06 December 2012 18:07 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFF521F87C8 for <video-codec@ietfa.amsl.com>; Thu, 6 Dec 2012 10:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmiW4i-HA0q5 for <video-codec@ietfa.amsl.com>; Thu, 6 Dec 2012 10:07:48 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CD79721F87C0 for <video-codec@ietf.org>; Thu, 6 Dec 2012 10:07:35 -0800 (PST)
Received: from [132.177.126.194] (gtp126194.iol.unh.edu [132.177.126.194]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MgdCx-1TVJB41XFv-00O0cl; Thu, 06 Dec 2012 13:07:35 -0500
Message-ID: <50C0DEEC.5040901@wonderhamster.org>
Date: Thu, 06 Dec 2012 12:07:40 -0600
From: Spencer Dawkins <spencer@wonderhamster.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: video-codec@ietf.org
References: <20121106112625.2btpoxrylcgg8w4c@kizuka.merseine.nu> <509AC2B4.3010406@wonderhamster.org> <20121107153423.d93rypvha8w480wc@kizuka.merseine.nu> <50AAC17E.5000208@wonderhamster.org> <50BE9F0E.7070304@xiph.org>
In-Reply-To: <50BE9F0E.7070304@xiph.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:IHEziQdkZX/hv5R6D8B+i3kd8gt48RTdSezp+zZ/7Kd rtZdGhUnkVYDf7Rdw44kICHT5bRXWGweB0im+1c6IqZcoiE3HK F7dcBVKBfyjSUQpMbqMPn45td8sZU+tTtUP0sEz8rhnSv/BIQe iqzwVmFJ2N8+MnWgiJiLNIValqyPu8mrrZxtc4BtmcpllxFKGX TOjbZdpVUuqJkdoW47g+7fyzhB5QGe45CvXLd+HWfV7TCqKegx Fbbr06xRXRaYUA020SsbL1LAE07AKcDddHkOYEz82BpqNquTWg 22vAikTTaTBwwsEKx4w4fDwzJT4WLvr36jrwENn4QnNPjskEfp UYGFiS72h004IU2gz8ATHlW7wMZSpqYSFG3cOb9gz
Subject: Re: [video-codec] Charter issues from BoF
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/video-codec>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2012 18:07:49 -0000

Hi, Tim,

Thanks for your reply. Where you are seems, to me, to be well within the 
boundaries of the kind of decisions we rely on working groups to make, 
and rely on working group chairs to call consensus for.

On one specific point, and this is as much for your amusement as for 
your information ...

On 12/4/2012 7:10 PM, Timothy B. Terriberry wrote:
> Spencer Dawkins wrote:

>> I'd suggest the proposed working group community discuss whether it's
>> worth producing a video codec that is known to not be RF, early in the
>> process.
>
> There is some difficulty in deciding what "known to not be RF" means.
> Some people would take the existence of an IPR disclosure---any IPR
> disclosure---that does not make that IPR available under RF terms to be
> an indication that the work is not RF... and in the case that the
> disclosure is by the author of the technique in question, this is very
> compelling. Other people are willing to investigate the real risk
> associated with those disclosures, evaluate the effectiveness of
> design-arounds (which do not incur an obligation to update that
> disclosure), etc.

So, right. We rely on IETF working groups to make decisions about what's 
acceptable from an IPR standpoint, in specific cases.

One of my favorite quotes of all time is from the 1968 NATO Software 
Engineering (conveniently located at 
http://www.scrummanager.net/files/nato1968e.pdf):

"Bauer: The concept seems to be clear by now. It has been defined 
several times by examples of what it is not."

Your response is very clear at a detailed level. My comment was at the 
50,000-foot level - I'm betting there are IPR situations that you and 
other working group participants would agree are not even remotely "RF", 
and I'm wondering if it's helpful for working group participants to know 
whether they expect to proceed if that's the way things play out.

> Experience with Opus suggests to me that this should be handled by WG
> consensus on a case-by-case basis, instead of with an iron-clad rule in
> the charter. This was discussed a fair bit at the bar BoF in Vancouver,
> and the "developed under the IPR rules of the IETF" language that's
> currently in the charter was strongly suggested to me as the best way to
> phrase this.

Yes, exactly - not that this is nailed down in the charter, but that the 
working group has given the question some thought. Perhaps that's a 
reasonable group activity; perhaps it's better left to individual 
contemplation.

> Speaking personally, I would not support publishing as an RFC any codec
> that I did not believe was RF.

This is the kind of thought I'm suggesting :-)

I'm glad my comments were mostly useful. IMO, one of the most important 
things IAB members do is to help IETF participants charter new work.

Spencer