Re: [Roll] Roll IPR issues
"Tim Hirou" <THirou@convergencewireless.com> Fri, 12 February 2010 02:25 UTC
Return-Path: <THirou@convergencewireless.com>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF7F3A778E for <roll@core3.amsl.com>; Thu, 11 Feb 2010 18:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KkpdaIOTtBY for <roll@core3.amsl.com>; Thu, 11 Feb 2010 18:25:46 -0800 (PST)
Received: from convergencewireless.com (wsip-98-189-245-26.oc.oc.cox.net [98.189.245.26]) by core3.amsl.com (Postfix) with ESMTP id 0F49F3A7789 for <roll@ietf.org>; Thu, 11 Feb 2010 18:25:44 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Thu, 11 Feb 2010 18:35:37 -0800
Message-ID: <6881400D22DB1E4F8069C27BEBA58C450C986E@sbs01.cwi.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Roll] Roll IPR issues
thread-index: AcqqwkeV1dIVSc1LQSO8Iq1Pii3OSQAvG8Jg
From: Tim Hirou <THirou@convergencewireless.com>
To: Tzeta Tsao <tzeta.tsao@ekasystems.com>
Cc: roll@ietf.org
Subject: Re: [Roll] Roll IPR issues
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2010 02:25:47 -0000
Hello Tzeta, The IETF draft was draft-iwao-roll-dadr-00 Best Regards, Timothy L. Hirou Founder & CEO Convergence Wireless, Inc. 27392 Calle Arroyo Suite B San Juan Capistrano, CA 92675 (949) 542-4160 Office (949) 444-1723 Cell (949) 271-2385 Fax thirou@convergencewireless.com www.convergencewireless.com This e-mail message is for sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution, is prohibited. If you are not the intended recipient, please contact Convergence Wireless or the sender by e-mail and return all copies of the original message and any attachments. All reasonable costs in returning materials will be paid by Convergence Wireless. -----Original Message----- From: Tzeta Tsao [mailto:tzeta.tsao@ekasystems.com] Sent: Wednesday, February 10, 2010 7:23 PM To: Tim Hirou Cc: roll@ietf.org Subject: Re: [Roll] Roll IPR issues Hi Tim, As you mentioned in the previous post about more efficient designs than RPL, could you point us to these alternatives? regards, Tzeta ----- Original Message ---- From: Tim Hirou <THirou@convergencewireless.com> To: Tzeta Tsao <tzeta.tsao@ekasystems.com> Cc: roll@ietf.org Sent: Wed, February 10, 2010 7:24:16 PM Subject: RE: [Roll] Roll IPR issues Hello Tzeta, My concern is related to the standards work being done in the United States (e.g. The NIST Smart Grid Standardization Project and the Smart Energy 2.0 Standards work of the UCA OpenSG Working Group) Specifically, if the IETF ROLL has RPL as the only standard and NIST specifies that the Smart Energy 2.0 Standard is the only acceptable standard for use in the NIST Approved HAN application, I would be forced to use RPL and pay Cisco royalties because Smart Energy 2.0 is specifying RPL as their routing protocol even though we own patents in the U.S. that date back to 1996 which protect our ability to put a radio in a light fixture, in a ballast, use powerline carrier to perform indoor system control, and photovoltaic powered indoor radios (for the most cost effective way to deploy sensors). If Cisco, however, offers RPL royalty free is does become an issue for us. Best Regards, Timothy L. Hirou Founder & CEO Convergence Wireless, Inc. 27392 Calle Arroyo Suite B San Juan Capistrano, CA 92675 (949) 542-4160 Office (949) 444-1723 Cell (949) 271-2385 Fax thirou@convergencewireless.com www.convergencewireless.com This e-mail message is for sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution, is prohibited. If you are not the intended recipient, please contact Convergence Wireless or the sender by e-mail and return all copies of the original message and any attachments. All reasonable costs in returning materials will be paid by Convergence Wireless. -----Original Message----- From: Tzeta Tsao [mailto:tzeta.tsao@ekasystems.com] Sent: Wednesday, February 10, 2010 3:21 PM To: Tim Hirou; roll@ietf.org Subject: Re: [Roll] Roll IPR issues Hi Tim, Would you elaborate why the IPR concern prevents other approaches to contend? Regards, Tzeta ----- Original Message ---- From: Tim Hirou <THirou@convergencewireless.com> To: roll@ietf.org Sent: Wed, February 10, 2010 4:32:48 PM Subject: [Roll] Roll IPR issues Hello Fellow Rollers, I wanted to weigh in on the issue regarding Cisco's Intellectual Property for the current approach being taken within this ROLL Working Group. My issue is specifically centered around the fact that the standard should be written so that other approaches for Routing of Low Power and Lossy Networks need to be allowed to become a standard of this ROLL Working Group [in case another approach (such as the DADR proposal) is found to be a better approach than RPL]. This way, we are assured of choosing the best technology for the respective task.(e.g. As long as the alternative approach is at least "equivalent" or more efficient, where "efficient" is defined as equal to or faster data throughput performance with equal or better reliability for packet delivery in all the defined ROLL use cases, as long as it adheres to the 6LoWPAN standards for packet definitions.) Best Regards, Timothy L. Hirou Founder & CEO Convergence Wireless, Inc. 27392 Calle Arroyo Suite B San Juan Capistrano, CA 92675 (949) 542-4160 Office (949) 444-1723 Cell (949) 271-2385 Fax thirou@convergencewireless.com www.convergencewireless.com This e-mail message is for sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution, is prohibited. If you are not the intended recipient, please contact Convergence Wireless or the sender by e-mail and return all copies of the original message and any attachments. All reasonable costs in returning materials will be paid by Convergence Wireless. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Wednesday, February 10, 2010 9:12 AM To: Dan Lang Cc: roll@ietf.org Subject: Re: [Roll] Roll IPR issues 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: > 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. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- [Roll] Roll IPR issues Dan Lang
- Re: [Roll] Roll IPR issues Philip Levis
- Re: [Roll] Roll IPR issues Geoff Mulligan
- Re: [Roll] Roll IPR issues Alexandru Petrescu
- Re: [Roll] Roll IPR issues Adrian Farrel
- [Roll] Roll IPR issues Tim Hirou
- Re: [Roll] Roll IPR issues Tzeta Tsao
- [Roll] Roll IPR issues Ted.Humpal
- Re: [Roll] Roll IPR issues Tim Hirou
- Re: [Roll] Roll IPR issues Tzeta Tsao
- Re: [Roll] Roll IPR issues Tim Hirou