Re: [rtcweb] H.264 IPR disclosures (or persistent lack thereof)

SM <sm@resistor.net> Sat, 14 December 2013 17:49 UTC

Return-Path: <sm@resistor.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A9F1AE243 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 09:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no
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 S9y9YlUtickc for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 09:49:52 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE211AE25A for <rtcweb@ietf.org>; Sat, 14 Dec 2013 09:48:51 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rBEHlCDU028702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Dec 2013 09:47:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1387043240; bh=JG/s3VXyQt363/5QM69Gz7XmGO2/X9NsDY3uIWuxEsI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yKQ8NH11f3d57+e8+g639x47G/rFDLT5LZugcoDhf+MKbAdq5shkc0rl3fU91DCZ9 YsYFHSU4iEjCnhdAaayTEpux9/Obhsv2snRa6h00IiGK18fuce1G5ex0Ccs7sBJ0YB 3cI4YY8WRKuKwb239PuyzVWao8dt18cwejqppD28=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1387043240; i=@resistor.net; bh=JG/s3VXyQt363/5QM69Gz7XmGO2/X9NsDY3uIWuxEsI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qjNDeDtSbmBS8UD4OhOF7AXrY2Tp+vGgqDjDBLa0Gm/ICOQOvBy3yxcgj3bmCibdx dErvlMRJTZzNA1zKT6Pd+h+1ZGRVEafRcC/uwgqKxgSW+Loru3rY/xqd7evTSjVgor fZsmjl/HfKDpzX7CTxvIAinAM6kco52bkWHMrd28=
Message-Id: <6.2.5.6.2.20131214085022.0d243398@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 14 Dec 2013 09:21:09 -0800
To: Ron <ron@debian.org>
From: SM <sm@resistor.net>
In-Reply-To: <20131214102855.GY3245@audi.shelbyville.oz>
References: <D5A2C5EC-C65F-4E39-9A56-315B94C5FB1D@iii.ca> <CAD5OKxs-OoqwbQgBy7K4wQRffCk0=8Qmo_xJQdSwhBL2F85v1g@mail.gmail.com> <20131212214310.GR3245@audi.shelbyville.oz> <CECFA3EA.AC30E%stewe@stewe.org> <949EF20990823C4C85C18D59AA11AD8B0F8739@FR712WXCHMBA11.zeu.alcatel-lucent.com> <20131213024334.GV3245@audi.shelbyville.oz> <949EF20990823C4C85C18D59AA11AD8B0F88D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <20131213033344.GW3245@audi.shelbyville.oz> <CECFF758.205FF%mzanaty@cisco.com> <E44893DD4E290745BB608EB23FDDB7620A16219B@008-AM1MPN1-042.mgdnok.nokia.com> <20131214102855.GY3245@audi.shelbyville.oz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] H.264 IPR disclosures (or persistent lack thereof)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 14 Dec 2013 17:49:53 -0000

Hi Ron,

At 02:28 14-12-2013, Ron wrote:
>If we were making this an optional extra technology we can interop with,
>then I could sort of see how this might be considered out of scope for the
>IETF to be responsible for, but the drafts submitted wrt to H.264 are all
>proposing to make it mandatory for WebRTC.  Which means the IETF would be
>effectively coopting this as a standard, since anyone implementing WebRTC
>MUST implement it.  That would mean that it _is_ on the IETF standard track,
>(albeit by some back door) and as far as I can see, means it falls foul of
>at least 2 requirements at the present time:

[snip]

>draft-burman-rtcweb-h264-proposal even makes no reference whatsoever to
>the out of pool IPR held by Nokia (and others?), and seems to imply that
>the MPEG-LA subset is all that would need to be licenced.  This would
>seem to fall well short of even the bare minimum of due diligence
>disclosure to the working group.

draft-burman-rtcweb-h264-proposal-00 is not listed as a working group 
document.  I don't have a clear picture of the discussion about that 
draft.  As such it is difficult to form an opinion about how BCP 79 
applies.  I was puzzled by the lack of IPR disclosures on any of the 
working group documents given that there has been several threads on 
the WG mailing list about patents.

Regards,
-sm