Subject: [rohc] IPR situation

From: "Price, Richard" <[email-masked]>
Date: Wed, 20 Feb 2002 17:31:54 -0000

Hi,

Some background on the IPR situation:

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. So in release 04 of the SigComp draft I defined the following
list of identifiers as a well-known area of the UDVM memory:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        id_length 1        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |
:        id_value_1         :
|                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         :         : 
         :         : 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        id_length n        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |
:        id_value_n         :
|                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If a certain identifier is sent from Endpoint A to Endpoint B, then Endpoint
B knows that the corresponding piece of bytecode is available at Endpoint A
and can be retrieved using the appropriate UDVM instruction.

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.).

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).

Unfortunately, including the above mechanism raised IPR concerns from Hans,
so to get the draft out on time I deleted it.

[LWC] Why the heck is sending a list of identifiers of available
      decompression algorithms in the extended draft?

It isn't! Currently the ability to send a list of supported decompression
algorithms isn't available in either draft, so it can only be done externally
to SigComp.

[LEJ] I do not think this is what is there. I agree that the principle you
      mention may probably not be an IPR-problem, but if this is done by 
      sending acknowledges of established state ("pre-loaded"), I guess there
      might be IPR concerns about that. Without having an opinion on that, I
      can see a difference between the general principle and how the mechanism
      is provided.

The actual mechanism provided is as described above, with no mention of what
the identifiers are actually for (e.g. they could be used to retrieve well-
known decompression algorithms, dictionaries of SIP phrases, extended
operation mechanisms etc.).

In fact, the draft didn't include the terms "feedback" or "acknowledgement" at
all.

[LWC] Did I miss some comment in the postings (see third extract below),
      in which someone mentioned that they thought they had IPR on this?

This was done offline - I proposed the above list of identifiers for inclusion
in the SigComp draft, but Hans indicated that he had IPR concerns on it so I
didn't bother.

[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.

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.
An IPR statement is only required when an official IPR claim is made, so what
we need to find out is whether anyone would put in such a claim on basic
SigComp if the above announcement mechanism were to be included.

[HH]  The proposal that is somewhat described in SigComp and 
      SigComp-extended is not exactly like the mechanism in SDP as 
      this proposal can be interpreted as an explicit 
      acknowledgement for an established state, which is one 
      feature described in SigComp extended.

I think that the above comment is key to the IPR situation. All that SDP can do
is announce a list of algorithms supported at an endpoint, and this is all that
SigComp needs to be able to do as well. Whether the algorithms are predefined
or downloaded on the fly is not specified by either draft.

As far as I can tell, the IPR concerns appear to apply to one possible use for
announcing some identifiers rather than to the concept itself. Whether the
identifiers are used in an IPR-encumbered manner depends on where these identifiers
come from - are they well-known or are they created on the fly? In fact, the
decision on how to use the identifiers (and hence the IPR situation) is made
by the compressor.

Hans: Would the following statement in basic SigComp solve your IPR concerns?

"The capabilities announcement mechanism MUST only be used to announce support
for well-known algorithms."

[HH]  Thus, a capability announcement mechanism including the reserved state 
      identifiers for decompression algorithms, may also be used 
      for other mechanisms in SigComp-extended.

This is certainly the case, but I don't think that it means an IPR statement is
required on the basic SigComp draft even if it includes the ability to send a
list of identifiers from one endpoint to another. After all, the UDVM can run
any algorithm in existence - some encumbered, some not - and the decision on
which algorithms to run is made by the compressor.

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 21 Feb 2002 16:21:59 +0100

Richard,

> 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 do not believe we have to bother if anyone has
tried to protect the use of a feedback mechanism in general.

> So in release 04 of the SigComp draft I defined the following
<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

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.

> 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?

> [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. 

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.

Rgds,
/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 17:24:11 -0000

> 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

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.

> 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).

> 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?

> 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.

> 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).

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 25 Feb 2002 17:46:09 +0100

Richard,

> http://www.cdt.luth.se/rohc/msg03631.html and related messages).

Well, in that message you describe the mechanism, but the purpose
you later described (see above) was not at all mentioned. At that
time, the only purpose explained was to use it for explicit acking
of received state. My point was basically that we should explain,
justify and agree on what we want to achieve, and then start to
develop technical solutions.

> from one endpoint to another?

I would not immediately conclude that we obviously need a capability
announcement to support extended operations. I am not saying that we
can support everything without capability exchange, but I think this
should be discussed on a high level. Let's take the example with 
explicit acks, which is one kind of feedback. If we defined a generic
feedback mechanism to be used from the decompressor (incl. the UDVM)
to its peer compressor (who controls the UDVM). I can then see at
least two different principles for how this could be used for explicit
acks:
1) The compressor (who controls its peer UDVM) makes the UDVM send
feedback for received state through the feedback channel. If this is
possible, it would simply be an implementation issue. 
2) We could define feedback with a feedback type and only some
types are defined in SigComp. Others are left as reserved. New feedback
types must then be defined only for enhanced operation, so that a
compressor receiving feedback of "unknown" types could just discard it.
An explicit state-ack feedbcak type could then be defined in an
additional document. With such an approach, the enhancements would
be additional standards (new defined messages).

Please convince me that the above discussion is missing something
fundamental that invalidates the high-level principles described.

> > :   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
> > This is wrong. You MUST (as an author) indicate if you are 
> > aware of any patent on the technology.
> 
> "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."

I do not see the contradiction.
The above quote only discusses other parties IPR's, and it
is also captured in the RFC2026 text, which says "...rights in
the contribution that are reasonably and personally known to
the contributor". It is thus not expected that you should be
able to have knowledge and indicate presence of any IPR, but
at least those that are "reasonably and personally known". It
is therefore not true that you as an author do not need to have
opinions about patents, but the opposite. You are responsible to
make that judgment regarding those IPR's you are expected to
know about, and indicate "IPR risk" if you believe there is one.

Rgds, 
/L-E