Re: [rtcweb] Input to Video Codec Selection

Harald Alvestrand <harald@alvestrand.no> Mon, 04 March 2013 10:43 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5721F8999 for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 02:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.598
X-Spam-Level:
X-Spam-Status: No, score=-112.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 85k1J8W8e2-f for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 02:43:50 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82C7521F897F for <rtcweb@ietf.org>; Mon, 4 Mar 2013 02:43:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0383739E0FD; Mon, 4 Mar 2013 11:43:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwbhcU7d37LN; Mon, 4 Mar 2013 11:43:46 +0100 (CET)
Received: from [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab] (unknown [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 66D0639E0C8; Mon, 4 Mar 2013 11:43:46 +0100 (CET)
Message-ID: <51347AE2.7020401@alvestrand.no>
Date: Mon, 04 Mar 2013 11:43:46 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <CD58BCAF.95F6C%stewe@stewe.org>
In-Reply-To: <CD58BCAF.95F6C%stewe@stewe.org>
Content-Type: multipart/alternative; boundary="------------060700050704040405070703"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Input to Video Codec Selection
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 10:43:51 -0000

On 03/03/2013 05:52 PM, Stephan Wenger wrote:
> Hi Harald,
> Thanks for these candid answers.  I have a few comments, marked in 
> blue and with StW:
> Stephan
> Speaking with my IETF-amateur-lawyer hat on (and as a former chair of 
> the IPR WG): No, it does not change the rule. The rule depends on 
> whether the technology in question is discussed in the IETF, not on 
> the nature of the contribution. RFC 3979 section 6.1.2 refers to 
> "Contribution", the definition of that term in RFC 3979 section 1 
> letter j makes it completely explicit that RFC Editor Contributions 
> are covered by the term "Contribution".
>
---- below here is StW ---
>
> StW; While this answer IMO correctly interprets the language of BCP79, 
> you answer the question IMO to directly.  Therefore, the answer is 
> somewhat misleading in it misses to mention an important point:
>
> The main (sole?) purpose of an IETF WG is to facilitate consensus 
> building, which necessarily involves more than one party, and those 
> contributing to the discussions (belonging to more than one party) 
> have a disclosure obligation.  To which extent there is real 
> discussion and consensus building dependent from draft to draft and WG 
> to WG, but there is at least some.
>
> ISE submissions, like the draft that lead to RFC 6386, OTOH, are 
> almost always NOT the result of a multiparty consensus building 
> process.  Quite commonly, they involved only a small authors' group, 
> often from the same company.  That's the case here.  No technical 
> community input from IETF participants was received in an IETF 
> context, no WG consensus was required, and the IESG "no conflict" 
> statement is also no indication of IETF consensus.
>
> Insofar, almost inevitably, the disclosure obligations for an ISE 
> submission are different in practice.  In this case, it appears that 
> only the authors (and perhaps the IESG members—I'm not clear on this 
> point) had a disclosure obligation.  Which they fulfilled.
> /StW
>

I don't know how much the blue survives, email formatting is still 
hit-and-miss, but I hope this makes sense still.... this is still from 
my IETF amateur lawyer perspective, and shouldn't be taken as a Google 
position in any way.

I've always worked on the assumption that the RFC 3979 disclosure rules 
applied only when I was part of the discussion - but that it applied to 
anything brought into the discussion, including RFCs that I had not 
heard about before.

Thus, I don't believe the submission, editing and publication of RFC 
6386 triggered a disclosure obligation on anyone except those involved 
in the submission and editing process - but I believe that the moment a 
submission was made to the RTCWEB working group saying "VP8 should be a 
mandatory to implement codec for RTCWEB", participants who "reasonably 
and personally" knew of "IPR that is owned directly or indirectly, by 
the individual or his/her employer or sponsor (if any) or that such 
persons otherwise have the right to license or assert" (3979 section 
6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in 
the contributions of others).

(In the same way, I believe the submission saying "H.264 should be a 
mandatory to implement codec for RTCWEB", detailed in 
draft-marjou-rtcweb-video-codec among others, triggered a requirement 
for similar disclosure of IPR in H.264 technology. I believe the chairs 
earlier stated which draft such IPR claims should be filed against, but 
I don't have that message in front of me at the moment.)