Subject: RE: [Capwap] RE: IPR issues/Close of Thread

From: <[email-masked]>
Date: Wed, 21 Sep 2005 09:18:21 -0700

Agreed, this tread and the resulting company attacks is getting out of
hand.  Please keep the discussion civil.

The IETF cannot force disclosure on any patent claims other disclosing
that they exist.  Unfortunately all four protocol have RAND disclosures
against them.  IPR is just one issue in deciding whether to adopt a
technology.   The only issue under discussion is how critical the IPR
issue is to CAPWAP.  

Thanks,
Dorothy 

From RFC 3669:

5.4. Patents versus Pending Patents Applied For
>  
>    The IETF does not (cannot) expect IPR claimants to tell a working
>    group specifically how they think a particular patent applies.  If
a
>    patent has already been granted, the IETF can reasonably expect
>    disclosure of the patent number and possibly the relevant IETF
>    document sections, which will allow working group participants to
>    explore details of the claims.  If a patent has not yet been
granted
>    (or if knowledge of the patent is restricted, e.g., for security
>    reasons), significantly less information is available.  In most
>    countries patent applications are published 18 months after they
are
>    filed, but in the USA that can be avoided if the applicant does not
>    also file outside the USA.  In some countries applications are a
>    matter of public record, but details of pending claims can be
>    modified at any time by the claim submitter before the patent is
>    granted.  It is not known before then what rights will actually be
>    granted.  Finally, rights can be contested in court, and nothing is
>    final until the courts decide -- perhaps not even then.  All the
IETF
>    can expect regarding a pending patent is disclosure that it exists,
>    the related IETF documents, and possibly the relevant IETF document
>    sections and some statement about licensing terms.
>  
>  
>  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Troy Dixler
Sent: Tuesday, September 20, 2005 8:22 PM
To: 'Dan Harkins'; 'Pat Calhoun [[email-masked]]'
Cc: 'James Kempf'; 'Ted Lemon'; 'Darren Loher'; [email-masked];
[email-masked]
Subject: RE: [Capwap] RE: IPR issues 

Guys,

It's really getting stale watching the personal attacks.  This is not
about Dan or Pat and your personal differences.  I saw this same thing
play out in Paris and the undertones are clearly unprofessional at this
point.  This thread is about an important issue involving the outcome of
this working group and not about individuals.

The fact is we are not standardizing 802.anything in this working group
and quite frankly after all the people that have made their points about
how uncomfortable they are with moving forward with the cloud of
uncertainty it appears we have a consensus.

Back to the issue, it's pretty clear that we've seen more than 6-7
people weigh in with various issues surrounding the current language
expressed by Cisco's proposal. 

There are just a few open questions that Pat needs to address (IMHO).
Pat will you consult with Cisco to change the language on the IPR
claims?  Will you make the specific IPR being claimed known to the
working group? These are very simple questions.  Please don't sling any
mud and just let the working group know the answers.  I understand if
Cisco does not want to change the language, but I also understand that
just about every other major vendor that actively participates on this
mailing list does not feel comfortable with the language used in your
IPR claims.

I think it's fair to see if Pat can discuss this with Cisco and hear the
results.  Based on that answer the working group chairs need to make
some decisions in the best interest of the IETF community.

-Troy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dan Harkins
> Sent: Tuesday, September 20, 2005 8:50 PM
> To: Pat Calhoun [[email-masked]]
> Cc: James Kempf; Ted Lemon; Darren Loher; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Capwap] RE: IPR issues
> 
>   Pat,
> 
>   I can't. I was not aware that language was added to Trapeze's IEEE 
> letters of assurance. To be fair that is an alternate licensing 
> strategy, the previous paragraph states that Trapeze Networks will 
> offer a non-exclusive license on "reasonable and non-discriminatory 
> terms" provided similar terms are given to Trapeze Networks (which is 
> what I understood the letters to state). But also, to be fair, there 
> is language in there that is, for all intents-and-purposes, exactly 
> the same as LWAPP's IPR licensing language. Needless to say, I am 
> surprised and upset.
> 
>   Are Airespace's/Cisco's claims in 11e, 11i, 11k, 11n, 11r any 
> different? I'd wager that that language was added because that's the 
> same terms other companies were offering their IEEE-related IPR for. 
> Lawyers tend to meet at bottom, and if other IEEE letters of assurance

> had that language then that's probably the reason it was added to 
> our's. That is not a rhetorical question by the way. Please tell me 
> what the terms are of Airespace's/Cisco's claims for the 5 areas of 
> 802.11 technology that any implementation of CAPWAP would need to also

> implement.
> 
>   Also, my imaginary scenarios are not attempts by your firm (or 
> apparently my firm!) to limit participation. It is that it invites 
> patent poaching (is that less pejorative?) since cross licensing is 
> the logical result of _ANY_ assertion of IPR.
> 
>   Yes, IPR claims against successful technologies have not hindered 
> that technology. IPR claims against technologies have also not been 
> enforced. I refer to a Cisco employee standing up in the VRRP BOF 
> saying that Cisco's HSRP patents precluded any unencumbered 
> implementation of VRRP and that Cisco would assert those patents 
> against anyone who implemented VRRP. To my knowledge Cisco has not 
> asserted those patents against anyone who implemented VRRP. But, as 
> with purchases of stock, past performance does not guarantee future
performance.
> 
>   Dan.
> 
> On Tue, 20 Sep 2005 16:46:58 PDT you wrote
> > Dan,
> >
> > Given you keep bringing up this point, could I possibly ask how you 
> > differentiate the LWAPP IPR licensing language from Trapeze's IPR 
> > statement on 802.11e, 802.11f, 802.11k and 802.11i, which I quote:
> >
> > "... said royalty-free license shall terminate should the licensee 
> > assert any intellectual property claims against Trapeze Networks".
> >
> > Just to be clear, your firm has used the exact same language in at 
> > least four scenarios that I am aware of, so clearly the LWAPP 
> > statement is really not that unusual - is it?
> >
> > So once more, you can cook up a plethora of imaginary scenarios 
> > where my firm attempts to limit others from participating in this 
> > space, but the reality is this does not represent past, or current, 
> > behavior. Once more, I point you to 
> > https://datatracker.ietf.org/public/ipr_list.cgi
> > which includes a variety of examples where Cisco (not to mention 
> > other
> > firms) have IPR claims against successful technologies, and 
> > ironically enough, the presence of IPR has not stopped companies 
> > from innovating, or being successful.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:[email-masked]]
> > > Sent: Tuesday, September 20, 2005 11:22 AM
> > > To: Pat Calhoun [[email-masked]]
> > > Cc: James Kempf; Ted Lemon; Darren Loher; [email-masked];
> > > [email-masked]
> > > Subject: Re: [Capwap] RE: IPR issues
> > >
> > >   Pat,
> > >
> > >   Your statement that "LWAPP is royalty free" has a huge
> > > condition applied to it. It is only "royalty free" for a
> > > company if it does not assert its own IPR against Cisco, on
> > > anything and not just its own claims on LWAPP.
> > >
> > >   As I stated earlier, that means that Cisco is free to steal
> > > one piece of intellectual property from each company that
> > > implements LWAPP.
> > >
> > >   Royalty free would be something like this:
> > >
> > > 	http://www.ietf.org/ietf/IPR/CAST-128-entrust
> > >
> > > LWAPP is _NOT ROYALTY FREE_.
> > >
> > >   Dan.
> > >
> > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote
> > > > That is correct, James. LWAPP is royalty free, while the others
> > > > (SLAPP, CTP, WiCOP) are under RAND terms.
> > > >
> > > > Folks, while I understand the concerns raised on the list, I
would
> > > > like to remind everyone that many technologies developed by
> > > IETF (any
> > > > any SDO for that matter) have IPR claims around them.
> > > Nonetheless, if
> > > > these technologies address a market need, they end up being
> > > very successful.
> > > >
> > > > Further, there is no guarantee that additional IPR claims
> > > won't show
> > > > up at a later date. There are many wireless companies that have
no
> > > > representation in this working group, and given the protocol
> > > > independence objective of CAPWAP, I wouldn't be surprised if
> > > > additional IPR is identified at a later date.
> > > >
> > > > But just because IPR exists does not make a technology less
> > > successful.
> > > > In fact, I would point you to
> > > > https://datatracker.ietf.org/public/ipr_list.cgi for a
> > > snapshot of the
> > > > current IPR claims for all of the IETF work in progress. Many
IETF
> > > > protocols are widely deployed that have IPR claims against
> > > them, and
> > > > these are very successful. In fact, if one were to design a WLAN
> > > > system, chances are one would run into other IPR claims
> > > that exist out
> > > > of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k
and
> > > > 802.11i (the last one being a clear example that patents do
> > > not stop a
> > > > protocol's usefulness), and the CAPWAP protocol is just part of
the
> > > > overall WLAN system.
> > > >
> > > > As we evaluate specific protocols, they each have their
> > > pros and cons.
> > > > In the end, a protocol must be chosen based on its
> > > completeness, its
> > > > ability to solve the problem, etc. IPR is just one of many
> > > criterion
> > > > that we must deal with during the protocol engineering process.
> > > > Trying to avoid known patents today does not guarantee a
> > > patent free
> > > > protocol by any means, nor does enhancing a lesser protocol.
> > > >
> > > > So I would urge the WG to look at IPR as one of many issues
> > > that must
> > > > be dealt with in our engineering task ahead of us...
> > > >
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of James Kempf
> > > > > Sent: Thursday, September 15, 2005 11:44 AM
> > > > > To: Ted Lemon
> > > > > Cc: Darren Loher; [email-masked]; [email-masked]
> > > > > Subject: Re: [Capwap] RE: IPR issues
> > > > >
> > > > > Let's be careful to distinguish which IPR notice we're talking
> > > > > about. As I read the two disclosures (and I'm not a
> > > lawyer so take
> > > > > this for what it's worth), the license associated with
> > > LWAPP would
> > > > > be royalty free if it is adopted as a standard, the claimed
terms
> > > > > for the others are RAND, which would not be royality free.
> > > > >
> > > > > Have I got that right?
> > > > >
> > > > >             jak
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Ted Lemon" <[email-masked]>
> > > > > To: "James Kempf" <[email-masked]>
> > > > > Cc: "Darren Loher" <[email-masked]>;
<[email-masked]>;
> > > > > <[email-masked]>
> > > > > Sent: Thursday, September 15, 2005 11:07 AM
> > > > > Subject: Re: [Capwap] RE: IPR issues
> > > > >
> > > > >
> > > > > On Sep 15, 2005, at 10:30 AM, James Kempf wrote:
> > > > > > I don't have any problem with a license if it is royalty
> > > > free, but  it
> > > > > > will certainly cause problems for the OpenSource community.
> > > > >
> > > > > The license in this case isn't royalty free.   It's
"reasonable,"
> > > > > which can mean anything, although in my experience to
> > > date Cisco has
> > > > > in fact been reasonable in the sense of the word that I
normally
> > > > > use.   The relevant document here is RFC3979, which doesn't
> > > > > explicitly say what to do, but has a good discussion of
> > > the issues
> > > > > involved.
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Capwap mailing list
> > > > > [email-masked]
> > > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > >
> > > > _______________________________________________
> > > > Capwap mailing list
> > > > [email-masked]
> > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > >
> > >
> >
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap