[rohc] RE: IPR situation

"Lars-Erik Jonsson (EPL)" <Lars-Erik.Jonsson@epl.ericsson.se> Thu, 21 February 2002 15:27 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20304 for <rohc-archive@odin.ietf.org>; Thu, 21 Feb 2002 10:27:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28173; Thu, 21 Feb 2002 10:23:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28141 for <rohc@optimus.ietf.org>; Thu, 21 Feb 2002 10:23:13 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20155 for <rohc@ietf.org>; Thu, 21 Feb 2002 10:23:08 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1LFMdZc020577 for <rohc@ietf.org>; Thu, 21 Feb 2002 16:22:39 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Feb 21 16:22:39 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <YHKDVP4F>; Thu, 21 Feb 2002 16:13:04 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E31E19@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EPL)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Price, Richard'" <richard.price@roke.co.uk>, rohc@ietf.org
Date: Thu, 21 Feb 2002 16:21:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [rohc] RE: IPR situation
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression <rohc.ietf.org>
X-BeenThere: rohc@ietf.org

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

> 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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc