Re: [rtcweb] H.264's high-low play (Was: H.264 IPR disclosures (or persistent lack thereof))

Eric Rescorla <ekr@rtfm.com> Sat, 14 December 2013 19:42 UTC

Return-Path: <ekr@rtfm.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 0F2CE1AE293 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 11:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 3KcA1e12BzpM for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 11:41:45 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id BF3C91AE19C for <rtcweb@ietf.org>; Sat, 14 Dec 2013 11:41:44 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so3219985wes.32 for <rtcweb@ietf.org>; Sat, 14 Dec 2013 11:41:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UMrue5F0yioDwGhONLh/oq7gsM1E+QKwey1fA0Mw+PQ=; b=OAeVg9pftHBMl2D6O/Py48CYrwL0nTfFL/GjYGw0Si4H0lFU3S4P7YDTy2x4foP/Cv rbIKoAPfjpd5kNVe+l+o9X+59agkrUurNxWX6M7eIV1eKz/8yq4tRH2fUnKCNln3LOtd GdhziVKqsV5YWUOQsDd0zwm+XNxDuDd+fxGAlQ+ap396P35OaX2osSt1ppF1Fg96KFz1 s+i24DbxvKIV+yWTgWiQJCDDuIQ9gZvcjq4PwyyyT7FQoEmXuL5YuCN5ViIEva3hxUzl HZwL9zzFqaOqMPZs2a2IzFNsL8gdPEGmz1N9vObEJMpZN9ZSf8MHlCr47WmC39+O060J NTvg==
X-Gm-Message-State: ALoCoQnwtugUYGSz8H27zyVoEwX3KRK2KLedE42RIhZR0CBFUcIhGZ7emgGIZF4IY74gZbcYLazj
X-Received: by 10.180.189.6 with SMTP id ge6mr7178376wic.1.1387050097573; Sat, 14 Dec 2013 11:41:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Sat, 14 Dec 2013 11:40:57 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CAMwTW+g6q0gRbdioEkw8aUjpBY1s=V=sHbPNXaebFbhr6WihJQ@mail.gmail.com>
References: <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> <20131214122049.604352b3@rainpc> <20131214132520.GZ3245@audi.shelbyville.oz> <52AC7B89.3030103@bbs.darktech.org> <CAMwTW+g6q0gRbdioEkw8aUjpBY1s=V=sHbPNXaebFbhr6WihJQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 14 Dec 2013 11:40:57 -0800
Message-ID: <CABcZeBNx5wpKDgd6TgA9U3_nxEKXdCsXpo8Kp663yQ6e_iN9vQ@mail.gmail.com>
To: bryandonnovan@gmail.com
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] H.264's high-low play (Was: 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 19:42:04 -0000
X-List-Received-Date: Sat, 14 Dec 2013 19:42:04 -0000
X-List-Received-Date: Sat, 14 Dec 2013 19:42:04 -0000

On Sat, Dec 14, 2013 at 11:27 AM,  <bryandonnovan@gmail.com> wrote:
> +1 -
>
> Anyone else notice the silence of VP8 detractors in response to Google's
> offer to host a VP8 binary?

You mean aside from the original suggestion coming from Cullen in the
first place? It would be great if we could have this discussion without
people personally attacking others the way that seems to be happening
in this thread.


On the substantive question, while I think it would be great if Google
would host a VP8 binary, I don't think that that really addresses the
arguments against VP8-MTI in quite the same way that Cisco's offer
did for H.264-MTI.

While there certainly are people who have trouble with implementing
VP8, I take the primary argument for H.264 to be that it had a large
installed base (despite being encumbered) and the primary argument
against it being that it was encumbered and therefore hard for new
people to implement. The idea behind Cisco's offer is to reduce that
barrier for new entrants (whether you believe it is doing so is a
different question).

By contrast, the primary argument for VP8 is that it's free (despite
some people saying they couldn't implement it). So, if Google were
to make a plugin available, that would alleviate the concerns of people
that it really was encumbered, but it doesn't do anything for the
existing installed base.

-Ekr


> On Sat, Dec 14, 2013 at 7:38 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>> +1
>>
>> By total coincidence, I happen to be reading a book called "The Marketing
>> Playback: Five Battle-Tested Plays for Capturing and Keeping the Lead in Any
>> Market" and I note with amusement that they write the following about the
>> "High-Low" Play:
>>
>> High-Low Players are stubborn. They say, "No compromises. Down with
>> mediocrity, up with choice." So what if it makes life more complicated? You
>> deserve the right thing for you. One of the key tools in the High-Low
>> Player's bag is FUD. Sowing fear, uncertainty, and doubt as well as
>> underscoring the risks of going with a middle ground are key ways to buy
>> time.
>>
>> [Emphasis added]
>> Source:
>> http://books.google.ca/books?id=cZAawCoJmrMC&lpg=PT130&ots=goUUaLHeDk&dq=The%20Marketing%20Playbook%20%2Bfud&pg=PT131#v=onepage&q=fud&f=false
>>
>> Does this sound familiar to anyone?
>>
>> Why choose a mediocre solution (VP8) when you could have a free (albeit
>> highly restricted) H.264 codec on the low end, or a more powerful
>> (royalty-encumbered) H.264 codec on the high end? (i.e. "Best of Both
>> Worlds" vs High-Low options)
>> VP8 is unsafe. Just look at all this (hand waving) IPR problems. (i.e.
>> fear, uncertainty, and doubt)
>>
>> Let's recognize this play for what it is: a desperate attempt to buy time.
>> We are all being played.
>>
>> Gili
>>
>> On 14/12/2013 8:25 AM, Ron wrote:
>>
>> On Sat, Dec 14, 2013 at 12:20:49PM +0100, Lorenzo Miniero wrote:
>>
>> Just FYI (for all the group, actually), I remember we had a F2F discussion
>> in
>> Atlanta about IPR in the IETF. Specifically, Scott Bradner gave a
>> presentation during the RTCWEB session. You can find the recordings here:
>>
>>
>> http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF85_RTCWEB_SESSION_I&chapter=part_3
>>
>> Hopefully it will help clarify what is actually supposed to happen.
>>
>> So unfortunately, that session ran out of time and ended right at the
>> instant before the distinction I see here was actually addressed. :/
>>
>> In my comment about "optional extra technology" I was thinking precisely
>> of things like RTP payload definitions.  Those aren't mandating that you
>> use a particular technology, just saying "if you want to, this is how you
>> should signal that within this IETF protocol".
>>
>> And if that's all we were doing with H.264 here, then I'd view it in a
>> similar light.
>>
>> But the draft proposals aren't doing that, they are saying we should
>> mandate it.  Which effectively makes the relevant WebRTC RFC(s) a
>> perfect superset of the H.264 standard, and would make H.264 itself an
>> IETF standard that is an essential and mandatory part of what we hope
>> to publish.  Which afaics means all the usual IETF requirements would
>> be directly applicable to it.
>>
>>
>> And just on a side note, the other interesting thing in that discussion
>> was the importance and necessity for disclosures to "point to the part
>> of the specification that is affected" -- the total lack of which seems
>> to be the hallmark of, shall we call them "deliberately disruptive"
>> disclosures, that are sometimes seen.
>>
>> At least in the context of VP8, that, combined with the facts that nobody
>> has since made any change to VP8, or any user of it has stopped using it,
>> or anyone at all has pointed at some section of its code and said "OMG,
>> that really is doing what's described in this prohibitive disclosure",
>> and that courts are throwing out the cases put before them, and the
>> European regulators are warning against further Troll-like Behaviour,
>> make it very hard to take those disclosures seriously, or to consider
>> them as being a genuine blocker for its adoption.
>>
>> So if people want to clarify that too while they're busy making the
>> necessary H.264 disclosures, that would be really helpful for those
>> of us who are still trying to winnow the actual facts from the FUD
>> and arrive at an actually considered position to present to the Chairs :)
>>
>>   Thanks!
>>   Ron
>>
>>
>> On Sat, 14 Dec 2013 20:58:55 +1030
>> Ron <ron@debian.org> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> --
>> Lorenzo Miniero, COB
>>
>> Meetecho s.r.l.
>> Web Conferencing and Collaboration Tools
>> http://www.meetecho.com
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>