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

[[e-mail]]

+1 -

Anyone else notice the silence of VP8 detractors in response to Google's
offer to host a VP8 binary?


On Sat, Dec 14, 2013 at 7:38 AM, 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.
> 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]> <[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 [e-mail]://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Lorenzo Miniero, COB
>
> Meetecho s.r.l.
> Web Conferencing and Collaboration Toolshttp://www.meetecho.com
>
>  _______________________________________________
> rtcweb mailing [e-mail]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>