Re: [rtcweb] H.264 IPR disclosures (or persistent lack thereof)

["DRAGE, Keith (Keith)" <[e-mail]>]

I'm not sure exactly where you are trying to take this discussion.

If you are implying that the IPR for either of the two codec specifications is unknown, then we MUST stop any decision making process until it is known, because the WG is bound to take that status into account in making its decision.

But I believe the chairs have stated in prior meetings that the IPR is known, and noone has contradicted that on the list or in the meeting, and where to find it has been reiterated time and time again, in the meeting, on mailing lists and in documents.

And you yourself do not seem to be pointing at any IPR coverage that you know of that has not been publically identified.

The only doubts I have heard about absence of IPR disclosure is specifically against the VP8 codec, with the contention that as the specification has only recently been submitted to ISO, many ISO participants may still be evaluating their patent portfolio against it.

Of course if you really do want an IETF IPR disclosure under way, then submit a draft that makes both codecs mandatory and asks for it to be a WG item. The codec declarations will have to be made against that document. But do you really believe that will produce any surprise declarations.

That draft WG document at the moment does not exist.

Regards

Keith



 

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Ron
> Sent: 14 December 2013 13:25
> To: [e-mail]
> Subject: Re: [rtcweb] H.264 IPR disclosures (or persistent 
> lack thereof)
> 
> 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=IET
> > F85_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
>