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

[Jukka Manner <[e-mail]>]

Hi Roland, thanks for your detailed analysis. You are right that the QoS 
NSLP would not necessarily included the binding concept had we known 
Columbia had a hidden IPR on it. So, essentially the IPR also affects 
the QoS NSLP. And the issue with RFC 2764 is pretty good, actually - 
interesting how the same stuff gets patented years after publishing it 
the first time. ;)

I would propose to go for item a) but knowing that if people want to 
progress the NSIS protocols towards standards track, we may need to 
re-engineer the designs to counter Columbia's IPR. Or, we may ask them 
to go back to their licensing terms and change them. Either is an issue 
for the future, allowing us to go forward now.

Jukka

On 12/06/2010 11:33 AM, Roland Bless wrote:
> 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