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

Ron <ron@debian.org> Sat, 14 December 2013 10:29 UTC

Return-Path: <ron@debian.org>
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 092B21ADE88 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 02:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nlf28PMjonB4 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 02:29:09 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 449C61AC863 for <rtcweb@ietf.org>; Sat, 14 Dec 2013 02:29:07 -0800 (PST)
Received: from ppp118-210-211-6.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.211.6]) by ipmail07.adl2.internode.on.net with ESMTP; 14 Dec 2013 20:59:01 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 3622C4F8F3; Sat, 14 Dec 2013 20:58:57 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nXBRV44o7Xto; Sat, 14 Dec 2013 20:58:55 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 938274F902; Sat, 14 Dec 2013 20:58:55 +1030 (CST)
Date: Sat, 14 Dec 2013 20:58:55 +1030
From: Ron <ron@debian.org>
To: Markus.Isomaki@nokia.com
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A16219B@008-AM1MPN1-042.mgdnok.nokia.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
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 10:29:25 -0000

Hi Markus,

On Fri, Dec 13, 2013 at 07:48:56AM +0000, Markus.Isomaki@nokia.com wrote:
> Hi,
> 
> My and Nokia's interpretation has been that since neither of H.264 nor VP8
> are IETF specifications, there is no obligation for anyone to disclose IPR on
> them in the IETF, even if there may be IETF specifications that refer to
> them. For H.264 all Nokia's IPR is publicly declared in ISO/IEC/ITU. For VP8
> Nokia decided voluntarily to do the declaration to make it open and clear
> what the Nokia position on that is.

Do you have a reference to something that is the basis of that interpretation?

I may well be missing something here, but I'm not seeing any exception that
could be interpreted in that way.

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:


 9.  Change Control for Technologies

   The IETF must have change control over the technology described in
   any standards track IETF Documents in order to fix problems that may
   be discovered or to produce other derivative works.

(which indeed may not be a problem specific to H.264, but let's not get
too sidetracked by this one at this stage, since this or some other WG
could fix that fairly easily by publishing an RFC if necessary - but we
may indeed need to fix that before all is said and done)


And the requirements of section 6, which I won't quote again except to
note once more that the applicable clause has a "no excuses" requirement

 "Contributors must disclose IPR meeting the description in this
   section; there are no exceptions to this rule."

Which since you are listed as one of the Authors of (at least?) one
of the H.264 proposal drafts, would seem to explicitly disallow the
interpretation you suggest.


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.


Since making this mandatory _would_ expose all implementors of this
IETF standard to the IPR in question, I really can't see how "oh that's
been declared somewhere else already" is an acceptable way to meet the
IETF's requirements.  That would completely defeat the purpose of having
these declarations be a mandatory part of defining IETF standards.

If they are already declared somewhere else then that indeed should make
it easier to make the necessary declarations here, but I don't see what
might absolve the people with such an obligation from still making them?


This seems like information that in the absence of, we can't possibly
even consider H.264 to be a serious contender for acceptance by the
IETF as an integral and essential part of one of its standards.

So afaics, either somebody needs to point out what I'm missing here
(with something more definitive than "my opinion is"), the people with
obligations to disclose need to do so, or we need to simply remove H.264
from any further consideration as MTI.


Thanks to those who responded actually taking this question seriously
though, it shouldn't be hard to resolve one way or the other.

  Cheers,
  Ron