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

Ron <ron@debian.org> Fri, 20 December 2013 20:20 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 A097E1ADF9B for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 12:20:46 -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 dluzodnRu_wF for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 12:20:42 -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 27FBF1ADF8B for <rtcweb@ietf.org>; Fri, 20 Dec 2013 12:20:41 -0800 (PST)
Received: from ppp118-210-62-207.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.62.207]) by ipmail07.adl2.internode.on.net with ESMTP; 21 Dec 2013 06:50:39 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 966334F8F3 for <rtcweb@ietf.org>; Sat, 21 Dec 2013 06:49:07 +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 vKzRjB2u96UZ for <rtcweb@ietf.org>; Sat, 21 Dec 2013 06:49:06 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C86AD4F902; Sat, 21 Dec 2013 06:49:06 +1030 (CST)
Date: Sat, 21 Dec 2013 06:49:06 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131220201906.GO3245@audi.shelbyville.oz>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <76E03D61-C9A5-4A93-BC0D-6773D603CD3B@apple.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
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: Fri, 20 Dec 2013 20:20:46 -0000

On Fri, Dec 20, 2013 at 11:29:56AM -0800, David Singer wrote:
> 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.

I'm not suggesting they be ignored.  But since they don't reference any part
of the specification that they claim to apply to, and since nobody has been
able to subsequently point to one, their applicability to this working group
in its capacity to "revise the work to attempt to avoid the IPR claim" would
appear to be negligible.

If nobody can identify any affected part of VP8, then there doesn't seem to
be any work required by the group to avoid these claims.  The burden of proof
would seem to have fallen on the people claiming this is a blocker.

If they haven't analysed this either, they don't have much of a case to refute.
If they have, please point for the rest of us to see also.

> >> 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.

Do you have a reference to another technology that the IETF has *mandated*
as essential to implement (effectively making it an IETF standard), without:

 a) The IETF having change control over that technology (even if just by
    reprinting a reference from some other source and making it an RFC).

 b) Following all of the other relevant IETF process requirements, such as
    timely IPR disclosure.


As noted previously, there's a very big difference between something like
an optional RTP profile and a mandatory appendage to some other standard.

It seems out of scope for this working group to unilaterally break new
ground in violation of the above requirements, and I'm not aware of any
precedent that we'd be following in the footsteps of.  Is there one?


  Ron