[rtcweb] IETF change control

[Ron <[e-mail]>]

On Mon, Dec 23, 2013 at 03:02:20AM +0000, DRAGE, Keith (Keith) wrote:
> > Do you have a reference to another technology that the IETF 
> > has *mandated* as essential to implement (effectively making 
> > it an IETF standard), without:
> > 
> >  a) The IETF having change control over that technology (even 
> > if just by
> >     reprinting a reference from some other source and making 
> > it an RFC).
> > 
> >  b) Following all of the other relevant IETF process 
> > requirements, such as
> >     timely IPR disclosure.
> 
> The closest example to the RTCWEB working group is G.711,

If that's actually true, then that would indeed confirm that there is
actually no precedent at all for any exemption to the problems that
H.264 poses with this.

> which the IETF does not control,

You're missing the key point identified in earlier discussion.
The IETF _could_ have change control over G.711 at any time, if the need
for that ever arose.  All it would take is to publish an RFC with whatever
changes it was felt necessary to make.

And we could do this, on zero notice, with no need to obtain any additional
permission to what we already have, because G.711 is an unencumbered RF
specification.  Which I believe does actually satisfy BCP 79, section 9,
both in spirit and letter.

That doesn't say it must be an IETF standard, that says the IETF must have
change control over *the technology*.  If we can make a derived standard
at any time, which for G.711 we clearly can, then we have change control.
QED.

We could likewise do the same for VP8, or H.261, given the status of their
applicable IPR.  We have the option for change control, either by explicit
grant of the IPR holder in the former case, or by its expiry in the latter,
which we could exercise at any time we might need to.


The important difference is we do NOT have that luxury for H.264 at all.
Not only is it not an IETF standard, but one of its major IPR holders has
openly threatened to sue the pants off anyone who makes a derived work.
We've been openly prohibited from having any form of change control.

The closest examples to this might actually be referenced from BCP 79
itself.  It even gives examples of possible remedies - but those aren't
applicable for H.264 either in the light of that prohibitive threat.
Oops.


> and has no IPR database against it in IETF.

are you ...  seriously suggesting you think there is unreported IPR on a
40 year old standard?  One which consists of such trivial math that it's
probably about as patentable as the two times table?


> But I am sure we could identify lots of work elsewhere in the IETF
> (if I really wanted to waste any time on a pointless exercise)

If you think facts are a waste of time, then I can't help you there.
I'm sure we could imagine all sorts of fanciful things if we refuse
to be constrained by them.

The requirements of BCP 79 are fairly simple and plainly stated.

If you can't show where the authority comes from for the exceptions
that you are claiming to them, then we can probably safely take that
as consensus that those exceptions simply don't exist.

And this is the wrong place to begin inventing them from thin air.

  Ron