[rohc] RE: IPR situation

["Price, Richard" <[e-mail]>]

> > RP: Based on previous mailing list discussions, I concluded that 
> > the IPR issues on the base SigComp solution were due to the
> > informative description of how to implement a feedback mechanism
> > rather than the technical content of the solution. 
> 
> Was it not rather the described mechanisms for acknowledging
> state generated based on received messages that there were IPR
> concerns on.

I deleted all of the above mechanisms in an attempt to resolve the
IPR issues on the base SigComp solution. It didn't work!

> I do not believe we have to bother if anyone has
> tried to protect the use of a feedback mechanism in general.

This is what I find so confusing about the current IPR debate. The
mechanism I proposed just sends a list of identifiers from one
endpoint to another - this could be used to implement a feedback
mechanism, but equally it could be used to announce support for a
list of well-known decompression algorithms.

In my opinion, an IPR claim on the above would cover not only the
use of a feedback mechanism in general, but also the use of a
capability announcement mechanism as well.

> > So in release 04 of the SigComp draft I defined the following
> > list of identifiers as a well-known area of the UDVM memory:
> >
> <snip>
> > 
> > The aim of the above mechanism was not to provide feedback 
> > (although it could feasibly be used as such) but rather to
> > allow an endpoint to announce support for a selection of
> > well-known decompression algorithms. Each algorithm would
> > be given its own unique identifier (e.g. 0 for NULL, 1 for 
> > DEFLATE etc.).
> 
> Was this ever discussed on the mailing list? I may have missed
> it, and in that case I apologize. However, we must try to keep
> the technical development of new mechanisms, and especially
> agree on the need for new things, on the mailing list. Working
> group documents should be updated based on what has been 
> agreed on the list, not the opposite.

Yes, this was discussed in some detail on the mailing list (see
http://www.cdt.luth.se/rohc/msg03631.html and related messages).

> > I also hoped that the mechanism could be used to indicate 
> > support for the extended operations themselves, by reserving
> > a certain identifier for the sigcomp-extended draft. Without
> > this ability the extended operations would have to be
> > negotiated externally to SigComp, or else feedback data would
> > be sent without knowing whether or not it could be understood 
> > by the receiver (potentially very inefficient).
> 
> Do you mean that this is the only way to provide a hook for
> extended operations without negotiation?

Unfortunately, if Hans' IPR concerns on my proposed "hook" are valid
then I believe that they cover the concept of capability announcement
itself. The mechanism I wanted to include in the draft simply
transmitted a list of identifiers from Endpoint A to Endpoint B -
specific identifiers could then be reserved to indicate support for
various well-known algorithms, extended operations and so on.

How can a capability announcement mechanism be implemented without
reserving an identifier (any flag or bit pattern) for each optional
mechanism, and then transmitting a list of the supported mechanisms
from one endpoint to another?

> > [LEJ] Note:
> >       When someone indicates that they know of potential IPR,
> >       it does not necessary mean that it is their own IPR. I
> >       hope we are all looking for potential IPR's on the
> >       technology we are standardizing, so that we can indicate
> >       this, or avoid the technology when that is desirable.
> > 
> > My understanding of the IETF approach to dealing with IPRs is 
> > that an RFC includes an IPR statement only as a pointer to an
> > official IPR announcement made at http://www.ietf.org/ipr.html.
> 
> RFC2026 says the following about Standards Track documents:
> 
> : 10.3.2. Standards Track Documents
> :
> :   (A)  Where any patents, patent applications, or other proprietary
> :      rights are known, or claimed, with respect to any specification on
> :      the standards track, and brought to the attention of the IESG, the
> :      IESG shall not advance the specification without including in the
> :      document a note indicating the existence of such rights, or
> :      claimed rights.  
> 
> This is therefore not only about official IPR announcements on the web,
> but about whether there are known IPR's. Patents are public information,
> so one can know about others patents.

I believe that knowledge of 3rd party patents is also placed on the IETF
website; for example http://www.ietf.org/ietf/IPR/CHRISTENSEN-MAGMA-SNOOP.txt.

> RFC2026 states the following for all contributions, which affects 
> all of us who write internet drafts:
> 
> : 10.3.1.  All Contributions
> :
> :   By submission of a contribution, each person actually submitting the
> :   contribution is deemed to agree to the following terms and conditions
> :   on his own behalf, on behalf of the organization (if any) he
> :   represents and on behalf of the owners of any propriety rights in the
> :   contribution..  Where a submission identifies contributors in
> :   addition to the contributor(s) who provide the actual submission, the
> :   actual submitter(s) represent that each other named contributor was
> :   made aware of and agreed to accept the same terms and conditions on
> :   his own behalf, on behalf of any organization he may represent and
> :   any known owner of any proprietary rights in the contribution.
> :
> :   6. The contributor represents that he has disclosed the existence of
> :      any proprietary or intellectual property rights in the
> :      contribution that are reasonably and personally known to the
> :      contributor.  The contributor does not represent that he
> :      personally knows of all potentially pertinent proprietary and
> :      intellectual property rights owned or claimed by the organization
> :      he represents (if any) or third parties.
> 
> As an author of a draft, you therefore MUST tell if YOU know of any
> IPR on the technology described.
>  
> 
> > The advantage of the above approach is that as authors, we 
> > don't need to make a decision on whether particular patents are
> > applicable to our work or not.
> 
> This is wrong. You MUST (as an author) indicate if you are aware of any
> patent on the technology.

The above statement seems to contradict the following, quoted from the
previous discussion on IPRs between Scott Bradner and yourself:

"You have no obligation to send in an IPR notice for other parties IPR's, and
you might also have an NDA that prevents you from doing so. However, since
it is beneficial for the community to know about all potential IPR's, if you
can you should of course share your knowledge with the WG and the community."

Which of the above statements is correct? It's important for us to get this
right, particularly if Hans' IPR concerns stem from a patent similar to the
Motorola patent WO9110289 that tries to cover the general concept of a feedback
mechanism.

(As an aside, I don't believe that even the Motorola patent covers the more
general concept of a capability announcement mechanism, so I'm not worried
about it from the perspective of my proposed text for the SigComp draft).