Subject: [Roll] Roll IPR issues

From: Dan Lang <[email-masked]>
Date: Tue, 9 Feb 2010 23:45:20 -0800

Hi All:

I understand that several people on this mailer have raised questions
about Cisco's IPR commitment for RPL, and about which Cisco patents
cover which parts of the RPL specification.  I'll address both of these
points below.  First, a disclaimer:  Even though I am a lawyer for
Cisco, I am not giving you legal advice;  that can only come from your
own legal counsel.

Preliminarily, all standards organizations grapple in some way with IPR
issues because formulating a standard often involves incorporating the
intellectual property of one or more participants.  In some
organizations such as the ITU and IEEE, virtually all the contributors
simply commit to license their essential IPR on reasonable and
non-discriminatory terms, leaving themselves free to to later charge
royalties that are not exactly specified.  Other organizations such as
the W3C insist that IPR be licensed on a royalty-free basis.  The IETF
for its part does not have a royalty-free requirement and there is a
range of licensing commitments that are used by participants.

Turning now to RPL, the exact language of Cisco's commitment is at
http://www.ietf.org/ietf-ftp/IPR/cisco-ipr-draft-dt-roll-rpl-01.txt.
This is a legal statement and again, although IAAL, remember that I am
not your legal counsel, so my comments are here to help you understand
some of the underlying issues and not to provide an interpretation.
I'll focus on the issues that people have asked about.

First, Cisco promises not to sue anyone for products that implement the
standard under any of its essential patents.  Even though Cisco lists
several patents and patent applications in its disclosure, its promise
not to sue is not limited to those patent assets, but to *any* Cisco
essential patents.  In contrast to this promise to not assert patents,
many participants in other IETF WGs have made commitments that allow for
royalty-bearing licenses on their disclosed IPR.

Second, Cisco has a "defensive suspension" provision, which allows Cisco
to assert those essential patents against someone who asserts their own
patent (whether or not related to RPL) against Cisco ("...Cisco retains
the right to assert its patents (including the right to claim past
royalties) against any party that asserts a patent it owns or controls
(either directly or indirectly) against Cisco or any of Cisco's
affiliates or successors in title or against any products of Cisco or
any products of any of Cisco's affiliates either alone or in combination
with other products").  The wording of our statement may seem complex to
a lay reader, but in fact similar statements are commonly used by other
IETF participants.  Here are some examples that are similar, if not
exactly identical to, Cisco's defensive suspension terms:

https://datatracker.ietf.org/ipr/1173/  (Juniper)
https://datatracker.ietf.org/ipr/1254/  (Huawei)
https://datatracker.ietf.org/ipr/1244/  (Ericsson)
https://datatracker.ietf.org/ipr/947/  (H3C Technology)
https://datatracker.ietf.org/ipr/1170/  (Vidyo)
https://datatracker.ietf.org/ipr/1253/  (Verizon)
https://datatracker.ietf.org/ipr/1235/  (Apple)
https://datatracker.ietf.org/ipr/674/  (Digital Fountain)
https://datatracker.ietf.org/ipr/935/  (Avaya)

Indeed, there are numerous I-Ds and RFCs that have progressed and
succeeded with this type of statement even where there may be patent
coverage.  The majority of Internet technologies are patented, some
under more onerous licensing conditions than ours above, and have been
deployed successfully for years.

We see the practice of making this kind of declaration (combining our  
commitment to not assert and the "defensive suspension") on the vast  
majority
of IETF I-Ds and RFCs where we have essential patents as being both
generous and effective in driving open standards and the development  
of the Internet.
   The IETF and Cisco have extensive positive experience with this  
style of statement,
gathered over years of development, deployment, and use.

Finally, questions have been raised on the mailer about which portions
of the specification are covered by Cisco patents.  It is natural to be
interested in this question but we have good reasons for not answering
it.  Infringement analysis and claim construction are legal questions
which are best answered by your own legal advisers and not by Cisco
lawyers or engineers.   Furthermore, if even if we presented our own  
current views
  they would not reflect later changes in patent claims during  
prosecution or even changes in the
specification.

I hope that this helps clarify the issues and move the discussion to
resolution.

Best regards,

Dan Lang

Dan Lang
Director, Intellectual Property
Legal Services
Cisco Systems, Inc.

---

From: Philip Levis <[email-masked]>
Date: Wed, 10 Feb 2010 07:44:03 -0800

> Cisco, I am not giving you legal advice;  that can only come from your

Dan,

Thank you for your message; this is very helpful, especially for some of us who are pretty new to the IETF. 

My reading is that this is standard practice, which has been used (and will be used) many times, in many different areas of the IETF. Cisco's IPR isn't disrupting the rest of the Internet, so there's no reason it would especially do so here.

Phil

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 10 Feb 2010 09:12:16 -0700

Dan,
  thanks for the information.  this is somewhat helpful.

are there some ietf documents that are not early stage drafts that are
standards track that have this licensing (your list didn't include any)?

I would like to understand the impact on RPL should the WG decide that
we'd like to avoid the IPR.  From what you said, it seems that this is
not possible to determine. Then I only wish that we had known about the
IPR encumbrance earlier in the process. 	geoff

On Tue, 2010-02-09 at 23:45 -0800, Dan Lang wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 17:32:58 +0100

Philip,  I take advantage of your note to say also that...

There are cases at IETF where basic design _has_ been redesigned after
IPR has been disclosed, and after the relevant parts have been
identified, with the specific goal of designing around that IPR.  The
most recent I can remember of was with DNS and internationalization.

I think also that GRE (a tunnelling protocol) standardization has seen
some conflicts related to IPR and led to Cisco-mostly implementations.
Situation has changed with time, i.e. GRE is now widely available with
linux kernels.

I remember issues with Apple discovery mechanisms as well (zeroconf or
Bonjour stuff IIRC).

(this is not to paint some actors in a corner - it's already wonderful
they are at IETF, as opposed to some other very relevant companies who
don't come to IETF).

Alex

Le 10/02/2010 16:44, Philip Levis a écrit :
>> I understand that several people on this mailer have raised
>> questions about Cisco's IPR commitment for RPL, and about which
>> Cisco patents cover which parts of the RPL specification.  I'll
>> address both of these points below.  First, a disclaimer:  Even
>> though I am a lawyer for Cisco, I am not giving you legal advice;
>> that can only come from your own legal counsel.
>
> Dan,
>
> My reading is that this is standard practice, which has been used
> (and will be used) many times, in many different areas of the IETF.
> Cisco's IPR isn't disrupting the rest of the Internet, so there's no
>  reason it would especially do so here.
>
> Phil _______________________________________________ Roll mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Feb 2010 16:37:08 -0000

Hi,

If you go to https://datatracker.ietf.org/ipr/search/ you can enter "Cisco" 
in the keyword search.

You will see a list of drafts and RFCs for which Cisco have disclosed IPR 
and for which they have notified about their license terms.

There are some examples in the routing area, for example RSVP-TE and LDP for 
MPLS networks (widely deployed), BFD (deployed and currently being discussed 
by the BFD WG).

Cheers,
Adrian