[rohc] RE: IPR situation

Richard,

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

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.

> > Do you mean that this is the only way to provide a hook for
> > extended operations without negotiation?
> 
> 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?

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.

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

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

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc