Re: [Ospf-wireless-design] Design Team Problem Statement

[Thomas Heide Clausen <[e-mail]>]

Although I have not studied the IETF IPR RFC's and the IPR statement in 
question in detail (travelling, limited bandwidth...), I agree with Joe and 
Richard: if at all possible, I too prefer IPR-unencumbered designs. 

Cheers,

--thomas

...... Original Message .......
On Wed, 22 Sep 2004 10:59:36 -0400 Joe Macker <[e-mail]> 
wrote:
>I vote for preferring a non-IPR encumbered design.
>I think we know how to do most of this from existing work that is 
>nonencumbered.
>
>-Joe
>
>Henderson, Thomas R wrote:
>
>>  
>>
>>>-----Original Message-----
>>>From: Richard [mailto:[e-mail]] 
>>>Sent: Tuesday, September 21, 2004 7:16 AM
>>>To: Henderson, Thomas R
>>>Cc: [e-mail]
>>>Subject: Re: [Ospf-wireless-design] Design Team Problem Statement
>>>
>>>
>>>Henderson, Thomas R wrote:
>>>
>>>    
>>>
>>>>>> 7) Technology without IPR claims should be preferred over 
>>>>>>
>>>>>>          
>>>>>>
>>>>>technology
>>>>>
>>>>>        
>>>>>
>>>>>>    with IPR claims (ala section 8 of RFC 3668).
>>>>>>
>>>>>>          
>>>>>>
>>>>>I hope we consider performance of the technology, and not reject a
>>>>>design just because it has an IPR statement attached to it.  
>>>>>Especially,
>>>>>since many IPR claims are purely defensive...as is Cisco's.
>>>>>
>>>>>        
>>>>>
>>>>Would you agree to this rephrasing:  "The design team will use 
>>>>RFC 3668 guidance for dealing with IPR claims."?  
>>>>
>>>>RFC 3668 supersedes RFC 2026 Section 10, and my reading of it
>>>>suggests to me that it should not cause any trouble for someone 
>>>>with a purely defensive IPR claim.
>>>>
>>>>      
>>>>
>>>RFC 3668 does not contain the word "defensive".  How can we be sure a
>>>patent is "purely defensive"?  I think the key term is "royalty-free
>>>licensing". Section 8 states: "In general, IETF working groups prefer
>>>technologies with no known IPR claims or, for technologies with claims
>>>against them, an offer of royalty-free licensing." If Cisco writes an
>>>IPR statement that states anyone can use the protocol royalty-free if
>>>it is included in an IETF standard or a standards-track RFC, 
>>>that would
>>>be one way to be sure the IPR claim is purely defensive. SRI 
>>>wrote such
>>>an IPR statement for TBRPF.
>>>
>>>    
>>>
>>
>>Section 6.5 of RFC 3668 states:
>>   Since IPR disclosures will be used by IETF working groups during
>>   their evaluation of alternative technical solutions, it is helpful if
>>   an IPR disclosure includes information about licensing of the IPR in
>>   case Implementing Technologies require a license.  Specifically, it
>>   is helpful to indicate whether, upon approval by the IESG for
>>   publication as RFCs of the relevant IETF specification(s), all
>>   persons will be able to obtain the right to implement, use,
>>   distribute and exercise other rights with respect to an Implementing
>>   Technology a) under a royalty-free and otherwise reasonable and non-
>>   discriminatory license, or b) under a license that contains
>>   reasonable and non-discriminatory terms and conditions, including a
>>   reasonable royalty or other payment, or c) without the need to obtain
>>   a license from the IPR holder.
>>
>>Cisco's IPR statement is at:
>>http://www.ietf.org/ietf/IPR/cisco-ipr-draft-chandra-ospf-manet-ext-01.txt
>>It is not clear which specific mechanisms in this draft are being claimed.
>>
>>Section 8 of RFC 3668 states:
>>   In general, IETF working groups prefer technologies with no known IPR
>>   claims or, for technologies with claims against them, an offer of
>>   royalty-free licensing.  But IETF working groups have the discretion
>>   to adopt technology with a commitment of fair and non-discriminatory
>>   terms, or even with no licensing commitment, if they feel that this
>>   technology is superior enough to alternatives with fewer IPR claims
>>   or free licensing to outweigh the potential cost of the licenses.
>>
>>So it seems to me that the Cisco claim does not fall under the 
>>"royalty-free" category, so the working group can decide whether to adopt 
>>it at the working group's discretion, as discussed in Section 8.
>>
>>Tom
>>
>>_______________________________________________
>>Ospf-wireless-design mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
>>
>>
>>  
>>
>
>
>_______________________________________________
>Ospf-wireless-design mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
>


_______________________________________________
Ospf-wireless-design mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design