Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 23 December 2013 03:02 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
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 276B21AE768 for <rtcweb@ietfa.amsl.com>; Sun, 22 Dec 2013 19:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 MR-U6yTnHUGz for <rtcweb@ietfa.amsl.com>; Sun, 22 Dec 2013 19:02:28 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id DDAA71AE142 for <rtcweb@ietf.org>; Sun, 22 Dec 2013 19:02:27 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id rBN32Ldt025610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2013 21:02:23 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBN32J5G027804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Dec 2013 04:02:20 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 23 Dec 2013 04:02:20 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: David Singer <singer@apple.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)
Thread-Index: AQHO/adey5fdu0H5JEmjhL85euoOsJpdXnOAgAAJNACAA6GpMA==
Date: Mon, 23 Dec 2013 03:02:19 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0FC76E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <CA+E6M0m5O1OqjBm13qNoRAtYZKwOs+4fs3evyO2VuuO1uqQ5eA@mail.gmail.com> <CED773F0.2D6AA%stewe@stewe.org> <20131219033000.GK3245@audi.shelbyville.oz> <CA+E6M0n9frSRbbrXh=jczQETX13HX6LDGUCq2P4=6voXx93ZVA@mail.gmail.com> <CAHp8n2m5XNC8UfDswGfD=0qCPaddcsrg08FJKXnDsz-A+tWqzQ@mail.gmail.com> <CA+E6M0mwWVEAv6zeET1fwdL6oDB-Cxag64XNV1EJhk-oP3241g@mail.gmail.com> <52B38E3E.1040801@bbs.darktech.org> <52B40035.2010308@alvestrand.no> <0D649E40-454C-4945-B148-FD8AC6D49349@apple.com> <20131220185659.GN3245@audi.shelbyville.oz> <76E03D61-C9A5-4A93-BC0D-6773D603CD3B@apple.com>
In-Reply-To: <76E03D61-C9A5-4A93-BC0D-6773D603CD3B@apple.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)
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: Mon, 23 Dec 2013 03:02:30 -0000

> If we insist on a recursive closure of all normatively 
> referenced documents, the database would be so overloaded as 
> to be unreadable and a mess.  As far as I know, no body has 
> gone down that (insane, IMHO) route, expecting that people 
> can work out for themselves that if a document is published 
> by body A, it may well be in body A that you'll find the declarations.

More to the point, you will probably find that many of the potential holders of IPR against H.264, and also possible VP8, are not represented in the IETF RTCWEG WG, or else their representatives have insufficient information on their companies IPR holdings because they work in a different area. At the end of the day, the majority of the videocodec experts, who would have such direct knowledge, are in ISO/IEC. Therefore you will get an incomplete set of declarations in IETF even if you start insisting on a declaration against every dpcument.

So you will only get a complete picture of the IPR position by going to the ISO / IEC IPR databases.

And that position applies to VP8 as well. My view is that we will only have a clear view of the IPR position of VP8 when ISO / IEC asks for declarations against that technology. At the moment we only have the statement of one company (albeit a large company) that their investigations have not revealed any IPR that either they they themselves do not own, or have negotiated some sort of arrangement with). (Ignoring for the moment the Nokia IPR declaration).

Regards

Keith Drage 

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> David Singer
> Sent: 20 December 2013 19:30
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)
> 
> 
> On Dec 20, 2013, at 10:56 , Ron <ron@debian.org> wrote:
> 
> > On Fri, Dec 20, 2013 at 09:17:10AM -0800, David Singer wrote:
> >> 
> >>>>>> It has been pointed out that the MTI should satisfy 
> options a) or 
> >>>>>> b) on the ietf declaration form. As matters stand 
> AVC/h264 does 
> >>>>>> not satisfy that, this has been made very clear 
> through the ISO process.
> >> 
> >> But at least it satisfies (c).
> > 
> > Does it?  Can you point me to the IETF declaration which 
> indicates this?
> 
> If there an IETF specification for H.264/AVC?
> 
> Seriously, you need to look at the ISO, IEC, and ITU 
> databases, because that's where it is published.  The 
> declarations are all there. There are no 'unwilling to 
> license' declarations.
> 
> Perhaps you didn't realize that declarations are in the same 
> place as the standard?
> 
> > 
> >>>>> On the other hand, VP8 has
> >>>>>> so far withstood court challenges, as you point out
> >> 
> >> I am unaware of a result from Germany still (it was 
> expected in JUNE, 
> >> wasn't it?). And I believe that we have been told that those cases 
> >> only involve a subset of what what was declared.
> > 
> > But you'd assume it's the _strongest_ subset that they think they 
> > might be able to prove to the court.
> 
> In legal matters, I have long learned that assumptions are dangerous.
> 
> >> VP8 is formally *unlicensable* at the IETF.
> > 
> > I don't believe that is true.  The IETF *formally* takes no 
> position 
> > or makes no claims about the validity or applicability of 
> any declaration.
> 
> There is a formal declaration registered at the IETF of 
> unlicensable IPR.  
> 
> >  The results of this procedure shall not, in themselves, block  
> > publication of an IETF Document or advancement of an IETF  Document 
> > along the standards track.  A working group may take  into 
> > consideration the results of this procedure in evaluating  the 
> > technology,  ...
> > 
> > This wouldn't be the first working group that has had to 
> laugh off a 
> > patently ridiculous claim in a disclosure in order to achieve a 
> > sensible result that was in the best interest of its charter.
> 
> If someone makes to analyze these patents and VP8, and stand 
> behind their analysis, go ahead.
> 
> If you want to mandate people to ignore declarations, I think 
> you need a much stronger case.
> 
> >> You're saying you are aware of IPR declarations against H.264
> > 
> > I'm still waiting for us to be informed of the reasons why IETF 
> > sanctions shouldn't be sought against the contributors who 
> have failed 
> > to meet their obligations to make them.
> 
> Against what IETF document?
> 
> If we insist on a recursive closure of all normatively 
> referenced documents, the database would be so overloaded as 
> to be unreadable and a mess.  As far as I know, no body has 
> gone down that (insane, IMHO) route, expecting that people 
> can work out for themselves that if a document is published 
> by body A, it may well be in body A that you'll find the declarations.
> 
> Let's at least try to deal with the as it is.
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>