Re: IPR Disclosure: The Trustees of Columbia University in the City of New York's Statement about IPR related to draft-ietf-nsis-tunnel-13

Hi,

On 03.12.2010 17:45, Jukka Manner wrote:
> The authors of draft-ietf-nsis-tunnel have disclosed an IPR that affects
> the accepted, but not yet published, NSIS document.
> 
> We need guidance from the working group on how to proceed:
> 
> a) Do members of the WG accept those terms,
> b) Do you want to redesign the protocol to work around the IPR,
> c) Do you want to ask Columbia to modify the terms, or
> d) Do we drop the document from the WG (authors can still pursue
> publications through the independent track)?
> 
> Items a) and d) let's us continue with the publication procedure (for
> item d) we just remove references to the work from the mobility
> applicability document). Items b) and c) will need considerable work and
> since the WG is closing, I would like to avoid them.

When browsing through:
http://www.freepatentsonline.com/y2007/0109966.html
it's not entirely clear to me how QoS NSLP in RFC 5974
is also affected by this. It provides the binding code, which
is one mechanism that the patent claims refer to:

> 2. The method of claim 1, wherein the first binding information of the first binding data object comprises a binding type value indicating a binding type of the end-to-end session.
> 
> 3. The method of claim 1, wherein the second binding information of the second binding data object comprises a binding type value indicating a binding type of the tunnel session.
> 
> 4. The method of claim 2, wherein the binding type value comprises an end-to-end-tunnel binding, indicating a binding between the end-to-end session and the tunnel session.

and so on....

I guess that the WG probably wouldn't have included the binding code
into QoS NSLP if we already had knowledge of the patent application
(BTW: a provisional application was filed on Oct 21, 2005 already).

Furthermore, RFC2764 (RSVP Operation Over IP Tunnels)
http://www.rfc-editor.org/rfc/rfc2746.txt
defines very similar mechanisms and the claims read as
if they can be applied to that RFC, too (thus voiding
most of the claims).
I don't buy the reasoning that RSVP is receiver-oriented
and doesn't support mobility, since most of the claims are
not referring to these restrictions, except maybe claim 25.
Any thoughts on that?

Regards,
 Roland