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

[cowwoc <[e-mail]>]

+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 <[e-mail]> wrote:
>>
>>> Hi Markus,
>>>
>>> On Fri, Dec 13, 2013 at 07:48:56AM +0000, [e-mail] 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
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb