[rtcweb] IETF requirements for mandatory technologies

[Ron <[e-mail]>]

Hi Stephan,

On Fri, Dec 20, 2013 at 10:46:24PM +0000, Stephan Wenger wrote:
> Ron,
> 
> On 12/20/13, 1:39 PM, "Ron" <[e-mail]> wrote:
> 
> >[Š]
> >And it would also seem to be subject to the IETF requirement that security
> >technologies MUST be strictly RF.
> 
> There is no such requirement.  The only requirement that I recall related
> to security technologies is that, whenever security is mandated, that
> there MUST be at least one RF security technology be mandated.  Optional
> other security technologies can be royalty bearing or otherwise encumbered.

Sorry, I thought the context there was clear, but I was indeed only referring
to mandatory requirements.  Optional things do seem to be in a different boat
there for several reasons that I don't think are in dispute.

It is indeed *all* mandatory technologies though, not just "at least one".

  An IETF consensus has developed that no mandatory-to-implement security
  technology can be specified in an IETF specification unless it has no
  known IPR claims against it or a royalty-free license is available ...

You're correct if they are optional, and I didn't mean to imply otherwise.


> Also please note that security is the one single exception we currently
> have in the IETF where there exists an actual licensing requirement.  I
> would argue very strongly against creating another such precedence.

It's ok, I'm not arguing here for the expansion of this (or any other
requirement) -- I'm trying to get to the bottom of the rationale for
dodging the other already existing requirements, for which there seem
to be no such exceptions granted at all, and for the disclosures at
least, rather explicit "no excuses" requirements.

In the case of AES, I would assume that any existing IPR, should there
have been any, would have been required to be reported against the draft
that proposed mandating it, even by citation alone, and would have then
required the WG to pick some other option that wasn't so encumbered.
Even if there was no contributor in that case with an obligation to
disclose, the WG still had an extra obligation to ensure it was RF
(which obviously then makes a whole range of things much simpler, and
adds some practical liberties to pragmatically 'cut some corners', since
they could always be easily remedied after the fact if needed).


Here we have something that is proposed to be even more mandatory than
AES was, by people who haven't shown which IETF requirement gives them
an excuse not to disclose, and which clearly doesn't get the benefit of
any of the relaxations the IETF offers for RF technology.

I don't see how making some technology a strictly required IETF standard
by the back door path of deferring to a citation can exempt it from all
of the other normal requirements -- without driving a bulldozer through
both the spirit and the letter of those requirements.


Unless somebody can explain that, it's hard to see how this group could
do anything but reject that technology as mandatory, or face the shame
of having the broader IETF do that for us when it goes up for review.
And I'd like to not be in the shamed bunch when I decide how to answer
the survey questions that the chairs have posed :)  So I'm trying hard
to find out if there really is something I'm missing here.

  Cheers,
  Ron


> >Which leaves the door open that the IETF
> >_could_ always assume change control of it if the need ever arose.  Which
> >seems reasonably pragmatic, even absent the "mandatory unless" language,
> >and the IETF does make sensible exceptions for strictly RF technologies.
> >
> >We don't appear to have that option in the case of H.264 though, in the
> >light of declarations and statements that insist there would never be a
> >licence granted for an alternative but similar technology, by at least
> >one major IPR holder.
> >
> >
> >I know we're edging out of the scope of things that this group is
> >chartered
> >to decide on, but I don't see any document that explicitly gives us the
> >option to ignore these requirements either, and it does seem relevant to
> >the decision that we need to make.
> >
> >Even after we decide on something (assuming that we do), it's still going
> >to need to run the gauntlet of the broader IETF, and we seem to be
> >somewhat
> >perilously close to a loophole whereby I could reference something which
> >I hold IPR on, that was published in the newsletter of my mother's
> >knitting
> >group, and then assert with a Straight Face, that I have no obligation to
> >disclose, since it was Published Elsewhere.  And point to the discussion
> >here as precedent for that.
> >
> >
> >The IETF requirements as published would seem to be very clear.  Where
> >does
> >our leeway come from to blur those lines here?
> >
> >  Cheers,
> >  Ron