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

[Silvia Pfeiffer <[e-mail]>]

On 15 Dec 2013 02:40, "cowwoc" <[e-mail]> 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.

While I'm all for vp8, this argument is a far shot. I actually think that
the longer we wait, the easier it will be to pick vp8.

Did you notice that the only objection to choosing vp8 that returns in the
survey is the Nokia ipr statement? There is no mention any more of lack of
hw support? When Google makes the binary offer that Cisco made for h264,
that goes away. I wonder what objections will remain??

Time is actually on the side of royalty free in this case faict.

Silvia.

> 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]:
>>>>>
>>>>> 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
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>