From zach@sensinode.com Mon Feb 1 00:44:11 2010 Return-Path: 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 7D8273A6767 for ; Mon, 1 Feb 2010 00:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 MQwcnBCoRVvg for ; Mon, 1 Feb 2010 00:44:10 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 882A63A691A for ; Mon, 1 Feb 2010 00:44:08 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o118iV60016569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Feb 2010 10:44:32 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <389672.5062.qm@web1203.biz.mail.gq1.yahoo.com> Date: Mon, 1 Feb 2010 10:44:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> <4B6335AC.4090902@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D012357A9@XMB-AMS-107.cisco.com> <389672.5062.qm@web1203.biz.mail.gq1.yahoo.com> To: Roger Alexander X-Mailer: Apple Mail (2.1077) Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 08:44:11 -0000 I totally agree with Roger and the earlier comment from Don Sturek. Time = to move forward with the work. Zach On Jan 30, 2010, at 15:34 , Roger Alexander wrote: > Hi Pascal, >=20 > I support the effort made in being open and forthright regarding the = IPR issue and Cisco's IPR provisions as it relates to RPL. With any = standards development it is impossible to a priori guarantee that it = does not include elements of any given individual's or company's IPR. = They key therefore, particularly in an open forum like the IETF, is for = the community, collectively, to be as forthright and transparent as = possible where individuals or companies may have IPR or knowledge of IPR = that may be related to on-going work. In that regard, I certainly = appreciate the steps already taken. >=20 > Thanks. >=20 > Roger >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: Pascal Thubert (pthubert) > To: Alexandru Petrescu > Cc: Pascal Thubert ; ROLL WG > Sent: Sat, January 30, 2010 7:44:18 AM > Subject: Re: [Roll] IPR issue >=20 > Hi Alex: >=20 > I have no clue for OSPF but I think I follow your drift and agree with = your points.=20 >=20 > Also you're perfectly correct that for NEMO, both the Nokia and the = Cisco statements did not prevent the open source implementations to = thrive, and the same goes for RPL. >=20 > And finally I also agree with you this thread is really suspicious = from the start. That was the occasion to make sure that the group was = well aware of the Cisco IPR and terms, though. Maybe we can leave it at = that for the time being? >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: vendredi 29 janvier 2010 20:23 > To: Pascal Thubert (pthubert) > Cc: JP Vasseur (jvasseur); Pascal Thubert; ROLL WG > Subject: Re: [Roll] IPR issue >=20 > Le 29/01/2010 19:19, Pascal Thubert (pthubert) a =E9crit : >> Hi Alex: >>=20 >> This is an IETF list, it's open with the reasonable hope that people >> who join wish to understand and contribute to the technology. >=20 > Yes, open, but there are rules, e.g. RFC2418 at a point: >=20 > "Moderate the WG email list >=20 > The Chair should attempt to ensure that the discussions on this > list are relevant and that they converge to consensus = agreements." >=20 >> This is not always the case but it usually works. I would not expect >> from the chairs or some bigger brother to police every mail that >> comes in the list. >=20 > Hmm, not sure. In netlmm WG there was some unidentified poster at = some > point who stirred waters about "netlemmings". There was Chair > intervention to give guidance. It was reassuring. >=20 > Regularly on the IETF list we see complaints, procedure, email rights, > appeals, etc. >=20 >> And it is perfectly acceptable to discuss IPR. You did so in the >> past. Since we are at it... >=20 > I am ready to discuss with you about IPR aspects. But the current IPR > thread was provoked by we don't know what. It's difficult to continue > discussing without doubting it's all bluff (as in poker: deceiving > provocation). >=20 >> As an author of RFC 3963, I trust that you remember that Cisco had >> IPR on NEMO too. The terms that were finally used are the same as >> those that are proposed here, for all I assert/remember. Since you >> mention it in your mail, would you think that Cisco IPR had any >> counter effect on open source? >=20 > Thanks for mentioning it. YEs, we worked together on NEMO and IPR > aspects. Cisco's IPR claims on NEMO were ok, but were not the only > ones. Nokia's IPR were explicitely geared towards Open Source. >=20 > I wonder what's the IPR count for OSPF? (how many different companies > made IPR claims on it). >=20 > Anyways, >=20 > Alex >=20 >>=20 >> Cheers, >>=20 >> Pascal >>=20 >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> vendredi 29 janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal >> Thubert; ROLL WG Subject: Re: [Roll] IPR issue >>=20 >> Dear JP, >>=20 >> Do you tolerate unidentified comments happening in this group? >>=20 >> Is this serious? >>=20 >> Alex >>=20 >> Le 29/01/2010 18:37, JP Vasseur a =E9crit : >>> Dear Alex, >>>=20 >>> On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: >>>=20 >>>> JP, >>>>=20 >>>> Thank for this note. >>>>=20 >>>> Please help us understand _who_ is 'RAV' - the anonymous poster >>>> with address ietfroll@yahoo.com, who posted recently about IPR >>>> and ROLL. >>>>=20 >>>> This helps better understand what's going on with IPR and RoLL. >>>>=20 >>>=20 >>> unfortunately I cannot tell you ... Just don't know. >>>=20 >>> Thanks, >>>=20 >>> JP. >>>=20 >>>> Alex >>>>=20 >>>> Le 28/01/2010 20:47, JP Vasseur a =E9crit : >>>>> Dear all, >>>>>=20 >>>>> Some of you expressed some concerns about IPR on RPL, more >>>>> specifically, >>>>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 > Pascal Thubert, since you are the closest to this issue, could you >>>>> please shed some light on the IPR statement for that invention >>>>> ? >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP. >>>>>=20 >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jvasseur@cisco.com Mon Feb 1 05:56:48 2010 Return-Path: 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 105633A68A4 for ; Mon, 1 Feb 2010 05:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.708 X-Spam-Level: X-Spam-Status: No, score=-9.708 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ubmbunGKqecg for ; Mon, 1 Feb 2010 05:56:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2BB6128C0E5 for ; Mon, 1 Feb 2010 05:56:47 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIdsZkutJV2d/2dsb2JhbADCR5ZhhEUE X-IronPort-AV: E=Sophos;i="4.49,383,1262563200"; d="scan'208,217";a="294520052" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 01 Feb 2010 13:57:21 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o11Dv2n9029392 for ; Mon, 1 Feb 2010 13:57:21 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 14:57:14 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 14:57:14 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-238--1037374939 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Feb 2010 14:57:13 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Feb 2010 13:57:14.0677 (UTC) FILETIME=[756FA650:01CAA346] Subject: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 13:56:48 -0000 --Apple-Mail-238--1037374939 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Given the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on the list. I will make a consensus call on Friday 11 February. Thanks. JP. --Apple-Mail-238--1037374939 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all,

Given the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on the list. I will make a consensus call on Friday 11 February.

Thanks.

JP.

--Apple-Mail-238--1037374939-- From d.sturek@att.net Mon Feb 1 06:59:15 2010 Return-Path: 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 5FFBA28C140 for ; Mon, 1 Feb 2010 06:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 97Kqaw6vsPQ3 for ; Mon, 1 Feb 2010 06:59:14 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 7F54B28C13E for ; Mon, 1 Feb 2010 06:59:14 -0800 (PST) Received: (qmail 23440 invoked from network); 1 Feb 2010 14:59:45 -0000 Received: from Studio (d.sturek@209.203.104.177 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 01 Feb 2010 06:59:45 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: DaaPji0VM1l6mpPCtI1rtRkD8KqjKoZuf8PU2WgNHbUHAf5aczzveBUapDWnLpBsY2EN4fDe5mhOkjsKG0YgSBNKBRR90ap8ahHgtYkxBW7w1QvoSIVYowM8Lk77XgkWcQ_4uf6j5z.sATDLZtQFBPwyuT.8PW.LoEhWkTbfMjIK7lpb3WqUkNn3WbhD0UWnQmGWK0QpSaIchFmFgM4S73K9Ghyem9laY_S9.ZEXaKdDZGXd4iB2qyb5gJ7p9UjSFqyb7ZroZTsu.vr3ZoQ1VH2p X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: In-Reply-To: Date: Mon, 1 Feb 2010 06:59:42 -0800 Message-ID: <006e01caa34f$2ff21aa0$8fd64fe0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CAA30C.21CEDAA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqjRo4RC47SSA0zS0q9HFxfF1/ukQACH9tA Content-Language: en-us Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 14:59:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01CAA30C.21CEDAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, As noted in an earlier thread, I am fine with proceeding using the draft-ietf-roll-rpl. Best Regards, Don Sturek From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Monday, February 01, 2010 5:57 AM To: ROLL WG Subject: [Roll] Closing on the IPR Dear all, Given the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on the list. I will make a consensus call on Friday 11 February. Thanks. JP. ------=_NextPart_000_006F_01CAA30C.21CEDAA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

As noted in an earlier thread, I am fine with proceeding = using the draft-ietf-roll-rpl.

 

Best Regards,

 

Don Sturek

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Monday, February 01, 2010 5:57 AM
To: ROLL WG
Subject: [Roll] Closing on the IPR

 

Dear all,

 

Given the discussions about the IPR disclosure at = https://datatracker.ietf.= org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/poli= cy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on = the list. I will make a consensus call on Friday 11 February.

 

Thanks.

 

JP.

 

------=_NextPart_000_006F_01CAA30C.21CEDAA0-- From tzeta.tsao@ekasystems.com Mon Feb 1 07:05:39 2010 Return-Path: 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 E7AB928C0F5 for ; Mon, 1 Feb 2010 07:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Qzs5JVoyg1SL for ; Mon, 1 Feb 2010 07:05:38 -0800 (PST) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by core3.amsl.com (Postfix) with SMTP id 318AA28C15F for ; Mon, 1 Feb 2010 07:05:38 -0800 (PST) Received: (qmail 42818 invoked from network); 1 Feb 2010 15:06:10 -0000 Received: from (tzeta.tsao@209.48.242.70 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 01 Feb 2010 07:06:10 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: jbegxaEVM1lyMIRSY3XZWeMyy6_g2aBwh84QyO7DopX_YZV4X5UmthlyPEexTXNP0FLZZ7QdJVqSYboUECmJUhRcP.vAJurmRc89mP2VdBoVkBmuNyN2Bl76a4oLFVMTjxrJ8u9PTEOOGZhqtZtxoMqmoi61Fjy59EXZ2x2NhseqxSMjfR4Te_nH1Y0j0Yb8bEqYeXCB6bKAIevH1YLLYb8HZsEtp2KzTF4_gm9IFALMpk3LUAbdFLQ9XgmYwrnFNWSDON2Y5j4FtkmheVs0TbpuiQmNzKV4R1MtItuBaH6yHF7JpODIytLBjQ377QIu2Y0ylQ6KQVvxZltvFHC.MsJKeVUOLWLO1q_YIyNWa0G5u0wQxd.hnyGXzd0fflGboYHknf41veQ3hIw1nvyCoOcLAY28kK6qYNNnM9H3m_D9cuL6WTrHqmVufIiVUO.yUseK6vLBPexj0mepQuPWMezrHbm6HKXDIgPeh0Fkugv__UmPLoapNaA3QXkIWYeass83tcJPJtQKyRfUgNxBdmWoRqjXHEoX.alrWVN9VA9ZJpQl6zZypBEu9NfMIvLfmFqfXvMFj66LpjEIyFb3ILGteNxdC2EQVLQSTfuXYB14yc0WVaJRlrFIPq64r7FLOmZXm0PFIECJY26rVjVYC9ff5wK_AD3Fv6t.hTXOSf4tsDDTEYwTicAHbIDzG.8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B66EDE1.4010501@ekasystems.com> Date: Mon, 01 Feb 2010 10:06:09 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Michael Richardson References: <6986.1264989792@marajade.sandelman.ca> In-Reply-To: <6986.1264989792@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF ROLL Subject: Re: [Roll] sequence number increment and wrap X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 15:05:40 -0000 Indeed, replay protection can be a deceptively simple problem. For example, here is a security analysis on 802.15.4 and it has a lot to say about 15.4's Access Control List, which is based on a counter: http://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf. Maintaining a counter for every neighbor may present a problem for some devices. Suppose one uses MiniSec's approach: http://sparrow.ece.cmu.edu/group/pub/luk_mezzour_perrig_miniSec.pdf. In this case, a device sends one-byte counter in the message for sync but actually keeps a multi-byte counter per neighbor: in many situations it will wind up needing a few k bytes. Some networks/devices have time, so using timestamp for anti-replay is another option. Of course, a complete design will need to address issues such as re-sync of states due to power outages, etc.; the question is then if it is possible for us to put requirements on the rest of the system. Tzeta Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Are there any security implications in the sequence number? > > (I realize that the security architecture is not complete. > I assume that there will be some kind of per-message authenticator (MAC) > How this is keyed is really the hard part of the architectured) > > Typically, there is some concern if there is a replay of a lower > sequence number. Such an event causes the network to return to some > earlier state. The concern is that an attacker can record a previously > authenticated set of messages and then play them back, intentionally > causing such a time travel. > > One question is: is this a threat? > > The usual defense against that is that the sequence number must be > monotonically increasing. If a nodes has been out of communication for > a period of time, it may see a abrupt jump in sequence number, but > that's okay --- if the authentication checks out, it advances. > > The problem is that we have an 8-bit field, and it isn't clear how much > it may advance --- advances of 254 for instance, look like going > backwards 1, and may be disallowed. > > The text in -05 is: > > Sequence Number: 8-bit unsigned integer set by the DODAG root, > incremented according to a policy provisioned at the DODAG > root, and propagated with no change down the DODAG. Each > increment SHOULD have a value of 1 and may cause a wrap back to > zero. > > > It is good that the text tells what the DODAG should do, but we need to > know what happens if there is an increment of more than 1, and how to > know when there is an increment of more than 1, when it is a wrap. > > My first suggestion is that increments of up to 127 should be acceptable, as > can unambiguously be understood to be increments (with possible > wraps). Further, any increment which does not cause a wrap can be > accepted as well. > > What I think would decide this is to understand under what conditions > the sequence number can and should be incremented? > > - From my understanding, it's a DAG Iteration, and I think that this will > happen somewhat often --- not as often as once a second, but certainly > more often than once an hour. > > It is also my understanding that many DIO messages will be sent with the > same sequence number --- it is not incremented each time the DIO is > sent. > > I therefore suggest renaming this field to "DIO Iteration Number". > > - -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBS2Y2XoCLcPvd0N1lAQL0BwgAvyVovfNupQL7MjNOB/KDM3UaJJS0vVli > yzKliEF7CvhrT8nxowLKK40XCyDp5vUNIzVMZrZOSknXcfyJdlWgFEVS7E4lcTz6 > mSJJ4pyIAmSiUlBTka5p8YJqtzSDBRsEA4Egz0fRXJyhN2kdbw3kLOcTId6WeB0o > +MJMnl1DjFryahQP8cuqwBy6nTgshqmPFsMUPFnf4jvUIZsK6L3Ucmp8SjUUndMI > i8f4JWAsq/3/hMqfaAZYTAqmzlXBscLWh+lpzd5OOvfGS8vCf8/CZr3ewrvkDo7f > 9iAqcw8DiSqNAmPUu6UT+Bf/MledzDflFCOlKSl5l0v28Y6bE3FccA== > =6mQT > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Pete.Stpierre@Sun.COM Mon Feb 1 08:46:05 2010 Return-Path: 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 20F2828C1B6 for ; Mon, 1 Feb 2010 08:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Y618VWa0uvv2 for ; Mon, 1 Feb 2010 08:46:03 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id BC92028C13E for ; Mon, 1 Feb 2010 08:46:03 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o11GkcKv024627 for ; Mon, 1 Feb 2010 08:46:38 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CuNc4qZvcW5kYwlRbghpxA)" Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX60090096EE200@fe-sfbay-09.sun.com> for roll@ietf.org; Mon, 01 Feb 2010 08:46:38 -0800 (PST) Received: from [192.168.1.56] (99-57-137-67.lightspeed.sntcca.sbcglobal.net [99.57.137.67]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX60084999PIC00@fe-sfbay-09.sun.com>; Mon, 01 Feb 2010 08:46:38 -0800 (PST) Date: Mon, 01 Feb 2010 08:46:37 -0800 From: "Pete St. Pierre" In-reply-to: Sender: Pete.Stpierre@Sun.COM To: JP Vasseur Message-id: X-Mailer: Apple Mail (2.1077) References: Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 16:46:05 -0000 --Boundary_(ID_CuNc4qZvcW5kYwlRbghpxA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi JP - I think it would be easier to answer this question if we knew exactly which portions of the work were encumbered. If Pascal could summarize the implications of Cisco's IP on the current draft, I'm sure we'd all have a better understanding and could then move this along with confidence. Regards, ...Pete On Feb 1, 2010, at 5:57 AM, JP Vasseur wrote: > Dear all, > > Given the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on the list. I will make a consensus call on Friday 11 February. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Boundary_(ID_CuNc4qZvcW5kYwlRbghpxA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Hi JP -
I = think it would be easier to answer this question if we knew  exa= ctly which portions of the work were encumbered.

=
If Pascal could summarize the implications of Cisco's IP on the = current draft, I'm sure we'd all have a better understanding and coul= d then move this along with confidence.

Rega= rds,
...Pete


 =  
On Feb 1, 2010, at 5:57 AM, JP Vasseur wrote:
<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit= -line-break: after-white-space; ">Dear all,

Given = the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ = and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would lik= e to make sure that the working group is happy to proceed with draft-= ietf-roll-rpl in its current form. Please state your opinions on the = list. I will make a consensus call on Friday 11 February.
<= br>
Thanks.

JP.

_______________________________________________
Roll mailing list<= br>Roll@ietf.org
https://www.= ietf.org/mailman/listinfo/roll

--Boundary_(ID_CuNc4qZvcW5kYwlRbghpxA)-- From emmanuel.baccelli@gmail.com Mon Feb 1 09:35:34 2010 Return-Path: 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 5D43E28C1C3 for ; Mon, 1 Feb 2010 09:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 27Xbx4jeV9ia for ; Mon, 1 Feb 2010 09:35:33 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 11FB428C1AE for ; Mon, 1 Feb 2010 09:35:32 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so1265323eye.51 for ; Mon, 01 Feb 2010 09:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=1FKSj8m8KIIZdGOWKSqXlkYoJhEb8hd8/mf5rR06Y5E=; b=sr13VYw1DK4IN3MQq2lAseskAT+173cEYZBS6XngQbLz68/wJdXkeDzEGvVnzDN5hu THI0UUKjc7tTGzFUFsfQnkgmlrnW2QSxAeZJDWC4kVeLqrXEIj9u8QdVg+wTIXpSj1Vq 3BrQ4ztsRumivOT0unPmTR7PuE+UN+Sdtaudg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=pBpZ1BRCo9ljQXOvhhiEgev3dvG6SN+S5Pt1LbV1BclS3zfIVVxnOCUPR9Jjh+LFvZ llKhHbMoaiJ16/C7LWMcPy9f+yBrk16uKq4TgM/Avp0nPBs+OmbtaK9vqEqS8Ckou9Rr Zi9M8qqDPghikF2EXe2a31VYieHGWrDjHGzbg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.38.7 with SMTP id z7mr4718887ebd.75.1265045764136; Mon, 01 Feb 2010 09:36:04 -0800 (PST) In-Reply-To: References: From: Emmanuel Baccelli Date: Mon, 1 Feb 2010 18:35:44 +0100 X-Google-Sender-Auth: 8b94a99fd2a124a5 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=00148530b918656063047e8d6bf5 Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 17:35:34 -0000 --00148530b918656063047e8d6bf5 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, as discussed, IPR may indeed be difficult to avoid entirely, even without looming deadlines... If I recall correctly, we are discussing this because someone claimed that Cisco forces an IPR deal which, quoting this now famous anonymous, can be summarized by the following: "Free license to use the patents in RPL so long as you and your company don't sue Cisco over any other patent for anything." We are engineers, not lawyers, so to understand legal matters, most of us need such one-liner to understand what is the deal. Therefore in my mind, the right questions that we need to ask ourselves at this point are: 1 - is the above an accurate summary of the IPR deal imposed by Cisco? 2 - if no, what is an accurate summary of the IPR deal imposed by Cisco? 3 - if yes, are we OK with these terms? Let's clarify this and move on quickly, back to protocol design where we belong! Regards, Emmanuel On Mon, Feb 1, 2010 at 5:46 PM, Pete St. Pierre wrote: > Hi JP - > I think it would be easier to answer this question if we knew exactly > which portions of the work were encumbered. > > If Pascal could summarize the implications of Cisco's IP on the current > draft, I'm sure we'd all have a better understanding and could then move > this along with confidence. > > Regards, > ...Pete > > > > On Feb 1, 2010, at 5:57 AM, JP Vasseur wrote: > > Dear all, > > Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at > http://www.ietf.org/ipr/policy.html I would like to make sure that the > working group is happy to proceed with draft-ietf-roll-rpl in its current > form. Please state your opinions on the list. I will make a consensus call > on Friday 11 February. > > Thanks. > > JP. > > _______________________________________________ > 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 > > --00148530b918656063047e8d6bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,

as discussed, IPR may indeed be difficult to avoi= d entirely, even without looming deadlines... If I recall correctly, we are= discussing this because someone claimed that Cisco forces an IPR deal whic= h, quoting this now famous anonymous, can be summarized by the following:

"Free license to use the patents in RPL so long as= you and your company don't sue Cisco over any other patent for anythin= g." =A0

We are engineers, not lawyers, so to = understand legal matters, most of us need such one-liner to understand what= is the deal. Therefore in my mind, the right questions that we need to ask= ourselves at this point are:

1 - is the above an accurate summary of the IPR deal im= posed by Cisco?
2 - if no, what is an accurate summary=A0of the I= PR deal imposed by Cisco?
3 - if yes, are we OK with these terms?=

Let's clarify this and move on quickly, back to pro= tocol design where we belong!

Regards,
<= br>
Emmanuel




On Mon, Feb 1, 2010 at 5:46 PM, Pete St= . Pierre <Pet= e.Stpierre@sun.com> wrote:
Hi JP -
I think it would be easier = to answer this question if we knew =A0exactly which portions of the work we= re encumbered.

If Pascal could summarize the impli= cations of Cisco's IP on the current draft, I'm sure we'd all h= ave a better understanding and could then move this along with confidence.<= /div>

Regards,
...Pete

=A0=A0
On Feb 1,= 2010, at 5:57 AM, JP Vasseur wrote:

Dear = all,

Given the discussions about the IPR disclosure at <= a href=3D"https://datatracker.ietf.org/ipr/1246/" target=3D"_blank">https:/= /datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at=A0http://www.ie= tf.org/ipr/policy.html=A0I would like to make sure that the working gro= up is happy to proceed with draft-ietf-roll-rpl in its current form. Please= state your opinions on the list. I will make a consensus call on Friday 11= February.

Thanks.

JP.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://= www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--00148530b918656063047e8d6bf5-- From rstruik@certicom.com Mon Feb 1 10:11:47 2010 Return-Path: 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 135D83A67E3 for ; Mon, 1 Feb 2010 10:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yge3WF66xJdM for ; Mon, 1 Feb 2010 10:11:43 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 415A03A659B for ; Mon, 1 Feb 2010 10:11:42 -0800 (PST) X-AuditID: 0a401fcb-b7b37ae000001770-28-4b671980c20c Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 41.EE.06000.089176B4; Mon, 1 Feb 2010 13:12:16 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 13:12:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Feb 2010 13:11:40 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC403ABC9B7@XCH57YKF.rim.net> In-Reply-To: <4B66EDE1.4010501@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] sequence number increment and wrap Thread-Index: AcqjUBrI/B605hr+QEqsr0dUq1v+NQAF7qcQ References: <6986.1264989792@marajade.sandelman.ca> <4B66EDE1.4010501@ekasystems.com> From: "Rene Struik" To: "Michael Richardson" X-OriginalArrivalTime: 01 Feb 2010 18:12:15.0715 (UTC) FILETIME=[1590C330:01CAA36A] X-Brightmail-Tracker: AAAAAA== Cc: IETF ROLL Subject: Re: [Roll] sequence number increment and wrap X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 18:11:47 -0000 Dear Michael: For a summary of security considerations, please also cf. the slides of my presentation at the IETF-76 meeting, Hiroshima, Japan, November 9-13, 2010. The requirement for replay protection and timeliness is captured on Slide 4; structure of keying material on Slide 7. Here, timeliness would imply that one can detect stale frames (e.g., those that have been captured somewhere else in the network and are propagated elsewhere with a large delay). One cautionary note on references to 802.15.4: this term is really ambiguous, since 802.15.4-2006 totally rewrote the "security" provisions of 802.15.4-2003 (to which the 2004 paper by David Wagner and Naveen Sestry that Tzeta Tsao referenced below refers to). Ironically, IETF still overwhelmingly uses 802.15.4-2003. For a summary of changes to 802.15.4 currently underway, cf. the slides of my presentation at the IETF-75 meeting, Stockholm, Sweden, July 27-31, 2009. The suggestion to move away from 802.15.4-2003 (which has been deprecated since 2006 anyway) is captured on Slide 15 of the consolidated slide deck. Best regards, Rene Rene Struik, Update on IEEE 802.15.4e, IETF-75, Stockholm, Sweden, July 27-31, 2009 http://www.ietf.org/proceedings/75/slides/6lowpan-0.pdf=20 Rene Struik, Reflections on Security Architectural Framework RoLL, IETF-76, Hiroshima, Japan, November 9-13, 2009 http://www.ietf.org/proceedings/76/slides/roll-0/roll-0_files/frame.htm -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tzeta Tsao Sent: Monday, February 01, 2010 10:06 AM To: Michael Richardson Cc: IETF ROLL Subject: Re: [Roll] sequence number increment and wrap Indeed, replay protection can be a deceptively simple problem. For=20 example, here is a security analysis on 802.15.4 and it has a lot to say about 15.4's Access Control List, which is based on a counter:=20 http://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf. Maintaining a counter for every neighbor may present a problem for some=20 devices. Suppose one uses MiniSec's approach:=20 http://sparrow.ece.cmu.edu/group/pub/luk_mezzour_perrig_miniSec.pdf. In=20 this case, a device sends one-byte counter in the message for sync but=20 actually keeps a multi-byte counter per neighbor: in many situations it=20 will wind up needing a few k bytes. Some networks/devices have time, so using timestamp for anti-replay is=20 another option. Of course, a complete design will need to address issues such as re-sync of states due to power outages, etc.; the question is=20 then if it is possible for us to put requirements on the rest of the system. Tzeta Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Are there any security implications in the sequence number? >=20 > (I realize that the security architecture is not complete.=20 > I assume that there will be some kind of per-message authenticator (MAC) > How this is keyed is really the hard part of the architectured) >=20 > Typically, there is some concern if there is a replay of a lower > sequence number. Such an event causes the network to return to some > earlier state. The concern is that an attacker can record a previously > authenticated set of messages and then play them back, intentionally > causing such a time travel. =20 >=20 > One question is: is this a threat? >=20 > The usual defense against that is that the sequence number must be > monotonically increasing. If a nodes has been out of communication for > a period of time, it may see a abrupt jump in sequence number, but > that's okay --- if the authentication checks out, it advances. >=20 > The problem is that we have an 8-bit field, and it isn't clear how much > it may advance --- advances of 254 for instance, look like going > backwards 1, and may be disallowed. >=20 > The text in -05 is: >=20 > Sequence Number: 8-bit unsigned integer set by the DODAG root, > incremented according to a policy provisioned at the DODAG > root, and propagated with no change down the DODAG. Each > increment SHOULD have a value of 1 and may cause a wrap back to > zero. >=20 >=20 > It is good that the text tells what the DODAG should do, but we need to > know what happens if there is an increment of more than 1, and how to > know when there is an increment of more than 1, when it is a wrap. >=20 > My first suggestion is that increments of up to 127 should be acceptable, as > can unambiguously be understood to be increments (with possible > wraps). Further, any increment which does not cause a wrap can be > accepted as well. >=20 > What I think would decide this is to understand under what conditions > the sequence number can and should be incremented?=20 >=20 > - From my understanding, it's a DAG Iteration, and I think that this will > happen somewhat often --- not as often as once a second, but certainly > more often than once an hour. =20 >=20 > It is also my understanding that many DIO messages will be sent with the > same sequence number --- it is not incremented each time the DIO is > sent. >=20 > I therefore suggest renaming this field to "DIO Iteration Number". >=20 > - --=20 > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition.=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys >=20 > iQEVAwUBS2Y2XoCLcPvd0N1lAQL0BwgAvyVovfNupQL7MjNOB/KDM3UaJJS0vVli > yzKliEF7CvhrT8nxowLKK40XCyDp5vUNIzVMZrZOSknXcfyJdlWgFEVS7E4lcTz6 > mSJJ4pyIAmSiUlBTka5p8YJqtzSDBRsEA4Egz0fRXJyhN2kdbw3kLOcTId6WeB0o > +MJMnl1DjFryahQP8cuqwBy6nTgshqmPFsMUPFnf4jvUIZsK6L3Ucmp8SjUUndMI > i8f4JWAsq/3/hMqfaAZYTAqmzlXBscLWh+lpzd5OOvfGS8vCf8/CZr3ewrvkDo7f > 9iAqcw8DiSqNAmPUu6UT+Bf/MledzDflFCOlKSl5l0v28Y6bE3FccA=3D=3D > =3D6mQT > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Feb 1 10:16:18 2010 Return-Path: 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 081EC3A67D1 for ; Mon, 1 Feb 2010 10:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FgzFNeN5QjCD for ; Mon, 1 Feb 2010 10:16:17 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 3AC633A659B for ; Mon, 1 Feb 2010 10:16:17 -0800 (PST) Received: from dnab42225d.stanford.edu ([171.66.34.93]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nc0pQ-0005Xh-8x; Mon, 01 Feb 2010 10:16:52 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 1 Feb 2010 10:16:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 18:16:18 -0000 On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: > Hi JP, >=20 > as discussed, IPR may indeed be difficult to avoid entirely, even = without looming deadlines... If I recall correctly, we are discussing = this because someone claimed that Cisco forces an IPR deal which, = quoting this now famous anonymous, can be summarized by the following: >=20 > "Free license to use the patents in RPL so long as you and your = company don't sue Cisco over any other patent for anything." =20 >=20 > We are engineers, not lawyers, so to understand legal matters, most of = us need such one-liner to understand what is the deal. Therefore in my = mind, the right questions that we need to ask ourselves at this point = are: >=20 > 1 - is the above an accurate summary of the IPR deal imposed by Cisco? > 2 - if no, what is an accurate summary of the IPR deal imposed by = Cisco? > 3 - if yes, are we OK with these terms? >=20 > Let's clarify this and move on quickly, back to protocol design where = we belong! Agreed -- part of the issue here is that I think it's not really = possible for Pascal to describe exactly what the patents cover: he's not = a patent lawyer, and I doubt that Cisco would like him to speak for them = in this regard. My brief interactions with patent law have taught me = that it often works quite differently than engineers might expect. So we = should be careful assuming that we can easily understand the full = situation. :) Phil From alexandru.petrescu@gmail.com Mon Feb 1 13:17:26 2010 Return-Path: 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 1BC703A699A for ; Mon, 1 Feb 2010 13:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 tMZ-t8M7X76x for ; Mon, 1 Feb 2010 13:17:25 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CAE5E3A6993 for ; Mon, 1 Feb 2010 13:17:23 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id D9C27D48018 for ; Mon, 1 Feb 2010 22:17:55 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id E2982D48082 for ; Mon, 1 Feb 2010 22:17:52 +0100 (CET) Message-ID: <4B6744FF.2010601@gmail.com> Date: Mon, 01 Feb 2010 22:17:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100201-0, 01/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 21:17:26 -0000 Just my two cents worth in this new thread, Le 01/02/2010 19:16, Philip Levis a écrit : > > On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: > >> Hi JP, >> >> as discussed, IPR may indeed be difficult to avoid entirely, even >> without looming deadlines... If I recall correctly, we are >> discussing this because someone claimed that Cisco forces an IPR >> deal which, quoting this now famous anonymous, can be summarized >> by the following: >> >> "Free license to use the patents in RPL so long as you and your >> company don't sue Cisco over any other patent for anything." >> >> We are engineers, not lawyers, so to understand legal matters, >> most of us need such one-liner to understand what is the deal. >> Therefore in my mind, the right questions that we need to ask >> ourselves at this point are: >> >> 1 - is the above an accurate summary of the IPR deal imposed by >> Cisco? 2 - if no, what is an accurate summary of the IPR deal >> imposed by Cisco? 3 - if yes, are we OK with these terms? >> >> Let's clarify this and move on quickly, back to protocol design >> where we belong! > > Agreed -- part of the issue here is that I think it's not really > possible for Pascal to describe exactly what the patents cover: he's > not a patent lawyer, YEs, I mostly agree. There's a long way between the initial idea laid down in a company-internal "disclosure", what gets filed by the patent attorney and what gets patented. However, as a technical writer of some other IPRs (not in RoLL space) I can tell that when I write technical IPR and technical IETF text I know 100% which IPR covers which IETF text. This is why I believe it is relatively easy to offer some guidance about which text in the current draft _might_ be tainted. If we really want to know, then it's easy to find out: just ask the right questions: may section x.y.z be covered? OTOH, if we don't really care then we can't blame Pascal or anybody else about absence of declarations. They already did what IETF asks them to: they disclosed. Alex and I doubt that Cisco would like him to speak > for them in this regard. My brief interactions with patent law have > taught me that it often works quite differently than engineers might > expect. So we should be careful assuming that we can easily > understand the full situation. :) > > Phil > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From Jerald.P.Martocci@jci.com Mon Feb 1 13:44:57 2010 Return-Path: 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 230E83A68C5 for ; Mon, 1 Feb 2010 13:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] 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 XSQfA2E+LKW6 for ; Mon, 1 Feb 2010 13:44:54 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id 203973A6811 for ; Mon, 1 Feb 2010 13:44:52 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKS2dLd/lKXt0ZlYHnIbN0giMM3zXa98DW@postini.com; Mon, 01 Feb 2010 13:45:28 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010020115472951-10519681 ; Mon, 1 Feb 2010 15:47:29 -0600 In-Reply-To: MIME-Version: 1.0 To: Joydeep Tripathi X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 1 Feb 2010 15:45:03 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/01/2010 03:45:10 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/01/2010 03:47:40 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/01/2010 03:47:51 PM Content-Type: multipart/mixed; boundary="=_mixed 00777AFE862576BD_=" Cc: ROLL WG Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 21:44:57 -0000 --=_mixed 00777AFE862576BD_= Content-Type: multipart/related; boundary="=_related 00777AFE862576BD_=" --=_related 00777AFE862576BD_= Content-Type: multipart/alternative; boundary="=_alternative 00777AFE862576BD_=" --=_alternative 00777AFE862576BD_= Content-Type: text/plain; charset="US-ASCII" Hi Joydeep, Attached is a spreadsheet we developed in 2005 that described the device density, packet sizes, hops and packet densities into various kinds of buildings. I think it should answer your questions. It might require a bit more explanation to make the data obvious. Don't hesitate to write or call. Regards, Jerry Joydeep Tripathi 01/31/2010 04:55 PM To "jerald.p.martocci" cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Jerry, Thanks a lot for the information you provided on simulation details, we're making excellent progress on the P2P simulation results which will be posted soon in the next revision. Could you just tell us which packet size we should be using and the average number of packets? Then we could provide with you with actual delay bound for P2P routing. Thanks, Joydeep --- On Tue, 1/26/10, Jerald.P.Martocci@jci.com wrote: From: Jerald.P.Martocci@jci.com Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home To: "JP Vasseur" Cc: "ROLL WG" , "Mukul Goyal" , roll-bounces@ietf.org Date: Tuesday, January 26, 2010, 12:20 PM Hi JP, My $.02 on your answers: 1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building. 2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes. 2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 01/26/2010 11:01 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > 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 mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -----Inline Attachment Follows----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00777AFE862576BD_= Content-Type: text/html; charset="US-ASCII"
Hi Joydeep,

Attached is a spreadsheet we developed in 2005 that described the device density, packet sizes, hops and packet densities into various kinds of buildings.  I think it should answer your questions.  It might require a bit more explanation to make the data obvious.  Don't hesitate to write or call.

Regards,

Jerry








Joydeep Tripathi <joydeep.tripathi@gmail.com>

01/31/2010 04:55 PM

To
"jerald.p.martocci" <jerald.p.martocci@jci.com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in         the home






Hi Jerry,

Thanks a lot for the information you provided on simulation details, we're making excellent progress on the P2P simulation results which will be posted soon in the next revision. Could you just tell us which packet size we should be using and the average number of packets? Then we could provide with you with actual delay bound for P2P routing. 

Thanks,
Joydeep

--- On Tue, 1/26/10, Jerald.P.Martocci@jci.com <Jerald.P.Martocci@jci.com> wrote:

From: Jerald.P.Martocci@jci.com <Jerald.P.Martocci@jci.com>
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home
To: "JP Vasseur" <jvasseur@cisco.com>
Cc: "ROLL WG" <roll@ietf.org>, "Mukul Goyal" <mukul@UWM.EDU>, roll-bounces@ietf.org
Date: Tuesday, January 26, 2010, 12:20 PM

Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes.

Regards,

Jerry




JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

01/26/2010 11:01 AM


To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation        in the home







Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the  
> need to maintain reachability information for all possible  
> destinations to which some source might send a packet some day.  
> That's why we need source-initiated route discovery, i.e. a reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 -
> > router 5
>    but router 5 has never been routing traffic to lamp module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that  
> it should be reactive.
> What you describe is routing protocol convergence, which of course  
> does not imply that the
> protocol should be reactive. This is a typical case where the  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep  
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a reactive  
> mechanism instead of
> proactive, this is not a magic solution either since you flood your  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router  
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the  
> ability to
> operate in a reactive fasion is critical to home & building and that  
> the DAG update
> signaling currently designed will have much bigger delays than the  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so  
> that over time
> DAG routes will reconstructed, but that the current spec cannot find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route  
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still  
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump  
> between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P  in home and  
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On  
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3  
> years.  He has a good handle on the commercial building performance  
> requirements.  It would be good for you to run those he notes  
> below.  It might be advantageous then for you two to share the  
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s)  
> need to traverse the DAG all the way up to the LBR and back down to  
> the destination node.  Of course, this is now a function on DAG  
> depth.  Also since all our messages require ACK, the additional  
> latency of the ACK having to return possibly through a different set  
> of nodes yet via the LBR.  That would be the worst case scenario.  
> If other nodes could short circuit the packets through a shorter  
> path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning  
> on lights, etc) latency is a big issue.  Moving the packet up and  
> down the DAG is reasonably deterministic and should be primarily a  
> function of the DAG depth.  However, what will really affect the  
> system performance is 'DAG Repair'.  I have no sense how long a  
> packet in transit would have to wait if the DAG was under repair.  
> Since we require ACKs of every message, the source node would time-
> out and retry a few times (usually 3).  After that, the source node  
> would have to fall into some 'failsoft' mode depending on the type  
> of data it was trying to access.  This is not a good situation.  The  
> source node can only assume that its data is inaccessible, not just  
> held up in transit.  The fail-soft mode will have large hysteresis  
> since it can't be constantly dithering between modes.  This will all  
> be logged to the operator which is a bad thing!!!  That was what was  
> nice about an AODV concept, because even route repair was fairly  
> deterministic.
>
> So... if your simulation could measure packet latency as a function  
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM                  
> To                  Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc                  ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com
>  >
>
> Subject                  Re: [Roll] RPL Simulation
>                  
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a  
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through  
> the DAG from a source to a destination passes through their closest  
> common ancestor) and DAG routes through root (all DAG paths have to  
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over  
> the DAG versus the length/cost of ideal routes) for given number of  
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the  
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop  
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from  
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic  
> loads as well as packet loss/delay along the DAG links. Compare  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada  
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic
> are to a 2 -hop distance destination, and observe the performance of
> RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> 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 mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

-----Inline Attachment Follows-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll



--=_alternative 00777AFE862576BD_=-- --=_related 00777AFE862576BD_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0EA567D40EA560F000777AFE862576BD> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 00777AFE862576BD_=-- --=_mixed 00777AFE862576BD_= Content-Type: application/vnd.ms-excel; name="Commercial Bldg Device Modeling.xls" Content-Disposition: attachment; filename="Commercial Bldg Device Modeling.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAXgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////YQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAAD+/////v///2AAAAD+/////v////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIDWdLCHo8oB XwAAAAADAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAbbcAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAADAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAFgBAAAAAAAACQgQ AAAGBQCqH80HwQABAAYEAADhAAIAsATBAAIAAADiAAAAXABwABEAAEplcmFsZCBQIE1hcnRvY2Np ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCAAIAsARhAQIAAADAAQAAPQEIAAEA AgADAAQAnAACABAAGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAOABSwBMO3gtOAAA AAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAGgDIAAAA/3+QAQAA AAAAAAUBQQByAGkAYQBsADEAHgDcAAAACACQAQAAAAIAcgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAA AAgAkAEAAAACAHIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAIAJABAAAAAgByBwFDAGEAbABpAGIA cgBpADEAGgCgAAAA/3+QAQAAAAAAcgUBQQByAGkAYQBsADEAHACgAAAAUQCQAQAAAAAAcgYBVABh AGgAbwBtAGEAMQAcAKAAAABRAJABAAAAAgByBgFUAGEAaABvAG0AYQAxABoAoAABACsAvAIAAAAC AHIFAUEAcgBpAGEAbAAxABoAoAAAAP9/kAEAAAACAHIFAUEAcgBpAGEAbAAxABoAyAAAACsAkAEA AAAAAHIFAUEAcgBpAGEAbAAxABoAoAABAAwAvAIAAAACAHIFAUEAcgBpAGEAbAAxABoAoAAAAAsA kAEAAAACAHIFAUEAcgBpAGEAbAAxABwAoAABAFEAvAIAAAAAAHIGAVQAYQBoAG8AbQBhADEAGgDI AAAA/3+QAQAAAAAAcgUBQQByAGkAYQBsADEAHgBoAQEAOAC8AgAAAAIAcgcBQwBhAG0AYgByAGkA YQAxAB4ALAEBADgAvAIAAAACAHIHAUMAYQBsAGkAYgByAGkAMQAeAAQBAQA4ALwCAAAAAgByBwFD AGEAbABpAGIAcgBpADEAHgDcAAEAOAC8AgAAAAIAcgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAABEA kAEAAAACAHIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAUAJABAAAAAgByBwFDAGEAbABpAGIAcgBp ADEAHgDcAAAAPACQAQAAAAIAcgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAAD4AkAEAAAACAHIHAUMA YQBsAGkAYgByAGkAMQAeANwAAQA/ALwCAAAAAgByBwFDAGEAbABpAGIAcgBpADEAHgDcAAEANAC8 AgAAAAIAcgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAADQAkAEAAAACAHIHAUMAYQBsAGkAYgByAGkA MQAeANwAAQAJALwCAAAAAgByBwFDAGEAbABpAGIAcgBpADEAHgDcAAAACgCQAQAAAAIAcgcBQwBh AGwAaQBiAHIAaQAxAB4A3AACABcAkAEAAAACAHIHAUMAYQBsAGkAYgByAGkAMQAeANwAAQAIALwC AAAAAgByBwFDAGEAbABpAGIAcgBpADEAHgDcAAAACQCQAQAAAAIAcgcBQwBhAGwAaQBiAHIAaQAe BBwABQAXAAAiJCIjLCMjMF8pO1woIiQiIywjIzBcKR4EIQAGABwAACIkIiMsIyMwXyk7W1JlZF1c KCIkIiMsIyMwXCkeBCIABwAdAAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwAIACIA ACIkIiMsIyMwLjAwXyk7W1JlZF1cKCIkIiMsIyMwLjAwXCkeBDcAKgAyAABfKCIkIiogIywjIzBf KTtfKCIkIiogXCgjLCMjMFwpO18oIiQiKiAiLSJfKTtfKEBfKR4ELgApACkAAF8oKiAjLCMjMF8p O18oKiBcKCMsIyMwXCk7XygqICItIl8pO18oQF8pHgQ/ACwAOgAAXygiJCIqICMsIyMwLjAwXyk7 XygiJCIqIFwoIywjIzAuMDBcKTtfKCIkIiogIi0iPz9fKTtfKEBfKR4ENgArADEAAF8oKiAjLCMj MC4wMF8pO18oKiBcKCMsIyMwLjAwXCk7XygqICItIj8/Xyk7XyhAXyngABQAAAAAAPX/IAAAAAAA AAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDg ABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/ IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAA AAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQA AAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAA AAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAAAAAPX/IAAAAAAAAAAAAAAA wCDgABQAAAAAAAEAIAAAAAAAAAAAAAAAwCDgABQAAQAAAPX/IAAAtAAAAAAAAAAEnyDgABQAAQAA APX/IAAAtAAAAAAAAAAErSDgABQAAQAAAPX/IAAAtAAAAAAAAAAEqiDgABQAAQAAAPX/IAAAtAAA AAAAAAAEriDgABQAAQAAAPX/IAAAtAAAAAAAAAAEmyDgABQAAQAAAPX/IAAAtAAAAAAAAAAEryDg ABQAAQAAAPX/IAAAtAAAAAAAAAAErCDgABQAAQAAAPX/IAAAtAAAAAAAAAAEnSDgABQAAQAAAPX/ IAAAtAAAAAAAAAAEiyDgABQAAQAAAPX/IAAAtAAAAAAAAAAEriDgABQAAQAAAPX/IAAAtAAAAAAA AAAErCDgABQAAQAAAPX/IAAAtAAAAAAAAAAEsyDgABQAHgAAAPX/IAAAtAAAAAAAAAAEniDgABQA HgAAAPX/IAAAtAAAAAAAAAAEnSDgABQAHgAAAPX/IAAAtAAAAAAAAAAEiyDgABQAHgAAAPX/IAAA tAAAAAAAAAAEpCDgABQAHgAAAPX/IAAAtAAAAAAAAAAEsSDgABQAHgAAAPX/IAAAtAAAAAAAAAAE tCDgABQAHgAAAPX/IAAAtAAAAAAAAAAEviDgABQAHgAAAPX/IAAAtAAAAAAAAAAEiiDgABQAHgAA APX/IAAAtAAAAAAAAAAEuSDgABQAHgAAAPX/IAAAtAAAAAAAAAAEpCDgABQAHgAAAPX/IAAAtAAA AAAAAAAEsSDgABQAHgAAAPX/IAAAtAAAAAAAAAAEtSDgABQAFAAAAPX/IAAAtAAAAAAAAAAErSDg ABQAGAAAAPX/IAAAlBERlwuXCwAEliDgABQAGgAAAPX/IAAAlGZmvx+/HwAEtyDgABQADgArAPX/ IAAA+AAAAAAAAAAAwCDgABQADgApAPX/IAAA+AAAAAAAAAAAwCDgABQADgAsAPX/IAAA+AAAAAAA AAAAwCDgABQADgAqAPX/IAAA+AAAAAAAAAAAwCDgABQAHAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA EwAAAPX/IAAAtAAAAAAAAAAEqiDgABQAEAAAAPX/IAAA1ABQAAAAHwAAwCDgABQAEQAAAPX/IAAA 1ABQAAAACwAAwCDgABQAEgAAAPX/IAAA1AAgAAAADwAAwCDgABQAEgAAAPX/IAAA9AAAAAAAAAAA wCDgABQAFgAAAPX/IAAAlBERlwuXCwAEryDgABQAGQAAAPX/IAAA1ABgAAAAGgAAwCDgABQAFQAA APX/IAAAtAAAAAAAAAAEqyDgABQADgAAAPX/IAAAnBERFgsWCwAEmiDgABQAFwAAAPX/IAAAlBER vx+/HwAEliDgABQADgAJAPX/IAAA+AAAAAAAAAAAwCDgABQADwAAAPX/IAAA9AAAAAAAAAAAwCDg ABQAHQAAAPX/IAAA1ABhAAA+HwAAwCDgABQAGwAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAAEA GAAAEAAAAAAAAAAAwCDgABQAAAAAAAEAGgAAEAAAAAAAAAAAwCDgABQACQAAAAEAGgAAGAAAAAAA AAAAwCDgABQACQAAAAEAIgAAGAAAAAAAAAAAwCDgABQACQAAAAEAGgAAOBERQCBAIBAAwCDgABQA CQAAAAEAGgAAOCERQCBAIBAAwCDgABQACQAAAAEAGgAAOBEhQCBAIBAAwCDgABQACgAAAAEAGgAA eAASQCBAIBAEDCDgABQACQAAAAEAGgAAOBEQQCBAIBAAwCDgABQACQAAAAEAGgAAOCEQQCBAIBAA wCDgABQACAAAAAEAGgAAeBFhQCBAIBAEDCDgABQACAAAAAEAGgAAeCFhQCBAIBAEDCDgABQACwAA AAEAEgAAeBIQQCBAIBAAwCDgABQACwAAAAEAEgAAeBIRQCBAIBAAwCDgABQACwAAAAEAEgAAeBIh QCBAIBAAwCDgABQACAAAAAEAGgAAeBFgQCBAIBAEDCDgABQACQAAAAEAGgAAOAEQQCBAIBAAwCDg ABQACQADAAEAGgAAPBERQCBAIBAAwCDgABQACQAAAAkAGgAAOCERQCBAIBAAwCDgABQACQAAAAkA GgAAOBERQCBAIBAAwCDgABQACQAAAAEAGgAAeBEAQCBAIBAAwCDgABQACAAAAAEAGgAAeAFhQCBA IBAEDCDgABQACQAAAAEAGgAAOBEgQCBAIBAAwCDgABQACQAAAAkAGgAAOBEhQCBAIBAAwCDgABQA CQAAAAkAGgAAOCEhQCBAIBAAwCDgABQACQAAAAEAGgAAeAAAAAAAAAAAwCDgABQAAAAAAAEAIgAA EAAAAAAAAAAAwCDgABQACQAAAAEAGgAAOAERQCBAIBAAwCDgABQACQAAAAkAGgAAOAERQCBAIBAA wCDgABQACgAAAAEAGgAAeCISQCBAIBAEDCDgABQACAAAAAEAGgAAeCIRQCBAIBAEDCDgABQACAAA AAEAGgAAeCJhQCBAIBAEDCDgABQACQAAAAEAGgAAOCIQQCBAIBAAwCDgABQACQAAAAEAGgAAOCIg QCBAIBAAwCDgABQACQABAAEAGgAAPBEQQCBAIBAAwCDgABQACQABAAEAGgAAPBERQCBAIBAAwCDg ABQACQABAAEAGgAAPBEhQCBAIBAAwCDgABQACQAAAAEAGgAAeBEQQCBAIBAAwCDgABQACQAAAAkA GgAAeBERQCBAIBAAwCDgABQACQAAAAEAGgAAeBERQCBAIBAAwCDgABQACQAAAAEAGgAAeBEhQCBA IBAAwCDgABQACAAAAAEAGgAAeBJhQCBAIBAEDCDgABQACQAAAAEAGgAAOBIQQCBAIBAAwCDgABQA CQAAAAEAGgAAOBIgQCBAIBAAwCDgABQACQAAAAEAGAAAGAAAAAAAAAAAwCDgABQABQAAAAEAGAAA GAAAAAAAAAAAwCDgABQABQAAAAEAGgAAGAAAAAAAAAAAwCDgABQACQAAAAkAGgAAOBEQQCBAIBAA wCDgABQACQAAAAEAGQAAOBIRQCBAIBAAwCDgABQACQAAAAEAGQAAOBERQCBAIBAAwCDgABQACQAA AAEAGQAAOCERQCBAIBAAwCDgABQACQAAAAEAGQAAOBIhQCBAIBAAwCDgABQACQAAAAEAGQAAOBEh QCBAIBAAwCDgABQACQAAAAEAGQAAOCEhQCBAIBAAwCDgABQACAAAAAEAGgAAeBISQCBAIBAEDCDg ABQACAAAAAEAGgAAeBESQCBAIBAEDCDgABQACAAAAAEAGgAAeCESQCBAIBAEDCDgABQACAAAAAEA GgAAeBECQCBAIBAEDCDgABQACAAAAAEAGgAAeBEAQCBAIBAEDCDgABQACAAAAAEAGgAAeBFgQCBA IBAEDCDgABQACAAAAAEAGgAAeBICQCBAIBAEDCDgABQACAAAAAEAGgAAeBIAQCBAIBAEDCDgABQA CAAAAAEAGgAAeBJgQCBAIBAEDCDgABQACgAAAAEAGgAAeAASQCBAIBAEDCDgABQACgAAAAEAGgAA eCASQCBAIBAEDCDgABQACAAAAAEAGgAAeAERQCBAIBAEDCDgABQACAAAAAEAGgAAeBARQCBAIBAE DCDgABQACgAAAAEAGgAAeAESQCBAIBAEDCDgABQACgAAAAEAGgAAeBASQCBAIBAEDCDgABQACAAA AAEAGgAAeBEBQCBAIBAEDCDgABQACAAAAAEAGgAAeCARQCBAIBAEDCDgABQACgAAAAEAGgAAeAIS QCBAIBAEDCDgABQACAAAAAEAGgAAeAIRQCBAIBAEDCDgABQACAAAAAEAGgAAeAARQCBAIBAEDCB8 CBQAfAgAAAAAAAAAAAAAAACIAA6mHO19CC0AfQgAAAAAAAAAAAAAAAA7AAAAAgANABQAAwAAAAMA AAAwMFwpO18oKg4ABQABfQhBAH0IAAAAAAAAAAAAAAAAMQAAAAMADQAUAAMAAAADAAAAMDBcKTtf KCoOAAUAAggAFAADAAAABAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAMgAAAAMADQAUAAMA AAADAAAAMDBcKTtfKCoOAAUAAggAFAADAP8/BAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAA MwAAAAMADQAUAAMAAAADAAAAMDBcKTtfKCoOAAUAAggAFAADADIzBAAAADtfKEBfKSAgfQgtAH0I AAAAAAAAAAAAAAAANAAAAAIADQAUAAMAAAADAAAAMDBcKTtfKCoOAAUAAn0IQQB9CAAAAAAAAAAA AAAAADAAAAADAA0AFAACAAAAAGEA/zAwXCk7XygqDgAFAAIEABQAAgAAAMbvzv87XyhAXykgIH0I QQB9CAAAAAAAAAAAAAAAACgAAAADAA0AFAACAAAAnAAG/zAwXCk7XygqDgAFAAIEABQAAgAAAP/H zv87XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAADcAAAADAA0AFAACAAAAnGUA/zAwXCk7XygqDgAF AAIEABQAAgAAAP/rnP87XyhAXykgIH0IkQB9CAAAAAAAAAAAAAAAADUAAAAHAA0AFAACAAAAPz92 /zAwXCk7XygqDgAFAAIEABQAAgAAAP/Mmf87XyhAXykgIAcAFAACAAAAf39//yAgICAgICAgCAAU AAIAAAB/f3//ICAgICAgICAJABQAAgAAAH9/f/8AAAAAAAAAAAoAFAACAAAAf39//wAAAAAAAAAA fQiRAH0IAAAAAAAAAAAAAAAAOQAAAAcADQAUAAIAAAA/Pz//MDBcKTtfKCoOAAUAAgQAFAACAAAA 8vLy/ztfKEBfKSAgBwAUAAIAAAA/Pz//ICAgICAgICAIABQAAgAAAD8/P/8gICAgICAgIAkAFAAC AAAAPz8//wAAAAAAAAAACgAUAAIAAAA/Pz//AAAAAAAAAAB9CJEAfQgAAAAAAAAAAAAAAAApAAAA BwANABQAAgAAAPp9AP8wMFwpO18oKg4ABQACBAAUAAIAAADy8vL/O18oQF8pICAHABQAAgAAAH9/ f/8gICAgICAgIAgAFAACAAAAf39//yAgICAgICAgCQAUAAIAAAB/f3//AAAAAAAAAAAKABQAAgAA AH9/f/8AAAAAAAAAAH0IQQB9CAAAAAAAAAAAAAAAADYAAAADAA0AFAACAAAA+n0A/zAwXCk7Xygq DgAFAAIIABQAAgAAAP+AAf87XyhAXykgIH0IkQB9CAAAAAAAAAAAAAAAACoAAAAHAA0AFAADAAAA AAAAADAwXCk7XygqDgAFAAIEABQAAgAAAKWlpf87XyhAXykgIAcAFAACAAAAPz8//yAgICAgICAg CAAUAAIAAAA/Pz//ICAgICAgICAJABQAAgAAAD8/P/8AAAAAAAAAAAoAFAACAAAAPz8//wAAAAAA AAAAfQgtAH0IAAAAAAAAAAAAAAAAPQAAAAIADQAUAAIAAAD/AAD/MDBcKTtfKCoOAAUAAn0IeAB9 CAAAAAAAAAAAAAAAADgAAAAFAAQAFAACAAAA///M/zAwXCk7XygqBwAUAAIAAACysrL/AKWlpf87 XygIABQAAgAAALKysv8APz8//yAgIAkAFAACAAAAsrKy/wA/Pz//ICAgCgAUAAIAAACysrL/AD8/ P/8AAAB9CC0AfQgAAAAAAAAAAAAAAAAvAAAAAgANABQAAgAAAH9/f/8wMFwpO18oKg4ABQACfQhV AH0IAAAAAAAAAAAAAAAAPAAAAAQADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgcAFAADAAAABAAA ADtfKAgAFAACCAAUAAMAAAAEAAAAICAgCQAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAiAAAAAwANABQA AwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAAAAEAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAA AAAQAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAZWYEAAAAO18oCAAUAAJ9CEEA fQgAAAAAAAAAAAAAAAAWAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAzEwEAAAA O18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAcAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQAC BAAUAAMAMjMEAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAjAAAAAwANABQAAwAAAAAAAAAw MFwpO18oKg4ABQACBAAUAAMAAAAFAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAARAAAAAwAN ABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAZWYFAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAA AAAAAAAXAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAzEwFAAAAO18oCAAUAAJ9 CEEAfQgAAAAAAAAAAAAAAAAdAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAMjMF AAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAkAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4A BQACBAAUAAMAAAAGAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAASAAAAAwANABQAAwAAAAEA AAAwMFwpO18oKg4ABQACBAAUAAMAZWYGAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAYAAAA AwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAzEwGAAAAO18oCAAUAAJ9CEEAfQgAAAAA AAAAAAAAAAAeAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAMjMGAAAAO18oCAAU AAJ9CEEAfQgAAAAAAAAAAAAAAAAlAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMA AAAHAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAATAAAAAwANABQAAwAAAAEAAAAwMFwpO18o Kg4ABQACBAAUAAMAZWYHAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAZAAAAAwANABQAAwAA AAEAAAAwMFwpO18oKg4ABQACBAAUAAMAzEwHAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAf AAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAMjMHAAAAO18oCAAUAAJ9CEEAfQgA AAAAAAAAAAAAAAAmAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAAAAIAAAAO18o CAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAUAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAU AAMAZWYIAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAaAAAAAwANABQAAwAAAAEAAAAwMFwp O18oKg4ABQACBAAUAAMAzEwIAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAgAAAAAwANABQA AwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAMjMIAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAA AAAnAAAAAwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAMAAAAJAAAAO18oCAAUAAJ9CEEA fQgAAAAAAAAAAAAAAAAVAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBAAUAAMAZWYJAAAA O18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAbAAAAAwANABQAAwAAAAEAAAAwMFwpO18oKg4ABQAC BAAUAAMAzEwJAAAAO18oCAAUAAJ9CEEAfQgAAAAAAAAAAAAAAAAhAAAAAwANABQAAwAAAAAAAAAw MFwpO18oKg4ABQACBAAUAAMAMjMJAAAAO18oCAAUAAKTAhIAEAANAAAyMCUgLSBBY2NlbnQxkghN AJIIAAAAAAAAAAAAAAEEHv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADEAAAADAAEADAAHBGVm 2+Xx/wUADAAHAQAAAAAA/yUABQACkwISABEADQAAMjAlIC0gQWNjZW50MpIITQCSCAAAAAAAAAAA AAABBCL/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAAyAAAAAwABAAwABwVlZvLd3P8FAAwABwEA AAAAAP8lAAUAApMCEgASAA0AADIwJSAtIEFjY2VudDOSCE0AkggAAAAAAAAAAAAAAQQm/w0AMgAw ACUAIAAtACAAQQBjAGMAZQBuAHQAMwAAAAMAAQAMAAcGZWbq8d3/BQAMAAcBAAAAAAD/JQAFAAKT AhIAEwANAAAyMCUgLSBBY2NlbnQ0kghNAJIIAAAAAAAAAAAAAAEEKv8NADIAMAAlACAALQAgAEEA YwBjAGUAbgB0ADQAAAADAAEADAAHB2Vm5eDs/wUADAAHAQAAAAAA/yUABQACkwISABQADQAAMjAl IC0gQWNjZW50NZIITQCSCAAAAAAAAAAAAAABBC7/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAA1 AAAAAwABAAwABwhlZtvu8/8FAAwABwEAAAAAAP8lAAUAApMCEgAVAA0AADIwJSAtIEFjY2VudDaS CE0AkggAAAAAAAAAAAAAAQQy/w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJ ZWb96dn/BQAMAAcBAAAAAAD/JQAFAAKTAhIAFgANAAA0MCUgLSBBY2NlbnQxkghNAJIIAAAAAAAA AAAAAAEEH/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0ADEAAAADAAEADAAHBMxMuMzk/wUADAAH AQAAAAAA/yUABQACkwISABcADQAANDAlIC0gQWNjZW50MpIITQCSCAAAAAAAAAAAAAABBCP/DQA0 ADAAJQAgAC0AIABBAGMAYwBlAG4AdAAyAAAAAwABAAwABwXMTOa5uP8FAAwABwEAAAAAAP8lAAUA ApMCEgAYAA0AADQwJSAtIEFjY2VudDOSCE0AkggAAAAAAAAAAAAAAQQn/w0ANAAwACUAIAAtACAA QQBjAGMAZQBuAHQAMwAAAAMAAQAMAAcGzEzX5Lz/BQAMAAcBAAAAAAD/JQAFAAKTAhIAGQANAAA0 MCUgLSBBY2NlbnQ0kghNAJIIAAAAAAAAAAAAAAEEK/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0 ADQAAAADAAEADAAHB8xMzMDa/wUADAAHAQAAAAAA/yUABQACkwISABoADQAANDAlIC0gQWNjZW50 NZIITQCSCAAAAAAAAAAAAAABBC//DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA1AAAAAwABAAwA BwjMTLbd6P8FAAwABwEAAAAAAP8lAAUAApMCEgAbAA0AADQwJSAtIEFjY2VudDaSCE0AkggAAAAA AAAAAAAAAQQz/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJzEz81bT/BQAM AAcBAAAAAAD/JQAFAAKTAhIAHAANAAA2MCUgLSBBY2NlbnQxkghNAJIIAAAAAAAAAAAAAAEEIP8N ADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADEAAAADAAEADAAHBDIzlbPX/wUADAAHAAAA/////yUA BQACkwISAB0ADQAANjAlIC0gQWNjZW50MpIITQCSCAAAAAAAAAAAAAABBCT/DQA2ADAAJQAgAC0A IABBAGMAYwBlAG4AdAAyAAAAAwABAAwABwUyM9mXlf8FAAwABwAAAP////8lAAUAApMCEgAeAA0A ADYwJSAtIEFjY2VudDOSCE0AkggAAAAAAAAAAAAAAQQo/w0ANgAwACUAIAAtACAAQQBjAGMAZQBu AHQAMwAAAAMAAQAMAAcGMjPC1pr/BQAMAAcAAAD/////JQAFAAKTAhIAHwANAAA2MCUgLSBBY2Nl bnQ0kghNAJIIAAAAAAAAAAAAAAEELP8NADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADQAAAADAAEA DAAHBzIzsqHH/wUADAAHAAAA/////yUABQACkwISACAADQAANjAlIC0gQWNjZW50NZIITQCSCAAA AAAAAAAAAAABBDD/DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA1AAAAAwABAAwABwgyM5PN3f8F AAwABwAAAP////8lAAUAApMCEgAhAA0AADYwJSAtIEFjY2VudDaSCE0AkggAAAAAAAAAAAAAAQQ0 /w0ANgAwACUAIAAtACAAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJMjP6wJD/BQAMAAcAAAD///// JQAFAAKTAgwAIgAHAABBY2NlbnQxkghBAJIIAAAAAAAAAAAAAAEEHf8HAEEAYwBjAGUAbgB0ADEA AAADAAEADAAHBAAAT4G9/wUADAAHAAAA/////yUABQACkwIMACMABwAAQWNjZW50MpIIQQCSCAAA AAAAAAAAAAABBCH/BwBBAGMAYwBlAG4AdAAyAAAAAwABAAwABwUAAMBQTf8FAAwABwAAAP////8l AAUAApMCDAAkAAcAAEFjY2VudDOSCEEAkggAAAAAAAAAAAAAAQQl/wcAQQBjAGMAZQBuAHQAMwAA AAMAAQAMAAcGAACbu1n/BQAMAAcAAAD/////JQAFAAKTAgwAJQAHAABBY2NlbnQ0kghBAJIIAAAA AAAAAAAAAAEEKf8HAEEAYwBjAGUAbgB0ADQAAAADAAEADAAHBwAAgGSi/wUADAAHAAAA/////yUA BQACkwIMACYABwAAQWNjZW50NZIIQQCSCAAAAAAAAAAAAAABBC3/BwBBAGMAYwBlAG4AdAA1AAAA AwABAAwABwgAAEusxv8FAAwABwAAAP////8lAAUAApMCDAAnAAcAAEFjY2VudDaSCEEAkggAAAAA AAAAAAAAAQQx/wcAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJAAD3lkb/BQAMAAcAAAD/////JQAF AAKTAggAKAADAABCYWSSCDkAkggAAAAAAAAAAAAAAQEb/wMAQgBhAGQAAAADAAEADAAF/wAA/8fO /wUADAAF/wAAnAAG/yUABQACkwIQACkACwAAQ2FsY3VsYXRpb26SCIEAkggAAAAAAAAAAAAAAQIW /wsAQwBhAGwAYwB1AGwAYQB0AGkAbwBuAAAABwABAAwABf8AAPLy8v8FAAwABf8AAPp9AP8lAAUA AgYADgAF/wAAf39//wEABwAOAAX/AAB/f3//AQAIAA4ABf8AAH9/f/8BAAkADgAF/wAAf39//wEA kwIPACoACgAAQ2hlY2sgQ2VsbJIIfwCSCAAAAAAAAAAAAAABAhf/CgBDAGgAZQBjAGsAIABDAGUA bABsAAAABwABAAwABf8AAKWlpf8FAAwABwAAAP////8lAAUAAgYADgAF/wAAPz8//wYABwAOAAX/ AAA/Pz//BgAIAA4ABf8AAD8/P/8GAAkADgAF/wAAPz8//wYAkwIEACuAA/+SCCAAkggAAAAAAAAA AAAAAQUD/wUAQwBvAG0AbQBhAAAAAACTAgQALIAG/5IIKACSCAAAAAAAAAAAAAABBQb/CQBDAG8A bQBtAGEAIABbADAAXQAAAAAAkwIEAC2ABP+SCCYAkggAAAAAAAAAAAAAAQUE/wgAQwB1AHIAcgBl AG4AYwB5AAAAAACTAgQALoAH/5IILgCSCAAAAAAAAAAAAAABBQf/DABDAHUAcgByAGUAbgBjAHkA IABbADAAXQAAAAAAkwIVAC8AEAAARXhwbGFuYXRvcnkgVGV4dJIIRwCSCAAAAAAAAAAAAAABAjX/ EABFAHgAcABsAGEAbgBhAHQAbwByAHkAIABUAGUAeAB0AAAAAgAFAAwABf8AAH9/f/8lAAUAApMC CQAwAAQAAEdvb2SSCDsAkggAAAAAAAAAAAAAAQEa/wQARwBvAG8AZAAAAAMAAQAMAAX/AADG787/ BQAMAAX/AAAAYQD/JQAFAAKTAg4AMQAJAABIZWFkaW5nIDGSCEcAkggAAAAAAAAAAAAAAQMQ/wkA SABlAGEAZABpAG4AZwAgADEAAAADAAUADAAHAwAAH0l9/yUABQACBwAOAAcEAABPgb3/BQCTAg4A MgAJAABIZWFkaW5nIDKSCEcAkggAAAAAAAAAAAAAAQMR/wkASABlAGEAZABpAG4AZwAgADIAAAAD AAUADAAHAwAAH0l9/yUABQACBwAOAAcE/z+owN7/BQCTAg4AMwAJAABIZWFkaW5nIDOSCEcAkggA AAAAAAAAAAAAAQMS/wkASABlAGEAZABpAG4AZwAgADMAAAADAAUADAAHAwAAH0l9/yUABQACBwAO AAcEMjOVs9f/AgCTAg4ANAAJAABIZWFkaW5nIDSSCDkAkggAAAAAAAAAAAAAAQMT/wkASABlAGEA ZABpAG4AZwAgADQAAAACAAUADAAHAwAAH0l9/yUABQACkwIKADUABQAASW5wdXSSCHUAkggAAAAA AAAAAAAAAQIU/wUASQBuAHAAdQB0AAAABwABAAwABf8AAP/Mmf8FAAwABf8AAD8/dv8lAAUAAgYA DgAF/wAAf39//wEABwAOAAX/AAB/f3//AQAIAA4ABf8AAH9/f/8BAAkADgAF/wAAf39//wEAkwIQ ADYACwAATGlua2VkIENlbGySCEsAkggAAAAAAAAAAAAAAQIY/wsATABpAG4AawBlAGQAIABDAGUA bABsAAAAAwAFAAwABf8AAPp9AP8lAAUAAgcADgAF/wAA/4AB/wYAkwIMADcABwAATmV1dHJhbJII QQCSCAAAAAAAAAAAAAABARz/BwBOAGUAdQB0AHIAYQBsAAAAAwABAAwABf8AAP/rnP8FAAwABf8A AJxlAP8lAAUAApMCBAAAgAD/kggiAJIIAAAAAAAAAAAAAAEBAP8GAE4AbwByAG0AYQBsAAAAAACT AgkAOAAEAABOb3RlkghiAJIIAAAAAAAAAAAAAAECCv8EAE4AbwB0AGUAAAAFAAEADAAF/wAA///M /wYADgAF/wAAsrKy/wEABwAOAAX/AACysrL/AQAIAA4ABf8AALKysv8BAAkADgAF/wAAsrKy/wEA kwILADkABgAAT3V0cHV0kgh3AJIIAAAAAAAAAAAAAAECFf8GAE8AdQB0AHAAdQB0AAAABwABAAwA Bf8AAPLy8v8FAAwABf8AAD8/P/8lAAUAAgYADgAF/wAAPz8//wEABwAOAAX/AAA/Pz//AQAIAA4A Bf8AAD8/P/8BAAkADgAF/wAAPz8//wEAkwIEADqABf+SCCQAkggAAAAAAAAAAAAAAQUF/wcAUABl AHIAYwBlAG4AdAAAAAAAkwIKADsABQAAVGl0bGWSCDEAkggAAAAAAAAAAAAAAQMP/wUAVABpAHQA bABlAAAAAgAFAAwABwMAAB9Jff8lAAUAAZMCCgA8AAUAAFRvdGFskghNAJIIAAAAAAAAAAAAAAED Gf8FAFQAbwB0AGEAbAAAAAQABQAMAAcBAAAAAAD/JQAFAAIGAA4ABwQAAE+Bvf8BAAcADgAHBAAA T4G9/wYAkwIRAD0ADAAAV2FybmluZyBUZXh0kgg/AJIIAAAAAAAAAAAAAAECC/8MAFcAYQByAG4A aQBuAGcAIABUAGUAeAB0AAAAAgAFAAwABf8AAP8AAP8lAAUAAo4IWACOCAAAAAAAAAAAAACQAAAA EQARAFQAYQBiAGwAZQBTAHQAeQBsAGUATQBlAGQAaQB1AG0AOQBQAGkAdgBvAHQAUwB0AHkAbABl AEwAaQBnAGgAdAAxADYAYAECAAAAhQAiALs5AAAAABoAQ29tbWVyY2lhbCBSZWFsIEVzdGF0ZS1W TUGFACUAP2MAAAAAHQBDb21tZXJjaWFsIFJlYWwgRXN0YXRlLVRoZXJtb4UAEwC9iwAAAAALAEVs ZW0gU2Nob29shQAOAKqhAAAAAAYAQ2xpbmljmggYAJoIAAAAAAAAAAAAAAEAAAAAAAAAAQAAAKMI EACjCAAAAAAAAAAAAAAAAAAAjAAEAAEAAQCuAQQABAABBBcACAABAAAAAAAAABgAFwAhAAABBwAA AAEAAAAAAAANPAAAAAAAAMEBCADBAQAAHesBAOsAfgAPAADwdgAAAAAABvAwAAAABBAAAAUAAAAW AAAABAAAAAEAAAAZAAAAAgAAAA0AAAADAAAABwAAAAQAAAAEAAAAUwAL8B4AAAC/AAgACACBAUEA AAiGQQAAAADAAUAAAAjFQQAAAABAAB7xEAAAAA0AAAgMAAAIFwAACPcAABD8AI4GcgEAAEgAAAAL AABaaWdCZWUgVHlwZRIAAFRlbXBlcmF0dXJlIFNlbnNvcgoAAFRoZXJtb3N0YXQMAABQb3dlciBT b3VyY2UHAABCYXR0ZXJ5BAAATWVhbggAAFZhcmlhbmNlBQAAbWFpbnMEAABUeXBlCgAARW5kIERl dmljZQYAAFJvdXRlciEAAFJvdXRlciwgQ29vcmRpbmF0b3IsIFRydXN0IENlbnRlcgcAAERldmlj ZXMOAABUcmFuc21pdCBQb3dlcgMAADFtdxkAAERlbnNpdHkgKG1lc3NhZ2VzL21pbnV0ZSkPAABM ZW5ndGggCihieXRlcykIAAAxIC0gMTBtdy4AAEV4cGVjdGVkIEhvcHMgQmV0d2VlbiBTZW5kaW5n L1JlY2VpdmluZyBEZXZpY2UzAABFeHBlY3RlZCBEaXN0YW5jZSBCZXR3ZWVuIFNlbmRpbmcvUmVj ZWl2aW5nIERldmljZXMMAABEZXZpY2UgVHlwZSAGAABQZW9wbGUiAAgCAFF1YW50aXR5CiAoMTAw MDAgc3EgZnQgRmxvb3JwbGF0ZSkLAAwAEAAIAAsAAEFzc3VtcHRpb25zagAAMi4gIFRoZSBOQUUg cmVjZWl2ZXMgNzAlIG9mIHRoZSBtZXNzYWdlcy4gIFdlIHdpbGwgbW9kZWwgdGhlIE5BRSBjZW50 cmFsbHkgbG9jYXRlZCBhbmQgaW4gYSByZW1vdGUgbG9jYWxlLngAADMuICBUaGUgYWJvdmUgcmVw cmVzZW50cyBhIHF1aWVzY2VudCBzeXN0ZW0uICAgV2Ugd2lsbCBhbHNvIG1vZGVsIGFiYmVyYXRp b25zIHN1Y2hoIGFzIHN0YXJ0dXAgYW5kIGRvd25sb2FkcyBzZXBhcmF0ZWx5LkoAADEuIFRoZSBh Ym92ZSByZXByZXNlbnRzIGEgZmxvb3Igb2YgMTAwMDAgc3FmdC4gIEFsbCBmbG9vcnMgYXJlIGlu ZGVwZW5kZW50BwAAdW5pY2FzdAYAACsvLSAxMAUAACsvLSAxHQAATWVzc2FnZXMgRW50ZXJlZCBv bnRvIE5ldHdvcmsGAABUb3RhbHMIAABNZXNzYWdlcxcAAE1lc3NhZ2UgQUNLcyBvbiBOZXR3b3Jr HAAAUm91dGVyZWQgTWVzc2FnZXMgb24gTmV0d29yaw8AAEZsb29ycGxhdGUgU2l6ZQQAAHNxZnQE AABIb3BzBgAAMCBIb3BzBQAAMSBob3AGAAAyIGhvcHMGAAAzIGhvcHNGAABVbml0IFZlbnRpbGF0 b3JzIGluIHJvb21zIHdpdGggYSBDZW50cmFsIFBsYW50IHRvIGZlZWQgdGhlIHZlbnRpbGF0b3Jz BQAAKy8tIDUEAAArLy00CgAARXhwYW5kYWJsZQMAAG4vYQwAAEhvcml6b250YWxseQ0AAEhvcml6 b250YWxseSAKAABWZXJpY2FsbHkgCAAAMyBmbG9vcnMKAAA2MCBzdG9yaWVzBAAAKy8tNQIAACsy SgAAMS4gVGhlIGFib3ZlIHJlcHJlc2VudHMgYSBmbG9vciBvZiA1MDAwMCBzcWZ0LiAgQWxsIGZs b29ycyBhcmUgaW5kZXBlbmRlbnQbAABNZXNzYWdlIEFDSy9EYXRhIG9uIE5ldHdvcmsiAAgCAFF1 YW50aXR5CiAoNTAwMDAgc3EgZnQgRmxvb3JwbGF0ZSkLAAwAEAAIAA0AAFZlcnRpY2FsbHkgdG8J AABNZWFuIChmdCkOAABWYXJpYW5jZSAoKy8tKQIAACsxBgAAKy8tIDI1BAAAKy0xMCMAAFF1YW50 aXR5CiAoMjUwMDAwIHNxIGZ0IEZsb29ycGxhdGUpBAAAKy01MCMACAIAUXVhbnRpdHkKICgxNTAw MDAgc3EgZnQgRmxvb3JwbGF0ZSkLAAwAEQAIAAsAAERldmljZSBUeXBlEAAARmllbGQgQ29udHJv bGxlcg8AAFJvb20gQ29udHJvbGxlcgkAAFBvaW50IE11eBYAAFN1cGVydmlzb3J5IENvbnRyb2xs ZXJ9AAAyLiAgVGhlIFN1cGVydmlzb3J5IENvbnRyb2xsZXIgcmVjZWl2ZXMgNzAlIG9mIHRoZSBt ZXNzYWdlcy4gIFdlIHdpbGwgbW9kZWwgdGhlIE5BRSBjZW50cmFsbHkgbG9jYXRlZCBhbmQgaW4g YSByZW1vdGUgbG9jYWxlLv8ASgAIAI0yAAAMAAAA8DIAAG8AAABuMwAA7QAAAEc0AADGAQAAwDUA AD8DAAA1NgAAtAMAAME2AABABAAAbTcAAOwEAAAEOAAAgwUAAGMIFgBjCAAAAAAAAAAAAAAWAAAA AAAAAAIAlggQAJYIAAAAAAAAAAAAAELlAQCbCBAAmwgAAAAAAAAAAAAAAQAAAIwIEACMCAAAAAAA AAAAAAAAAAAACgAAAAkIEAAABhAAqh/NB8EAAQAGBAAACwIUAAAAAAAAAAAAFQAAAM9JAACsWAAA DQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggAC AAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAACYACAAAAAAA AADoPycACAAAAAAAAADoPygACAAAAAAAAADwPykACAAAAAAAAADwP00A+g4AAFwAXABjADcAbQBr AGUAcwAyADEAMgAuAGMAZwAuAG4AYQAuAGoAYwBpAC4AYwBvAG0AXABDADIAMAAwAAAAAAABBEoC 3AAcDgPXAQABAAEA6gpvCGQAAQAHAFgCAQABAAAAAwABAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAIAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAABDYW5vbgAAADgMAAAAAAAAAAEA AAEAAAACBgAACQR0BwAgCQTrA0MAYQBuAG8AbgAgAGkAUgA1ADAAMAAwAC0ANgAwADAAMAAgAFAA UwAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAD/BwAAJgIzAQAAAWQBAwIBAwMEAgUCBmQB AQIBAw8EEAUGAAdkAQECAQMPBBAFBgAIAwkBCgELAgwCDQIOAg8DAApkAQECAgMCBAIFAgYCBwII AglkAQMCAgMCBAEACmQBAgIBAwEEAQUKBmQBBwIHAwcEAgUIIAAAAAtkAQECAgMCBAIFAgYCBwII AgAMDQ1kAQMCAgQCBQIGAgcBAA5kAQMCAgMCBAIFAQYEgAcEQAgEQAAPZAEDAgggAwggBGQBBwIH AwcEAgUIIAAFCgYOBwEAEGQBAwICAwEEAQUBBgEHAQgIEgkCABFkAQEAEmQBCCAAE2QBAgIEIgBl ZAFkAQMCAwMBBAEFAQYBBwEIAQkBCgMLAQwBAAJkAQMCAmQDAQAEZAEDAgEDAQQBBQMGAwcDCAMJ AQoBCwIMAQ0BDgIPAhABEQISAhMBFAEVARYBFwEYCCEZCGUaARsBHAEdAR4BHwEgASEBIgMjASQB JQEmAicBAAVkAQghAggQAwEECCEABmQBAwIBAwEEAQUBBgEHAQgBCQYKBgsGDAINAg4CDwIQAREB EgETARQCFQIWAhcBGAEZAhoCGwMUHAIdAR4CHwIgAQAHZAEBAgEDAQQDBQhBBgYHBggGCQYKBgsG DAYNBg4DAAhkAQECAQMBBAEFAQYBBwEIAQkBCgiBCwiBDAiBDQIOAg8CEAIACWQBAgICAwgQBAgQ BQIGAwcIEAgIEAkCCgILAgADAwgAAAA4AAABAAAAAAAAAAEAAQBvCAAA6goAACgAAAAoAAAARwgA AMIKAACymwEAAQBvCAAA6goAACgAAAAoAAAARwgAAMIKAACymwEKhgBYAlgCAAABGAEAAABkAAAA AAAAAAAAAAAAAQAyAAEBAAEAAQAAAAAACwAAAAAAAACQAQAAAEEAcgBpAGEAbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAEAAGQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAXENBTlNSR0JBLklDQwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAABcQ0FOU1JHQkEuSUNDAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFxDQU5TUkdCQS5JQ0MAAAAAAAACAQEB AQICAAABAAAACQAAAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJIAAABD AE8ATgBGAEkARABFAE4AVABJAEEATAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQwBPAE4ARgBJAEQARQBOAFQASQBBAEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEgAAAAAAAAAkAEAAAAt/zP/IAAw/w5mHWcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgICAAAAAAAAAAAAAwgEAAAAAAAcABwAH AAQABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAABEAGUAZgBhAHUAbAB0 ACAAUwBlAHQAdABpAG4AZwBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAMAZAAAACQEwgEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAEAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC AAIAAgAEAAIAAgACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHIAaQBuAHQAZQByACAARABlAGYAYQB1AGwAdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHIAaQBu AHQAZQByACAARABlAGYAYQB1AGwAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGEAbgBvAG4AIABpAFIAIABDADMAMgAwADAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAChACIAAQBkAAEAAQABAAIAWAIAAAAAAAAAAOA/AAAAAAAA4D8BAJwIJgCcCAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAFUAAgAIAH0ADAAAAAAAJBIPAAIAAAB9AAwAAQABACQM PgACAAAAfQAMAAIAAgCSCj4AAgAAAH0ADAADAAMAtgs/AAIAAAB9AAwABAAFAAALPgACAAAAfQAM AAYABgBJDD4AAgAAAH0ADAAHAAcA2ws+AAIAAAB9AAwACAAJAAALPgACAAAAfQAMAAoACgAkCj4A AgAAAH0ADAALAAsA2wo+AAIAAAB9AAwADAAMALYJPgACAAAAfQAMAA0ADgDbCj4AAgAAAH0ADAAX ABcAJA4PAAIAAAAAAg4AAAAAABUAAAAAABgAAAAIAhAAAAAAABgAlQEAAAAAQAEPAAgCEAABAAAA GACUAgAAAABAAQ8ACAIQAAIAAAAYAIYBAAAAAEABDyAIAhAAAwAAABgADgEAAAAAAAEPEAgCEAAE AAAAGAD/AAAAAAAAAQ8ACAIQAAUAAAAYAP8AAAAAAAABDwAIAhAABgAAABgA/wAAAAAAAAEPAAgC EAAHAAAAGAD/AAAAAAAAAQ8ACAIQAAgAAAAYALICAAAAAAABDyAIAhAACQAAABgA/wAAAAAAAAEP AAgCEAAKAAAAGAD/AAAAAAAAAQ8ACAIQAAsAAAAYAP8AAAAAAAABDwAIAhAADAAAABgA/wAAAAAA AAEPAAgCEAANAAAAGAD/AAAAAAAAAQ8ACAIQAA4AAAAYAP8AAAAAAAABDwAIAhAADwAAABgA/wAA AAAAAAEPAAgCEAAQAAEABgAOAQAAAAAAAQ8gCAIQABEAAQAGAP4BAAAAAEABDwAIAhAAEgABAAYA wgEAAAAAQAEPAAgCEAATAAEABgCUAgAAAABAAQ8ACAIQABQAAQAGAEkCAAAAAEABDyD9AAoAAAAA AHoAFAAAAP0ACgAAAAEAdwADAAAA/QAKAAAAAgB3AA0AAAD9AAoAAAADAHcAQgAAAP0ACgAAAAQA gQAMAAAAvgASAAAABQB9AH0AfQB9AIIARQAKAP0ACgAAAAsAfQAeAAAAvgAMAAAADAB9AH0AfgAO AP0ACgAAAA8AfQAhAAAAvgAMAAAAEAB9AH0AfgASAP0ACgAAABMAhQAiAAAAvgAMAAAAFAB9AH0A fgAWAP0ACgAAABcAWwAfAAAAvgAOAAEAAAB7AHgAeAB4AAMA/QAKAAEABAB/ADgAAAABAgYAAQAF AIAA/QAKAAEABgB/ABMAAAABAgYAAQAHAIAA/QAKAAEACAB/ABIAAAABAgYAAQAJAIAA/QAKAAEA CgCDAAgAAAD9AAoAAQALAH8ADwAAAAECBgABAAwAgAD9AAoAAQANAH8AEAAAAAECBgABAA4AhAD9 AAoAAQAPAH8ADwAAAAECBgABABAAgAD9AAoAAQARAH8AEAAAAAECBgABABIAhAD9AAoAAQATAIYA JQAAAL4ADAABABQAhwCHAIQAFgD9AAoAAQAXAFwAIAAAAL4ADgACAAAAfAB5AHkAeQADAP0ACgAC AAQATQAFAAAA/QAKAAIABQBNAAYAAAD9AAoAAgAGAEgAOgAAAP0ACgACAAcASAA7AAAA/QAKAAIA CABIAAUAAAD9AAoAAgAJAEgABgAAAAECBgACAAoAeQD9AAoAAgALAEgABQAAAP0ACgACAAwASAAG AAAA/QAKAAIADQBIAAUAAAD9AAoAAgAOAEkABgAAAP0ACgACAA8ASAAFAAAA/QAKAAIAEABIAAYA AAD9AAoAAgARAEgABQAAAP0ACgACABIASQAGAAAA/QAKAAIAEwBnACYAAAD9AAoAAgAUAEgAJwAA AP0ACgACABUASAAoAAAA/QAKAAIAFgBJACkAAAD9AAoAAgAXAF0ABQAAAP0ACgADAAAASgABAAAA /QAKAAMAAQBGAAQAAAD9AAoAAwACAEYADgAAAP0ACgADAAMARgAJAAAAfgIKAAMABABjAAAAOED9 AAoAAwAFAGQANAAAAAYAJwADAAYAYAB17Pi6X9JGQAAAAwAH/xEARAwAAcBBFABEAwAEwEEUAAYG ACUAAwAHAGAA94ktL+ZBIkAAAAQAFf8PAEQDAAbAH5qZmZmZmck/Bb0AEgADAAgAYAAAAAAAYAAA AAAACQD9AAoAAwAKAEYAGwAAAL0ATgADAAsARgAAAPA/RgAAAAAARgAAAD5ARwAAAAAARgAAAAAA RgAAAAAARgAAAAAARwAAAAAAaAAAwFJARgAAADRARgAAABRARwAAAAAAFgAGABsAAwAXAF4AAAAA AAAA8D8IAAYAF/8FAAEDABcAvAQVAAMACAAXFwAGCwBMAAD0wEwAAPjAA/0ACgAEAAAASwACAAAA /QAKAAQAAQBCAAcAAAD9AAoABAACAEIAEQAAAP0ACgAEAAMAQgAKAAAAvQAqAAQABABlAAAAAABl AAAAAABhAAAAAABhAAAAAABhAAAAAABhAAAAAAAJAP0ACgAEAAoARgAbAAAAvQA8AAQACwBCAAAA AABCAAAAAABCAAAAAABDAAAAAABGAAAAAABCAAAAAABCAAAAAABDAAAAAABoAAAAAAATAAYAGwAE ABQARgAAAAAAAAAAAAAABgAP/wUARAQAC8AGABsABAAVAEYAAAAAAAAAAAAAAAQAFP8FAEQEAA/A fgIKAAQAFgBDAAAAAAAGABsABAAXAF4AAAAAAAAAAAAIAAcAF/8FAAEDABcA/QAKAAUAAABLAEMA AAD9AAoABQABAEIABwAAAP0ACgAFAAIAQgARAAAA/QAKAAUAAwBCAAoAAAB+AgoABQAEAGUAAAAY QP0ACgAFAAUAZAA1AAAABgAnAAUABgBgAHXs+Lpf0lZAAAAFAAf/EQBEDAABwEEUAEQFAATAQRQA BgYAJQAFAAcAYQD3iS0v5kEyQAAAAwAG/w8ARAUABsAfmpmZmZmZyT8FvQASAAUACABhAAAA8D9h AAAAAAAJAP0ACgAFAAoARgAbAAAABgAfAAUACwBCAAAAAAAAAE5AAAAHAAv/CQBEBQAEwB4KAAX9 AAoABQAMAFEAHQAAAH4CCgAFAA0ATwAAwF9A/QAKAAUADgBQABwAAAAGAB8ABQAPAEIAAAAAAAAA GEAAAAUAF/8JAEQFAATAHgEABb0AMAAFABAAUQAAAAAATwAAAE5AUAAAAAAAaAAAAEFARgAAgEBA RgAAgEBAUAAAAAAAFgAGABsABQAXAF4AAAAAAACAUEAIAAcAD/8FAAEDABcA/QAKAAYAAABLAEQA AAD9AAoABgABAEIABwAAAP0ACgAGAAIAQgARAAAA/QAKAAYAAwBCAAoAAAB+AgoABgAEAGUAAAA0 QP0ACgAGAAUAZAA0AAAAvQAeAAYABgBgAAAAPkBhAAAAJEBhAAAAAABhAAAAAAAJAP0ACgAGAAoA RgAbAAAABgAfAAYACwBCAAAAAAAAAGlAAAAIAA//CQBEBgAEwB4KAAX9AAoABgAMAFEAHQAAAH4C CgAGAA0ATwAAwF9A/QAKAAYADgBQABwAAAAGAB8ABgAPAEIAAAAAAAAANEAAAAYAC/8JAEQGAATA HgEABb0AMAAGABAAUQAAAAAATwAAAE5AUAAAAAAAaAAAAEFARgAAgEBARgAAgEBAUAAAAAAAFgAG ABsABgAXAF4AAAAAAACAa0AIAMAAAP0FAAEDABcA/QAKAAcAAABLAEUAAAD9AAoABwABAEIABwAA AP0ACgAHAAIAQgARAAAA/QAKAAcAAwBCAAoAAAB+AgoABwAEAGUAAADwPwECBgAHAAUAZQC9AB4A BwAGAGAAAABZQGEAAAA0QGEAAADwP2EAAAAAAAkA/QAKAAcACgBGABsAAAAGAB8ABwALAEIAAAAA AAAAJEAAAAUAD/8JAEQHAATAHgoABf0ACgAHAAwAUQAdAAAAfgIKAAcADQBCAADAX0D9AAoABwAO AFAAHAAAAAYAHwAHAA8AQgAAAAAAAADwPwAABAAX/wkARAcABMAeAQAFvQAwAAcAEABRAAAAAABC AAAATkBQAAAAAABoAAAAQUBGAACAQEBGAACAQEBQAAAAAAAWAAYAGwAHABcAXgAAAAAAAAAmQAgA AwAX/wUAAQMAFwD9AAoACAAAAEwARgAAAP0ACgAIAAEARAAHAAAA/QAKAAgAAgBEABEAAAD9AAoA CAADAEQACwAAAL0AKgAIAAQAZgAAAOA/ZgAAAAAAYgAAAFlAYgAAAElAYgAAAAAAYgAAAPA/CQD9 AAoACAAKAFQAGwAAAH4CCgAIAAsARAAAAPA//QAKAAgADABVAB0AAAB+AgoACAANAEQAAMBfQP0A CgAIAA4AVgAcAAAABgAjAAgADwBEAAAAAAAA4HBAAAAIABf/DQAlBQAHAAvAC8AZEAVBvQAwAAgA EABVAAAAAABEAACAUUBWAAAAAABpAAAAQUBUAACAQEBUAACAQEBWAAAAAAAWAAYAGwAIABcAXwAA AAAAAPBwQAgABQAL/wUAAQMAFwD9AAoACQAAAEEAHwAAAL4ADAAJAAEAQABAAEAAAwAGACMACQAE AEAAAAAAAADASUAAAAUABv4NACUDAAgABMAEwBkQQUG+ABwACQAFAEAAQABAAEAAQABAAEAAQABA AEAAWAAPAL4ADAAJABMAVwBSAFIAFQABAgYACQAXAFIAvgAkAAoAAABBAEAAQABAAEAAQABAAEAA QABAAEAAQABAAEAAQAAOAAECBgAKABcAVwD9AAoACwAAAEEAFQAAAH4CCgALAAEAagAAAFlAAQIG AAsAAgBqAP0ACgAMAAAAQQAjAAAAfgIKAAwAAQBqAABq6ED9AAoADAACAGoAJAAAAP0ACgANAAAA QQAtAAAA/QAKAA0AAQBqADkAAAD9AAoADQACAGoAMwAAAAECBgAOAAAAQQABAgYADwAAAEEA/QAK ABEAAQB0ABcAAAC+AA4AEQACAHUAdQB1AHYABQD9AAoAEgABAG4ANgAAAL4ADgASAAIAbwBvAG8A cAAFAP0ACgATAAEAbgBHAAAAvgAOABMAAgBvAG8AbwBwAAUA/QAKABQAAQBxABkAAAC+AA4AFAAC AHIAcgByAHMABQDXAC4A9Q0AAJABxAD0ACYBVgEfAY8BRwFDASYBfwAyACYAKgAqAAoACgAAACAA IAAgAMIBJAAEAAMAAgAJDwcAcgAJAAMAAwAJFxcAQAAFAAkAAQAJBgQAQADsAM4ADwAC8NQDAAAQ AAjwCAAAAAgAAAAYBAAADwAD8LwDAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAAQAAAUAAAAPAATwfgAAAKIMCvAIAAAAEAQAAAAKAACjAAvwPAAAAIAAKJmIA4UAAQAA AIsAAgAAAL8ACAAIAFgBAAAAAIEBUAAACIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAA AwAKAGEDAAC0AAwAaQICAIoAAAAR8AAAAABdADQAFQASABkAEAARQCiZiAPAFogDAAAAAA0AFgA+ oWDgyEa+T4LP1jfx7USWAAAQAAAAAAAAAOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAANAAYAAAA AAA8ADUAAFNvbGljaXRlZApVbnNvbGljaXRlZApCcm9hZGNhc3QKR3VhcmFudGVlZCBEZWxpdmVy eQo8ABgAAAAHAAAAAAAzAAYAAAAAADQA/38AAAAA7AB+AA8ABPB+AAAAogwK8AgAAAASBAAAAAoA AKMAC/A8AAAAgACAmYgDhQABAAAAiwACAAAAvwAIAAgAWAEAAAAAgQFQAAAIgwFQAAAIAQIAAAAA PwIDAAMAvwMCAAIAAAAQ8BIAAAADAAUAWgEHAGkABgCVAwgAZAAAABHwAAAAAF0ANAAVABIAGQAS ABFAgJmIAyAXiAMAAAAADQAWAJDpCJsC9gdLiq9Xwu7Vru4AAIsAAgAAAAAA7AAIAAAADfAAAAAA tgESABICAAAAAAAAAAAVABgAAAAAADwAFgAAMSBmb3IgZXZlcnkgNCBmbG9vcnMKPAAYAAAABwAA AAAAFAAGAAAAAAAVAP9/AAAAAOwAeAAPAATweAAAAKIMCvAIAAAAEwQAAAAKAACTAAvwNgAAAIAA 0JmIA4sAAgAAAL8ACAAIAFgBAAAAAIEBUAAACIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPAS AAAAAwABALUACgBpAAIAIwMPAB4AAAAR8AAAAABdADQAFQASABkAEwARQNCZiAOAF4gDAAAAAA0A FgAa6H/J4DvkToM+yTqsocagAAC/AAgAAAAAAOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAAHwAY AAAAAAA8ACAAADEgcGVyc29uLyAxMDAgc3FmdAouOCBjZm0vc3EgZnQ8ABgAAAAHAAAAAAASAAYA AAAAAB8A/38AAAAA7AB4AA8ABPB4AAAAogwK8AgAAAAVBAAAAAoAAJMAC/A2AAAAgACol4gDiwAC AAAAvwAIAAgAWAEAAAAAgQFQAAAIgwFQAAAIAQIAAAAAPwIDAAMAvwMCAAIAAAAQ8BIAAAADAAcA uQACAJ4ACAAeAwYAtQAAABHwAAAAAF0ANAAVABIAGQAVABFAqJeIA+AXiAMAAAAADQAWAOOOAt0j Zy1GlzYrMzEVukYAAL8ACAAAAAAA7AAIAAAADfAAAAAAtgESABICAAAAAAAAAAAfABgAAAAAADwA IAAARGlzdGFuY2UgYmV0d2VlbiBUZW1wIFNlbnNvcnMKCjwAGAAAAA0AAAAAAB4ABgAAAAAAHwD/ fwAAAADsAHgADwAE8HgAAACiDArwCAAAABYEAAAACgAAkwAL8DYAAACAACgViQOLAAIAAAC/AAgA CABYAQAAAACBAVAAAAiDAVAAAAgBAgAAAAA/AgMAAwC/AwIAAgAAABDwEgAAAAMABwC5AAQAaQAI AB4DCABIAAAAEfAAAAAAXQA0ABUAEgAZABYAEUAoFYkDQBiIAwAAAAANABYAbNFKMitdxkClRoL3 ZstLwQAAvwAIAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAAABgAGAAAAAAAPAAZAABEaXN0 YW5jZSBiZXR3ZWVuIEZFQ3MuCgo8ABgAAAANAAAAAAAXAAYAAAAAABgA/38AAAAA7AB4AA8ABPB4 AAAAogwK8AgAAAAXBAAAAAoAAJMAC/A2AAAAgACAFYkDiwACAAAAvwAIAAgAWAEAAAAAgQFQAAAI gwFQAAAIAQIAAAAAPwIDAAMAvwMCAAIAAAAQ8BIAAAADAAcAuQAFAGkACAAeAwgApwAAABHwAAAA AF0ANAAVABIAGQAXABFAgBWJA6AYiAMAAAAADQAWAFJ/SC262gBBn3KOhaFRtQwAAL8ACAAAAAAA 7AAIAAAADfAAAAAAtgESABICAAAAAAAAAAAxABgAAAAAADwAMgAARGlzdGFuY2UgYmV0d2VlbiBW TUEgYW5kIGFzc29jaWF0ZWQgVGVtcCBTZW5zb3IKCjwAGAAAAA0AAAAAADAABgAAAAAAMQD/fwAA AADsAHgADwAE8HgAAACiDArwCAAAABgEAAAACgAAkwAL8DYAAACAAAAViQOLAAIAAAC/AAgACABY AQAAAACBAVAAAAiDAVAAAAgBAgAAAAA/AgMAAwC/AwIAAgAAABDwEgAAAAMABwC5AAYAaQAIAB4D CQAPAAAAEfAAAAAAXQA0ABUAEgAZABgAEUAAFYkDABmIAwAAAAANABYAybc6I3DoLUCX3KdyvQek CQAAvwAIAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAAABgAGAAAAAAAPAAZAABEaXN0YW5j ZSBiZXR3ZWVuIEZFQ3MuCgo8ABgAAAANAAAAAAAXAAYAAAAAABgA/38AAAAAHAAbAAEACgAAABAA DwAAIEplcnJ5IE1hcnRvY2NpyRwAGwADAAYAAAAVAA8AACBKZXJyeSBNYXJ0b2NjackcABsABQAG AAAAFgAPAAAgSmVycnkgTWFydG9jY2nJHAAbAAYABgAAABcADwAAIEplcnJ5IE1hcnRvY2NpyRwA GwAHAAYAAAAYAA8AACBKZXJyeSBNYXJ0b2NjackcABsACAAEAAAAEgAPAAAgSmVycnkgTWFydG9j Y2nJHAAbAAsAAAAAABMADwAAIEplcnJ5IE1hcnRvY2NpyT4CEgC+BwAAAABAAAAAAABkAHJyAACL CBAAiwgAAAAAAAAAAAAAAAByckEACgABAAMAAwABAAAAHQAPAAMAAAAAAAABAAAAAAAAAB0ADwAB AAABAAAAAQAAAAAAAQEdAA8AAgMAAAAAAAEAAwADAAAAHQAPAAAZAAIAAAABABkAGQACAuUAqgAV AAAAAAAPABIAAQABAA8AEAABAAEAEQASAAAAAAATABYAAQABABMAFgAAAAIAAAAAAAAAAAALAA4A AQABAAgACQAAAAAABAAJAAEAAQALAAwAAQACAAoACgABAAEADQAOAAEAAQAGAAcAAAACAAMAAwAB AAEABAAFABMAEwABAAUAFAAUAAEABQASABIAAQAFABEAEQABAAUAAAACAAIAAgAAAAIAAQABAO8A BgAFALcDAABnCBcAZwgAAAAAAAAAAAAAAgAB/////wNEAAAKAAAACQgQAAAGEACqH80HwQABAAYE AAALAhQAAAAAAAAAAAAUAAAAU3MAAJSCAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx 0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDBBBQA AAAVAAAAgwACAAAAhAACAAAAJgAIAAAAAAAAAOg/JwAIAAAAAAAAAOg/KAAIAAAAAAAAAPA/KQAI AAAAAAAAAPA/TQD6DgAAXABcAGMANwBtAGsAZQBzADIAMQAyAC4AYwBnAC4AbgBhAC4AagBjAGkA LgBjAG8AbQBcAEMAMgAwADAAAAAAAAEESgLcABwOA9cBAAEAAQDqCm8IZAABAAcAWAIBAAEAAAAD AAEATABlAHQAdABlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAEAAAACAAAAAAAAAAAAAAAA AAAAAAAAAENhbm9uAAAAOAwAAAAAAAAAAQAAAQAAAAIGAAAJBHQHACAJBOsDQwBhAG4AbwBuACAA aQBSADUAMAAwADAALQA2ADAAMAAwACAAUABTADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA AP8HAAAmAjMBAAABZAEDAgEDAwQCBQIGZAEBAgEDDwQQBQYAB2QBAQIBAw8EEAUGAAgDCQEKAQsC DAINAg4CDwMACmQBAQICAwIEAgUCBgIHAggCCWQBAwICAwIEAQAKZAECAgEDAQQBBQoGZAEHAgcD BwQCBQggAAAAC2QBAQICAwIEAgUCBgIHAggCAAwNDWQBAwICBAIFAgYCBwEADmQBAwICAwIEAgUB BgSABwRACARAAA9kAQMCCCADCCAEZAEHAgcDBwQCBQggAAUKBg4HAQAQZAEDAgIDAQQBBQEGAQcB CAgSCQIAEWQBAQASZAEIIAATZAECAgQiAGVkAWQBAwIDAwEEAQUBBgEHAQgBCQEKAwsBDAEAAmQB AwICZAMBAARkAQMCAQMBBAEFAwYDBwMIAwkBCgELAgwBDQEOAg8CEAERAhICEwEUARUBFgEXARgI IRkIZRoBGwEcAR0BHgEfASABIQEiAyMBJAElASYCJwEABWQBCCECCBADAQQIIQAGZAEDAgEDAQQB BQEGAQcBCAEJBgoGCwYMAg0CDgIPAhABEQESARMBFAIVAhYCFwEYARkCGgIbAxQcAh0BHgIfAiAB AAdkAQECAQMBBAMFCEEGBgcGCAYJBgoGCwYMBg0GDgMACGQBAQIBAwEEAQUBBgEHAQgBCQEKCIEL CIEMCIENAg4CDwIQAgAJZAECAgIDCBAECBAFAgYDBwgQCAgQCQIKAgsCAAMDCAAAADgAAAEAAAAA AAAAAQABAG8IAADqCgAAKAAAACgAAABHCAAAwgoAALKbAQABAG8IAADqCgAAKAAAACgAAABHCAAA wgoAALKbAQqGAFgCWAIAAAEYAQAAAGQAAAAAAAAAAAAAAAABADIAAQEAAQABAAAAAAALAAAAAAAA AJABAAAAQQByAGkAYQBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAAAAAQAAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAABcQ0FOU1JHQkEuSUNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAIAAFxDQU5TUkdCQS5JQ0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAXENBTlNSR0JBLklDQwAAAAAAAAIBAQEBAgIAAAEAAAAJAAAA//8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAEMATwBOAEYASQBEAEUATgBUAEkAQQBMAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDAE8ATgBGAEkARABFAE4AVABJAEEATAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAAACQAQAAAC3/M/8g ADD/DmYdZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAgIAAAAAAAAAAAADCAQAAAAAABwAHAAcABAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAEQAZQBmAGEAdQBsAHQAIABTAGUAdAB0AGkAbgBnAHMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAAwBkAAAAJATCAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAAgAAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAgACAAQAAgACAAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgBpAG4AdABl AHIAIABEAGUAZgBhAHUAbAB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcgBpAG4AdABlAHIAIABEAGUAZgBhAHUAbAB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYQBuAG8A bgAgAGkAUgAgAEMAMwAyADAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKEAIgABAGQAAQABAAEAAgBYAgAAAAAAAAAA4D8A AAAAAADgPwEAnAgmAJwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAVQACAAgA fQAMAAAAAAAkEg8AAgAAAH0ADAABAAIAJAw+AAIAAAB9AAwAAwADALYLPwACAAAAfQAMAAQABQAA Cz4AAgAAAH0ADAAGAAYASQw+AAIAAAB9AAwABwAHANsLPgACAAAAfQAMAAgACQAACz4AAgAAAH0A DAAKAAoAJAo+AAIAAAB9AAwACwALANsKPgACAAAAfQAMAAwADAC2CT4AAgAAAH0ADAANAA4A2wo+ AAIAAAB9AAwAFwAXACQODwACAAAAAAIOAAAAAAAUAAAAAAAYAAAACAIQAAAAAAAYAJUBAAAAAEAB DwAIAhAAAQAAABgAlAIAAAAAQAEPAAgCEAACAAAAGACGAQAAAABAAQ8gCAIQAAMAAAAYAA4BAAAA AAABDxAIAhAABAAAABgADgEAAAAAAAEPIAgCEAAFAAAAGAD/AAAAAAAAAQ8ACAIQAAYAAAAYAP8A AAAAAAABDwAIAhAABwAAABgADgEAAAAAAAEPIAgCEAAIAAAAGACyAgAAAAAAAQ8gCAIQAAkAAAAY AP8AAAAAAAABDwAIAhAACgAAABgA/wAAAAAAAAEPAAgCEAALAAAAGAD/AAAAAAAAAQ8ACAIQAAwA AAAYAP8AAAAAAAABDwAIAhAADQAAABgA/wAAAAAAAAEPAAgCEAAOAAAAGAD/AAAAAAAAAQ8ACAIQ AA8AAAAYAA4BAAAAAAABDyAIAhAAEAABAAYA/gEAAAAAQAEPAAgCEAARAAEABgDCAQAAAABAAQ8A CAIQABIAAQAGAJQCAAAAAEABDwAIAhAAEwABAAYASQIAAAAAQAEPIP0ACgAAAAAAegAUAAAA/QAK AAAAAQB3AAMAAAD9AAoAAAACAHcADQAAAP0ACgAAAAMAdwAAAAAA/QAKAAAABACBAAwAAAC+ABIA AAAFAH0AfQB9AH0AggBFAAoA/QAKAAAACwB9AB4AAAC+AAwAAAAMAH0AfQB+AA4A/QAKAAAADwB9 ADcAAAC+AAwAAAAQAH0AfQB+ABIA/QAKAAAAEwCFACIAAAC+AAwAAAAUAH0AfQB+ABYA/QAKAAAA FwBbAB8AAAC+AA4AAQAAAHsAeAB4AHgAAwD9AAoAAQAEAH8AFgAAAAECBgABAAUAgAD9AAoAAQAG AH8AEwAAAAECBgABAAcAgAD9AAoAAQAIAH8AEgAAAAECBgABAAkAgAD9AAoAAQAKAIMACAAAAP0A CgABAAsAfwAPAAAAAQIGAAEADACAAP0ACgABAA0AfwAQAAAAAQIGAAEADgCEAP0ACgABAA8AfwAP AAAAAQIGAAEAEACAAP0ACgABABEAfwAQAAAAAQIGAAEAEgCEAP0ACgABABMAhgAlAAAAvgAMAAEA FACHAIcAhAAWAP0ACgABABcAXAAgAAAAvgAOAAIAAAB8AHkAeQB5AAMA/QAKAAIABABNAAUAAAD9 AAoAAgAFAE0ABgAAAP0ACgACAAYASAAFAAAA/QAKAAIABwBIAAYAAAD9AAoAAgAIAEgABQAAAP0A CgACAAkASAAGAAAAAQIGAAIACgB5AP0ACgACAAsASAAFAAAA/QAKAAIADABIAAYAAAD9AAoAAgAN AEgABQAAAP0ACgACAA4ASQAGAAAA/QAKAAIADwBIAAUAAAD9AAoAAgAQAEgABgAAAP0ACgACABEA SAAFAAAA/QAKAAIAEgBJAAYAAAD9AAoAAgATAGcAJgAAAP0ACgACABQASAAnAAAA/QAKAAIAFQBI ACgAAAD9AAoAAgAWAEkAKQAAAP0ACgACABcAXQAFAAAA/QAKAAMAAABKAAEAAAD9AAoAAwABAEYA BAAAAP0ACgADAAIARgAOAAAA/QAKAAMAAwBGAAkAAAC9ACoAAwAEAGMAAAAAAGMAAAAAAEYAAAAA AEYAAAAAAEYAAAAAAEYAAAAAAAkA/QAKAAMACgBGABsAAAC9AE4AAwALAEYAAAAAAEYAAAAAAEYA AAAAAEcAAAAAAEYAAAAAAEYAAAAAAEYAAAAAAEcAAAAAAGgAAAAAAEYAAAAAAEYAAAAAAEcAAAAA ABYABgAbAAMAFwBeAAAAAAAAAAAACAAEABf/BQABAwAXALwEFQADAAgAFxcABgsATAAA9MBMAAD4 wAP9AAoABAAAAEsAAgAAAP0ACgAEAAEAQgAHAAAA/QAKAAQAAgBCABEAAAD9AAoABAADAEIACgAA AH4CCgAEAAQAZQAAABBA/QAKAAQABQBkADUAAAB+AgoABAAGAEIAAABJQP0ACgAEAAcAVQA9AAAA vQASAAQACABCAAAA8D9CAAAA8D8JAP0ACgAEAAoARgAbAAAAvQAeAAQACwBCAAAAAABCAAAAAABC AAAAAABDAAAAAAAOAAYAHwAEAA8ARgAAAAAAAMByQAAACAAL/gkAHksARAQABMAFvQAwAAQAEABC AAAAAABCAADAX0BDAAAAAABoAAAAQUBGAACAQEBGAACAQEBDAAAAAAAWAAYAGwAEABcAXgAAAAAA AMByQAgABQAL/wUAAQMAFwD9AAoABQAAAEsAQwAAAP0ACgAFAAEAQgAHAAAA/QAKAAUAAgBCABEA AAD9AAoABQADAEIACgAAAL0AKgAFAAQAZQAAAAAAZQAAAAAAQgAAAAAAQgAAAAAAQgAAAAAAQgAA AAAACQD9AAoABQAKAEYAGwAAAAYAHwAFAAsAQgAAAAAAAAAAAAAABQAP/wkARAUABMAeCgAF/QAK AAUADABRAB0AAAB+AgoABQANAE8AAMBfQP0ACgAFAA4AUAAcAAAABgAfAAUADwBCAAAAAAAAAAAA AAAFABf/CQBEBQAEwB4BAAW9ADAABQAQAFEAAAAAAE8AAABOQFAAAAAAAGgAAABBQEYAAIBAQEYA AIBAQFAAAAAAABYABgAbAAUAFwBeAAAAAAAAAAAACAAGAAv/BQABAwAXAP0ACgAGAAAASwBEAAAA /QAKAAYAAQBCAAcAAAD9AAoABgACAEIAEQAAAP0ACgAGAAMAQgAKAAAAvQAqAAYABABlAAAAAABl AAAAAABCAAAAAABCAAAAAABCAAAAAABCAAAAAAAJAP0ACgAGAAoARgAbAAAABgAfAAYACwBCAAAA AAAAAAAAAAAJAAv/CQBEBgAEwB4KAAX9AAoABgAMAFEAHQAAAH4CCgAGAA0ATwAAwF9A/QAKAAYA DgBQABwAAAAGAB8ABgAPAEIAAAAAAAAAAAAAAAcAC/8JAEQGAATAHgEABb0AMAAGABAAUQAAAAAA TwAAAE5AUAAAAAAAaAAAAEFARgAAgEBARgAAgEBAUAAAAAAAFgAGABsABgAXAF4AAAAAAAAAAAAI AAkAF/8FAAEDABcA/QAKAAcAAABLAEUAAAD9AAoABwABAEIABwAAAP0ACgAHAAIAQgARAAAA/QAK AAcAAwBCAAoAAAB+AgoABwAEAGUAAAAAQP0ACgAHAAUAZAA8AAAAfgIKAAcABgBCAAAASUD9AAoA BwAHAFUAPQAAAL0AEgAHAAgAQgAAAPA/QgAAAPA/CQD9AAoABwAKAEYAGwAAAAYAHwAHAAsAQgAA AAAAAAA0QAAABwAP/wkARAcABMAeCgAF/QAKAAcADABRAB0AAAB+AgoABwANAEIAAMBfQP0ACgAH AA4AUAAcAAAABgAfAAcADwBCAAAAAAAAAABAAAAHABf/CQBEBwAEwB4BAAW9ADAABwAQAFEAAAAA AEIAAABOQFAAAAAAAGgAAABBQEYAAIBAQEYAAIBAQFAAAAAAABYABgAbAAcAFwBeAAAAAAAAADZA CAAIAA//BQABAwAXAP0ACgAIAAAATABGAAAA/QAKAAgAAQBEAAcAAAD9AAoACAACAEQAEQAAAP0A CgAIAAMARAALAAAAvQAYAAgABABmAAAA8D9mAAAAAABEAAAASUAGAP0ACgAIAAcAVQA9AAAAvQAS AAgACABEAAAA8D9EAAAA8D8JAP0ACgAIAAoAVAAbAAAABgAfAAgACwBEAAAAAAAAAFlAAAADABf/ CQAeGQBEBAAEwAX9AAoACAAMAFUAHQAAAH4CCgAIAA0ARAAAwF9A/QAKAAgADgBWABwAAAAGACMA CAAPAEQAAAAAAAAANEAAAAgAF/8NACUFAAcAC8ALwBkQQUG9ADAACAAQAFUAAAAAAEQAAIBRQFYA AAAAAGkAAABBQFQAAIBAQFQAAIBAQFYAAAAAABYABgAbAAgAFwBfAAAAAAAAAF5ACAAJABX/BQAB AwAXAP0ACgAJAAAAQQAfAAAAvgAMAAkAAQBAAEAAQAADAAYAIwAJAAQAQAAAAAAAAAAcQAAABgAX /w0AJQMACAAEwATAGRBBQb4AEgAJAAUAQABAAEAAQABAAEAACgAGACMACQALAEAAAAAAAAAAXkAA AAYAD/8NACUDAAgAC8ALwBkQQUG+AAwACQAMAEAAQABAAA4ABgAjAAkADwBYAAAAAAAAIHRAAAAJ AAT/DQAlAwAIAA/AD8AZEEFBBgAjAAkAEwBXAAAAAAAAQGVAAAAJAA//DQAlAwAIABPAE8AZEEFB BgAjAAkAFABSAAAAAAAAoGRAAAAJABP/DQAlAwAIABTAFMAZEEFBBgAjAAkAFQBSAAAAAAAAoGRA AAAJABT/DQAlAwAIABXAFcAZEEFBBgAjAAkAFwBSAAAAAAAAoHtAAADAAAD9DQAlAwAIABfAF8AZ EEFBvgAkAAoAAABBAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAAOAAECBgAKABcAVwD9AAoA CwAAAEEAFQAAAH4CCgALAAEAawAAAFlAvgAKAAsAAgBrAGwAAwD9AAoADAAAAEEAIwAAAH4CCgAM AAEAawAAiMNA/QAKAAwAAgBrACQAAAABAgYADAADAGwAAQIGAA0AAABBAP0ACgANAAEAawAtAAAA /QAKAA0AAgBrADAAAAABAgYADQADAGwAvgAKAA4AAABBAGsAAQD9AAoADgACAGsAMQAAAP0ACgAO AAMAbAAyAAAA/QAKABAAAQB0ABcAAAC+AA4AEAACAHUAdQB1AHYABQD9AAoAEQABAG4AGgAAAL4A DgARAAIAbwBvAG8AcAAFAP0ACgASAAEAbgAYAAAAvgAOABIAAgBvAG8AbwBwAAUA/QAKABMAAQBx ABkAAAC+AA4AEwACAHIAcgByAHMABQDXACwAaQ4AAHwBxAD0ACYB/gAsATcBNwFXAU0BVQEyACoA NAAwACoAAAAgACAAIADCATAACAAEAAIACQsPAHIAAwAIAAQACRcLAEAABAAJAAEACRUEAEAABgAJ AAEACRcXAAAA7ADOAA8AAvDaAgAAIAAI8AgAAAAGAAAADAgAAA8AA/DCAgAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8H4AAACiDArwCAAAAAcIAAAA CgAAowAL8DwAAACAAFAaiQOFAAEAAACLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAgBAgAA AAA/AgMAAwC/AwIAAgAAABDwEgAAAAMACwDKAAAAoQAMAPEDAgB2AAAAEfAAAAAAXQA0ABUAEgAZ AAcAEUBQGokDQBuIAwAAAAANABYAiK2jJkJFp0CFWgGYlPkqtgAAEAAAAAAAAADsAAgAAAAN8AAA AAC2ARIAEgIAAAAAAAAAADQAGAAAAAAAPAA1AABTb2xpY2l0ZWQKVW5zb2xpY2l0ZWQKQnJvYWRj YXN0Ckd1YXJhbnRlZWQgRGVsaXZlcnkKPAAYAAAABwAAAAAAMwAGAAAAAAA0AP9/AAAAAOwAeAAP AATweAAAAKIMCvAIAAAACQgAAAAKAACTAAvwNgAAAIAAqBqJA4sAAgAAAL8ACAAIAFgBAAAAAIEB UAAACIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwABALUACgBLAAIAuwIPAAAAAAAR 8AAAAABdADQAFQASABkACQARQKgaiQOgG4gDAAAAAA0AFgDlQ8j3aklVRIplXtLb3ptAAAC/AAgA AAAAAOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAAHwAYAAAAAAA8ACAAADEgcGVyc29uLyAxMDAg c3FmdAouOCBjZm0vc3EgZnQ8ABgAAAAHAAAAAAASAAYAAAAAAB8A/38AAAAA7AB4AA8ABPB4AAAA ogwK8AgAAAAKCAAAAAoAAJMAC/A2AAAAgAAAG4kDiwACAAAAvwAIAAgAWAEAAAAAgQFQAAAIgwFQ AAAIAQIAAAAAPwIDAAMAvwMCAAIAAAAQ8BIAAAADAAUAxwADAHIABgASAwcAqwAAABHwAAAAAF0A NAAVABIAGQAKABFAABuJAwAciAMAAAAADQAWABaNwlgobjREqrPpNHUdsPMAAL8ACAAAAAAA7AAI AAAADfAAAAAAtgESABICAAAAAAAAAAA2ABgAAAAAADwANwAARWFjaCBUaGVybm9zdGF0IGhhcyA1 MCBvYmplY3RzIHRvIHJlYWQgb25jZSBhIG1pbnV0ZS4KPAAYAAAADQAAAAAANQAGAAAAAAA2AP9/ AAAAAOwAfgAPAATwfgAAAKIMCvAIAAAACwgAAAAKAACjAAvwPAAAAIAAUBuJA4UAAQAAAIsAAgAA AL8ACAAIAFgBAAAAAIEBUAAACIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwAMAOIA BwBVAA4A5QEKALUAAAAR8AAAAABdADQAFQASABkACwARQFAbiQNgHIgDAAAAAA0AFgC4YAE7WJps QbQ4qFltFd4/AACLAAIAAAAAAOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAAgAAYAAAAAAA8AIEA AFRvIHBvbGwgdGhlIHRzdGF0LCB0aGUgTkFFIG11c3Qgc2VuZCBvdXQgMTIgLSAxMjcgYnl0ZSBt ZXNzYWdlIHBlciBtaW51dGUuICBUaGlzIHRyYW5zbGF0ZXMgdG8gMjQgbWVzc2FnZSBkdWUgdG8g ZnJhZ21lbnRhdGlvbi4KPAAYAAAABwAAAAAAfwAGAAAAAACAAP9/AAAAAOwAfgAPAATwfgAAAKIM CvAIAAAADAgAAAAKAACjAAvwPAAAAIAAqBuJA4UAAQAAAIsAAgAAAL8ACAAIAFgBAAAAAIEBUAAA CIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwAQAPAABwDHABIAsAINAIgAAAAR8AAA AABdADQAFQASABkADAARQKgbiQPAHIgDAAAAAA0AFgBZ+upTnqXKTIJoYdKlt3v0AACLAAIAAAAA AOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAAkQAYAAAAAAA8AJIAAENhbGN1bGF0ZWQgYXMgNCBk ZXZpY2VzLCBuZWVkaW5nIDMgc2VnbWVudHMgdG8gcmVwbGl5IHRvIGVhY2ggTkFFIHJlcXVlc3Qu IChBdCB0aGlzIHBvaW50IHdlIGFyZSBhc3N1bWluZyAyNSByZXF1ZXN0cyBwZXIgbWludXRlIHBl ciB0aGVybW9zdGF0Lgo8ABgAAAAHAAAAAACQAAYAAAAAAJEA/38AAAAAHAAbAAEACgAAAAcADwAA IEplcnJ5IE1hcnRvY2NpbhwAGwAEAAQAAAAKAA8AACBKZXJyeSBNYXJ0b2NjaW4cABsABAAPAAAA DAAPAAAgSmVycnkgTWFydG9jY2luHAAbAAgACwAAAAsADwAAIEplcnJ5IE1hcnRvY2NpbhwAGwAL AAAAAAAJAA8AACBKZXJyeSBNYXJ0b2NjaW4+AhIAvgEAAAAAQAAAAAAAAABycgAAiwgQAIsIAAAA AAAAAAAAAAAAcnJBAAoAAQADAAMAAQAAAB0ADwADAAAAAAAAAQAAAAAAAAAdAA8AAQAAAQAAAAEA AAAAAAEBHQAPAAIDAAAAAAABAAMAAwAAAB0ADwAABQAAAAAAAQAFAAgAAADlAKoAFQATABMAAQAF AAAAAAAPABIAAAAAABMAFgABAAEADwAQAAEAAQARABIAAQABABMAFgAAAAAABAAJAAAAAAALAA4A AQABAAQABQABAAEABgAHAAEAAQALAAwAAQABAA0ADgAAAAIAAAAAAAAAAgABAAEAAAACAAIAAgAA AAIAAwADABAAEAABAAUAEQARAAEABQASABIAAQAFAAEAAQAIAAkAAQACAAoACgDvAAYABQC3AwAA ZwgXAGcIAAAAAAAAAAAAAAIAAf////8DRAAACgAAAAkIEAAABhAAqh/NB8EAAQAGBAAACwIUAAAA AAAAAAAAFwAAANOMAAA2nAAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwAC AAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMA AgAAAIQAAgAAACYACAAAAAAAAADoPycACAAAAAAAAADoPygACAAAAAAAAADwPykACAAAAAAAAADw P6EAIgAAAP8AAQABAAEABAACAAH/AAAAAAAA4D8AAAAAAADgPxAAnAgmAJwIAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAVQACAAgAfQAMAAAAAAAkEg8AAgAAAH0ADAABAAIAJAw+ AAIAAAB9AAwAAwADALYLPwACAAAAfQAMAAQABQAACz4AAgAAAH0ADAAGAAYASQw+AAIAAAB9AAwA BwAHANsLPgACAAAAfQAMAAgACQAACz4AAgAAAH0ADAAKAAoAJAo+AAIAAAB9AAwACwALANsKPgAC AAAAfQAMAAwADAC2CT4AAgAAAH0ADAANAA4A2wo+AAIAAAB9AAwAFwAXACQODwACAAAAAAIOAAAA AAAXAAAAAAAYAAAACAIQAAAAAAAYAJUBAAAAAEABDwAIAhAAAQAAABgAlAIAAAAAQAEPAAgCEAAC AAAAGACGAQAAAABAAQ8gCAIQAAMAAAAYAA4BAAAAAAABDxAIAhAABAAAABgA/wAAAAAAAAEPAAgC EAAFAAAAGAD/AAAAAAAAAQ8ACAIQAAYAAAAYAP8AAAAAAAABDwAIAhAABwAAABgA/wAAAAAAAAEP AAgCEAAIAAAAGACyAgAAAAAAAQ8gCAIQAAkAAAAYAP8AAAAAAAABDwAIAhAACgAAABgA/wAAAAAA AAEPAAgCEAALAAAAGAD/AAAAAAAAAQ8ACAIQAAwAAAAYAP8AAAAAAAABDwAIAhAADQAAABgA/wAA AAAAAAEPAAgCEAAOAAAAGAD/AAAAAAAAAQ8ACAIQAA8AAAAYAA4BAAAAAAABDyAIAhAAEAAAAAYA /gEAAAAAQAEPAAgCEAARAAAABgDCAQAAAABAAQ8ACAIQABIAAAAGAJQCAAAAAEABDwAIAhAAEwAA AAYASQIAAAAAQAEPIAgCEAAWAAAABgD/AAAAAAAAAQ8A/QAKAAAAAAB6ABQAAAD9AAoAAAABAHcA AwAAAP0ACgAAAAIAdwANAAAA/QAKAAAAAwB3AAAAAAD9AAoAAAAEAIEADAAAAL4AEgAAAAUAfQB9 AH0AfQCCAEUACgD9AAoAAAALAH0AHgAAAL4ADAAAAAwAfQB9AH4ADgD9AAoAAAAPAH0AIQAAAL4A DAAAABAAfQB9AH4AEgD9AAoAAAATAH0AIgAAAL4ADAAAABQAfQB9AH0AFgD9AAoAAAAXAFsAHwAA AL4ADgABAAAAewB4AHgAeAADAP0ACgABAAQAfwA/AAAAAQIGAAEABQCAAP0ACgABAAYAfwATAAAA AQIGAAEABwCAAP0ACgABAAgAfwASAAAAAQIGAAEACQCAAP0ACgABAAoAgwAIAAAA/QAKAAEACwB/ AA8AAAABAgYAAQAMAIAA/QAKAAEADQB/ABAAAAABAgYAAQAOAIQA/QAKAAEADwB/AA8AAAABAgYA AQAQAIAA/QAKAAEAEQB/ABAAAAABAgYAAQASAIQA/QAKAAEAEwCGACUAAAC+AAwAAQAUAIcAhwCE ABYA/QAKAAEAFwBcACAAAAC+AA4AAgAAAHwAeQB5AHkAAwD9AAoAAgAEAE0ABQAAAP0ACgACAAUA TQAGAAAA/QAKAAIABgBIAAUAAAD9AAoAAgAHAEgABgAAAP0ACgACAAgASAAFAAAA/QAKAAIACQBI AAYAAAABAgYAAgAKAHkA/QAKAAIACwBIAAUAAAD9AAoAAgAMAEgABgAAAP0ACgACAA0ASAAFAAAA /QAKAAIADgBJAAYAAAD9AAoAAgAPAEgABQAAAP0ACgACABAASAAGAAAA/QAKAAIAEQBIAAUAAAD9 AAoAAgASAEkABgAAAP0ACgACABMASAAmAAAA/QAKAAIAFABIACcAAAD9AAoAAgAVAEgAKAAAAP0A CgACABYAUwApAAAA/QAKAAIAFwBdAAUAAAD9AAoAAwAAAEoAAQAAAP0ACgADAAEARgAEAAAA/QAK AAMAAgBGAA4AAAD9AAoAAwADAEYACQAAAH4CCgADAAQAYwAAADhA/QAKAAMABQBkACsAAAB+AgoA AwAGAEYAAABEQP0ACgADAAcAbQA+AAAAvQASAAMACABGAAAAAABGAAAA8D8JAP0ACgADAAoARgAb AAAAvQBOAAMACwBGAAAAAABGAAAAAABGAAAAAABHAAAAAABGAAAAAABGAAAAAABGAAAAAABHAAAA AABGAAAAAABGAAAAAABGAAAAAABOAAAAAAAWAAYAGwADABcAXgAAAAAAAAAAAAgABAAX/wUAAQMA FwC8BBUAAwAIABcXAAYLAEwAAPTATAAA+MAD/QAKAAQAAABLAAIAAAD9AAoABAABAEIABwAAAP0A CgAEAAIAQgARAAAA/QAKAAQAAwBCAAoAAAC9ACoABAAEAGUAAAAAAGUAAAAAAEIAAAAAAEIAAAAA AEIAAAAAAEIAAADwPwkA/QAKAAQACgBGABsAAAC9ADwABAALAEIAAAAAAEIAAAAAAEIAAAAAAEMA AAAAAEYAAAAAAEIAAAAAAEIAAAAAAEMAAAAAAEYAAAAAABMABgAbAAQAFABGAAAAAAAAAAAAAAAJ ABT/BQBEBAALwAYAGwAEABUARgAAAAAAAAAAAAAACQAV/wUARAQAD8B+AgoABAAWAFkAAAAAAAYA GwAEABcAXgAAAAAAAAAAAAgABQAL/wUAAQMAFwD9AAoABQAAAEsAQwAAAP0ACgAFAAEAQgAHAAAA /QAKAAUAAgBCABEAAAD9AAoABQADAEIACgAAAH4CCgAFAAQAZQAAADpA/QAKAAUABQBkACsAAAB+ AgoABQAGAEIAAABEQP0ACgAFAAcAUQA+AAAAvQASAAUACABCAAAAAABCAAAA8D8JAP0ACgAFAAoA RgAbAAAABgAfAAUACwBCAAAAAAAAQHBAAAAFAA//CQBEBQAEwB4KAAX9AAoABQAMAFEAHQAAAH4C CgAFAA0ATwAAwF9A/QAKAAUADgBQABwAAAAGAB8ABQAPAEIAAAAAAAAAOkAAAAUAF/8JAEQFAATA HgEABb0AMAAFABAAUQAAAAAATwAAAE5AUAAAAAAARgAAAEFARgAAgEBARgAAgEBAWgAAAAAAFgAG ABsABQAXAF4AAAAAAADgcUAIAAYAC/8FAAEDABcA/QAKAAYAAABLAEQAAAD9AAoABgABAEIABwAA AP0ACgAGAAIAQgARAAAA/QAKAAYAAwBCAAoAAAC9ABgABgAEAGUAAAAAAGUAAAAAAEIAAEBvQAYA /QAKAAYABwBRAEAAAAC9ABIABgAIAEIAAAAIQEIAAADwPwkA/QAKAAYACgBGABsAAAAGAB8ABgAL AEIAAAAAAAAAAAAAAAkAC/8JAEQGAATAHgoABf0ACgAGAAwAUQAdAAAAfgIKAAYADQBPAADAX0D9 AAoABgAOAFAAHAAAAAYAHwAGAA8AQgAAAAAAAAAAAAAABgAX/wkARAYABMAeAQAFvQAwAAYAEABR AAAAAABPAAAATkBQAAAAAABGAAAAQUBGAACAQEBGAACAQEBaAAAAAAAWAAYAGwAGABcAXgAAAAAA AAAAAAgABwAL/wUAAQMAFwD9AAoABwAAAEsARQAAAP0ACgAHAAEAQgAHAAAA/QAKAAcAAgBCABEA AAD9AAoABwADAEIACgAAAL0AGAAHAAQAZQAAAABAZQAAAAAAQgAAQG9ABgD9AAoABwAHAFEAQAAA AL0AEgAHAAgAQgAAAAhAQgAAAPA/CQD9AAoABwAKAEYAGwAAAAYAHwAHAAsAQgAAAAAAAAA0QAAA BwAP/wkARAcABMAeCgAF/QAKAAcADABRAB0AAAB+AgoABwANAEIAAMBfQP0ACgAHAA4AUAAcAAAA BgAfAAcADwBCAAAAAAAAAABAAAAHABf/CQBEBwAEwB4BAAW9ADAABwAQAFEAAAAAAEIAAABOQFAA AAAAAEYAAABBQEYAAIBAQEYAAIBAQFoAAAAAABYABgAbAAcAFwBeAAAAAAAAADZACAAIAA//BQAB AwAXAP0ACgAIAAAATABGAAAA/QAKAAgAAQBEAAcAAAD9AAoACAACAEQAEQAAAP0ACgAIAAMARAAL AAAAvQAYAAgABABmAAAA8D9mAAAAAABEAABAb0AGAAYAIAAIAAcARAAAAAAAAABZwAAAAwAX/goA HwAAAAAAAFnAEr0AEgAIAAgARAAAAAhARAAAAPA/CQD9AAoACAAKAFQAGwAAAH4CCgAIAAsARAAA APA//QAKAAgADABVAB0AAAB+AgoACAANAEQAAMBfQP0ACgAIAA4AVgAcAAAABgAjAAgADwBEAAAA AAAAgHFAAAAIABf/DQAlBQAHAAvAC8AZEEFBvQAwAAgAEABVAAAAAABEAACAUUBWAAAAAABGAAAA QUBGAACAQEBGAACAQEBaAAAAAAAWAAYAGwAIABcAXwAAAAAAAJBxQAgABAAV/wUAAQMAFwD9AAoA CQAAAEEAHwAAAL4ADAAJAAEAQABAAEAAAwAGACMACQAEAEAAAAAAAACASkAAAAkAF/8NACUDAAgA BMAEwBkQQUG+ABIACQAFAEAAQABAAEAAQABAAAoABgAjAAkACwBAAAAAAAAAkHFAAAAGAA//DQAl AwAIAAvAC8AZEEFBvgAMAAkADABAAEAAQAAOAAYAIwAJAA8AWAAAAAAAAEBzQAAACQAE/w0AJQMA CAAPwA/AGRBBQQYAIwAJABMAVwAAAAAAAABhQAAACQAP/w0AJQMACAATwBPAGRBBQQYAIwAJABQA UgAAAAAAAIBgQAAACQAT/w0AJQMACAAUwBTAGRBBQQYAIwAJABUAUgAAAAAAAIBgQAAABAAU/w0A JQMACAAVwBXAGRBBQQYAIwAJABcAUgAAAAAAAGiCQAAAwAAA/Q0AJQMACAAXwBfAGRBBQb4AJAAK AAAAQQBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAADgABAgYACgAXAFcA/QAKAAsAAABBABUA AAB+AgoACwABAGsAAABZQAECBgALAAIAawD9AAoADAAAAEEAIwAAAH4CCgAMAAEAawCAhA5B/QAK AAwAAgBrACQAAAD9AAoADQAAAEEALQAAAP0ACgANAAEAawAvAAAAAQIGAA0AAgBrAAECBgAOAAAA QQD9AAoAEAABAHQAFwAAAL4ADgAQAAIAdQB1AHUAdgAFAP0ACgARAAEAbgAaAAAAvgAOABEAAgBv AG8AbwBwAAUA/QAKABIAAQBuABgAAAC+AA4AEgACAG8AbwBvAHAABQD9AAoAEwABAHEAGQAAAL4A DgATAAIAcgByAHIAcwAFAP0ACgAWAAAADwAqAAAA1wAuAIsOAACQAcQA9AAmAR4BHwFXAUkBSQFO AVUBMgAmACoAJgAKAAAAIAAgACAAIADCASQACQAIAAEADQQHACoAAwAJAAIACRcEAEAACQAJAAQA CRcXAEAA7ADOAA8AAvDUAQAAMAAI8AgAAAAEAAAABgwAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8H4AAACiDArwCAAAAAQMAAAACgAA owAL8DwAAACAANAfiQOFAAEAAACLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAgBAgAAAAA/ AgMAAwC/AwIAAgAAABDwEgAAAAMACwDKAAAAoQAMAPEDAgB2AAAAEfAAAAAAXQA0ABUAEgAZAAQA EUDQH4kDgB2IAwAAAAANABYAIDCSmn+tkUekiQqejyHeHgAAEAAAAAAAAADsAAgAAAAN8AAAAAC2 ARIAEgIAAAAAAAAAADQAGAAAAAAAPAA1AABTb2xpY2l0ZWQKVW5zb2xpY2l0ZWQKQnJvYWRjYXN0 Ckd1YXJhbnRlZWQgRGVsaXZlcnkKPAAYAAAABwAAAAAAMwAGAAAAAAA0AP9/AAAAAOwAfgAPAATw fgAAAKIMCvAIAAAABQwAAAAKAACjAAvwPAAAAIAAKBA8BIUAAQAAAIsAAgAAAL8ACAAIAFgBAAAA AIEBUAAACIMBUAAACAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwAFAMcABwBpAAYAEgMIAGQA AAAR8AAAAABdADQAFQASABkABQARQCgQPATgHYgDAAAAAA0AFgDQFoUgvdQcTrF8LsvJ9MT9AACL AAIAAAAAAOwACAAAAA3wAAAAALYBEgASAgAAAAAAAAAAFQAYAAAAAAA8ABYAADEgZm9yIGV2ZXJ5 IDQgZmxvb3JzCjwAGAAAAAcAAAAAABQABgAAAAAAFQD/fwAAAADsAHgADwAE8HgAAACiDArwCAAA AAYMAAAACgAAkwAL8DYAAACAAIAQPASLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAgBAgAA AAA/AgMAAwC/AwIAAgAAABDwEgAAAAMAAQC1AAoAaQACALsCDwAcAAAAEfAAAAAAXQA0ABUAEgAZ AAYAEUCAEDwEQB6IAwAAAAANABYAAx/P07smtUupBbaNcQxFmQAAvwAIAAAAAADsAAgAAAAN8AAA AAC2ARIAEgIAAAAAAAAAAB8AGAAAAAAAPAAgAAAxIHBlcnNvbi8gMTAwIHNxZnQKLjggY2ZtL3Nx IGZ0PAAYAAAABwAAAAAAEgAGAAAAAAAfAP9/AAAAABwAGwABAAoAAAAEAA8AACBKZXJyeSBNYXJ0 b2NjaS8cABsACAAEAAAABQAPAAAgSmVycnkgTWFydG9jY2kvHAAbAAsAAAAAAAYADwAAIEplcnJ5 IE1hcnRvY2NpLz4CEgC2AAAAAABAAAAAAAAAAHJyAACLCBAAiwgAAAAAAAAAAAAAAABych0ADwAD BQAAAAAAAQAFAAgAAADlAKoAFQAAAAAAEwAWAAEAAQAPABAAAQABABEAEgABAAEAEwAWAAEAAQAL AAwAEAAQAAEABQARABEAAQAFABIAEgABAAUAEwATAAEABQAAAAAADwASAAEAAQANAA4AAAACAAAA AAAAAAIAAQABAAAAAgACAAIAAAACAAMAAwAAAAAABAAJAAAAAAALAA4AAQABAAQABQABAAEABgAH AAEAAQAIAAkAAQACAAoACgDvAAYABQC3AwAAZwgXAGcIAAAAAAAAAAAAAAIAAf////8DRAAACgAA AAkIEAAABhAAqh/NB8EAAQAGBAAACwIUAAAAAAAAAAAAFwAAAMCiAAD5sQAADQACAAEADAACAGQA DwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAA AAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAACYACAAAAAAAAADoPycACAAAAAAA AADoPygACAAAAAAAAADwPykACAAAAAAAAADwP6EAIgAAAP8AAQABAAEABAACAAH/AAAAAAAA4D8A AAAAAADgPxYAnAgmAJwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAVQACAAgA fQAMAAAAAAAkEg8AAgAAAH0ADAABAAIAJAw+AAIAAAB9AAwAAwADALYLPwACAAAAfQAMAAQABQAA Cz4AAgAAAH0ADAAGAAYASQw+AAIAAAB9AAwABwAHANsLPgACAAAAfQAMAAgACQAACz4AAgAAAH0A DAAKAAoAJAo+AAIAAAB9AAwACwALANsKPgACAAAAfQAMAAwADAC2CT4AAgAAAH0ADAANAA4A2wo+ AAIAAAB9AAwAFwAXACQODwACAAAAAAIOAAAAAAAXAAAAAAAYAAAACAIQAAAAAAAYAJUBAAAAAEAB DwAIAhAAAQAAABgAlAIAAAAAQAEPAAgCEAACAAAAGACGAQAAAABAAQ8gCAIQAAMAAAAYAA4BAAAA AAABDxAIAhAABAAAABgA/wAAAAAAAAEPAAgCEAAFAAAAGAD/AAAAAAAAAQ8ACAIQAAYAAAAYAP8A AAAAAAABDwAIAhAABwAAABgA/wAAAAAAAAEPAAgCEAAIAAAAGACyAgAAAAAAAQ8gCAIQAAkAAAAY AP8AAAAAAAABDwAIAhAACgAAABgA/wAAAAAAAAEPAAgCEAALAAAAGAD/AAAAAAAAAQ8ACAIQAAwA AAAYAP8AAAAAAAABDwAIAhAADQAAABgA/wAAAAAAAAEPAAgCEAAOAAAAGAD/AAAAAAAAAQ8ACAIQ AA8AAAAYAA4BAAAAAAABDyAIAhAAEAAAAAYA/gEAAAAAQAEPAAgCEAARAAAABgDCAQAAAABAAQ8A CAIQABIAAAAGAJQCAAAAAEABDwAIAhAAEwAAAAYASQIAAAAAQAEPIAgCEAAWAAAABgD/AAAAAAAA AQ8A/QAKAAAAAAB6ABQAAAD9AAoAAAABAHcAAwAAAP0ACgAAAAIAdwANAAAA/QAKAAAAAwB3AAAA AAD9AAoAAAAEAIEADAAAAL4AEgAAAAUAfQB9AH0AfQCCAEUACgD9AAoAAAALAH0AHgAAAL4ADAAA AAwAfQB9AH4ADgD9AAoAAAAPAH0AIQAAAL4ADAAAABAAfQB9AH4AEgD9AAoAAAATAH0AIgAAAL4A DAAAABQAfQB9AH0AFgD9AAoAAAAXAFsAHwAAAL4ADgABAAAAewB4AHgAeAADAP0ACgABAAQAfwBB AAAAAQIGAAEABQCAAP0ACgABAAYAfwATAAAAAQIGAAEABwCAAP0ACgABAAgAfwASAAAAAQIGAAEA CQCAAP0ACgABAAoAgwAIAAAA/QAKAAEACwB/AA8AAAABAgYAAQAMAIAA/QAKAAEADQB/ABAAAAAB AgYAAQAOAIQA/QAKAAEADwB/AA8AAAABAgYAAQAQAIAA/QAKAAEAEQB/ABAAAAABAgYAAQASAIQA /QAKAAEAEwCGACUAAAC+AAwAAQAUAIcAhwCEABYA/QAKAAEAFwBcACAAAAC+AA4AAgAAAHwAeQB5 AHkAAwD9AAoAAgAEAE0ABQAAAP0ACgACAAUATQAGAAAA/QAKAAIABgBIAAUAAAD9AAoAAgAHAEgA BgAAAP0ACgACAAgASAAFAAAA/QAKAAIACQBIAAYAAAABAgYAAgAKAHkA/QAKAAIACwBIAAUAAAD9 AAoAAgAMAEgABgAAAP0ACgACAA0ASAAFAAAA/QAKAAIADgBJAAYAAAD9AAoAAgAPAEgABQAAAP0A CgACABAASAAGAAAA/QAKAAIAEQBIAAUAAAD9AAoAAgASAEkABgAAAP0ACgACABMASAAmAAAA/QAK AAIAFABIACcAAAD9AAoAAgAVAEgAKAAAAP0ACgACABYAUwApAAAA/QAKAAIAFwBdAAUAAAD9AAoA AwAAAEoAAQAAAP0ACgADAAEARgAEAAAA/QAKAAMAAgBGAA4AAAD9AAoAAwADAEYACQAAAH4CCgAD AAQAZQAAADVA/QAKAAMABQBkACwAAAB+AgoAAwAGAEYAAAA+QP0ACgADAAcAbQA+AAAAvQASAAMA CABGAAAAAABGAAAAAAAJAP0ACgADAAoARgAbAAAAvQBOAAMACwBGAAAAAABGAAAAAABGAAAAAABH AAAAAABGAAAAAABGAAAAAABGAAAAAABHAAAAAABGAAAAAABGAAAAAABGAAAAAABOAAAAAAAWAAYA GwADABcAXgAAAAAAAAAAAAgABAAX/gUAAQMAFwC8BBUAAwAIABcXAAYLAEwAAPTATAAA+MAD/QAK AAQAAABLAAIAAAD9AAoABAABAEIABwAAAP0ACgAEAAIAQgARAAAA/QAKAAQAAwBCAAoAAAC9ACoA BAAEAGUAAAAAAGUAAAAAAEIAAAAAAEIAAAAAAEIAAAAAAEIAAAAAAAkA/QAKAAQACgBGABsAAAC9 ADwABAALAEIAAAAAAEIAAAAAAEIAAAAAAEMAAAAAAEYAAAAAAEIAAAAAAEIAAAAAAEMAAAAAAEYA AAAAABMABgAbAAQAFABGAAAAAAAAAAAAAAAJABT/BQBEBAALwAYAGwAEABUARgAAAAAAAAAAAAAA CQAV/wUARAQAD8B+AgoABAAWAFkAAAAAAAYAGwAEABcAXgAAAAAAAAAAAAgABQAL/wUAAQMAFwD9 AAoABQAAAEsAQwAAAP0ACgAFAAEAQgAHAAAA/QAKAAUAAgBCABEAAAD9AAoABQADAEIACgAAAL0A GAAFAAQAZQAAABBAZAAAAPA/QgAAwGJABgD9AAoABQAHAFEAQAAAAL0AEgAFAAgAQgAAAAhAQgAA APA/CQD9AAoABQAKAEYAGwAAAAYAHwAFAAsAQgAAAAAAAABEQAAABQAP/wkARAUABMAeCgAF/QAK AAUADABRAB0AAAB+AgoABQANAE8AAMBfQP0ACgAFAA4AUAAcAAAABgAfAAUADwBCAAAAAAAAABBA AAAFABf/CQBEBQAEwB4BAAW9ADAABQAQAFEAAAAAAE8AAABOQFAAAAAAAEYAAABBQEYAAIBAQEYA AIBAQFoAAAAAABYABgAbAAUAFwBeAAAAAAAAAEZACAAGAAv/BQABAwAXAP0ACgAGAAAASwBEAAAA /QAKAAYAAQBCAAcAAAD9AAoABgACAEIAEQAAAP0ACgAGAAMAQgAKAAAAfgIKAAYABABlAAAANED9 AAoABgAFAGQALAAAAH4CCgAGAAYAQgAAAD5A/QAKAAYABwBRAD4AAAC9ABIABgAIAEIAAAAAAEIA AAAAAAkA/QAKAAYACgBGABsAAAAGAB8ABgALAEIAAAAAAAAAaUAAAAkAC/8JAEQGAATAHgoABf0A CgAGAAwAUQAdAAAAfgIKAAYADQBPAADAX0D9AAoABgAOAFAAHAAAAAYAHwAGAA8AQgAAAAAAAAA0 QAAABgAX/wkARAYABMAeAQAFvQAwAAYAEABRAAAAAABPAAAATkBQAAAAAABGAAAAQUBGAACAQEBG AACAQEBaAAAAAAAWAAYAGwAGABcAXgAAAAAAAIBrQAgABwAL/wUAAQMAFwD9AAoABwAAAEsARQAA AP0ACgAHAAEAQgAHAAAA/QAKAAcAAgBCABEAAAD9AAoABwADAEIACgAAAL0AGAAHAAQAZQAAAABA ZQAAAPA/QgAAwGJABgD9AAoABwAHAFEAQAAAAL0AEgAHAAgAQgAAAAhAQgAAAPA/CQD9AAoABwAK AEYAGwAAAAYAHwAHAAsAQgAAAAAAAAA0QAAABwAP/wkARAcABMAeCgAF/QAKAAcADABRAB0AAAB+ AgoABwANAEIAAMBfQP0ACgAHAA4AUAAcAAAABgAfAAcADwBCAAAAAAAAAABAAAAHABf/CQBEBwAE wB4BAAW9ADAABwAQAFEAAAAAAEIAAABOQFAAAAAAAEYAAABBQEYAAIBAQEYAAIBAQFoAAAAAABYA BgAbAAcAFwBeAAAAAAAAADZACAAIAA//BQABAwAXAP0ACgAIAAAATABGAAAA/QAKAAgAAQBEAAcA AAD9AAoACAACAEQAEQAAAP0ACgAIAAMARAALAAAAvQAYAAgABABmAAAA8D9mAAAAAABEAAAAaUAG AP0ACgAIAAcAUQBAAAAAvQASAAgACABEAAAACEBEAAAA8D8JAP0ACgAIAAoAVAAbAAAAfgIKAAgA CwBEAAAA8D/9AAoACAAMAFUAHQAAAH4CCgAIAA0ARAAAwF9A/QAKAAgADgBWABwAAAAGACMACAAP AEQAAAAAAABAcEAAAAgAF/8NACUFAAcAC8ALwBkQQUG9ADAACAAQAFUAAAAAAEQAAIBRQFYAAAAA AEYAAABBQEYAAIBAQEYAAIBAQFoAAAAAABYABgAbAAgAFwBfAAAAAAAAUHBACAAEABX/BQABAwAX AP0ACgAJAAAAQQAfAAAAvgAMAAkAAQBAAEAAQAADAAYAIwAJAAQAQAAAAAAAAABIQAAACQAX/w0A JQMACAAEwATAGRBBQb4AEgAJAAUAQABAAEAAQABAAEAACgAGACMACQALAEAAAAAAAABQcEAAAAYA D/8NACUDAAgAC8ALwBkQQUG+AAwACQAMAEAAQABAAA4ABgAjAAkADwBYAAAAAAAA4HFAAAAJAAT/ DQAlAwAIAA/AD8AZEEFBBgAjAAkAEwBXAAAAAAAAAGFAAAAJAA//DQAlAwAIABPAE8AZEEFBBgAj AAkAFABSAAAAAAAAgGBAAAAJABP/DQAlAwAIABTAFMAZEEFBBgAjAAkAFQBSAAAAAAAAgGBAAAAE ABT/DQAlAwAIABXAFcAZEEFBBgAjAAkAFwBSAAAAAAAAGIFAAADAAAD9DQAlAwAIABfAF8AZEEFB vgAkAAoAAABBAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAAOAAECBgAKABcAVwD9AAoACwAA AEEAFQAAAH4CCgALAAEAPgAAAFlA/QAKAAwAAABBACMAAAB+AgoADAABAD4AgE8CQf0ACgAMAAIA PgAkAAAA/QAKAA0AAABBAC0AAAD9AAoADQABAD4ALgAAAAECBgAOAAAAQQD9AAoAEAABAHQAFwAA AL4ADgAQAAIAdQB1AHUAdgAFAP0ACgARAAEAbgAaAAAAvgAOABEAAgBvAG8AbwBwAAUA/QAKABIA AQBuABgAAAC+AA4AEgACAG8AbwBvAHAABQD9AAoAEwABAHEAGQAAAL4ADgATAAIAcgByAHIAcwAF AP0ACgAWAAAADwAqAAAA1wAuAGEOAACQAcQA9AAmAR4BHwFJAVcBSQE4AVUBMgAcACoAHAAKAAAA IAAgACAAIADCASQABAADAAQACRcXACoAAwAJAAMACRcEAEAABgAJAAIACRcXAEAA7ADOAA8AAvDU AQAAQAAI8AgAAAAEAAAAAxAAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAAAQAAAFAAAADwAE8H4AAACiDArwCAAAAAEQAAAACgAAowAL8DwAAACAAKgUPASF AAEAAACLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAgBAgAAAAA/AgMAAwC/AwIAAgAAABDw EgAAAAMACwDKAAAAoQAMAPEDAgB2AAAAEfAAAAAAXQA0ABUAEgAZAAEAEUCoFDwEAB+IAwAAAAAN ABYAUJZ4xxkMSUqQLLJ0SH5ZYgAAEAAAAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAAADQA GAAAAAAAPAA1AABTb2xpY2l0ZWQKVW5zb2xpY2l0ZWQKQnJvYWRjYXN0Ckd1YXJhbnRlZWQgRGVs aXZlcnkKPAAYAAAABwAAAAAAMwAGAAAAAAA0AP9/AAAAAOwAfgAPAATwfgAAAKIMCvAIAAAAAhAA AAAKAACjAAvwPAAAAIAAABU8BIUAAQAAAIsAAgAAAL8ACAAIAFgBAAAAAIEBUAAACIMBUAAACAEC AAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwAFAMcABwBpAAYAEgMIAGQAAAAR8AAAAABdADQAFQAS ABkAAgARQAAVPARgH4gDAAAAAA0AFgBjKHE4FAZVTb1d21qboU2FAACLAAIAAAAAAOwACAAAAA3w AAAAALYBEgASAgAAAAAAAAAAFQAYAAAAAAA8ABYAADEgZm9yIGV2ZXJ5IDQgZmxvb3JzCjwAGAAA AAcAAAAAABQABgAAAAAAFQD/fwAAAADsAHgADwAE8HgAAACiDArwCAAAAAMQAAAACgAAkwAL8DYA AACAAFAVPASLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAgBAgAAAAA/AgMAAwC/AwIAAgAA ABDwEgAAAAMAAQC1AAoAaQACALsCDwAcAAAAEfAAAAAAXQA0ABUAEgAZAAMAEUBQFTwEAEA6BAAA AAANABYAUvTwkUEEckaAJ/+JEttJFAAAvwAIAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAA AB8AGAAAAAAAPAAgAAAxIHBlcnNvbi8gMTAwIHNxZnQKLjggY2ZtL3NxIGZ0PAAYAAAABwAAAAAA EgAGAAAAAAAfAP9/AAAAABwAGwABAAoAAAABAA8AACBKZXJyeSBNYXJ0b2NjaS8cABsACAAEAAAA AgAPAAAgSmVycnkgTWFydG9jY2kvHAAbAAsAAAAAAAMADwAAIEplcnJ5IE1hcnRvY2NpLz4CEgC2 AAAAAABAAAAAAAAAAHJyAACLCBAAiwgAAAAAAAAAAAAAAABych0ADwADBQAAAAAAAQAFAAgAAADl AKoAFQABAAEACAAJAAEAAQAEAAUAAAAAAAQACQATABMAAQAFAAEAAQATABYAEAAQAAEABQARABEA AQAFABIAEgABAAUAAQABAAsADAABAAEADQAOAAEAAQAPABAAAAACAAAAAAAAAAIAAQABAAAAAgAC AAIAAAACAAMAAwABAAEABgAHAAEAAgAKAAoAAQABABEAEgAAAAAACwAOAAAAAAAPABIAAAAAABMA FgDvAAYABQC3AwAAZwgXAGcIAAAAAAAAAAAAAAIAAf////8DRAAACgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAP7///8FAAAABgAAAAcAAAAIAAAACQAAAP7/ //8LAAAA/v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EI ACsns9kwAAAAtAAAAAcAAAABAAAAQAAAAAQAAABIAAAACAAAAGAAAAASAAAAfAAAAAwAAACUAAAA DQAAAKAAAAATAAAArAAAAAIAAADkBAAAHgAAABAAAAAgSmVycnkgTWFydG9jY2kAHgAAABQAAABK ZXJhbGQgUCBNYXJ0b2NjaQAAAB4AAAAQAAAATWljcm9zb2Z0IEV4Y2VsAEAAAACAv1w/x/3GAUAA AAAAsd6vh6PKAQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAACgBAAAJAAAAAQAAAFAAAAAPAAAA WAAAABcAAAB4AAAACwAAAIAAAAAQAAAAiAAAABMAAACQAAAAFgAAAJgAAAANAAAAoAAAAAwAAAAE AQAAAgAAAOQEAAAeAAAAGAAAAEpvaG5zb24gQ29udHJvbHMsIEluYy4AAAMAAAAAAAwACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAABAAAABsAAABDb21tZXJjaWFsIFJlYWwgRXN0 YXRlLVZNQQAeAAAAQ29tbWVyY2lhbCBSZWFsIEVzdGF0ZS1UaGVybW8ADAAAAEVsZW0gU2Nob29s AAcAAABDbGluaWMADBAAAAIAAAAeAAAACwAAAFdvcmtzaGVldHMAAwAAAAQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////yAIAgAAAAAAwAAAAAAA AEYmAAAATWljcm9zb2Z0IE9mZmljZSBFeGNlbCAyMDAzIFdvcmtzaGVldAAGAAAAQmlmZjgADgAA AEV4Y2VsLlNoZWV0LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACgAAAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --=_mixed 00777AFE862576BD_=-- From joydeep.tripathi@gmail.com Mon Feb 1 14:02:47 2010 Return-Path: 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 04EBF28C0EF for ; Mon, 1 Feb 2010 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] 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 2pr9q9QRJX9h for ; Mon, 1 Feb 2010 14:02:44 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id 5E8673A69AA for ; Mon, 1 Feb 2010 14:02:43 -0800 (PST) Received: by bwz24 with SMTP id 24so941007bwz.29 for ; Mon, 01 Feb 2010 14:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BL72HUF/nLLuFJkfyy4KPR4XU5WD8NLolIzwR/YlgoM=; b=ah48Pz0AZYFDbFDaMFMHgUInxQIpSRRFz6l2LVDtkJfZhZqzwUTFNEgWOlZZ1MFzw7 Gg1IqEyo54zmCoFcwL0CxayZMdts9K3oh9cvIsZ8hYQgqTRjmZEziqlwFT6sL7jvoPCi x3boPVBXAs8Lc45/q9LH8caUoE+5HImrI+EAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Le4xyp77W3YXPk9TsBwiE+tqAuTbPS4HlkAV7fDh/bmX6qWIDwokP2uK/0HWOGICZQ QTzeXSJeGIJYSH6sGXDVaZNZkmD92z9dCrSYhDUU4z2ZmacZAaMYzUK19Jx0Cg4ROBh7 v8z1h/eTsS/U8V3M9v+TwvY4y6qHKmiblk0yo= MIME-Version: 1.0 Received: by 10.204.140.13 with SMTP id g13mr654457bku.96.1265061792659; Mon, 01 Feb 2010 14:03:12 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Feb 2010 17:03:12 -0500 Message-ID: From: Joydeep Tripathi To: Jerald.P.Martocci@jci.com Content-Type: multipart/related; boundary=0015174c3b86c53afc047e9126b6 Cc: ROLL WG Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 22:02:47 -0000 --0015174c3b86c53afc047e9126b6 Content-Type: multipart/alternative; boundary=0015174c3b86c53ae8047e9126b5 --0015174c3b86c53ae8047e9126b5 Content-Type: text/plain; charset=ISO-8859-1 Hi Jerry, Thanks a lot for the information. Currently we are using the same hop distance distribution for building routing. We will use the informations while simulating. Thanks, Joydeep On Mon, Feb 1, 2010 at 4:45 PM, wrote: > > Hi Joydeep, > > Attached is a spreadsheet we developed in 2005 that described the device > density, packet sizes, hops and packet densities into various kinds of > buildings. I think it should answer your questions. It might require a bit > more explanation to make the data obvious. Don't hesitate to write or call. > > Regards, > > Jerry > > > > > > > > > *Joydeep Tripathi * > > 01/31/2010 04:55 PM > To > "jerald.p.martocci" > cc > ROLL WG > Subject > Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in > the home > > > > > > Hi Jerry, > > Thanks a lot for the information you provided on simulation details, we're > making excellent progress on the P2P simulation results which will be posted > soon in the next revision. Could you just tell us which packet size we > should be using and the average number of packets? Then we could provide > with you with actual delay bound for P2P routing. > > Thanks, > Joydeep > > --- On *Tue, 1/26/10, **Jerald.P.Martocci@jci.com* > * <**Jerald.P.Martocci@jci.com* *>* wrote: > > From: *Jerald.P.Martocci@jci.com* <* > Jerald.P.Martocci@jci.com* > > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > To: "JP Vasseur" <*jvasseur@cisco.com* > > Cc: "ROLL WG" <*roll@ietf.org* >, "Mukul Goyal" <* > mukul@UWM.EDU* >, *roll-bounces@ietf.org* > Date: Tuesday, January 26, 2010, 12:20 PM > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if Anders > does not have this requirement for a home, I do have this requirement for a > building. > > 2) My understanding is that for 6LoWPAN networks all devices are on a flat > network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence > there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is no a > priori way to preselect routes. > > Regards, > > Jerry > > > > > *JP Vasseur <**jvasseur@cisco.com* *>* > Sent by: *roll-bounces@ietf.org* > > 01/26/2010 11:01 AM > > To > Mukul Goyal <*mukul@UWM.EDU* > > cc > ROLL WG <*roll@ietf.org* > > Subject > Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > > > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > > > JP, > > > > The obvious problem with proactive approaches, such as RPL, is the > > need to maintain reachability information for all possible > > destinations to which some source might send a packet some day. > > That's why we need source-initiated route discovery, i.e. a reactive > > approach. > > > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "JP Vasseur" <*jvasseur@cisco.com* > > > To: "Anders Brandt" <*abr@sdesigns.dk* > > > Cc: "ROLL WG" <*roll@ietf.org* > > > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > > Central > > Subject: Re: [Roll] RPL Simulation in the home > > > > > > Copying the list to continue that discussion - see below > > > > > > > > Anders> > > > > > > > > > > > > > > > > > > > > > > > > Anyway, > > the use case is quite simple: > > > > Z - R1 - R2 - R3 - A > > > > 1) Lamp module A was recently controlled by controller Z via router > > 1 -> router 2 -> router 3 > > > > Z - R1 - R2 - R3 - A > > > > 2) Something renders the radio connection unusable from router 3 to > > lamp module A > > 3) The lamp module can however be reached via router 1 -> router 4 - > > > router 5 > > but router 5 has never been routing traffic to lamp module A > > > > Z - R1 - R2 - R3 - . > > \ > > - R4 - R5 - A > > 4) Controller Z sends another command to lamp module A via router 1 > > 5) Router 1 sends the command to router 2 which forwards the command > > to router 3 > > 6) Router 3 is unable to deliver the command > > > > What happens now? > > > > > > This is exactly why I was asking you the reason why you think that > > it should be reactive. > > What you describe is routing protocol convergence, which of course > > does not imply that the > > protocol should be reactive. This is a typical case where the > > topology is changing and RPL > > needs to adapt to it, which it does. The way to meet your time > > requirements is to adjust > > the RPL parameters to make it quicker to converge. If there is a > > link between A and R5, > > as soon as it becomes operational, A can send a DAO and R1 will > > direct the traffic to R4 > > instead of R2. > > > > > > > > > > Will the lamp go on within 250ms? > > > > > > > > So you raise the issue of convergence time, fair. It all depends on > > how you tune RPL and A > > selects R5 as a new parent. Note that you do not have to keep > > sending control traffic for > > that. If you links are extremely lossy you will have to make the DAG > > fairly reactive, which > > means more control traffic of course. If you are using a reactive > > mechanism instead of > > proactive, this is not a magic solution either since you flood your > > network and add control > > messages too. > > > > > > What I think is that by using these mechanism you can achieve a good > > level of convergence > > time with reasonable traffic in presence of lossy link w/o too much > > control traffic. We can try > > to quantify if you can provide an example topology, few stats on the > > link flaps trying few RPL > > tuning. Could you ? > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > > > > > > > > > Thanks, > > Anders > > > > > > From: JP Vasseur [ mailto:*jvasseur@cisco.com* ] > > Sent: Thursday, January 21, 2010 09:11 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > > > > > > Sorry JP > > > > I really have no intention of spreading FUD. > > Guess this mainly indicates that I and Jerry need education of what > > RPL is expected/able to deliver. > > > > At the most recent telecon we again touched the issue of e.g. a lamp > > module which due to rf phenomena > > cannot be reached via the recent router - and I thought we had a > > common understanding that some reactive mechanism > > would be needed. > > > > Can RPL - in its current shape - identify a new route via a router > > which did not previously forward traffic to said lamp module? > > > > > > > > Not sure of what you mean by this ? > > > > > > > > > > I would love that but I need to understand how - and I would love to > > see your evidence! > > > > > > > > Here is what I can propose: could you provide a home network > > topology that I could use to provide > > simulations results ? > > > > > > Cheers. > > > > > > JP. > > > > > > > > > > Thanks, > > Anders > > > > > > > > From: JP Vasseur [ mailto:*jvasseur@cisco.com* ] > > Sent: Wednesday, January 20, 2010 18:21 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > > > > > > > > Hi JP > > > >> Are you saying that RPL is not good enough for P2P in home and > >> building? > > > > Well - which incarnation of RPL? (!) > > I was of the impression that we had a common understanding that the > > ability to > > operate in a reactive fasion is critical to home & building and that > > the DAG update > > signaling currently designed will have much bigger delays than the > > 250ms real-time > > users will tolerate. > > > > > > Where does that come from ? > > > > > > > > > > > > > > > >> Since I have evidence that it is not the case. > >> Do you have data that shows different results ? > > > > I may have misunderstood the telecon conclusions, but I got it so > > that over time > > DAG routes will reconstructed, but that the current spec cannot find > > a lost target on demand (?). > > > > > >> Because as you know it is now in our charter to work on other > >> protocols. > > now? I guess you mean "not" ? (!) > > My conclusion from the Rolle interim was that we needed something > > special to find routes across the cloud. > > If the DAG can re-establish contact within 250ms to an operational > > node that was just lost in a routing table, > > I would really love it. Is that the case? > > > > > > mmm I do not think so ... happy to discuss it live with you though. > > > > > > Cheers! > > > > > > JP. > > > > > > > > > > > > > > > > Cheers, > > Anders > > > > > > Fra: JP Vasseur [ mailto:*jvasseur@cisco.com* ] > > Sendt: on 20-01-2010 17:02 > > Til: Anders Brandt > > Emne: Re: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > off-line first. > > > > > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > > > > > > Jerry, > > > >> That was what was nice about an AODV concept, because even route > >> repair was fairly deterministic. > > > > As far as I am informed some reactive discovery mechanism is still > > needed for all the reasons that you list below. > > > > You may remember that we have the same needs in home automation. > > By utilizing the fact that source routing is already used to jump > > between RPL-capable routers AND the fact that the (time critical) > > point-to-point communication is limited to 5 hops or less, some TTL- > > aware, source-route-based AODV hybrid may not cause so > > much flooding as one could fear. > > > > > > > > Are you saying that RPL is not good enough for P2P in home and > > building ? Since I have evidence that it is not the case. > > Do you have data that shows different results ? > > Because as you know it is now in our charter to work on other > > protocols. > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > - Anders > > > > > > > > From: *roll-bounces@ietf.org* [ mailto:* > roll-bounces@ietf.org* ] On > > Behalf Of *Jerald.P.Martocci@jci.com* > > Sent: Thursday, January 14, 2010 19:11 > > To: Joydeep Tripathi > > Cc: ROLL WG > > Subject: Re: [Roll] RPL Simulation > > > > > > > > Hi Joydeep, > > > > Mukul's been doing some simulations for my company for the past 3 > > years. He has a good handle on the commercial building performance > > requirements. It would be good for you to run those he notes > > below. It might be advantageous then for you two to share the > > results to better correlate the simulations. > > > > I would also look at the latency for P2P messages when the packet(s) > > need to traverse the DAG all the way up to the LBR and back down to > > the destination node. Of course, this is now a function on DAG > > depth. Also since all our messages require ACK, the additional > > latency of the ACK having to return possibly through a different set > > of nodes yet via the LBR. That would be the worst case scenario. > > If other nodes could short circuit the packets through a shorter > > path, that would on;y help. > > > > Since Building systems are real-time (smoke/fire detection, turning > > on lights, etc) latency is a big issue. Moving the packet up and > > down the DAG is reasonably deterministic and should be primarily a > > function of the DAG depth. However, what will really affect the > > system performance is 'DAG Repair'. I have no sense how long a > > packet in transit would have to wait if the DAG was under repair. > > Since we require ACKs of every message, the source node would time- > > out and retry a few times (usually 3). After that, the source node > > would have to fall into some 'failsoft' mode depending on the type > > of data it was trying to access. This is not a good situation. The > > source node can only assume that its data is inaccessible, not just > > held up in transit. The fail-soft mode will have large hysteresis > > since it can't be constantly dithering between modes. This will all > > be logged to the operator which is a bad thing!!! That was what was > > nice about an AODV concept, because even route repair was fairly > > deterministic. > > > > So... if your simulation could measure packet latency as a function > > of DAG repair severity, that would be terrific. > > > > Hope this makes sense. > > > > Jerry > > > > > > > > > > > > > > Mukul Goyal < *mukul@uwm.edu* > > > > > 01/13/2010 10:17 AM > > To Joydeep Tripathi < *joydeep.tripathi@gmail.com*> > > > > cc ROLL WG < *roll@ietf.org* >, Jerald > P Martocci < *Jerald.P.Martocci@jci.com* > > > > > > > Subject Re: [Roll] RPL Simulation > > > > > > > > > > Joydeep > > > > Here are a few suggestions for your simulations: > > > > 1. Simulate a 100 node and a 1000 node topology operating under a > > single DAG > > > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > > the DAG from a source to a destination passes through their closest > > common ancestor) and DAG routes through root (all DAG paths have to > > go through the DAG root). > > > > 3. Study the stretch factor (increase in length/cost of routes over > > the DAG versus the length/cost of ideal routes) for given number of > > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > > number of nodes in the topology: > > a) the scenario you suggested: Choose 20% flows over 2 hop > > neighbors, 10% flows over longer paths. > > b) randomly selected source and destinations (in n*(n-1) case, from > > each possible source node to each possible destination node). > > > > 4. In addition to the stretch factor, calculate/simulate the traffic > > loads as well as packet loss/delay along the DAG links. Compare > > these values against values with ideal P2P routing. > > > > Thanks > > Mukul > > ----- Original Message ----- > > From: "Joydeep Tripathi" < *joydeep.tripathi@gmail.com*> > > To: "Jerald P Martocci" < *Jerald.P.Martocci@jci.com*> > > Cc: "ROLL WG" < *roll@ietf.org* > > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > > Central > > Subject: [Roll] RPL Simulation > > > > Hi, > > > > In the next revision, we are also planning to implement a typical > > building routing scenario, where 60-70% of the P2P traffic are > > confined within 1 hop physical distance and, 20% of the P2P traffic > > are to a 2 -hop distance destination, and observe the performance of > > RPL against the ideal shortest route. Also, please let us know if > > there is any other scenario or traffic pattern you want to be > > implemented. > > > > Thanks, > > Joydeep > > _______________________________________________ > > 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 mailing list* > **Roll@ietf.org* * > **https://www.ietf.org/mailman/listinfo/roll* > > > -----Inline Attachment Follows----- > > _______________________________________________ > Roll mailing list* > **Roll@ietf.org* * > **https://www.ietf.org/mailman/listinfo/roll* > > > --0015174c3b86c53ae8047e9126b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jerry,

Thanks a lot for the information. Currently we are using t= he same hop distance distribution for building routing. We will use the inf= ormations while simulating.

Thanks,
Joydeep

On Mon, Feb 1, 2010 at 4:45 PM, <Jerald.P.Martocci@jci.com> wrote:

Hi Joydeep,

Attached is a spreadsheet we devel= oped in 2005 that described the device density, packet sizes, hops and packet densities into various kinds of buildings. =A0I think it should answer your questions. =A0It might require a bit more explanation to make the data obvious. =A0Don't hesitate to write or call.

Regards,

Jerry








Joydeep Tripathi <joydeep.tripathi@gmail.com>

01/31/2010 04:55 PM

To
"jerald.p.martocci"= <jerald.= p.martocci@jci.com>
cc
ROLL WG <= ;roll@ietf.org>
Subject
Re: [Roll] Reactive versus Pr= oactive approaches Re: RPL Simulation in =A0 =A0 =A0 =A0 the home






Hi Jerry,

Thanks a lot for the information you pr= ovided on simulation details, we're mak= ing excellent progress on the P2P=A0simulation results which will be posted soon=A0in the next revision. Could you just tell us which packet size we should be=A0= using and the average number of packets? Then we could provide with you with actual delay bound for P2P routing.=A0

Thanks,
Joydeep

--- On Tue, 1/26/10, Jerald.P.Martocci@jci.com <Jerald.P.Martocci@jci.= com> wrote:

From: Jerald.P.Martocci@jci.com <<= font size=3D"3" color=3D"blue">Jerald.P.Martocci@jci.com<= font size=3D"3">>
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home
To: "JP Vasseur" <jvasseur@cisco.com>
Cc: "ROLL WG" <roll@ietf.org= >, "Mukul Goyal" <mukul@UWM.EDU= >, roll-bounces@ietf.org
Date: Tuesday, January 26, 2010, 12:20 PM

Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes.

Regards,

Jerry <= br>



JP Vasseur <jvasseur@cisco.com<= /font>>
Sent by: = roll-bounces@ietf.or= g

01/26/2010 11:01 AM


To
Mukul Goyal <= ;mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Pr= oactive approaches Re: RPL Simulation =A0 =A0 =A0 =A0in the home







Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the =A0
> need to maintain reachability information for all possible =A0
> destinations to which some source might send a packet some day. =A0 > That's why we need source-initiated route discovery, i.e. a reacti= ve =A0
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive =A0
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvass= eur@cisco.com>
> To: "Anders Brandt" <abr@sde= signs.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =A0 > Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router =A0
> 1 -> router 2 -> router 3
>
> =A0Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to =A0
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 -
> > router 5
> =A0 =A0but router 5 has never been routing traffic to lamp module A
>
> =A0Z - R1 - R2 - R3 - .
> =A0 =A0 =A0 =A0\
> =A0 =A0 =A0 =A0 - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command =A0
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that =A0
> it should be reactive.
> What you describe is routing protocol convergence, which of course =A0
> does not imply that the
> protocol should be reactive. This is a typical case where the =A0
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time =A0
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a =A0 > link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will =A0 > direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on =A0
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep =A0
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG =A0
> fairly reactive, which
> means more control traffic of course. If you are using a reactive =A0
> mechanism instead of
> proactive, this is not a magic solution either since you flood your =A0
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good =A0
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much =A0
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the =A0
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
> =A0Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cis= co.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what =A0
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp =A0
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a =A0 > common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router =A0
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to =A0
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network =A0
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
> =A0Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cis= co.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P =A0in home and =A0
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the =A0
> ability to
> operate in a reactive fasion is critical to home & building and that =A0
> the DAG update
> signaling currently designed will have much bigger delays than the =A0
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so =A0
> that over time
> DAG routes will reconstructed, but that the current spec cannot find =A0
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other =A0
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something =A0
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational =A0
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though. >
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
> =A0Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisc= o.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route =A0
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still =A0
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump =A0
> between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P =A0in home and =A0
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other =A0
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org<= /font> ] On =A0
> Behalf Of Jerald.P.Martocci@jci= .com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3 =A0
> years. =A0He has a good handle on the commercial building performance =A0
> requirements. =A0It would be good for you to run those he notes =A0
> below. =A0It might be advantageous then for you two to share the =A0
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s) =A0
> need to traverse the DAG all the way up to the LBR and back down to =A0
> the destination node. =A0Of course, this is now a function on DAG =A0
> depth. =A0Also since all our messages require ACK, the additional =A0
> latency of the ACK having to return possibly through a different set =A0
> of nodes yet via the LBR. =A0That would be the worst case scenario. =A0
> If other nodes could short circuit the packets through a shorter =A0 > path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning =A0
> on lights, etc) latency is a big issue. =A0Moving the packet up and =A0
> down the DAG is reasonably deterministic and should be primarily a =A0
> function of the DAG depth. =A0However, what will really affect the =A0
> system performance is 'DAG Repair'. =A0I have no sense how lon= g a =A0
> packet in transit would have to wait if the DAG was under repair. =A0
> Since we require ACKs of every message, the source node would time-
> out and retry a few times (usually 3). =A0After that, the source node =A0
> would have to fall into some 'failsoft' mode depending on the = type =A0
> of data it was trying to access. =A0This is not a good situation. =A0The =A0
> source node can only assume that its data is inaccessible, not just =A0
> held up in transit. =A0The fail-soft mode will have large hysteresis =A0
> since it can't be constantly dithering between modes. =A0This will all =A0
> be logged to the operator which is a bad thing!!! =A0That was what was =A0
> nice about an AODV concept, because even route repair was fairly =A0 > deterministic.
>
> So... if your simulation could measure packet latency as a function =A0
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> To =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joydeep Tripathi < joydeep.tripathi@gmai= l.com >
>
> cc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.= P.Martocci@jci.com
> =A0>
>
> Subject =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Re: [Roll] RPL Simulation
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a =A0
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through =A0
> the DAG from a source to a destination passes through their closest =A0
> common ancestor) and DAG routes through root (all DAG paths have to =A0
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over =A0
> the DAG versus the length/cost of ideal routes) for given number of =A0
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =A0
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop =A0
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from =A0
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic =A0
> loads as well as packet loss/delay along the DAG links. Compare =A0 > these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org<= /u> >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =A0
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of
> RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> 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 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

-----Inline Attachment Follows-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/li= stinfo/roll




--0015174c3b86c53ae8047e9126b5-- --0015174c3b86c53afc047e9126b6 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <_2_0EA567D40EA560F000777AFE862576BD> X-Attachment-Id: 0.0.1 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --0015174c3b86c53afc047e9126b6-- From joydeep.tripathi@gmail.com Mon Feb 1 14:02:54 2010 Return-Path: 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 EB7513A69C3 for ; Mon, 1 Feb 2010 14:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 xS0WDzVBTC1J for ; Mon, 1 Feb 2010 14:02:54 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id ACE1F3A69C0 for ; Mon, 1 Feb 2010 14:02:53 -0800 (PST) Received: by mail-bw0-f224.google.com with SMTP id 24so941007bwz.29 for ; Mon, 01 Feb 2010 14:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EokodZu6Qwm2kOSEHOt5UxJe/aNGz09+p1kKdgYrcIM=; b=Ish8DiYgJilie6RpdFgH1fxaUKdMPEKaIfrpZA+617pfUg5cX0myNoVq1C63/TmYrU HCEukoQMCoPde+Db6UtME/n8p8y/kxQ0ZZAvhdUeZnjXALfE7NYo6Lb5VBM/OFg6aoAY w5K6nIKQ86TUacfBuaajNeEZIxmlP+mlo1Rfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MGhP/OrOHIuLAcq0nLgsnFtRNMLgL6DGbITBmA24+1MLQAO10nI1IFW3aKgRvhksbW oxQ+dTnfM2R65RVqmMsc1/9Z6Z3xwttv1zCQ4KFH32cAEhFFZClLD4KBb4OzCPH96Y+S C15Hnl9RoENF16O2sNRwRuI+eio7yiiaNqHtI= MIME-Version: 1.0 Received: by 10.204.36.207 with SMTP id u15mr3155277bkd.187.1265061809419; Mon, 01 Feb 2010 14:03:29 -0800 (PST) In-Reply-To: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> References: <706668471.992211263398457269.JavaMail.root@mail02.pantherlink.uwm.edu> <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 1 Feb 2010 17:03:29 -0500 Message-ID: From: Joydeep Tripathi To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 22:02:55 -0000 Hi MUkul, Thanks a ton for your suggestions. We will definitely try and simulate the scenarios and include the results. Thanks, Joydeep On Wed, Jan 13, 2010 at 11:17 AM, Mukul Goyal wrote: > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a single DAG No need to do now. just use smart meter network. > > 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Mon Feb 1 23:32:55 2010 Return-Path: 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 5C3AA3A6AB9 for ; Mon, 1 Feb 2010 23:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.577 X-Spam-Level: X-Spam-Status: No, score=-9.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 eyjZ+rZ+VhuR for ; Mon, 1 Feb 2010 23:32:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 183B23A6AB4 for ; Mon, 1 Feb 2010 23:32:54 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALBkZ0tAZnwM/2dsb2JhbADABZdehEUEjXQ X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208";a="83450864" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2010 07:33:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o127XUp9023913; Tue, 2 Feb 2010 07:33:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 08:33:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Feb 2010 08:33:24 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on the IPR Thread-Index: AcqjasCJnw0HCkJfQuCeZC0HRRkCZwAa+5RA References: From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Emmanuel Baccelli" X-OriginalArrivalTime: 02 Feb 2010 07:33:29.0824 (UTC) FILETIME=[03F7A600:01CAA3DA] Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 07:32:55 -0000 Hi: Phil: You're so right. It is also my experience that the process of = patenting rapidly escapes the author, and the coverage of the resulting = words is just beyond people like me. I made the exercise of browsing the = claims for the ten+ disclosures listed, and I'm clear that 3 to 6 of = these have an application in RPL. How far that goes I can hardly assert. = I simply think that if some external party comes at any of us in the = future claiming its own IPR against RPL, there's a good probability that = the Cisco IPR makes their attack quite a bit more difficult on a number = of key elements. Emmanuel: 1) is my understanding as well. I talked to our legal team to = try to understand as deeply as I could and my understanding has not = changed. So We're on the exact same line. I just wanted to make it clear = that the Cisco IPR is not only a defense for Cisco; it is also an = umbrella that provides some degree of protection to any group that would = implement RPL. And 3) is my understanding of what JP is asking to the = group at this time. Great summary! So: 3 - if yes, are we OK with these terms? Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Philip Levis Sent: lundi 1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: > Hi JP, >=20 > as discussed, IPR may indeed be difficult to avoid entirely, even = without looming deadlines... If I recall correctly, we are discussing = this because someone claimed that Cisco forces an IPR deal which, = quoting this now famous anonymous, can be summarized by the following: >=20 > "Free license to use the patents in RPL so long as you and your = company don't sue Cisco over any other patent for anything." =20 >=20 > We are engineers, not lawyers, so to understand legal matters, most of = us need such one-liner to understand what is the deal. Therefore in my = mind, the right questions that we need to ask ourselves at this point = are: >=20 > 1 - is the above an accurate summary of the IPR deal imposed by Cisco? > 2 - if no, what is an accurate summary of the IPR deal imposed by = Cisco? > 3 - if yes, are we OK with these terms? >=20 > Let's clarify this and move on quickly, back to protocol design where = we belong! Agreed -- part of the issue here is that I think it's not really = possible for Pascal to describe exactly what the patents cover: he's not = a patent lawyer, and I doubt that Cisco would like him to speak for them = in this regard. My brief interactions with patent law have taught me = that it often works quite differently than engineers might expect. So we = should be careful assuming that we can easily understand the full = situation. :) Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Feb 2 01:26:18 2010 Return-Path: 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 02F8928C22B for ; Tue, 2 Feb 2010 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.857 X-Spam-Level: X-Spam-Status: No, score=-9.857 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 H-J5I-Qv+-x7 for ; Tue, 2 Feb 2010 01:26:17 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1B07528C22A for ; Tue, 2 Feb 2010 01:26:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALJ+Z0utJV2a/2dsb2JhbAC/UpduhEUE X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208";a="294888573" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 09:26:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o129QrmR017727; Tue, 2 Feb 2010 09:26:53 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:47 +0100 Received: from dhcp-lyon-144-254-54-125.cisco.com ([144.254.54.125]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:47 +0100 Message-Id: From: JP Vasseur To: ROLL WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 09:04:56 +0100 References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Feb 2010 09:26:47.0590 (UTC) FILETIME=[D7C06C60:01CAA3E9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17168.004 X-TM-AS-Result: No--26.799200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Adrian Farrel Subject: Re: [Roll] New Design Team to work on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 09:26:18 -0000 Dear all, On Jan 26, 2010, at 12:22 AM, JP Vasseur wrote: > Dear all, > > This is to announce the formation of a new RPL Security Design Team, > made of the following members: > * Tzeta Tsao > * Roger Alexander > * Dave Ward > * Phil Levis > Kris Pister kindly accepted to help there. Thanks Kris. The final DT is thus: * Tzeta Tsao, * roger Alexander * Dave Ward * Phil Levis * Kris Pister Thanks. JP. > Thanks to the four of you for volunteering. > > Rene Struik will help the team as our security advisor. > > As a reminder: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission > * We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... > * All: please provide input to the Design Team and copy the mailing > list. > > Charter > ###### > > The charter of the security design team is to produce a Security > Framework document and the potential routing security extensions to > RPL in the context of that framework (or document how existing > routing mechanisms should be used). With regards to the framework, > the Security DT may choose to use http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt > as a starting point (the document has been presented and discussed > at the last two Working Group meetings). > > Please make sure to be aligned with the ROLL terminology document > and provide input to their authors should new terms be introduced. > > Milestones > ######### > > Milestones are pretty aggressive. > > Feb 10: produce a first draft of Security Framework to be submitted > to the WG for WG adoption > Feb 29: produce a first draft on the potential security extensions > for RPL as a separate document (that may be incorporated in the core > specification of RPL in a second step). > > The Design Team may not be dissolved after the completion of the > security work for RPL as security in routing within LLN may apply to > future specifications produced by the Working Group. > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP and David. > > On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: > >> Dear WG, >> >> I think that we can all be very happy with our progress so far with >> the core specification of RPL. There are still a few open issues >> that we need to solve before IETF-77: >> >> * Detailed DAO mechanisms >> * Detailed mode of operation with multicast >> * Use of Flow Label versus new IPv6 header >> * Potential needed optimization such as DAO packing >> * Editorial work >> * ... >> >> We are on track for all of these. >> >> The one item we absolutely need to speed on is security. As you >> know there is a security framework document that is still not a WG >> document and we now need to start the work on the RPL security >> aspects. To that end, we will form a small Design Team with >> aggressive milestones, the objective being to have the RPL security >> item almost completed by end of Feb, ready for the IETF-77. >> >> If you have a good understanding of RPL and routing security >> expertise, please go back to me (unicast). >> >> Thanks. >> >> JP. >> _______________________________________________ >> 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 From alexandru.petrescu@gmail.com Tue Feb 2 01:50:53 2010 Return-Path: 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 A780328C23E for ; Tue, 2 Feb 2010 01:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Ne1HIEzt46Zj for ; Tue, 2 Feb 2010 01:50:52 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA9E28C0F3 for ; Tue, 2 Feb 2010 01:50:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o129pKi2015317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2010 10:51:20 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o129pJ9N010121; Tue, 2 Feb 2010 10:51:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o129pI2E029287; Tue, 2 Feb 2010 10:51:19 +0100 Message-ID: <4B67F596.10504@gmail.com> Date: Tue, 02 Feb 2010 10:51:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Emmanuel Baccelli , ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 09:50:53 -0000 Cisco IPR protection umbrella to any group implementing IPR? NO! If I implement this stuff I will not need Cisco protection - I will write a different protection, a different licensing scheme. I don't need Cisco licensing to protect me. What I need from Cisco is to interoperate. Take my stance as moderate - as I previously said, I am generally ok with Cisco disclosures at IETF - but I never considered it as a protection umbrella, rather as something that I had to live with. This is also why a second disclosure on RPL, from a competitor would be beneficial. Alex Le 02/02/2010 08:33, Pascal Thubert (pthubert) a écrit : > Hi: > > Phil: You're so right. It is also my experience that the process of > patenting rapidly escapes the author, and the coverage of the > resulting words is just beyond people like me. I made the exercise > of browsing the claims for the ten+ disclosures listed, and I'm > clear that 3 to 6 of these have an application in RPL. How far that > goes I can hardly assert. I simply think that if some external party > comes at any of us in the future claiming its own IPR against RPL, > there's a good probability that the Cisco IPR makes their attack > quite a bit more difficult on a number of key elements. > > Emmanuel: 1) is my understanding as well. I talked to our legal team > to try to understand as deeply as I could and my understanding has > not changed. So We're on the exact same line. I just wanted to make > it clear that the Cisco IPR is not only a defense for Cisco; it is > also an umbrella that provides some degree of protection to any > group that would implement RPL. And 3) is my understanding of what JP > is asking to the group at this time. Great summary! > > So: 3 - if yes, are we OK with these terms? > > Cheers, > > Pascal -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi > 1 février 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: > [Roll] Closing on the IPR > > > On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: > >> Hi JP, >> >> as discussed, IPR may indeed be difficult to avoid entirely, even >> without looming deadlines... If I recall correctly, we are >> discussing this because someone claimed that Cisco forces an IPR >> deal which, quoting this now famous anonymous, can be summarized >> by the following: >> >> "Free license to use the patents in RPL so long as you and your >> company don't sue Cisco over any other patent for anything." >> >> We are engineers, not lawyers, so to understand legal matters, >> most of us need such one-liner to understand what is the deal. >> Therefore in my mind, the right questions that we need to ask >> ourselves at this point are: >> >> 1 - is the above an accurate summary of the IPR deal imposed by >> Cisco? 2 - if no, what is an accurate summary of the IPR deal >> imposed by Cisco? 3 - if yes, are we OK with these terms? >> >> Let's clarify this and move on quickly, back to protocol design >> where we belong! > > Agreed -- part of the issue here is that I think it's not really > possible for Pascal to describe exactly what the patents cover: he's > not a patent lawyer, and I doubt that Cisco would like him to speak > for them in this regard. My brief interactions with patent law have > taught me that it often works quite differently than engineers might > expect. So we should be careful assuming that we can easily > understand the full situation. :) > > Phil > > _______________________________________________ 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 > From jvasseur@cisco.com Tue Feb 2 02:17:20 2010 Return-Path: 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 C0F8328C250 for ; Tue, 2 Feb 2010 02:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.963 X-Spam-Level: X-Spam-Status: No, score=-9.963 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 EyWrskCP0Q3c for ; Tue, 2 Feb 2010 02:17:19 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 69C3A28C24D for ; Tue, 2 Feb 2010 02:17:19 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALOKZ0utJV2Y/2dsb2JhbAC/apd3hEUE X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208,217";a="237070983" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2010 10:17:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o12AHl1x025410; Tue, 2 Feb 2010 10:17:55 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:17:54 +0100 Received: from dhcp-lyon-144-254-54-125.cisco.com ([144.254.54.125]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:17:53 +0100 Message-Id: <56EB87C4-1B5B-488C-83A1-7778135E7D33@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4B67F596.10504@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-281--964261422 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 11:15:47 +0100 References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> <4B67F596.10504@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Feb 2010 10:17:53.0903 (UTC) FILETIME=[FB6AA7F0:01CAA3F0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17168.006 X-TM-AS-Result: No--25.671000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 10:17:20 -0000 --Apple-Mail-281--964261422 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Alex, Just to make sure since we're looking for an answer to the following =20 question: "Given the discussions about the IPR disclosure at = https://datatracker.ietf.org/ipr/1246/=20 and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I =20 would like to make sure that the working group is happy to proceed =20 with draft-ietf-roll-rpl in its current form. Please state your =20 opinions on the list. I will make a consensus call on Friday 11 =20 February. " Are you OK ? Based on what you said I think that the answer is "yes" =20 but I wanted to make sure. Thanks. JP. On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu wrote: > Cisco IPR protection umbrella to any group implementing IPR? > > NO! > > If I implement this stuff I will not need Cisco protection - I will > write a different protection, a different licensing scheme. I don't > need Cisco licensing to protect me. What I need from Cisco is to > interoperate. > > Take my stance as moderate - as I previously said, I am generally ok > with Cisco disclosures at IETF - but I never considered it as a > protection umbrella, rather as something that I had to live with. > > This is also why a second disclosure on RPL, from a competitor would =20= > be > beneficial. > > Alex > > Le 02/02/2010 08:33, Pascal Thubert (pthubert) a =E9crit : >> Hi: >> >> Phil: You're so right. It is also my experience that the process of >> patenting rapidly escapes the author, and the coverage of the >> resulting words is just beyond people like me. I made the exercise >> of browsing the claims for the ten+ disclosures listed, and I'm >> clear that 3 to 6 of these have an application in RPL. How far that >> goes I can hardly assert. I simply think that if some external party >> comes at any of us in the future claiming its own IPR against RPL, >> there's a good probability that the Cisco IPR makes their attack >> quite a bit more difficult on a number of key elements. >> >> Emmanuel: 1) is my understanding as well. I talked to our legal team >> to try to understand as deeply as I could and my understanding has >> not changed. So We're on the exact same line. I just wanted to make >> it clear that the Cisco IPR is not only a defense for Cisco; it is >> also an umbrella that provides some degree of protection to any >> group that would implement RPL. And 3) is my understanding of what JP >> is asking to the group at this time. Great summary! >> >> So: 3 - if yes, are we OK with these terms? >> >> Cheers, >> >> Pascal -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi >> 1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: >> [Roll] Closing on the IPR >> >> >> On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: >> >>> Hi JP, >>> >>> as discussed, IPR may indeed be difficult to avoid entirely, even >>> without looming deadlines... If I recall correctly, we are >>> discussing this because someone claimed that Cisco forces an IPR >>> deal which, quoting this now famous anonymous, can be summarized >>> by the following: >>> >>> "Free license to use the patents in RPL so long as you and your >>> company don't sue Cisco over any other patent for anything." >>> >>> We are engineers, not lawyers, so to understand legal matters, >>> most of us need such one-liner to understand what is the deal. >>> Therefore in my mind, the right questions that we need to ask >>> ourselves at this point are: >>> >>> 1 - is the above an accurate summary of the IPR deal imposed by >>> Cisco? 2 - if no, what is an accurate summary of the IPR deal >>> imposed by Cisco? 3 - if yes, are we OK with these terms? >>> >>> Let's clarify this and move on quickly, back to protocol design >>> where we belong! >> >> Agreed -- part of the issue here is that I think it's not really >> possible for Pascal to describe exactly what the patents cover: he's >> not a patent lawyer, and I doubt that Cisco would like him to speak >> for them in this regard. My brief interactions with patent law have >> taught me that it often works quite differently than engineers might >> expect. So we should be careful assuming that we can easily >> understand the full situation. :) >> >> Phil >> >> _______________________________________________ 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 --Apple-Mail-281--964261422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Alex,

Just to make sure since we're looking for an = answer to the following question: 

"Given = the discussions about the IPR disclosure at https://datatracker.ietf.o= rg/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/polic= y.html I would like to make sure that the working group is = happy to proceed with draft-ietf-roll-rpl in its current form. Please = state your opinions on the list. I will make a consensus call on Friday = 11 February.
"

Are you OK ? Based on = what you said I think that the answer is "yes" but I wanted to make = sure.

Thanks.

JP.
<= div>
On Feb 2, 2010, at 10:51 AM, Alexandru = Petrescu wrote:

Cisco IPR protection umbrella to any group = implementing IPR?

=             &n= bsp;       NO!

If I implement = this stuff I will not need Cisco protection - I will
write a = different protection, a different licensing scheme.  I = don't
need Cisco licensing to protect me.  What I need from = Cisco is to
interoperate.

Take my stance as moderate - as I = previously said, I am generally ok
with Cisco disclosures at IETF - = but I never considered it as a
protection umbrella, rather as = something that I had to live with.

This is also why a second = disclosure on RPL, from a competitor would = be
beneficial.

Alex

Le 02/02/2010 08:33, Pascal Thubert = (pthubert) a =E9crit :
Hi:

Phil: You're so = right. It is also my experience that the process = of
patenting rapidly escapes = the author, and the coverage of the
resulting words is just beyond people like me. I made the = exercise
of browsing the = claims for the ten+ disclosures listed, and = I'm
clear that 3 to 6 of these = have an application in RPL. How far that
goes I can hardly assert. I simply think that if some = external party
comes at any of = us in the future claiming its own IPR against = RPL,
there's a good = probability that the Cisco IPR makes their = attack
quite a bit more = difficult on a number of key elements.

Emmanuel: 1) is = my understanding as well. I talked to our legal = team
to try to understand as = deeply as I could and my understanding has
not changed. So We're on the exact same line. I just = wanted to make
it clear that = the Cisco IPR is not only a defense for Cisco; it = is
also an umbrella that = provides some degree of protection to any
group that would implement RPL. And 3) is my understanding = of what JP
is asking to the = group at this time. Great summary!

So:  3 - = if yes, are we OK with these terms?

Cheers,

Pascal = -----Original Message----- From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] = On Behalf Of Philip Levis Sent: lundi
1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG = Subject: Re:
[Roll] Closing on = the IPR


On Feb 1, 2010, = at 9:35 AM, Emmanuel Baccelli wrote:

Hi JP,

as discussed, IPR may indeed be = difficult to avoid entirely, = even
without looming deadlines... If I recall correctly, we = are
discussing this because someone claimed that Cisco forces = an IPR
deal which, quoting this now famous anonymous, can be = summarized
by the = following:

"Free license to use the patents = in RPL so long as you and your
company don't sue Cisco over any = other patent for anything."

We are engineers, not lawyers, = so to understand legal matters,
most of us need such one-liner = to understand what is the deal.
Therefore in my mind, the right = questions that we need to ask
ourselves at this point = are:

1 - is the above an accurate = summary of the IPR deal imposed = by
Cisco? 2 - if no, what is an accurate summary of the IPR = deal
imposed by Cisco? 3 - if yes, are we OK with these = terms?

Let's clarify this and move on = quickly, back to protocol = design
where we belong!

Agreed -- part = of the issue here is that I think it's not = really
possible for Pascal to = describe exactly what the patents cover: = he's
not a patent lawyer, and = I doubt that Cisco would like him to speak
for them in this regard. My brief interactions with patent = law have
taught me that it = often works quite differently than engineers = might
expect. So we should be = careful assuming that we can easily
understand the full situation. = :)

Phil

_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll



___________________________________= ____________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-281--964261422-- From jvasseur@cisco.com Tue Feb 2 02:18:26 2010 Return-Path: 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 C46D728C24E for ; Tue, 2 Feb 2010 02:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=-3.407, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sYlgtMT+Ffut for ; Tue, 2 Feb 2010 02:18:25 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3E11128C24A for ; Tue, 2 Feb 2010 02:18:20 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkBAOKKZ0uQ/uCWe2dsb2JhbACbSgEBFiQGo2KXd4RFBA X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208,217";a="2989687" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2010 09:48:30 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o12AIukw021750; Tue, 2 Feb 2010 10:18:56 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:18:56 +0100 Received: from dhcp-lyon-144-254-54-125.cisco.com ([144.254.54.125]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:18:55 +0100 Message-Id: <9CAA4EF7-805F-4382-ADB2-23419267ECBB@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4B67F596.10504@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-284--964136985 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 11:17:51 +0100 References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> <4B67F596.10504@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Feb 2010 10:18:55.0637 (UTC) FILETIME=[20368450:01CAA3F1] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17168.006 X-TM-AS-Result: No--25.671000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 10:18:26 -0000 --Apple-Mail-284--964136985 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Alex, Just to make sure since we're looking for an answer to the following =20 question: "Given the discussions about the IPR disclosure at = https://datatracker.ietf.org/ipr/1246/=20 and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I =20 would like to make sure that the working group is happy to proceed =20 with draft-ietf-roll-rpl in its current form. Please state your =20 opinions on the list. I will make a consensus call on Friday 11 =20 February. " Are you OK ? Based on what you said I think that the answer is "yes" =20 but I wanted to make sure. Thanks. JP. On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu wrote: > Cisco IPR protection umbrella to any group implementing IPR? > > NO! > > If I implement this stuff I will not need Cisco protection - I will > write a different protection, a different licensing scheme. I don't > need Cisco licensing to protect me. What I need from Cisco is to > interoperate. > > Take my stance as moderate - as I previously said, I am generally ok > with Cisco disclosures at IETF - but I never considered it as a > protection umbrella, rather as something that I had to live with. > > This is also why a second disclosure on RPL, from a competitor would =20= > be > beneficial. > > Alex > > Le 02/02/2010 08:33, Pascal Thubert (pthubert) a =E9crit : >> Hi: >> >> Phil: You're so right. It is also my experience that the process of >> patenting rapidly escapes the author, and the coverage of the >> resulting words is just beyond people like me. I made the exercise >> of browsing the claims for the ten+ disclosures listed, and I'm >> clear that 3 to 6 of these have an application in RPL. How far that >> goes I can hardly assert. I simply think that if some external party >> comes at any of us in the future claiming its own IPR against RPL, >> there's a good probability that the Cisco IPR makes their attack >> quite a bit more difficult on a number of key elements. >> >> Emmanuel: 1) is my understanding as well. I talked to our legal team >> to try to understand as deeply as I could and my understanding has >> not changed. So We're on the exact same line. I just wanted to make >> it clear that the Cisco IPR is not only a defense for Cisco; it is >> also an umbrella that provides some degree of protection to any >> group that would implement RPL. And 3) is my understanding of what JP >> is asking to the group at this time. Great summary! >> >> So: 3 - if yes, are we OK with these terms? >> >> Cheers, >> >> Pascal -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi >> 1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: >> [Roll] Closing on the IPR >> >> >> On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: >> >>> Hi JP, >>> >>> as discussed, IPR may indeed be difficult to avoid entirely, even >>> without looming deadlines... If I recall correctly, we are >>> discussing this because someone claimed that Cisco forces an IPR >>> deal which, quoting this now famous anonymous, can be summarized >>> by the following: >>> >>> "Free license to use the patents in RPL so long as you and your >>> company don't sue Cisco over any other patent for anything." >>> >>> We are engineers, not lawyers, so to understand legal matters, >>> most of us need such one-liner to understand what is the deal. >>> Therefore in my mind, the right questions that we need to ask >>> ourselves at this point are: >>> >>> 1 - is the above an accurate summary of the IPR deal imposed by >>> Cisco? 2 - if no, what is an accurate summary of the IPR deal >>> imposed by Cisco? 3 - if yes, are we OK with these terms? >>> >>> Let's clarify this and move on quickly, back to protocol design >>> where we belong! >> >> Agreed -- part of the issue here is that I think it's not really >> possible for Pascal to describe exactly what the patents cover: he's >> not a patent lawyer, and I doubt that Cisco would like him to speak >> for them in this regard. My brief interactions with patent law have >> taught me that it often works quite differently than engineers might >> expect. So we should be careful assuming that we can easily >> understand the full situation. :) >> >> Phil >> >> _______________________________________________ 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 --Apple-Mail-284--964136985 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Alex,

Just to make sure since we're looking for an = answer to the following question: 

"Given = the discussions about the IPR disclosure at https://datatracker.ietf.o= rg/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/polic= y.html I would like to make sure that the working group is = happy to proceed with draft-ietf-roll-rpl in its current form. Please = state your opinions on the list. I will make a consensus call on Friday = 11 February.
"

Are you OK ? Based on = what you said I think that the answer is "yes" but I wanted to make = sure.

Thanks.

JP.
<= div>
On Feb 2, 2010, at 10:51 AM, Alexandru = Petrescu wrote:

Cisco IPR protection umbrella to any group = implementing IPR?

=             &n= bsp;       NO!

If I implement = this stuff I will not need Cisco protection - I will
write a = different protection, a different licensing scheme.  I = don't
need Cisco licensing to protect me.  What I need from = Cisco is to
interoperate.

Take my stance as moderate - as I = previously said, I am generally ok
with Cisco disclosures at IETF - = but I never considered it as a
protection umbrella, rather as = something that I had to live with.

This is also why a second = disclosure on RPL, from a competitor would = be
beneficial.

Alex

Le 02/02/2010 08:33, Pascal Thubert = (pthubert) a =E9crit :
Hi:

Phil: You're so = right. It is also my experience that the process = of
patenting rapidly escapes = the author, and the coverage of the
resulting words is just beyond people like me. I made the = exercise
of browsing the = claims for the ten+ disclosures listed, and = I'm
clear that 3 to 6 of these = have an application in RPL. How far that
goes I can hardly assert. I simply think that if some = external party
comes at any of = us in the future claiming its own IPR against = RPL,
there's a good = probability that the Cisco IPR makes their = attack
quite a bit more = difficult on a number of key elements.

Emmanuel: 1) is = my understanding as well. I talked to our legal = team
to try to understand as = deeply as I could and my understanding has
not changed. So We're on the exact same line. I just = wanted to make
it clear that = the Cisco IPR is not only a defense for Cisco; it = is
also an umbrella that = provides some degree of protection to any
group that would implement RPL. And 3) is my understanding = of what JP
is asking to the = group at this time. Great summary!

So:  3 - = if yes, are we OK with these terms?

Cheers,

Pascal = -----Original Message----- From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] = On Behalf Of Philip Levis Sent: lundi
1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG = Subject: Re:
[Roll] Closing on = the IPR


On Feb 1, 2010, = at 9:35 AM, Emmanuel Baccelli wrote:

Hi JP,

as discussed, IPR may indeed be = difficult to avoid entirely, = even
without looming deadlines... If I recall correctly, we = are
discussing this because someone claimed that Cisco forces = an IPR
deal which, quoting this now famous anonymous, can be = summarized
by the = following:

"Free license to use the patents = in RPL so long as you and your
company don't sue Cisco over any = other patent for anything."

We are engineers, not lawyers, = so to understand legal matters,
most of us need such one-liner = to understand what is the deal.
Therefore in my mind, the right = questions that we need to ask
ourselves at this point = are:

1 - is the above an accurate = summary of the IPR deal imposed = by
Cisco? 2 - if no, what is an accurate summary of the IPR = deal
imposed by Cisco? 3 - if yes, are we OK with these = terms?

Let's clarify this and move on = quickly, back to protocol = design
where we belong!

Agreed -- part = of the issue here is that I think it's not = really
possible for Pascal to = describe exactly what the patents cover: = he's
not a patent lawyer, and = I doubt that Cisco would like him to speak
for them in this regard. My brief interactions with patent = law have
taught me that it = often works quite differently than engineers = might
expect. So we should be = careful assuming that we can easily
understand the full situation. = :)

Phil

_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________ Roll = mailing list
Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll



___________________________________= ____________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-284--964136985-- From alexandru.petrescu@gmail.com Tue Feb 2 02:29:33 2010 Return-Path: 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 9450D28C25F for ; Tue, 2 Feb 2010 02:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 HsDPVJvA1Zin for ; Tue, 2 Feb 2010 02:29:32 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 35A1B28C259 for ; Tue, 2 Feb 2010 02:29:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o12AU4pE021595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2010 11:30:04 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o12AU4Dj026301; Tue, 2 Feb 2010 11:30:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o12AU37U017861; Tue, 2 Feb 2010 11:30:04 +0100 Message-ID: <4B67FEAB.6030405@gmail.com> Date: Tue, 02 Feb 2010 11:30:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: JP Vasseur References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> <4B67F596.10504@gmail.com> <9CAA4EF7-805F-4382-ADB2-23419267ECBB@cisco.com> In-Reply-To: <9CAA4EF7-805F-4382-ADB2-23419267ECBB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 10:29:33 -0000 Hi JP, Le 02/02/2010 11:17, JP Vasseur a écrit : > Hi Alex, > > Just to make sure since we're looking for an answer to the following > question: > > "Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at > http://www.ietf.org/ipr/policy.html I would like to make sure that > the working group is happy to proceed with draft-ietf-roll-rpl in > its current form. Please state your opinions on the list. I will make > a consensus call on Friday 11 February. " > > Are you OK ? Based on what you said I think that the answer is "yes" > but I wanted to make sure. On my side I am ok with the questions above. The WG as whole - your draw. Alex > Thanks. > > JP. > > On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu wrote: > >> Cisco IPR protection umbrella to any group implementing IPR? >> >> NO! >> >> If I implement this stuff I will not need Cisco protection - I will >> write a different protection, a different licensing scheme. I don't >> need Cisco licensing to protect me. What I need from Cisco is to >> interoperate. >> >> Take my stance as moderate - as I previously said, I am generally >> ok with Cisco disclosures at IETF - but I never considered it as a >> protection umbrella, rather as something that I had to live with. >> >> This is also why a second disclosure on RPL, from a competitor >> would be beneficial. >> >> Alex >> >> Le 02/02/2010 08:33, Pascal Thubert (pthubert) a écrit : >>> Hi: >>> >>> Phil: You're so right. It is also my experience that the process >>> of patenting rapidly escapes the author, and the coverage of the >>> resulting words is just beyond people like me. I made the >>> exercise of browsing the claims for the ten+ disclosures listed, >>> and I'm clear that 3 to 6 of these have an application in RPL. >>> How far that goes I can hardly assert. I simply think that if >>> some external party comes at any of us in the future claiming >>> its own IPR against RPL, there's a good probability that the >>> Cisco IPR makes their attack quite a bit more difficult on a >>> number of key elements. >>> >>> Emmanuel: 1) is my understanding as well. I talked to our legal >>> team to try to understand as deeply as I could and my >>> understanding has not changed. So We're on the exact same line. >>> I just wanted to make it clear that the Cisco IPR is not only a >>> defense for Cisco; it is also an umbrella that provides some >>> degree of protection to any group that would implement RPL. And >>> 3) is my understanding of what JP is asking to the group at this >>> time. Great summary! >>> >>> So: 3 - if yes, are we OK with these terms? >>> >>> Cheers, >>> >>> Pascal -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On >>> Behalf Of Philip Levis Sent: lundi 1 février 2010 19:17 To: >>> Emmanuel Baccelli Cc: ROLL WG Subject: Re: [Roll] Closing on the >>> IPR >>> >>> >>> On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: >>> >>>> Hi JP, >>>> >>>> as discussed, IPR may indeed be difficult to avoid entirely, >>>> even without looming deadlines... If I recall correctly, we are >>>> discussing this because someone claimed that Cisco forces an >>>> IPR deal which, quoting this now famous anonymous, can be >>>> summarized by the following: >>>> >>>> "Free license to use the patents in RPL so long as you and your >>>> company don't sue Cisco over any other patent for anything." >>>> >>>> We are engineers, not lawyers, so to understand legal matters, >>>> most of us need such one-liner to understand what is the deal. >>>> Therefore in my mind, the right questions that we need to ask >>>> ourselves at this point are: >>>> >>>> 1 - is the above an accurate summary of the IPR deal imposed by >>>> Cisco? 2 - if no, what is an accurate summary of the IPR deal >>>> imposed by Cisco? 3 - if yes, are we OK with these terms? >>>> >>>> Let's clarify this and move on quickly, back to protocol design >>>> where we belong! >>> >>> Agreed -- part of the issue here is that I think it's not really >>> possible for Pascal to describe exactly what the patents cover: >>> he's not a patent lawyer, and I doubt that Cisco would like him >>> to speak for them in this regard. My brief interactions with >>> patent law have taught me that it often works quite differently >>> than engineers might expect. So we should be careful assuming >>> that we can easily understand the full situation. :) >>> >>> Phil >>> >>> _______________________________________________ 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 > From Adrian.Farrel@huawei.com Tue Feb 2 05:30:47 2010 Return-Path: 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 D1D9228C0EB for ; Tue, 2 Feb 2010 05:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, STOX_REPLY_TYPE=0.001] 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 8aA0h7C3iG7P for ; Tue, 2 Feb 2010 05:30:47 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 05B3428C0E9 for ; Tue, 2 Feb 2010 05:30:47 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX7007PJUWCW7@usaga01-in.huawei.com> for roll@ietf.org; Tue, 02 Feb 2010 05:31:24 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX700DK9UWAZT@usaga01-in.huawei.com> for roll@ietf.org; Tue, 02 Feb 2010 05:31:24 -0800 (PST) Date: Tue, 02 Feb 2010 13:28:02 +0000 From: Adrian Farrel To: roll@ietf.org Message-id: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [Roll] An AD Comments on IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 13:30:47 -0000 Hi, I can understand people's frustration with the nature of IPR claims and disclosures. However, while you can ask anyone to give you advice about what is covered by a claim, and what the IPR terms actually mean, this is ultimately a question that must be handled as an individual issue by you, or as a corporate issue by your legal advisers. You would be poorly advised to rely on the advice of an individual on this list, whatever their technical or legal qualifications. JP's question is intended to allow you to state your opinions so that he can judge working group consensus. He asked: > Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR > policy at http://www.ietf.org/ipr/policy.html I would like > to make sure that the working group is happy to proceed > with draft-ietf-roll-rpl in its current form. Please state your > opinions on the list. I will make a consensus call on Friday > 11 February. [We can probably assume that he means Friday 12 February :-)] In answering this question you need to say "yes, let's go ahead" or "no, we have to take steps to avoid the IPR". Your reasons for holding a position may be helpful to others and to the chairs in finding the way forward. By way of background, the IETF has always attempted to find unencumbered technical solutions, but there is a general recognition that very few specifications reach RFC status without the possibility of some IPR claim at some time. By requiring IETF participants to disclose IPR, the IETF is seeking to enable informed decisions why its participants, and this helps to avoid claims of entrapment. It should be noted that the absence of an IPR disclosure is not a guarantee that no IPR exists, but the presence of a disclosure allows everyone to see the licensing terms. In deciding whether to support or deny continuation of technical work in the presence of an IPR disclosure, individuals (or their companies) will want to consider whether they think the IPR actually covers the technical work, whether it is enforceable, and whether they consider the licensing terms to be favourable. They will also need to consider the cost-benefit of the various options that exist. No-one else can make these decisions for you! May I also take this opportunity to ask you all to look at the IETF's IPR policy. In particular, can I remind you all about the policy with respect to IPR that you know about as described in RFC 3979 and RFC 4879. All document authors and contributors to discussions need to be aware of their personal commitments to disclose IPR as expressed in those two RFCs. Thanks, Adrian From root@core3.amsl.com Wed Feb 3 03:30:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA8493A6C20; Wed, 3 Feb 2010 03:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100203113001.BA8493A6C20@core3.amsl.com> Date: Wed, 3 Feb 2010 03:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 11:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-06.txt Pages : 82 Date : 2010-02-03 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of LLN routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint-to-point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-03032812.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Wed Feb 3 09:48:21 2010 Return-Path: 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 E418528C0E3 for ; Wed, 3 Feb 2010 09:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 yWYyRzdpcVgv for ; Wed, 3 Feb 2010 09:48:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 132A928C174 for ; Wed, 3 Feb 2010 09:48:19 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAOVFaUurRN+J/2dsb2JhbACBbL5GmBaERQQ X-IronPort-AV: E=Sophos;i="4.49,399,1262563200"; d="scan'208,217";a="83177371" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2010 17:49:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o13Hn16q006631 for ; Wed, 3 Feb 2010 17:49:02 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 11:49:01 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 11:49:00 -0600 Message-Id: <332FB434-344B-4851-957E-FBBA4E642B8B@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-419--850669091 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Feb 2010 18:48:59 +0100 References: <20100203173153.864F928C0F7@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Feb 2010 17:49:00.0969 (UTC) FILETIME=[2B0EE990:01CAA4F9] Subject: [Roll] Fwd: Revised Guidelines to Authors of Internet-Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 17:48:22 -0000 --Apple-Mail-419--850669091 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IESG Secretary > Date: February 3, 2010 6:31:53 PM CEST > To: IETF Announcement list > Subject: Revised Guidelines to Authors of Internet-Drafts > > An updated version of the Guidelines to Authors of Internet-Drafts > is now > available and has been posted on the IETF website: > > http://www.ietf.org/id-info/guidelines.html OR > http://www.ietf.org/id-info/1id-guidelines.txt > > Summary of changes in this version: > > o Update the references to reflect the current BCPs. Remove the > reference to rfc2333bis, which is no longer an active work item. > Add a references for the I-D Submission Tool and the Data Tracker. > > o Rewrite of Section 3. > > o Structure the choices in Section 4 to match the current BCPs. > > o Provide two boilerplate options in Section 5, as approved by the > IESG on 7 January 2010. > > o Remove the discussion of grace period from Section 7. With the > I-D Submission Tool, there is no longer a need for one. > > o Include URLs that are not redirected. > > o Significant editorial changes. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-419--850669091 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Date: February 3, 2010 6:31:53 PM = CEST
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: Revised Guidelines to Authors of = Internet-Drafts 

An updated = version of the Guidelines to Authors of Internet-Drafts is = now
available and has been posted on the IETF website:

=  http://www.ietf.org/i= d-info/guidelines.html  OR
 http://www.ietf.or= g/id-info/1id-guidelines.txt

Summary of changes in this = version:

o Update the references to reflect the current BCPs. = Remove the
 reference to rfc2333bis, which is no longer an = active work item.
 Add a references for the I-D Submission Tool = and the Data Tracker.

o Rewrite of Section 3.

o Structure = the choices in Section 4 to match the current BCPs.

o Provide two = boilerplate options in Section 5, as approved by the
 IESG on 7 = January 2010.

o Remove the discussion of grace period from = Section 7. With the
 I-D Submission Tool, there is no longer a = need for one.

o Include URLs that are not redirected.

o = Significant editorial = changes.
_______________________________________________
IETF-Announ= ce mailing list
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-419--850669091-- From wintert@acm.org Thu Feb 4 05:39:39 2010 Return-Path: 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 DB2D528C1A0 for ; Thu, 4 Feb 2010 05:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 B0fdLlV+UhtH for ; Thu, 4 Feb 2010 05:39:39 -0800 (PST) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id BD8D23A691E for ; Thu, 4 Feb 2010 05:39:38 -0800 (PST) Received: (qmail 25634 invoked from network); 4 Feb 2010 13:40:22 -0000 Received: from 67-197-171-92.dyn.comporium.net (wintert@67.197.171.92 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 04 Feb 2010 05:40:22 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: jd4FbAoVM1ke0yKZqmV6tZb3FTUZwjq2XoGOfRNa1rzw2xFRetRwCoedP_rRneXpdRyzTiIIjLrd1MmJZIjfMDGeHhhBdIAM1_NWvlqWRnJhZH99DawF5n_H.sHuo7MYBhb5T6DeGZaHT6TEIW7sdeID82SowW6wSFV0RaQsHPZZqqqAvg5k0IvywRUCkAZMx_oTZMrdg3ZiNAZMWD0rYlRCmB9ciRrYSXJiMPNVhgoTSNJRnDYBveCL.sZ4dqPzFd5x0xpTy4Y7t6TSJoS8AOvBQ61CitIUTCm6gZuDho4rhQfPDnqbwMujLATwJTvBbPdJoWSUFWmRCwB5LwjW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B6ACE45.7040509@acm.org> Date: Thu, 04 Feb 2010 08:40:21 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <20100203113001.BA8493A6C20@core3.amsl.com> In-Reply-To: <20100203113001.BA8493A6C20@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:39:39 -0000 WG, In this revision changes include: - editorial improvements - terminology - section 3 - breaking out Protocol Specification into separate sections - text for a proposed downward route mechanism (section 6) - more flexible rank (see 3.6.2.1) Please do continue to provide your feedback to the list Thanks, -RPL Authors Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-06.txt > Pages : 82 > Date : 2010-02-03 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to-point traffic > (between devices inside the LLN), point-to-multipoint traffic (from a > central control point to a subset of devices inside the LLN) and > multipoint-to-point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Feb 4 07:46:10 2010 Return-Path: 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 3043628C1AC for ; Thu, 4 Feb 2010 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 xpwcpYQRDzyZ for ; Thu, 4 Feb 2010 07:46:09 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0FDA83A6C4E for ; Thu, 4 Feb 2010 07:46:08 -0800 (PST) Received: from sandelman.ottawa.on.ca (66-78-101-1.access.ripnet.com [66.78.101.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 9749134366; Thu, 4 Feb 2010 10:40:27 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4A3224E80D; Thu, 4 Feb 2010 03:23:45 -0500 (EST) From: Michael Richardson To: IETF ROLL In-Reply-To: <4B66EDE1.4010501@ekasystems.com> References: <6986.1264989792@marajade.sandelman.ca> <4B66EDE1.4010501@ekasystems.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 04 Feb 2010 03:23:45 -0500 Message-ID: <21865.1265271825@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] sequence number increment and wrap X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:46:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Tzeta" == Tzeta Tsao writes: Tzeta> Indeed, replay protection can be a deceptively simple Tzeta> problem. For example, here is a security analysis on 802.15.4 Tzeta> and it has a lot to say about 15.4's Access Control List, Tzeta> which is based on a counter: Tzeta> http://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf. Tzeta> Maintaining a counter for every neighbor may present a Tzeta> problem for some devices. Suppose one uses MiniSec's Yes, it certainly is a problem. Tzeta> approach: Tzeta> http://sparrow.ece.cmu.edu/group/pub/luk_mezzour_perrig_miniSec.pdf. In Tzeta> this case, a device sends one-byte counter in the message for Tzeta> sync but actually keeps a multi-byte counter per neighbor: in Tzeta> many situations it will wind up needing a few k bytes. That's the method that RFC4301 (IPSEC) style ESP uses to get 64-bit replay counters for very high speed networks, where a 32-bit replay counters rolls in a matter of minutes. A counter roll otherwise causes a rekey. In the case of RPL, the SequenceNumber in the DAG header in the DIO is incremented only when there is some material change to the network. I'm not yet clear what this might be --- the information is, however, retransmitted multiple times by the DAG root (and subsequent nodes). When the information changes, there is a new SequenceNumber, which causes a DAG Iteration, and nodes have to re-evaluate their situation, moving to the new DAG Iteration in an organized way. I'm pretty sure that the subsequent nodes need to add/modify to the DIO as it it passed out --- I do not think the L4 payload can be just resent. (Clearly the L2 and L3 information changes). That is, any authentication placed on the packet has to be recalculated by each node on a hop-by-hop basis. This is important, because it implies that there are many messages which can be replayed, and each one needs some seperate tracking. But, so far nobody has answered my key question: what happens to a DAG at Iteration N when information from DAG Iteration then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS2qED4CLcPvd0N1lAQKNsQgAkS3tOPpgGO8JVuxkjMPXf1iJMEoYOdHy 7rF4uj5Jmv92uceI2Kejcj9zJqio7R45k8M+9iM2o2GdP5ZVoVCDF5zdvt3cOlkk dIGeRnTWa6db2BuF0NzJuYRvYv//2DNVk5TS8bt4ZQ/h7WVdHdj+75OUJPoTt9NR ztkh0EO8yVVW1wet3ScNkjfOV1YBEXdAPqODEzgtMmV68ev6yJsdltf7c6hpi20C XfcK6bTRf0IbeGDQsJTSnSKXQ2liOrhCJAdWvfO/6i+99T4fyHN8ay2WCpUr2n63 4AMpVjdNBkw6EAIGctOzS4m7i9syus+6ZgVf9IleEL4EhNkOVl2j3w== =XRmK -----END PGP SIGNATURE----- From pister@eecs.berkeley.edu Thu Feb 4 11:34:41 2010 Return-Path: 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 8E9E728C19D for ; Thu, 4 Feb 2010 11:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 hA1P2ZIpZE2s for ; Thu, 4 Feb 2010 11:34:40 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id B36363A6BD9 for ; Thu, 4 Feb 2010 11:34:40 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o14JZOvm026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 11:35:25 -0800 (PST) Message-ID: <4B6B217B.908@eecs.berkeley.edu> Date: Thu, 04 Feb 2010 11:35:23 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adrian Farrel References: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> In-Reply-To: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] An AD Comments on IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 19:34:41 -0000 Yes, let's go ahead. For what it's worth, this will not be the last time someone discloses IP related to RPL or sensor networks in general. Cisco's policies are well known, and in my opinion quite reasonable. Other IP is likely to be disclosed in a friendly letter as soon as someone perceives that you are making a profit. To quote Casablanca (Peter Lorre?): There are vultures, vultures everywhere! I can't count the number of times that I've been approached after a talk by someone who says "you know, I've got the fundamental patent that covers that". I've heard so many people claim that they are the ones who patented combining a microprocessor/sensor/radio that it makes me wonder if the patent office isn't paying attention, or if I just attract nut cases. It would be a wonderful thing if we had a central database describing the first public disclosure of the building block ideas that go into sensor networks, because we will, as a community, need to be able to fight back against those who see IP as a profit center, not a protocol :) Maybe a brainstorming session at the next meeting is in order? ksjp Adrian Farrel wrote: > Hi, > > I can understand people's frustration with the nature of IPR claims > and disclosures. > > However, while you can ask anyone to give you advice about what is > covered by a claim, and what the IPR terms actually mean, this is > ultimately a question that must be handled as an individual issue by > you, or as a corporate issue by your legal advisers. You would be > poorly advised to rely on the advice of an individual on this list, > whatever their technical or legal qualifications. > > JP's question is intended to allow you to state your opinions so that > he can judge working group consensus. > > He asked: > >> Given the discussions about the IPR disclosure at >> https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR >> policy at http://www.ietf.org/ipr/policy.html I would like >> to make sure that the working group is happy to proceed >> with draft-ietf-roll-rpl in its current form. Please state your >> opinions on the list. I will make a consensus call on Friday >> 11 February. > > [We can probably assume that he means Friday 12 February :-)] > > In answering this question you need to say "yes, let's go ahead" or > "no, we have to take steps to avoid the IPR". Your reasons for holding > a position may be helpful to others and to the chairs in finding the > way forward. > > By way of background, the IETF has always attempted to find > unencumbered technical solutions, but there is a general recognition > that very few specifications reach RFC status without the possibility > of some IPR claim at some time. By requiring IETF participants to > disclose IPR, the IETF is seeking to enable informed decisions why its > participants, and this helps to avoid claims of entrapment. It should > be noted that the absence of an IPR disclosure is not a guarantee that > no IPR exists, but the presence of a disclosure allows everyone to see > the licensing terms. In deciding whether to support or deny > continuation of technical work in the presence of an IPR disclosure, > individuals (or their companies) will want to consider whether they > think the IPR actually covers the technical work, whether it is > enforceable, and whether they consider the licensing terms to be > favourable. They will also need to consider the cost-benefit of the > various options that exist. No-one else can make these decisions for you! > > May I also take this opportunity to ask you all to look at the IETF's > IPR policy. In particular, can I remind you all about the policy with > respect to IPR that you know about as described in RFC 3979 and RFC > 4879. All document authors and contributors to discussions need to be > aware of their personal commitments to disclose IPR as expressed in > those two RFCs. > > Thanks, > Adrian > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Feb 4 12:19:44 2010 Return-Path: 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 81E4028C0E9 for ; Thu, 4 Feb 2010 12:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Y5w3-3sE98nu for ; Thu, 4 Feb 2010 12:19:42 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 3D4C03A687F for ; Thu, 4 Feb 2010 12:19:34 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B8D49D48206; Thu, 4 Feb 2010 21:20:18 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7CDEAD4820B; Thu, 4 Feb 2010 21:20:15 +0100 (CET) Message-ID: <4B6B2BFC.7020907@gmail.com> Date: Thu, 04 Feb 2010 21:20:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: JP Vasseur References: <20100203173153.864F928C0F7@core3.amsl.com> <332FB434-344B-4851-957E-FBBA4E642B8B@cisco.com> In-Reply-To: <332FB434-344B-4851-957E-FBBA4E642B8B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Fwd: Revised Guidelines to Authors of Internet-Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 20:19:45 -0000 I think an important change is the suggested (optional) new boilerplate to include urls of kind datatracker.ietf.org instead of www.ietf.org. Excerpt: > In the modern Internet, the need for stable URLs is more important > than providing multiple sites around the world to obtain I-Ds. Also, > search engines have replaced the need for a file containing a > collection of I-D abstracts. As a result, the second choice is: > > "This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF). Note that > other groups may also distribute working documents as > Internet-Drafts. The list of current Internet-Drafts is at > http://datatracker.ietf.org/drafts/current. > [...] Alex Le 03/02/2010 18:48, JP Vasseur a écrit : > > > Begin forwarded message: > >> *From: *IESG Secretary > > *Date: *February 3, 2010 6:31:53 >> PM CEST *To: *IETF Announcement list > > *Subject: **Revised Guidelines to >> Authors of Internet-Drafts * >> >> An updated version of the Guidelines to Authors of Internet-Drafts >> is now available and has been posted on the IETF website: >> >> http://www.ietf.org/id-info/guidelines.html OR >> http://www.ietf.org/id-info/1id-guidelines.txt >> >> Summary of changes in this version: >> >> o Update the references to reflect the current BCPs. Remove the >> reference to rfc2333bis, which is no longer an active work item. >> Add a references for the I-D Submission Tool and the Data Tracker. >> >> o Rewrite of Section 3. >> >> o Structure the choices in Section 4 to match the current BCPs. >> >> o Provide two boilerplate options in Section 5, as approved by the >> IESG on 7 January 2010. >> >> o Remove the discussion of grace period from Section 7. With the >> I-D Submission Tool, there is no longer a need for one. >> >> o Include URLs that are not redirected. >> >> o Significant editorial changes. >> _______________________________________________ IETF-Announce >> mailing list IETF-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Feb 4 12:25:26 2010 Return-Path: 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 DBD4728C163 for ; Thu, 4 Feb 2010 12:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 TTaTic-aL-wC for ; Thu, 4 Feb 2010 12:25:23 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CB06928C0F1 for ; Thu, 4 Feb 2010 12:25:21 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4D24DD4812F for ; Thu, 4 Feb 2010 21:26:05 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 56592D48211 for ; Thu, 4 Feb 2010 21:26:03 +0100 (CET) Message-ID: <4B6B2D58.4070800@gmail.com> Date: Thu, 04 Feb 2010 21:26:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <20100203113001.BA8493A6C20@core3.amsl.com> In-Reply-To: <20100203113001.BA8493A6C20@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 20:25:27 -0000 draft-ietf-roll-rpl-06.txt says: > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect to this document. Code Components extracted from this > document must include Simplified BSD License text as described in > Section 4.e of the Trust Legal Provisions and are provided without > warranty as described in the BSD License. What are the Code Components in this document? I don't seem to see any, is it normal? What makes you Authors want to make it a BSD license? We haven't discussed this until now and here it pops. Absence of this clarification makes it a little bit fuzzy... because what I know is that if I want to implement this document then I surely want to have freedom to paste a license of my choice on it, not necessarily the Simplified BSD License, please. I don't understand where does this mandatory Simplified BSD License come from... Thanks, Alex From alexandru.petrescu@gmail.com Thu Feb 4 13:07:23 2010 Return-Path: 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 5462D28C156 for ; Thu, 4 Feb 2010 13:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 XdKUMk-4Qwsk for ; Thu, 4 Feb 2010 13:07:22 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 3CB4728C0CE for ; Thu, 4 Feb 2010 13:07:20 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id C9E50D480CF for ; Thu, 4 Feb 2010 22:08:05 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C26E6D48037 for ; Thu, 4 Feb 2010 22:08:02 +0100 (CET) Message-ID: <4B6B372F.1020008@gmail.com> Date: Thu, 04 Feb 2010 22:07:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 CC: roll@ietf.org References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B2D58.4070800@gmail.com> In-Reply-To: <4B6B2D58.4070800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Disagreement about Simplified BSD License and e.g. RPL Control Codes (was: I-D Action:draft-ietf-roll-rpl-06.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 21:07:23 -0000 "Code Components" seem to be pretty much anything - more than simply some C code. They are for example "tables of values", as said in: http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt I don't agree to be bound by the Simplified BSD License in order to use "tables of values" such as the RPL Control Codes: +------+----------------------------------+---------------+ | Code | Description | Reference | +------+----------------------------------+---------------+ | 0x01 | DAG Information Solicitation | This document | | 0x02 | DAG Information Object | This document | | 0x04 | Destination Advertisement Object | This document | +------+----------------------------------+---------------+ I am in full disagreement to be bound to this license for this table. Part of this disagreement is because I did participate with feedback about this table and I never thought I was bound to this license. Alex Le 04/02/2010 21:26, Alexandru Petrescu a écrit : > draft-ietf-roll-rpl-06.txt says: >> Copyright Notice >> >> Copyright (c) 2010 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with >> respect to this document. Code Components extracted from this >> document must include Simplified BSD License text as described in >> Section 4.e of the Trust Legal Provisions and are provided without >> warranty as described in the BSD License. > > What are the Code Components in this document? I don't seem to see any, > is it normal? > > What makes you Authors want to make it a BSD license? > > We haven't discussed this until now and here it pops. > > Absence of this clarification makes it a little bit fuzzy... because > what I know is that if I want to implement this document then I surely > want to have freedom to paste a license of my choice on it, not > necessarily the Simplified BSD License, please. > > I don't understand where does this mandatory Simplified BSD License come > from... > > Thanks, > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu Feb 4 13:28:53 2010 Return-Path: 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 7C0D73A6CED for ; Thu, 4 Feb 2010 13:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 h+gO4jaSCVF8 for ; Thu, 4 Feb 2010 13:28:52 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5CCA03A6978 for ; Thu, 4 Feb 2010 13:28:50 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 014D0D48193 for ; Thu, 4 Feb 2010 22:29:35 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id EB48ED48118 for ; Thu, 4 Feb 2010 22:29:32 +0100 (CET) Message-ID: <4B6B3C3A.20802@gmail.com> Date: Thu, 04 Feb 2010 22:29:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 CC: roll@ietf.org References: <20100203113001.BA8493A6C20@core3.amsl.com> In-Reply-To: <20100203113001.BA8493A6C20@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Abstract first - normal? (was: I-D Action:draft-ietf-roll-rpl-06.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 21:28:53 -0000 Excuse-me is it normal to have the Abstract before the "Status of this Memo" and "Copyright Notice"? Do the Status and Copyright cover the Abstract too? I am asking because it is the first time I see this order, and I usually expect the Abstract to come _after_ the Status and Copyright. I may be not up to date with the recent trends... Alex Le 03/02/2010 12:30, Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Routing Over Low power > and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy > Networks Author(s) : T. Winter, et al. Filename : > draft-ietf-roll-rpl-06.txt Pages : 82 Date : > 2010-02-03 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to-point traffic > (between devices inside the LLN), point-to-multipoint traffic (from > a central control point to a subset of devices inside the LLN) and > multipoint-to-point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From pal@cs.stanford.edu Thu Feb 4 13:36:52 2010 Return-Path: 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 5D6393A6E41 for ; Thu, 4 Feb 2010 13:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 neBgqj80a2mh for ; Thu, 4 Feb 2010 13:36:51 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id AFDC83A6E3D for ; Thu, 4 Feb 2010 13:36:51 -0800 (PST) Received: from dnab404630.stanford.edu ([171.64.70.48]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nd9ON-0000VS-3o; Thu, 04 Feb 2010 13:37:39 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4B6B3C3A.20802@gmail.com> Date: Thu, 4 Feb 2010 13:37:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B3C3A.20802@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: roll@ietf.org Subject: Re: [Roll] Abstract first - normal? (was: I-D Action:draft-ietf-roll-rpl-06.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 21:36:52 -0000 On Feb 4, 2010, at 1:29 PM, Alexandru Petrescu wrote: > Excuse-me is it normal to have the Abstract before the "Status of this > Memo" and "Copyright Notice"? >=20 > Do the Status and Copyright cover the Abstract too? >=20 > I am asking because it is the first time I see this order, and I = usually > expect the Abstract to come _after_ the Status and Copyright. >=20 > I may be not up to date with the recent trends... I think your concern is with the general IETF Trust Legal Provisions = (4.0), and so probably isn't really worthwhile pursuing in this forum: = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-200= 91228.htm Phil= From alexandru.petrescu@gmail.com Thu Feb 4 13:49:15 2010 Return-Path: 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 97ECA28C1E1 for ; Thu, 4 Feb 2010 13:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 JJnUT6yQYbVP for ; Thu, 4 Feb 2010 13:49:14 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 821BB28C1D8 for ; Thu, 4 Feb 2010 13:49:12 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9CD72D481CB; Thu, 4 Feb 2010 22:49:57 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 90EF1D480CB; Thu, 4 Feb 2010 22:49:54 +0100 (CET) Message-ID: <4B6B40FF.6020505@gmail.com> Date: Thu, 04 Feb 2010 22:49:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Philip Levis References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B3C3A.20802@gmail.com> <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> In-Reply-To: <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Abstract first - normal? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 21:49:15 -0000 Le 04/02/2010 22:37, Philip Levis a écrit : > > On Feb 4, 2010, at 1:29 PM, Alexandru Petrescu wrote: > >> Excuse-me is it normal to have the Abstract before the "Status of >> this Memo" and "Copyright Notice"? >> >> Do the Status and Copyright cover the Abstract too? >> >> I am asking because it is the first time I see this order, and I >> usually expect the Abstract to come _after_ the Status and >> Copyright. >> >> I may be not up to date with the recent trends... > > > I think your concern is with the general IETF Trust Legal Provisions > (4.0), and so probably isn't really worthwhile pursuing in this > forum: > > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm Strange I don't see in that htm something telling to put the Abstract first. Maybe it's a matter of text editor. (but I get your point about better discussing legal matters somewhere else.) Alex From alexandru.petrescu@gmail.com Thu Feb 4 14:00:55 2010 Return-Path: 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 56A2F3A6E00 for ; Thu, 4 Feb 2010 14:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_40=-0.185, HELO_EQ_FR=0.35] 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 6daJDDhlJQXq for ; Thu, 4 Feb 2010 14:00:54 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5BA753A6E5E for ; Thu, 4 Feb 2010 14:00:52 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 80F46D480B7; Thu, 4 Feb 2010 23:01:36 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7C0C9D4808F; Thu, 4 Feb 2010 23:01:34 +0100 (CET) Message-ID: <4B6B43BB.3000807@gmail.com> Date: Thu, 04 Feb 2010 23:01:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Philip Levis References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B3C3A.20802@gmail.com> <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> In-Reply-To: <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100204-1, 04/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] linux kernel implementation and IETF Trust (was: Abstract first - normal?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:00:55 -0000 And let me add... h t t p ://www.ietf.org/id/draft-iab-iana-05.txt makes it that the IETF Trust covers it, i.e. its tables, with a BSD license, i.e. not GPL. Do we want RPL implemented in a Linux kernel? Alex Le 04/02/2010 22:37, Philip Levis a écrit : > > On Feb 4, 2010, at 1:29 PM, Alexandru Petrescu wrote: > >> Excuse-me is it normal to have the Abstract before the "Status of this >> Memo" and "Copyright Notice"? >> >> Do the Status and Copyright cover the Abstract too? >> >> I am asking because it is the first time I see this order, and I usually >> expect the Abstract to come _after_ the Status and Copyright. >> >> I may be not up to date with the recent trends... > > > I think your concern is with the general IETF Trust Legal Provisions (4.0), and so probably isn't really worthwhile pursuing in this forum: > > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm > > Phil From geoff@proto6.com Fri Feb 5 10:53:09 2010 Return-Path: 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 A1B883A6DC7 for ; Fri, 5 Feb 2010 10:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 E88keUHsLYzT for ; Fri, 5 Feb 2010 10:53:08 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id CD9963A6882 for ; Fri, 5 Feb 2010 10:53:08 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 5D1FB1834C; Fri, 5 Feb 2010 11:54:02 -0700 (MST) Received: from [172.19.165.150] ([198.202.202.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o15Irv1q019469; Fri, 5 Feb 2010 11:53:58 -0700 (MST) From: Geoff Mulligan To: JP Vasseur , roll@mail.ietf.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 05 Feb 2010 08:24:45 -0700 Message-Id: <1265383485.3502.29.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 05 Feb 2010 11:20:28 -0800 Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 18:53:09 -0000 I am extremely concerned should we decide to proceed with draft-ietf-roll-rpl in its current form. I agree with Pete and I second the request from JP that Pascal indicate what portions of RPL are covered by the Cisco IPR. Until we know what portions of RPL are covered by the IPR and how difficult it might be to "work around" the patents I dont know how to proceed. I do not think that Pascal should say that he doesn't know because patent lawyers got involved. Pascal is the best person in the world to show what is covered and what isn't. He is an author on the patents and also part of the DT for RPL. No one else is. I feel that it is critically important that we not proceed with the draft as it currently stands. I think that the current licensing terms for the IPR are a show stopper. geoff On Mon, 2010-02-01 at 14:57 +0100, JP Vasseur wrote: > Dear all, > > > Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy > at http://www.ietf.org/ipr/policy.html I would like to make sure that > the working group is happy to proceed with draft-ietf-roll-rpl in its > current form. Please state your opinions on the list. I will make a > consensus call on Friday 11 February. > > > Thanks. > > > JP. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Fri Feb 5 13:05:29 2010 Return-Path: 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 4DE1C3A6E18 for ; Fri, 5 Feb 2010 13:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Ia9hEdSkqdby for ; Fri, 5 Feb 2010 13:05:28 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 5CA933A6819 for ; Fri, 5 Feb 2010 13:05:28 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o15L7SDD015670 for ; Fri, 5 Feb 2010 13:07:28 -0800 (PST) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o15L7SXO015662 for ; Fri, 5 Feb 2010 13:07:28 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id o15L6Dgn024396 for ; Fri, 5 Feb 2010 13:06:13 -0800 (PST) Received: from [10.157.253.32] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id o15L6Cf03706 for ; Fri, 5 Feb 2010 13:06:12 -0800 (PST) Message-ID: <4B6C8837.4060203@us.fujitsu.com> Date: Fri, 05 Feb 2010 16:05:59 -0500 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 21:05:29 -0000 I too would like to express my interest in knowing what portions of RPL are covered by Cisco IPRs. Without such information, I am uncomfortable to move forward. Regards, Sung > > Message: 8 > Date: Fri, 05 Feb 2010 08:24:45 -0700 > From: Geoff Mulligan > Subject: Re: [Roll] Closing on the IPR > To: JP Vasseur , roll@mail.ietf.org > Cc: ROLL WG > Message-ID: <1265383485.3502.29.camel@dellx1> > Content-Type: text/plain > > I am extremely concerned should we decide to proceed with > draft-ietf-roll-rpl in its current form. I agree with Pete and I second > the request from JP that Pascal indicate what portions of RPL are > covered by the Cisco IPR. > > Until we know what portions of RPL are covered by the IPR and how > difficult it might be to "work around" the patents I dont know how to > proceed. > > I do not think that Pascal should say that he doesn't know because > patent lawyers got involved. Pascal is the best person in the world to > show what is covered and what isn't. He is an author on the patents and > also part of the DT for RPL. No one else is. > > I feel that it is critically important that we not proceed with the > draft as it currently stands. I think that the current licensing terms > for the IPR are a show stopper. > > geoff > > > > > On Mon, 2010-02-01 at 14:57 +0100, JP Vasseur wrote: > >> Dear all, >> >> >> Given the discussions about the IPR disclosure at >> https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy >> at http://www.ietf.org/ipr/policy.html I would like to make sure that >> the working group is happy to proceed with draft-ietf-roll-rpl in its >> current form. Please state your opinions on the list. I will make a >> consensus call on Friday 11 February. >> >> >> Thanks. >> >> >> JP. >> >> >> _______________________________________________ >> 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 > > > End of Roll Digest, Vol 25, Issue 9 > *********************************** > From mcr@sandelman.ca Sat Feb 6 18:48:02 2010 Return-Path: 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 0D92B28C102 for ; Sat, 6 Feb 2010 18:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 HyTm+CnIbp7N for ; Sat, 6 Feb 2010 18:48:01 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 221D728C0F5 for ; Sat, 6 Feb 2010 18:48:00 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan205.sandelman.ca [209.87.252.205]) by relay.sandelman.ca (Postfix) with ESMTPS id 3584834358; Sat, 6 Feb 2010 21:42:40 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E73C44E799; Sat, 6 Feb 2010 21:48:58 -0500 (EST) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4B6B2D58.4070800@gmail.com> References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B2D58.4070800@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sat, 06 Feb 2010 21:48:58 -0500 Message-ID: <7874.1265510938@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:48:02 -0000 >>>>> "Alexandru" == Alexandru Petrescu writes: >> Copyright Notice >> >> Copyright (c) 2010 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with >> respect to this document. Code Components extracted from this >> document must include Simplified BSD License text as described in >> Section 4.e of the Trust Legal Provisions and are provided >> without warranty as described in the BSD License. Alexandru> What are the Code Components in this document? I don't Alexandru> seem to see any, is it normal? This is normal. Not all documents have code components. Did you go and read BCP78? Have you submitted a document before? Do you know that the above is all boilerplate? Code components that *might* be an IETF document are typically things like MIB definitions. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Adrian.Farrel@huawei.com Sun Feb 7 05:15:57 2010 Return-Path: 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 B7C1F3A70A0 for ; Sun, 7 Feb 2010 05:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] 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 Xos7D736FKfo for ; Sun, 7 Feb 2010 05:15:56 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D2F923A6D4C for ; Sun, 7 Feb 2010 05:15:56 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXH006RK3K6VG@usaga01-in.huawei.com> for roll@ietf.org; Sun, 07 Feb 2010 05:16:55 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXH0049S3K5BZ@usaga01-in.huawei.com> for roll@ietf.org; Sun, 07 Feb 2010 05:16:54 -0800 (PST) Date: Sun, 07 Feb 2010 13:12:38 +0000 From: Adrian Farrel To: Alexandru Petrescu Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B3C3A.20802@gmail.com> <892ED51B-9BA0-40E2-854F-677ACC7B27D6@cs.stanford.edu> <4B6B40FF.6020505@gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] Abstract first - normal? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 13:15:57 -0000 Hi, >> Excuse-me is it normal to have the Abstract before the "Status of >> this Memo" and "Copyright Notice"? If "normal" is a historic measure, then no. If "normal" is an increasingly popular approach, then yes. The concern was that the Boilerplate was pushing the Anstract off the front page. Re-ordering solves this, and is acceptable within the IETF copyright, license and boilerplate rules. Please see the recently re-issued http://www.ietf.org/id-info/guidelines.html for advice about what should and must be done. Cheers, Adrian From alexandru.petrescu@gmail.com Mon Feb 8 00:55:10 2010 Return-Path: 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 996CF3A72DE for ; Mon, 8 Feb 2010 00:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dUe9pBxCqaAd for ; Mon, 8 Feb 2010 00:55:09 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 95AA03A72E4 for ; Mon, 8 Feb 2010 00:55:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o188u8hC001093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Feb 2010 09:56:08 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o188u8tD014501; Mon, 8 Feb 2010 09:56:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o188u7Fm020179; Mon, 8 Feb 2010 09:56:07 +0100 Message-ID: <4B6FD1A7.70409@gmail.com> Date: Mon, 08 Feb 2010 09:56:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Michael Richardson References: <20100203113001.BA8493A6C20@core3.amsl.com> <4B6B2D58.4070800@gmail.com> <7874.1265510938@marajade.sandelman.ca> In-Reply-To: <7874.1265510938@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 08:55:10 -0000 Thanks for the reply, Le 07/02/2010 03:48, Michael Richardson a écrit : >>>>>> "Alexandru" == Alexandru >>>>>> Petrescu writes: >>> Copyright Notice >>> >>> Copyright (c) 2010 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with >>> respect to this document. Code Components extracted from this >>> document must include Simplified BSD License text as described in >>> Section 4.e of the Trust Legal Provisions and are provided >>> without warranty as described in the BSD License. > > Alexandru> What are the Code Components in this document? I don't > Alexandru> seem to see any, is it normal? > > This is normal. Not all documents have code components. Did you go > and read BCP78? Have you submitted a document before? Do you know > that the above is all boilerplate? I am not legal specialist but I believe boilerplates are supposed to make sense whatever much boilerplates they are. To my reading it is strange to talk about Code Components while there are no Code Components. Imagine that we wrote, as technical experts, that the encoding used by RPL is bit not qubit. It makes no sense and it is unnecessary distraction. > Code components that *might* be an IETF document are typically things > like MIB definitions. Ah ok, this makes sense in a MIB document. I think this draft doesn't describe MIB. I also think Code Components might be much more than just MIB. (and yes, I did submit documents some times and I may again in the future.) Alex > From d.sturek@att.net Mon Feb 8 05:38:09 2010 Return-Path: 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 E33DB28C102 for ; Mon, 8 Feb 2010 05:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 KXg4664MSkB7 for ; Mon, 8 Feb 2010 05:38:09 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 6D5103A738F for ; Mon, 8 Feb 2010 05:38:08 -0800 (PST) Received: (qmail 24385 invoked from network); 8 Feb 2010 13:32:31 -0000 Received: from Studio (d.sturek@12.14.150.2 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 08 Feb 2010 05:32:31 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: oGXi9scVM1niKZzmwds5z92rePagaln8p90y8WMlx9rxm_ZFpM208ZEa7ScKYaZBW25nzyo2C60izhGv2O_cvZQZuWXZ7sFBQdeVk.EhBOLtVl8ewn8QJCcpkXf4UHnoMSoUJQvr8ZhAeTOOjL_iZ0Yq_qX_TZGbSVTli4hDr0_DyRSkaE84pN3_pNBZCApzOHsW3I5X0qP5hlF1mTmi2jIrVroV3izuvjuucloNIYmrhSfOd.BvT0U6Op.RlHehsNb1FyEhEAYS0yaTR1vtUxfXT5yzrZXg.DzfG9cEw4QE_H7tW1U- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Geoff Mulligan'" , "'JP Vasseur'" , References: <1265383485.3502.29.camel@dellx1> In-Reply-To: <1265383485.3502.29.camel@dellx1> Date: Mon, 8 Feb 2010 05:32:28 -0800 Message-ID: <006701caa8c3$290716e0$7b1544a0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqmmGaYOmpLbLrTQfeUqwYzalUv5ACKk8Ig Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:38:10 -0000 Can I ask what part of the Cisco licensing is a "show stopper"? If we agree that the Cisco licensing terms are unacceptable, are there going to be any assurances that what is left in RPL is covered by no other IPR (meaning someone is going to do a patent search and provide such assurances). Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Friday, February 05, 2010 7:25 AM To: JP Vasseur; roll@mail.ietf.org Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR I am extremely concerned should we decide to proceed with draft-ietf-roll-rpl in its current form. I agree with Pete and I second the request from JP that Pascal indicate what portions of RPL are covered by the Cisco IPR. Until we know what portions of RPL are covered by the IPR and how difficult it might be to "work around" the patents I dont know how to proceed. I do not think that Pascal should say that he doesn't know because patent lawyers got involved. Pascal is the best person in the world to show what is covered and what isn't. He is an author on the patents and also part of the DT for RPL. No one else is. I feel that it is critically important that we not proceed with the draft as it currently stands. I think that the current licensing terms for the IPR are a show stopper. geoff On Mon, 2010-02-01 at 14:57 +0100, JP Vasseur wrote: > Dear all, > > > Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy > at http://www.ietf.org/ipr/policy.html I would like to make sure that > the working group is happy to proceed with draft-ietf-roll-rpl in its > current form. Please state your opinions on the list. I will make a > consensus call on Friday 11 February. > > > Thanks. > > > JP. > > > _______________________________________________ > 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 From edward.j.beroset@us.elster.com Mon Feb 8 05:47:00 2010 Return-Path: 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 501453A7317 for ; Mon, 8 Feb 2010 05:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 z5RZNrAvD8Tc for ; Mon, 8 Feb 2010 05:46:59 -0800 (PST) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id 3FAC43A6F18 for ; Mon, 8 Feb 2010 05:46:59 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: edward.j.beroset@us.elster.com X-Msg-Ref: server-2.tower-53.messagelabs.com!1265636881!38438475!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 26591 invoked from network); 8 Feb 2010 13:48:01 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-2.tower-53.messagelabs.com with SMTP; 8 Feb 2010 13:48:01 -0000 In-Reply-To: <006701caa8c3$290716e0$7b1544a0$@sturek@att.net> References: <1265383485.3502.29.camel@dellx1> <006701caa8c3$290716e0$7b1544a0$@sturek@att.net> To: 'ROLL WG' MIME-Version: 1.0 X-KeepSent: DB61B05A:7EFFC8CD-852576C4:004B588E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008 Message-ID: From: edward.j.beroset@us.elster.com Date: Mon, 8 Feb 2010 08:48:22 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 02/08/2010 08:44:39 AM, Serialize complete at 02/08/2010 08:44:39 AM Content-Type: multipart/alternative; boundary="=_alternative 004BD6FE852576C4_=" Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:47:00 -0000 This is a multipart message in MIME format. --=_alternative 004BD6FE852576C4_= Content-Type: text/plain; charset="US-ASCII" I noticed about the Cisco statement are probably worth discussing. First, the license to use the patented technology is terminated if a company decides to sue Cisco. That seems OK, until you consider that if Company X was sued *by* Cisco and then Company X countersued (which is quite common, I'm told), then that clause comes into effect. That doesn't seem quite right. Further, this happens even if the suit has nothing to do with an implementation of roll, which also doesn't seem right. Perhaps Cisco lawyers can figure out a way to address those issues while still giving Cisco reasonable protection. Ed --=_alternative 004BD6FE852576C4_= Content-Type: text/html; charset="US-ASCII"
I noticed about the Cisco statement are probably worth discussing.  First, the license to use the patented technology is terminated if a company decides to sue Cisco.  That seems OK, until you consider that if Company X was sued *by* Cisco and then Company X countersued (which is quite common, I'm told), then that clause comes into effect.  That doesn't seem quite right.

Further, this happens even if the suit has nothing to do with an implementation of roll, which also doesn't seem right.  

Perhaps Cisco lawyers can figure out a way to address those issues while still giving Cisco reasonable protection.

Ed --=_alternative 004BD6FE852576C4_=-- From bushsf@research.ge.com Mon Feb 8 07:26:17 2010 Return-Path: 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 4F5623A7412 for ; Mon, 8 Feb 2010 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wp7ukkG7glQh for ; Mon, 8 Feb 2010 07:26:16 -0800 (PST) Received: from exprod5og103.obsmtp.com (exprod5og103.obsmtp.com [64.18.0.145]) by core3.amsl.com (Postfix) with ESMTP id 2FF1C3A73EE for ; Mon, 8 Feb 2010 07:26:14 -0800 (PST) Received: from source ([12.71.149.1]) (using TLSv1) by exprod5ob103.postini.com ([64.18.4.12]) with SMTP ID DSNKS3AtVAc0NeTK4phMzRDKumDMEYHZketx@postini.com; Mon, 08 Feb 2010 07:27:18 PST Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by Cinmlip09.e2k.ad.ge.com with ESMTP; 08 Feb 2010 10:27:10 -0500 Received: from CINMLVEM12.e2k.ad.ge.com ([3.159.214.57]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 10:26:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 10:26:45 -0500 Message-ID: <71BEE88C279BEB479AE8A5405B2DA0DAFAA583@CINMLVEM12.e2k.ad.ge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requesting ns-2 model of RLP Thread-Index: Acqo0x9ERrjKW+tlR9Ko0JMWoNz2aw== From: "Bush, Stephen F (GE, Research)" To: X-OriginalArrivalTime: 08 Feb 2010 15:26:49.0343 (UTC) FILETIME=[21E0D8F0:01CAA8D3] Subject: [Roll] Requesting ns-2 model of RLP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 15:26:17 -0000 Does anyone have an ns-2 model of roll that they would be willing to share? Thanks, Steve (www.research.ge.com/~bushsf) (www.comsoc.org/nano) From jvasseur@cisco.com Tue Feb 9 21:37:26 2010 Return-Path: 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 F01A028C0DD for ; Tue, 9 Feb 2010 21:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 pIZ7zF3eyMAS for ; Tue, 9 Feb 2010 21:37:25 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0146728B797 for ; Tue, 9 Feb 2010 21:37:25 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFAELVcUutJV2Z/2dsb2JhbACBRpkfdKR1mC6EVQQ X-IronPort-AV: E=Sophos;i="4.49,441,1262563200"; d="scan'208,217";a="239000367" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2010 05:38:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o1A5cXCY011684 for ; Wed, 10 Feb 2010 05:38:33 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 06:38:32 +0100 Received: from [10.108.68.111] ([10.55.94.216]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 06:38:32 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-96--289696435 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Feb 2010 06:38:32 +0100 References: <20100210001234.48C7A28C104@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Feb 2010 05:38:32.0547 (UTC) FILETIME=[482CB330:01CAAA13] Subject: [Roll] Fwd: Revised Guidelines to Authors of Internet-Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 05:37:26 -0000 --Apple-Mail-96--289696435 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI Begin forwarded message: > From: IESG Secretary > Date: February 10, 2010 1:12:34 AM CEST > To: IETF Announcement list > Subject: Revised Guidelines to Authors of Internet-Drafts > > An updated version of the Guidelines to Authors of Internet-Drafts > is now > available and has been posted on the IETF website: > > http://www.ietf.org/id-info/guidelines.html OR > http://www.ietf.org/id-info/1id-guidelines.txt > > Summary of changes in this version: > > o Correct the typographical errors in the excerpts from the Trust > License Policy (TLP) in Section 4. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-96--289696435 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable FYI

Begin = forwarded message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Date: February 10, 2010 1:12:34 AM = CEST
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: Revised Guidelines to Authors of = Internet-Drafts 

An updated = version of the Guidelines to Authors of Internet-Drafts is = now
available and has been posted on the IETF website:

=  http://www.ietf.org/i= d-info/guidelines.html  OR
 http://www.ietf.or= g/id-info/1id-guidelines.txt

Summary of changes in this = version:

o Correct the typographical errors in the excerpts from = the Trust
License Policy (TLP) in Section = 4.
_______________________________________________
IETF-Announce = mailing list
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-96--289696435-- From dlang@cisco.com Tue Feb 9 23:44:13 2010 Return-Path: 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 8E39C28C0FE for ; Tue, 9 Feb 2010 23:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ns0EmQJTkbR0 for ; Tue, 9 Feb 2010 23:44:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 066943A767F for ; Tue, 9 Feb 2010 23:44:11 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,442,1262563200"; d="scan'208,217";a="480910347" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2010 07:45:20 +0000 Received: from [192.168.1.108] (sjc-vpn5-939.cisco.com [10.21.91.171]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1A7jKhU017785; Wed, 10 Feb 2010 07:45:20 GMT Message-Id: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com> From: Dan Lang To: roll@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-762--282088636 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Feb 2010 23:45:20 -0800 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 10 Feb 2010 00:06:23 -0800 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 07:44:13 -0000 --Apple-Mail-762--282088636 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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. --Apple-Mail-762--282088636 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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.o= rg/ipr/1173/  (Juniper)
https://datatracker.ietf.o= rg/ipr/1254/  (Huawei)
https://datatracker.ietf.o= rg/ipr/1244/  (Ericsson)
https://datatracker.ietf.or= g/ipr/947/  (H3C Technology)
https://datatracker.ietf.o= rg/ipr/1170/  (Vidyo)
https://datatracker.ietf.o= rg/ipr/1253/  (Verizon)
https://datatracker.ietf.o= rg/ipr/1235/  (Apple)
https://datatracker.ietf.or= g/ipr/674/  (Digital Fountain)
https://datatracker.ietf.or= g/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.
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 From alexandru.petrescu@gmail.com Wed Feb 10 08:31:52 2010 Return-Path: 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 EE3A128C1D8 for ; Wed, 10 Feb 2010 08:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 TYmgnvKyAPBx for ; Wed, 10 Feb 2010 08:31:52 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id C46203A775B for ; Wed, 10 Feb 2010 08:31:51 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1AGWxSX003822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 17:32:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1AGWx3V018325; Wed, 10 Feb 2010 17:32:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1AGWxUv002990; Wed, 10 Feb 2010 17:32:59 +0100 Message-ID: <4B72DFBA.7060503@gmail.com> Date: Wed, 10 Feb 2010 17:32:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com> <6564C203-05A5-4749-88EB-54F85FE380D8@cs.stanford.edu> In-Reply-To: <6564C203-05A5-4749-88EB-54F85FE380D8@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:31:53 -0000 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 : > On Feb 9, 2010, at 11:45 PM, 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. > > 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 _______________________________________________ Roll mailing > list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From adrian@olddog.co.uk Wed Feb 10 08:36:26 2010 Return-Path: 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 4B9EF3A774F for ; Wed, 10 Feb 2010 08:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 GHZsRNYWw9DL for ; Wed, 10 Feb 2010 08:36:25 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id A61D73A7709 for ; Wed, 10 Feb 2010 08:36:24 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1AGbIYZ023484; Wed, 10 Feb 2010 16:37:23 GMT Received: from your029b8cecfe (62-50-195-17.client.stsn.net [62.50.195.17]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1AGbGk0023454; Wed, 10 Feb 2010 16:37:17 GMT Message-ID: From: "Adrian Farrel" To: "Geoff Mulligan" , "Dan Lang" References: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com> <1265818336.3895.12.camel@dellx1> Date: Wed, 10 Feb 2010 16:37:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: roll@ietf.org Subject: Re: [Roll] Roll IPR issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:36:26 -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 ----- Original Message ----- From: "Geoff Mulligan" To: "Dan Lang" Cc: Sent: Wednesday, February 10, 2010 4:12 PM 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 > From alexandru.petrescu@gmail.com Wed Feb 10 08:47:15 2010 Return-Path: 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 9F0E03A7775 for ; Wed, 10 Feb 2010 08:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 o4+TNfchhFHw for ; Wed, 10 Feb 2010 08:47:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9A49B3A7774 for ; Wed, 10 Feb 2010 08:47:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1AGmNj5022850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 17:48:23 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1AGmNWM021831; Wed, 10 Feb 2010 17:48:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1AGmMVo030840; Wed, 10 Feb 2010 17:48:23 +0100 Message-ID: <4B72E356.4080000@gmail.com> Date: Wed, 10 Feb 2010 17:48:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:47:15 -0000 What are the _software_ licensing schemes (not IPR) which I can expect from RPL designed at IETF? Can RPL be implemented in a linux kernel (GPL)? Can RPL be implemented in a Open Source project? In the past, when people tried to port the TCP/IP stack from BSD to linux they realize (after months of work) the BSD licensing would prevent them, and rewrote it from scratch. Now that I see the word "BSD" mentioned in the RPL draft (which is new, not all RFCs do) I am afraid there may be some software licensing problems. Alex From alexandru.petrescu@gmail.com Wed Feb 10 08:55:23 2010 Return-Path: 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 834DF28C1E2 for ; Wed, 10 Feb 2010 08:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 IVetrgkm1KtB for ; Wed, 10 Feb 2010 08:55:22 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id F22E73A7750 for ; Wed, 10 Feb 2010 08:55:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1AGuVFu004092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 17:56:31 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1AGuVeI023332; Wed, 10 Feb 2010 17:56:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1AGuUfO000780; Wed, 10 Feb 2010 17:56:31 +0100 Message-ID: <4B72E53E.4040702@gmail.com> Date: Wed, 10 Feb 2010 17:56:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <20100210001234.48C7A28C104@core3.amsl.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090002030902070303010206" Subject: Re: [Roll] Fwd: Revised Guidelines to Authors of Internet-Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:55:23 -0000 This is a multi-part message in MIME format. --------------090002030902070303010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks JP. It's surprising to see new guidelines at 1 week interval. What are the differences between these guidelines and those of February 3rd (see attached announcement)? Thanks, Alex Le 10/02/2010 06:38, JP Vasseur a écrit : > FYI > > Begin forwarded message: > >> *From: *IESG Secretary > > >> *Date: *February 10, 2010 1:12:34 AM CEST >> *To: *IETF Announcement list > > >> *Subject: **Revised Guidelines to Authors of Internet-Drafts * >> >> An updated version of the Guidelines to Authors of Internet-Drafts is now >> available and has been posted on the IETF website: >> >> http://www.ietf.org/id-info/guidelines.html OR >> http://www.ietf.org/id-info/1id-guidelines.txt >> >> Summary of changes in this version: >> >> o Correct the typographical errors in the excerpts from the Trust >> License Policy (TLP) in Section 4. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------090002030902070303010206 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Received: from LAURIN.intra.cea.fr ([132.166.65.44]) by LODERI.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 18:49:26 +0100 Received: from mansart.intra.cea.fr ([132.166.88.54]) by LAURIN.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 18:49:27 +0100 Received: from muguet2.intra.cea.fr ([132.166.192.7]) by mansart.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 18:49:26 +0100 Received: from epeire1.extra.cea.fr (epeire1.extra.cea.fr [132.167.198.31]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-in-1.1) with ESMTP id o13HnQxM018184 for ; Wed, 3 Feb 2010 18:49:26 +0100 Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by epeire1.extra.cea.fr (8.14.2/8.14.2) with ESMTP id o13HnP71009704 for ; Wed, 3 Feb 2010 18:49:25 +0100 (envelope-from alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-in-3.0) with ESMTP id o13HnKck028559 for ; Wed, 3 Feb 2010 18:49:25 +0100 Received: from spool.mail.gandi.net (mspool1-d.mgt.gandi.net [10.0.21.131]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id AC573225191; Wed, 3 Feb 2010 18:49:20 +0100 (CET) Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.40]) by spool.mail.gandi.net (Postfix) with ESMTP id 6711725D357; Wed, 3 Feb 2010 18:49:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-v Received: from spool.mail.gandi.net ([10.0.21.131]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.40]) (amavisd-new, port 10024) with ESMTP id MgrNuMphDhtH; Wed, 3 Feb 2010 18:49:18 +0100 (CET) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by spool.mail.gandi.net (Postfix) with ESMTP id BE08325D350 for ; Wed, 3 Feb 2010 18:49:18 +0100 (CET) Received: by fxm27 with SMTP id 27so1618652fxm.7 for ; Wed, 03 Feb 2010 09:49:18 -0800 (PST) Received: by 10.223.4.130 with SMTP id 2mr2405451far.100.1265219358602; Wed, 03 Feb 2010 09:49:18 -0800 (PST) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.223.126.13 with SMTP id a13cs41337fas; Wed, 3 Feb 2010 09:49:17 -0800 (PST) Received: by 10.114.162.13 with SMTP id k13mr3223287wae.152.1265219354812; Wed, 03 Feb 2010 09:49:14 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 10si2685075pzk.84.2010.02.03.09.49.12; Wed, 03 Feb 2010 09:49:14 -0800 (PST) Received-SPF: pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=roll-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA47828C0EC; Wed, 3 Feb 2010 09:48:23 -0800 (PST) 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 E418528C0E3 for ; Wed, 3 Feb 2010 09:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 yWYyRzdpcVgv for ; Wed, 3 Feb 2010 09:48:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 132A928C174 for ; Wed, 3 Feb 2010 09:48:19 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAOVFaUurRN+J/2dsb2JhbACBbL5GmBaERQQ X-IronPort-AV: E=Sophos;i="4.49,399,1262563200"; d="scan'208,217";a="83177371" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2010 17:49:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o13Hn16q006631 for ; Wed, 3 Feb 2010 17:49:02 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 11:49:01 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 11:49:00 -0600 Message-Id: <332FB434-344B-4851-957E-FBBA4E642B8B@cisco.com> From: JP Vasseur To: ROLL WG Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Feb 2010 18:48:59 +0100 References: <20100203173153.864F928C0F7@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Feb 2010 17:49:00.0969 (UTC) FILETIME=[2B0EE990:01CAA4F9] Subject: [Roll] Fwd: Revised Guidelines to Authors of Internet-Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2052592338==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org X-CEA-Source: externe X-CEA-Spam: 10% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description TO_IN_SUBJECT 0.500 To address is found in the subject line HTML_50_70 0.100 Message is 50-70% HTML BODY_SIZE_5000_5999 0.000 Message body size is 5000 to 5999 bytes BODY_SIZE_7000_LESS 0.000 Message body size is less than 5000 bytes. X-CEA-Spam-Hits: TO_IN_SUBJECT 0.5, HTML_50_70 0.1, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __HAS_HTML 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_XOAT 0, __HAS_X_MAILER 0, __MIME_HTML 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NS , __USER_AGENT_APPLEMAIL 0, __X_FORWARDED_FOR_GMAIL 0, __X_MAILER_APPLEMAIL 0 Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com --===============2052592338== Content-Type: multipart/alternative; boundary=Apple-Mail-419--850669091 --Apple-Mail-419--850669091 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IESG Secretary > Date: February 3, 2010 6:31:53 PM CEST > To: IETF Announcement list > Subject: Revised Guidelines to Authors of Internet-Drafts > > An updated version of the Guidelines to Authors of Internet-Drafts > is now > available and has been posted on the IETF website: > > http://www.ietf.org/id-info/guidelines.html OR > http://www.ietf.org/id-info/1id-guidelines.txt > > Summary of changes in this version: > > o Update the references to reflect the current BCPs. Remove the > reference to rfc2333bis, which is no longer an active work item. > Add a references for the I-D Submission Tool and the Data Tracker. > > o Rewrite of Section 3. > > o Structure the choices in Section 4 to match the current BCPs. > > o Provide two boilerplate options in Section 5, as approved by the > IESG on 7 January 2010. > > o Remove the discussion of grace period from Section 7. With the > I-D Submission Tool, there is no longer a need for one. > > o Include URLs that are not redirected. > > o Significant editorial changes. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-419--850669091 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Date: February 3, 2010 6:31:53 PM = CEST
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: Revised Guidelines to Authors of = Internet-Drafts 

An updated = version of the Guidelines to Authors of Internet-Drafts is = now
available and has been posted on the IETF website:

=  http://www.ietf.org/i= d-info/guidelines.html  OR
 http://www.ietf.or= g/id-info/1id-guidelines.txt

Summary of changes in this = version:

o Update the references to reflect the current BCPs. = Remove the
 reference to rfc2333bis, which is no longer an = active work item.
 Add a references for the I-D Submission Tool = and the Data Tracker.

o Rewrite of Section 3.

o Structure = the choices in Section 4 to match the current BCPs.

o Provide two = boilerplate options in Section 5, as approved by the
 IESG on 7 = January 2010.

o Remove the discussion of grace period from = Section 7. With the
 I-D Submission Tool, there is no longer a = need for one.

o Include URLs that are not redirected.

o = Significant editorial = changes.
_______________________________________________
IETF-Announ= ce mailing list
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-419--850669091-- --===============2052592338== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2052592338==-- --------------090002030902070303010206-- From pal@cs.stanford.edu Wed Feb 10 09:16:19 2010 Return-Path: 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 9CB2B28C1F3 for ; Wed, 10 Feb 2010 09:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uixRXgnCHsoz for ; Wed, 10 Feb 2010 09:16:18 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D5B5A3A775D for ; Wed, 10 Feb 2010 09:16:18 -0800 (PST) Received: from dnab404630.stanford.edu ([171.64.70.48]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NfGBt-0001M4-SS; Wed, 10 Feb 2010 09:17:30 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4B72E356.4080000@gmail.com> Date: Wed, 10 Feb 2010 09:17:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4B72E356.4080000@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:16:19 -0000 On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: > Can RPL be implemented in a linux kernel (GPL)? Yes. > Can RPL be implemented in a Open Source project? Yes. > In the past, when people tried to port the TCP/IP stack from BSD to > linux they realize (after months of work) the BSD licensing would > prevent them, and rewrote it from scratch. I don't think this is true. Do you have a reference? Phil From alexandru.petrescu@gmail.com Wed Feb 10 10:16:40 2010 Return-Path: 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 9037628C238 for ; Wed, 10 Feb 2010 10:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 L7TnJZSy9HMr for ; Wed, 10 Feb 2010 10:16:39 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8F3E828C237 for ; Wed, 10 Feb 2010 10:16:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1AIHhxO020381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 19:17:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1AIHh2q004076; Wed, 10 Feb 2010 19:17:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1AIHhMv030383; Wed, 10 Feb 2010 19:17:43 +0100 Message-ID: <4B72F847.3090206@gmail.com> Date: Wed, 10 Feb 2010 19:17:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ROLL WG References: <4B72E356.4080000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:16:40 -0000 Le 10/02/2010 18:17, Philip Levis a écrit : > > On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: > >> Can RPL be implemented in a linux kernel (GPL)? > > Yes. The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL (General Public License). I suppose there may be a contradiction, in the sense that all that runs in the linux kernel MUST be GPL, otherwise it's binary (no source available). What do you mean when you say 'Yes' to the question of linux kernel and RPL? >> Can RPL be implemented in a Open Source project? > > Yes. Which Open Source license is compatible with RPL document? >> In the past, when people tried to port the TCP/IP stack from BSD >> to linux they realize (after months of work) the BSD licensing >> would prevent them, and rewrote it from scratch. > > I don't think this is true. Do you have a reference? I am not sure which part you believe untrue? Sorry, I don't have a reference, just some thoughts not published anywhere else. I noticed there are only few TCP/IP stacks in wide use, and are either the BSD's or the linux's. And knowing the linux's came much later after BSD, and after BSD was already integrated in many commercial systems, one wonders why did they write a stack from scratch for linux? I suppose it was because of the licensing. Alex From pal@cs.stanford.edu Wed Feb 10 11:24:24 2010 Return-Path: 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 E65F928C257 for ; Wed, 10 Feb 2010 11:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 b1w6wyUeo3lH for ; Wed, 10 Feb 2010 11:24:23 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 905CF3A6F4D for ; Wed, 10 Feb 2010 11:24:23 -0800 (PST) Received: from dnab404630.stanford.edu ([171.64.70.48]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NfIBq-0000go-KH; Wed, 10 Feb 2010 11:25:35 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-27--240074449 From: Philip Levis In-Reply-To: <4B72F847.3090206@gmail.com> Date: Wed, 10 Feb 2010 11:25:34 -0800 Message-Id: <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 104fcb84af92cc131bf6e023e43ddbb4 Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:24:25 -0000 --Apple-Mail-27--240074449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 10, 2010, at 10:17 AM, Alexandru Petrescu wrote: > Le 10/02/2010 18:17, Philip Levis a =E9crit : >>=20 >> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: >>=20 >>> Can RPL be implemented in a linux kernel (GPL)? >>=20 >> Yes. >=20 > The draft says BSD (Berkeley Systems Distrib). The linux kernel is = GPL > (General Public License). I suppose there may be a contradiction, in > the sense that all that runs in the linux kernel MUST be GPL, = otherwise > it's binary (no source available). >=20 > What do you mean when you say 'Yes' to the question of linux kernel = and RPL? Alex, I don't really want to turn this list into a primer on source = licenses. The basic point is that you can take code under a BSD license = and release it under a GPL license. The original BSD license remains. = While Theo de Raadt has commented on how he finds this personally = offensive[1], you can of course do it. >=20 >>> Can RPL be implemented in a Open Source project? >>=20 >> Yes. >=20 > Which Open Source license is compatible with RPL document? Please go read about open source licensing and all of the ways in which = different licenses can interact. As you might imagine, this information = is very available on the Internet. Let's not clog up this list with the = basics of a quite mature area of concern which isn't at all = ROLL-specific. >=20 >>> In the past, when people tried to port the TCP/IP stack from BSD >>> to linux they realize (after months of work) the BSD licensing >>> would prevent them, and rewrote it from scratch. >>=20 >> I don't think this is true. Do you have a reference? >=20 > I am not sure which part you believe untrue? >=20 > Sorry, I don't have a reference, just some thoughts not published > anywhere else. >=20 > I noticed there are only few TCP/IP stacks in wide use, and are > either the BSD's or the linux's. And knowing the linux's came much > later after BSD, and after BSD was already integrated in many = commercial > systems, one wonders why did they write a stack from scratch for = linux? > I suppose it was because of the licensing. So, you don't know, made something up based on your best (clearly = uninformed) guess, and then asserted it as truth? That's not a good = approach for anyone to take your concerns seriously. Phil [1] http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code --Apple-Mail-27--240074449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Le 10/02/2010 18:17, Philip Levis a =E9crit = :

On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu = wrote:

Can RPL be implemented in a linux kernel = (GPL)?

Yes.

The draft says BSD (Berkeley = Systems Distrib).  The linux kernel is GPL
(General Public = License).  I suppose there may be a contradiction, in
the sense = that all that runs in the linux kernel MUST be GPL, otherwise
it's = binary (no source available).

What do you mean when you say 'Yes' = to the question of linux kernel and = RPL?

Alex, I don't really want = to turn this list into a primer on source licenses. The basic point is = that you can take code under a BSD license and release it under a GPL = license. The original BSD license remains. While Theo de Raadt has = commented on how he finds this personally offensive[1], you can of = course do it.


Can RPL be implemented in a Open = Source project?

Yes.

Which Open Source license is = compatible with RPL = document?

Please go read about = open source licensing and all of the ways in which different licenses = can interact. As you might imagine, this information is very available = on the Internet. Let's not clog up this list with the basics of a quite = mature area of concern which isn't at all = ROLL-specific.


In the past, when people tried = to port the TCP/IP stack from = BSD
to linux they realize (after months of work) the BSD = licensing
would prevent them, and rewrote = it from scratch.

I don't think = this is true. Do you have a reference?

I am not sure = which part you believe untrue?

Sorry, I don't have a reference, = just some thoughts not published
anywhere else.

I noticed = there are only few TCP/IP stacks in wide use, and are
either the = BSD's or the linux's.  And knowing the linux's came much
later = after BSD, and after BSD was already integrated in many = commercial
systems, one wonders why did they write a stack from = scratch for linux?
I suppose it was because of the = licensing.

So, you don't know, made = something up based on your best (clearly uninformed) guess, and then = asserted it as truth? That's not a good approach for anyone to take your = concerns = seriously.

Phil



= --Apple-Mail-27--240074449-- From joakime@sics.se Wed Feb 10 11:24:44 2010 Return-Path: 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 5EE3C28C25B for ; Wed, 10 Feb 2010 11:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 LmuPuWGU9i7D for ; Wed, 10 Feb 2010 11:24:43 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id DF83928C24D for ; Wed, 10 Feb 2010 11:24:42 -0800 (PST) Received: from [127.0.0.1] (grayling.sics.se [193.10.67.143]) by letter.sics.se (Postfix) with ESMTP id DC80A40319; Wed, 10 Feb 2010 20:25:52 +0100 (CET) Message-ID: <4B730840.2020701@sics.se> Date: Wed, 10 Feb 2010 20:25:52 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> In-Reply-To: <4B72F847.3090206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:24:44 -0000 Alexandru Petrescu wrote: > Le 10/02/2010 18:17, Philip Levis a écrit : >> >> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: >> >>> Can RPL be implemented in a linux kernel (GPL)? >> >> Yes. > > The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL > (General Public License). I suppose there may be a contradiction, in > the sense that all that runs in the linux kernel MUST be GPL, otherwise > it's binary (no source available). > > What do you mean when you say 'Yes' to the question of linux kernel and > RPL? From this description http://en.wikipedia.org/wiki/BSD_licenses and reading the version of the suggested BSD license it seems to be compatible with GPL so implementing in Linux should not be any problems. The original BSD license had problems since it imposed some "advertisement" in the user interface of the software that used the BSD licensed software. >>> Can RPL be implemented in a Open Source project? >> >> Yes. > > Which Open Source license is compatible with RPL document? Most. Look at above link. And there is not much code to actually take from the RPL specification. It would take almost not time at all to write that code instead of "cut-n-pasing" from the RPL-specification if the license would be a problem. >>> In the past, when people tried to port the TCP/IP stack from BSD >>> to linux they realize (after months of work) the BSD licensing >>> would prevent them, and rewrote it from scratch. >> >> I don't think this is true. Do you have a reference? > > I am not sure which part you believe untrue? > > Sorry, I don't have a reference, just some thoughts not published > anywhere else. > > I noticed there are only few TCP/IP stacks in wide use, and are > either the BSD's or the linux's. And knowing the linux's came much > later after BSD, and after BSD was already integrated in many commercial > systems, one wonders why did they write a stack from scratch for linux? > I suppose it was because of the licensing. It might have been an original 4-clause BSD license that is not compatible with GPL. Best regards, -- Joakim Eriksson, SICS > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From adam@sics.se Wed Feb 10 11:26:27 2010 Return-Path: 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 1DF1928C24D for ; Wed, 10 Feb 2010 11:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 BwJl4KjSd+kd for ; Wed, 10 Feb 2010 11:26:26 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 078C628C220 for ; Wed, 10 Feb 2010 11:26:26 -0800 (PST) Received: from [10.1.1.139] (unknown [10.1.1.139]) by letter.sics.se (Postfix) with ESMTPS id 071B140319; Wed, 10 Feb 2010 20:27:36 +0100 (CET) Message-ID: <4B7308A0.7060008@sics.se> Date: Wed, 10 Feb 2010 20:27:28 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> In-Reply-To: <4B72F847.3090206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:26:27 -0000 Alexandru Petrescu wrote: > Le 10/02/2010 18:17, Philip Levis a écrit : >> >> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: >> >>> Can RPL be implemented in a linux kernel (GPL)? >> >> Yes. > > The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL > (General Public License). I suppose there may be a contradiction, in > the sense that all that runs in the linux kernel MUST be GPL, otherwise > it's binary (no source available). > > What do you mean when you say 'Yes' to the question of linux kernel and > RPL? There is nothing that prevents an implementation of RPL to adopt any software license that the copyright holder may chose. RPL can be implemented as non-open source software, as GPL free software, as MIT/X11/BSD/Apache/whatever open source software. It is up to the copyright holder and not up to the IETF to decide. The RPL draft does not appear to contain any code or otherwise copyrightable tables. It seems that the Code Components clause has been added only because it is in the boiler plate, and not because the draft contains any code that needs it. In any case, a 3-clause BSD-licensed RPL implementation can without problems be combined with GPL code. I.e., such an implementation can be included in the Linux kernel. A GPL licensed RPL implementation could also be included in the Linux kernel. And so forth. It is not up to the IETF to decide what licenses the implementations choose to use. The only code that the IETF can assert copyright over is code that is part of an RFC or other IETF document. In this case, there seems to be nosuch code. >>> In the past, when people tried to port the TCP/IP stack from BSD >>> to linux they realize (after months of work) the BSD licensing >>> would prevent them, and rewrote it from scratch. >> >> I don't think this is true. Do you have a reference? > > I am not sure which part you believe untrue? > > Sorry, I don't have a reference, just some thoughts not published > anywhere else. I think you may be recalling the problems that existed with the old 4-clause BSD license. This license was used for the original BSD code, and included an "advertising clause" which was deemed to be non-compatible with the GPL. This may have prompted people to rewrite the TCP/IP stack under the GPL. This 4th clause has subsequently been removed and the BSD license is now compatible with the GPL. You'll find it on the list here: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From alexandru.petrescu@gmail.com Wed Feb 10 11:50:57 2010 Return-Path: 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 3134228C224 for ; Wed, 10 Feb 2010 11:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_20=-0.74, HELO_EQ_FR=0.35] 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 vHoHtpXovvo4 for ; Wed, 10 Feb 2010 11:50:56 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D143D28C22C for ; Wed, 10 Feb 2010 11:50:54 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 467C1D48200; Wed, 10 Feb 2010 20:52:01 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0C356D48094; Wed, 10 Feb 2010 20:51:58 +0100 (CET) Message-ID: <4B730E5B.2040203@gmail.com> Date: Wed, 10 Feb 2010 20:51:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Adam Dunkels References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> In-Reply-To: <4B7308A0.7060008@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:50:57 -0000 Le 10/02/2010 20:27, Adam Dunkels a écrit : > Alexandru Petrescu wrote: >> Le 10/02/2010 18:17, Philip Levis a écrit : >>> >>> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: >>> >>>> Can RPL be implemented in a linux kernel (GPL)? >>> >>> Yes. >> >> The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL >> (General Public License). I suppose there may be a contradiction, in >> the sense that all that runs in the linux kernel MUST be GPL, otherwise >> it's binary (no source available). >> >> What do you mean when you say 'Yes' to the question of linux kernel >> and RPL? > > There is nothing that prevents an implementation of RPL to adopt any > software license that the copyright holder may chose. Sorry, but the fact this Internet Draft says it must be "BSD" worries me a lot, especially from the GPL standpoint. > RPL can be > implemented as non-open source software, as GPL free software, as > MIT/X11/BSD/Apache/whatever open source software. It is up to the > copyright holder and not up to the IETF to decide. IETF says: "BSD", in the draft. Alex The RPL draft does > not appear to contain any code or otherwise copyrightable tables. It > seems that the Code Components clause has been added only because it is > in the boiler plate, and not because the draft contains any code that > needs it. > > In any case, a 3-clause BSD-licensed RPL implementation can without > problems be combined with GPL code. I.e., such an implementation can be > included in the Linux kernel. A GPL licensed RPL implementation could > also be included in the Linux kernel. And so forth. It is not up to the > IETF to decide what licenses the implementations choose to use. The only > code that the IETF can assert copyright over is code that is part of an > RFC or other IETF document. In this case, there seems to be nosuch code. > >>>> In the past, when people tried to port the TCP/IP stack from BSD >>>> to linux they realize (after months of work) the BSD licensing >>>> would prevent them, and rewrote it from scratch. >>> >>> I don't think this is true. Do you have a reference? >> >> I am not sure which part you believe untrue? >> >> Sorry, I don't have a reference, just some thoughts not published >> anywhere else. > > I think you may be recalling the problems that existed with the old > 4-clause BSD license. This license was used for the original BSD code, > and included an "advertising clause" which was deemed to be > non-compatible with the GPL. This may have prompted people to rewrite > the TCP/IP stack under the GPL. > > This 4th clause has subsequently been removed and the BSD license is now > compatible with the GPL. You'll find it on the list here: > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses > > /adam From adam@sics.se Wed Feb 10 11:53:29 2010 Return-Path: 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 4C5783A75B5 for ; Wed, 10 Feb 2010 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 TJDMbBq9YSay for ; Wed, 10 Feb 2010 11:53:28 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 44FEE3A7464 for ; Wed, 10 Feb 2010 11:53:28 -0800 (PST) Received: from [10.1.1.139] (unknown [10.1.1.139]) by letter.sics.se (Postfix) with ESMTPS id 62CF140319; Wed, 10 Feb 2010 20:54:39 +0100 (CET) Message-ID: <4B730EF6.6030301@sics.se> Date: Wed, 10 Feb 2010 20:54:30 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> <4B730E5B.2040203@gmail.com> In-Reply-To: <4B730E5B.2040203@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:53:29 -0000 Alexandru Petrescu wrote: > Sorry, but the fact this Internet Draft says it must be "BSD" worries me > a lot, especially from the GPL standpoint. It is not a problem. /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From alexandru.petrescu@gmail.com Wed Feb 10 11:56:43 2010 Return-Path: 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 1E57F28C14E for ; Wed, 10 Feb 2010 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 sxlyxv1BKAl5 for ; Wed, 10 Feb 2010 11:56:42 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DDC9B28C160 for ; Wed, 10 Feb 2010 11:56:40 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id CC6FED481FE; Wed, 10 Feb 2010 20:57:48 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id BBEE6D4802D; Wed, 10 Feb 2010 20:57:45 +0100 (CET) Message-ID: <4B730FB6.5060301@gmail.com> Date: Wed, 10 Feb 2010 20:57:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Joakim Eriksson References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> In-Reply-To: <4B730840.2020701@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:56:43 -0000 Le 10/02/2010 20:25, Joakim Eriksson a écrit : > Alexandru Petrescu wrote: >> Le 10/02/2010 18:17, Philip Levis a écrit : >>> >>> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: >>> >>>> Can RPL be implemented in a linux kernel (GPL)? >>> >>> Yes. >> >> The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL >> (General Public License). I suppose there may be a contradiction, in >> the sense that all that runs in the linux kernel MUST be GPL, otherwise >> it's binary (no source available). >> >> What do you mean when you say 'Yes' to the question of linux kernel >> and RPL? > > From this description http://en.wikipedia.org/wiki/BSD_licenses and > reading the version of the suggested BSD license it seems to be > compatible with GPL so implementing in Linux should not be any problems. I meant linux kernel. Is there some BSD code in the linux kernel? Alex > > The original BSD license had problems since it imposed some > "advertisement" in the user interface of the software that used the > BSD licensed software. > >>>> Can RPL be implemented in a Open Source project? >>> >>> Yes. >> >> Which Open Source license is compatible with RPL document? > > Most. Look at above link. And there is not much code to actually > take from the RPL specification. It would take almost not time at > all to write that code instead of "cut-n-pasing" from the > RPL-specification if the license would be a problem. > >>>> In the past, when people tried to port the TCP/IP stack from BSD >>>> to linux they realize (after months of work) the BSD licensing >>>> would prevent them, and rewrote it from scratch. >>> >>> I don't think this is true. Do you have a reference? >> >> I am not sure which part you believe untrue? >> >> Sorry, I don't have a reference, just some thoughts not published >> anywhere else. >> >> I noticed there are only few TCP/IP stacks in wide use, and are >> either the BSD's or the linux's. And knowing the linux's came much >> later after BSD, and after BSD was already integrated in many commercial >> systems, one wonders why did they write a stack from scratch for linux? >> I suppose it was because of the licensing. > > It might have been an original 4-clause BSD license that is not > compatible with GPL. > > > Best regards, > -- Joakim Eriksson, SICS > > >> Alex >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Wed Feb 10 11:59:49 2010 Return-Path: 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 900303A75CD for ; Wed, 10 Feb 2010 11:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 QHHoId5jA4fz for ; Wed, 10 Feb 2010 11:59:49 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CC2523A7593 for ; Wed, 10 Feb 2010 11:59:47 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 60474D481BD for ; Wed, 10 Feb 2010 21:00:55 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 695D9D481A9 for ; Wed, 10 Feb 2010 21:00:53 +0100 (CET) Message-ID: <4B731072.5060201@gmail.com> Date: Wed, 10 Feb 2010 21:00:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] I want the word "GPL" in the RPL draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:59:49 -0000 RoLLers, Software licensing discussions can be long. To make it short here is what I want: I want GPL to be a license in the RPL document. I don't want BSD in this document. I wonder how "BSD" landed there. If there was a choice to make between the two I'd put GPL. It's surprising nobody asked about this and here it goes, RPL about to become BSD. Come on, serious. Alex From adam@sics.se Wed Feb 10 12:07:15 2010 Return-Path: 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 6511C3A75D0 for ; Wed, 10 Feb 2010 12:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 trhhpA6F6cUe for ; Wed, 10 Feb 2010 12:07:14 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 53DBF3A75B3 for ; Wed, 10 Feb 2010 12:07:14 -0800 (PST) Received: from [10.1.1.139] (unknown [10.1.1.139]) by letter.sics.se (Postfix) with ESMTPS id 6FE3740319; Wed, 10 Feb 2010 21:08:25 +0100 (CET) Message-ID: <4B731230.3090904@sics.se> Date: Wed, 10 Feb 2010 21:08:16 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> In-Reply-To: <4B730FB6.5060301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:07:15 -0000 Alexandru Petrescu wrote: > I meant linux kernel. Is there some BSD code in the linux kernel? Plenty. Here are a few examples, from a quick search: http://lxr.linux.no/#linux+v2.6.32/include/acpi/actbl.h#L11 http://lxr.linux.no/#linux+v2.6.32/include/acpi/acexcep.h#L11 http://lxr.linux.no/#linux+v2.6.32/scripts/unifdef.c#L4 http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14 /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From alexandru.petrescu@gmail.com Wed Feb 10 12:07:53 2010 Return-Path: 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 A76F93A75D0 for ; Wed, 10 Feb 2010 12:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 c0CMONghgXDp for ; Wed, 10 Feb 2010 12:07:52 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 59C5D3A75CD for ; Wed, 10 Feb 2010 12:07:50 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5011DD48121; Wed, 10 Feb 2010 21:08:58 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4555BD48160; Wed, 10 Feb 2010 21:08:56 +0100 (CET) Message-ID: <4B731254.1000203@gmail.com> Date: Wed, 10 Feb 2010 21:08:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Adam Dunkels References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> In-Reply-To: <4B7308A0.7060008@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:07:53 -0000 Le 10/02/2010 20:27, Adam Dunkels a écrit : > [...] It seems that the Code Components clause has been added only > because it is in the boiler plate, and not because the draft contains > any code that needs it. It makes no sense whatsoever for the boilerplate to talk "Code Components" and there to be no "Code Components". Let's remove the word "Code Components" because there are no "Code Components". Similarly to the reason why we put the Abstract first because it should be there first. > It is not up to the IETF to decide what licenses the implementations > choose to use. Well, but why does IETF force us to use the word "BSD" in the RPL document? Isn't that a license? > The only code that the IETF can assert copyright over is code that is > part of an RFC or other IETF document. In this case, there seems to > be nosuch code. > >>>> In the past, when people tried to port the TCP/IP stack from >>>> BSD to linux they realize (after months of work) the BSD >>>> licensing would prevent them, and rewrote it from scratch. >>> >>> I don't think this is true. Do you have a reference? >> >> I am not sure which part you believe untrue? >> >> Sorry, I don't have a reference, just some thoughts not published >> anywhere else. > > I think you may be recalling the problems that existed with the old > 4-clause BSD license. This license was used for the original BSD > code, and included an "advertising clause" which was deemed to be > non-compatible with the GPL. This may have prompted people to rewrite > the TCP/IP stack under the GPL. Also, this was possible because the TCP/IP RFCs did not have such "BSD" word in them. It was a great advantage to have two different implementations of TCP/IP, interoperable. Were the RFCs to say "BSD" then the GPL'ed stack would have been impossible. > This 4th clause has subsequently been removed and the BSD license is > now compatible with the GPL. You'll find it on the list here: > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses LKe't s not use https redirections, it's very difficult. That same URL you post as indication says it's risky to recommend the use of the "BSD license" and the X11 should be referred to instead. I don't care about them. I want no license in this document RPL. If there should be one, then let the implementer (yes, the implementer) write it. Alex From alexandru.petrescu@gmail.com Wed Feb 10 12:08:05 2010 Return-Path: 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 02BD03A7797 for ; Wed, 10 Feb 2010 12:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 xWrgNUnKxnER for ; Wed, 10 Feb 2010 12:08:04 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id C1D853A7795 for ; Wed, 10 Feb 2010 12:08:02 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B3218D4819D; Wed, 10 Feb 2010 21:09:10 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id A91F9D4808B; Wed, 10 Feb 2010 21:09:07 +0100 (CET) Message-ID: <4B731260.4050709@gmail.com> Date: Wed, 10 Feb 2010 21:09:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Philip Levis References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> In-Reply-To: <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:08:05 -0000 Le 10/02/2010 20:25, Philip Levis a écrit : [blah] > The basic point is that you can take code under a BSD license > and release it under a GPL license. The original BSD license remains. I think it's impossible to take BSD code and turn it into GPL code. Let me say that I have my strong reasons to not want that "BSD" word in this draft. Or otherwise make it experimental. Alex > While Theo de Raadt has commented on how he finds this personally > offensive[1], you can of course do it. > >> >>>> Can RPL be implemented in a Open Source project? >>> >>> Yes. >> >> Which Open Source license is compatible with RPL document? > > Please go read about open source licensing and all of the ways in which > different licenses can interact. As you might imagine, this information > is very available on the Internet. Let's not clog up this list with the > basics of a quite mature area of concern which isn't at all ROLL-specific. > >> >>>> In the past, when people tried to port the TCP/IP stack from BSD >>>> to linux they realize (after months of work) the BSD licensing >>>> would prevent them, and rewrote it from scratch. >>> >>> I don't think this is true. Do you have a reference? >> >> I am not sure which part you believe untrue? >> >> Sorry, I don't have a reference, just some thoughts not published >> anywhere else. >> >> I noticed there are only few TCP/IP stacks in wide use, and are >> either the BSD's or the linux's. And knowing the linux's came much >> later after BSD, and after BSD was already integrated in many commercial >> systems, one wonders why did they write a stack from scratch for linux? >> I suppose it was because of the licensing. > > So, you don't know, made something up based on your best (clearly > uninformed) guess, and then asserted it as truth? That's not a good > approach for anyone to take your concerns seriously. > > Phil > > [1] http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code > > From alexandru.petrescu@gmail.com Wed Feb 10 12:15:30 2010 Return-Path: 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 138063A75D8 for ; Wed, 10 Feb 2010 12:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 Cfjg5rpdfc+u for ; Wed, 10 Feb 2010 12:15:25 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 361D93A7792 for ; Wed, 10 Feb 2010 12:15:05 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 33130D48231; Wed, 10 Feb 2010 21:16:13 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2C087D480EA; Wed, 10 Feb 2010 21:16:11 +0100 (CET) Message-ID: <4B731407.5020003@gmail.com> Date: Wed, 10 Feb 2010 21:16:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Philip Levis References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> In-Reply-To: <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:15:30 -0000 Le 10/02/2010 20:25, Philip Levis a écrit : > [...] > Please go read about open source licensing and all of the ways in > which different licenses can interact. As you might imagine, this > information is very available on the Internet. Let's not clog up this > list with the basics of a quite mature area of concern which isn't at > all ROLL-specific. WEll thanks for the redirection, I just went to the IPR WG and made some questions about this. I'll stop clogging this list about this. [...] > So, you don't know, made something up based on your best (clearly > uninformed) guess, and then asserted it as truth? That's not a good > approach for anyone to take your concerns seriously. Philip, I once wrote an open source license. I don't want the word "BSD" in this RPL document. Alex > > Phil > > [1] http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code > > From alexandru.petrescu@gmail.com Wed Feb 10 12:19:28 2010 Return-Path: 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 3F0963A7479 for ; Wed, 10 Feb 2010 12:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 HhcWuCJtitSH for ; Wed, 10 Feb 2010 12:19:27 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 1AE943A7464 for ; Wed, 10 Feb 2010 12:19:25 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 15D00D48201; Wed, 10 Feb 2010 21:20:33 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0BE23D480A3; Wed, 10 Feb 2010 21:20:31 +0100 (CET) Message-ID: <4B73150B.5040403@gmail.com> Date: Wed, 10 Feb 2010 21:20:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Adam Dunkels References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> In-Reply-To: <4B731230.3090904@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:19:28 -0000 Le 10/02/2010 21:08, Adam Dunkels a écrit : > Alexandru Petrescu wrote: >> I meant linux kernel. Is there some BSD code in the linux kernel? > > Plenty. Here are a few examples, from a quick search: > http://lxr.linux.no/#linux+v2.6.32/include/acpi/actbl.h#L11 > http://lxr.linux.no/#linux+v2.6.32/include/acpi/acexcep.h#L11 > http://lxr.linux.no/#linux+v2.6.32/scripts/unifdef.c#L4 > http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14 Ah I see what you mean. For example Intel may ask linux community to include their license in the kernel. I don't want IETF to ask the linux community to include the "BSD" license, whatever version of BSD that may be. If IETF has to ask anybody implementing RFCs to include some license then let it be GPL and not some BSD derivative. I am wondering why am I spending time on this anyways... :-( Alex > > /adam From nvt@sics.se Wed Feb 10 12:30:48 2010 Return-Path: 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 F419C28C276 for ; Wed, 10 Feb 2010 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-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 hRzFaCDjMMPE for ; Wed, 10 Feb 2010 12:30:47 -0800 (PST) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by core3.amsl.com (Postfix) with ESMTP id D70E528C274 for ; Wed, 10 Feb 2010 12:30:46 -0800 (PST) Received: from c83-250-220-173.bredband.comhem.se ([83.250.220.173]:50795 helo=[192.168.0.10]) by ch-smtp01.sth.basefarm.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NfJDu-0005YP-3z for roll@ietf.org; Wed, 10 Feb 2010 21:31:48 +0100 Message-ID: <4B7317AC.40203@sics.se> Date: Wed, 10 Feb 2010 21:31:40 +0100 From: Nicolas Tsiftes User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> In-Reply-To: <4B73150B.5040403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 83.250.220.173 X-Scan-Result: No virus found in message 1NfJDu-0005YP-3z. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1NfJDu-0005YP-3z e166c0d053705b994e99d42337da08ca Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:30:48 -0000 Alexandru Petrescu skrev: > Ah I see what you mean. > > For example Intel may ask linux community to include their license in > the kernel. > > I don't want IETF to ask the linux community to include the "BSD" > license, whatever version of BSD that may be. > > If IETF has to ask anybody implementing RFCs to include some license > then let it be GPL and not some BSD derivative. > > I am wondering why am I spending time on this anyways... :-( > > Alex Hello Alex, First, if there would have been any code in the draft, which there isn't by the way, the implementor is free to neglect it and write own code. Second, if the license would've been GPL instead of BSD, and the implementor for some unknown reason would'vee been forced to include this nonexistent code in the implementation, the license would've made it impossible to include in BSD kernels. On the other hand, the nonexistent BSD-licensed code would be possible to include in both BSD-licensed and closed-source kernels (which the BSD license allows.) Nicolas From osk@exegin.com Wed Feb 10 12:33:46 2010 Return-Path: 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 53A9A28C257 for ; Wed, 10 Feb 2010 12:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hzvMQNVQeFWC for ; Wed, 10 Feb 2010 12:33:45 -0800 (PST) Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id 68AAF3A7796 for ; Wed, 10 Feb 2010 12:33:41 -0800 (PST) Received: by pxi8 with SMTP id 8so223776pxi.19 for ; Wed, 10 Feb 2010 12:34:50 -0800 (PST) Received: by 10.115.133.25 with SMTP id k25mr480243wan.134.1265834090073; Wed, 10 Feb 2010 12:34:50 -0800 (PST) Received: from ?172.16.1.66? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 23sm1849946pzk.8.2010.02.10.12.34.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 12:34:49 -0800 (PST) Message-ID: <4B73186A.8000904@exegin.com> Date: Wed, 10 Feb 2010 12:34:50 -0800 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> In-Reply-To: <4B73150B.5040403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:33:46 -0000 Alex, As I understand the BSD license and how it is involved with the RPL specification, we're not imposing any license on any implementation of the RPL specification. The copyright license applies to the text of the RPL document which may contain (pseudo)code or MIB structures, and only comes into effect if you copy that text from the specification. An implementation of RPL is not considered a copy of the specification, and can fall under any license the software author chooses, be it BSD, GPL or something entirely proprietary. Even so, If we allow the proposition that the copyright license for the RPL specification gets carried over to any implementations of that spec, then a modified BSD license is an excellent choice, since it is not a copyleft license and can be integrated with almost any other license (including the GPL). The GPL would be an extremely bad choice for RPL, since the copyleft provisions would effectively prohibit implementing RPL in anything other than the Linux network stack. In particular, you couldn't add RPL to the BSD stack. As an additional question, why do we need a license anyways? Is there any danger in making these code and MIB components public domain? Thanks, Owen Alexandru Petrescu wrote: > Le 10/02/2010 21:08, Adam Dunkels a écrit : >> Alexandru Petrescu wrote: >>> I meant linux kernel. Is there some BSD code in the linux kernel? >> >> Plenty. Here are a few examples, from a quick search: >> http://lxr.linux.no/#linux+v2.6.32/include/acpi/actbl.h#L11 >> http://lxr.linux.no/#linux+v2.6.32/include/acpi/acexcep.h#L11 >> http://lxr.linux.no/#linux+v2.6.32/scripts/unifdef.c#L4 >> http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14 > > Ah I see what you mean. > > For example Intel may ask linux community to include their license in > the kernel. > > I don't want IETF to ask the linux community to include the "BSD" > license, whatever version of BSD that may be. > > If IETF has to ask anybody implementing RFCs to include some license > then let it be GPL and not some BSD derivative. > > I am wondering why am I spending time on this anyways... :-( > > Alex > >> >> /adam > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Feb 10 12:40:39 2010 Return-Path: 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 F2E113A75FE for ; Wed, 10 Feb 2010 12:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_05=-1.11, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6] 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 VNWUVKbj3Umf for ; Wed, 10 Feb 2010 12:40:38 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DE0D33A75D5 for ; Wed, 10 Feb 2010 12:40:36 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E7B01D48094; Wed, 10 Feb 2010 21:41:44 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D3915D48132; Wed, 10 Feb 2010 21:41:41 +0100 (CET) Message-ID: <4B731A02.4000804@gmail.com> Date: Wed, 10 Feb 2010 21:41:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Nicolas Tsiftes References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> <4B7317AC.40203@sics.se> In-Reply-To: <4B7317AC.40203@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:40:39 -0000 Le 10/02/2010 21:31, Nicolas Tsiftes a écrit : > Alexandru Petrescu skrev: >> Ah I see what you mean. >> >> For example Intel may ask linux community to include their license >> in the kernel. >> >> I don't want IETF to ask the linux community to include the "BSD" >> license, whatever version of BSD that may be. >> >> If IETF has to ask anybody implementing RFCs to include some >> license then let it be GPL and not some BSD derivative. >> >> I am wondering why am I spending time on this anyways... :-( >> >> Alex > > Hello Alex, > > First, if there would have been any code in the draft, There is a table in the IANA section which will soon contain values. There are certainly some names which will be used in the macro definitions. The "Code Components" as per IETF definition may include these. Now, what is "Code"? If you wish we can discuss it too. > which there isn't by the way, the implementor is free to neglect it > and write own code. I think that if I use a value from the RPL IANA table and some macro from the text then I no longer write own code, but reuse from the draft. Which is normal. What I don't want is to have that BSD tag on the values from the IANA table. Or, Code Components seem to. > Second, if the license would've been GPL instead of BSD, and the > implementor for some unknown reason would'vee been forced to include > this nonexistent code in the implementation, the license would've > made it impossible to include in BSD kernels. A-ha! Even worse! So if this draft said "GPL" the the BSD community wouldn't be happy at all. So why should the GPL community be happy when this draft says "BSD"? > On the other hand, the nonexistent BSD-licensed code would be > possible to include in both BSD-licensed and closed-source kernels > (which the BSD license allows.) Non-existent code? Why does the preamble say "Code Components extracted from this draft"? This makes no sense, please remove "Code Components" from the preamble and the BSD word too. Please remove all that's not necessary and that can cause confusion. Alex From jdrake@juniper.net Wed Feb 10 12:54:04 2010 Return-Path: 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 0DA7E3A748C for ; Wed, 10 Feb 2010 12:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] 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 rt4-qpC6xwNv for ; Wed, 10 Feb 2010 12:54:03 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id EF7383A682A for ; Wed, 10 Feb 2010 12:54:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS3MdLZzHR7DzVhaLarv2eZ78zaitNpYa@postini.com; Wed, 10 Feb 2010 12:55:15 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 10 Feb 2010 12:54:00 -0800 From: John E Drake To: Alexandru Petrescu , Nicolas Tsiftes Date: Wed, 10 Feb 2010 12:53:59 -0800 Thread-Topic: [Roll] Software Licensing and RPL Thread-Index: AcqqkXzBjVA0IEw/QwO9y54WZFpG0wAAZ0Pw Message-ID: <5E893DB832F57341992548CDBB3331639804FF738F@EMBX01-HQ.jnpr.net> References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> <4B7317AC.40203@sics.se> <4B731A02.4000804@gmail.com> In-Reply-To: <4B731A02.4000804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:54:04 -0000 It sounds as though this is much ado about nothing > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Wednesday, February 10, 2010 12:42 PM > To: Nicolas Tsiftes > Cc: roll@ietf.org > Subject: Re: [Roll] Software Licensing and RPL >=20 > Le 10/02/2010 21:31, Nicolas Tsiftes a =E9crit : > > Alexandru Petrescu skrev: > >> Ah I see what you mean. > >> > >> For example Intel may ask linux community to include their license > >> in the kernel. > >> > >> I don't want IETF to ask the linux community to include the "BSD" > >> license, whatever version of BSD that may be. > >> > >> If IETF has to ask anybody implementing RFCs to include some > >> license then let it be GPL and not some BSD derivative. > >> > >> I am wondering why am I spending time on this anyways... :-( > >> > >> Alex > > > > Hello Alex, > > > > First, if there would have been any code in the draft, >=20 > There is a table in the IANA section which will soon contain values. > There are certainly some names which will be used in the macro > definitions. >=20 > The "Code Components" as per IETF definition may include these. >=20 > Now, what is "Code"? If you wish we can discuss it too. >=20 > > which there isn't by the way, the implementor is free to neglect it > > and write own code. >=20 > I think that if I use a value from the RPL IANA table and some macro > from the text then I no longer write own code, but reuse from the draft. > Which is normal. >=20 > What I don't want is to have that BSD tag on the values from the IANA > table. Or, Code Components seem to. >=20 > > Second, if the license would've been GPL instead of BSD, and the > > implementor for some unknown reason would'vee been forced to include > > this nonexistent code in the implementation, the license would've > > made it impossible to include in BSD kernels. >=20 > A-ha! Even worse! So if this draft said "GPL" the the BSD community > wouldn't be happy at all. So why should the GPL community be happy when > this draft says "BSD"? >=20 > > On the other hand, the nonexistent BSD-licensed code would be > > possible to include in both BSD-licensed and closed-source kernels > > (which the BSD license allows.) >=20 > Non-existent code? Why does the preamble say "Code Components extracted > from this draft"? >=20 > This makes no sense, please remove "Code Components" from the preamble > and the BSD word too. >=20 > Please remove all that's not necessary and that can cause confusion. >=20 > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Feb 10 12:56:11 2010 Return-Path: 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 027643A77A6 for ; Wed, 10 Feb 2010 12:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 rX7D4m1wGQvo for ; Wed, 10 Feb 2010 12:56:09 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 938BC3A77A4 for ; Wed, 10 Feb 2010 12:56:07 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 13A8DD4818A; Wed, 10 Feb 2010 21:57:15 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id AE601D48116; Wed, 10 Feb 2010 21:57:12 +0100 (CET) Message-ID: <4B731DA5.4010701@gmail.com> Date: Wed, 10 Feb 2010 21:57:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Owen Kirby References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> <4B73186A.8000904@exegin.com> In-Reply-To: <4B73186A.8000904@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:56:11 -0000 Le 10/02/2010 21:34, Owen Kirby a écrit : > Alex, > > As I understand the BSD license and how it is involved with the RPL > specification, we're not imposing any license on any implementation > of the RPL specification. The copyright license applies to the text > of the Copyright applying to text is ok. But BSD applies to code, not to text ("provided AS-IS" - who cares about text being "AS-IS"?). Why talking BSD if there's no code? It would be sufficient to talk only Copyright. > RPL document which may contain (pseudo)code or MIB structures, and > only comes into effect if you copy that text from the specification. What if I use a value from the table, and a name as a macro? Does that BSD license apply? I am tempted to say yes because IETF Trust seems to say so in its description of "Code Components" - it says more than just MIB - tables and values too. BEsides, not even the MIBs - I don't want MIBs tagged BSD. Ah if only I knew this BSD default preamble... I wouldn't have contributed to so many discussions, time spent for nothing, really. > An implementation of RPL is not considered a copy of the > specification, and can fall under any license the software author > chooses, be it BSD, GPL or something entirely proprietary. I won't blindly submit example code to this draft knowing it will be automatically tagged BSD. No thanks. And as an implementer having implemented some RFCs I often said thanks when I found C code in that RFC. But this document with that "BSD" on it and without code, this draft won't have many thanks from GPL implementers. And they won't submit GPL code either. > Even so, If we allow the proposition that the copyright license for > the RPL specification gets carried over to any implementations of > that spec, then a modified BSD license is an excellent choice, since > it is not a copyleft license and can be integrated with almost any > other license (including the GPL). The GPL would be an extremely bad > choice for RPL, since the copyleft provisions would effectively > prohibit implementing RPL in anything other than the Linux network > stack. In particular, you couldn't add RPL to the BSD stack. Well, if it is so (GPL code couldn't make it into BSD kernel) then don't tag the draft "GPL" either. Don't tag it anything, just like before, let the implementer choose the license. > As an additional question, why do we need a license anyways? Is > there any danger in making these code and MIB components public > domain? I agree in this sense. Don't tag _any_ software license on the Internet Draft RPL. If there is a license to be tagged then make it GPL. Alex > > Thanks, Owen > > Alexandru Petrescu wrote: >> Le 10/02/2010 21:08, Adam Dunkels a écrit : >>> Alexandru Petrescu wrote: >>>> I meant linux kernel. Is there some BSD code in the linux >>>> kernel? >>> >>> Plenty. Here are a few examples, from a quick search: >>> http://lxr.linux.no/#linux+v2.6.32/include/acpi/actbl.h#L11 >>> http://lxr.linux.no/#linux+v2.6.32/include/acpi/acexcep.h#L11 >>> http://lxr.linux.no/#linux+v2.6.32/scripts/unifdef.c#L4 >>> http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14 >> >> Ah I see what you mean. >> >> For example Intel may ask linux community to include their license >> in the kernel. >> >> I don't want IETF to ask the linux community to include the "BSD" >> license, whatever version of BSD that may be. >> >> If IETF has to ask anybody implementing RFCs to include some >> license then let it be GPL and not some BSD derivative. >> >> I am wondering why am I spending time on this anyways... :-( >> >> Alex >> >>> >>> /adam >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Wed Feb 10 13:11:29 2010 Return-Path: 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 BD80E3A75FC for ; Wed, 10 Feb 2010 13:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6] 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 Bsk1u2CvCUmf for ; Wed, 10 Feb 2010 13:11:28 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 8E73F3A6A80 for ; Wed, 10 Feb 2010 13:11:26 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 18F5DD4811D; Wed, 10 Feb 2010 22:12:34 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id BED0AD480A9; Wed, 10 Feb 2010 22:12:31 +0100 (CET) Message-ID: <4B73213C.5020800@gmail.com> Date: Wed, 10 Feb 2010 22:12:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: John E Drake References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B730840.2020701@sics.se> <4B730FB6.5060301@gmail.com> <4B731230.3090904@sics.se> <4B73150B.5040403@gmail.com> <4B7317AC.40203@sics.se> <4B731A02.4000804@gmail.com> <5E893DB832F57341992548CDBB3331639804FF738F@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639804FF738F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: "roll@ietf.org" Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:11:29 -0000 Le 10/02/2010 21:53, John E Drake a écrit : > It sounds as though this is much ado about nothing WEll ok, I can stop posting in this WG as well. (after having seen so many times complains about licensing _after_ the fact - as if people did not know before that the preamble part (boilerplate) is there to mean something). Alex > >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Wednesday, February 10, 2010 12:42 PM To: Nicolas Tsiftes >> Cc: roll@ietf.org Subject: Re: [Roll] Software Licensing and RPL >> >> Le 10/02/2010 21:31, Nicolas Tsiftes a écrit : >>> Alexandru Petrescu skrev: >>>> Ah I see what you mean. >>>> >>>> For example Intel may ask linux community to include their >>>> license in the kernel. >>>> >>>> I don't want IETF to ask the linux community to include the >>>> "BSD" license, whatever version of BSD that may be. >>>> >>>> If IETF has to ask anybody implementing RFCs to include some >>>> license then let it be GPL and not some BSD derivative. >>>> >>>> I am wondering why am I spending time on this anyways... :-( >>>> >>>> Alex >>> >>> Hello Alex, >>> >>> First, if there would have been any code in the draft, >> >> There is a table in the IANA section which will soon contain >> values. There are certainly some names which will be used in the >> macro definitions. >> >> The "Code Components" as per IETF definition may include these. >> >> Now, what is "Code"? If you wish we can discuss it too. >> >>> which there isn't by the way, the implementor is free to neglect >>> it and write own code. >> >> I think that if I use a value from the RPL IANA table and some >> macro from the text then I no longer write own code, but reuse >> from the draft. Which is normal. >> >> What I don't want is to have that BSD tag on the values from the >> IANA table. Or, Code Components seem to. >> >>> Second, if the license would've been GPL instead of BSD, and the >>> implementor for some unknown reason would'vee been forced to >>> include this nonexistent code in the implementation, the license >>> would've made it impossible to include in BSD kernels. >> >> A-ha! Even worse! So if this draft said "GPL" the the BSD >> community wouldn't be happy at all. So why should the GPL >> community be happy when this draft says "BSD"? >> >>> On the other hand, the nonexistent BSD-licensed code would be >>> possible to include in both BSD-licensed and closed-source >>> kernels (which the BSD license allows.) >> >> Non-existent code? Why does the preamble say "Code Components >> extracted from this draft"? >> >> This makes no sense, please remove "Code Components" from the >> preamble and the BSD word too. >> >> Please remove all that's not necessary and that can cause >> confusion. >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From cabo@tzi.org Wed Feb 10 13:12:51 2010 Return-Path: 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 622CF3A77B4 for ; Wed, 10 Feb 2010 13:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 IGSmG7UB3ZZR for ; Wed, 10 Feb 2010 13:12:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 807533A75FC for ; Wed, 10 Feb 2010 13:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1ALDqoa002419; Wed, 10 Feb 2010 22:13:52 +0100 (CET) Received: from [192.168.217.101] (p5489DE0C.dip.t-dialin.net [84.137.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BA494E95C; Wed, 10 Feb 2010 22:13:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4B731072.5060201@gmail.com> Date: Wed, 10 Feb 2010 22:13:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE6AC61-B29B-4F31-B04E-8C7DDFA487B0@tzi.org> References: <4B731072.5060201@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) Cc: ROLL WG Subject: Re: [Roll] I want the word "GPL" in the RPL draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:12:51 -0000 On Feb 10, 2010, at 21:00, Alexandru Petrescu wrote: > I don't want BSD in this document. I wonder how "BSD" landed there. Wrong working group. I don't think the ROLL WG wants to discuss the IETF Trust Legal = Provisions. (And the WG couldn't change them if it wanted.) I could now start educating you about why the TLP reflect exactly the = right decision here and even provides what you appear to want, but that = message would also be "wrong working group". Gruesse, Carsten From alexandru.petrescu@gmail.com Wed Feb 10 13:42:00 2010 Return-Path: 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 2F5B23A7603 for ; Wed, 10 Feb 2010 13:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 gKEACjU8z29l for ; Wed, 10 Feb 2010 13:41:59 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4386C3A75F9 for ; Wed, 10 Feb 2010 13:41:57 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 73831D48102; Wed, 10 Feb 2010 22:43:05 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 57447D48092; Wed, 10 Feb 2010 22:43:03 +0100 (CET) Message-ID: <4B732864.3080400@gmail.com> Date: Wed, 10 Feb 2010 22:43:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <4B731072.5060201@gmail.com> <6FE6AC61-B29B-4F31-B04E-8C7DDFA487B0@tzi.org> In-Reply-To: <6FE6AC61-B29B-4F31-B04E-8C7DDFA487B0@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100210-0, 10/02/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] I want the word "GPL" in the RPL draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:42:00 -0000 Le 10/02/2010 22:13, Carsten Bormann a écrit : > On Feb 10, 2010, at 21:00, Alexandru Petrescu wrote: > >> I don't want BSD in this document. I wonder how "BSD" landed >> there. > > Wrong working group. > > I don't think the ROLL WG wants to discuss the IETF Trust Legal > Provisions. (And the WG couldn't change them if it wanted.) > > I could now start educating you about why the TLP reflect exactly the > right decision here and even provides what you appear to want, but > that message would also be "wrong working group". Carsten - what I want is to either (1) no license in this draft (no BSD, no GPL) or (2) if a license is absolutely needed then GPL. Without that I have a very hard time motivating me to contribute to this WG technically. Also you know that I am used to contribute technically to some WGs and I always did freely without worry. Well yes, you may have discarded my comments in some WGs but I always felt ok to post. Now that I see everybody's happy to that "BSD" word I am really wondering if I care at all about IETF in general (its documents being so preambled). Imagine I have to translate "copyleft" in order to pre-understand IETF before posting. Thanks and a smiley, Alex > > Gruesse, Carsten > > From THirou@convergencewireless.com Wed Feb 10 14:11:53 2010 Return-Path: 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 170013A74E3 for ; Wed, 10 Feb 2010 14:11:53 -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 K3J0r33UxfBQ for ; Wed, 10 Feb 2010 14:11:49 -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 42CB43A7571 for ; Wed, 10 Feb 2010 14:11:49 -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: Wed, 10 Feb 2010 13:32:48 -0800 Message-ID: <6881400D22DB1E4F8069C27BEBA58C450C9849@sbs01.cwi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Roll IPR issues thread-index: AcqqbQ+05ncPQCBPRI+7FDoFTpoClwAKKTbw From: "Tim Hirou" To: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:11:53 -0000 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. =20 -----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: >=20 > 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. =20 >=20 > 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.=20 >=20 > 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. =20 >=20 > 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.=20 >=20 > 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: >=20 > 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) >=20 > 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. =20 >=20 >=20 > We see the practice of making this kind of declaration (combining our > commitment to not assert and the "defensive suspension") on the vast > majority=20 > of IETF I-Ds and RFCs where we have essential patents as being both=20 > 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. >=20 > 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. =20 >=20 > I hope that this helps clarify the issues and move the discussion to > resolution. >=20 > Best regards, >=20 > Dan Lang >=20 >=20 >=20 >=20 >=20 >=20 > Dan Lang > Director, Intellectual Property > Legal Services > Cisco Systems, Inc. >=20 >=20 >=20 > _______________________________________________ > 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 From tzeta.tsao@ekasystems.com Wed Feb 10 14:19:53 2010 Return-Path: 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 9305928C141 for ; Wed, 10 Feb 2010 14:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ChfQ2lfZQqxh for ; Wed, 10 Feb 2010 14:19:46 -0800 (PST) Received: from web304.biz.mail.mud.yahoo.com (web304.biz.mail.mud.yahoo.com [68.142.199.180]) by core3.amsl.com (Postfix) with SMTP id 98F6028C0FD for ; Wed, 10 Feb 2010 14:19:45 -0800 (PST) Received: (qmail 14636 invoked by uid 60001); 10 Feb 2010 22:20:55 -0000 Message-ID: <35785.12984.qm@web304.biz.mail.mud.yahoo.com> X-YMail-OSG: M3zhMbQVM1m5cl52pkvGmAIplN_Juiz_w52F4NaRs8oGh5pXKl3hhhg0akQuPD0nO4MbvpB4oxyJvc6LlbYh0FXPhNFf8gntG7uIHMgrALkB6AcpFH.L8UZ5OTKtQTtaLkUdQIkQ62Xj0rUDSpPqyDJnlDnfzONlQqUm48E_KXqRlM57Elfy9LRF.BwDyWuOxYCmFfd3tgMe10_hHyDETNdKL87wMB2AvdptN79PATm90PUTpcMuOOYPpb.nsZ6esS3nZinN6slKtOeGSvWehbvXlp.yXbRuqSJ5nyHgRLGWefR8wXPbjJhhrcHopKsiNBnlNXfAQalYVo_uWZHzi0GxUUwzR294IeQ1I6kS1jRvz8zqnjtvpG5ndrB5PAgVwxlOARermzmKHC2Z19JO_xUKcbsStpENwcr. Received: from [96.255.4.156] by web304.biz.mail.mud.yahoo.com via HTTP; Wed, 10 Feb 2010 14:20:54 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <6881400D22DB1E4F8069C27BEBA58C450C9849@sbs01.cwi.local> Date: Wed, 10 Feb 2010 14:20:54 -0800 (PST) From: Tzeta Tsao To: Tim Hirou , roll@ietf.org In-Reply-To: <6881400D22DB1E4F8069C27BEBA58C450C9849@sbs01.cwi.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:19:53 -0000 Hi Tim, Would you elaborate why the IPR concern prevents other approaches to contend? Regards, Tzeta ----- Original Message ---- From: Tim Hirou 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 From Ted.Humpal@jci.com Wed Feb 10 16:22:35 2010 Return-Path: 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 B9B823A7247 for ; Wed, 10 Feb 2010 16:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] 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 KWAHcEu4gyUf for ; Wed, 10 Feb 2010 16:22:35 -0800 (PST) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id B7ADE3A68AC for ; Wed, 10 Feb 2010 16:22:34 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKS3NOEoynapMwAFUDCc7VKbG7uBjvlD+3@postini.com; Wed, 10 Feb 2010 16:23:47 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010021018234663-161642 ; Wed, 10 Feb 2010 18:23:46 -0600 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Ted.Humpal@jci.com To: roll@ietf.org Message-ID: Date: Wed, 10 Feb 2010 18:23:37 -0600 X-Mailer: Lotus Domino Web Server Release 8.0.1 HF1280 July 09, 2009 X-MIMETrack: Serialize by HTTP Server on jwimkns6.na.jci.com/NA/Johnson_Controls(Release 8.0.1 HF1280|July 09, 2009) at 02/10/2010 06:23:37 PM, Serialize complete at 02/10/2010 06:23:37 PM, Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/10/2010 06:23:43 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/10/2010 06:23:46 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/10/2010 06:23:50 PM, Serialize complete at 02/10/2010 06:23:50 PM MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 00:22:35 -0000
As requested - for the general health check on this issue.=
 
Just a note to indicate that as a developer of end products, I al= so have concerns about
the Cisco IPR as currently written.
 
Ted Humpal
 
= From Jerald.P.Martocci@jci.com Wed Feb 10 16:46:48 2010 Return-Path: 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 328EB3A77EA for ; Wed, 10 Feb 2010 16:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] 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 8jQsmtkSdz0V for ; Wed, 10 Feb 2010 16:46:47 -0800 (PST) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id 292033A75DB for ; Wed, 10 Feb 2010 16:46:47 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKS3NTv2GFKBEMS9QRUIVpmB7PWngcYy83@postini.com; Wed, 10 Feb 2010 16:47:59 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010021018491851-162828 ; Wed, 10 Feb 2010 18:49:18 -0600 To: JP Vasseur MIME-Version: 1.0 X-KeepSent: 14271E89:B879743C-862576C7:0003D208; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 10 Feb 2010 18:47:36 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/10/2010 06:47:42 PM, Serialize complete at 02/10/2010 06:47:42 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/10/2010 06:49:18 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/10/2010 06:49:35 PM, Serialize complete at 02/10/2010 06:49:35 PM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 00:46:48 -0000
JP,

Per your request on the ROLL mailing list a few weeks ago, I believe that ROLL should develop an alternate means to implementing RPL that works around the Cisco IPR.

Regards,

Jerry


From THirou@convergencewireless.com Wed Feb 10 16:51:27 2010 Return-Path: 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 45FBB28B56A for ; Wed, 10 Feb 2010 16:51:27 -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 hyYemU0YMlBB for ; Wed, 10 Feb 2010 16:51:26 -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 BD5103A6CA8 for ; Wed, 10 Feb 2010 16:51:25 -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: Wed, 10 Feb 2010 16:24:16 -0800 Message-ID: <6881400D22DB1E4F8069C27BEBA58C450C9854@sbs01.cwi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Roll IPR issues thread-index: AcqqoIUumfz2vh2mR+K5M15Ms9WDjQACr+ow From: "Tim Hirou" To: "Tzeta Tsao" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 00:51:27 -0000 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]=20 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 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: >=20 > 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. =20 >=20 > 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.=20 >=20 > 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. =20 >=20 > 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.=20 >=20 > 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: >=20 > 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) >=20 > 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. =20 >=20 >=20 > We see the practice of making this kind of declaration (combining our > commitment to not assert and the "defensive suspension") on the vast > majority=20 > of IETF I-Ds and RFCs where we have essential patents as being both=20 > 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. >=20 > 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. =20 >=20 > I hope that this helps clarify the issues and move the discussion to > resolution. >=20 > Best regards, >=20 > Dan Lang >=20 >=20 >=20 >=20 >=20 >=20 > Dan Lang > Director, Intellectual Property > Legal Services > Cisco Systems, Inc. >=20 >=20 >=20 > _______________________________________________ > 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 From tzeta.tsao@ekasystems.com Wed Feb 10 18:21:32 2010 Return-Path: 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 5BF123A764A for ; Wed, 10 Feb 2010 18:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 6utCUm41cMoT for ; Wed, 10 Feb 2010 18:21:28 -0800 (PST) Received: from web305.biz.mail.mud.yahoo.com (web305.biz.mail.mud.yahoo.com [68.142.199.181]) by core3.amsl.com (Postfix) with SMTP id 482693A763E for ; Wed, 10 Feb 2010 18:21:26 -0800 (PST) Received: (qmail 20452 invoked by uid 60001); 11 Feb 2010 02:22:36 -0000 Message-ID: <373238.19903.qm@web305.biz.mail.mud.yahoo.com> X-YMail-OSG: yASk.ZsVM1likUmktedSHxtdZcaRWF2LqoklD0bz_mRDFsceYzR99byFfgZN0TVJ2mYyVbZgCYK_38vHGfedpZCwKiBnBicKZ0V29xpq35fqrpIFG7k7QcI8TLQU5kbV1wWWWcLy65LwxWqUBpu2xOfabav3_1zM2Smmp8UuUQFmz8tLlV58ardbKvM_lGfQ_V5bUaOZWdxTsT51L4YjzNlryIm4tB7jS.1VGmvm9k24JBcklDks5XloZj4cGIY1aEBtvKbv_Z5RnCCr3GCxJHOHCbT98gQ7ZlLV_42_ck1aQRTyt7eSX2Txb.43mB8iAVEbV_AoOWkYzC.arirdP9Gs0pEGm3hor55MlD6RhlrQ8Sbmi6ZXzv8L4Szdnnrtzkajq..b3kMbsD2XCA0Q2dI7t1hPG4PaPGk- Received: from [96.255.4.156] by web305.biz.mail.mud.yahoo.com via HTTP; Wed, 10 Feb 2010 18:22:36 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <6881400D22DB1E4F8069C27BEBA58C450C9854@sbs01.cwi.local> Date: Wed, 10 Feb 2010 18:22:36 -0800 (PST) From: Tzeta Tsao To: Tim Hirou In-Reply-To: <6881400D22DB1E4F8069C27BEBA58C450C9854@sbs01.cwi.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 02:21:32 -0000 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 To: Tzeta Tsao 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 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 From jonsmirl@gmail.com Wed Feb 10 19:07:37 2010 Return-Path: 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 1FB1328C10A for ; Wed, 10 Feb 2010 19:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9EcTPqLlSHin for ; Wed, 10 Feb 2010 19:07:36 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id CEDEC3A74F2 for ; Wed, 10 Feb 2010 19:07:35 -0800 (PST) Received: by qyk13 with SMTP id 13so519215qyk.31 for ; Wed, 10 Feb 2010 19:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=78bcTjRTFRauQUTFBvPggMUdU7oB2cq8UjotuHkrKsI=; b=xcVocdFjQWr39rYGstF0k5KCyoUNvQG6VEAShetyxGqOECHMjNQD5sAOlLUeEB+UAa AHJFAiW5wn5kLHff/u95gTaIhS+QuqBxUWWK9xfPtYDOto5ygk7qAD5qABqU5AAZFTwN HjwzYZzKcykz8Frfc9zNb9PNk4BscVLJFg0Mk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q5SkT9f3HzZmme2YDlG0Z2aAntKRuvi+mwU5SBe/W30fNQ/hiVLrrIXUXZv7xl0faI UyMG38V1qLaI6X76qzyH92JETB96k48ay5ozEyYHBVtU0nIkOL8UQ4Ly8DndwcrsKMOV c2XcXWUUJn3PVlfsbo8dmsqgkQXk0CZ1zDAec= MIME-Version: 1.0 Received: by 10.229.110.199 with SMTP id o7mr552214qcp.76.1265857726120; Wed, 10 Feb 2010 19:08:46 -0800 (PST) In-Reply-To: <4B731260.4050709@gmail.com> References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <3FED69B4-1F1D-4C04-A568-248201C1FEE7@cs.stanford.edu> <4B731260.4050709@gmail.com> Date: Wed, 10 Feb 2010 22:08:44 -0500 Message-ID: <9e4733911002101908m5de2c2cl307c43e8890250e6@mail.gmail.com> From: Jon Smirl To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 03:07:37 -0000 On Wed, Feb 10, 2010 at 3:09 PM, Alexandru Petrescu wrote: > Le 10/02/2010 20:25, Philip Levis a =E9crit : > [blah] >> >> The basic point is that you can take code under a BSD license >> and release it under a GPL license. The original BSD license remains. > > I think it's impossible to take BSD code and turn it into GPL code. The GPL license is a super set of BSD. Plenty of BSD code has been incorporated into the Linux kernel. I work on the Linux kernel and combining BSD and GPL code has been discussed in great detail. All of the kernel mode setting and direct rendering code is BSD licensed. Open source lawyers have written an explicit procedure for integrating BSD code into GPL software. I can find the document if needed. The key danger is taking patches made to the GPL code base back into the BSD code base, you don't want to inadvertently turn the BSD code into GPL code. An explicit step of also contributing the patch to the BSD code base is needed. Royalty bearing patents are completely incompatible with the GPL. The GPL requires the developer to redistribute code without royalty and for copying costs only. Nobody bothers with the copying cost so the code is effectively free. If RPL needs a patent royalty it will never go into the Linux kernel. To work around this companies like IBM grant royalty free patent licenses for use in GPL'd software. Putting a royalty requirement on the protocol will pretty much ensure that the Linux kernel people will build an alternative solution that is GPL compatible. Since virtually every home router in existence runs Linux, I'd hope that RPL can be added to the kernel so that it can easily be incorporated into these routers. Add $10 of 802.15.4 hardware and all of these routers can talk to smart meters, dimmers, thermostats, etc. > > Let me say that I have my strong reasons to not want that "BSD" word in t= his > draft. =A0Or otherwise make it experimental. > > Alex > >> While Theo de Raadt has commented on how he finds this personally >> offensive[1], you can of course do it. >> >>> >>>>> Can RPL be implemented in a Open Source project? >>>> >>>> Yes. >>> >>> Which Open Source license is compatible with RPL document? >> >> Please go read about open source licensing and all of the ways in which >> different licenses can interact. As you might imagine, this information >> is very available on the Internet. Let's not clog up this list with the >> basics of a quite mature area of concern which isn't at all ROLL-specifi= c. >> >>> >>>>> In the past, when people tried to port the TCP/IP stack from BSD >>>>> to linux they realize (after months of work) the BSD licensing >>>>> would prevent them, and rewrote it from scratch. >>>> >>>> I don't think this is true. Do you have a reference? >>> >>> I am not sure which part you believe untrue? >>> >>> Sorry, I don't have a reference, just some thoughts not published >>> anywhere else. >>> >>> I noticed there are only few TCP/IP stacks in wide use, and are >>> either the BSD's or the linux's. And knowing the linux's came much >>> later after BSD, and after BSD was already integrated in many commercia= l >>> systems, one wonders why did they write a stack from scratch for linux? >>> I suppose it was because of the licensing. >> >> So, you don't know, made something up based on your best (clearly >> uninformed) guess, and then asserted it as truth? That's not a good >> approach for anyone to take your concerns seriously. >> >> Phil >> >> [1] http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 Jon Smirl jonsmirl@gmail.com From jvasseur@cisco.com Wed Feb 10 21:28:32 2010 Return-Path: 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 BBAEE28C10A for ; Wed, 10 Feb 2010 21:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.643 X-Spam-Level: X-Spam-Status: No, score=-9.643 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 zBbXfZjVu8pu for ; Wed, 10 Feb 2010 21:28:31 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DA2AF28C0DC for ; Wed, 10 Feb 2010 21:28:31 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPMjc0utJV2a/2dsb2JhbACaenSlOZdWhFUE X-IronPort-AV: E=Sophos;i="4.49,449,1262563200"; d="scan'208,217";a="298166129" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2010 05:29:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o1B5TixA013990; Thu, 11 Feb 2010 05:29:44 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 06:29:43 +0100 Received: from [10.108.69.235] ([10.61.104.27]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 06:29:42 +0100 Message-Id: <22EEB0B2-68D7-498E-A722-D760563348E1@cisco.com> From: JP Vasseur To: Carsten Bormann , Alexandru Petrescu In-Reply-To: <6FE6AC61-B29B-4F31-B04E-8C7DDFA487B0@tzi.org> Content-Type: multipart/alternative; boundary=Apple-Mail-154--203826321 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 06:29:42 +0100 References: <4B731072.5060201@gmail.com> <6FE6AC61-B29B-4F31-B04E-8C7DDFA487B0@tzi.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Feb 2010 05:29:42.0894 (UTC) FILETIME=[36E3D0E0:01CAAADB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17186.004 X-TM-AS-Result: No--20.192700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: [Roll] * move that discussion to the appropriate WG * Re: I want the word "GPL" in the RPL draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 05:28:32 -0000 --Apple-Mail-154--203826321 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Alex, If I may intervene, Carsten is quite right here. I'd suggest to move that particular discussion to the appropriate WG. Many Thanks JP. On Feb 10, 2010, at 10:13 PM, Carsten Bormann wrote: > On Feb 10, 2010, at 21:00, Alexandru Petrescu wrote: > >> I don't want BSD in this document. I wonder how "BSD" landed there. > > Wrong working group. > > I don't think the ROLL WG wants to discuss the IETF Trust Legal > Provisions. > (And the WG couldn't change them if it wanted.) > > I could now start educating you about why the TLP reflect exactly > the right decision here and even provides what you appear to want, > but that message would also be "wrong working group". > > Gruesse, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-154--203826321 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Alex,

If = I may intervene, Carsten is quite right here. I'd suggest to move = that particular discussion to the 
appropriate = WG.

Many = Thanks

JP.

On Feb 10, = 2010, at 10:13 PM, Carsten Bormann wrote:

On = Feb 10, 2010, at 21:00, Alexandru Petrescu wrote:

I don't want BSD in this document.  I wonder how = "BSD" landed there.

Wrong working group.

I = don't think the ROLL WG wants to discuss the IETF Trust Legal = Provisions.
(And the WG couldn't change them if it wanted.)

I = could now start educating you about why the TLP reflect exactly the = right decision here and even provides what you appear to want, but that = message would also be "wrong working group".

Gruesse, = Carsten

_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-154--203826321-- From geoff@proto6.com Wed Feb 10 22:39:00 2010 Return-Path: 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 6B9BF3A750B for ; Wed, 10 Feb 2010 22:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 y5IhI7jM30pC for ; Wed, 10 Feb 2010 22:38:59 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 046493A7442 for ; Wed, 10 Feb 2010 22:38:58 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 0FB291808A; Wed, 10 Feb 2010 23:40:18 -0700 (MST) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o1B6e9SL024460; Wed, 10 Feb 2010 23:40:10 -0700 (MST) From: Geoff Mulligan To: Adam Dunkels In-Reply-To: <4B7308A0.7060008@sics.se> References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> Content-Type: text/plain; charset="UTF-8" Date: Wed, 10 Feb 2010 23:40:04 -0700 Message-Id: <1265870404.3523.7.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 06:39:00 -0000 Adam, So this is an interesting, how does someone writing open source code notify the the users of that code that the software is encumbered with patents, so that people that take the code understand that they are using software that comes with a license. geoff On Wed, 2010-02-10 at 20:27 +0100, Adam Dunkels wrote: > Alexandru Petrescu wrote: > > Le 10/02/2010 18:17, Philip Levis a écrit : > >> > >> On Feb 10, 2010, at 8:48 AM, Alexandru Petrescu wrote: > >> > >>> Can RPL be implemented in a linux kernel (GPL)? > >> > >> Yes. > > > > The draft says BSD (Berkeley Systems Distrib). The linux kernel is GPL > > (General Public License). I suppose there may be a contradiction, in > > the sense that all that runs in the linux kernel MUST be GPL, otherwise > > it's binary (no source available). > > > > What do you mean when you say 'Yes' to the question of linux kernel and > > RPL? > > There is nothing that prevents an implementation of RPL to adopt any > software license that the copyright holder may chose. RPL can be > implemented as non-open source software, as GPL free software, as > MIT/X11/BSD/Apache/whatever open source software. It is up to the > copyright holder and not up to the IETF to decide. The RPL draft does > not appear to contain any code or otherwise copyrightable tables. It > seems that the Code Components clause has been added only because it is > in the boiler plate, and not because the draft contains any code that > needs it. > > In any case, a 3-clause BSD-licensed RPL implementation can without > problems be combined with GPL code. I.e., such an implementation can be > included in the Linux kernel. A GPL licensed RPL implementation could > also be included in the Linux kernel. And so forth. It is not up to the > IETF to decide what licenses the implementations choose to use. The only > code that the IETF can assert copyright over is code that is part of an > RFC or other IETF document. In this case, there seems to be nosuch code. > > >>> In the past, when people tried to port the TCP/IP stack from BSD > >>> to linux they realize (after months of work) the BSD licensing > >>> would prevent them, and rewrote it from scratch. > >> > >> I don't think this is true. Do you have a reference? > > > > I am not sure which part you believe untrue? > > > > Sorry, I don't have a reference, just some thoughts not published > > anywhere else. > > I think you may be recalling the problems that existed with the old > 4-clause BSD license. This license was used for the original BSD code, > and included an "advertising clause" which was deemed to be > non-compatible with the GPL. This may have prompted people to rewrite > the TCP/IP stack under the GPL. > > This 4th clause has subsequently been removed and the BSD license is now > compatible with the GPL. You'll find it on the list here: > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses > > /adam From adam@sics.se Wed Feb 10 23:40:14 2010 Return-Path: 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 A9C503A6D47 for ; Wed, 10 Feb 2010 23:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 7ju-kI4cvkij for ; Wed, 10 Feb 2010 23:40:13 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id D36F53A68E9 for ; Wed, 10 Feb 2010 23:40:12 -0800 (PST) Received: from [10.1.1.139] (unknown [10.1.1.139]) by letter.sics.se (Postfix) with ESMTPS id 2374A4001B; Thu, 11 Feb 2010 08:41:25 +0100 (CET) Message-ID: <4B73B49A.2070006@sics.se> Date: Thu, 11 Feb 2010 08:41:14 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> <1265870404.3523.7.camel@dellx1> In-Reply-To: <1265870404.3523.7.camel@dellx1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 07:40:14 -0000 Hi Geoff, (Disclaimer: I am not a lawyer) Geoff Mulligan wrote: > So this is an interesting, how does someone writing open source code > notify the the users of that code that the software is encumbered with > patents, so that people that take the code understand that they are > using software that comes with a license. First, patents and copyrights are *completely* separate issues and should not be confused with each other. So if I may interpret your question as two questions, one regarding patents and one regarding copyright: (1) how do you let people know that your system (open source or closed source, it doesn't matter) is covered by patents? and (2) how do you let people know that your code is open source and can be distributed and modified under a copyright license? One way to solve (1) is to include a list of patents that covers the software. You see this sometimes (e.g. vmware: http://www.vmware.com/download/patents.html). It is not an obligation to inform anyone of such patents, however. Most, if not all, software systems today are covered by many patents from different parties. The open source Linux kernel is covered by patents from IBM, Apple, Microsoft, etc. The closed source Windows kernel is also covered by patents, as is the Mac OS X kernel. Call me a cynic, but software patents seem to have very little to do with technology or innovation. The normal way to solve (2) is simply to tell people that your software is open source and may be redistributed under a specific license. Without such a license, the software may not be redistributed - redistribution is always forbidden in by law, unless explicitly allowed by a copyright license. /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From jvasseur@cisco.com Thu Feb 11 00:35:20 2010 Return-Path: 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 E700C28C0F1 for ; Thu, 11 Feb 2010 00:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=4.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gnmNE9qI4upb for ; Thu, 11 Feb 2010 00:35:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2ED5028C0E4 for ; Thu, 11 Feb 2010 00:35:19 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHtQc0tAZnwM/2dsb2JhbACaeXSlFpdohFYE X-IronPort-AV: E=Sophos;i="4.49,450,1262563200"; d="scan'208";a="85439971" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2010 08:36:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1B8aUJ6020257; Thu, 11 Feb 2010 08:36:32 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 09:36:30 +0100 Received: from [64.103.30.14] ([64.103.30.14]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 09:36:30 +0100 Message-Id: From: JP Vasseur To: Adam Dunkels , Geoff Mulligan In-Reply-To: <4B73B49A.2070006@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 09:36:30 +0100 References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> <1265870404.3523.7.camel@dellx1> <4B73B49A.2070006@sics.se> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Feb 2010 08:36:30.0553 (UTC) FILETIME=[4F2CDC90:01CAAAF5] Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 08:35:21 -0000 Interesting discussion as pointing out by Adam, these are separate issues so if I may let's move the licensing discussing to the appropriate WG. On Feb 11, 2010, at 8:41 AM, Adam Dunkels wrote: > Hi Geoff, > > (Disclaimer: I am not a lawyer) > > Geoff Mulligan wrote: >> So this is an interesting, how does someone writing open source code >> notify the the users of that code that the software is encumbered >> with >> patents, so that people that take the code understand that they are >> using software that comes with a license. > > First, patents and copyrights are *completely* separate issues and > should not be confused with each other. So if I may interpret your > question as two questions, one regarding patents and one regarding > copyright: > > (1) how do you let people know that your system (open source or > closed source, it doesn't matter) is covered by patents? > > and > > (2) how do you let people know that your code is open source and can > be distributed and modified under a copyright license? > > One way to solve (1) is to include a list of patents that covers the > software. You see this sometimes (e.g. vmware: http://www.vmware.com/download/patents.html) > . It is not an obligation to inform anyone of such patents, however. > Most, if not all, software systems today are covered by many patents > from different parties. The open source Linux kernel is covered by > patents from IBM, Apple, Microsoft, etc. The closed source Windows > kernel is also covered by patents, as is the Mac OS X kernel. Call > me a cynic, but software patents seem to have very little to do with > technology or innovation. > > The normal way to solve (2) is simply to tell people that your > software is open source and may be redistributed under a specific > license. Without such a license, the software may not be > redistributed - redistribution is always forbidden in by law, unless > explicitly allowed by a copyright license. > > /adam > -- > Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ > Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jonsmirl@gmail.com Thu Feb 11 05:25:42 2010 Return-Path: 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 8FFB83A76D9 for ; Thu, 11 Feb 2010 05:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Tk5lSC7KkHnA for ; Thu, 11 Feb 2010 05:25:41 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 4FFFF3A71CA for ; Thu, 11 Feb 2010 05:25:41 -0800 (PST) Received: by qyk13 with SMTP id 13so679302qyk.31 for ; Thu, 11 Feb 2010 05:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CjTOKQt4WMS8hM4YV15Os5JJQ/UOlxCXPixZkXCqwT4=; b=p2V0wposrrIOJh4Rc/aok+2vfRJb1lDgb1q7GtW5SfVmlJE166YrrGajAKL6lrzbV7 8IJqUxZ9sSo0xdBBpVJ8q57Vt9xq9WX/UENnRuf2duAMW8oBMDBL869zOauWkz/vBGJZ JrAIQJ/daYkkY8zc0FWp663V5BHjs+MS5Ay/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wNfcsugSClMvpBWu+SmxWlU1Yan5yy2FZxxDIXtpKYkJA7mp66GhJlVhwZ+wm1RnIY 0VMEnnQO41MTA+P+fxbNzcUXY/GgExOSJOq44Kp00ysCFvSS4gi90pRXD2u+zYwHphoj 0KvtG0RGzp3Do0+InL7nnO51+aVKj0QWrVs0Q= MIME-Version: 1.0 Received: by 10.229.115.203 with SMTP id j11mr785855qcq.3.1265894812358; Thu, 11 Feb 2010 05:26:52 -0800 (PST) In-Reply-To: References: <4B72E356.4080000@gmail.com> <4B72F847.3090206@gmail.com> <4B7308A0.7060008@sics.se> <1265870404.3523.7.camel@dellx1> <4B73B49A.2070006@sics.se> Date: Thu, 11 Feb 2010 08:26:52 -0500 Message-ID: <9e4733911002110526l4132519x7c3b587bcc0300eb@mail.gmail.com> From: Jon Smirl To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Software Licensing and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 13:25:42 -0000 On Thu, Feb 11, 2010 at 3:36 AM, JP Vasseur wrote: > Interesting discussion as pointing out by Adam, these are separate issues= so > if I may let's move the licensing discussing to the appropriate WG. The issue of incorporating royalty bearing patents into the RPL standard is a highly relevant one. Royalties prevent incorporation of RPL into the Linux kernel and will probably result in the creation of an alternative, unencumbered protocol. Is Cisco willing to provide a royalty free license for their patents when RPL is implemented in GPL licensed code? Will other people with IP claims provide a GPL compatible license? This is the same issue Mozilla is currently facing with H.264. Mozilla is GPL licensed, H.264 requires royalties. Mozilla can't include H.264. So far this has resulted in the Google acquiring ON2. We're still waiting for Google to announce a royalty free alternative to H.264 as a result of the ON2 acquisition. YouTube will be converted to this new codec and Mozilla will be able to incorporate it. H.264 will lose the Internet. > > On Feb 11, 2010, at 8:41 AM, Adam Dunkels wrote: > >> Hi Geoff, >> >> (Disclaimer: I am not a lawyer) >> >> Geoff Mulligan wrote: >>> >>> =A0So this is an interesting, how does someone writing open source code >>> notify the the users of that code that the software is encumbered with >>> patents, so that people that take the code understand that they are >>> using software that comes with a license. >> >> First, patents and copyrights are *completely* separate issues and shoul= d >> not be confused with each other. So if I may interpret your question as = two >> questions, one regarding patents and one regarding copyright: >> >> (1) how do you let people know that your system (open source or closed >> source, it doesn't matter) is covered by patents? >> >> and >> >> (2) how do you let people know that your code is open source and can be >> distributed and modified under a copyright license? >> >> One way to solve (1) is to include a list of patents that covers the >> software. You see this sometimes (e.g. vmware: >> http://www.vmware.com/download/patents.html). It is not an obligation to >> inform anyone of such patents, however. Most, if not all, software syste= ms >> today are covered by many patents from different parties. The open sourc= e >> Linux kernel is covered by patents from IBM, Apple, Microsoft, etc. The >> closed source Windows kernel is also covered by patents, as is the Mac O= S X >> kernel. Call me a cynic, but software patents seem to have very little t= o do >> with technology or innovation. >> >> The normal way to solve (2) is simply to tell people that your software = is >> open source and may be redistributed under a specific license. Without s= uch >> a license, the software may not be redistributed - redistribution is alw= ays >> forbidden in by law, unless explicitly allowed by a copyright license. >> >> /adam >> -- >> Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ >> Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org >> _______________________________________________ >> 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 > --=20 Jon Smirl jonsmirl@gmail.com From THirou@convergencewireless.com Thu Feb 11 18:25:47 2010 Return-Path: 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 ; 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 ; 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 ; 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" To: "Tzeta Tsao" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, =20 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. =20 -----Original Message----- From: Tzeta Tsao [mailto:tzeta.tsao@ekasystems.com]=20 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=20 ----- Original Message ---- From: Tim Hirou To: Tzeta Tsao 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]=20 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 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: >=20 > 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. =20 >=20 > 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.=20 >=20 > 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. =20 >=20 > 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.=20 >=20 > 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: >=20 > 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) >=20 > 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. =20 >=20 >=20 > We see the practice of making this kind of declaration (combining our > commitment to not assert and the "defensive suspension") on the vast > majority=20 > of IETF I-Ds and RFCs where we have essential patents as being both=20 > 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. >=20 > 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. =20 >=20 > I hope that this helps clarify the issues and move the discussion to > resolution. >=20 > Best regards, >=20 > Dan Lang >=20 >=20 >=20 >=20 >=20 >=20 > Dan Lang > Director, Intellectual Property > Legal Services > Cisco Systems, Inc. >=20 >=20 >=20 > _______________________________________________ > 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 From wintert@acm.org Fri Feb 12 08:36:18 2010 Return-Path: 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 1CC2B3A771C for ; Fri, 12 Feb 2010 08:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 pm0wIV02Agvq for ; Fri, 12 Feb 2010 08:36:17 -0800 (PST) Received: from smtp105.prem.mail.ac4.yahoo.com (smtp105.prem.mail.ac4.yahoo.com [76.13.13.44]) by core3.amsl.com (Postfix) with SMTP id D92B03A7374 for ; Fri, 12 Feb 2010 08:36:16 -0800 (PST) Received: (qmail 8755 invoked from network); 12 Feb 2010 16:37:32 -0000 Received: from (wintert@209.48.242.70 with plain) by smtp105.prem.mail.ac4.yahoo.com with SMTP; 12 Feb 2010 08:37:32 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: aucxc.gVM1mIsGrA.F8gjFtDVoxLkzFfLTSPDjsXghw2U1CW_o7jpn76o.ckg4z9BOgQHlTORIF2p9S.qjMHI2Qi42DV1mtGXQ55Qws57iYXKuVjQ2s0UsFQqu7Gdov8k3Cx0i_nFcsiKisVyjv31NRnJHzLifr5D6g.i7CrmCIN89oNzkKV0EWYOr1uCCQNpazhZ3nCezwrwTBKwg8l0u75jM.2JKLoP6AvFpZUQA7RiUGa.qNmneFIAOWnkIGzWa7mvW8yl79LtgZc8J28cpiiCDglYOKjvTQWTA55z3UZ7ZO_zCOFLTDRBLOy8p_T0N_dYX1uqTl8zuBTwvek X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B7583C2.4050201@acm.org> Date: Fri, 12 Feb 2010 11:37:22 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> <4B6B217B.908@eecs.berkeley.edu> In-Reply-To: <4B6B217B.908@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] An AD Comments on IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:36:18 -0000 I believe we should go ahead, and share Kris' opinion that Cisco's polices seem reasonable. Given these terms, I do not think that it is necessary to re-engineer RPL for the express intent of avoiding possible Cisco IPR. Further, I would like to encourage others to continue to disclose any claims to IPR that relates to the activities of this WG as per IETF policy. Regards, -Tim Kris Pister wrote: > Yes, let's go ahead. > > For what it's worth, this will not be the last time someone discloses IP > related to RPL or sensor networks in general. Cisco's policies are well > known, and in my opinion quite reasonable. Other IP is likely to be > disclosed in a friendly letter as soon as someone perceives that you are > making a profit. To quote Casablanca (Peter Lorre?): There are vultures, > vultures everywhere! > I can't count the number of times that I've been approached after a talk > by someone who says "you know, I've got the fundamental patent that > covers that". I've heard so many people claim that they are the ones > who patented combining a microprocessor/sensor/radio that it makes me > wonder if the patent office isn't paying attention, or if I just attract > nut cases. > > It would be a wonderful thing if we had a central database describing > the first public disclosure of the building block ideas that go into > sensor networks, because we will, as a community, need to be able to > fight back against those who see IP as a profit center, not a protocol :) > Maybe a brainstorming session at the next meeting is in order? > > ksjp > > Adrian Farrel wrote: >> Hi, >> >> I can understand people's frustration with the nature of IPR claims >> and disclosures. >> >> However, while you can ask anyone to give you advice about what is >> covered by a claim, and what the IPR terms actually mean, this is >> ultimately a question that must be handled as an individual issue by >> you, or as a corporate issue by your legal advisers. You would be >> poorly advised to rely on the advice of an individual on this list, >> whatever their technical or legal qualifications. >> >> JP's question is intended to allow you to state your opinions so that >> he can judge working group consensus. >> >> He asked: >> >>> Given the discussions about the IPR disclosure at >>> https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR >>> policy at http://www.ietf.org/ipr/policy.html I would like >>> to make sure that the working group is happy to proceed >>> with draft-ietf-roll-rpl in its current form. Please state your >>> opinions on the list. I will make a consensus call on Friday >>> 11 February. >> >> [We can probably assume that he means Friday 12 February :-)] >> >> In answering this question you need to say "yes, let's go ahead" or >> "no, we have to take steps to avoid the IPR". Your reasons for holding >> a position may be helpful to others and to the chairs in finding the >> way forward. >> >> By way of background, the IETF has always attempted to find >> unencumbered technical solutions, but there is a general recognition >> that very few specifications reach RFC status without the possibility >> of some IPR claim at some time. By requiring IETF participants to >> disclose IPR, the IETF is seeking to enable informed decisions why its >> participants, and this helps to avoid claims of entrapment. It should >> be noted that the absence of an IPR disclosure is not a guarantee that >> no IPR exists, but the presence of a disclosure allows everyone to see >> the licensing terms. In deciding whether to support or deny >> continuation of technical work in the presence of an IPR disclosure, >> individuals (or their companies) will want to consider whether they >> think the IPR actually covers the technical work, whether it is >> enforceable, and whether they consider the licensing terms to be >> favourable. They will also need to consider the cost-benefit of the >> various options that exist. No-one else can make these decisions for you! >> >> May I also take this opportunity to ask you all to look at the IETF's >> IPR policy. In particular, can I remind you all about the policy with >> respect to IPR that you know about as described in RFC 3979 and RFC >> 4879. All document authors and contributors to discussions need to be >> aware of their personal commitments to disclose IPR as expressed in >> those two RFCs. >> >> Thanks, >> Adrian >> _______________________________________________ >> 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 > From pal@cs.stanford.edu Fri Feb 12 08:53:43 2010 Return-Path: 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 E71673A7729 for ; Fri, 12 Feb 2010 08:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EIp3Di87bvUc for ; Fri, 12 Feb 2010 08:53:43 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 412913A771C for ; Fri, 12 Feb 2010 08:53:43 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NfynG-0003TP-BS; Fri, 12 Feb 2010 08:55:02 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4B7583C2.4050201@acm.org> Date: Fri, 12 Feb 2010 08:55:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3168CF54-EB11-4E78-AC83-97B83B9FBC8E@cs.stanford.edu> References: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> <4B6B217B.908@eecs.berkeley.edu> <4B7583C2.4050201@acm.org> To: Tim Winter X-Mailer: Apple Mail (2.1077) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: ROLL WG Subject: Re: [Roll] An AD Comments on IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:53:44 -0000 On Feb 12, 2010, at 8:37 AM, Tim Winter wrote: > I believe we should go ahead, and share Kris' opinion that Cisco's = polices seem > reasonable. Given these terms, I do not think that it is necessary to = re-engineer > RPL for the express intent of avoiding possible Cisco IPR. Further, I = would like to > encourage others to continue to disclose any claims to IPR that = relates to the > activities of this WG as per IETF policy. >=20 > Regards, >=20 > -Tim >=20 I agree with Tim and Kris. In this space, it's inevitable that almost = any reasonable design will touch on someone's IPR. If we re-engineer RPL = to avoid Cisco's, all we'll do is more greatly impinge on someone = else's, under much less kind terms. Phil= From d.sturek@att.net Fri Feb 12 09:08:20 2010 Return-Path: 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 9A2F628C1B8 for ; Fri, 12 Feb 2010 09:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 MBqB2+prM5ZT for ; Fri, 12 Feb 2010 09:08:19 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 99D8D28C10A for ; Fri, 12 Feb 2010 09:08:19 -0800 (PST) Received: (qmail 205 invoked from network); 12 Feb 2010 17:09:36 -0000 Received: from Studio (d.sturek@12.190.142.90 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 12 Feb 2010 09:09:36 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: iTjbnxYVM1n3atSvzOQKoM3i1gHO191MqgZhUuf4RA3FODWhfFHZBBHNNWAx4EA7ig7oHbLY160BsyVpkyodF_TplE30VpkPzxdQvVqT.mkdvTYUexDGxILSVaXphhEZecJqS7o9DvlDdMQf5UrmTsw2fzqs4IUjahanS42Bk5ZwjOYm28qDxZ3WcW0DBsgCIZjKgzGYDP8F9xkgq75scCuhNfZrW.GxKHoB2ndICJwvMk4acUSkK4q3kbvKcaV28FO7Mrac8DO6mxyKYjOnS6OHOzsuDd_TwnctpYe5c8N1CXw.IQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: In-Reply-To: Date: Fri, 12 Feb 2010 09:09:34 -0800 Message-ID: <006c01caac06$267e19a0$737a4ce0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CAABC3.185AD9A0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcqjRo4RC47SSA0zS0q9HFxfF1/ukQACH9tAAizHr8A= Content-Language: en-us Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 17:08:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01CAABC3.185AD9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP (and ROLL team), After a lot of discussion, I have to say there are legitimate concerns on proceeding with draft-ietf-roll-rpl given the IPR disclosure from Cisco. Please modify my respond to indicate that I am not in favor of proceeding with the current RPL draft with the existing IPR statement. Best Regards, Don Sturek From: Don Sturek [mailto:d.sturek@att.net] Sent: Monday, February 01, 2010 7:00 AM To: 'JP Vasseur'; 'ROLL WG' Subject: RE: [Roll] Closing on the IPR Hi JP, As noted in an earlier thread, I am fine with proceeding using the draft-ietf-roll-rpl. Best Regards, Don Sturek From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Monday, February 01, 2010 5:57 AM To: ROLL WG Subject: [Roll] Closing on the IPR Dear all, Given the discussions about the IPR disclosure at https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/policy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on the list. I will make a consensus call on Friday 11 February. Thanks. JP. ------=_NextPart_000_006D_01CAABC3.185AD9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP (and ROLL team),

 

After a lot of discussion, I have to say there are = legitimate concerns on proceeding with draft-ietf-roll-rpl given the IPR disclosure = from Cisco.

 

Please modify my respond to indicate that I am not in = favor of proceeding with the current RPL draft with the existing IPR = statement.

 

Best Regards,

 

Don Sturek

 

From:= Don Sturek [mailto:d.sturek@att.net]
Sent: Monday, February 01, 2010 7:00 AM
To: 'JP Vasseur'; 'ROLL WG'
Subject: RE: [Roll] Closing on the IPR

 

Hi JP,

 

As noted in an earlier thread, I am fine with proceeding = using the draft-ietf-roll-rpl.

 

Best Regards,

 

Don Sturek

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Monday, February 01, 2010 5:57 AM
To: ROLL WG
Subject: [Roll] Closing on the IPR

 

Dear all,

 

Given the discussions about the IPR disclosure at = https://datatracker.ietf.= org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/poli= cy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on = the list. I will make a consensus call on Friday 11 February.

 

Thanks.

 

JP.

 

------=_NextPart_000_006D_01CAABC3.185AD9A0-- From pal@cs.stanford.edu Fri Feb 12 09:19:50 2010 Return-Path: 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 774043A7374 for ; Fri, 12 Feb 2010 09:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 XUAnrLhWnhZR for ; Fri, 12 Feb 2010 09:19:49 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6C16B3A708D for ; Fri, 12 Feb 2010 09:19:49 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NfzCW-0005HQ-E5; Fri, 12 Feb 2010 09:21:08 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-50--74740689 From: Philip Levis In-Reply-To: <006c01caac06$267e19a0$737a4ce0$@sturek@att.net> Date: Fri, 12 Feb 2010 09:21:08 -0800 Message-Id: References: <006c01caac06$267e19a0$737a4ce0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 1a4cd7935245e7f84af030f069fa5aea Cc: 'ROLL WG' Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 17:19:50 -0000 --Apple-Mail-50--74740689 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 12, 2010, at 9:09 AM, Don Sturek wrote: > Hi JP (and ROLL team), > =20 > After a lot of discussion, I have to say there are legitimate concerns = on proceeding with draft-ietf-roll-rpl given the IPR disclosure from = Cisco. > =20 > Please modify my respond to indicate that I am not in favor of = proceeding with the current RPL draft with the existing IPR statement. > =20 > Best Regards, > =20 > Don Sturek Don, Two questions: 1) It's not yet clear what in the RPL draft overlaps with Cisco's IPR. = Is your opinion that the draft should not overlap with the disclosed = IPR, or that regardless of their relationship we should adopt a complete = different design? 2) Given that there is lots of IPR in this space, most of which is not = represented here, is your opinion that we should do an IP survey and = strive to come up with a design that is covered by none, or that we = should only strive to avoid the IPR that's been disclosed within this = WG? It's easy to say "this isn't the right path forward." I'm trying to = figure out what you think the alternative is. Phil= --Apple-Mail-50--74740689 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 12, 2010, at 9:09 AM, Don = Sturek wrote:

Hi JP (and ROLL = team),
After = a lot of discussion, I have to say there are legitimate concerns on = proceeding with draft-ietf-roll-rpl given the IPR disclosure from = Cisco.
Best = Regards,
Don = Sturek
<= br>
Don,

Two = questions:

1) It's not yet clear what in the = RPL draft overlaps with Cisco's IPR. Is your opinion that the draft = should not overlap with the disclosed IPR, or that regardless of their = relationship we should adopt a complete different = design?

2) Given that there is lots of IPR in = this space, most of which is not represented here, is your opinion that = we should do an IP survey and strive to come up with a design that is = covered by none, or that we should only strive to avoid the IPR that's = been disclosed within this WG?

It's easy to say = "this isn't the right path forward." I'm trying to figure out what you = think the alternative = is.

Phil
= --Apple-Mail-50--74740689-- From edward.j.beroset@us.elster.com Fri Feb 12 10:49:33 2010 Return-Path: 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 9310328C1BA; Fri, 12 Feb 2010 10:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 wH8nlCBq1Gnm; Fri, 12 Feb 2010 10:49:32 -0800 (PST) Received: from mail54.messagelabs.com (mail54.messagelabs.com [216.82.241.131]) by core3.amsl.com (Postfix) with SMTP id 9971428C190; Fri, 12 Feb 2010 10:49:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: edward.j.beroset@us.elster.com X-Msg-Ref: server-8.tower-54.messagelabs.com!1266000650!68829535!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 23696 invoked from network); 12 Feb 2010 18:50:50 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-8.tower-54.messagelabs.com with SMTP; 12 Feb 2010 18:50:50 -0000 In-Reply-To: References: <006c01caac06$267e19a0$737a4ce0$@sturek@att.net> To: pal@cs.stanford.edu MIME-Version: 1.0 X-KeepSent: 5F26EBFE:4A250423-852576C8:006706F6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008 Message-ID: From: edward.j.beroset@us.elster.com Date: Fri, 12 Feb 2010 13:49:53 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 02/12/2010 01:47:26 PM, Serialize complete at 02/12/2010 01:47:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0067720F852576C8_=" Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:49:33 -0000 This is a multipart message in MIME format. --=_alternative 0067720F852576C8_= Content-Type: text/plain; charset="US-ASCII" Philip Levis wrote on 02/12/2010 12:21:08: > > It's easy to say "this isn't the right path forward." I'm trying to > figure out what you think the alternative is. Logically, either RPL or Cisco's terms could be changed to meet objections. Has Cisco ruled out the latter? Ed --=_alternative 0067720F852576C8_= Content-Type: text/html; charset="US-ASCII"
Philip Levis wrote on 02/12/2010 12:21:08:
>
> It's easy to say "this isn't the right path forward." I'm trying to
> figure out what you think the alternative is.

Logically, either RPL or Cisco's terms could be changed to meet objections.  Has Cisco ruled out the latter?

Ed --=_alternative 0067720F852576C8_=-- From jvasseur@cisco.com Fri Feb 12 12:42:50 2010 Return-Path: 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 26A8728C250 for ; Fri, 12 Feb 2010 12:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EMr2KBn1xIFv for ; Fri, 12 Feb 2010 12:42:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E95CF28C262 for ; Fri, 12 Feb 2010 12:42:48 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAACNMdUuQ/uCWe2dsb2JhbACbARUBARYkBh2oAZdHhFgE X-IronPort-AV: E=Sophos;i="4.49,463,1262563200"; d="scan'208";a="57047323" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2010 20:41:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1CKfpEY015553 for ; Fri, 12 Feb 2010 20:41:51 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 21:41:50 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 21:41:50 +0100 Message-Id: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 12 Feb 2010 21:41:47 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Feb 2010 20:41:50.0672 (UTC) FILETIME=[CD99C500:01CAAC23] Subject: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 20:42:50 -0000 Dear all, When I look back over the last six to nine months I am really impressed with the progress we have made developing RPL. There are multiple implementations already in progress to show that the solution can really work. The IPR issue is very important, of course. So far quite a few people have made comments, but I do not see a clear consensus and I would like to hear from more people. At the same time, I don't think it would be appropriate for me to judge the consensus on this issue because my company affiliation might be considered to influence my independent IETF role. Therefore I have asked our Routing Area Director Adrian Farrel to take the judgement decision. Thanks Adrian for accepting to do this job. JP. From jvasseur@cisco.com Fri Feb 12 12:50:05 2010 Return-Path: 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 ECF2128C1FF for ; Fri, 12 Feb 2010 12:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[AWL=-4.196, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] 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 oAsejpRUpMJN for ; Fri, 12 Feb 2010 12:50:04 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DA8CA28C1FA for ; Fri, 12 Feb 2010 12:50:03 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAItNdUuQ/uCWe2dsb2JhbACbARUBARYkBh2nepdHhFgE X-IronPort-AV: E=Sophos;i="4.49,463,1262563200"; d="scan'208";a="3329183" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 Feb 2010 20:15:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1CKkdbX019369; Fri, 12 Feb 2010 20:46:39 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 21:46:39 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 21:46:38 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Adrian Farrel In-Reply-To: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 12 Feb 2010 21:46:37 +0100 References: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Feb 2010 20:46:38.0705 (UTC) FILETIME=[79481E10:01CAAC24] Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 20:50:05 -0000 > Dear all, > > When I look back over the last six to nine months I am really > impressed with the progress we have made developing RPL. There are > multiple implementations already in progress to show that the > solution can really work. > > The IPR issue is very important, of course. So far quite a few > people have made comments, but I do not see a clear consensus and I > would like to hear from more people. > > At the same time, I don't think it would be appropriate for me to > judge the consensus on this issue because my company affiliation > might be considered to influence my independent IETF role. Therefore > I have asked our Routing Area Director Adrian Farrel to take the > judgement decision. > > Thanks Adrian for accepting to do this job. > > JP. From jdrake@juniper.net Fri Feb 12 13:20:06 2010 Return-Path: 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 83E4D3A7904 for ; Fri, 12 Feb 2010 13:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cYdef23ge5lG for ; Fri, 12 Feb 2010 13:20:04 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1CBFA3A720C for ; Fri, 12 Feb 2010 13:20:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS3XGUbJH7d1xwOrrUpHThMaOL99QfHGa@postini.com; Fri, 12 Feb 2010 13:21:24 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 12 Feb 2010 13:20:08 -0800 From: John E Drake To: JP Vasseur , ROLL WG , Adrian Farrel Date: Fri, 12 Feb 2010 13:20:06 -0800 Thread-Topic: [Roll] IPR ROLL Thread-Index: AcqsJSVxRFRQjuSKQfCUhw/1uONM4QAA9r1A Message-ID: <5E893DB832F57341992548CDBB33316398050D8DDD@EMBX01-HQ.jnpr.net> References: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:20:06 -0000 JP and Adrian, I hope you interpreted my e-mail of several days ago as indicating that I t= hink it makes sense to proceed with draft-ietf-roll-rpl. Thanks, John > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of J= P > Vasseur > Sent: Friday, February 12, 2010 12:47 PM > To: ROLL WG; Adrian Farrel > Subject: Re: [Roll] IPR ROLL >=20 > > Dear all, > > > > When I look back over the last six to nine months I am really > > impressed with the progress we have made developing RPL. There are > > multiple implementations already in progress to show that the > > solution can really work. > > > > The IPR issue is very important, of course. So far quite a few > > people have made comments, but I do not see a clear consensus and I > > would like to hear from more people. > > > > At the same time, I don't think it would be appropriate for me to > > judge the consensus on this issue because my company affiliation > > might be considered to influence my independent IETF role. Therefore > > I have asked our Routing Area Director Adrian Farrel to take the > > judgement decision. > > > > Thanks Adrian for accepting to do this job. > > > > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Yusuf.Bashir@jci.com Fri Feb 12 14:11:08 2010 Return-Path: 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 E52A03A75B5; Fri, 12 Feb 2010 14:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] 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 Rs4Z+mDcOaGn; Fri, 12 Feb 2010 14:11:05 -0800 (PST) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 7C3683A744C; Fri, 12 Feb 2010 14:11:04 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKS3XSRs5DunJO9KtCVhOCWF1DL8xbcAkK@postini.com; Fri, 12 Feb 2010 14:12:25 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010021216121619-369333 ; Fri, 12 Feb 2010 16:12:16 -0600 In-Reply-To: References: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> To: JP Vasseur MIME-Version: 1.0 X-KeepSent: 8663264B:0FAD728C-862576C8:007951F5; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Yusuf.Bashir@jci.com Message-ID: Date: Fri, 12 Feb 2010 16:12:02 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/12/2010 04:12:09 PM, Serialize complete at 02/12/2010 04:12:09 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/12/2010 04:12:16 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/12/2010 04:12:29 PM, Serialize complete at 02/12/2010 04:12:29 PM Content-Type: text/html; charset="US-ASCII" Cc: roll-bounces@ietf.org, ROLL WG , Adrian Farrel Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 22:11:08 -0000
Hi JP and Adrian,
I am not in favor of proceeding with draft-ietf-roll-rpl because most of us only found out about the IPR six months after the initial draft.

Regards,
Yusuf



From: JP Vasseur <jvasseur@cisco.com>
To: ROLL WG <roll@ietf.org>, Adrian Farrel <Adrian.Farrel@huawei.com>
Date: 02/12/2010 02:51 PM
Subject: Re: [Roll] IPR ROLL




> Dear all,
>
> When I look back over the last six to nine months I am really  
> impressed with the progress we have made developing RPL. There are  
> multiple implementations already in progress to show that the  
> solution can really work.
>
> The IPR issue is very important, of course. So far quite a few  
> people have made comments, but I do not see a clear consensus and I  
> would like to hear from more people.
>
> At the same time, I don't think it would be appropriate for me to  
> judge the consensus on this issue because my company affiliation  
> might be considered to influence my independent IETF role. Therefore  
> I have asked our Routing Area Director Adrian Farrel to take the  
> judgement decision.
>
> Thanks Adrian for accepting to do this job.
>
> JP.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From Ruben.Salazar@landisgyr.com Fri Feb 12 20:01:16 2010 Return-Path: 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 CFFC628C0E8 for ; Fri, 12 Feb 2010 20:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 tGuyOgPgNxmL for ; Fri, 12 Feb 2010 20:01:06 -0800 (PST) Received: from mta2.cellnet.com (mta2.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id DC3A63A68C7 for ; Fri, 12 Feb 2010 20:01:05 -0800 (PST) X-ASG-Debug-ID: 1266033745-0b2600010000-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 9F7873CDA2A for ; Fri, 12 Feb 2010 23:02:25 -0500 (EST) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id MwsWUydA1wgWYuvL for ; Fri, 12 Feb 2010 23:02:25 -0500 (EST) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 23:02:25 -0500 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Fri, 12 Feb 2010 23:02:24 -0500 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAAC61.5918E325" X-ASG-Orig-Subj: RE: [Roll] Closing on the IPR Date: Fri, 12 Feb 2010 22:59:11 -0500 Message-ID: <09D9C0631368C244941E610D99FEA71001AE11AC@usatlsv105.am.bm.net> In-Reply-To: <56EB87C4-1B5B-488C-83A1-7778135E7D33@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on the IPR thread-index: Acqj8SAZbJRZo1MVS4KsWInj5/iLLgIbqzhA References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com><4B67F596.10504@gmail.com> <56EB87C4-1B5B-488C-83A1-7778135E7D33@cisco.com> From: "Salazar, Ruben" To: "JP Vasseur" X-OriginalArrivalTime: 13 Feb 2010 04:02:24.0883 (UTC) FILETIME=[599E4430:01CAAC61] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1266033745 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: ROLL WG , Dan Lang Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 04:01:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAAC61.5918E325 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JP and ROLL team, Like most of you, I am trying to form a position regarding this = discussion about Cisco's IPR, and I can summarize it in a particular = way: Cisco asks companies that are working in this effort and may potentially = make use of this protocol to renounce to enforce any potential IPR = violation from Cisco to their own IPR and in exchange these companies = get whatever coverage they can get with Cisco's IPR essential to this = protocol. Well, somebody earlier in the exchange compared Cisco's IPR to a = "protection umbrella" to all this effort. We know that despite any = number of patents that Cisco may consider relevant and essential to it = there could (and there will) be areas that their portfolio would not = cover, so the "umbrella" will have "holes" at best. So my conclusion is that by agreeing to Cisco's terms we would allow = Cisco to "walk" freely anywhere in our "property " in exchange from an = umbrella with holes to protect work only on RPL. It does not seem right. The argument that "it has been done before" is not only weak as = justification for it to continue being done, but also is not necessarily = true: I believe that for every example that can be produced in that = sense there will be tens of examples where standardization has happened = without such terms. I also think that knowing what part of the current RPL may be affected = by Cisco's IPR would not alleviate the concern, it will just help us see = the "holes in the umbrella". The work on ROLL/RPL is supposed to bring standardization in the = relatively new area of low power low reliability wireless networks, and = the best way to help it flourish is by bringing to the table, together, = the elements of our thoughts that can be shared openly and freely, and = leaving the remaining elements to each company to introduce its own = differentiating solutions. Regards =20 =20 Ruben Salazar, PhD Director of Research and Technology Landys+Gyr EMS Office: 678 258 3165 Cellular: 678 438 0063 ruben.salazar@landysgyr.com www.landisgyr.com manage energy better =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur Sent: Tuesday, February 02, 2010 5:16 AM To: Alexandru Petrescu Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR =20 Hi Alex, =20 Just to make sure since we're looking for an answer to the following = question:=20 =20 "Given the discussions about the IPR disclosure at = https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at = http://www.ietf.org/ipr/policy.html I would like to make sure that the = working group is happy to proceed with draft-ietf-roll-rpl in its = current form. Please state your opinions on the list. I will make a = consensus call on Friday 11 February. " =20 Are you OK ? Based on what you said I think that the answer is "yes" but = I wanted to make sure. =20 Thanks. =20 JP. =20 On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu wrote: Cisco IPR protection umbrella to any group implementing IPR? NO! If I implement this stuff I will not need Cisco protection - I will write a different protection, a different licensing scheme. I don't need Cisco licensing to protect me. What I need from Cisco is to interoperate. Take my stance as moderate - as I previously said, I am generally ok with Cisco disclosures at IETF - but I never considered it as a protection umbrella, rather as something that I had to live with. This is also why a second disclosure on RPL, from a competitor would be beneficial. Alex Le 02/02/2010 08:33, Pascal Thubert (pthubert) a =E9crit : Hi: =20 Phil: You're so right. It is also my experience that the process of patenting rapidly escapes the author, and the coverage of the resulting words is just beyond people like me. I made the exercise of browsing the claims for the ten+ disclosures listed, and I'm clear that 3 to 6 of these have an application in RPL. How far that goes I can hardly assert. I simply think that if some external party comes at any of us in the future claiming its own IPR against RPL, there's a good probability that the Cisco IPR makes their attack quite a bit more difficult on a number of key elements. =20 Emmanuel: 1) is my understanding as well. I talked to our legal team to try to understand as deeply as I could and my understanding has not changed. So We're on the exact same line. I just wanted to make it clear that the Cisco IPR is not only a defense for Cisco; it is also an umbrella that provides some degree of protection to any group that would implement RPL. And 3) is my understanding of what JP is asking to the group at this time. Great summary! =20 So: 3 - if yes, are we OK with these terms? =20 Cheers, =20 Pascal=20 Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi 1 f=E9vrier 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR =20 =20 On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: =20 Hi JP, =20 as discussed, IPR may indeed be difficult to avoid entirely, even without looming deadlines... If I recall correctly, we are discussing this because someone claimed that Cisco forces an IPR deal which, quoting this now famous anonymous, can be summarized by the following: =20 "Free license to use the patents in RPL so long as you and your company don't sue Cisco over any other patent for anything." =20 We are engineers, not lawyers, so to understand legal matters, most of us need such one-liner to understand what is the deal. Therefore in my mind, the right questions that we need to ask ourselves at this point are: =20 1 - is the above an accurate summary of the IPR deal imposed by Cisco? 2 - if no, what is an accurate summary of the IPR deal imposed by Cisco? 3 - if yes, are we OK with these terms? =20 Let's clarify this and move on quickly, back to protocol design where we belong! =20 Agreed -- part of the issue here is that I think it's not really possible for Pascal to describe exactly what the patents cover: he's not a patent lawyer, and I doubt that Cisco would like him to speak for them in this regard. My brief interactions with patent law have taught me that it often works quite differently than engineers might expect. So we should be careful assuming that we can easily understand the full situation. :) =20 Phil =20 _______________________________________________ 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 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAAC61.5918E325 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

JP and ROLL team,

Like most of you, I am trying to form a position = regarding this discussion about Cisco’s IPR, and I can summarize it in a = particular way:

Cisco asks companies that are working in this = effort and may potentially make use of this protocol to renounce to enforce any = potential  IPR violation from Cisco to their own IPR and in exchange these companies = get whatever coverage they can get with Cisco’s IPR essential to this protocol.

Well, somebody earlier in the exchange compared = Cisco’s IPR to a “protection umbrella” to all this effort. We know = that despite any number of patents that Cisco may consider relevant and essential to = it there could (and there will) be areas that their portfolio would not = cover, so  the “umbrella” will have “holes” at = best.

So my conclusion is that by agreeing to = Cisco’s terms we would allow Cisco to “walk” freely anywhere in our = “property “ in exchange from an umbrella with holes to protect work only on = RPL. It does not seem right.

The argument that “it has been done = before” is not only weak as justification for it to continue being done, but also = is not necessarily true: I believe that for every example that can be produced = in that sense there will be tens of examples where standardization has happened = without such terms.

I also think that knowing what part of the current = RPL may be affected by Cisco’s IPR would not alleviate the concern, it = will just help us see the “holes in the umbrella”.

The work on ROLL/RPL is supposed to bring = standardization in the relatively new area of low power low reliability wireless networks, = and the best way to help it flourish is by bringing to the table, together, the elements of our thoughts that can be shared openly and freely, and = leaving the remaining elements to each company to introduce its own differentiating = solutions.

Regards

 

 

Ruben Salazar, PhD

Director of Research  and = Technology

Landys+Gyr EMS

Office: 678 258 3165

Cellular: 678 438 0063

ruben.salazar@landysgyr.com

www.landisgyr.com=

manage energy better

 

 



Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 = 1550        
Ruben.Salazar@landisgyr.com
www.landisgyr.com =
manage energy = better

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Tuesday, February 02, 2010 5:16 AM
To: Alexandru Petrescu
Cc: ROLL WG
Subject: Re: [Roll] Closing on the IPR

 

Hi Alex,

 

Just to make sure since we're looking for an answer = to the following question: 

 

"Given the discussions about the IPR = disclosure at https://datatracker.ietf.= org/ipr/1246/ and the IETF's IPR policy at http://www.ietf.org/ipr/poli= cy.html I would like to make sure that the working group is happy to proceed with draft-ietf-roll-rpl in its current form. Please state your opinions on = the list. I will make a consensus call on Friday 11 February.

"

 

Are you OK ? Based on what you said I think that = the answer is "yes" but I wanted to make sure.

 

Thanks.

 

JP.

 

On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu = wrote:



Cisco IPR protection umbrella to any group = implementing IPR?

            &= nbsp;       NO!

If I implement this stuff I will not need Cisco protection - I will
write a different protection, a different licensing scheme.  I = don't
need Cisco licensing to protect me.  What I need from Cisco is = to
interoperate.

Take my stance as moderate - as I previously said, I am generally ok
with Cisco disclosures at IETF - but I never considered it as a
protection umbrella, rather as something that I had to live with.

This is also why a second disclosure on RPL, from a competitor would = be
beneficial.

Alex

Le 02/02/2010 08:33, Pascal Thubert (pthubert) a écrit :

Hi:

 

Phil: You're so right. It is also my experience = that the process of

patenting rapidly escapes the author, and the = coverage of the

resulting words is just beyond people like me. I = made the exercise

of browsing the claims for the ten+ disclosures = listed, and I'm

clear that 3 to 6 of these have an application in = RPL. How far that

goes I can hardly assert. I simply think that if = some external party

comes at any of us in the future claiming its own = IPR against RPL,

there's a good probability that the Cisco IPR makes = their attack

quite a bit more difficult on a number of key = elements.

 

Emmanuel: 1) is my understanding as well. I talked = to our legal team

to try to understand as deeply as I could and my understanding has

not changed. So We're on the exact same line. I = just wanted to make

it clear that the Cisco IPR is not only a defense = for Cisco; it is

also an umbrella that provides some degree of = protection to any

group that would implement RPL. And 3) is my = understanding of what JP

is asking to the group at this time. Great = summary!

 

So:  3 - if yes, are we OK with these = terms?

 

Cheers,

 

Pascal -----Original Message----- From: roll-bounces@ietf.org

[mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi

1 février 2010 19:17 To: Emmanuel Baccelli Cc: = ROLL WG Subject: Re:

[Roll] Closing on the IPR

 

 

On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli = wrote:

 

Hi JP,

 

as discussed, IPR may indeed be difficult to avoid = entirely, even

without looming deadlines... If I recall correctly, = we are

discussing this because someone claimed that Cisco = forces an IPR

deal which, quoting this now famous anonymous, can = be summarized

by the following:

 

"Free license to use the patents in RPL so = long as you and your

company don't sue Cisco over any other patent for anything."

 

We are engineers, not lawyers, so to understand = legal matters,

most of us need such one-liner to understand what = is the deal.

Therefore in my mind, the right questions that we = need to ask

ourselves at this point are:

 

1 - is the above an accurate summary of the IPR = deal imposed by

Cisco? 2 - if no, what is an accurate summary of = the IPR deal

imposed by Cisco? 3 - if yes, are we OK with these = terms?

 

Let's clarify this and move on quickly, back to = protocol design

where we belong!

 

Agreed -- part of the issue here is that I think = it's not really

possible for Pascal to describe exactly what the = patents cover: he's

not a patent lawyer, and I doubt that Cisco would = like him to speak

for them in this regard. My brief interactions with = patent law have

taught me that it often works quite differently = than engineers might

expect. So we should be careful assuming that we = can easily

understand the full situation. :)

 

Phil

 

_______________________________________________ = 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

 

------_=_NextPart_001_01CAAC61.5918E325-- From richard.kelsey@ember.com Sat Feb 13 03:57:09 2010 Return-Path: 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 4226F3A79A5 for ; Sat, 13 Feb 2010 03:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sIQyNe1lg-Nb for ; Sat, 13 Feb 2010 03:57:08 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 744E63A79A4 for ; Sat, 13 Feb 2010 03:57:08 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Feb 2010 07:00:54 -0500 Date: Sat, 13 Feb 2010 06:46:47 -0500 Message-Id: <87eikpbbo8.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <3168CF54-EB11-4E78-AC83-97B83B9FBC8E@cs.stanford.edu> (message from Philip Levis on Fri, 12 Feb 2010 08:55:04 -0800) From: Richard Kelsey References: <35FA417FDBD348DDA5B44E4B74401FB8@your029b8cecfe> <4B6B217B.908@eecs.berkeley.edu> <4B7583C2.4050201@acm.org> <3168CF54-EB11-4E78-AC83-97B83B9FBC8E@cs.stanford.edu> X-OriginalArrivalTime: 13 Feb 2010 12:00:54.0353 (UTC) FILETIME=[31CBBC10:01CAACA4] Cc: roll@ietf.org Subject: Re: [Roll] An AD Comments on IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 11:57:09 -0000 > From: Philip Levis > Date: Fri, 12 Feb 2010 08:55:04 -0800 > > I agree with Tim and Kris. In this space, it's inevitable that almost > any reasonable design will touch on someone's IPR. If we re-engineer > RPL to avoid Cisco's, all we'll do is more greatly impinge on someone > else's, under much less kind terms. There are strong arguments for why we should continue with RPL, but I do not think that this is one of them. Why would the existence of Cisco IPR covering RPL make it any less likely that there is other IPR covering it? -Richard ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. From ccrisan@gmail.com Sat Feb 13 14:10:56 2010 Return-Path: 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 0DAD728C11E for ; Sat, 13 Feb 2010 14:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5MPt9jQMQ4Oi for ; Sat, 13 Feb 2010 14:10:54 -0800 (PST) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 46A123A7903 for ; Sat, 13 Feb 2010 14:10:54 -0800 (PST) Received: by fxm27 with SMTP id 27so44076fxm.5 for ; Sat, 13 Feb 2010 14:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=0SHNLQa6QPpHqVGPXpfBPgDMx0hvf04D431YjoCHLPQ=; b=TKrwmsJCLdmCyri/g8OYAhZmWV9eLvam0MtgP26ep7l6kkuWzDKQA4zuh1A+cZaTEd V9XFWMsNMMRnlPWQ6BjgvA5XSVaV8XwECoN/2WTdXkyIIupZCOK1QPEHpopMnIhWiZeT HBvKSVqOXt9ra6WwGm1JOXG2gleGxws/2vb3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ISC64DgsBVk97sJf9ZnREY0nnXIyZ0GeLklRVvxeJOY9y/6JSufWDp8mVhVu8aaa5i M0DnPXi1GGrpkJsm21hf9wQgfsFYHBdYUmNYUM1L6Gali7bFC8eL/oABpErFKyno6OIe TSv4GQAyfhQ2MauicYyCG6yEXIMX4+oIs7hww= MIME-Version: 1.0 Received: by 10.223.143.70 with SMTP id t6mr3557091fau.101.1266099132073; Sat, 13 Feb 2010 14:12:12 -0800 (PST) From: Calin Crisan Date: Sat, 13 Feb 2010 23:11:52 +0100 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=0023545bd1a40488d5047f82ad84 Subject: [Roll] few questions regarding RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 22:10:56 -0000 --0023545bd1a40488d5047f82ad84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I'm working on a RPL simulator and I have some questions with respect t= o the version 6 of the RPL draft: (1) At page 32, the document says "* During transition to a new DODAG Iteration, a node may decide to forward packets via =92future parents=92... ". My question here is why do we speak about "transition" in this case? Isn't this process of following a new iteration of the same DODAG immediate= ? Everything that has to be done in this case is re-evaluate the parents/siblings and its own rank, which in my opinion should take place instantly, based on the already stored information. Further sending of new DIO info shouldn't affect the routing decision, should it?* *(2) What's the exact usage of a "multicast DIS message", as mentioned at the top of the page 37? More precisely, in what situation is it sent?* * * * Thanks,* * * * Calin.* * * --0023545bd1a40488d5047f82ad84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =A0=A0 =A0Hi,

=A0=A0 =A0I'm working on a RPL simulat= or and I have some questions with respect to the version 6 of the RPL draft= :
(1) At page 32, the document says "
During transition to a new DODAG Iteration, a node may decide to=A0
forward packets via= =92future parents=92...=A0
". My question here is why do we speak about = "transition" in this case? Isn't this process of following a = new iteration of the same DODAG immediate? Everything that has to be done i= n this case is re-evaluate the parents/siblings and its own rank, which in = my opinion should take place instantly, based on the already stored informa= tion. Further sending of new DIO info shouldn't affect the routing deci= sion, should it?
= (2) What's the exact us= age of a "multicast DIS message", as mentioned at the top of the page 37? = More precisely, in what situation is it sent?<= /i>
=
=A0=A0 =A0Thanks,
=
=A0=A0 =A0Calin.
=
--0023545bd1a40488d5047f82ad84-- From pister@eecs.berkeley.edu Sat Feb 13 15:59:24 2010 Return-Path: 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 982CB3A724C for ; Sat, 13 Feb 2010 15:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.14 X-Spam-Level: X-Spam-Status: No, score=-4.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] 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 pDPpjg9JGgAE for ; Sat, 13 Feb 2010 15:59:21 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 3CDF93A67D1 for ; Sat, 13 Feb 2010 15:59:21 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o1E00hF1012402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Feb 2010 16:00:44 -0800 (PST) Message-ID: <4B773D1D.5030000@eecs.berkeley.edu> Date: Sat, 13 Feb 2010 16:00:29 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Salazar, Ruben" References: <6A2A459175DABE4BB11DE2026AA50A5D01235F36@XMB-AMS-107.cisco.com> <4B67F596.10504@gmail.com> <56EB87C4-1B5B-488C-83A1-7778135E7D33@cisco.com> <09D9C0631368C244941E610D99FEA71001AE11AC@usatlsv105.am.bm.net> In-Reply-To: <09D9C0631368C244941E610D99FEA71001AE11AC@usatlsv105.am.bm.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 23:59:24 -0000 As I have previously stated, I believe that we should move ahead with RPL, but I want to correct a mis-perception about protection. Claims that the Cisco IPR provides any sort of protection are false. Patent law doesn't work that way. To use a silly example, Cisco may patent an automobile with a motor and a steering wheel and give you the rights to make that for free. But someone else can still come after you if they own the rights to anything with a round steering wheel, or internal combustion motors, or vehicles with rubber wheels, or the method that you use to make the steering wheel. Any company's IPR, regardless of what terms they use to offer it, provides us with no protection from anything except the company itself, under the terms that they use. ksjp Salazar, Ruben wrote: > > JP and ROLL team, > > Like most of you, I am trying to form a position regarding this > discussion about Cisco’s IPR, and I can summarize it in a particular way: > > Cisco asks companies that are working in this effort and may > potentially make use of this protocol to renounce to enforce any > potential IPR violation from Cisco to their own IPR and in exchange > these companies get whatever coverage they can get with Cisco’s IPR > essential to this protocol. > > Well, somebody earlier in the exchange compared Cisco’s IPR to a > “protection umbrella” to all this effort. We know that despite any > number of patents that Cisco may consider relevant and essential to it > there could (and there will) be areas that their portfolio would not > cover, so the “umbrella” will have “holes” at best. > > So my conclusion is that by agreeing to Cisco’s terms we would allow > Cisco to “walk” freely anywhere in our “property “ in exchange from an > umbrella with holes to protect work only on RPL. It does not seem right. > > The argument that “it has been done before” is not only weak as > justification for it to continue being done, but also is not > necessarily true: I believe that for every example that can be > produced in that sense there will be tens of examples where > standardization has happened without such terms. > > I also think that knowing what part of the current RPL may be affected > by Cisco’s IPR would not alleviate the concern, it will just help us > see the “holes in the umbrella”. > > The work on ROLL/RPL is supposed to bring standardization in the > relatively new area of low power low reliability wireless networks, > and the best way to help it flourish is by bringing to the table, > together, the elements of our thoughts that can be shared openly and > freely, and leaving the remaining elements to each company to > introduce its own differentiating solutions. > > Regards > > Ruben Salazar, PhD > > Director of Research and Technology > > Landys+Gyr EMS > > Office: 678 258 3165 > > Cellular: 678 438 0063 > > _ruben.salazar@landysgyr.com _ > > _www.landisgyr.com _ > > *manage energy better*** > > > > *Ruben Salazar* > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > *manage energy better* > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *JP Vasseur > *Sent:* Tuesday, February 02, 2010 5:16 AM > *To:* Alexandru Petrescu > *Cc:* ROLL WG > *Subject:* Re: [Roll] Closing on the IPR > > Hi Alex, > > Just to make sure since we're looking for an answer to the following > question: > > "Given the discussions about the IPR disclosure at > https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy at > http://www.ietf.org/ipr/policy.html I would like to make sure that the > working group is happy to proceed with draft-ietf-roll-rpl in its > current form. Please state your opinions on the list. I will make a > consensus call on Friday 11 February. > > " > > Are you OK ? Based on what you said I think that the answer is "yes" > but I wanted to make sure. > > Thanks. > > JP. > > On Feb 2, 2010, at 10:51 AM, Alexandru Petrescu wrote: > > > > Cisco IPR protection umbrella to any group implementing IPR? > > NO! > > If I implement this stuff I will not need Cisco protection - I will > write a different protection, a different licensing scheme. I don't > need Cisco licensing to protect me. What I need from Cisco is to > interoperate. > > Take my stance as moderate - as I previously said, I am generally ok > with Cisco disclosures at IETF - but I never considered it as a > protection umbrella, rather as something that I had to live with. > > This is also why a second disclosure on RPL, from a competitor would be > beneficial. > > Alex > > Le 02/02/2010 08:33, Pascal Thubert (pthubert) a écrit : > > Hi: > > Phil: You're so right. It is also my experience that the process of > > patenting rapidly escapes the author, and the coverage of the > > resulting words is just beyond people like me. I made the exercise > > of browsing the claims for the ten+ disclosures listed, and I'm > > clear that 3 to 6 of these have an application in RPL. How far that > > goes I can hardly assert. I simply think that if some external party > > comes at any of us in the future claiming its own IPR against RPL, > > there's a good probability that the Cisco IPR makes their attack > > quite a bit more difficult on a number of key elements. > > Emmanuel: 1) is my understanding as well. I talked to our legal team > > to try to understand as deeply as I could and my understanding has > > not changed. So We're on the exact same line. I just wanted to make > > it clear that the Cisco IPR is not only a defense for Cisco; it is > > also an umbrella that provides some degree of protection to any > > group that would implement RPL. And 3) is my understanding of what JP > > is asking to the group at this time. Great summary! > > So: 3 - if yes, are we OK with these terms? > > Cheers, > > Pascal -----Original Message----- From: roll-bounces@ietf.org > > > [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: lundi > > 1 février 2010 19:17 To: Emmanuel Baccelli Cc: ROLL WG Subject: Re: > > [Roll] Closing on the IPR > > On Feb 1, 2010, at 9:35 AM, Emmanuel Baccelli wrote: > > Hi JP, > > as discussed, IPR may indeed be difficult to avoid entirely, even > > without looming deadlines... If I recall correctly, we are > > discussing this because someone claimed that Cisco forces an IPR > > deal which, quoting this now famous anonymous, can be summarized > > by the following: > > "Free license to use the patents in RPL so long as you and your > > company don't sue Cisco over any other patent for anything." > > We are engineers, not lawyers, so to understand legal matters, > > most of us need such one-liner to understand what is the deal. > > Therefore in my mind, the right questions that we need to ask > > ourselves at this point are: > > 1 - is the above an accurate summary of the IPR deal imposed by > > Cisco? 2 - if no, what is an accurate summary of the IPR deal > > imposed by Cisco? 3 - if yes, are we OK with these terms? > > Let's clarify this and move on quickly, back to protocol design > > where we belong! > > Agreed -- part of the issue here is that I think it's not really > > possible for Pascal to describe exactly what the patents cover: he's > > not a patent lawyer, and I doubt that Cisco would like him to speak > > for them in this regard. My brief interactions with patent law have > > taught me that it often works quite differently than engineers might > > expect. So we should be careful assuming that we can easily > > understand the full situation. :) > > Phil > > _______________________________________________ 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 mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jonsmirl@gmail.com Sun Feb 14 08:35:35 2010 Return-Path: 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 EA99F3A7704 for ; Sun, 14 Feb 2010 08:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iEczjzqQkIKb for ; Sun, 14 Feb 2010 08:35:34 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id AFA013A677D for ; Sun, 14 Feb 2010 08:35:34 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 5so389848qwi.31 for ; Sun, 14 Feb 2010 08:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cvH1VOPTsr+ONBf90YPs9G+T9HBh2Zp/0anChfe66nQ=; b=sVfMjWkdqigKssxY/usST34RtwT24k769IpI/9uPsgIFoWgiSUkf1jjEIzc53yOv1b F2fsUmjbckgMzG/5gCcpTW1otq1bv2Cj8tJ7BDIO8dAMjJbrQZ0C265t2mnlz3sLumP4 h027Df9Ho0lkfleFVEdPrWbvfJZCSOpz2zH/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LD/s8n3GjZIB3yTMHBAHg7KVzaquNMPiu/5IXSmrMDi4zEPUUzWpf+GcJekEsTuXQz K4CcYZTy0qCb8m/Q4tqcO6sftEbmd1CPZOFeU5ljcsJ/XRO+DKYBYzgw+m/O99QzbljP qxcsPNkgz5ULXJJNUSuv+D3uZwX3uPDWjV/3c= MIME-Version: 1.0 Received: by 10.229.26.135 with SMTP id e7mr200416qcc.58.1266165418911; Sun, 14 Feb 2010 08:36:58 -0800 (PST) Date: Sun, 14 Feb 2010 11:36:58 -0500 Message-ID: <9e4733911002140836m129fd6b3j6c8cb13c747d97c0@mail.gmail.com> From: Jon Smirl To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Free standards vs proprietary standards. (off-topic from the ROLL protocol) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 16:35:36 -0000 This is my personal opinion, I'm not associated with any vendor in the computer industry. Why do we have approximately 40 incompatible home automation networks? I believe this is due to the incorporation of licensed IP into each of these networks. All of these networks offer their IP for licensing but instead we get 40 different networks. These networks get created because each vendor chooses to reinvent the wheel instead of paying fees to their competitors. I've been working in networking for over twenty years, I can think of hundreds of ways to vary the signaling and protocols to create even more incompatible home automation networks. For someone experienced in the networking field it is simply too easy to create yet another variation and avoid licensing. You can even pitch your investors about how you'll be receiving licensing revenue from your new system. Sure these variations may be more inefficient, but does it really matter? What matters much more is avoiding the licensing fees. I have seven incompatible home automation networks in use in my house. It has taken me forever to build bridges linking the various pieces and these bridges are often unreliable. The vendors behind each of these seven network islands behave like monopolists and charge accordingly. If you aren't a software engineer you're going to be locked into one of these islands and pay inflated prices when you expand your network. This model results is great margins for the vendors, but it greatly limits the available market for home automation. In my area it is not common to find home automation systems until the price of the home exceeds $3M. They are non-existent in the $500K price range. As a consumer of these networked items I am fed up with all of the incompatible systems. I want to be able to go down to Home Depot and pick from two or three different dimmers with the confidence that they will all work when I bring them home. I do not want to call an expensive CEDIA rep to change a light switch. If people agree with this vision, how do we achieve it? My experience says the solution is to build a GPL licensed reference implementation of the protocol stack. This stack could be used inside the Linux kernel (and inside common home routers). It could also be used standalone in conjunction with something like Contiki or TinyOS in dimmers. The GPL is excellent neutral ground. It requires everyone to share with each other and licenses everyone for free. For stronger patent protection the code base could be dual licensed GPLv2 and GPLv3. Note that it is implementations that infringe patents, not the standards. The point of the GPL'd implementation is to move the competition up the stack. Quit competing on the networking protocols and instead move the competition higher in the stack to things like Smart Energy. A common networking base will expand the market available to all players. Personally I'd like to see two things: 1) 6lowpan/ROLL added to the Linux kernel. This makes it much easier to build IPv6 routers between WiFi and 802.15.4. All of those little home routers will get a 802.15.4 chip and a big marketing announcement saying "Smart Energy capable" Now a PC/Smartphone can get at power data from smart meters. Or control a network of smart dimmers. 2) A free, GPL licensed stand-alone implementation suitable for use in dimmers. Then encourage Asian manufacturers to flood the US market with 300M "smart" dimmers for $40 each. This will be a cut throat, low margin business, but it will sell a whole lot of 802.15.4 chips. Smart dimmers help a lot with efficiency by allowing an "All Off" button when you leave the house. Everything will be compatible since everything will be running the same code base. These two events should be enough to jump start the use of home automation networks in homes at the $500K level - greatly expanding the market. Now everyone can go back to building high margin add-ons for these newly created customers. -- Jon Smirl jonsmirl@gmail.com From dlang@cisco.com Sun Feb 14 21:40:27 2010 Return-Path: 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 8B41A3A7636 for ; Sun, 14 Feb 2010 21:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5FMOtWzGLk7U for ; Sun, 14 Feb 2010 21:40:26 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 625F13A7616 for ; Sun, 14 Feb 2010 21:40:26 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,474,1262563200"; d="scan'208,217";a="483016296" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Feb 2010 05:41:54 +0000 Received: from [192.168.1.108] (sjc-vpn5-1297.cisco.com [10.21.93.17]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1F5fsh3019933; Mon, 15 Feb 2010 05:41:54 GMT Message-Id: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> From: Dan Lang To: Ruben.Salazar@landisgyr.com Content-Type: multipart/alternative; boundary=Apple-Mail-22-142505489 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 14 Feb 2010 21:41:54 -0800 X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 05:40:27 -0000 --Apple-Mail-22-142505489 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Ruben, A couple of points that I'd like to clarify in response to your email. Again, I recommend that you check with your company's attorneys but at least let me suggest some things to ask them about. 1. No one is being asked to "renounce their IPR." But, per our statement, an entity that wants to make money on or otherwise exploit their patents against Cisco products might have to pay something for a license to Cisco's patents. That seems fair to me, but more importantly, it seems fair to a lot of people who find sufficient assurance with our commitment to make numerous IETF standards successful. 2. We would never claim that our intellectual property provides an "umbrella" for the industry. Having the right to use one company's patents does not give you the right to use other patents if they are relevant. Potential exposure to unknown third party patents is always a concern in the information technology industry. Due to the large number of patents and the challenges of searching for them and evaluating them, it would be almost impossible to reliably identify all of the relevant patents for a particular product or standard. But our patents and our licensing commitment are not the cause of this problem. Even if our patents did not exist at all, the problem would still be there. That is why I agree with some of the commenters who pointed out that it is very difficult to avoid intellectual property concerns entirely because they cannot all be known. Best regards, Dan Dan Lang Director, Intellectual Property Legal Services Cisco Systems, Inc. --Apple-Mail-22-142505489 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = Ruben,
A couple of points = that I'd like to clarify in response to your email.  Again, I = recommend that you check with your company's attorneys but at least let = me suggest some things to ask them = about.
1.  No one is = being asked to "renounce their IPR."     But, per our = statement, an entity that wants to make money on or otherwise exploit = their patents against Cisco products might have to pay something for a = license to Cisco's patents.  That seems fair to me, but more = importantly, it seems fair to a lot of people who find sufficient = assurance with our commitment to make numerous IETF standards = successful.
2.  We would = never claim that our intellectual property provides an "umbrella" for = the industry.   Having the right to use one company's patents does = not give you the right to use other patents if they are relevant.   = Potential exposure to unknown third party patents is always a concern in = the information technology industry.  Due to the large number of = patents and the challenges of searching for them and evaluating them, it = would be almost impossible to reliably identify all of the relevant = patents for a particular product or standard.  But our patents and = our licensing commitment are not the cause of this problem.  Even = if our patents did not exist at all, the problem would still be there. =   That is why I agree with some of the commenters who pointed out = that it is very difficult to avoid intellectual property concerns = entirely because they cannot all be = known.
Best = regards,
Dan
; Mon, 15 Feb 2010 06:25:25 GMT Message-Id: <422FDE4C-C74D-4383-BE98-68C8AB074480@cisco.com> From: Dan Lang To: roll@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-73-145116827 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 14 Feb 2010 22:25:25 -0800 X-Mailer: Apple Mail (2.936) Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 06:23:57 -0000 --Apple-Mail-73-145116827 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable In addition to responding to Ruben, I'd like to comment on a couple of =20= other points that have been raised. One commenter worried that they =20 will =93be forced to use RPL and pay Cisco royalties because Smart =20 Energy 2.0 is specifying RPL as their routing protocol=94 = (http://www.ietf.org/mail-archive/web/roll/current/msg03008.html=20 ); another asked if Cisco would be =93willing to provide a royalty-free =20= license to their patents=94 = (http://www.ietf.org/mail-archive/web/roll/current/msg03015.html=20 ). Again, you should consult with your own legal counsel, but Cisco=92s = =20 statement will have the same practical effect to you as a royalty-free =20= patent license. In essence, Cisco is promising not to sue you, and is =20= not asking you to pay it any royalties, under any Cisco essential =20 patents, for any of your products that implement the RPL standard. As =20= I mentioned before, this commitment may go away if you sue Cisco with =20= your own patents. In that case, Cisco may ask you to pay for a =20 license to its essential RPL patents on reasonable and non-=20 discriminatory terms. Best regards, Dan Dan Lang Director, Intellectual Property Legal Services Cisco Systems, Inc.= --Apple-Mail-73-145116827 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable In addition to responding to = Ruben, I'd like to comment on a couple of other points that have been = raised.  One commenter worried that they will =93be forced to use = RPL and pay Cisco royalties because Smart Energy 2.0 is specifying RPL = as their routing protocol=94  (h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03008.html); = another asked if Cisco would be =93willing to provide a royalty-free = license to their patents=94 (h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03015.html). = Again, you should consult with your own legal counsel, but Cisco=92s = statement will have the same practical effect to you as a royalty-free = patent license.  In essence, Cisco is promising not to sue you, and = is not asking you to pay it any royalties, under any Cisco essential = patents, for any of your products that implement the RPL standard.  = As I mentioned before, this commitment may go away if you sue Cisco with = your own patents.  In that case, Cisco may ask you to pay for a = license to its essential RPL patents on reasonable and = non-discriminatory terms.  

Best = regards,
Dan


Dan Lang
Director, Intellectual Property
Legal = Services
Cisco Systems, = Inc.
= --Apple-Mail-73-145116827-- From jonsmirl@gmail.com Mon Feb 15 05:31:59 2010 Return-Path: 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 2280F3A769C for ; Mon, 15 Feb 2010 05:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0bMHIbAWG1Ep for ; Mon, 15 Feb 2010 05:31:58 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id E722E3A798D for ; Mon, 15 Feb 2010 05:31:57 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 5so528649qwi.31 for ; Mon, 15 Feb 2010 05:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9JaQO05dZzvw+AiPM/w9llJpCM7BpsyDqdhEmkvNGd0=; b=ZOgut7U3cwQw5Dbo573Gi/gnWpDrpk487iMrWnZCWtqsHMFxumZJ9dy6MRhl5hwlZk LWhpqlCQhzjeRR3mavkPjTOv2NuPyxhhwdvzi2Vja3DqQP9d7jcik+Uo/ShEm7hJk7PI xGxZM9c8E0OpZKM3M6V4nJOA52PoPgvos4oi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lOMImQd9dNpn80JCcH2Cwd509YNkEyOUO9SWDGIS8ATaA/ghNLbuaMOJGUxAmeyR+t +OXY+OdXK5OKPn64zZNdJ2cPikt0j4JHqrD6yf4HX4rnBj8whL7XvKb1z/MKgvI39Pla wwVu+4dSE71oY3AZYVV5Ghce3rR/QBlsQoxlE= MIME-Version: 1.0 Received: by 10.229.251.69 with SMTP id mr5mr469169qcb.91.1266240803929; Mon, 15 Feb 2010 05:33:23 -0800 (PST) In-Reply-To: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> Date: Mon, 15 Feb 2010 08:33:23 -0500 Message-ID: <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> From: Jon Smirl To: Dan Lang Content-Type: multipart/alternative; boundary=0016363b91205180c3047fa3a998 Cc: roll@ietf.org, Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:31:59 -0000 --0016363b91205180c3047fa3a998 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang wrote: > Hi Ruben, > A couple of points that I'd like to clarify in response to your email. > Again, I recommend that you check with your company's attorneys but at > least let me suggest some things to ask them about. > > 1. No one is being asked to "renounce their IPR." But, per our > statement, an entity that wants to make money on or otherwise exploit their > patents against Cisco products might have to pay something for a license to > Cisco's patents. That seems fair to me, but more importantly, it seems fair > to a lot of people who find sufficient assurance with our commitment to make > numerous IETF standards successful. > >From a legal sense, is your statement compatible with the GPL? I just want to ensure that we can build a GPL'd version of RPL. I don't want to repeat the problems with Zigbee where their licensing is incompatible with the GPL. > > 2. We would never claim that our intellectual property provides an > "umbrella" for the industry. Having the right to use one company's patents > does not give you the right to use other patents if they are relevant. > Potential exposure to unknown third party patents is always a concern in the > information technology industry. Due to the large number of patents and the > challenges of searching for them and evaluating them, it would be almost > impossible to reliably identify all of the relevant patents for a particular > product or standard. But our patents and our licensing commitment are not > the cause of this problem. Even if our patents did not exist at all, the > problem would still be there. That is why I agree with some of the > commenters who pointed out that it is very difficult to avoid intellectual > property concerns entirely because they cannot all be known. > Trolls are everywhere and can't be identified ahead of time. Do you feel that the GPL and the set of companies surrounding the Linux kernel somewhat protects it from troll attacks? Would implementing the reference version of RPL inside the Linux kernel provide added protection to RPL users? As we reasonably sure that there aren't problem patents held by direct competitors who aren't participating in ROLL and might be interested in disrupting ROLL? > Best regards, > Dan > > > > Dan Lang > Director, Intellectual Property > Legal Services > Cisco Systems, Inc. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > -- Jon Smirl jonsmirl@gmail.com --0016363b91205180c3047fa3a998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 15, 2010 at 12:41 AM, Dan La= ng <dlang@cisco.com> wrote:
Hi = Ruben,
A couple of points that I'd like to clarify in response to your email. = =A0Again, I recommend that you check with your company's attorneys but = at least let me suggest some things to ask them about.
=A0
1. =A0No one is being aske= d to "renounce their IPR." =A0 =A0 But, per our statement, an ent= ity that wants to make money on or otherwise exploit their patents against = Cisco products might have to pay something for a license to Cisco's pat= ents. =A0That seems fair to me, but more importantly, it seems fair to a lo= t of people who find sufficient assurance with our commitment to make numer= ous IETF standards successful.

From a legal sense, is your statement com= patible with the GPL? I just want to ensure that we can build a GPL'd v= ersion of RPL. I don't want to repeat the problems with Zigbee where th= eir licensing is incompatible with the GPL.
=A0=
2. =A0We would never claim that our intellectual property provides an "= ;umbrella" for the industry. =A0 Having the right to use one company&#= 39;s patents does not give you the right to use other patents if they are r= elevant. =A0 Potential exposure to unknown third party patents is always a = concern in the information technology industry. =A0Due to the large number = of patents and the challenges of searching for them and evaluating them, it= would be almost impossible to reliably identify all of the relevant patent= s for a particular product or standard. =A0But our patents and our licensin= g commitment are not the cause of this problem. =A0Even if our patents did = not exist at all, the problem would still be there. =A0 That is why I agree= with some of the commenters who pointed out that it is very difficult to a= void intellectual property concerns entirely because they cannot all be kno= wn.

Trolls are everywhere and can't be id= entified ahead of time. Do you feel that the GPL and the set of companies s= urrounding the Linux kernel somewhat protects it from troll attacks? Would = implementing the reference version of RPL inside the Linux kernel provide a= dded protection to RPL users?

As we reasonably sure that there aren't problem patents held by dir= ect competitors who aren't participating in ROLL and might be intereste= d in disrupting ROLL?

=A0
Best regards,
Dan
<= table style=3D"width: 543px;" cellpadding=3D"0" cellspacing=3D"0" width=3D"= 543.0">
=



Dan Lang
Director, Intellectual Propert= y
Legal Services
Cisco Systems, Inc.

___= ____________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll




--
Jon Smirl
jonsmirl@gmail.com --0016363b91205180c3047fa3a998-- From sung.lee@us.fujitsu.com Mon Feb 15 07:16:22 2010 Return-Path: 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 728B23A7B6E for ; Mon, 15 Feb 2010 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 XzRwX43k2Qzx for ; Mon, 15 Feb 2010 07:16:21 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 92BA93A7B72 for ; Mon, 15 Feb 2010 07:16:21 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o1FFJ2rg002111 for ; Mon, 15 Feb 2010 07:19:02 -0800 (PST) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o1FFJ2kJ002108 for ; Mon, 15 Feb 2010 07:19:02 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id o1FFHk6u011504 for ; Mon, 15 Feb 2010 07:17:46 -0800 (PST) Received: from [10.157.253.31] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id o1FFHhf10347 for ; Mon, 15 Feb 2010 07:17:44 -0800 (PST) Message-ID: <4B796581.5040707@us.fujitsu.com> Date: Mon, 15 Feb 2010 10:17:21 -0500 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 15:16:22 -0000 Dear Dan, I am checking with our legal team on this issue. Meanwhile, could you please answer one yes-no question for me? That would help me understand the situation better. Is this following scenario true? Scenario: - My company implements and sells products with RPL with essentially a loyal-free term. - Cisco does something that infringes on my company's patents (completely unrelated to RPL or not even in smart grid domain). - When my company decides to sue, then my company would have to pay for a license on RPL. The key point in this hypothetical scenario is that Cisco infringes on our patents NOT related to RPL. Following the conversation on Cisco IPR issue so far, my understanding is YES. But I would like to hear it from you. Thank you and best regards, Sung > In addition to responding to Ruben, I'd like to comment on a couple > of other points that have been raised. One commenter worried that > they will “be forced to use RPL and pay Cisco royalties because > Smart Energy 2.0 is specifying RPL as their routing protocol” > (http://www.ietf.org/mail-archive/web/roll/current/msg03008.html); > another asked if Cisco would be “willing to provide a royalty-free > license to their patents” > (http://www.ietf.org/mail-archive/web/roll/current/msg03015.html). > Again, you should consult with your own legal counsel, but Cisco’s > statement will have the same practical effect to you as a royalty-free > patent license. In essence, Cisco is promising not to sue you, > and is not asking you to pay it any royalties, under any Cisco essential > patents, for any of your products that implement the RPL standard. > As I mentioned before, this commitment may go away if you sue > Cisco with your own patents. In that case, Cisco may ask you to > pay for a license to its essential RPL patents on reasonable and > non-discriminatory terms. > > Best regards, > Dan From wintert@acm.org Mon Feb 15 11:30:09 2010 Return-Path: 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 776943A75BD for ; Mon, 15 Feb 2010 11:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fARlH1zo3kel for ; Mon, 15 Feb 2010 11:30:08 -0800 (PST) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id D46553A6BF8 for ; Mon, 15 Feb 2010 11:30:07 -0800 (PST) Received: (qmail 6761 invoked from network); 15 Feb 2010 19:31:36 -0000 Received: from (wintert@209.48.242.70 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 15 Feb 2010 11:31:36 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: DrMz1.cVM1mYnasqP56z4d9FutC5BcQEXgWBXweYlkV9ly5vkdh7bo4TCgJU1vVTDDaXORbfF5WWRI0R.VlkMZL.fJxuReqVzfkoTEQZavJ9O6TVRJxKIgrS351Sm52Val_YJuM5ncUsxVKidsokJi1tfXVZ2fGL0l4ZBKdQIEZtNvQukTg6LW0jX10TtMn6QHD737dKa2nDlxaWV6ANPnkZWFFyfy1a7OcqUDPAPWreRX3tadvK41IDPswkC2dzK6E0ARRA6okRhOYrQpi53mBXUSizt5rPPMvDQDyYqL16uVjv0Bn5K5EtKioBaOCfDZWtVZ2RZpeI7jOOonUb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B79A120.8030104@acm.org> Date: Mon, 15 Feb 2010 14:31:44 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] few questions regarding RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 19:30:09 -0000 Hi Calin, Calin Crisan wrote: > Hi, > > I'm working on a RPL simulator and I have some questions with > respect to the version 6 of the RPL draft: > (1) At page 32, the document says "//// > During transition to a new DODAG Iteration, a node may decide to > //// > forward packets via ’future parents’... > //"//. My question here is why do we speak about "transition" in this > case? Isn't this process of following a new iteration of the same DODAG > immediate? Everything that has to be done in this case is re-evaluate > the parents/siblings and its own rank, which in my opinion should take > place instantly, based on the already stored information. Further > sending of new DIO info shouldn't affect the routing decision, should > it?//// Here the spec leaves some room to the implementation. Some implementations may choose to immediately transition to the new iteration, others may choose to delay somewhat. Consider for example the case where a node hears a DIO for a new iteration from a candidate neighbor that is not presently in the DODAG Parent set -- perhaps such a node would benefit by waiting a small delay to hear from present DODAG Parents before moving. A node has not necessarily 'committed' to the next DODAG iteration until it has advertised a DIO to that effect (i.e. with the new sequence number). > ////(2) What's the exact usage of a "multicast DIS message", as > mentioned at the top of the page 37? More precisely, in what situation > is it sent?//// The most common use case might be where a node needs to 'probe' its neighborhood and does not want to wait for neighbors to send DIOs. For example, a battery powered node may benefit from soliciting DIOs from its neighbors (e.g. at installation/provisioning). > //// > //// > //// Thanks,//// > //// > //// > //// Calin.//// > //// > //// Regards, -Tim > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jreddy@ti.com Mon Feb 15 11:41:38 2010 Return-Path: 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 0FD383A7BD5 for ; Mon, 15 Feb 2010 11:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=-2.048, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, LOCALPART_IN_SUBJECT=2.02, SUBJ_ALL_CAPS=2.077] 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 HMMOeQ2BD1EL for ; Mon, 15 Feb 2010 11:41:37 -0800 (PST) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by core3.amsl.com (Postfix) with ESMTP id 456D73A7BD0 for ; Mon, 15 Feb 2010 11:41:37 -0800 (PST) Received: from dlep34.itg.ti.com ([157.170.170.115]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id o1FJh8B9022689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Feb 2010 13:43:08 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep34.itg.ti.com (8.13.7/8.13.7) with ESMTP id o1FJh8SW001498 for ; Mon, 15 Feb 2010 13:43:08 -0600 (CST) Received: from dlee75.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1FJh8UX015809 for ; Mon, 15 Feb 2010 13:43:08 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee75.ent.ti.com ([157.170.170.72]) with mapi; Mon, 15 Feb 2010 13:43:07 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Mon, 15 Feb 2010 13:43:09 -0600 Thread-Topic: IPR ROLL Thread-Index: AcqsYWlUAfSw1ZhCQlOnAbpMaxnvYwCFV2iw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 19:41:38 -0000 =20 Hi JP, Adrian, I am not in favour of moving with the current RPL draft under the proposed = licensing terms.=20 -Regards, Joseph >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Fri, 12 Feb 2010 21:41:47 +0100 >>From: JP Vasseur >>Subject: [Roll] IPR ROLL >>To: ROLL WG >>Message-ID: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> >>Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; delsp=3Dye= s >> >>Dear all, >> >>When I look back over the last six to nine months I am really=20 >>impressed with the progress we have made developing RPL.=20 >>There are multiple implementations already in progress to=20 >>show that the solution can really work. >> >>The IPR issue is very important, of course. So far quite a=20 >>few people have made comments, but I do not see a clear=20 >>consensus and I would like to hear from more people. >> >>At the same time, I don't think it would be appropriate for=20 >>me to judge the consensus on this issue because my company=20 >>affiliation might be considered to influence my independent=20 >>IETF role. Therefore I have asked our Routing Area Director=20 >>Adrian Farrel to take the judgement decision. >> >>Thanks Adrian for accepting to do this job. >> >>JP. >> >> From ccrisan@gmail.com Mon Feb 15 12:58:30 2010 Return-Path: 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 42BD73A7870 for ; Mon, 15 Feb 2010 12:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yRe9OaK2vMvA for ; Mon, 15 Feb 2010 12:58:29 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id BDC7C3A682A for ; Mon, 15 Feb 2010 12:58:28 -0800 (PST) Received: by fxm7 with SMTP id 7so6285040fxm.28 for ; Mon, 15 Feb 2010 12:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=KdOvLFVqw2dHauAvGkgoV/Y4cvej9DQKkr0IMBDA2uA=; b=Y2/PTzW4YQyhSsv0TnQkcufgdm6TVrA7BvuRXE8XjoyPGQye48814X8kGEE7UjiGgP mcWTrxBnVYayeOKQ7AN6ETQq158CSewor8XYlS0wWXxZlZir6vVJaB1WrEI3XlrU/vqs wN2O9GGazAgU64spi2lYY8wMgu0BotdVw5+Jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VEYNhBndpdzCt+NfTxoWL66l7sKZJgwg1kl7WbXYYT4wjnlXZJ48FeTRUfceVeKoZt Iz57YKe4KJQOHnsVtxa0hrqAOHbkgSJormHkJwh2Hf7vbXucSaUNEYmpregAvO7wk9Jz fmuVOjOaOM2LD9Glf9gPgt12PL7J9iNQn/zbI= MIME-Version: 1.0 Received: by 10.223.62.78 with SMTP id w14mr4385208fah.82.1266267596211; Mon, 15 Feb 2010 12:59:56 -0800 (PST) In-Reply-To: <4B79A120.8030104@acm.org> References: <4B79A120.8030104@acm.org> From: Calin Crisan Date: Mon, 15 Feb 2010 21:59:36 +0100 Message-ID: To: Tim Winter Content-Type: multipart/alternative; boundary=0015174029d24345c6047fa9e684 Cc: ROLL WG Subject: Re: [Roll] few questions regarding RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:58:30 -0000 --0015174029d24345c6047fa9e684 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks for the answers. For the first question everything is clear now. Concerning the second one, I guess I was misled by the sentence on page 29: "*This suboption MAY be included occasionally by the DODAG Root, and MUST b= e included in response to a unicast request, e.g. a DODAG Information Solicitation (DIS) message.*", and the one at page 37: "*When a node receives a unicast DIS message, it MUST unicast a DIO message in response, and MUST include the DODAG Configuration Object.*". The only explicit occurrence of multicast DIS is on the same page 37, which simply requires a trickle timer reset. Should this timer be reset whenever a new node probes for nearby DODAGs, anyway? Thanks, Calin. On Mon, Feb 15, 2010 at 8:31 PM, Tim Winter wrote: > Hi Calin, > > > Calin Crisan wrote: > > Hi, > > > > I'm working on a RPL simulator and I have some questions with > > respect to the version 6 of the RPL draft: > > (1) At page 32, the document says "//// > > During transition to a new DODAG Iteration, a node may decide to > > //// > > forward packets via =92future parents=92... > > //"//. My question here is why do we speak about "transition" in this > > case? Isn't this process of following a new iteration of the same DODAG > > immediate? Everything that has to be done in this case is re-evaluate > > the parents/siblings and its own rank, which in my opinion should take > > place instantly, based on the already stored information. Further > > sending of new DIO info shouldn't affect the routing decision, should > > it?//// > > Here the spec leaves some room to the implementation. Some implementatio= ns > may > choose to immediately transition to the new iteration, others may choose = to > delay > somewhat. Consider for example the case where a node hears a DIO for a n= ew > iteration > from a candidate neighbor that is not presently in the DODAG Parent set -= - > perhaps > such a node would benefit by waiting a small delay to hear from present > DODAG Parents > before moving. A node has not necessarily 'committed' to the next DODAG > iteration > until it has advertised a DIO to that effect (i.e. with the new sequence > number). > > > > ////(2) What's the exact usage of a "multicast DIS message", as > > mentioned at the top of the page 37? More precisely, in what situation > > is it sent?//// > > The most common use case might be where a node needs to 'probe' its > neighborhood and > does not want to wait for neighbors to send DIOs. For example, a battery > powered > node may benefit from soliciting DIOs from its neighbors (e.g. at > installation/provisioning). > > > //// > > //// > > //// Thanks,//// > > //// > > //// > > //// Calin.//// > > //// > > //// > > > > Regards, > > -Tim > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > 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 > --0015174029d24345c6047fa9e684 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =A0=A0 =A0Hi Tim,

=A0=A0 =A0Thanks for the answers. For = the first question everything is clear now. Concerning the second one, I gu= ess I was misled by the sentence on page 29: "This suboption MAY be= included occasionally by the DODAG Root,=A0and MUST be included in respons= e to a unicast request, e.g. a DODAG=A0Information Solicitation (DIS) messa= ge.", and the one at page 37: "When a node receives a unic= ast DIS message, it MUST unicast a DIO=A0message in response, and MUST incl= ude the DODAG Configuration=A0Object.". The only explicit=A0occurr= ence=A0of multicast DIS is on the same page 37, which simply requires a tri= ckle timer reset. Should this timer be reset whenever a new node probes for= nearby DODAGs, anyway?

=A0=A0 =A0Thanks,

=A0=A0 =A0Ca= lin.

On Mon, Feb 15, 2010 at = 8:31 PM, Tim Winter <wintert@acm.org> wrote:
Hi Calin,


Calin Crisan wrote:
> =A0 =A0 Hi,
>
> =A0 =A0 I'm working on a RPL simulator and I have some questions w= ith
> respect to the version 6 of the RPL draft:
> (1) At page 32, the document says "////
> During transition to a new DODAG Iteration, a node may decide to
> ////
> forward packets via =92future parents=92...
> //"//. My question here is why do we speak about "transition= " in this
> case? Isn't this process of following a new iteration of the same = DODAG
> immediate? Everything that has to be done in this case is re-evaluate<= br> > the parents/siblings and its own rank, which in my opinion should take=
> place instantly, based on the already stored information. Further
> sending of new DIO info shouldn't affect the routing decision, sho= uld
> it?////

Here the spec leaves some room to the implementation. =A0Some implementatio= ns may
choose to immediately transition to the new iteration, others may choose to= delay
somewhat. =A0Consider for example the case where a node hears a DIO for a n= ew iteration
from a candidate neighbor that is not presently in the DODAG Parent set -- = perhaps
such a node would benefit by waiting a small delay to hear from present DOD= AG Parents
before moving. =A0A node has not necessarily 'committed' to the nex= t DODAG iteration
until it has advertised a DIO to that effect (i.e. with the new sequence nu= mber).


> ////(2) What's the exact usage of a "multicast DIS message&qu= ot;, as
> mentioned at the top of the page 37? More precisely,= in what situation
> is it sent?////

The most common use case might be where a node needs to 'probe' its= neighborhood and
does not want to wait for neighbors to send DIOs. =A0For example, a battery= powered
node may benefit from soliciting DIOs from its neighbors (e.g. at
installation/provisioning).

> ////
> ////
> //// =A0 =A0Thanks,////
> ////
> ////
> //// =A0 =A0Calin.////
> ////
> ////



Regards,

-Tim


>
>
> ----------------------------------------------------------------------= --
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0015174029d24345c6047fa9e684-- From joakime@sics.se Mon Feb 15 13:32:57 2010 Return-Path: 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 B4D5028C10F for ; Mon, 15 Feb 2010 13:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 lYV8b7qBkLQA for ; Mon, 15 Feb 2010 13:32:57 -0800 (PST) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by core3.amsl.com (Postfix) with ESMTP id C715928C108 for ; Mon, 15 Feb 2010 13:32:56 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC037C0C34 for roll@ietf.org; Mon, 15 Feb 2010 22:34:26 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcWAK1MeUtV5BLKPGdsb2JhbAAHmxoBAQEBN7x7hFsE X-IronPort-AV: E=Sophos;i="4.49,479,1262559600"; d="scan'208";a="37697153" Received: from c-ca12e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [192.168.1.144]) ([85.228.18.202]) by ipb1.telenor.se with ESMTP; 15 Feb 2010 22:34:26 +0100 Message-ID: <4B79BDE6.7060509@sics.se> Date: Mon, 15 Feb 2010 22:34:30 +0100 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> In-Reply-To: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:32:57 -0000 I vote for ROLL WG to continue with RPL. Modifying RPL will likely only move us from these patents right into some other, yet unknown, patents. I believe that it will be very hard to find a reasonably good protocol that is not conflicting with some patents. Best regards, -- Joakim Eriksson, SICS JP Vasseur skrev 2010-02-12 21:41: > Dear all, > > When I look back over the last six to nine months I am really impressed > with the progress we have made developing RPL. There are multiple > implementations already in progress to show that the solution can really > work. > > The IPR issue is very important, of course. So far quite a few people > have made comments, but I do not see a clear consensus and I would like > to hear from more people. > > At the same time, I don't think it would be appropriate for me to judge > the consensus on this issue because my company affiliation might be > considered to influence my independent IETF role. Therefore I have asked > our Routing Area Director Adrian Farrel to take the judgement decision. > > Thanks Adrian for accepting to do this job. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Feb 15 14:48:31 2010 Return-Path: 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 BF3AE3A7A4C for ; Mon, 15 Feb 2010 14:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 B9tE0faIzEyD for ; Mon, 15 Feb 2010 14:48:30 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 981D53A7A55 for ; Mon, 15 Feb 2010 14:48:30 -0800 (PST) Received: from dn0a2019a6.sunet ([10.32.25.166]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nh9lS-00038o-E2 for roll@ietf.org; Mon, 15 Feb 2010 14:50:02 -0800 From: Philip Levis Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-61-204193430 Date: Mon, 15 Feb 2010 14:50:02 -0800 In-Reply-To: To: ROLL WG References: Message-Id: X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 1620fcb02ed1792cf65161168a9fe1e9 Subject: [Roll] Let's do our homework: RPL and Cisco IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:48:31 -0000 --Apple-Mail-61-204193430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not a patent lawyer by any means. But one thing which worries me about this discussion is that, no-one has = even claimed to have looked at the patents and patent applications for a = sanity check of what might apply. Of course we'd all like someone from = Cisco to speak up on this, but that doesn't mean we ourselves can't do a = little homework. Patent law can be very complex, but it's not = irrational.=20 Most of the patents in the IPR disclosure deal with mobility and mobile = ad-hoc routers, e.g., Pascal's prior work on NEMO. For example, = "Multicast support by mobile routers in a mobile ad hoc network." The only one that raised a possible red flag for me was patent = *application* 20070091811: http://www.freepatentsonline.com/y2007/0091811.html "Forwarding packets to a directed acyclic graph destination using link = selection based on received link metrics" Of course "raise a red flag for me" means "an academic who isn't a = patent lawyer thinks it might possibly apply." All of the others seemed = to have nothing to do with RPL, at all. At least, that's how I, as = someone with ordinary skill in the art, would interpret the claims = besides the one above. I'd have to read closely to understand fully. And = I'd implore everyone on this list who has concerns to do so. I understand that there are business as well as technical concerns in = play here, I just want to make sure that our discussion is based on = fact, not hypothesis. Phil= --Apple-Mail-61-204193430 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The only one that raised a = possible red flag for me was patent *application* 20070091811:

http://www.fr= eepatentsonline.com/y2007/0091811.html

"Forwarding packets to = a directed acyclic graph destination using link selection based on = received link metrics"

Of course "raise a red flag for me" means = "an academic who isn't a patent lawyer thinks it might possibly apply." = All of the others seemed to have nothing to do with RPL, at all. At = least, that's how I, as someone with ordinary skill in the art, would = interpret the claims besides the one above. I'd have to read closely to = understand fully. And I'd implore everyone on this list who has concerns = to do so.

I understand that there are business as well = as technical concerns in play here, I just want to make sure that our = discussion is based on fact, not = hypothesis.

Phil
= --Apple-Mail-61-204193430-- From dlang@cisco.com Mon Feb 15 15:31:45 2010 Return-Path: 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 199A228C11B for ; Mon, 15 Feb 2010 15:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6XgN4ij9dNfa for ; Mon, 15 Feb 2010 15:31:43 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF7D13A7BE9 for ; Mon, 15 Feb 2010 15:31:43 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMFoeUurR7Hu/2dsb2JhbACBQplWdKVglyiCRgeCDgSDFIs+ X-IronPort-AV: E=Sophos;i="4.49,480,1262563200"; d="scan'208,217";a="483449536" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Feb 2010 23:33:16 +0000 Received: from dhcp-171-70-234-89.cisco.com (dhcp-171-70-234-89.cisco.com [171.70.234.89]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1FNXGmB005219; Mon, 15 Feb 2010 23:33:16 GMT Message-Id: <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> From: Dan Lang To: Jon Smirl In-Reply-To: <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-418-206787372 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 15 Feb 2010 15:33:16 -0800 References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org, Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 23:31:45 -0000 --Apple-Mail-418-206787372 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Jon: I am not your lawyer, so I unfortunately won=92t be able to answer your =20= question (=93=46rom a legal sense, is your statement compatible with the = =20 GPL?=94) in way that satisfies you. However, I don=92t think that = having =20 RPL inside the Linux kernel under a GPL license would somehow =20 =93protect=94 RPL and its implementers from patent "troll" attacks. The = =20 entities you are worried about don=92t typically have any products, and =20= the GPL provides conditions on those who distribute or modify covered =20= works, so they would not likely be bound by any of those conditions. =20= If anything, they would have a larger pool of companies against which =20= to assert their patents. Your last question highlights the risk of standard-setting generally; =20= competitors or any third parties who aren=92t participating in ROLL =20 don=92t necessarily have an obligation to disclose any of their patents =20= to the IETF and may choose to wait until after the standard is =20 finalized to demand fees (and not necessarily on reasonable and non-=20 discriminatory terms) for RPL-compliant products. This unfortunate =20 fact will be true no matter what the RPL specification looks like. Best regards, Dan On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: > > > On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang wrote: > Hi Ruben, > A couple of points that I'd like to clarify in response to your =20 > email. Again, I recommend that you check with your company's =20 > attorneys but at least let me suggest some things to ask them about. > > 1. No one is being asked to "renounce their IPR." But, per our =20= > statement, an entity that wants to make money on or otherwise =20 > exploit their patents against Cisco products might have to pay =20 > something for a license to Cisco's patents. That seems fair to me, =20= > but more importantly, it seems fair to a lot of people who find =20 > sufficient assurance with our commitment to make numerous IETF =20 > standards successful. > > =46rom a legal sense, is your statement compatible with the GPL? I =20 > just want to ensure that we can build a GPL'd version of RPL. I =20 > don't want to repeat the problems with Zigbee where their licensing =20= > is incompatible with the GPL. > > 2. We would never claim that our intellectual property provides an =20= > "umbrella" for the industry. Having the right to use one company's =20= > patents does not give you the right to use other patents if they are =20= > relevant. Potential exposure to unknown third party patents is =20 > always a concern in the information technology industry. Due to the =20= > large number of patents and the challenges of searching for them and =20= > evaluating them, it would be almost impossible to reliably identify =20= > all of the relevant patents for a particular product or standard. =20 > But our patents and our licensing commitment are not the cause of =20 > this problem. Even if our patents did not exist at all, the problem =20= > would still be there. That is why I agree with some of the =20 > commenters who pointed out that it is very difficult to avoid =20 > intellectual property concerns entirely because they cannot all be =20 > known. > > Trolls are everywhere and can't be identified ahead of time. Do you =20= > feel that the GPL and the set of companies surrounding the Linux =20 > kernel somewhat protects it from troll attacks? Would implementing =20 > the reference version of RPL inside the Linux kernel provide added =20 > protection to RPL users? > > As we reasonably sure that there aren't problem patents held by =20 > direct competitors who aren't participating in ROLL and might be =20 > interested in disrupting ROLL? > > > Best regards, > Dan > > > > Dan Lang > Director, Intellectual Property > Legal Services > Cisco Systems, Inc. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > --=20 > Jon Smirl > jonsmirl@gmail.com --Apple-Mail-418-206787372 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi = Jon:
I am = not your lawyer, so I unfortunately won=92t be able to answer your = question (=93=46rom a legal sense, is your statement compatible with the = GPL?=94) in way that satisfies you.  However, I don=92t think that = having RPL inside the Linux kernel under a GPL license would somehow = =93protect=94 RPL and its implementers from patent "troll" = attacks.  The entities you are worried about don=92t typically have = any products, and the GPL provides conditions on those who distribute or = modify covered works, so they would not likely be bound by any of those = conditions.   If anything, they would have a larger pool of = companies against  which to assert their = patents. 
Your = last question highlights the risk of standard-setting generally; = competitors or any third parties who aren=92t participating in ROLL = don=92t necessarily have an obligation to disclose any of their patents = to the IETF and may choose to wait until after the standard is finalized = to demand fees (and not necessarily on reasonable and non-discriminatory = terms) for RPL-compliant products.  This unfortunate fact will be = true no matter what the RPL specification looks = like.
Best = regards,
=


On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang <dlang@cisco.com> wrote:
Hi = Ruben,
A couple of = points that I'd like to clarify in response to your email.  Again, = I recommend that you check with your company's attorneys but at least = let me suggest some things to ask them about.
 
1. =  No one is being asked to "renounce their IPR."     But, = per our statement, an entity that wants to make money on or otherwise = exploit their patents against Cisco products might have to pay something = for a license to Cisco's patents.  That seems fair to me, but more = importantly, it seems fair to a lot of people who find sufficient = assurance with our commitment to make numerous IETF standards = successful.

=46rom a legal = sense, is your statement compatible with the GPL? I just want to ensure = that we can build a GPL'd version of RPL. I don't want to repeat the = problems with Zigbee where their licensing is incompatible with the = GPL.
 
2. =  We would never claim that our intellectual property provides an = "umbrella" for the industry.   Having the right to use one = company's patents does not give you the right to use other patents if = they are relevant.   Potential exposure to unknown third party = patents is always a concern in the information technology industry. =  Due to the large number of patents and the challenges of searching = for them and evaluating them, it would be almost impossible to reliably = identify all of the relevant patents for a particular product or = standard.  But our patents and our licensing commitment are not the = cause of this problem.  Even if our patents did not exist at all, = the problem would still be there.   That is why I agree with some = of the commenters who pointed out that it is very difficult to avoid = intellectual property concerns entirely because they cannot all be = known.

Trolls are everywhere and = can't be identified ahead of time. Do you feel that the GPL and the set = of companies surrounding the Linux kernel somewhat protects it from = troll attacks? Would implementing the reference version of RPL inside = the Linux kernel provide added protection to RPL users?

As we = reasonably sure that there aren't problem patents held by direct = competitors who aren't participating in ROLL and might be interested in = disrupting ROLL?

 
Best regards,
Dan
=



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

_______________________________________________=
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=



--
Jon Smirl
jonsmirl@gmail.com

= = --Apple-Mail-418-206787372-- From jonsmirl@gmail.com Mon Feb 15 16:39:21 2010 Return-Path: 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 E0CF43A7AF0 for ; Mon, 15 Feb 2010 16:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FCN6Iam+45Ym for ; Mon, 15 Feb 2010 16:39:20 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 43B2B3A7A3C for ; Mon, 15 Feb 2010 16:39:20 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so190314qwb.31 for ; Mon, 15 Feb 2010 16:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gnNjkaQYMg8Y6oZzD2CCFTSo/fznmdYI7HbKUclL4Bc=; b=MGd8K6Sp5oOTkmHY3F3oFQ04zPpYWm4O/K74YRP+t07EqunjmbuEq6ULfub3tqiemk lKMnWjZodHHqfv+XasYvy1PuQbUSg79SFXbQNDkGgGXmvhk93vh1lAKCOayDTunTeL42 ST6ontw1liPOclp0dZ1drzp6RP9g5myEBLXrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Fzf/HICss0eVCGIgRU5XJnnRwnETj4Jf+SNxX6WsGCRX+AnlenDfZ1VV0Ps2wqiHd6 caZQL1V0BAniB62yAov1EbWtNiF3hM+sEPp7yw9q/+NYycLlKe+cdx5D5rtIP3QmL9in nb99fvHmmZQQgIFQHZVK2q4e92DObdkT5yUUE= MIME-Version: 1.0 Received: by 10.229.214.10 with SMTP id gy10mr1626298qcb.18.1266280849830; Mon, 15 Feb 2010 16:40:49 -0800 (PST) In-Reply-To: <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> Date: Mon, 15 Feb 2010 19:40:49 -0500 Message-ID: <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> From: Jon Smirl To: Dan Lang Content-Type: multipart/alternative; boundary=0016363102993d7569047facfc68 Cc: roll@ietf.org, Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:39:22 -0000 --0016363102993d7569047facfc68 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang wrote: > Hi Jon: > > I am not your lawyer, so I unfortunately won=92t be able to answer your > question (=93From a legal sense, is your statement compatible with the GP= L?=94) > in way that satisfies you. However, I don=92t think that having RPL insi= de > the Linux kernel under a GPL license would somehow =93protect=94 RPL and = its > implementers from patent "troll" attacks. The entities you are worried > about don=92t typically have any products, and the GPL provides condition= s on > those who distribute or modify covered works, so they would not likely be > bound by any of those conditions. If anything, they would have a larger > pool of companies against which to assert their patents. > My only goal is to try and keep the RPL spec in a form where GPL licensed implementations are possible. I don't want to repeat the mess that Siemens walked into when they tried to contribute Zigbee code to the kernel and discovered that the Zigbee licenses weren't GPL incompatible. > > Your last question highlights the risk of standard-setting generally; > competitors or any third parties who aren=92t participating in ROLL don= =92t > necessarily have an obligation to disclose any of their patents to the IE= TF > and may choose to wait until after the standard is finalized to demand fe= es > (and not necessarily on reasonable and non-discriminatory terms) for > RPL-compliant products. This unfortunate fact will be true no matter wha= t > the RPL specification looks like. > > Best regards, > > Dan > > > On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: > > > > On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang wrote: > >> Hi Ruben, >> A couple of points that I'd like to clarify in response to your email. >> Again, I recommend that you check with your company's attorneys but at >> least let me suggest some things to ask them about. >> >> 1. No one is being asked to "renounce their IPR." But, per our >> statement, an entity that wants to make money on or otherwise exploit th= eir >> patents against Cisco products might have to pay something for a license= to >> Cisco's patents. That seems fair to me, but more importantly, it seems = fair >> to a lot of people who find sufficient assurance with our commitment to = make >> numerous IETF standards successful. >> > > From a legal sense, is your statement compatible with the GPL? I just wan= t > to ensure that we can build a GPL'd version of RPL. I don't want to repea= t > the problems with Zigbee where their licensing is incompatible with the G= PL. > >> >> 2. We would never claim that our intellectual property provides an >> "umbrella" for the industry. Having the right to use one company's pat= ents >> does not give you the right to use other patents if they are relevant. >> Potential exposure to unknown third party patents is always a concern in= the >> information technology industry. Due to the large number of patents and= the >> challenges of searching for them and evaluating them, it would be almost >> impossible to reliably identify all of the relevant patents for a partic= ular >> product or standard. But our patents and our licensing commitment are n= ot >> the cause of this problem. Even if our patents did not exist at all, th= e >> problem would still be there. That is why I agree with some of the >> commenters who pointed out that it is very difficult to avoid intellectu= al >> property concerns entirely because they cannot all be known. >> > > Trolls are everywhere and can't be identified ahead of time. Do you feel > that the GPL and the set of companies surrounding the Linux kernel somewh= at > protects it from troll attacks? Would implementing the reference version = of > RPL inside the Linux kernel provide added protection to RPL users? > > As we reasonably sure that there aren't problem patents held by direct > competitors who aren't participating in ROLL and might be interested in > disrupting ROLL? > > > >> Best regards, >> Dan >> >> >> >> Dan Lang >> Director, Intellectual Property >> Legal Services >> Cisco Systems, Inc. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > > -- > Jon Smirl > jonsmirl@gmail.com > > > --=20 Jon Smirl jonsmirl@gmail.com --0016363102993d7569047facfc68 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 15, 2010 at 6:33 PM, Dan Lan= g <dlang@cisco.com<= /a>> wrote:
Hi Jon:
=A0
I am not your lawyer, so I unfortunately won=92t be able to answer y= our question (=93From a legal sense, is your statement compatible with the = GPL?=94) in way that satisfies you.=A0 However, I don=92t think that having= RPL inside the Linux kernel under a GPL license would somehow =93protect= =94 RPL and its implementers from patent "troll" attacks.=A0 The = entities you are worried about don=92t typically have any products, and the= GPL provides conditions on those who distribute or modify covered works, s= o they would not likely be bound by any of those conditions.=A0 =A0If anyth= ing, they would have a larger pool of companies against =A0which to assert = their patents.
=A0
My only goal is to try and keep the RP= L spec in a form where GPL licensed implementations are possible. I don'= ;t want to repeat the mess that Siemens walked into when they tried to cont= ribute Zigbee code to the kernel and discovered that the Zigbee licenses we= ren't GPL incompatible.
=A0
=A0
=A0
Best regards,
=A0
Dan
=A0

On F= eb 15, 2010, at 5:33 AM, Jon Smirl wrote:



On Mon, Fe= b 15, 2010 at 12:41 AM, Dan Lang <dlang@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi= Ruben,
A couple of points that I'd like to clarify in response to your email.= =A0Again, I recommend that you check with your company's attorneys but= at least let me suggest some things to ask them about.
=A0
1. =A0No one is being ask= ed to "renounce their IPR." =A0 =A0 But, per our statement, an en= tity that wants to make money on or otherwise exploit their patents against= Cisco products might have to pay something for a license to Cisco's pa= tents. =A0That seems fair to me, but more importantly, it seems fair to a l= ot of people who find sufficient assurance with our commitment to make nume= rous IETF standards successful.

From a legal sense, is your statement co= mpatible with the GPL? I just want to ensure that we can build a GPL'd = version of RPL. I don't want to repeat the problems with Zigbee where t= heir licensing is incompatible with the GPL.
=A0
2. =A0We would never clai= m that our intellectual property provides an "umbrella" for the i= ndustry. =A0 Having the right to use one company's patents does not giv= e you the right to use other patents if they are relevant. =A0 Potential ex= posure to unknown third party patents is always a concern in the informatio= n technology industry. =A0Due to the large number of patents and the challe= nges of searching for them and evaluating them, it would be almost impossib= le to reliably identify all of the relevant patents for a particular produc= t or standard. =A0But our patents and our licensing commitment are not the = cause of this problem. =A0Even if our patents did not exist at all, the pro= blem would still be there. =A0 That is why I agree with some of the comment= ers who pointed out that it is very difficult to avoid intellectual propert= y concerns entirely because they cannot all be known.

Trolls are everywhere and can't be i= dentified ahead of time. Do you feel that the GPL and the set of companies = surrounding the Linux kernel somewhat protects it from troll attacks? Would= implementing the reference version of RPL inside the Linux kernel provide = added protection to RPL users?

As we reasonably sure that there aren't problem patents held by di= rect competitors who aren't participating in ROLL and might be interest= ed in disrupting ROLL?

=A0
Be= st regards,
Dan



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

_______________________________________________<= br> Roll mailing list
R= oll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

<= /blockquote>



--
Jon Smirl
jonsmirl@gmail.com




-- Jon Smirl
jonsmirl@gmail.com
--0016363102993d7569047facfc68-- From pal@cs.stanford.edu Mon Feb 15 16:50:53 2010 Return-Path: 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 DC93E3A7BF3 for ; Mon, 15 Feb 2010 16:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 a2Hgi5UXQbzA for ; Mon, 15 Feb 2010 16:50:52 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D13B03A7BF0 for ; Mon, 15 Feb 2010 16:50:52 -0800 (PST) Received: from dn0a2019a6.sunet ([10.32.25.166]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NhBft-0001i2-5n; Mon, 15 Feb 2010 16:52:25 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-211535775 From: Philip Levis In-Reply-To: <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> Date: Mon, 15 Feb 2010 16:52:24 -0800 Message-Id: <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> To: Jon Smirl X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Cc: roll@ietf.org, Dan Lang , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:50:54 -0000 --Apple-Mail-1-211535775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 15, 2010, at 4:40 PM, Jon Smirl wrote: >=20 >=20 > On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang wrote: > Hi Jon: > =20 > I am not your lawyer, so I unfortunately won=92t be able to answer = your question (=93=46rom a legal sense, is your statement compatible = with the GPL?=94) in way that satisfies you. However, I don=92t think = that having RPL inside the Linux kernel under a GPL license would = somehow =93protect=94 RPL and its implementers from patent "troll" = attacks. The entities you are worried about don=92t typically have any = products, and the GPL provides conditions on those who distribute or = modify covered works, so they would not likely be bound by any of those = conditions. If anything, they would have a larger pool of companies = against which to assert their patents.=20 > =20 > My only goal is to try and keep the RPL spec in a form where GPL = licensed implementations are possible. I don't want to repeat the mess = that Siemens walked into when they tried to contribute Zigbee code to = the kernel and discovered that the Zigbee licenses weren't GPL = incompatible. Jon, This makes sense, but is in some ways independent of Cisco's IPR. No-one = has yet reported a serious examination of whether Cisco's IPR overlaps = with the current draft. Phil= --Apple-Mail-1-211535775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang <dlang@cisco.com> = wrote:
Hi Jon:
 
I am not your = lawyer, so I unfortunately won=92t be able to answer your question = (=93=46rom a legal sense, is your statement compatible with the GPL?=94) = in way that satisfies you.  However, I don=92t think that having = RPL inside the Linux kernel under a GPL license would somehow =93protect=94= RPL and its implementers from patent "troll" attacks.  The = entities you are worried about don=92t typically have any products, and = the GPL provides conditions on those who distribute or modify covered = works, so they would not likely be bound by any of those = conditions.   If anything, they would have a larger pool of = companies against  which to assert their patents.
 
My only goal is to try and keep = the RPL spec in a form where GPL licensed implementations are possible. = I don't want to repeat the mess that Siemens walked into when they tried = to contribute Zigbee code to the kernel and discovered that the Zigbee = licenses weren't GPL = incompatible.


J= on,

This makes sense, but is in some ways = independent of Cisco's IPR. No-one has yet reported a serious = examination of whether Cisco's IPR overlaps with the current = draft.

Phil
= --Apple-Mail-1-211535775-- From geoff@proto6.com Mon Feb 15 17:48:54 2010 Return-Path: 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 14F0E3A7C05 for ; Mon, 15 Feb 2010 17:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 zyZapW1UVUhw for ; Mon, 15 Feb 2010 17:48:53 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 41BF23A7C04 for ; Mon, 15 Feb 2010 17:48:53 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 45B421848C; Mon, 15 Feb 2010 18:50:36 -0700 (MST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o1G1oOhP023565; Mon, 15 Feb 2010 18:50:24 -0700 (MST) From: Geoff Mulligan To: Philip Levis In-Reply-To: <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 15 Feb 2010 18:50:19 -0700 Message-Id: <1266285019.3643.325.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Dan Lang , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 01:48:54 -0000 Phil, Who is going to do this? Can we not sort of assume that Cisco believes that their IPR overlaps with the current draft. If it didn't then why are we continuing to discuss this. The point would be moot and we could get back to the fun stuff such as question of RPL design and applicability to the various use cases such as SE2.0, building control and home control. geoff On Mon, 2010-02-15 at 16:52 -0800, Philip Levis wrote: > > On Feb 15, 2010, at 4:40 PM, Jon Smirl wrote: > > > > > > > On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang wrote: > > Hi Jon: > > > > I am not your lawyer, so I unfortunately won’t be able to > > answer your question (“From a legal sense, is your statement > > compatible with the GPL?â€) in way that satisfies you. > > However, I don’t think that having RPL inside the Linux > > kernel under a GPL license would somehow “protect†RPL and > > its implementers from patent "troll" attacks. The entities > > you are worried about don’t typically have any products, and > > the GPL provides conditions on those who distribute or > > modify covered works, so they would not likely be bound by > > any of those conditions. If anything, they would have a > > larger pool of companies against which to assert their > > patents. > > > > > > My only goal is to try and keep the RPL spec in a form where GPL > > licensed implementations are possible. I don't want to repeat the > > mess that Siemens walked into when they tried to contribute Zigbee > > code to the kernel and discovered that the Zigbee licenses weren't > > GPL incompatible. > > > > > Jon, > > > This makes sense, but is in some ways independent of Cisco's IPR. > No-one has yet reported a serious examination of whether Cisco's IPR > overlaps with the current draft. > > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Mon Feb 15 18:16:28 2010 Return-Path: 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 B220C3A7C0A for ; Mon, 15 Feb 2010 18:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 cSRysyJwfc32 for ; Mon, 15 Feb 2010 18:16:26 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E7D1328C154 for ; Mon, 15 Feb 2010 18:16:26 -0800 (PST) Received: (qmail 37682 invoked from network); 16 Feb 2010 02:17:58 -0000 Received: from adsl-69-224-127-54.dsl.sndg02.pacbell.net (d.sturek@69.224.127.54 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 15 Feb 2010 18:17:58 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: szq6fiYVM1mu5ErEkWHaKWyq.vBetQbVlcX8FknW5IVzylFprRxXwoIc9Zv_MOQgM_T8LoUG48YyPPGGlxz1oS5TfP4mqEh_qAZP3yALko.dkff_KoreajROcO3MCuMePktxwUNqE89VIVvB91tkVmzL3Amzm.__imd6AD4_shj6LsvrMAoNOw6vFLkFCTnSNqImxEcxG55E2cd9UKB09pLf6tltAuJCErrm1r6rHJiL8rCPxwBFZOn_pYhU4irTw5udUgo5kABG9L9JJMIGqD35ANwbX9xkjiRaGhtXuZ.w2n67S_8- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Geoff Mulligan'" , "'Philip Levis'" References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> <1266285019.3643.325.camel@dellx1> In-Reply-To: <1266285019.3643.325.camel@dellx1> Date: Mon, 15 Feb 2010 18:17:55 -0800 Message-ID: <01f501caaeae$403a5e30$c0af1a90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acquqms4hk69oxCHRpK34HNCTAuLhAAA532w Content-Language: en-us Cc: roll@ietf.org, 'Dan Lang' , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 02:16:29 -0000 I guess I have a different view..... Given ROLL RPL has had a lot of design work put into it, I would like to = see some resolution that works on the business side. "Getting back to the fun stuff" sounds like a serious schedule delay to = me (which would not be good). Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Geoff Mulligan Sent: Monday, February 15, 2010 5:50 PM To: Philip Levis Cc: roll@ietf.org; Dan Lang; Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR Phil, Who is going to do this? Can we not sort of assume that Cisco believes that their IPR overlaps with the current draft. If it didn't then why are we continuing to discuss this. The point would be moot and we could get back to the fun stuff such as question of RPL design and applicability to the various use cases such as SE2.0, building control and home control. geoff On Mon, 2010-02-15 at 16:52 -0800, Philip Levis wrote: >=20 > On Feb 15, 2010, at 4:40 PM, Jon Smirl wrote: >=20 > >=20 > >=20 > > On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang wrote: > > Hi Jon: > > =20 > > I am not your lawyer, so I unfortunately won=E2=80=99t be = able to > > answer your question (=E2=80=9CFrom a legal sense, is your = statement > > compatible with the GPL?=E2=80=9D) in way that satisfies = you. > > However, I don=E2=80=99t think that having RPL inside the = Linux > > kernel under a GPL license would somehow = =E2=80=9Cprotect=E2=80=9D RPL and > > its implementers from patent "troll" attacks. The entities > > you are worried about don=E2=80=99t typically have any = products, and > > the GPL provides conditions on those who distribute or > > modify covered works, so they would not likely be bound by > > any of those conditions. If anything, they would have a > > larger pool of companies against which to assert their > > patents.=20 > > =20 > > =20 > > My only goal is to try and keep the RPL spec in a form where GPL > > licensed implementations are possible. I don't want to repeat the > > mess that Siemens walked into when they tried to contribute Zigbee > > code to the kernel and discovered that the Zigbee licenses weren't > > GPL incompatible. >=20 >=20 >=20 >=20 > Jon, >=20 >=20 > This makes sense, but is in some ways independent of Cisco's IPR. > No-one has yet reported a serious examination of whether Cisco's IPR > overlaps with the current draft. >=20 >=20 > Phil > _______________________________________________ > 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 From roger.alexander@ekasystems.com Mon Feb 15 20:46:55 2010 Return-Path: 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 DB5BF28C129 for ; Mon, 15 Feb 2010 20:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cHeWsLXm7p67 for ; Mon, 15 Feb 2010 20:46:55 -0800 (PST) Received: from web1212.biz.mail.gq1.yahoo.com (web1212.biz.mail.gq1.yahoo.com [67.195.14.59]) by core3.amsl.com (Postfix) with SMTP id DF51728C0D0 for ; Mon, 15 Feb 2010 20:46:54 -0800 (PST) Received: (qmail 65238 invoked by uid 60001); 16 Feb 2010 04:48:25 -0000 Message-ID: <421832.63584.qm@web1212.biz.mail.gq1.yahoo.com> X-YMail-OSG: HHMtrJ0VM1mwdSW5._ciZqiuZTjsUOgKUdvc4xJFSvMeP4BoCJIvgsOEFFjtYJQBah0qYlv0WvFFknWt69HeV0VoIwrkrXuqEWfa9Bb_DJmlS4UKTZ7wUnIzoc.aGicpdzCDRLM79tpfhm_gipB7l_rDmjpt0u6q6oTWOd_IZlVOhlDmE3qE6_5gjvk0SaYJCF7FyfMZI1U1zziYXn2l9UTJF84L3fglPcrlhCytE9Uo5IqyKQO_SBRyMwtV_pHHokr8y4iQXShnaKwtltx8QBH4YeaORDQnBJJ0p3iEW7oG.UXwUK0Q8bVwLk0G.30GzC4XD3Zi.kxVmN4cLpn.GlkzT_OD7.gf5TqYskBDImAxsyiITg-- Received: from [69.143.218.61] by web1212.biz.mail.gq1.yahoo.com via HTTP; Mon, 15 Feb 2010 20:48:25 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> <1266285019.3643.325.camel@dellx1> <01f501caaeae$403a5e30$c0af1a90$@sturek@att.net> Date: Mon, 15 Feb 2010 20:48:25 -0800 (PST) From: Roger Alexander To: d.sturek@att.net, Geoff Mulligan , Philip Levis In-Reply-To: <01f501caaeae$403a5e30$c0af1a90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, Dan Lang , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 04:46:56 -0000 The current focus on Cisco's IPR appears to stem from the=0Aactive involvem= ent of Cisco personnel in the design and development of RPL=0Atogether with= their open IPR declarations. The assumption is that=0Awhile any protocol d= esign is vulnerable to the potential of unknown IPR,=0ACisco's IPR is less = potential and more of an explicit, known concern (even=0Athough the IPR is = being made openly available). If Cisco's declared IPR is removed as=0Aa pot= ential concern, then all companies achieve the 'comfort' of being equally= =0Avulnerable to the vagaries of other unknown IPR. =0A=0A=0AOne possible c= ompromise=0Atherefore would be for Cisco to make its RPL-related IPR availa= ble to any and=0Aall RPL implementations while still retaining the right to= re-assert its IPR=0Aclaims but solely in the context of RPL-related suits = brought against them by others. This=0Adoes not seem to be very far away fr= om what Cisco=E2=80=99s legal representative, Dan, has=0Aindicated. However= , it is narrower in scope in that it would imply Cisco giving=0Aup the opti= on to reassert its potential RPL IPR claims in response to suits=0Athat are= not explicitly related to RPL (clearly a question to be addressed by=0Aleg= al rather than technical representatives). =0A=0A=0ANonetheless, such a com= promise could allow companies to feel that they=0Aare on an equal footing w= ith regard to potential vulnerability from unknown and=0Aundeclared IPR, as= well as on an equal footing with regard to the removal of=0Apotential vuln= erability from known Cisco IPR. Of course this may not be sufficient=0Afor = some who may still perceive a Cisco advantage from the potential to trade= =0Aits IPR in the case of RPL-related suits. However, such an advantage acc= rues to=0Aany company that has developed IPR in the space. =0A =0AHopefully= there is a compromise that can allow the focus=0Ato return to the RPL desi= gn and development.=0A=0ARoger=0A=0A=0A----- Original Message ----=0AFrom: = Don Sturek =0ATo: Geoff Mulligan ; Phil= ip Levis =0ACc: roll@ietf.org; Dan Lang ; Ruben.Salazar@landisgyr.com=0ASent: Mon, February 15, 2010 9:17:55 PM= =0ASubject: Re: [Roll] Closing on the IPR=0A=0AI guess I have a different v= iew.....=0A=0AGiven ROLL RPL has had a lot of design work put into it, I wo= uld like to see some resolution that works on the business side.=0A=0A"Gett= ing back to the fun stuff" sounds like a serious schedule delay to me (whic= h would not be good).=0A=0ADon=0A=0A=0A-----Original Message-----=0AFrom: r= oll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Geoff Mull= igan=0ASent: Monday, February 15, 2010 5:50 PM=0ATo: Philip Levis=0ACc: rol= l@ietf.org; Dan Lang; Ruben.Salazar@landisgyr.com=0ASubject: Re: [Roll] Clo= sing on the IPR=0A=0APhil,=0A Who is going to do this? Can we not sort of= assume that Cisco=0Abelieves that their IPR overlaps with the current draf= t. If it didn't=0Athen why are we continuing to discuss this. The point w= ould be moot and=0Awe could get back to the fun stuff such as question of R= PL design and=0Aapplicability to the various use cases such as SE2.0, build= ing control=0Aand home control.=0A=0A geoff=0A=0AOn Mon, 2010-02-15 at 1= 6:52 -0800, Philip Levis wrote:=0A> =0A> On Feb 15, 2010, at 4:40 PM, Jon S= mirl wrote:=0A> =0A> > =0A> > =0A> > On Mon, Feb 15, 2010 at 6:33 PM, Dan L= ang wrote:=0A> > Hi Jon:=0A> > =0A> > = I am not your lawyer, so I unfortunately won=E2=80=99t be able to=0A>= > answer your question (=E2=80=9CFrom a legal sense, is your state= ment=0A> > compatible with the GPL?=E2=80=9D) in way that satisfies= you.=0A> > However, I don=E2=80=99t think that having RPL inside t= he Linux=0A> > kernel under a GPL license would somehow =E2=80=9Cpr= otect=E2=80=9D RPL and=0A> > its implementers from patent "troll" a= ttacks. The entities=0A> > you are worried about don=E2=80=99t typ= ically have any products, and=0A> > the GPL provides conditions on = those who distribute or=0A> > modify covered works, so they would n= ot likely be bound by=0A> > any of those conditions. If anything,= they would have a=0A> > larger pool of companies against which to= assert their=0A> > patents. =0A> > =0A> > =0A> > My only g= oal is to try and keep the RPL spec in a form where GPL=0A> > licensed impl= ementations are possible. I don't want to repeat the=0A> > mess that Siemen= s walked into when they tried to contribute Zigbee=0A> > code to the kernel= and discovered that the Zigbee licenses weren't=0A> > GPL incompatible.=0A= > =0A> =0A> =0A> =0A> Jon,=0A> =0A> =0A> This makes sense, but is in some w= ays independent of Cisco's IPR.=0A> No-one has yet reported a serious exami= nation of whether Cisco's IPR=0A> overlaps with the current draft.=0A> =0A>= =0A> Phil=0A> _______________________________________________=0A> Roll mai= ling list=0A> Roll@ietf.org=0A> https://www.ietf.org/mailman/listinfo/roll= =0A=0A_______________________________________________=0ARoll mailing list= =0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A=0A________= _______________________________________=0ARoll mailing list=0ARoll@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/roll=0A From p.bertrand@watteco.com Tue Feb 16 03:25:32 2010 Return-Path: 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 33D363A7CD6 for ; Tue, 16 Feb 2010 03:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 5hq8Fd4sdg8F for ; Tue, 16 Feb 2010 03:25:31 -0800 (PST) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 246963A7CC9 for ; Tue, 16 Feb 2010 03:25:30 -0800 (PST) Received: from [192.168.4.121] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id YNR45302 for ; Tue, 16 Feb 2010 12:27:02 +0100 From: Paul Bertrand Content-Type: multipart/alternative; boundary=Apple-Mail-122-249613556 Date: Tue, 16 Feb 2010 12:27:02 +0100 Message-Id: To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 11:25:32 -0000 --Apple-Mail-122-249613556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi JP, Adrian, Watteco is in favor of moving with the current RPL draft under the = proposed licensing terms. Watteco is a SOC company dedicated to low Power Powerline communication = technology and when it came to choose our MAC we turned to select an = open 802.15.4 that we adapted to Powerline media specificities. For us = RPL is a real opportunity to get an advanced routing mechanism on top of = our MAC and to start real business as soon as possible. I don't have any concerns with IPR within ROLL's group as I think Cisco = had been fair enough to offer a clear statement on their existing = patent and license politic.=20 Let us proceed on real work and finish the job. Paul Bertrand,=20 Founder, VP Technology & strategy Watteco SAS 1766 Chemin de la Planquette 83130 La Garde, France T=E9l : +33 4 98 01 60 05 Mobile: +33 6 22 45 35 59 Fax : +33 4 94 14 10 80 --Apple-Mail-122-249613556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = JP, Adrian,

Watteco is  in favor of moving with = the current RPL draft under the proposed licensing = terms.

Watteco is a SOC company dedicated to = low Power Powerline communication technology and when it came to choose = our MAC we turned to select an open 802.15.4 that we adapted to = Powerline media specificities. For us RPL is a real opportunity to get = an advanced routing mechanism on top of our MAC and to start real = business as soon as possible.
I don't have any concerns with = IPR within ROLL's group  as I think Cisco had been fair enough to = offer  a clear statement on their existing patent and license = politic. 

Let us  proceed on = real work and finish the job.

Paul = Bertrand, 
Founder, VP  Technology & = strategy
Watteco SAS
1766 Chemin de la Planquette 83130 La Garde, = France

T=E9l : +33 4 98 01 60 05
Mobile: +33 6 22 45 35 = 59
Fax : +33 4 94 14 10 = 80




= --Apple-Mail-122-249613556-- From robert.cragie@gridmerge.com Tue Feb 16 03:51:43 2010 Return-Path: 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 152FF3A7255 for ; Tue, 16 Feb 2010 03:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 ZMCgU9EzRPJn for ; Tue, 16 Feb 2010 03:51:41 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 5F8083A7681 for ; Tue, 16 Feb 2010 03:51:40 -0800 (PST) Received: from client-82-26-214-85.pete.adsl.virginmedia.com ([82.26.214.85] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NhLz8-0002WN-9o; Tue, 16 Feb 2010 11:53:08 +0000 Message-ID: <4B7A8712.8050606@gridmerge.com> Date: Tue, 16 Feb 2010 11:52:50 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roger Alexander References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> <1266285019.3643.325.camel@dellx1> <01f501caaeae$403a5e30$c0af1a90$@sturek@att.net> <421832.63584.qm@web1212.biz.mail.gq1.yahoo.com> In-Reply-To: <421832.63584.qm@web1212.biz.mail.gq1.yahoo.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060903000802080409090802" Cc: roll@ietf.org, Dan Lang , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 11:51:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060903000802080409090802 Content-Type: multipart/alternative; boundary="------------030801070808020404030005" This is a multi-part message in MIME format. --------------030801070808020404030005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Comments inline. Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Roger Alexander wrote: > The current focus on Cisco's IPR appears to stem from the > active involvement of Cisco personnel in the design and development of = RPL > together with their open IPR declarations. The assumption is that > while any protocol design is vulnerable to the potential of unknown IPR= , > Cisco's IPR is less potential and more of an explicit, known concern (e= ven > though the IPR is being made openly available). If Cisco's declared IPR= is removed as > a potential concern, then all companies achieve the 'comfort' of being = equally > vulnerable to the vagaries of other unknown IPR.=20 > =20 I fail to see how IPR can truly be unknown. Whilst it can be a very = laborious process, a patent search will reveal other IPR. As far as I=20 know (and I am not a lawyer) any other intellectual property which does=20 not have a patent on it or patent pending cannot be considered as there=20 is no formal declaration of the intellectual property or claims for it.=20 Maybe a thorough patent search should be done, although I am not sure=20 who would be prepared to undertake it. Maybe Cisco have already done due = diligence due to assertion of their own IPR and can provide their=20 assurance that there is no other potential IPR, although I appreciate=20 they have no obligation to reveal this information. > One possible compromise > therefore would be for Cisco to make its RPL-related IPR available to a= ny and > all RPL implementations while still retaining the right to re-assert it= s IPR > claims but solely in the context of RPL-related suits brought against t= hem by others. This > does not seem to be very far away from what Cisco=E2=80=99s legal repre= sentative, Dan, has > indicated. However, it is narrower in scope in that it would imply Cisc= o giving > up the option to reassert its potential RPL IPR claims in response to s= uits > that are not explicitly related to RPL (clearly a question to be addres= sed by > legal rather than technical representatives). I agree that this would likely be a more acceptable proposal. I am=20 not happy proceeding with RPL with the current statement on IPR and it=20 would seem many others are not too. > =20 > > > Nonetheless, such a compromise could allow companies to feel that they > are on an equal footing with regard to potential vulnerability from unk= nown and > undeclared IPR, as well as on an equal footing with regard to the remov= al of > potential vulnerability from known Cisco IPR. Of course this may not be= sufficient > for some who may still perceive a Cisco advantage from the potential to= trade > its IPR in the case of RPL-related suits. However, such an advantage ac= crues to > any company that has developed IPR in the space.=20 > =20 > Hopefully there is a compromise that can allow the focus > to return to the RPL design and development. > > Roger > > > ----- Original Message ---- > From: Don Sturek > To: Geoff Mulligan ; Philip Levis > Cc: roll@ietf.org; Dan Lang ; Ruben.Salazar@landisgyr.= com > Sent: Mon, February 15, 2010 9:17:55 PM > Subject: Re: [Roll] Closing on the IPR > > I guess I have a different view..... > > Given ROLL RPL has had a lot of design work put into it, I would like t= o see some resolution that works on the business side. > > "Getting back to the fun stuff" sounds like a serious schedule delay to= me (which would not be good). > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of= Geoff Mulligan > Sent: Monday, February 15, 2010 5:50 PM > To: Philip Levis > Cc: roll@ietf.org; Dan Lang; Ruben.Salazar@landisgyr.com > Subject: Re: [Roll] Closing on the IPR > > Phil, > Who is going to do this? Can we not sort of assume that Cisco > believes that their IPR overlaps with the current draft. If it didn't > then why are we continuing to discuss this. The point would be moot an= d > we could get back to the fun stuff such as question of RPL design and > applicability to the various use cases such as SE2.0, building control > and home control. > > geoff > > On Mon, 2010-02-15 at 16:52 -0800, Philip Levis wrote: > =20 >> On Feb 15, 2010, at 4:40 PM, Jon Smirl wrote: >> >> =20 >>> On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang wrote: >>> Hi Jon: >>> =20 >>> I am not your lawyer, so I unfortunately won=E2=80=99t be abl= e to >>> answer your question (=E2=80=9CFrom a legal sense, is your st= atement >>> compatible with the GPL?=E2=80=9D) in way that satisfies you.= >>> However, I don=E2=80=99t think that having RPL inside the Lin= ux >>> kernel under a GPL license would somehow =E2=80=9Cprotect=E2=80= =9D RPL and >>> its implementers from patent "troll" attacks. The entities >>> you are worried about don=E2=80=99t typically have any produc= ts, and >>> the GPL provides conditions on those who distribute or >>> modify covered works, so they would not likely be bound by >>> any of those conditions. If anything, they would have a >>> larger pool of companies against which to assert their >>> patents.=20 >>> =20 >>> =20 >>> My only goal is to try and keep the RPL spec in a form where GPL >>> licensed implementations are possible. I don't want to repeat the >>> mess that Siemens walked into when they tried to contribute Zigbee >>> code to the kernel and discovered that the Zigbee licenses weren't >>> GPL incompatible. >>> =20 >> >> Jon, >> >> >> This makes sense, but is in some ways independent of Cisco's IPR. >> No-one has yet reported a serious examination of whether Cisco's IPR >> overlaps with the current draft. >> >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> =20 > > _______________________________________________ > 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 > =20 --------------030801070808020404030005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments inline.

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Roger Alexander wrote: 
The current focus on Cisco's IPR appears to stem from th=
e
active involvement of Cisco personnel in the design and development of RP=
L
together with their open IPR declarations. The assumption is that
while any protocol design is vulnerable to the potential of unknown IPR,
Cisco's IPR is less potential and more of an explicit, known concern (eve=
n
though the IPR is being made openly available). If Cisco's declared IPR i=
s removed as
a potential concern, then all companies achieve the 'comfort' of being eq=
ually
vulnerable to the vagaries of other unknown IPR.=20
<RCC>I fail to see how IPR can truly be unknown. Whilst it can be a very laborious process, a patent search will reveal other IPR. As far as I know (and I am not a lawyer) any other intellectual property which does not have a patent on it or patent pending cannot be considered as there is no formal declaration of the intellectual property or claims for it. Maybe a thorough patent search should be done, although I am not sure who would be prepared to undertake it. Maybe Cisco have already done due diligence due to assertion of their own IPR and can provide their assurance that there is no other potential IPR, although I appreciate they have no obligation to reveal this information.</RCC>
One possible compromise
therefore would be for Cisco to make its RPL-related IPR available to any=
 and
all RPL implementations while still retaining the right to re-assert its =
IPR
claims but solely in the context of RPL-related suits brought against the=
m by others. This
does not seem to be very far away from what Cisco=E2=80=99s legal represe=
ntative, Dan, has
indicated. However, it is narrower in scope in that it would imply Cisco =
giving
up the option to reassert its potential RPL IPR claims in response to sui=
ts
that are not explicitly related to RPL (clearly a question to be addresse=
d by
legal rather than technical representatives).
<RCC>I agree that this would likely be a more acceptable proposal. I am not happy proceeding with RPL with the current statement on IPR and it would seem many others are not too.</RCC>
=20


Nonetheless, such a compromise could allow companies to feel that they
are on an equal footing with regard to potential vulnerability from unkno=
wn and
undeclared IPR, as well as on an equal footing with regard to the removal=
 of
potential vulnerability from known Cisco IPR. Of course this may not be s=
ufficient
for some who may still perceive a Cisco advantage from the potential to t=
rade
its IPR in the case of RPL-related suits. However, such an advantage accr=
ues to
any company that has developed IPR in the space.=20
=20
Hopefully there is a compromise that can allow the focus
to return to the RPL design and development.

Roger


----- Original Message ----
From: Don Sturek <d.sturek@att.net>
To: Geoff Mulligan <geoff@proto6.com>; Philip Le=
vis <=
pal@cs.stanford.edu>
Cc: r=
oll@ietf.org; Dan Lang <dlan=
g@cisco.com>; Ruben.Salazar@landisgyr.com<=
/a>
Sent: Mon, February 15, 2010 9:17:55 PM
Subject: Re: [Roll] Closing on the IPR

I guess I have a different view.....

Given ROLL RPL has had a lot of design work put into it, I would like to =
see some resolution that works on the business side.

"Getting back to the fun stuff" sounds like a serious schedule delay to m=
e (which would not be good).

Don


-----Original Message-----
From: roll-bounces@ietf.org [ma=
ilto:roll-bounces@ietf.org] On Behalf Of Geoff Mulligan
Sent: Monday, February 15, 2010 5:50 PM
To: Philip Levis
Cc: r=
oll@ietf.org; Dan Lang; Ruben.Salazar@landisgyr.com<=
/a>
Subject: Re: [Roll] Closing on the IPR

Phil,
  Who is going to do this?  Can we not sort of assume that Cisco
believes that their IPR overlaps with the current draft.  If it didn't
then why are we continuing to discuss this.  The point would be moot and
we could get back to the fun stuff such as question of RPL design and
applicability to the various use cases such as SE2.0, building control
and home control.

    geoff

On Mon, 2010-02-15 at 16:52 -0800, Philip Levis wrote:
  
On Feb 15, 2010, at 4:40 PM, Jon Smirl wrote:

    
On Mon, Feb 15, 2010 at 6:33 PM, Dan Lang <dlan=
g@cisco.com> wrote:
        Hi Jon:
        =20
        I am not your lawyer, so I unfortunately won=E2=80=99t be able to=

        answer your question (=E2=80=9CFrom a legal sense, is your statem=
ent
        compatible with the GPL?=E2=80=9D) in way that satisfies you.
        However, I don=E2=80=99t think that having RPL inside the Linux
        kernel under a GPL license would somehow =E2=80=9Cprotect=E2=80=9D=
 RPL and
        its implementers from patent "troll" attacks.  The entities
        you are worried about don=E2=80=99t typically have any products, =
and
        the GPL provides conditions on those who distribute or
        modify covered works, so they would not likely be bound by
        any of those conditions.   If anything, they would have a
        larger pool of companies against  which to assert their
        patents.=20
      =20
=20
My only goal is to try and keep the RPL spec in a form where GPL
licensed implementations are possible. I don't want to repeat the
mess that Siemens walked into when they tried to contribute Zigbee
code to the kernel and discovered that the Zigbee licenses weren't
GPL incompatible.
      

Jon,


This makes sense, but is in some ways independent of Cisco's IPR.
No-one has yet reported a serious examination of whether Cisco's IPR
overlaps with the current draft.


Phil
_______________________________________________
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 mailing list
Roll@=
ietf.org
https://www.ietf.org=
/mailman/listinfo/roll
--------------030801070808020404030005-- --------------ms060903000802080409090802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MTYxMTUyNTBaMCMGCSqGSIb3DQEJBDEWBBSgSrbedeHt95j+QhjlDCKtWszlTzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAByMiXJWikhZhDxxqAejtbG2a9fVZvbIf7SUFi3bApWPrTZZ5zfN6kxWL/DY0tXAqX32 5WoPeZcVxjEhrAeJ3sts1mT1HJjdKucnJ6DM7yjozN3Thny9l4BDEqx4CWEGlgqZ64oJSyf0 B/s5g2fUmVgOjbJOybTYNoCG4jKX4UI/AabLJmOIbZkY7J41lXvHQHsytuA1OdNRtnrJ++Eo s9okwxEm4IwsW5oiLobnHZBLHFR7+CM0Fu0Nn8AvYbxRwbUEVlqEMRk9P2Xx3otQjUuam3Fk /VcMlS+CdqroVyTS8JngRiXqpXHAV2N88JdW/Au3PfboMLvPD7XtPfT+xnYAAAAAAAA= --------------ms060903000802080409090802-- From pal@cs.stanford.edu Tue Feb 16 07:41:36 2010 Return-Path: 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 A3F623A7D34 for ; Tue, 16 Feb 2010 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 PragjDAy-j+r for ; Tue, 16 Feb 2010 07:41:35 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 655473A7D30 for ; Tue, 16 Feb 2010 07:41:35 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NhPZs-0004zx-Gy; Tue, 16 Feb 2010 07:43:10 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-6-264978569 From: Philip Levis In-Reply-To: <4B7A8712.8050606@gridmerge.com> Date: Tue, 16 Feb 2010 07:43:07 -0800 Message-Id: <48B53EFC-4EB9-439D-8EA9-B60F464F5804@cs.stanford.edu> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <9e4733911002151640w17dd2642qc4f3716f54b3ffdc@mail.gmail.com> <6946F3E1-BAA6-472F-8CE9-9391E0A0B646@cs.stanford.edu> <1266285019.3643.325.camel@dellx1> <01f501caaeae$403a5e30$c0af1a90$@sturek@att.net> <421832.63584.qm@web1212.biz.mail.gq1.yahoo.com> <4B7A8712.8050606@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) X-Scan-Signature: f5e9e554c6b25ad025467fa91158a833 Cc: roll@ietf.org, Dan Lang , Ruben.Salazar@landisgyr.com Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 15:41:36 -0000 --Apple-Mail-6-264978569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 16, 2010, at 3:52 AM, Robert Cragie wrote: > Comments inline. > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com >=20 >=20 >=20 > Roger Alexander wrote: >>=20 >> The current focus on Cisco's IPR appears to stem from the >> active involvement of Cisco personnel in the design and development = of RPL >> together with their open IPR declarations. The assumption is that >> while any protocol design is vulnerable to the potential of unknown = IPR, >> Cisco's IPR is less potential and more of an explicit, known concern = (even >> though the IPR is being made openly available). If Cisco's declared = IPR is removed as >> a potential concern, then all companies achieve the 'comfort' of = being equally >> vulnerable to the vagaries of other unknown IPR.=20 >> =20 > I fail to see how IPR can truly be unknown. Whilst it can be a = very laborious process, a patent search will reveal other IPR. As far as = I know (and I am not a lawyer) any other intellectual property which = does not have a patent on it or patent pending cannot be considered as = there is no formal declaration of the intellectual property or claims = for it. Maybe a thorough patent search should be done, although I am not = sure who would be prepared to undertake it. Maybe Cisco have already = done due diligence due to assertion of their own IPR and can provide = their assurance that there is no other potential IPR, although I = appreciate they have no obligation to reveal this information. It's also useful to note that the IETF has guidelines for IPR disclosure = beyond the simple case we have here. The key part is 6.1.3 of RFC 3979: 6.1.2. An IETF Participant's IPR in Contributions by Others Any individual participating in an IETF discussion who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the individual believes Covers or may ultimately Cover a Contribution made by another person, or which such IETF participant reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. 6.1.3. IPR of Others If a person has information about IPR that may Cover IETF Contributions, but the participant is not required to disclose because they do not meet the criteria in Section 6.6 (e.g., the IPR is owned by some other company), such person is encouraged to notify the IETF by sending an email message to ietf-ipr@ietf.org. Such a notice should be sent as soon as reasonably possible after the person realizes the connection. Phil= --Apple-Mail-6-264978569 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Feb 16, 2010, at 3:52 AM, Robert Cragie wrote:

Comments inline.

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Roger Alexander wrote: 
The current focus on Cisco's IPR appears to stem from the
active involvement of Cisco personnel in the design and development of RPL
together with their open IPR declarations. The assumption is that
while any protocol design is vulnerable to the potential of unknown IPR,
Cisco's IPR is less potential and more of an explicit, known concern (even
though the IPR is being made openly available). If Cisco's declared IPR is removed as
a potential concern, then all companies achieve the 'comfort' of being equally
vulnerable to the vagaries of other unknown IPR.
<RCC>I fail to see how IPR can truly be unknown. Whilst it can be a very laborious process, a patent search will reveal other IPR. As far as I know (and I am not a lawyer) any other intellectual property which does not have a patent on it or patent pending cannot be considered as there is no formal declaration of the intellectual property or claims for it. Maybe a thorough patent search should be done, although I am not sure who would be prepared to undertake it. Maybe Cisco have already done due diligence due to assertion of their own IPR and can provide their assurance that there is no other potential IPR, although I appreciate they have no obligation to reveal this information.</RCC>

It's also useful to note that the IETF has guidelines for IPR disclosure beyond the simple case we have here. The key part is 6.1.3 of RFC 3979:

6.1.2.  An IETF Participant's IPR in Contributions by Others

   Any individual participating in an IETF discussion who reasonably and
   personally knows of IPR meeting the conditions of Section 6.6 which
   the individual believes Covers or may ultimately Cover a Contribution
   made by another person, or which such IETF participant reasonably and
   personally knows his or her employer or sponsor may assert against
   Implementing Technologies based on such Contribution, must make a
   disclosure in accordance with this Section 6.

6.1.3.  IPR of Others

   If a person has information about IPR that may Cover IETF
   Contributions, but the participant is not required to disclose
   because they do not meet the criteria in Section 6.6 (e.g., the IPR
   is owned by some other company), such person is encouraged to notify
   the IETF by sending an email message to ietf-ipr@ietf.org.  Such a
   notice should be sent as soon as reasonably possible after the person
   realizes the connection.

Phil
--Apple-Mail-6-264978569-- From alexandru.petrescu@gmail.com Tue Feb 16 09:23:57 2010 Return-Path: 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 8EAC228C100 for ; Tue, 16 Feb 2010 09:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 fnt6VPWpWG-v for ; Tue, 16 Feb 2010 09:23:56 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7DD3A79A7 for ; Tue, 16 Feb 2010 09:23:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1GHPShZ009092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 18:25:28 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1GHPSEB021023; Tue, 16 Feb 2010 18:25:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1GHPRcJ029489; Tue, 16 Feb 2010 18:25:28 +0100 Message-ID: <4B7AD507.3070608@gmail.com> Date: Tue, 16 Feb 2010 18:25:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> In-Reply-To: <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:23:57 -0000 Le 16/02/2010 00:33, Dan Lang a écrit : > Hi Jon: I am not your lawyer, so I unfortunately won’t be able to > answer your question (“From a legal sense, is your statement > compatible with the GPL?”) in way that satisfies you. However, I > don’t think that having RPL inside the Linux kernel under a GPL > license would somehow “protect” RPL and its implementers from patent > "troll" attacks. Dan - do you think RPL could get _at all_ in the linux kernel were it to have the BSD tag on it (as indicated in the RFC preamble), moreover the IPR tag too? I do not think so. I do not think RPL as it stands has any chance to get into the linux kernel. It may be now in the kernel in the lab experimentation but only until the right questions are made (e.g. "show me the code"). Please comment, Alex > The entities you are worried about don’t typically have any > products, and the GPL provides conditions on those who distribute or > modify covered works, so they would not likely be bound by any of > those conditions. If anything, they would have a larger pool of > companies against which to assert their patents. Your last question > highlights the risk of standard-setting generally; competitors or any > third parties who aren’t participating in ROLL don’t necessarily have > an obligation to disclose any of their patents to the IETF and may > choose to wait until after the standard is finalized to demand fees > (and not necessarily on reasonable and non-discriminatory terms) for > RPL-compliant products. This unfortunate fact will be true no matter > what the RPL specification looks like. Best regards, Dan > > > On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: > >> >> >> On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang > > wrote: >> >> Hi Ruben, A couple of points that I'd like to clarify in response >> to your email. Again, I recommend that you check with your >> company's attorneys but at least let me suggest some things to ask >> them about. 1. No one is being asked to "renounce their IPR." But, >> per our statement, an entity that wants to make money on or >> otherwise exploit their patents against Cisco products might have >> to pay something for a license to Cisco's patents. That seems fair >> to me, but more importantly, it seems fair to a lot of people who >> find sufficient assurance with our commitment to make numerous >> IETF standards successful. >> >> >> From a legal sense, is your statement compatible with the GPL? I >> just want to ensure that we can build a GPL'd version of RPL. I >> don't want to repeat the problems with Zigbee where their licensing >> is incompatible with the GPL. >> >> 2. We would never claim that our intellectual property provides an >> "umbrella" for the industry. Having the right to use one company's >> patents does not give you the right to use other patents if they >> are relevant. Potential exposure to unknown third party patents is >> always a concern in the information technology industry. Due to the >> large number of patents and the challenges of searching for them >> and evaluating them, it would be almost impossible to reliably >> identify all of the relevant patents for a particular product or >> standard. But our patents and our licensing commitment are not the >> cause of this problem. Even if our patents did not exist at all, >> the problem would still be there. That is why I agree with some of >> the commenters who pointed out that it is very difficult to avoid >> intellectual property concerns entirely because they cannot all be >> known. >> >> >> Trolls are everywhere and can't be identified ahead of time. Do you >> feel that the GPL and the set of companies surrounding the Linux >> kernel somewhat protects it from troll attacks? Would implementing >> the reference version of RPL inside the Linux kernel provide added >> protection to RPL users? >> >> As we reasonably sure that there aren't problem patents held by >> direct competitors who aren't participating in ROLL and might be >> interested in disrupting ROLL? >> >> Best regards, Dan >> >> >> >> >> Dan Lang Director, Intellectual Property Legal Services Cisco >> Systems, Inc. >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> -- Jon Smirl jonsmirl@gmail.com > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Tue Feb 16 09:51:47 2010 Return-Path: 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 237A63A79BE for ; Tue, 16 Feb 2010 09:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 2t3wONKiwSoB for ; Tue, 16 Feb 2010 09:51:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8ED233A7349 for ; Tue, 16 Feb 2010 09:51:43 -0800 (PST) Received: from [192.168.1.3] (line-4974.dyn.kponet.fi [85.29.65.192]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1GHrBTo030044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Feb 2010 19:53:11 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <4B7AD507.3070608@gmail.com> Date: Tue, 16 Feb 2010 19:53:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFE1358-4387-4D19-BB9A-B4E1F20C3310@sensinode.com> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) Cc: roll@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:51:47 -0000 On Feb 16, 2010, at 19:25 , Alexandru Petrescu wrote: > Le 16/02/2010 00:33, Dan Lang a =E9crit : >> Hi Jon: I am not your lawyer, so I unfortunately won=92t be able to >> answer your question (=93=46rom a legal sense, is your statement >> compatible with the GPL?=94) in way that satisfies you. However, I >> don=92t think that having RPL inside the Linux kernel under a GPL >> license would somehow =93protect=94 RPL and its implementers from = patent >> "troll" attacks. >=20 > Dan - do you think RPL could get _at all_ in the linux kernel were it = to > have the BSD tag on it (as indicated in the RFC preamble), moreover = the > IPR tag too? >=20 > I do not think so. I do not think RPL as it stands has any chance to > get into the linux kernel. It may be now in the kernel in the lab > experimentation but only until the right questions are made (e.g. = "show > me the code"). Alex. These are totally separate issues, do not mix them up. The text in = the Internet-Draft template has absolutely nothing to do with the = licensing of an implementation of that specification. Please keep your = discussion regarding this to the appropriate IETF list, it really does = not belong here. Thanks. In my understanding, Cisco's IPR terms do not prevent a GPL = implementation. Dan's point was that just because you use code licensed = under GPL, that doesn't however protect you from being sued by someone = else claiming that code infringes on their IPR (e.g. by patent = trollers).=20 Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jonsmirl@gmail.com Tue Feb 16 10:38:42 2010 Return-Path: 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 4D39228C155 for ; Tue, 16 Feb 2010 10:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hmGPeoPgjBjc for ; Tue, 16 Feb 2010 10:38:41 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id C1EA73A7D96 for ; Tue, 16 Feb 2010 10:38:40 -0800 (PST) Received: by qyk13 with SMTP id 13so3473068qyk.31 for ; Tue, 16 Feb 2010 10:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Cq9CyLVY+7iLBn5K0ln4utqi3dlHi5QcJMRj9m5QNCQ=; b=QX6JVeCZGHbjbs7Y4r7b7FWruAPNcdQvMdPn78eRT4lnrlEmSlFo0tBpZHk+8iMNVY zeHNaI02snj+MMrbACPTFJAeCQYS9ceVtZe2m2R0X89ssDv2sVZTSK22Wt3gUISHiWvD xo+dX/HcPQc5Z6aZxC1q5GUoeXwPXQKYsRrjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uz4JlGFa6KUsR90ZlyedWD6VFP5jw057a01RpcG4pNWQY8SuDt34vU+0+Xa16PoOHK UXkVzj74HCMOCIIgQx3lyhEpZ5Xdwnoyz4s09YzJCZGf9C8icF1qUoAmc2R0E6ExH3IU LrvUJUD1gO6HrzEksNWf8002vuw3S5WPJFGIc= MIME-Version: 1.0 Received: by 10.229.230.208 with SMTP id jn16mr943601qcb.106.1266345611584; Tue, 16 Feb 2010 10:40:11 -0800 (PST) In-Reply-To: <4B7AD507.3070608@gmail.com> References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> Date: Tue, 16 Feb 2010 13:40:11 -0500 Message-ID: <9e4733911002161040r1b077ad6sb025bf83fc6c7f09@mail.gmail.com> From: Jon Smirl To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 18:38:42 -0000 On Tue, Feb 16, 2010 at 12:25 PM, Alexandru Petrescu wrote: > Le 16/02/2010 00:33, Dan Lang a =E9crit : >> >> Hi Jon: I am not your lawyer, so I unfortunately won=92t be able to >> answer your question (=93From a legal sense, is your statement >> compatible with the GPL?=94) in way that satisfies you. However, I >> don=92t think that having RPL inside the Linux kernel under a GPL >> license would somehow =93protect=94 RPL and its implementers from patent >> =A0"troll" attacks. > > Dan - do you think RPL could get _at all_ in the linux kernel were it to > have the BSD tag on it (as indicated in the RFC preamble), moreover the > IPR tag too? This is a problem specific to implementations, not with the spec. The GPL is a superset of the BSD license. The detailed procedures for bringing BSD code into Linux are described here: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.htm= l I don't know of any issues with bringing BSD licensed code in to Linux if these procedures are followed. > I do not think so. =A0I do not think RPL as it stands has any chance to > get into the linux kernel. =A0It may be now in the kernel in the lab > experimentation but only until the right questions are made (e.g. "show > me the code"). The quickest way to keep RPL out of Linux is to require a patent royalty on implementations of it. The GPL explicitly prohibits royalties. There are multiple solutions to royalties: avoid patents in RPL, statements of non-assertion against RPL implementations, explicit licenses granting royalty free use in GPL'd code, etc. Those work for known patents, there is nothing anyone can do about trolls without changing the patent system. As long as no one is standing up and saying that they want royalties on RPL I see no problem with implementing it in Linux. If someone stands up later (like Microsoft did with FAT) there will be problems and the code will get removed. Of course we can't tell right now if anyone is going to make later claims. If a BSD licensed RPL implementation is already available I can start looking at bringing it into Linux. I'd prefer to port tested code than start from scratch. Low level 802.15.4 support is already in the kernel. 6lowpan has not been added yet but I believe Dimitry is working on it. > > Please comment, > > Alex > >> The entities you are worried about don=92t typically have any >> products, and the GPL provides conditions on those who distribute or >> modify covered works, so they would not likely be bound by any of >> those conditions. If anything, they would have a larger pool of >> companies against which to assert their patents. Your last question >> highlights the risk of standard-setting generally; competitors or any >> third parties who aren=92t participating in ROLL don=92t necessarily hav= e >> an obligation to disclose any of their patents to the IETF and may >> choose to wait until after the standard is finalized to demand fees >> (and not necessarily on reasonable and non-discriminatory terms) for >> =A0RPL-compliant products. This unfortunate fact will be true no matter >> =A0what the RPL specification looks like. Best regards, Dan >> >> >> On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: >> >>> >>> >>> On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang >> > wrote: >>> >>> Hi Ruben, A couple of points that I'd like to clarify in response >>> to your email. Again, I recommend that you check with your >>> company's attorneys but at least let me suggest some things to ask >>> =A0them about. 1. No one is being asked to "renounce their IPR." But, >>> =A0per our statement, an entity that wants to make money on or >>> otherwise exploit their patents against Cisco products might have >>> to pay something for a license to Cisco's patents. That seems fair >>> =A0to me, but more importantly, it seems fair to a lot of people who >>> =A0find sufficient assurance with our commitment to make numerous >>> IETF standards successful. >>> >>> >>> From a legal sense, is your statement compatible with the GPL? I >>> just want to ensure that we can build a GPL'd version of RPL. I >>> don't want to repeat the problems with Zigbee where their licensing >>> is incompatible with the GPL. >>> >>> 2. We would never claim that our intellectual property provides an >>> "umbrella" for the industry. Having the right to use one company's >>> patents does not give you the right to use other patents if they >>> are relevant. Potential exposure to unknown third party patents is >>> always a concern in the information technology industry. Due to the >>> large number of patents and the challenges of searching for them >>> and evaluating them, it would be almost impossible to reliably >>> identify all of the relevant patents for a particular product or >>> standard. But our patents and our licensing commitment are not the >>> cause of this problem. Even if our patents did not exist at all, >>> the problem would still be there. That is why I agree with some of >>> the commenters who pointed out that it is very difficult to avoid >>> intellectual property concerns entirely because they cannot all be >>> known. >>> >>> >>> Trolls are everywhere and can't be identified ahead of time. Do you >>> feel that the GPL and the set of companies surrounding the Linux >>> kernel somewhat protects it from troll attacks? Would implementing >>> the reference version of RPL inside the Linux kernel provide added >>> protection to RPL users? >>> >>> As we reasonably sure that there aren't problem patents held by >>> direct competitors who aren't participating in ROLL and might be >>> interested in disrupting ROLL? >>> >>> Best regards, Dan >>> >>> >>> >>> >>> Dan Lang Director, Intellectual Property Legal Services Cisco >>> Systems, Inc. >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> >>> >>> -- Jon Smirl jonsmirl@gmail.com >> >> >> >> _______________________________________________ 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 > --=20 Jon Smirl jonsmirl@gmail.com From alexandru.petrescu@gmail.com Tue Feb 16 11:11:00 2010 Return-Path: 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 232F128C0DB for ; Tue, 16 Feb 2010 11:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 ShKOop6EKlxg for ; Tue, 16 Feb 2010 11:10:56 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id BDF743A7D8E for ; Tue, 16 Feb 2010 11:10:27 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 41148D481AC; Tue, 16 Feb 2010 20:11:48 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0A020D4807B; Tue, 16 Feb 2010 20:11:45 +0100 (CET) Message-ID: <4B7AEDEF.60407@gmail.com> Date: Tue, 16 Feb 2010 20:11:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Zach Shelby References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> <8AFE1358-4387-4D19-BB9A-B4E1F20C3310@sensinode.com> In-Reply-To: <8AFE1358-4387-4D19-BB9A-B4E1F20C3310@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:11:00 -0000 Le 16/02/2010 18:53, Zach Shelby a écrit : > On Feb 16, 2010, at 19:25 , Alexandru Petrescu wrote: > >> Le 16/02/2010 00:33, Dan Lang a écrit : >>> Hi Jon: I am not your lawyer, so I unfortunately won’t be able to >>> answer your question (“From a legal sense, is your statement >>> compatible with the GPL?”) in way that satisfies you. However, I >>> don’t think that having RPL inside the Linux kernel under a GPL >>> license would somehow “protect” RPL and its implementers from >>> patent "troll" attacks. >> >> Dan - do you think RPL could get _at all_ in the linux kernel were >> it to have the BSD tag on it (as indicated in the RFC preamble), >> moreover the IPR tag too? >> >> I do not think so. I do not think RPL as it stands has any chance >> to get into the linux kernel. It may be now in the kernel in the >> lab experimentation but only until the right questions are made >> (e.g. "show me the code"). > > Alex. These are totally separate issues, do not mix them up. The > text in the Internet-Draft template has absolutely nothing to do with > the licensing of an implementation of that specification. I am not sure why you think they're separate issues. In my experience both the boilerplate conditions and the IPR conditions are tightly coupled. One RFC I co-authored had two IPR tags on them, one specifically saying "open source". > Please keep your discussion regarding this to the appropriate IETF > list, it really does not belong here. Thanks. Which IETF list please? I started something in the ipr-wg list only to realize it's not anylonger an IETF list (WG IPR closed or so). I am not sure where to do it properly. > In my understanding, Cisco's IPR terms do not prevent a GPL > implementation. Dan's point was that just because you use code > licensed under GPL, that doesn't however protect you from being sued > by someone else claiming that code infringes on their IPR I agree. Moreover, explicit IPR conditions has even less chances of the GPL conditions to protect me. > (e.g. by patent trollers). What's a patent troller? Alex > > Zach > From alexandru.petrescu@gmail.com Tue Feb 16 11:39:59 2010 Return-Path: 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 8D5BD3A75C8 for ; Tue, 16 Feb 2010 11:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 7PXVOIAgH6SF for ; Tue, 16 Feb 2010 11:39:58 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id C43D83A7375 for ; Tue, 16 Feb 2010 11:39:56 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B81C4D480DE; Tue, 16 Feb 2010 20:41:28 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 97E52D481A4; Tue, 16 Feb 2010 20:41:25 +0100 (CET) Message-ID: <4B7AF4E3.206@gmail.com> Date: Tue, 16 Feb 2010 20:41:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jon Smirl References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> <9e4733911002161040r1b077ad6sb025bf83fc6c7f09@mail.gmail.com> In-Reply-To: <9e4733911002161040r1b077ad6sb025bf83fc6c7f09@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:39:59 -0000 Le 16/02/2010 19:40, Jon Smirl a écrit : > On Tue, Feb 16, 2010 at 12:25 PM, Alexandru Petrescu > wrote: >> Le 16/02/2010 00:33, Dan Lang a écrit : >>> >>> Hi Jon: I am not your lawyer, so I unfortunately won’t be able to >>> answer your question (“From a legal sense, is your statement >>> compatible with the GPL?”) in way that satisfies you. However, I >>> don’t think that having RPL inside the Linux kernel under a GPL >>> license would somehow “protect” RPL and its implementers from >>> patent "troll" attacks. >> >> Dan - do you think RPL could get _at all_ in the linux kernel were >> it to have the BSD tag on it (as indicated in the RFC preamble), >> moreover the IPR tag too? > > This is a problem specific to implementations, not with the spec. I agree the BSD-or-no-BSD is specific to implementations and should stay that way. I don't understand why this RFC must say "BSD" if a particular implementation absolutely wants to say exclusively GPL and no BSD. (or any other yet-to-be-written license scheme). > The GPL is a superset of the BSD license. The detailed procedures for > bringing BSD code into Linux are described here: > http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html (I will say again as I usually say in this WG: please don't point me to non-IETF urls I don't read them usually). That url gives advice about text to be added at the top of the files in order to make it work BSD-together-with-other-license. I do not want it. I want to write my own license the way I want, sorry. > I don't know of any issues with bringing BSD licensed code in to > Linux if these procedures are followed. I could give you examples. Recently a poster pointed to an existing license in the linux kernel telling how BSD and GPL could live together. That license says something like this: "Copyright Widget... Alternatively... GPL". That is pure nonsense, because neither Widget is sure to keep its name nor GPL is sure to have it source-offered-on-demand. This is trouble waiting to happen. >> I do not think so. I do not think RPL as it stands has any chance >> to get into the linux kernel. It may be now in the kernel in the >> lab experimentation but only until the right questions are made >> (e.g. "show me the code"). > > The quickest way to keep RPL out of Linux is to require a patent > royalty on implementations of it. I agree, mostly. Sometimes it can happen without going as far as asking royalties. There are watchdog organizations making sure GPL is enforced. When they employ lawyers only to check GPL is respected then big things happen for commercial actors. I could cite examples. Implementer should protect code the way s/e better feels, not the way BSD or IETF or particular company believes it should. There are many commercial interests and rarely are they compatible. > The GPL explicitly prohibits royalties. There are multiple solutions > to royalties: avoid patents in RPL, statements of non-assertion > against RPL implementations, explicit licenses granting royalty free > use in GPL'd code, etc. Those work for known patents, there is > nothing anyone can do about trolls without changing the patent > system. > > As long as no one is standing up and saying that they want royalties > on RPL I see no problem with implementing it in Linux. Even if IPR royalties are not demanded I see a problem: particular company implements RPL in linux kernel, linux maintainers ask for GPL, company says ok. Then another company asks for the source code. First company says no. And here go problems without IPR being involved. > If someone stands up later (like Microsoft did with FAT) there will > be problems and the code will get removed. Of course we can't tell > right now if anyone is going to make later claims. Not only companies like Microsoft can ask for rights and accuse of IPR infringement. Interests watching for GPL enforcement can also make statements hurting. And I can say I saw it happening. > If a BSD licensed RPL implementation is already available I can start > looking at bringing it into Linux. People tried too in the past, for the TCP/IP stack for example. They finished by rewriting code. Fortunately TCP/IP specs don't have that "BSD" tag, earlier than IETF Trust. (check for example defrag code in IPv6 rfc2460 - fortunately it doesn't have the BSD tag on it). > I'd prefer to port tested code than start from scratch. I fully agree. I prefer too to use code from RFCs, but if code in RFC has that BSD tag then it's all useless, have to rewrite. > Low level 802.15.4 support is already in the kernel. Hmm... is IEEE happy with the GPL in the linux kernel? Are the kernel maintainers happy with the IPRs claimed by some IEEE contributors? If any doubt - that spells trouble waiting to happen. > 6lowpan has not been added yet but I believe Dimitry is working on > it. IMHO, let me indulge myself an advice to Dmitry: don't implement until it's an RFC :-); mostly for technical reasons, but licensing too. Alex > >> >> Please comment, >> >> Alex >> >>> The entities you are worried about don’t typically have any >>> products, and the GPL provides conditions on those who >>> distribute or modify covered works, so they would not likely be >>> bound by any of those conditions. If anything, they would have a >>> larger pool of companies against which to assert their patents. >>> Your last question highlights the risk of standard-setting >>> generally; competitors or any third parties who aren’t >>> participating in ROLL don’t necessarily have an obligation to >>> disclose any of their patents to the IETF and may choose to wait >>> until after the standard is finalized to demand fees (and not >>> necessarily on reasonable and non-discriminatory terms) for >>> RPL-compliant products. This unfortunate fact will be true no >>> matter what the RPL specification looks like. Best regards, Dan >>> >>> >>> On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: >>> >>>> >>>> >>>> On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang>>> > wrote: >>>> >>>> Hi Ruben, A couple of points that I'd like to clarify in >>>> response to your email. Again, I recommend that you check with >>>> your company's attorneys but at least let me suggest some >>>> things to ask them about. 1. No one is being asked to >>>> "renounce their IPR." But, per our statement, an entity that >>>> wants to make money on or otherwise exploit their patents >>>> against Cisco products might have to pay something for a >>>> license to Cisco's patents. That seems fair to me, but more >>>> importantly, it seems fair to a lot of people who find >>>> sufficient assurance with our commitment to make numerous IETF >>>> standards successful. >>>> >>>> >>>> From a legal sense, is your statement compatible with the GPL? >>>> I just want to ensure that we can build a GPL'd version of RPL. >>>> I don't want to repeat the problems with Zigbee where their >>>> licensing is incompatible with the GPL. >>>> >>>> 2. We would never claim that our intellectual property >>>> provides an "umbrella" for the industry. Having the right to >>>> use one company's patents does not give you the right to use >>>> other patents if they are relevant. Potential exposure to >>>> unknown third party patents is always a concern in the >>>> information technology industry. Due to the large number of >>>> patents and the challenges of searching for them and evaluating >>>> them, it would be almost impossible to reliably identify all of >>>> the relevant patents for a particular product or standard. But >>>> our patents and our licensing commitment are not the cause of >>>> this problem. Even if our patents did not exist at all, the >>>> problem would still be there. That is why I agree with some of >>>> the commenters who pointed out that it is very difficult to >>>> avoid intellectual property concerns entirely because they >>>> cannot all be known. >>>> >>>> >>>> Trolls are everywhere and can't be identified ahead of time. >>>> Do you feel that the GPL and the set of companies surrounding >>>> the Linux kernel somewhat protects it from troll attacks? >>>> Would implementing the reference version of RPL inside the >>>> Linux kernel provide added protection to RPL users? >>>> >>>> As we reasonably sure that there aren't problem patents held by >>>> direct competitors who aren't participating in ROLL and might >>>> be interested in disrupting ROLL? >>>> >>>> Best regards, Dan >>>> >>>> >>>> >>>> >>>> Dan Lang Director, Intellectual Property Legal Services Cisco >>>> Systems, Inc. >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>>> >>>> >>>> -- Jon Smirl jonsmirl@gmail.com >>> >>> >>> >>> _______________________________________________ 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 >> > > > From alexandru.petrescu@gmail.com Tue Feb 16 14:49:45 2010 Return-Path: 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 1016828C0CF for ; Tue, 16 Feb 2010 14:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 alcVIP6dZ4sd for ; Tue, 16 Feb 2010 14:49:44 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 498213A78F4 for ; Tue, 16 Feb 2010 14:49:42 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 40E5FD48061 for ; Tue, 16 Feb 2010 23:51:15 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 079DCD4809A for ; Tue, 16 Feb 2010 23:51:12 +0100 (CET) Message-ID: <4B7B215E.9010502@gmail.com> Date: Tue, 16 Feb 2010 23:51:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Which xml2rfc ipr attribute does the RPL draft use? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 22:49:45 -0000 Excuse me - which ipr attribute does the RPL draft use (supposing it's formatted with xml2rfc, at the beginning of the file, ipr="xxx"). I need to understand the different options possible. I posted the question on xml2rfc list but didn't get through. I hope the list is functional. Thanks, I will listen, Alex From Adrian.Farrel@huawei.com Tue Feb 16 16:35:23 2010 Return-Path: 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 E7E0A28C108 for ; Tue, 16 Feb 2010 16:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] 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 H326CJ3Nz7gK for ; Tue, 16 Feb 2010 16:35:23 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 425BF3A7E15 for ; Tue, 16 Feb 2010 16:35:23 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXY000HXN1NHD@usaga01-in.huawei.com> for roll@ietf.org; Tue, 16 Feb 2010 16:36:59 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXY00306N1L62@usaga01-in.huawei.com> for roll@ietf.org; Tue, 16 Feb 2010 16:36:59 -0800 (PST) Date: Wed, 17 Feb 2010 00:36:41 +0000 From: Adrian Farrel To: Alexandru Petrescu , Zach Shelby Message-id: <1C24DA1B447546D2A7453DE0A7DDF4AB@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> <8AFE1358-4387-4D19-BB9A-B4E1F20C3310@sensinode.com> <4B7AEDEF.60407@gmail.com> Cc: roll@ietf.org Subject: [Roll] Where to discuss IETF Trust Legal Provisions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 00:35:24 -0000 > > Please keep your discussion regarding this to the appropriate IETF >> list, it really does not belong here. Thanks. > > Which IETF list please? I started something in the ipr-wg list only to > realize it's not anylonger an IETF list (WG IPR closed or so). I am not > sure where to do it properly. The IETF Trust Legal Provisions are described at http://trustee.ietf.org/license-info/ It states... The Trustees request that discussion of this topic be on the tlp-interest list, tlp-interest@ietf.org, with cc to trustees@ietf.org . This list can be joined here: https://www.ietf.org/mailman/listinfo/tlp-interest Thanks, Adrian From Adrian.Farrel@huawei.com Tue Feb 16 16:43:32 2010 Return-Path: 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 539EC28C120 for ; Tue, 16 Feb 2010 16:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] 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 1srfCbx1mPBW for ; Tue, 16 Feb 2010 16:43:30 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C5EF73A7E23 for ; Tue, 16 Feb 2010 16:43:30 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXY007BHNF6QY@usaga03-in.huawei.com> for roll@ietf.org; Tue, 16 Feb 2010 18:45:06 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXY00644NF4IG@usaga03-in.huawei.com> for roll@ietf.org; Tue, 16 Feb 2010 18:45:06 -0600 (CST) Date: Wed, 17 Feb 2010 00:44:48 +0000 From: Adrian Farrel To: Alexandru Petrescu , Jon Smirl Message-id: <2F5CADA1243F44C89AF2CCE6AE5A87A9@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <618C42FE-C5B8-4838-857E-43682072B21A@cisco.com> <9e4733911002150533u1dd14483p9b1cb6ee154edf78@mail.gmail.com> <2D8A76FB-4451-46D6-A1A0-7DFA14A7AC84@cisco.com> <4B7AD507.3070608@gmail.com> <9e4733911002161040r1b077ad6sb025bf83fc6c7f09@mail.gmail.com> <4B7AF4E3.206@gmail.com> Cc: roll@ietf.org Subject: [Roll] Discussions of GPL versus BFD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 00:43:32 -0000 Hi, As per my previous mail, discussions of the content and intent of the TLP can be had on the tlp-interest mailing list with the participation of the trustees. They have chosen a specific wording for inclusion in I-Ds and RFCs according to their judgement and the advice they have received. From our point of view we can choose to debate it, but we cannot vary from it within the IETF. It is also clear that any code extracted from an I-D or RFC must conform to the license terms as set out in the TLP. Further discussion of whether it is appropriate to say one thing or another within a ROLL I-D is, therefore, not fruitful on this mailing list. The I-D will say what it must say unless and until the rules are changed. Thanks, Adrian ----- Original Message ----- From: "Alexandru Petrescu" To: "Jon Smirl" Cc: Sent: Tuesday, February 16, 2010 7:41 PM Subject: Re: [Roll] Closing on the IPR Le 16/02/2010 19:40, Jon Smirl a écrit : > On Tue, Feb 16, 2010 at 12:25 PM, Alexandru Petrescu > wrote: >> Le 16/02/2010 00:33, Dan Lang a écrit : >>> >>> Hi Jon: I am not your lawyer, so I unfortunately won’t be able to >>> answer your question (“From a legal sense, is your statement >>> compatible with the GPL?”) in way that satisfies you. However, I >>> don’t think that having RPL inside the Linux kernel under a GPL >>> license would somehow “protect” RPL and its implementers from >>> patent "troll" attacks. >> >> Dan - do you think RPL could get _at all_ in the linux kernel were >> it to have the BSD tag on it (as indicated in the RFC preamble), >> moreover the IPR tag too? > > This is a problem specific to implementations, not with the spec. I agree the BSD-or-no-BSD is specific to implementations and should stay that way. I don't understand why this RFC must say "BSD" if a particular implementation absolutely wants to say exclusively GPL and no BSD. (or any other yet-to-be-written license scheme). > The GPL is a superset of the BSD license. The detailed procedures for > bringing BSD code into Linux are described here: > http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html (I will say again as I usually say in this WG: please don't point me to non-IETF urls I don't read them usually). That url gives advice about text to be added at the top of the files in order to make it work BSD-together-with-other-license. I do not want it. I want to write my own license the way I want, sorry. > I don't know of any issues with bringing BSD licensed code in to > Linux if these procedures are followed. I could give you examples. Recently a poster pointed to an existing license in the linux kernel telling how BSD and GPL could live together. That license says something like this: "Copyright Widget... Alternatively... GPL". That is pure nonsense, because neither Widget is sure to keep its name nor GPL is sure to have it source-offered-on-demand. This is trouble waiting to happen. >> I do not think so. I do not think RPL as it stands has any chance >> to get into the linux kernel. It may be now in the kernel in the >> lab experimentation but only until the right questions are made >> (e.g. "show me the code"). > > The quickest way to keep RPL out of Linux is to require a patent > royalty on implementations of it. I agree, mostly. Sometimes it can happen without going as far as asking royalties. There are watchdog organizations making sure GPL is enforced. When they employ lawyers only to check GPL is respected then big things happen for commercial actors. I could cite examples. Implementer should protect code the way s/e better feels, not the way BSD or IETF or particular company believes it should. There are many commercial interests and rarely are they compatible. > The GPL explicitly prohibits royalties. There are multiple solutions > to royalties: avoid patents in RPL, statements of non-assertion > against RPL implementations, explicit licenses granting royalty free > use in GPL'd code, etc. Those work for known patents, there is > nothing anyone can do about trolls without changing the patent > system. > > As long as no one is standing up and saying that they want royalties > on RPL I see no problem with implementing it in Linux. Even if IPR royalties are not demanded I see a problem: particular company implements RPL in linux kernel, linux maintainers ask for GPL, company says ok. Then another company asks for the source code. First company says no. And here go problems without IPR being involved. > If someone stands up later (like Microsoft did with FAT) there will > be problems and the code will get removed. Of course we can't tell > right now if anyone is going to make later claims. Not only companies like Microsoft can ask for rights and accuse of IPR infringement. Interests watching for GPL enforcement can also make statements hurting. And I can say I saw it happening. > If a BSD licensed RPL implementation is already available I can start > looking at bringing it into Linux. People tried too in the past, for the TCP/IP stack for example. They finished by rewriting code. Fortunately TCP/IP specs don't have that "BSD" tag, earlier than IETF Trust. (check for example defrag code in IPv6 rfc2460 - fortunately it doesn't have the BSD tag on it). > I'd prefer to port tested code than start from scratch. I fully agree. I prefer too to use code from RFCs, but if code in RFC has that BSD tag then it's all useless, have to rewrite. > Low level 802.15.4 support is already in the kernel. Hmm... is IEEE happy with the GPL in the linux kernel? Are the kernel maintainers happy with the IPRs claimed by some IEEE contributors? If any doubt - that spells trouble waiting to happen. > 6lowpan has not been added yet but I believe Dimitry is working on > it. IMHO, let me indulge myself an advice to Dmitry: don't implement until it's an RFC :-); mostly for technical reasons, but licensing too. Alex > >> >> Please comment, >> >> Alex >> >>> The entities you are worried about don’t typically have any >>> products, and the GPL provides conditions on those who >>> distribute or modify covered works, so they would not likely be >>> bound by any of those conditions. If anything, they would have a >>> larger pool of companies against which to assert their patents. >>> Your last question highlights the risk of standard-setting >>> generally; competitors or any third parties who aren’t >>> participating in ROLL don’t necessarily have an obligation to >>> disclose any of their patents to the IETF and may choose to wait >>> until after the standard is finalized to demand fees (and not >>> necessarily on reasonable and non-discriminatory terms) for >>> RPL-compliant products. This unfortunate fact will be true no >>> matter what the RPL specification looks like. Best regards, Dan >>> >>> >>> On Feb 15, 2010, at 5:33 AM, Jon Smirl wrote: >>> >>>> >>>> >>>> On Mon, Feb 15, 2010 at 12:41 AM, Dan Lang>>> > wrote: >>>> >>>> Hi Ruben, A couple of points that I'd like to clarify in >>>> response to your email. Again, I recommend that you check with >>>> your company's attorneys but at least let me suggest some >>>> things to ask them about. 1. No one is being asked to >>>> "renounce their IPR." But, per our statement, an entity that >>>> wants to make money on or otherwise exploit their patents >>>> against Cisco products might have to pay something for a >>>> license to Cisco's patents. That seems fair to me, but more >>>> importantly, it seems fair to a lot of people who find >>>> sufficient assurance with our commitment to make numerous IETF >>>> standards successful. >>>> >>>> >>>> From a legal sense, is your statement compatible with the GPL? >>>> I just want to ensure that we can build a GPL'd version of RPL. >>>> I don't want to repeat the problems with Zigbee where their >>>> licensing is incompatible with the GPL. >>>> >>>> 2. We would never claim that our intellectual property >>>> provides an "umbrella" for the industry. Having the right to >>>> use one company's patents does not give you the right to use >>>> other patents if they are relevant. Potential exposure to >>>> unknown third party patents is always a concern in the >>>> information technology industry. Due to the large number of >>>> patents and the challenges of searching for them and evaluating >>>> them, it would be almost impossible to reliably identify all of >>>> the relevant patents for a particular product or standard. But >>>> our patents and our licensing commitment are not the cause of >>>> this problem. Even if our patents did not exist at all, the >>>> problem would still be there. That is why I agree with some of >>>> the commenters who pointed out that it is very difficult to >>>> avoid intellectual property concerns entirely because they >>>> cannot all be known. >>>> >>>> >>>> Trolls are everywhere and can't be identified ahead of time. >>>> Do you feel that the GPL and the set of companies surrounding >>>> the Linux kernel somewhat protects it from troll attacks? >>>> Would implementing the reference version of RPL inside the >>>> Linux kernel provide added protection to RPL users? >>>> >>>> As we reasonably sure that there aren't problem patents held by >>>> direct competitors who aren't participating in ROLL and might >>>> be interested in disrupting ROLL? >>>> >>>> Best regards, Dan >>>> >>>> >>>> >>>> >>>> Dan Lang Director, Intellectual Property Legal Services Cisco >>>> Systems, Inc. >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>>> >>>> >>>> -- Jon Smirl jonsmirl@gmail.com >>> >>> >>> >>> _______________________________________________ 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 From wintert@acm.org Wed Feb 17 05:23:31 2010 Return-Path: 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 118803A7CD7 for ; Wed, 17 Feb 2010 05:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 XP1MTfqNuU21 for ; Wed, 17 Feb 2010 05:23:30 -0800 (PST) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 3CC9A3A7BAB for ; Wed, 17 Feb 2010 05:23:30 -0800 (PST) Received: (qmail 18598 invoked from network); 17 Feb 2010 13:25:06 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 17 Feb 2010 05:25:05 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: cq5oLyoVM1nIhc0Ss9s_5zrccrKhpSI29bzmzbydBdva20_6iUNYwYV_M8wgvGW9XOA6jcIJ_tWapAHQOQHxJZ9zfniAJPzsr.8OI706L0Gn7vQHE4JpRDgEAnCZr17wHm_Wxacec6GiI0EpNMA9f4kyBEYJB_sfI6fWF_zhuWlRcq_PXZIBA0B7bXbBtahsHR4ANHyUg2yDqoAOQ8ajwGSdynY8o3Jc0vuEvbeEFksWqTsILXJcj5Z6hoA0zh1CsId6bsPd4ZxxR.p.YxeWyjWtdqgWpmU9Ch9J2ENELgRcRiBesNhmOSYe7lQbiA8X9lvUl_0S3AadkcjwLY7r X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B7BEE35.4080901@acm.org> Date: Wed, 17 Feb 2010 08:25:09 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B7B215E.9010502@gmail.com> In-Reply-To: <4B7B215E.9010502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Which xml2rfc ipr attribute does the RPL draft use? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 13:23:31 -0000 Hi Alex, We do use xml2rfc -- the xml is also available from the repository at http://www.ietf.org/id/draft-ietf-roll-rpl-06.xml The present attribute is "trust200902". Regards, -Tim Alexandru Petrescu wrote: > Excuse me - which ipr attribute does the RPL draft use (supposing it's > formatted with xml2rfc, at the beginning of the file, ipr="xxx"). > > I need to understand the different options possible. > > I posted the question on xml2rfc list but didn't get through. I hope the > list is functional. > > Thanks, I will listen, > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Wed Feb 17 05:38:26 2010 Return-Path: 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 5B8603A7968 for ; Wed, 17 Feb 2010 05:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 EDRhuY4vIgtV for ; Wed, 17 Feb 2010 05:38:25 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9F13A76B7 for ; Wed, 17 Feb 2010 05:38:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HDdxUl004546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2010 14:40:00 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HDdxOj026444; Wed, 17 Feb 2010 14:39:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HDdxAW000876; Wed, 17 Feb 2010 14:39:59 +0100 Message-ID: <4B7BF1AF.8000800@gmail.com> Date: Wed, 17 Feb 2010 14:39:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Adrian Farrel References: <4B7B215E.9010502@gmail.com> <4B7BEE35.4080901@acm.org> In-Reply-To: <4B7BEE35.4080901@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Which xml2rfc ipr attribute does the RPL draft use? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 13:38:26 -0000 Le 17/02/2010 14:25, Tim Winter a écrit : > Hi Alex, > > We do use xml2rfc -- the xml is also available from the repository > at http://www.ietf.org/id/draft-ietf-roll-rpl-06.xml Thanks. It is strange this pointer to the xml version doesn't appear at the tools page of this draft (where one could find the various versions txt, pdf, earlier, diffs, more): http://tools.ietf.org/html/draft-ietf-roll-rpl-06 > The present attribute is "trust200902". Ok, thanks for the clarification. Alex > > Regards, > > -Tim > > Alexandru Petrescu wrote: >> Excuse me - which ipr attribute does the RPL draft use (supposing >> it's formatted with xml2rfc, at the beginning of the file, >> ipr="xxx"). >> >> I need to understand the different options possible. >> >> I posted the question on xml2rfc list but didn't get through. I >> hope the list is functional. >> >> Thanks, I will listen, >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From adrian@olddog.co.uk Wed Feb 17 06:43:26 2010 Return-Path: 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 652C328C15D for ; Wed, 17 Feb 2010 06:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] 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 GSIBtDHqzchI for ; Wed, 17 Feb 2010 06:43:25 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 4B21128C17D for ; Wed, 17 Feb 2010 06:43:25 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1HEikR5032283; Wed, 17 Feb 2010 14:44:51 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1HEih7A032275; Wed, 17 Feb 2010 14:44:45 GMT Message-ID: <101E9F65A32441AAAA78714DEF2F171E@your029b8cecfe> From: "Adrian Farrel" To: "Alexandru Petrescu" References: <4B7B215E.9010502@gmail.com> <4B7BEE35.4080901@acm.org> <4B7BF1AF.8000800@gmail.com> Date: Wed, 17 Feb 2010 14:44:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by asmtp3.iomartmail.com id o1HEih7A032275 Cc: ROLL WG Subject: Re: [Roll] Which xml2rfc ipr attribute does the RPL draft use? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 14:43:26 -0000 Alex, The XML is a little harder to find because it is not very readable. That=20 means that most people don't want to see it. If you need to see the XML for a draft (only a proportion actually have X= ML=20 submitted) I suggest you go in through the datatracker front end. The sea= rch=20 tool at https://datatracker.ietf.org/ will take you to=20 https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ where there is an X= ML=20 link. However, on my computer, the link seems to be broken so I have filed a=20 ticket with the tools team. Adrian ----- Original Message -----=20 From: "Alexandru Petrescu" To: "Adrian Farrel" Cc: "ROLL WG" Sent: Wednesday, February 17, 2010 1:39 PM Subject: Re: [Roll] Which xml2rfc ipr attribute does the RPL draft use? Le 17/02/2010 14:25, Tim Winter a =E9crit : > Hi Alex, > > We do use xml2rfc -- the xml is also available from the repository > at http://www.ietf.org/id/draft-ietf-roll-rpl-06.xml Thanks. It is strange this pointer to the xml version doesn't appear at the tools page of this draft (where one could find the various versions txt, pdf, earlier, diffs, more): http://tools.ietf.org/html/draft-ietf-roll-rpl-06 > The present attribute is "trust200902". Ok, thanks for the clarification. Alex > > Regards, > > -Tim > > Alexandru Petrescu wrote: >> Excuse me - which ipr attribute does the RPL draft use (supposing >> it's formatted with xml2rfc, at the beginning of the file, >> ipr=3D"xxx"). >> >> I need to understand the different options possible. >> >> I posted the question on xml2rfc list but didn't get through. I >> hope the list is functional. >> >> Thanks, I will listen, >> >> Alex _______________________________________________ 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 From privateanand@gmail.com Wed Feb 17 10:53:22 2010 Return-Path: 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 317D928C22D for ; Wed, 17 Feb 2010 10:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zWsfSTD1Jkbt for ; Wed, 17 Feb 2010 10:53:21 -0800 (PST) Received: from mail-px0-f188.google.com (mail-px0-f188.google.com [209.85.216.188]) by core3.amsl.com (Postfix) with ESMTP id 227A628C22A for ; Wed, 17 Feb 2010 10:53:21 -0800 (PST) Received: by pxi26 with SMTP id 26so7063080pxi.17 for ; Wed, 17 Feb 2010 10:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+qCE6Wu+nqaUl+Z9HaEf7+D2nQaRnQQ76DquE889iU8=; b=MK1UowaxHiG4wrK6YAp54fju/HqOFtKiRxIVEbm/Msx8FW5X+c/cnrA4cjrUKNXdny IxyujX9g0nYWlLJbZIiEWhdhVPdBM4VZGyYgQvzxtdLptiBX88WVmMwSXs1woIllCXem bu6R2u9hgo2st6LfVxSVL2ZNTj19f1uX4nCDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OtHbb5JD87CMpFl0wBpKF4I5Jy76yPEU/iLFXqozvQoujzAPJp4n+0VJzSak97meMT gEs1G/grs5dXYBl63vWaXGQFLwg058FmjRFErSjSjElbNiatBkywv5prWgAF7YKPgOEV XpxX6be5WsM1jVnq/KxiIsKer7DBJ+zVKOzVA= MIME-Version: 1.0 Received: by 10.142.3.33 with SMTP id 33mr1377011wfc.275.1266432897594; Wed, 17 Feb 2010 10:54:57 -0800 (PST) In-Reply-To: <4B79BDE6.7060509@sics.se> References: <9154EF94-F4E8-4A06-AA19-522DA8999DA9@cisco.com> <4B79BDE6.7060509@sics.se> Date: Wed, 17 Feb 2010 13:54:57 -0500 Message-ID: From: "M. B. Anand" To: roll@ietf.org Content-Type: multipart/alternative; boundary=00504502bd95fe3666047fd062a2 Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:53:22 -0000 --00504502bd95fe3666047fd062a2 Content-Type: text/plain; charset=ISO-8859-1 As someone who has sadly had to spend long amounts of time on patent-related matters going over words and phrases despite being an engineer and not a lawyer, I can provide the following inputs, divided into two parts, IPR in general (#1 to #5) and the Cisco declaration (#6, #7) in particular: 1. I would think as a practical matter it is impossible to have a design goal of not infringing on patents - even a cursory search will produce thousands and of course it is certainly not a matter of the US patents alone, there are patents in every country out there. Even a less stringent goal of "small chance" would be unachievable. 2. And even if that is done, exactly how to avoid this or that is no simple matter. Exactly what a claim means or does not mean, is what gets disputed, and gets settled in hearings and courts. To pre-decide all this is obviously not possible. 3. At best one might decide post-facto, whether something, after knowing what it is, infringes or not, and that would still be a matter of opinion. You might spend a few tens of K $, or hundreds of K and get a legal opinion on whether RPL infringes on some Cisco patent, but that also means not a whole lot. The matter only gets settled eventually in a suit if there is a dispute. 4. There are plenty of jaw-dropping patents, for example things like what might sound to all us engineers as simply source routing. Anyone involved in smart grid activities in the US might know this from several recent cases. 5. Therefore, remember that the absence of evidence, is not evidence of absence. Just because no one declares to have IPR in IETF on whatever standard is drafted absolutely does not mean there isn't any. I would in fact bet that it is quite the opposite. 6. One almost gets the impression from some of the discussion that lots of people are very concerned for the day they might decide to sue Cisco for royalties for something (are you quaking in your boots, yet, Dan :-)) I find that in itself to be a remote probability. 7. But let's say it is real and someone stands to make gazillions in royalties from Cisco. Even then as far as RPL is concerned, Cisco says they will provide royalty-bearing licenses for "reasonable, non-discriminatory" terms. That would mean, I think, a) they won't say, get lost, no RPL license for you because you decided to sue, b) they won't charge you anything special and provide a license at the same terms as others. Is that correct, Dan ? I would think this is quite fair. For all these reasons, I would support moving forward with the RPL draft. Regards, Anand. --00504502bd95fe3666047fd062a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As someone who has sadly had to spend long amounts of time on patent-relate= d matters going over words and phrases despite being an engineer and not a = lawyer, I can provide the following inputs, divided into two parts, IPR in = general (#1 to #5) and the Cisco declaration (#6, #7) in particular:

1. I would think as a practical matter it is impossible to have a desig= n goal of not infringing on patents=A0 - even a cursory search will produce= thousands and of course it is certainly not a matter of the US patents alo= ne, there are patents in every country out there. Even a less stringent goa= l of "small chance" would be unachievable.

2. And even if that is done, exactly how to avoid this or that is no si= mple matter. Exactly what a claim means or does not mean, is what gets disp= uted, and gets settled in hearings and courts. To pre-decide all this is ob= viously not possible.

3. At best one might decide post-facto, whether something, after knowin= g what it is, infringes or not, and that would still be a matter of opinion= . You might spend a few tens of K $, or hundreds of K and get a legal opini= on on whether RPL infringes on some Cisco patent, but that also means not a= whole lot. The matter only gets settled eventually in a suit if there is a= dispute.

4. There are plenty of jaw-dropping patents, for example things like wh= at might sound to all us engineers as simply source routing. Anyone involve= d in smart grid activities in the US might know this from several recent ca= ses.

5. Therefore, remember that the absence of evidence, is not evidence of= absence. Just because no one declares to have IPR in IETF on whatever stan= dard is drafted absolutely does not mean there isn't any. I would in fa= ct bet that it is quite the opposite.

6. One almost gets the impression from some of the discussion that lots= of people are very concerned for the day they might decide to sue Cisco fo= r royalties for something (are you quaking in your boots, yet, Dan :-)) I f= ind that in itself to be a remote probability.

7. But let's say it is real and someone stands to make gazillions i= n royalties from Cisco. Even then as far as RPL is concerned, Cisco says th= ey will provide royalty-bearing licenses for "reasonable, non-discrimi= natory" terms. That would mean, I think, a) they won't say, get lo= st, no RPL license for you because you decided to sue, b) they won't ch= arge you anything special and provide a license at the same terms as others= . Is that correct, Dan ? I would think this is quite fair.

For all these reasons, I would support moving forward with the RPL draf= t.

Regards,
Anand.
--00504502bd95fe3666047fd062a2-- From adam@sics.se Wed Feb 17 12:38:24 2010 Return-Path: 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 D0F753A7F18; Wed, 17 Feb 2010 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35] 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 Mjn+GheK3YLF; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 84C703A7F14; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from [10.1.1.143] (unknown [10.1.1.143]) by letter.sics.se (Postfix) with ESMTPS id C801440103; Wed, 17 Feb 2010 21:40:01 +0100 (CET) Message-ID: <4B7C534B.1050404@sics.se> Date: Wed, 17 Feb 2010 21:36:27 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Roll] ACM HotEmNets: deadline extended, paper submission open X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 20:38:24 -0000 The paper submission deadline for HotEmNets 2010 has been extended due to several requests: New deadline: 1 March 2010 Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Attendance to HotEmNets 2010 will be by invitation only, but everyone is encouraged to submit papers. Authors of accepted papers, TPC and SC members as well as other distinguished members of the community will be invited to enable a focused and productive discussion. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From dlang@cisco.com Wed Feb 17 15:59:35 2010 Return-Path: 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 C6D2F28C28A for ; Wed, 17 Feb 2010 15:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 v-18emwffI2y for ; Wed, 17 Feb 2010 15:59:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5A46028C2A3 for ; Wed, 17 Feb 2010 15:59:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,494,1262563200"; d="scan'208,217";a="152870029" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2010 00:01:00 +0000 Received: from dhcp-171-71-102-255.cisco.com (dhcp-171-71-102-255.cisco.com [171.71.102.255]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1I010A0026935; Thu, 18 Feb 2010 00:01:00 GMT Message-Id: From: Dan Lang To: roll@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-67-381252016 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Feb 2010 16:01:00 -0800 X-Mailer: Apple Mail (2.936) Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 23:59:35 -0000 --Apple-Mail-67-381252016 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Anand: In response to your item 7, the answer is basically yes. Some =20 entities have IPR statements that merely revoke their licensing =20 commitments when sued, leaving open the possibility that those =20 entities might not license their essential patents to the suing party =20= on *any* terms. In contrast, Cisco=92s statement makes a royalty-=20 bearing license to its essential patents available to anyone who =20 prefers that option =96 even if that person has sued Cisco. The terms =20= of that royalty-bearing license would be consistent with our overall =20 commitment to license on =93reasonable, non-discriminatory terms.=94 As a general note to the mailer, I am aware that I have not =20 specifically addressed each question that has been directed to me in =20 the last few days. In some cases, this is because I feel that I =20 shouldn't inadvertently give you legal advice by further interpreting =20= my previous statements. Best regards, Dan Dan Lang DIrector, Intellectual Property Cisco Systems, Inc. --Apple-Mail-67-381252016 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi Anand:
 
In response to your item 7, = the answer is basically yes.  Some entities have IPR statements = that merely revoke their licensing commitments when sued, leaving open = the possibility that those entities might not license their essential = patents to the suing party on *any* terms.  In contrast, = Cisco=92s statement makes a royalty-bearing license to its essential = patents available to anyone who prefers that option =96 even if that = person has sued Cisco.  The terms of that royalty-bearing license = would be consistent with our overall commitment to license on = =93reasonable, non-discriminatory = terms.=94 

As a general note to the mailer, I am aware that I = have not specifically addressed each question that has been directed to = me in the last few days.  In some cases, this is because I feel = that I shouldn't inadvertently give you legal advice by further = interpreting my previous statements.
 
Best = regards,
 
Dan

Dan Lang
DIrector, Intellectual Property
Cisco Systems, = Inc.

= --Apple-Mail-67-381252016-- From emmanuel.baccelli@gmail.com Thu Feb 18 00:18:16 2010 Return-Path: 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 DDBE728C160 for ; Thu, 18 Feb 2010 00:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 4B+cJAM95LU7 for ; Thu, 18 Feb 2010 00:18:15 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 6C51A28C15C for ; Thu, 18 Feb 2010 00:18:15 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1426346eyd.51 for ; Thu, 18 Feb 2010 00:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=6qVMhJ3x6/joiTRWzJZxfjAGVT/SxU/yWDc0DNkHmYo=; b=ifvFWyxRsnAzMbs3T5l+/whEfK2cbOk0povbcOStoZamvRzFKHgUEW2wJJr3a4x1zn O1DdRSNSIPQw1e6yoxPP2yUiUwTyJZ1GN2pEUhE4lz6aE64fOGqfGWx5xM2hCKIpq8um H4ovkGV5VlorxHs0euquQTmbP9ThAlYWWXRLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=ryCeG2e5acnjD/NA+ryI65kwfszPsYiStVlnqsW0ySco0lIbwKLDDHje67Oh0/tZ3Z UQ9XhgM/luoI0ZOpGW+xBlsn16sIGzlSZFPwKguRDsmE0RjOFV7B6Zi/SGDLlE+xzPLn SVCHCsMkkLoHTP4H6LVFxIBCQc0dpRULJhiI8= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.23.206 with SMTP id s14mr3722485ebb.77.1266481193254; Thu, 18 Feb 2010 00:19:53 -0800 (PST) In-Reply-To: <4B796581.5040707@us.fujitsu.com> References: <4B796581.5040707@us.fujitsu.com> From: Emmanuel Baccelli Date: Thu, 18 Feb 2010 09:19:33 +0100 X-Google-Sender-Auth: d9069927da756fa6 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=000e0cdfc542a381a9047fdba1b9 Subject: Re: [Roll] IPR ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 08:18:17 -0000 --000e0cdfc542a381a9047fdba1b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, can you please answer the question below? I think it is important that this is clear to everyone. Thanks, Emmanuel On Mon, Feb 15, 2010 at 4:17 PM, Sung Lee wrote: > Dear Dan, > > I am checking with our legal team on this issue. > Meanwhile, could you please answer one yes-no question for me? > That would help me understand the situation better. > > Is this following scenario true? > Scenario: > - My company implements and sells products with RPL with essentially a > loyal-free term. > - Cisco does something that infringes on my company's patents > (completely unrelated to RPL or not even in smart grid domain). > - When my company decides to sue, then my company would have to pay for > a license on RPL. > > The key point in this hypothetical scenario is that Cisco infringes on > our patents NOT related to RPL. > Following the conversation on Cisco IPR issue so far, my understanding > is YES. > But I would like to hear it from you. > > Thank you and best regards, > Sung > > > > > In addition to responding to Ruben, I'd like to comment on a couple > > of other points that have been raised. One commenter worried that > > they will =93be forced to use RPL and pay Cisco royalties because > > Smart Energy 2.0 is specifying RPL as their routing protocol=94 > > (http://www.ietf.org/mail-archive/web/roll/current/msg03008.html); > > another asked if Cisco would be =93willing to provide a royalty-free > > license to their patents=94 > > (http://www.ietf.org/mail-archive/web/roll/current/msg03015.html). > > Again, you should consult with your own legal counsel, but Cisco=92s > > statement will have the same practical effect to you as a royalty-free > > patent license. In essence, Cisco is promising not to sue you, > > and is not asking you to pay it any royalties, under any Cisco essentia= l > > patents, for any of your products that implement the RPL standard. > > As I mentioned before, this commitment may go away if you sue > > Cisco with your own patents. In that case, Cisco may ask you to > > pay for a license to its essential RPL patents on reasonable and > > non-discriminatory terms. > > > > Best regards, > > Dan > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000e0cdfc542a381a9047fdba1b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan,
can you please answer the question below? I think it is importa= nt that this is clear to everyone.
Thanks,
Emmanuel
=
On Mon, Feb 15, 2010 at 4:17 PM, Sung Lee <sung.lee@us.= fujitsu.com> wrote:
Dear Dan,

I am checking with our legal team on this issue.
Meanwhile, could you please answer one yes-no question for me?
That would help me understand the situation better.

Is this following scenario true?
Scenario:
- My company implements and sells products with RPL with essentially a
loyal-free term.
- Cisco does something that infringes on my company's patents
(completely unrelated to RPL or not even in smart grid domain).
- When my company decides to sue, then my company would have to pay for
a license on RPL.

The key point in this hypothetical scenario is that Cisco infringes on
our patents NOT related to RPL.
Following the conversation on Cisco IPR issue so far, my understanding
is YES.
But I would like to hear it from you.

Thank you and best regards,
Sung



> In addition to responding to Ruben, I'd like to comment on a coupl= e
> of other points that have been raised. One commenter worried that
> they will =93be forced to use RPL and pay Cisco royalties because
> Smart Energy 2.0 is specifying RPL as their routing protocol=94
> (http://www.ietf.org/mail-archive/web/roll/current/= msg03008.html);
> another asked if Cisco would be =93willing to provide a royalty-free > license to their patents=94
> (http://www.ietf.org/mail-archive/web/roll/current/= msg03015.html).
> Again, you should consult with your own legal counsel, but Cisco=92s > statement will have the same practical effect to you as a royalty-free=
> patent license. In essence, Cisco is promising not to sue you,
> and is not asking you to pay it any royalties, under any Cisco essenti= al
> patents, for any of your products that implement the RPL standard.
> As I mentioned before, this commitment may go away if you sue
> Cisco with your own patents. In that case, Cisco may ask you to
> pay for a license to its essential RPL patents on reasonable and
> non-discriminatory terms.
>
> Best regards,
> Dan
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--000e0cdfc542a381a9047fdba1b9-- From alexandru.petrescu@gmail.com Thu Feb 18 00:42:11 2010 Return-Path: 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 6A4E528C1CF for ; Thu, 18 Feb 2010 00:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 zOCgz0B-umrP for ; Thu, 18 Feb 2010 00:42:10 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 73C6728C17A for ; Thu, 18 Feb 2010 00:42:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1I8hoDL020506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Feb 2010 09:43:51 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1I8ho3G007442 for ; Thu, 18 Feb 2010 09:43:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1I8hnhk016724 for ; Thu, 18 Feb 2010 09:43:50 +0100 Message-ID: <4B7CFDC5.6030703@gmail.com> Date: Thu, 18 Feb 2010 09:43:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ROLL WG Content-Type: multipart/mixed; boundary="------------050205030202000904030102" Subject: [Roll] Fwd: I-D Action:draft-sreek-powerconsumption-mib-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 08:42:11 -0000 This is a multi-part message in MIME format. --------------050205030202000904030102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit (licensing apart, because it's incorrect from all standpoints). Hi RoLLers, I have just seen this draft (I'm not author) on IETF Announce list and I believe it maybe relevant to our energy metrics discussions. For example it mentions a MIB definition to be "Energy Consumption measured in watts"; we discussed earlier (I hope publicly, not only privately) about the same being in Joules. I will follow this draft. Alex -------- Message original -------- Sujet: I-D Action:draft-sreek-powerconsumption-mib-01.txt Date : Wed, 17 Feb 2010 23:15:01 -0800 (PST) De : Internet-Drafts@ietf.org Répondre à : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIB for Energy, Efficiency, Throughput and Carbon Emission Author(s) : S. Sasidharan, et al. Filename : draft-sreek-powerconsumption-mib-01.txt Pages : 11 Date : 2010-01-29 This document defines a portion of Management Information Base (MIB) for the Energy consumption, Throughput, Efficiency and Carbon emission in a Network Element. Energy,Throughput and Efficiency are required to calculate the carbon emission of the network element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sreek-powerconsumption-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------050205030202000904030102 Content-Type: Message/External-body; name="draft-sreek-powerconsumption-mib-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-sreek-powerconsumption-mib-01.txt" Content-Type: text/plain Content-ID: <2010-02-17230106.I-D@ietf.org> --------------050205030202000904030102 Content-Type: text/plain; name="Portion de message jointe" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Portion de message jointe" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050205030202000904030102-- From pthubert@cisco.com Thu Feb 18 01:40:56 2010 Return-Path: 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 720AB28C0D7 for ; Thu, 18 Feb 2010 01:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.704 X-Spam-Level: X-Spam-Status: No, score=-9.704 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5TBzBs7gTxwT for ; Thu, 18 Feb 2010 01:40:55 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AEF943A7F56 for ; Thu, 18 Feb 2010 01:40:55 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK6afEutJV2d/2dsb2JhbACDBZccZnSlc4gXj22BMIJSZAQ X-IronPort-AV: E=Sophos;i="4.49,496,1262563200"; d="scan'208";a="300404503" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2010 09:42:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o1I9gLdg002660 for ; Thu, 18 Feb 2010 09:42:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 10:42:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Feb 2010 10:42:24 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0141C98E@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-of0-01 Thread-Index: Acqwfm1ENvaLpeMsQX6grNEjBe6wIwAABIZw From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 18 Feb 2010 09:42:28.0012 (UTC) FILETIME=[AEE56EC0:01CAB07E] Subject: [Roll] FW: New Version Notification for draft-ietf-roll-of0-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 09:40:56 -0000 SGk6DQoNClRoZSBsYXRlc3QgcmVsZWFzZSBvZiBSUEwgbm93IGhhcyB0aGUgUmFuayBleHByZXNz ZWQgYXMgMiBvY3RldHMuIEkgcHVibGlzaGVkIGEgc2xpZ2h0IHVwZGF0ZSBvZiBPRjAgdG8gbWFr ZSBpdCBjb25zaXN0ZW50IHdpdGggdGhhdCBuZXcgZm9ybWF0Lg0KDQpDaGVlcnMsDQoNClBhc2Nh bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lv biBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAxOCwgMjAxMCAxMDozOSBBTQ0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkN ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLW9m MC0wMSANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1yb2xsLW9mMC0wMS50 eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLXJv bGwtb2YwDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBSUEwgT2JqZWN0aXZlIEZ1bmN0aW9uIDAN CkNyZWF0aW9uX2RhdGU6CSAyMDEwLTAyLTE4DQpXRyBJRDoJCSByb2xsDQpOdW1iZXJfb2ZfcGFn ZXM6IDgNCg0KQWJzdHJhY3Q6DQpUaGUgUm91dGluZyBQcm90b2NvbCBmb3IgTG93IFBvd2VyIGFu ZCBMb3NzeSBOZXR3b3JrcyAoUlBMKSBkZWZpbmVzIGEgZ2VuZXJpYyBEaXN0YW5jZSBWZWN0b3Ig cHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKExMTnMpLiAgUlBMIGlz IGluc3RhbnRpYXRlZCB0byBob25vciBhIHBhcnRpY3VsYXIgcm91dGluZyBvYmplY3RpdmUvIGNv bnN0cmFpbnQgYnkgdGhlIGFkZGluZyBhIHNwZWNpZmljIE9iamVjdGl2ZSBGdW5jdGlvbiAoT0Yp IHRoYXQgaXMgZGVzaWduZWQgdG8gc29sdmUgdGhhdCBwcm9ibGVtLiAgVGhpcyBzcGVjaWZpY2F0 aW9uIGRlZmluZXMgYSBiYXNpYyBPRiwgT0YwLCB0aGF0IHVzZXMgb25seSB0aGUgYWJzdHJhY3Qg cHJvcGVydGllcyBleHBvc2VkIGluIFJQTCBtZXNzYWdlcyB0byBtYXhpbWl6ZSBjb25uZWN0aXZp dHkuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQu DQoNCg0K From root@core3.amsl.com Thu Feb 18 01:45:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E2DB43A7AC4; Thu, 18 Feb 2010 01:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100218094501.E2DB43A7AC4@core3.amsl.com> Date: Thu, 18 Feb 2010 01:45:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 09:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-01.txt Pages : 8 Date : 2010-02-18 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages to maximize connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-of0-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-18013847.I-D@ietf.org> --NextPart-- From stoleru@cse.tamu.edu Tue Feb 16 13:10:46 2010 Return-Path: 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 844673A6F88 for ; Tue, 16 Feb 2010 13:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2xN083UmP4+9 for ; Tue, 16 Feb 2010 13:10:37 -0800 (PST) Received: from smtp.cs.tamu.edu (smtp.cs.tamu.edu [128.194.138.107]) by core3.amsl.com (Postfix) with ESMTP id A6E033A7CB7 for ; Tue, 16 Feb 2010 13:10:31 -0800 (PST) Received: from [128.194.143.109] (stoleru-tp.cs.tamu.edu [128.194.143.109]) by smtp.cs.tamu.edu (Postfix) with ESMTP id 2E442190634 for ; Tue, 16 Feb 2010 15:12:07 -0600 (CST) Message-ID: <4B7B0A26.4050207@cse.tamu.edu> Date: Tue, 16 Feb 2010 15:12:06 -0600 From: Radu Stoleru User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Feb 2010 08:03:51 -0800 Subject: [Roll] SenSys 2010 - Call for Papers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 21:12:10 -0000 [Please accept our apologies if you receive multiple copies of this posting] ===================================================================== C A L L F O R P A P E R S **** ACM SenSys 2010 **** Zurich, Switzerland November 3-5, 2010 http://sensys.acm.org/2010 SenSys 2010, the 8th ACM Conference on Embedded Networked Sensor Systems, solicits innovative research papers on the systems issues of networked, embedded sensing and control. The conference brings together academic, industry, and government professionals to a premier single-track, highly selective forum on the design, implementation, and application of sensor networks. SenSys takes a broad view of sensor systems to include any distributed system that interacts with the physical world. We seek technical papers describing original ideas, groundbreaking results and/or quantified system experiences. * Topics of interest include, but are not limited to, the following: ------------------------------------------------------------------------ - Approaches to architecting sensor networks - Experience with real-world deployments and applications - Resource management and OS support for sensor systems - Energy management and harvesting for long-term operation - Wireless communication systems and protocols for sensor networks - Sensor network measurement and characterization - Programming paradigms and models for distributed sensing - Sensor network debugging, fault-tolerance and reliability - Sensing, actuation and control in cyber-physical systems - Sensor systems leveraging mobile phones, RFIDs, robots, etc. - Distributed sensor data storage, retrieval, processing and management - Sensor data quality, integrity, and trustworthiness - In-network data reduction, coding, inference, and signal processing - Security and privacy in sensor networks - Time and location management - Social implications and human-sensor interactions ------------------------------------------------------------------------ Submissions will be subject to rigorous peer review and the top quality papers will be published in the conference proceedings. All published papers will be presented orally at the conference. * Submission: Submissions must be full papers, at most 14 single-spaced 8.5" x 11" pages, including figures, tables, and references, two-column format, using 10-point type on 12-point (single-spaced) leading, with a maximum text block of 7" wide x 9" deep with .25" intercolumn space. Papers that do not meet the size and formatting requirements will not be reviewed. * Key Dates: ----------------------------------------------------------------------- - Paper Registration and Abstract: April 1, 2010, 11:59 pm EST. - Paper Submission Deadline: April 8, 2010, 11:59 pm EST. - Notification of Paper Acceptance: July 20, 2010. ----------------------------------------------------------------------- These are "hard deadlines" - no extensions will be granted. * General Chair Jan Beutel (ETH Zurich) * Steering Committee Chair Matt Welsh (Harvard University) * Program Committee Co-Chairs Deepak Ganesan (UMass Amherst) John Stankovic (University of Virginia) * Technical Program Committee Anish Arora (Ohio State University) Alberto Cerpa (UC Merced) Tanzeem Choudhary (Dartmouth University) Romit Roy Choudhury (Duke University) David Culler (UC Berkeley) Phil Gibbons (Intel Research Pittsburgh) Rick Han (University of Colorado Boulder) Tian He (University of Minnesota) Polly Huang (National Taiwan University) Bhaskar Krishnamachari (University of Southern California) Koen Langendoen (TU Delft) Akos Ledeczi (Vanderbilt University) Suman Nath (Microsoft Research) Raj Rajkumar (Carnegie Mellon University) Umakishore Ramachandran (Georgia Tech) Krithi Ramamritham (IIT Bombay) Kay Roemer (University of Lubeck and ETH Zurich) Andreas Savvides (Yale University) Jacky Shen (Microsoft Research Asia) Prashant Shenoy (UMass Amherst) Cormac Sreenan (University College Cork) Kamin Whitehouse (University of Virginia) Adam Wolisz (TU Berlin) ======================================================== From joakime@sics.se Thu Feb 18 09:19:11 2010 Return-Path: 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 045F93A7FC3 for ; Thu, 18 Feb 2010 09:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 htMvCrwkWNDZ for ; Thu, 18 Feb 2010 09:19:10 -0800 (PST) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by core3.amsl.com (Postfix) with ESMTP id E70B73A7FC1 for ; Thu, 18 Feb 2010 09:19:09 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy1.bredband.net (7.3.140.3) id 4B62ECEA00CB360A for roll@ietf.org; Thu, 18 Feb 2010 18:20:52 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAcAFIFfUtV5BCGPGdsb2JhbAAHh1KTOQEBAQE3vX+EZwQ X-IronPort-AV: E=Sophos;i="4.49,498,1262559600"; d="scan'208";a="39116543" Received: from c-8610e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [192.168.1.144]) ([85.228.16.134]) by ipb1.telenor.se with ESMTP; 18 Feb 2010 18:20:52 +0100 Message-ID: <4B7D76FC.6000108@sics.se> Date: Thu, 18 Feb 2010 18:21:00 +0100 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] When to reset the Trickle timer? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 17:19:11 -0000 Hello, First a technical question: While I was studying our RPL implementation on a small network I saw that the root node was resetting its Trickle timer many timer before it got to send a single message. This behavior is caused when many nodes starts simultaneously and starts sending DIS messages (multicase). The root receives these messages and resets its Trickle timer each time. It seems like it resets more than 10 times before getting a message sent. One very simple solution would be to avoid resetting the timer if it is already at its lowest interval and did not yet trigger T. Possibly with the addition that it also should reset its C to ensure that any packet that was sent by someone else before the DIS request is ignored. Then a textual/readability statement: The new rpl-06 specification is much easier to read, but there are still things that can be confusing, such as: 5.3.5: - reset the interval of the trickle timer to its minimum value - reset the trickle timer to its minimum value - reset the trickle timer It is easy to get a feeling that there are multiple ways of resetting the trickle timer. I would suggest only saying "reset the trickle timer" everywhere except in the section describing the way to reset the timer (5.3.5.1.1). Best regards, -- Joakim Eriksson, SICS From jhui@archrock.com Thu Feb 18 09:39:04 2010 Return-Path: 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 3D2E228C2CA for ; Thu, 18 Feb 2010 09:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 t8MVbJ6+4Fbk for ; Thu, 18 Feb 2010 09:39:03 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7F1DE28C296 for ; Thu, 18 Feb 2010 09:39:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CE66CAF95B; Thu, 18 Feb 2010 09:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXoV8JRl1zpx; Thu, 18 Feb 2010 09:40:43 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id DA283AF845; Thu, 18 Feb 2010 09:40:42 -0800 (PST) Message-Id: <5341F703-488A-4DC7-ABB7-BF29058DF9E6@archrock.com> From: Jonathan Hui To: Joakim Eriksson In-Reply-To: <4B7D76FC.6000108@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Feb 2010 09:40:41 -0800 References: <4B7D76FC.6000108@sics.se> X-Mailer: Apple Mail (2.936) Cc: roll Subject: Re: [Roll] When to reset the Trickle timer? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 17:39:04 -0000 In general, we've found it best not to pick a new T if I is already at I_min, regardless of what the Trickle timer is driving. Resetting C doesn't have that much effect - little enough that it could be considered implementation dependent. But I agree that the text should be more clear about what it means to reset I. -- Jonathan Hui On Feb 18, 2010, at 9:21 AM, Joakim Eriksson wrote: > Hello, > > First a technical question: > > While I was studying our RPL implementation on a small network > I saw that the root node was resetting its Trickle timer many > timer before it got to send a single message. > > This behavior is caused when many nodes starts simultaneously > and starts sending DIS messages (multicase). The root receives > these messages and resets its Trickle timer each time. It seems > like it resets more than 10 times before getting a message sent. > > One very simple solution would be to avoid resetting the timer if > it is already at its lowest interval and did not yet trigger T. > Possibly with the addition that it also should reset its C to > ensure that any packet that was sent by someone else before the > DIS request is ignored. > > > > Then a textual/readability statement: > > The new rpl-06 specification is much easier to read, but there are > still things that can be confusing, such as: > 5.3.5: > - reset the interval of the trickle timer to its minimum value > - reset the trickle timer to its minimum value > - reset the trickle timer > > It is easy to get a feeling that there are multiple ways of resetting > the trickle timer. > > I would suggest only saying "reset the trickle timer" everywhere > except > in the section describing the way to reset the timer (5.3.5.1.1). > > > Best regards, > -- Joakim Eriksson, SICS > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Thu Feb 18 10:18:12 2010 Return-Path: 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 A4D013A7FE2 for ; Thu, 18 Feb 2010 10:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BGcFTEaTqSSq for ; Thu, 18 Feb 2010 10:18:11 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id DDB9B28C2EC for ; Thu, 18 Feb 2010 10:18:10 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id p33so247793gvf.15 for ; Thu, 18 Feb 2010 10:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :subject:date:message-id:to:mime-version:x-mailer; bh=QLpNjp1PubsJdvk8RWee9yt0EOOi5QrBvWIiM6NLMiM=; b=ZG1vVL0xrjaaT9foA9oersyCKW3sdgS5wu6Xj3s1vebqDDOgZfPdGsiawSMyiF8ggj +4JB1crtAYNKNiP7+hnN+xG0M6mnVb23+3HpnwK4YqkdPVTn6echtt6bl78V+bw597Vz FMmIkQk7eMLW200CenSeG9voD2POnxU5DG4/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; b=FNAw015OcEQsrti2morVjp9qWjheI72NfeUmBBykb7bpGQ710pLATxz0UDdzaquHra 6IlKk4jKVr1rJKNrcZiP6CG4BFIcfEWI4iqE5acC9p0HoLiR4hRt+Eka3HmOUMKpkYb0 cEdOIfrVYV7/gqgwm8OhBTTDjBVKCNyx8j8rY= Received: by 10.103.81.5 with SMTP id i5mr7206271mul.29.1266517190627; Thu, 18 Feb 2010 10:19:50 -0800 (PST) Received: from dnab40466a.stanford.edu (DNab40466a.Stanford.EDU [171.64.70.106]) by mx.google.com with ESMTPS id j2sm13354623mue.2.2010.02.18.10.19.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 10:19:48 -0800 (PST) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: multipart/alternative; boundary=Apple-Mail-1027-447175036 Date: Thu, 18 Feb 2010 10:19:43 -0800 Message-Id: <900A64E3-7C29-4587-962D-C55BB09CD380@cs.jhu.edu> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] Writing SenderRank in flow label. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 18:18:12 -0000 --Apple-Mail-1027-447175036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! I see an issue with how the usage of the flow label is specified in = Section 7.2. Section 7.2.1 of the rpl draft v6 states the following, " A = packet that is sourced at a node connected to a RPL network or destined = to a node connected to a RPL network MUST be issued with the flow label = zeroed out, but for the RPLInstanceID field." However, the details in 7.2 and also intuitively, the SenderRank should = also be set when the packet is issued at the source node and modified as = the packet passes router nodes in the RPL network. When the SenderRank = is set as zero (as what the draft states) the first router that receives = this message can notice that it is the first hop of the packet's = forwarding process (since the SenderRank is set to zero and no such rank = should exist, given that the rank of the DODAG root is 1) and proceed = the forwarding process, but it will not be able to check if this = forwarding process is valid or not (procedures specified in Sections = 7.2.2.*). I agree that this breaks the compliance with RFC 3697 that = Section 7.2.2.1 discusses (since it is difficult to know what the = initial senderRank was) but I still think we would need the sender rank = in place when the packet is initially issued, at least for the sake of = consistency. Given that RPL's modification of the flow label becomes = tricky when packets from 'outer-RPL' networks flow in to RPL networks = (it is hard to know what the original flow label was after modifications = within the RPL network), I think we should start thinking of ways to = break out of the flow label field and configure a new header format = maybe :) Thanks. -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko --Apple-Mail-1027-447175036 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi!

I see an issue = with how the usage of the flow label is specified in Section 7.2. = Section 7.2.1 of the rpl draft v6 states the following, " A packet that is sourced at a node connected = to a RPL network or destined to a node connected to a RPL network MUST = be issued with the flow label zeroed out, but for the RPLInstanceID = field."

However, the details in 7.2 and also intuitively, the SenderRank = should also be set when the packet is issued at the source node and = modified as the packet passes router nodes in the RPL network. When = the SenderRank is set as zero (as what the draft states) the first = router that receives this message can notice that it is the first hop of = the packet's forwarding process (since the SenderRank is set to zero and = no such rank should exist, given that the rank of the DODAG root is 1) = and proceed the forwarding process, but it will not be able to check if = this forwarding process is valid or not (procedures specified in = Sections 7.2.2.*). I agree that this breaks the compliance with RFC 3697 = that Section 7.2.2.1 discusses (since it is difficult to know what the = initial senderRank was) but I still think we would need the sender rank = in place when the packet is initially issued, at least for the sake of = consistency. Given that RPL's modification of the flow label becomes = tricky when packets from 'outer-RPL' networks flow in to RPL networks = (it is hard to know what the original flow label was after modifications = within the RPL network), I think we should start thinking of ways to = break out of the flow label field and configure a new header format = maybe :)

Thanks.

-John

------
JeongGil Ko = (John)
Ph.D. Student
Department of = Computer Science
Johns Hopkins = University
<= font class=3D"Apple-style-span" face=3D"Arial" size=3D"3">

= --Apple-Mail-1027-447175036-- From jhui@archrock.com Thu Feb 18 10:30:36 2010 Return-Path: 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 D98A83A7FE7 for ; Thu, 18 Feb 2010 10:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NeaTVLpdP19o for ; Thu, 18 Feb 2010 10:30:35 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 95A123A7FF5 for ; Thu, 18 Feb 2010 10:30:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E41E6AF846; Thu, 18 Feb 2010 10:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA5SJyGmZPPD; Thu, 18 Feb 2010 10:32:14 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 8E58FAF842; Thu, 18 Feb 2010 10:32:14 -0800 (PST) Message-Id: <2A2085EA-DCB1-46EE-A847-9901174B9B31@archrock.com> From: Jonathan Hui To: JeongGil Ko (John) In-Reply-To: <900A64E3-7C29-4587-962D-C55BB09CD380@cs.jhu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Feb 2010 10:32:13 -0800 References: <900A64E3-7C29-4587-962D-C55BB09CD380@cs.jhu.edu> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Writing SenderRank in flow label. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 18:30:36 -0000 Hi John, We cannot assume that the source and/or destination node is running RPL, let alone having some information about the Rank of it's attachment router. Also, when receiving a packet from the source node or delivering a packet to the destination node, no loops occur since you know you're one end of the path. Loops only occur among forwarding routers and only they must be concerned with setting the appropriate data-path fields necessary for loop-detection/recovery. Of course, if the source/destination is a RPL router, then the node *could* set the fields appropriately and maybe the text should be changed to allow this. As for where to carry the bits, we are currently investigating other options (in addition to the flow label). They all have their pros/cons. -- Jonathan Hui On Feb 18, 2010, at 10:19 AM, JeongGil Ko (John) wrote: > Hi! > > I see an issue with how the usage of the flow label is specified in > Section 7.2. Section 7.2.1 of the rpl draft v6 states the following, > " A packet that is sourced at a node connected to a RPL network or > destined to a node connected to a RPL network MUST be issued with > the flow label zeroed out, but for the RPLInstanceID field." > > However, the details in 7.2 and also intuitively, the SenderRank > should also be set when the packet is issued at the source node and > modified as the packet passes router nodes in the RPL network. When > the SenderRank is set as zero (as what the draft states) the first > router that receives this message can notice that it is the first > hop of the packet's forwarding process (since the SenderRank is set > to zero and no such rank should exist, given that the rank of the > DODAG root is 1) and proceed the forwarding process, but it will not > be able to check if this forwarding process is valid or not > (procedures specified in Sections 7.2.2.*). I agree that this breaks > the compliance with RFC 3697 that Section 7.2.2.1 discusses (since > it is difficult to know what the initial senderRank was) but I still > think we would need the sender rank in place when the packet is > initially issued, at least for the sake of consistency. Given that > RPL's modification of the flow label becomes tricky when packets > from 'outer-RPL' networks flow in to RPL networks (it is hard to > know what the original flow label was after modifications within the > RPL network), I think we should start thinking of ways to break out > of the flow label field and configure a new header format maybe :) > > Thanks. > > -John > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Thu Feb 18 20:06:24 2010 Return-Path: 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 5AEB53A8098 for ; Thu, 18 Feb 2010 20:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 V0gAd6cMX+p8 for ; Thu, 18 Feb 2010 20:06:23 -0800 (PST) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 410513A8094 for ; Thu, 18 Feb 2010 20:06:23 -0800 (PST) Received: by ywh3 with SMTP id 3so2020789ywh.31 for ; Thu, 18 Feb 2010 20:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=mu+r4gRPezOxoxLXoStDwRKdeLZQWYPSO4aIEtve9uY=; b=Z6u0ivRKfm4Ak6pv2PqsBFx3qEc9nhNT/cSgpgGKxpEQgK3de5XleBt4EShEqsuNXk WPLLFSYtJeN5oMtWoNhfBbEbOE81iy2rZgPuJfSBIY3M6Gbo7EpUEUYjaqYmoU54aXxq Pva0ew6i+mGh4vew4/7PLYAiinut+OoRLKdpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=ujei47bH44LRT1FcCz2s3/yY76gK6wLO69Ev1J49TpeuVNasRMAWdUe5Pa3NAJjuKP IVy9MqNZmSB9M7KbgfPVABvXILt5uGM25mDP4JEELpTT/QgaedCWTD1YzAq09YaD0qSu pFP4YtFzWVW8p2EfAk+517H3mlPz/QZhsv+7k= Received: by 10.151.3.3 with SMTP id f3mr822898ybi.336.1266552484739; Thu, 18 Feb 2010 20:08:04 -0800 (PST) Received: from dnab40466a.stanford.edu (DNab40466a.Stanford.EDU [171.64.70.106]) by mx.google.com with ESMTPS id 22sm708041ywh.46.2010.02.18.20.08.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 20:08:04 -0800 (PST) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 20:08:01 -0800 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] Selecting from multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 04:06:24 -0000 Hi! Thanks Jonathan for the previous clarification :) I have another = question that came up during the implementation process. When a RPL node = selects a DODAG between multiple DODAGs, the draft specifies that the = RPL node should select the DODAG that has higher preference or a DODAG = that advertises OFs that the RPL node understands. However, consider the = case where there are two DODAGs with the same preference and both = advertising OFs that the RPL node understands. In such case, is it = correct to assume that the node will select 'any' DODAG to connect to = (e.g., the DODAG that will result in a lower rank)? Or is there another = criteria in the DODAG selection process that I am missing? Thanks! -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jhui@archrock.com Fri Feb 19 00:08:15 2010 Return-Path: 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 801753A80D3 for ; Fri, 19 Feb 2010 00:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 SfXDw4QT61N6 for ; Fri, 19 Feb 2010 00:08:14 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8AC123A7851 for ; Fri, 19 Feb 2010 00:08:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6AFEEAF9AD; Fri, 19 Feb 2010 00:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N6syrTJa05I; Fri, 19 Feb 2010 00:09:56 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id 897EAAF846; Fri, 19 Feb 2010 00:09:56 -0800 (PST) Message-Id: <9D7ED099-49D2-45FD-9896-9B153014F0B1@archrock.com> From: Jonathan Hui To: JeongGil Ko (John) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 00:09:55 -0800 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Selecting from multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 08:08:15 -0000 Hi John, All things being equal, a node that must choose between different DODAGs can choose whatever DODAG it likes. Of course, other things can affect what DODAG a node joins (e.g. grounded vs. not grounded, same OFs advertising different metric values, any dwell timing used when jumping between different DODAGs, etc.), some of which may be implementation dependent. -- Jonathan Hui On Feb 18, 2010, at 8:08 PM, JeongGil Ko (John) wrote: > Hi! > > Thanks Jonathan for the previous clarification :) I have another > question that came up during the implementation process. When a RPL > node selects a DODAG between multiple DODAGs, the draft specifies > that the RPL node should select the DODAG that has higher preference > or a DODAG that advertises OFs that the RPL node understands. > However, consider the case where there are two DODAGs with the same > preference and both advertising OFs that the RPL node understands. > In such case, is it correct to assume that the node will select > 'any' DODAG to connect to (e.g., the DODAG that will result in a > lower rank)? Or is there another criteria in the DODAG selection > process that I am missing? > > Thanks! > > -John > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mijeom@gmail.com Fri Feb 19 00:48:11 2010 Return-Path: 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 943F028C228 for ; Fri, 19 Feb 2010 00:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 B-L5-lJtU5w5 for ; Fri, 19 Feb 2010 00:48:10 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id A2E8D28C227 for ; Fri, 19 Feb 2010 00:48:10 -0800 (PST) Received: by pzk4 with SMTP id 4so3866309pzk.5 for ; Fri, 19 Feb 2010 00:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P5KLyff5ASp5JaHFNwaF7NJpQnoQ0f4WBkkCyBiH1Ak=; b=kNvb7qWd7kAIBMc5cbQVxPkCajDV8N1rX/kAtxX4zmYgBvq+GHtSy2fi6dHafrL2vs Mbcy4c0xwgWrCSt4CcKNFJsU/E/jxgczwFhvtLUAFQbLtB51NnRmFwFPvdHus55VJ1ux slqEsqtoSXLH3wc2eCFGqF9dp8sIjZ1Bb9YFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Ap7q3UuEyzuWshs/TcMzhvpzXiZ4bjGmFgSeCSxcyG1sesVtt1cSU6l6JfubD0ClN8 seTVPN3ykthdLzrOAOVuszX13oa7GKswmkIRMIV5fNaJAvRMQcZoZ9iIu9nqG4EasvG0 4cR0m+gL6cqbccDk16YxJDNYm6MgQpD1A5T/o= MIME-Version: 1.0 Received: by 10.143.153.30 with SMTP id f30mr38990wfo.281.1266569394080; Fri, 19 Feb 2010 00:49:54 -0800 (PST) In-Reply-To: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> Date: Fri, 19 Feb 2010 17:49:54 +0900 Message-ID: From: MiJeom Kim To: roll@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 08:48:11 -0000 Hi, all, It's time to close on the #18. I think that throughput and latency can be better presented by unsigned integers as the below justification wrote. Latency can be expressed in units of milliseconds and throughput can be expressed in bytes per second. If you don't have any objection, let me close it. Please send me your comments on the issue. Thanks, Mijeom. On Sun, Nov 15, 2009 at 7:30 PM, roll issue tracker w= rote: > #18: Numeric Ranges in Routing Metric > --------------------------------+----------------------------------------= --- > =A0Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: = =A0jpv@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: > Component: =A0routing-metrics =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0Active WG Document =A0| =A0 =A0Keywords: > --------------------------------+----------------------------------------= --- > =A0This ticket is related to the Numeric Ranges in Routing Metric. > > =A0Here is the original thread: > > =A0I mentioned it during the roll meeting Tuesday, but I think it's proba= bly > =A0worth documenting the thought in a little more technical detail. =A0Th= e > =A0routing metrics right now include 32-bit floating point numbers for > =A0latency and throughput. =A0Since these numbers are much more likely to= be > =A0added or compared rather than multiplied, fixed point rather than floa= ting > =A0point is likely to be a better choice of representation. =A0For exampl= e, for > =A0normalized positive 32-bit IEEE 754 numbers, the maximum number is abo= ut > =A03.4e38 and the minimum is about 1.2e-38. =A0For reference, the age of > =A0universe in milliseconds (taking the high end of NASA's most recent > =A0estimate) is only 4.4e20 and the time it takes to travel the distance > =A0across an electron (Lorentz diameter for you physics heads) is about > =A01.9e-20 ms. =A0A negative latency would seem to imply that packets app= ear > =A0before they're sent which is probably not practical. =A0If instead, la= tency > =A0were a 32-bit unsigned integer in units of milliseconds, we'd still be > =A0able to go from 0 or 1 milliseconds up to almost 1200 hours if my math= is > =A0right. =A0That should be plenty for any practical network. =A0I haven'= t done > =A0so but I suspect that we could do the same thing with throughput. > > -- > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mijeom@gmail.com Fri Feb 19 00:57:05 2010 Return-Path: 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 9CE053A80F4 for ; Fri, 19 Feb 2010 00:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 VBQ8BLkhoATS for ; Fri, 19 Feb 2010 00:57:04 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id D55D73A7F1E for ; Fri, 19 Feb 2010 00:57:04 -0800 (PST) Received: by pzk4 with SMTP id 4so3872208pzk.5 for ; Fri, 19 Feb 2010 00:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KEOgtnV4yRSd2r4vALjAQ/FlMqc7uGZoMccbmE02Jq8=; b=dr23shj77CtcLucCRjKiWkhtSlaML+GoViMteGQDfU+0dwF7JuepwmwItK24vkWJ3D u75TQP15QnvG/lVGybr4y3cEMabqxINRcfXrp4l+Kr5Bc9iPaj6qZ8GBJgqV8EBomCc/ uXDqcywkCTm2CHEMzh7h1xATBy8WjBXQMLzQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=nVL+xVYFsRbPAA32aKUF6R9j1RqvvR+zt2sWSKJHHcTbkbBrk2J/EzYvo3dvln6ga+ irHkWmr9BJSz01Hy0w/M609X6XnqayWfwUqbEWT6yG5ZanezW5LZQrPKrWkrqt0XRJU7 pN/itzKuOaLgbzqBNbbZib/XGEHBpR3tJgSV0= MIME-Version: 1.0 Received: by 10.142.151.22 with SMTP id y22mr1247030wfd.126.1266569927670; Fri, 19 Feb 2010 00:58:47 -0800 (PST) In-Reply-To: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> Date: Fri, 19 Feb 2010 17:58:47 +0900 Message-ID: From: MiJeom Kim To: roll@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 08:57:05 -0000 Hi, again, Now the #20. As I mentioned in #18, throughput and latency may be better expressed in unsigned integers. And I confirmed that there is no IEEE 8 bits floating point format. So encoding of ETX needs to be reconsidered. I think we may use 16 bits half precision IEEE 754 format or 8 bits unsigned integer. Any better idea? Please post your opinion to close on this issue soon. Thanks, Mijeom. On Thu, Dec 3, 2009 at 8:54 PM, roll issue tracker wr= ote: > #20: Question on Metric ID > --------------------------------+----------------------------------------= --- > =A0Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: = =A0mjkim@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: > Component: =A0routing-metrics =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0Active WG Document =A0| =A0 =A0Keywords: > --------------------------------+----------------------------------------= --- > =A0Question on the METRIC ID asked during IETF-76 > > =A0- Throughput and latency should be IEEE 32 floating point? > > =A0- =A0Is there IEEE 8 floating point format? > > -- > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Pete.Stpierre@Sun.COM Fri Feb 19 08:49:29 2010 Return-Path: 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 E6D4D3A8188 for ; Fri, 19 Feb 2010 08:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] 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 Z0nBvdhNJRqL for ; Fri, 19 Feb 2010 08:49:28 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id A900628C151 for ; Fri, 19 Feb 2010 08:49:28 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1JGpFMv012341 for ; Fri, 19 Feb 2010 08:51:15 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TyH2d1OqXl/jpTpwoweR6g)" Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY300G00L6MQL00@fe-sfbay-10.sun.com> for roll@ietf.org; Fri, 19 Feb 2010 08:51:15 -0800 (PST) Received: from [192.168.1.56] (99-57-137-67.lightspeed.sntcca.sbcglobal.net [99.57.137.67]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY3005OVLHEAYA0@fe-sfbay-10.sun.com>; Fri, 19 Feb 2010 08:51:14 -0800 (PST) Date: Fri, 19 Feb 2010 08:51:13 -0800 From: "Pete St. Pierre" In-reply-to: <1265383485.3502.29.camel@dellx1> Sender: Pete.Stpierre@Sun.COM To: ROLL WG Message-id: <1A411AA0-B174-49B3-901C-EE3DD53A8171@Sun.COM> X-Mailer: Apple Mail (2.1077) References: <1265383485.3502.29.camel@dellx1> Subject: Re: [Roll] Closing on the IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:49:30 -0000 --Boundary_(ID_TyH2d1OqXl/jpTpwoweR6g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT JP & fellow Roll'ers - Now that the important legal questions are being discussed on the proper lists, I would like to get back to understanding the technical aspects of what elements of ROLL are impacted by the IPR statements Cisco has made. More comments below... On Feb 5, 2010, at 7:24 AM, Geoff Mulligan wrote: > I am extremely concerned should we decide to proceed with > draft-ietf-roll-rpl in its current form. I agree with Pete and I second > the request from JP that Pascal indicate what portions of RPL are > covered by the Cisco IPR. There seems to be much reluctance for anyone to step forward with more specifics. However, I don't believe I have made an unreasonable request. BCP 79 specifically states, in the second 1/2 of section 6.4.1: "In addition, if the IETF Document includes multiple parts and it is not reasonably apparent which part of such IETF Document is alleged to be Covered by the IPR in question, it is helpful if the discloser identifies the sections of the IETF Document that are alleged to be so Covered." IMHO, given the number of people that have expressed their concerns to NOT move forward compared to those who have expressed a desire to move on, I think that there are issues here that are "not reasonably apparent" and clarification is in order. > > Until we know what portions of RPL are covered by the IPR and how > difficult it might be to "work around" the patents I dont know how to > proceed. To be clear -- I am not advocating that we "identify and eradicate". I would simply like to understand the potential IPR encumbrances and implications prior to agreeing to move forward. > > I do not think that Pascal should say that he doesn't know because > patent lawyers got involved. Pascal is the best person in the world to > show what is covered and what isn't. He is an author on the patents and > also part of the DT for RPL. No one else is. I agree with Geoff's assessment. I do NOT expect Pascal to attempt to interpret for us every claim made in the granted patents, since that is certainly better left in the realm of corporate legal staffs. As a named inventor on several patents, I understand that the claims made in a patent filing often greatly exceed that of the original embodiment from which the patent was drawn. However, I would expect that an inventor would recognize the element or elements of a design that, at a minimum, approximate the original embodiment that lead to patenting of the "invention". Given that there was a separate design team carved off of the roll WG to do the initial roll/RPL design, I do not think it is unreasonable to ask the named inventors or other members of the DT to provide some insight into the design elements that may be impacted by the IPR stated in this disclosure. To be clear -- I agree with Dan Lang's earlier comments. To paraphrase: If you want to be covered, each individual and their lawyers should do their homework. I believe what we want is to move forward in a confident, expedient manner, and there is information that can be provided to help that along. If we want to wait until each individual that has expressed a desire to "not move forward", has done their own evaluation, we will be "stuck in neutral" for a while. > > I feel that it is critically important that we not proceed with the > draft as it currently stands. I think that the current licensing terms > for the IPR are a show stopper. I think we've beaten this one to death for the moment and I would ask that any additional discussions on this topic continue on the appropriate IPR/ILT (aka non-roll) mailing lists. Best regards, ...Pete > > geoff > > > > > On Mon, 2010-02-01 at 14:57 +0100, JP Vasseur wrote: >> Dear all, >> >> >> Given the discussions about the IPR disclosure at >> https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy >> at http://www.ietf.org/ipr/policy.html I would like to make sure that >> the working group is happy to proceed with draft-ietf-roll-rpl in its >> current form. Please state your opinions on the list. I will make a >> consensus call on Friday 11 February. >> >> >> Thanks. >> >> >> JP. >> >> >> _______________________________________________ >> 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 --Boundary_(ID_TyH2d1OqXl/jpTpwoweR6g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE JP & fello= w Roll'ers -
Now that the important legal questions are being dis= cussed on the proper lists, I would like to get back to understanding= the technical aspects of what elements of ROLL are impacted by the I= PR statements Cisco has made.  More comments below...
=
On Feb 5, 2010, at 7:24 AM, Geoff Mulligan wrote:
=
I am extremely concerned should we decide to proceed with
draft-= ietf-roll-rpl in its current form.  I agree with Pete and I seco= nd
the request from JP that Pascal indicate what portions of RPL a= re
covered by the Cisco IPR.

= There seems to be much reluctance for anyone to step forward with mor= e specifics.  However, I don't believe I have made an unreasonab= le request.  BCP 79 specifically states, in the second 1/2 of se= ction 6.4.1:

"In addit= ion, if the IETF Document includes multiple parts and it is not reaso= nably apparent which part of such IETF Document is alleged to be Cove= red by the IPR in question, it is helpful if the discloser identifies= the sections of the IETF Document that are alleged to be so Covered.= "

IMHO, given the number of people th= at have expressed their concerns to NOT move forward compared to thos= e who have expressed a desire to move on, I think that there are issu= es here that are "not reasonably apparent" and clarification is in or= der.

Until we know what = portions of RPL are covered by the IPR and how
difficult it might = be to "work around" the patents I dont know how to
proceed.

To be clear -- I am not advocating tha= t we "identify and eradicate".  I would simply like to understan= d the potential IPR encumbrances and implications prior to agreeing t= o move forward.  

<= br>I do not think that Pascal should say that he doesn't know because=
patent lawyers got involved.  Pascal is the best person in t= he world to
show what is covered and what isn't.  He is an au= thor on the patents and
also part of the DT for RPL.  No one = else is.

I agree with Geoff's as= sessment.  I do NOT expect Pascal to attempt to interpret for us= every claim made in the granted patents, since that is certainly bet= ter left in the realm of corporate legal staffs. 

=
As a named inventor on several patents, I understand that = the claims made in a patent filing often greatly exceed that of the o= riginal embodiment from which the patent was drawn.  However, I = would expect that an inventor would recognize the element or elements= of a design that, at a minimum, approximate the original embodiment = that lead to patenting of the "invention".  

Given that there was a separate design team carved off of the r= oll WG to do the initial roll/RPL design, I do not think it is unreas= onable to ask the named inventors or other members of the DT to provi= de some insight into the design elements that may be impacted by the = IPR stated in this disclosure.

To be clear -= - I agree with Dan Lang's earlier comments.  To paraphrase: If y= ou want to be covered, each individual and their lawyers should do th= eir homework.

I believe what we want is to m= ove forward in a confident, expedient manner, and there is informatio= n that can be provided to help that along.  If we want to wait u= ntil each individual that has expressed a desire to "not move forward= ", has done their own evaluation, we will be "stuck in neutral" for a= while.


I= feel that it is critically important that we not proceed with thedraft as it currently stands.  I think that the current licensi= ng terms
for the IPR are a show stopper.

I think we've beaten this one to death for the moment and= I would ask that any additional discussions on this topic continue o= n the appropriate IPR/ILT (aka non-roll) mailing lists.
Best regards,
...Pete


=09geoff




On Mon, 2010-02-01 at = 14:57 +0100, JP Vasseur wrote:
Dear all,=


Given the= discussions about the IPR disclosure at
http= s://datatracker.ietf.org/ipr/1246/ and the IETF's IPR policy
<= /blockquote>
at http://www.ietf.org/ipr/policy.html I would l= ike to make sure that
the w= orking group is happy to proceed with draft-ietf-roll-rpl in its
<= /blockquote>
current form. Please state your= opinions on the list. I will make a
consensus call on Friday 11 February.


<= /blockquote>
Thanks.


JP.


_______________________________________= ________
Roll mailing list<= br>
Roll@ietf.org
https://www.ietf.= org/mailman/listinfo/roll

___________________= ____________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/li= stinfo/roll

--Boundary_(ID_TyH2d1OqXl/jpTpwoweR6g)-- From alexandru.petrescu@gmail.com Fri Feb 19 13:04:55 2010 Return-Path: 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 685743A6A10 for ; Fri, 19 Feb 2010 13:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 cbK4hkq6RnYT for ; Fri, 19 Feb 2010 13:04:54 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 577553A801B for ; Fri, 19 Feb 2010 13:04:52 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id BB3E3D4817D for ; Fri, 19 Feb 2010 22:06:37 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 875CCD48012 for ; Fri, 19 Feb 2010 22:06:34 +0100 (CET) Message-ID: <4B7EFD56.9090408@gmail.com> Date: Fri, 19 Feb 2010 22:06:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100219-0, 19/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:04:55 -0000 I hope I get this straight... you're proposing to express latency in units of milliseconds, i.e. micro-second precision may get lost or so(?) Le 19/02/2010 09:49, MiJeom Kim a écrit : > Hi, all, > > It's time to close on the #18. I think that throughput and latency > can be better presented by unsigned integers as the below > justification wrote. Latency can be expressed in units of > milliseconds and throughput can be expressed in bytes per second. If > you don't have any objection, let me close it. Sure I object to expressing latency as units of milliseconds, in a 32bit integer, because there commonly exist Round-Trip Times for 802.11g in the range of micro-seconds, i.e. fractions of milliseconds - are they lost? > Please send me your comments on the issue. > > Thanks, Mijeom. > > > > On Sun, Nov 15, 2009 at 7:30 PM, roll issue > tracker wrote: >> #18: Numeric Ranges in Routing Metric >> --------------------------------+------------------------------------------- >> >> >> Reporter: jpv@… | Owner: jpv@… >> Type: defect | Status: new Priority: minor | >> Milestone: Component: routing-metrics | Version: Severity: >> Active WG Document | Keywords: >> --------------------------------+------------------------------------------- >> >> >> This ticket is related to the Numeric Ranges in Routing Metric. >> >> Here is the original thread: >> >> I mentioned it during the roll meeting Tuesday, but I think it's >> probably worth documenting the thought in a little more technical >> detail. The routing metrics right now include 32-bit floating >> point numbers for latency and throughput. Since these numbers are >> much more likely to be added or compared rather than multiplied, >> fixed point rather than floating point is likely to be a better >> choice of representation. For example, for normalized positive >> 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and >> the minimum is about 1.2e-38. For reference, the age of universe >> in milliseconds (taking the high end of NASA's most recent >> estimate) is only 4.4e20 and the time it takes to travel the >> distance across an electron (Lorentz diameter for you physics >> heads) is about 1.9e-20 ms. A negative latency would seem to imply >> that packets appear before they're sent which is probably not >> practical. If instead, latency were a 32-bit unsigned integer in >> units of milliseconds,we'd still be able to go from 0 or 1 >> milliseconds up to almost 1200 hours if my math is right. That >> should be plenty for any practical network. YEs the upper bound of the latency seems to be set straight (max latency to be a huge number). A huge latency would correspond to a very slow link... But the lower bound, i.e. a very fast link? (micro-seconds RTT of 802.11g). Also, how about expressing something in _baud_ somewhere because it is very common on the slowest serial links (e.g. 150baud, 300baud, 600baud...) Whereas latency and throughput are typical metrics for high-speed links such as 1Mbps, 1GBps, etc. Alex I haven't done >> so but I suspect that we could do the same thing with throughput. >> >> -- Ticket URL: >> 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 > From alexandru.petrescu@gmail.com Fri Feb 19 13:12:58 2010 Return-Path: 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 61FED3A801B for ; Fri, 19 Feb 2010 13:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 stzaaS21BHkM for ; Fri, 19 Feb 2010 13:12:57 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9E3363A8004 for ; Fri, 19 Feb 2010 13:12:54 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 78434D48138 for ; Fri, 19 Feb 2010 22:14:39 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3E820D4813D for ; Fri, 19 Feb 2010 22:14:37 +0100 (CET) Message-ID: <4B7EFF39.9020301@gmail.com> Date: Fri, 19 Feb 2010 22:14:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100219-0, 19/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:12:58 -0000 Le 19/02/2010 09:58, MiJeom Kim a écrit : > Hi, again, > > Now the #20. As I mentioned in #18, throughput and latency may be > better expressed in unsigned integers. Hmm... integers of milli-seconds would loose the micro-second precision of latency on e.g. 802.11g. Maybe micro-seconds? Maybe nano-seconds? I believe the > And I confirmed that there is no IEEE 8 bits floating point format. We may invent one if we needed and propose to IEEE, no? 1 sign, 5 mantissa, 2 exponent, or something else. > So encoding of ETX needs to be reconsidered. I think we may use 16 > bits half precision IEEE 754 format or 8 bits unsigned integer. Any > better idea? Please post your opinion to close on this issue soon. What's the range of reported values? What values did the implementers encounter? On what links? IMHO, Alex > > Thanks, Mijeom. > > > On Thu, Dec 3, 2009 at 8:54 PM, roll issue > tracker wrote: >> #20: Question on Metric ID >> --------------------------------+------------------------------------------- >> >> Reporter: jpv@… | Owner: mjkim@… >> Type: defect | Status: new Priority: major >> | Milestone: Component: routing-metrics | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------+------------------------------------------- >> >> Question on the METRIC ID asked during IETF-76 >> >> - Throughput and latency should be IEEE 32 floating point? >> >> - Is there IEEE 8 floating point format? >> >> -- Ticket URL: >> 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 > From jvasseur@cisco.com Fri Feb 19 14:29:21 2010 Return-Path: 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 4803D3A803B for ; Fri, 19 Feb 2010 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.565 X-Spam-Level: X-Spam-Status: No, score=-9.565 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vJK6sMNO2GPb for ; Fri, 19 Feb 2010 14:29:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 79D543A7B99 for ; Fri, 19 Feb 2010 14:29:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqffktAZnwN/2dsb2JhbACbCXOmbZdygkmCHgQ X-IronPort-AV: E=Sophos;i="4.49,506,1262563200"; d="scan'208,217";a="213345773" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2010 22:31:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JMV6TN023942 for ; Fri, 19 Feb 2010 22:31:07 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 23:31:05 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 23:31:04 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-134-548656125 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 23:31:04 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Feb 2010 22:31:05.0045 (UTC) FILETIME=[3933F850:01CAB1B3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17204.002 X-TM-AS-Result: No--4.177700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Provisional Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 22:29:21 -0000 --Apple-Mail-134-548656125 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Here is the provisional agenda for the ROLL WG Meeting - IETF-77 - Note that the final agenda will be available Feb 26: MONDAY, March 22, 2010 1740-1940 Afternoon Session III California A APP alto Application-Layer Traffic Optimization WG Huntington APP eai Email Address Internationalization WG California D INT csi Cga & Send maIntenance WG Redondo IRTF HIPRG Host Identity Protocol Palos Verdes OPS netconf Network Configuration WG California C RAI codec Internet Wideband Audio Codec WG Manhattan RTG forces Forwarding and Control Element Separation WG California B RTG roll Routing Over Low power and Lossy networks WG We will soon start working on the agenda. Thanks. JP. --Apple-Mail-134-548656125 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Here is the provisional agenda = for the ROLL WG Meeting - IETF-77 - Note that the final agenda will be = available Feb 26:

MONDAY, March 22, 2010

1740-1940  Afternoon Session III
California A    	APP 	alto        	Application-Layer =
Traffic Optimization WG
Huntington      	APP 	eai         	Email Address =
Internationalization WG
California D    	INT 	csi         	Cga & Send =
maIntenance WG
Redondo         	IRTF	HIPRG       	Host Identity Protocol=20=

Palos Verdes    	OPS 	netconf     	Network Configuration WG
California C    	RAI 	codec       	Internet Wideband Audio =
Codec WG
Manhattan       	RTG 	forces      	Forwarding and Control =
Element Separation WG
California B    	RTG 	roll        	Routing Over Low power =
and Lossy networks WG
We will soon =
start working on the agenda.

Thanks.

JP.
= --Apple-Mail-134-548656125-- From gnawali@cs.stanford.edu Mon Feb 22 21:01:45 2010 Return-Path: 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 A9E0228C528 for ; Mon, 22 Feb 2010 21:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 Wbj0MqbMADau for ; Mon, 22 Feb 2010 21:01:44 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D552228C522 for ; Mon, 22 Feb 2010 21:01:44 -0800 (PST) Received: from mail-qy0-f177.google.com ([209.85.221.177]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Njmvy-0006DH-24 for roll@ietf.org; Mon, 22 Feb 2010 21:03:46 -0800 Received: by qyk8 with SMTP id 8so1857041qyk.14 for ; Mon, 22 Feb 2010 21:03:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.73.35 with SMTP id o35mr631859qaj.386.1266901425082; Mon, 22 Feb 2010 21:03:45 -0800 (PST) In-Reply-To: <20100223045634.C3F6328C44F@core3.amsl.com> References: <20100223045634.C3F6328C44F@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 22 Feb 2010 21:03:25 -0800 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 05:01:45 -0000 ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Feb 22, 2010 at 8:56 PM Subject: New Version Notification for draft-gnawali-roll-etxof-00 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-etxof-00.txt has been successfuly submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-etxof Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 The ETX Objective Function for RPL Creation_date: =A0 2010-02-22 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 7 Abstract: The ETX metric of a wireless link is the expected number of transmissions required to successfully transmit and acknowledge a packet on the link. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes ETXOF, an objective function that minimizes ETX. =A0The RPL path computation using ETXOF results in minimum-ETX paths from the nodes to the DAG roots, i.e., paths that minimize the number of packet transmissions for packet delivery from nodes in the network to the DAG root. The IETF Secretariat. From thomas@thomasclausen.org Mon Feb 22 23:05:38 2010 Return-Path: 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 378083A69BE; Mon, 22 Feb 2010 23:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 6xOdmpqnAssA; Mon, 22 Feb 2010 23:05:37 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7356E3A6774; Mon, 22 Feb 2010 23:05:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5E37C430035; Mon, 22 Feb 2010 23:07:39 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D8CEC43001A; Mon, 22 Feb 2010 23:07:37 -0800 (PST) Message-Id: <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> From: Thomas Heide Clausen To: Omprakash Gnawali In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 08:07:36 +0100 References: <20100223045634.C3F6328C44F@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 22 Feb 2010 23:22:31 -0800 Cc: "L. Aaron Kaplan" , ROLL WG , MANET IETF Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 07:05:38 -0000 Just a FYI: in the [manet] WG, an ETx metrics specification was published recently, based on the exhaustive operational experiences from the FunkFeuer network: http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx I understand that the above I-D is being revised and an update is expected shortly. I thought that it might be useful to cross-post this information -- it would seem that there's both similarity and complementarity here. (and, for some reason, the only URL for draft-gnawali-roll-etxof that I could make work is this: https://datatracker.ietf.org/doc/draft-gnawali-roll-etxof/ ) Sincerely, Thomas On Feb 23, 2010, at 06:03 AM, Omprakash Gnawali wrote: > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Mon, Feb 22, 2010 at 8:56 PM > Subject: New Version Notification for draft-gnawali-roll-etxof-00 > To: gnawali@cs.stanford.edu > Cc: pal@cs.stanford.edu > > > > A new version of I-D, draft-gnawali-roll-etxof-00.txt has been > successfuly submitted by Omprakash Gnawali and posted to the IETF > repository. > > Filename: draft-gnawali-roll-etxof > Revision: 00 > Title: The ETX Objective Function for RPL > Creation_date: 2010-02-22 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > The ETX metric of a wireless link is the expected number of > transmissions required to successfully transmit and acknowledge a > packet on the link. The Routing Protocol for Low Power and Lossy > Networks (RPL) allows the use of objective functions to construct > routes that optimize or constrain a routing metric on the paths. > This specification describes ETXOF, an objective function that > minimizes ETX. The RPL path computation using ETXOF results in > minimum-ETX paths from the nodes to the DAG roots, i.e., paths that > minimize the number of packet transmissions for packet delivery from > nodes in the network to the DAG root. > > > > The IETF Secretariat. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Feb 22 23:24:25 2010 Return-Path: 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 A594028C535 for ; Mon, 22 Feb 2010 23:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-3.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ApOXQip+qZmQ for ; Mon, 22 Feb 2010 23:24:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6AA4828C532 for ; Mon, 22 Feb 2010 23:24:24 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAAABwSg0uQ/uCWe2dsb2JhbACBQplEFQEBFiQGHKIQmEKEaQQ X-IronPort-AV: E=Sophos;i="4.49,524,1262563200"; d="scan'208,217";a="3685763" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 23 Feb 2010 06:54:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1N7QOJ7028655 for ; Tue, 23 Feb 2010 07:26:24 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 08:26:24 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 08:26:24 +0100 Message-Id: <10E0C6BF-8E7B-4268-9981-001C70FE265A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-232-839975024 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 08:26:23 +0100 References: <20100222200002.042C53A8142@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Feb 2010 07:26:24.0421 (UTC) FILETIME=[81150D50:01CAB459] Subject: [Roll] Fwd: Internet Draft Cut-off Dates Reminder X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 07:24:25 -0000 --Apple-Mail-232-839975024 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IETF Secretariat > Date: February 22, 2010 9:00:01 PM CEST > To: ietf-announce@ietf.org > Subject: Internet Draft Cut-off Dates Reminder > > > This is a reminder that the Internet Draft Cut-off Dates are > approaching. > > > The initial draft (version -00) cut-off date is Monday, March 1, 2010. > These submissions are due by 17:00 PST (01:00 Tuesday, March 2 UTC). > > The Internet Draft final submission (version -01 and up) cut-off is > Monday, March 8, 2010 at 17:00 PST (01:00 Tuesday, March 2 UTC). > > All drafts can be uploaded using the ID submission tool located here: > https://datatracker.ietf.org/idst/upload.cgi > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-232-839975024 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: February 22, 2010 9:00:01 PM = CEST
To: ietf-announce@ietf.org
Subject: Internet Draft Cut-off Dates = Reminder 


This is = a reminder that the Internet Draft Cut-off Dates are = approaching.


The initial draft (version -00) cut-off date is = Monday, March 1, 2010.
These submissions are due by 17:00 PST (01:00 = Tuesday, March 2 UTC).

The Internet Draft final submission = (version -01 and up) cut-off is
Monday, March 8, 2010 at 17:00 PST = (01:00 Tuesday, March 2 UTC).

All drafts can be uploaded using = the ID submission tool located here:
https://datatracker.= ietf.org/idst/upload.cgi
__________________________________________= _____
IETF-Announce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= --Apple-Mail-232-839975024-- From mijeom@gmail.com Mon Feb 22 23:39:01 2010 Return-Path: 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 9CBBD3A6A48 for ; Mon, 22 Feb 2010 23:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Uat+TFbI7bqd for ; Mon, 22 Feb 2010 23:39:00 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A2B3A3A7929 for ; Mon, 22 Feb 2010 23:39:00 -0800 (PST) Received: by pwi3 with SMTP id 3so3677253pwi.31 for ; Mon, 22 Feb 2010 23:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bdh2kF8hso1GyZza6uqLRttO1GaFacUeYT+zPpsHjUQ=; b=nOQza6JtRqveEg4yBb6L1NRpPz5EZsOew9e5uyXML4b1QdDX/Txm65SUdP2L+sSSn4 E4fYfVH/ZlBmAqYP0/z3Qsa3U9+hDQgMlwbbD0F/hWp6qV2B2LQkJliPfkxV7ZMpLAFC 4jSBaGBex/ukxGsyoAc0jtIK9+mV7oDhRjV3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BaEjXmOh+Vex7MihpzkBpdV89YmD2qlFd1EfP1UEEGZIJbVywR48gpX/Q8fWrlp5Kc xxk9VbjKMBo1Ov9eY4oVP1A72Jkzsy7y8N9mb+BN7bMyUCQ62GKkRKUTPNjlSibFWCo+ uPU3I6TBfLpXI4rvSE8mvIBtKpTE6QALloSZI= MIME-Version: 1.0 Received: by 10.142.3.32 with SMTP id 32mr1773521wfc.321.1266910859032; Mon, 22 Feb 2010 23:40:59 -0800 (PST) In-Reply-To: <4B7EFD56.9090408@gmail.com> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <4B7EFD56.9090408@gmail.com> Date: Tue, 23 Feb 2010 16:40:59 +0900 Message-ID: From: MiJeom Kim To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 07:39:01 -0000 Hi, Alex, I still think that millisecond is better since micro-second is too high precision for LLNs considering that most links are relatively slow in LLNs. Even for the lower bound, difference of 1 millisecond seems to be fine. Difference between 0 millisecond latency and 1 millisecond latency seems good enough for LLN applications. Micro-second is okay, but I am just considering the trade-off, overhead to express that precision and accuracy. Regarding baud, you mean using it as throughput metric instead of bytes per second? I prefer bytes per second since baud changes with modulation methods. How about listening to more opinions? Thanks, Mijeom. On Sat, Feb 20, 2010 at 6:06 AM, Alexandru Petrescu wrote: > I hope I get this straight... you're proposing to express latency in > units of milliseconds, i.e. micro-second precision may get lost or so(?) > > Le 19/02/2010 09:49, MiJeom Kim a =E9crit : >> >> Hi, all, >> >> It's time to close on the #18. I think that throughput and latency >> can be better presented by unsigned integers as the below >> justification wrote. Latency can be expressed in units of >> milliseconds and throughput can be expressed in bytes per second. If >> you don't have any objection, let me close it. > > Sure I object to expressing latency as units of milliseconds, in a 32bit > integer, because there commonly exist Round-Trip Times for 802.11g in > the range of micro-seconds, i.e. fractions of milliseconds - are they los= t? > >> Please send me your comments on the issue. >> >> Thanks, Mijeom. >> >> >> >> On Sun, Nov 15, 2009 at 7:30 PM, roll issue >> tracker =A0wrote: >>> >>> #18: Numeric Ranges in Routing Metric >>> >>> --------------------------------+--------------------------------------= ----- >>> >>> >>> > Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0= jpv@=85 >>> >>> Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new = Priority: =A0minor | >>> Milestone: Component: =A0routing-metrics =A0 =A0 | =A0 =A0 Version: Sev= erity: >>> Active WG Document =A0| =A0 =A0Keywords: >>> >>> --------------------------------+--------------------------------------= ----- >>> >>> >>> > This ticket is related to the Numeric Ranges in Routing Metric. >>> >>> Here is the original thread: >>> >>> I mentioned it during the roll meeting Tuesday, but I think it's >>> probably worth documenting the thought in a little more technical >>> detail. =A0The routing metrics right now include 32-bit floating >>> point numbers for latency and throughput. =A0Since these numbers are >>> much more likely to be added or compared rather than multiplied, >>> fixed point rather than floating point is likely to be a better >>> choice of representation. =A0For example, for normalized positive >>> 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and >>> the minimum is about 1.2e-38. =A0For reference, the age of universe >>> in milliseconds (taking the high end of NASA's most recent >>> estimate) is only 4.4e20 and the time it takes to travel the >>> distance across an electron (Lorentz diameter for you physics >>> heads) is about 1.9e-20 ms. =A0A negative latency would seem to imply >>> that packets appear before they're sent which is probably not >>> practical. =A0If instead, latency were a 32-bit unsigned integer in >>> units of milliseconds,we'd still be able to go from 0 or 1 >>> milliseconds up to almost 1200 hours if my math is right. =A0That >>> should be plenty for any practical network. > > YEs the upper bound of the latency seems to be set straight (max latency > to be a huge number). =A0A huge latency would correspond to a very slow > link... > > But the lower bound, i.e. a very fast link? =A0(micro-seconds RTT of 802.= 11g). > > Also, how about expressing something in _baud_ somewhere because it is > very common on the slowest serial links (e.g. 150baud, 300baud, > 600baud...) > > Whereas latency and throughput are typical metrics for high-speed links > such as 1Mbps, 1GBps, etc. > > Alex > > > =A0I haven't done >>> >>> so but I suspect that we could do the same thing with throughput. >>> >>> -- Ticket URL: >>> 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 mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mijeom@gmail.com Tue Feb 23 00:00:35 2010 Return-Path: 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 4CB2C28C544 for ; Tue, 23 Feb 2010 00:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Be5JiMDjKJ5Y for ; Tue, 23 Feb 2010 00:00:34 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 235ED28C26E for ; Tue, 23 Feb 2010 00:00:34 -0800 (PST) Received: by pwi3 with SMTP id 3so3694121pwi.31 for ; Tue, 23 Feb 2010 00:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=adZu/FBNbWfaSGhtiqgaqyoAv7TLgZvGexV4Zu2UEkk=; b=mdDlcgpfmjr5veb0iwk8Rq+Rihb7jNeu5BuIxqrQS9JZMoTMwi9iIakjQCma/Y+qg5 yUeePezVY4NgB8sZuxB94GNlDD/bdB/ofwLNE1xg02ZSj+EeY0lSwrEWjzM4OYuMsC/q AfaUD/Ke6R+Lp8V7GujKhfhmztH4WZWUPk5p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cYUSFuvTVtb5/PuCuZGUmtbsuHRVlYxTWesGpTHcA7Fyluj7tgSoOcMDBaYfcP0ksJ A+c0DwEVaWILj5CYbYvf0IbSkpsqotlLVgIJw8gaRNu3kZt/jmB0oKlIc9oyqNxEURSs gq1EsnHncMEW7Ida35f0wivZMj9b8KfzFaLpc= MIME-Version: 1.0 Received: by 10.142.75.8 with SMTP id x8mr6482285wfa.226.1266912153612; Tue, 23 Feb 2010 00:02:33 -0800 (PST) In-Reply-To: <4B7EFF39.9020301@gmail.com> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <4B7EFF39.9020301@gmail.com> Date: Tue, 23 Feb 2010 17:02:33 +0900 Message-ID: From: MiJeom Kim To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:00:35 -0000 Hi, Alex, The range of ETX value is not defined since it depends on implementation. But, ETX is the number of transmission a node expects for successful transmission, thus, it should be higher than 1 and we can guess it cannot be so big number. If a node never delivers a packet successfully, the number can be infinite, but this is an extreme case. So it is not a bad idea to coin our own 8 bits floating point type. Mijeom. On Sat, Feb 20, 2010 at 6:14 AM, Alexandru Petrescu wrote: > Le 19/02/2010 09:58, MiJeom Kim a =E9crit : >> >> Hi, again, >> >> Now the #20. As I mentioned in #18, throughput and latency may be >> better expressed in unsigned integers. > > Hmm... integers of milli-seconds would loose the micro-second precision o= f > latency on e.g. 802.11g. =A0Maybe micro-seconds? =A0Maybe nano-seconds? > > I believe the > >> And I confirmed that there is no IEEE 8 bits floating point format. > > We may invent one if we needed and propose to IEEE, no? =A01 sign, 5 > mantissa, 2 exponent, or something else. > >> So encoding of ETX needs to be reconsidered. I think we may use 16 >> bits half precision IEEE 754 format or 8 bits unsigned integer. Any >> better idea? Please post your opinion to close on this issue soon. > > What's the range of reported values? =A0What values did the implementers > encounter? =A0On what links? > > IMHO, > > Alex > >> >> Thanks, Mijeom. >> >> >> On Thu, Dec 3, 2009 at 8:54 PM, roll issue >> tracker =A0wrote: >>> >>> #20: Question on Metric ID >>> >>> --------------------------------+--------------------------------------= ----- >>> >>> > Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0= mjkim@=85 >>> >>> Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new = Priority: =A0major >>> | =A0 Milestone: Component: =A0routing-metrics =A0 =A0 | =A0 =A0 Versio= n: >>> Severity: =A0Active WG Document =A0| =A0 =A0Keywords: >>> >>> --------------------------------+--------------------------------------= ----- >>> >>> > Question on the METRIC ID asked during IETF-76 >>> >>> - Throughput and latency should be IEEE 32 floating point? >>> >>> - =A0Is there IEEE 8 floating point format? >>> >>> -- Ticket URL: >>> 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 mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From henning.rogge@fkie.fraunhofer.de Tue Feb 23 00:12:00 2010 Return-Path: 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 E81C828C555 for ; Tue, 23 Feb 2010 00:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 7IByuvNIt93Z for ; Tue, 23 Feb 2010 00:11:58 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 99E8228C26B for ; Tue, 23 Feb 2010 00:11:57 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njptv-0005DB-JR; Tue, 23 Feb 2010 09:13:51 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njptv-0004O8-7S; Tue, 23 Feb 2010 09:13:51 +0100 From: Henning Rogge To: roll@ietf.org Date: Tue, 23 Feb 2010 09:13:42 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.5; i686; ; ) References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <4B7EFF39.9020301@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1950858.XI7zHafR10"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002230913.47381.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10434/Tue Feb 23 01:42:29 2010) by mailguard.fgan.de X-Scan-Signature: b6c942189b6c19c58f72b0b9976f47f0 Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:12:00 -0000 --nextPart1950858.XI7zHafR10 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable On Tue February 23 2010 09:02:33 MiJeom Kim wrote: > Hi, Alex, >=20 > The range of ETX value is not defined since it depends on > implementation. But, ETX is the number of transmission a node expects > for successful transmission, thus, it should be higher than 1 and we > can guess it cannot be so big number. If a node never delivers a > packet successfully, the number can be infinite, but this is an > extreme case. So it is not a bad idea to coin our own 8 bits floating > point type. In practice an ETX of more than 10 is close to infinity. A maximum value of= 100=20 for a single hop ETX is more than enough. The current draft of Christopher Dearlove for the OLSRv2 metric encoding=20 suggests a 8 Bit floating point for metrics with a range of 16 to 1015808,= =20 which can be easily used for ETX (multiplied with a constant factor to prev= ent=20 the need for real floating point calculations). My suggestion for ETX=3D1 i= n this=20 encoding would be 256, but that's still a point which has to be discussed. If you choose your own encoding I would suggest NOT to set ETX=3D1 as the b= est=20 possible metric value. My experience from our OLSR networks tells me that t= his=20 is a really bad decission which can hurt you later. Henning =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1950858.XI7zHafR10 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkuDjjYACgkQRIfGfFXsz+ByUwCeItb+5cOsp4iPuZV1EuaVFhcW QA4Ani834yrrmBu9jFOfqrxCvSOwy1KI =/Fb/ -----END PGP SIGNATURE----- --nextPart1950858.XI7zHafR10-- From henning.rogge@fkie.fraunhofer.de Tue Feb 23 00:13:58 2010 Return-Path: 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 E515028C274 for ; Tue, 23 Feb 2010 00:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[AWL=1.610, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 pYs+5wgCrS-1 for ; Tue, 23 Feb 2010 00:13:57 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id B080828C549 for ; Tue, 23 Feb 2010 00:13:56 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njpvx-0005aG-A6 for roll@ietf.org; Tue, 23 Feb 2010 09:15:57 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njpvv-0004Oh-Qc for roll@ietf.org; Tue, 23 Feb 2010 09:15:55 +0100 From: Henning Rogge To: roll@ietf.org Date: Tue, 23 Feb 2010 09:15:51 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.5; i686; ; ) References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201002230913.47381.henning.rogge@fkie.fraunhofer.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1305170.NC2MCTlK4c"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002230915.51233.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10434/Tue Feb 23 01:42:29 2010) by mailguard.fgan.de X-Scan-Signature: 38bebb0b8fa0111ad382b5b9a8cedd42 Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:13:59 -0000 --nextPart1305170.NC2MCTlK4c Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Tue February 23 2010 09:13:42 Henning Rogge wrote: > On Tue February 23 2010 09:02:33 MiJeom Kim wrote: > In practice an ETX of more than 10 is close to infinity. A maximum value = of > 100 for a single hop ETX is more than enough. >=20 > The current draft of Christopher Dearlove for the OLSRv2 metric encoding Sorry, forgot to include a link to the current draft: http://bgp.potaroo.net/ietf/idref/draft-dearlove-olsrv2-metrics/ Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1305170.NC2MCTlK4c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkuDjrcACgkQRIfGfFXsz+DtaACeKlx4sga2io1aVeCIB7tE2D+Q rxkAn0dnM3YwuqwQYt27gP6K49q7dqYk =HSkL -----END PGP SIGNATURE----- --nextPart1305170.NC2MCTlK4c-- From gnawali@cs.stanford.edu Tue Feb 23 02:11:37 2010 Return-Path: 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 688D13A70FC for ; Tue, 23 Feb 2010 02:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 LuBqP63lzVjx for ; Tue, 23 Feb 2010 02:11:35 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 78FEE28C16D for ; Tue, 23 Feb 2010 02:11:34 -0800 (PST) Received: from mail-qy0-f177.google.com ([209.85.221.177]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Njrlo-0000z8-3h for roll@ietf.org; Tue, 23 Feb 2010 02:13:36 -0800 Received: by qyk8 with SMTP id 8so1944469qyk.14 for ; Tue, 23 Feb 2010 02:13:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.52.211 with SMTP id j19mr6774044qag.301.1266920015142; Tue, 23 Feb 2010 02:13:35 -0800 (PST) In-Reply-To: <201002230913.47381.henning.rogge@fkie.fraunhofer.de> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <4B7EFF39.9020301@gmail.com> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> From: Omprakash Gnawali Date: Tue, 23 Feb 2010 02:13:15 -0800 Message-ID: To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:11:38 -0000 On Tue, Feb 23, 2010 at 12:13 AM, Henning Rogge wrote: > On Tue February 23 2010 09:02:33 MiJeom Kim wrote: >> Hi, Alex, >> >> The range of ETX value is not defined since it depends on >> implementation. But, ETX is the number of transmission a node expects >> for successful transmission, thus, it should be higher than 1 and we >> can guess it cannot be so big number. If a node never delivers a >> packet successfully, the number can be infinite, but this is an >> extreme case. So it is not a bad idea to coin our own 8 bits floating >> point type. > In practice an ETX of more than 10 is close to infinity. A maximum value of 100 > for a single hop ETX is more than enough. > > The current draft of Christopher Dearlove for the OLSRv2 metric encoding > suggests a 8 Bit floating point for metrics with a range of 16 to 1015808, > which can be easily used for ETX (multiplied with a constant factor to prevent > the need for real floating point calculations). My suggestion for ETX=1 in this > encoding would be 256, but that's still a point which has to be discussed. > > If you choose your own encoding I would suggest NOT to set ETX=1 as the best > possible metric value. My experience from our OLSR networks tells me that this > is a really bad decission which can hurt you later. Are you suggesting that the representation of the metric value "1" should not be 1, and it should be 256? Does your bad experience related to metric representation from running OLSR network have to do with metric precision? - om_p From henning.rogge@fkie.fraunhofer.de Tue Feb 23 02:20:52 2010 Return-Path: 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 BF9953A692C for ; Tue, 23 Feb 2010 02:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 zlr9VzGdYZmm for ; Tue, 23 Feb 2010 02:20:51 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 567A728C10C for ; Tue, 23 Feb 2010 02:20:51 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njruf-0007nb-6N; Tue, 23 Feb 2010 11:22:45 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Njrue-0005A0-5z; Tue, 23 Feb 2010 11:22:44 +0100 From: Henning Rogge To: Omprakash Gnawali Date: Tue, 23 Feb 2010 11:22:36 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.5; i686; ; ) References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3590772.s0Gmt7KYXk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002231122.41069.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10434/Tue Feb 23 01:42:29 2010) by mailguard.fgan.de X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:20:52 -0000 --nextPart3590772.s0Gmt7KYXk Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue February 23 2010 11:13:15 Omprakash Gnawali wrote: > Are you suggesting that the representation of the metric value "1" > should not be 1, and it should be 256? Yes, at least if you use the suggested encoding of the draft. Using a facto= r=20 of 256 for the ETX allows for better links than ETX 1 but still have a huge= =20 range of values for ETX >1. =20 > Does your bad experience related to metric representation from running > OLSR network have to do with metric precision? No, we discovered that we could not represent ethernet links (connecting=20 multiple devices) better than a "perfect" wireless link in our metric=20 encoding, so our routing agent prefers a single wireless link with some pac= ket=20 loss over an ethernet-hop plus a perfect wireless link, which is BAD. It's a good idea to keep a little bit room for "better links". We use 1 byte for LQ with a factor of 255 to shift the floating point value= =20 (0.0 - 1.0) into a pure integer one. It's very difficult to change the enco= ding=20 of the routing metric later without reinstalling the whole network at once. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3590772.s0Gmt7KYXk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkuDrGwACgkQRIfGfFXsz+CaVgCfUXq3wYYH8ovwgAYnhQir9kSy V6AAn1il5/7Je8P9cmViktMVrEaCcn4p =X27w -----END PGP SIGNATURE----- --nextPart3590772.s0Gmt7KYXk-- From ccrisan@gmail.com Tue Feb 23 06:09:37 2010 Return-Path: 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 45C293A83C0 for ; Tue, 23 Feb 2010 06:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7ZAAdoV12ztd for ; Tue, 23 Feb 2010 06:09:36 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 1E9423A837B for ; Tue, 23 Feb 2010 06:09:35 -0800 (PST) Received: by fxm5 with SMTP id 5so4017448fxm.29 for ; Tue, 23 Feb 2010 06:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=pYjkbv90X/RM/0vV0l7pQx9nq8K/JOrWTFH4NnFPrMc=; b=C5Do/PMk0AFOoa6sL8mf4GUW1TVIxSfjmCaO2/zM8q1MBqcWsgJ9ZxfVSCTJVDujuQ 269wmvcXs3qJGTRlRiej8nn4QPeIa0EA3gVEATcJRmbAufvDJ4jh5/0NzzfHGMIeBHBN ogBWcIGmFqwBUS1GBlC2O0DRbVMuT8gb6qsRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=xLjvW2LMEg7PTRotW3uUfxM0lGs22AOpBuwta+MjVJQUQH9PrtScQh8CMOTJiJNJbo WDdzUCY7i6jxBb1GBUxmJhH9t0Xb4Tm/WrHwsGtuRblLvb3jKpMUckIAsKvARFyE8337 SkHbonu2Mk0HdgDrW3jvZh9XrFx8mKJNRmRek= MIME-Version: 1.0 Received: by 10.223.62.83 with SMTP id w19mr87180fah.22.1266934295512; Tue, 23 Feb 2010 06:11:35 -0800 (PST) From: Calin Crisan Date: Tue, 23 Feb 2010 15:09:49 +0100 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=0015173ffacca345060480452019 Subject: [Roll] RPL question regarding the flow label's "Down" bit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 14:09:37 -0000 --0015173ffacca345060480452019 Content-Type: text/plain; charset=ISO-8859-1 Hi, Supposing a simple scenario where a node wants to send a packet to another node within its subdag, thus having a greater rank. The source node, who acts as a host in this case, is supposed to set the flow label's bits to 0, including the "Down" bit. The first router in the path will however have a greater rank, and so it will detect a first forwarding inconsistency. Is this OK? Thanks, Calin Crisan. --0015173ffacca345060480452019 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0=A0 =A0Hi,

=A0=A0 =A0Supposing a simple scenario wher= e a node wants to send a packet to another node within its subdag, thus hav= ing a greater rank. The source node, who acts as a host in this case, is su= pposed to set the flow label's bits to 0, including the "Down"= ; bit. The first router in the path will however have a greater rank, and s= o it will detect a first=A0forwarding inconsistency. Is this OK?

=A0=A0 =A0Thanks,

=A0=A0 =A0Cali= n Crisan.

--0015173ffacca345060480452019-- From dlang@cisco.com Tue Feb 23 07:45:32 2010 Return-Path: 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 BD13328C2EB; Tue, 23 Feb 2010 07:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vhbdfWrQKDR7; Tue, 23 Feb 2010 07:45:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6E47728C2D4; Tue, 23 Feb 2010 07:45:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,526,1262563200"; d="scan'208,217";a="88261821" Received: from sj-core-1.cisco.com ([171.71.177.237]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 15:47:31 +0000 Received: from [192.168.1.108] ([10.21.72.89]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1NFlUOP014290; Tue, 23 Feb 2010 15:47:30 GMT Message-Id: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> From: Dan Lang To: ietf-ipr@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-496-870041851 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 07:47:30 -0800 X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: [Roll] IPR statement RE:draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:45:33 -0000 --Apple-Mail-496-870041851 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cisco is the owner of US Patent Nos. 7,190,678, 7,203,175, 7,209,978, 7,366,111, 7,428,221, and 7,649,852, US Published Patent Applications 20060291404, 20070091811, 20070153764, and 20080219237, and US Patent Application Serial No. 11/984,049 relating to the subject matter of "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" . If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. The reasonable non- discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard. Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. To maintain reciprocity, notwithstanding anything to the contrary, Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a claim of a patent it owns or controls (either directly or indirectly), where such claim is necessary for practicing the standard, 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, where such assertion by such party is directed against implementation of the standard. For information contact: Dan Lang Director, Intellectual Property Cisco Systems +1 408-526-6672 standards-ipr@cisco.com --Apple-Mail-496-870041851 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

 
If technology in this document is included in a = standard adopted by IETF and any claims of any Cisco patents are = necessary for practicing the standard, any party will have the right to = use any such patent claims under reasonable, non-discriminatory terms, = with reciprocity, to implement and fully comply with the standard. The = reasonable non-discriminatory terms are: If this standard is adopted, = Cisco will not assert any patents owned or controlled by Cisco against = any party for making, using, selling, importing or offering for sale a = product that implements the standard. Cisco retains the right to assert = its patents against any product or portion thereof that is not necessary = for compliance with the standard.
 
To maintain reciprocity, notwithstanding anything to = the contrary, Cisco retains the right to assert its patents (including = the right to claim past royalties) against any party that asserts a = claim of a patent it owns or controls (either directly or indirectly), = where such claim is necessary for practicing the standard, 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, where such assertion by = such party is directed against implementation of the = standard.
For = information contact:
Dan = Lang
Cisco Systems
+1 408-526-6672
From: Dan Lang To: roll@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-505-870247542 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 07:50:56 -0800 X-Mailer: Apple Mail (2.936) Subject: [Roll] Our revised IPR declaration on ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:48:54 -0000 --Apple-Mail-505-870247542 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I wanted to provide a little commentary on the revised licensing commitment language that was just distributed on the mailer. We believe that it will satisfy the concerns as we understand them and allow the WG to move to the next step. Again, the proviso for the commentary is that it is not intended as an interpretation or legal advice and you should seek your own legal counsel. Essentially, our new statement, like the old, promises to not assert our essential patents against functionality that implements ROLL, once standardized. The difference is that whereas the old statement suspended, at our option, this commitment in response to any patent assertion against Cisco or Cisco products, the new statement only potentially suspends our commitment as to those who assert their essential patents against Cisco or CIsco products for implementing ROLL. Dan Lang Director, Intellectual Property Cisco Systems, Inc. --Apple-Mail-505-870247542 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi,  I wanted to provide a little = commentary on the revised licensing commitment language that was just = distributed on the mailer.  We believe that it will satisfy the = concerns as we understand them and allow the WG to move to the next = step.  Again, the proviso for the commentary is that it is not = intended as an interpretation or legal advice and you should seek your = own legal counsel.  
Essentially, our new statement, like the = old, promises to not assert our essential patents against functionality = that implements ROLL, once standardized.  The difference is that = whereas the old statement suspended, at our option,  this = commitment in response  to any patent assertion against Cisco or = Cisco products, the new statement only potentially suspends our = commitment as to those who assert their essential patents against Cisco = or CIsco products for implementing ROLL.

Dan Lang
Director, = Intellectual Property
Cisco Systems, Inc.




= --Apple-Mail-505-870247542-- From jeonggil.ko@gmail.com Tue Feb 23 07:52:46 2010 Return-Path: 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 C27DD3A7B45 for ; Tue, 23 Feb 2010 07:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 31WZTVDDP5N4 for ; Tue, 23 Feb 2010 07:52:44 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id DAAD628C1C6 for ; Tue, 23 Feb 2010 07:52:43 -0800 (PST) Received: by bwz3 with SMTP id 3so2777714bwz.29 for ; Tue, 23 Feb 2010 07:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=J8w0V/a2p1qCyz6m/+H8j8H3la2dicFcMikg+0TXK2I=; b=hEcaED0i6BvcJk3K5wz30pcJyRSsjtacuUbSqfkQqw3i5gE/7ArKB6Ad5mgqiKoatk 02ahYjBLkhnQj5hOFVv+Qcqcaw3ZzCNxtNbEIquyETGbiUVlyqq8ZsQN/vClwJpmrgHW Z+EOsqU3XX6HA243W+wAyKwqfr/AQQkIrT17w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=FzjCLpG2FDRg2BTV3fEVeSsXzkMxrs4vAWwA55vKjM4XI0hAzQWnVvnDfgB64X05zk ECtr0ue9srJ5+reFOApDa82Y1mZeYYwDEGQdhNV9rUIj4I3RlzC9w+ATaO350pXryP/H LkI99hYz5KHHCrgeQU8B9+MezWWrWwxqhTpMw= Received: by 10.103.126.29 with SMTP id d29mr4513430mun.28.1266940481826; Tue, 23 Feb 2010 07:54:41 -0800 (PST) Received: from ?192.168.1.108? ([76.14.51.89]) by mx.google.com with ESMTPS id w5sm4133955mue.52.2010.02.23.07.54.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 07:54:40 -0800 (PST) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: Date: Tue, 23 Feb 2010 07:54:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8538C767-9E3D-4E2B-901D-9F582E3DE4A8@cs.jhu.edu> References: To: Calin Crisan X-Mailer: Apple Mail (2.1077) Cc: ROLL WG Subject: Re: [Roll] RPL question regarding the flow label's "Down" bit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:52:46 -0000 Hi! Actually the first router will not detect inconsistency because the = SenderRank in the flow label is also set to zero when the message is = initiated at the source node (there will be no rank value for the first = router to compare with). So I think that the first router can receive = the message and then decide to modify the down bit before forwarding to = the second router, if any. Thanks. -John On Feb 23, 2010, at 6:09 AM, Calin Crisan wrote: > Hi, >=20 > Supposing a simple scenario where a node wants to send a packet to = another node within its subdag, thus having a greater rank. The source = node, who acts as a host in this case, is supposed to set the flow = label's bits to 0, including the "Down" bit. The first router in the = path will however have a greater rank, and so it will detect a first = forwarding inconsistency. Is this OK? >=20 > Thanks, >=20 > Calin Crisan. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From wwwrun@core3.amsl.com Tue Feb 23 08:18:14 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9BF5328C1F6; Tue, 23 Feb 2010 08:18:14 -0800 (PST) To: pthubert@cisco.com,wintert@acm.org,rpl-authors@external.cisco.com From: IETF Secretariat Message-Id: <20100223161814.9BF5328C1F6@core3.amsl.com> Date: Tue, 23 Feb 2010 08:18:14 -0800 (PST) X-Mailman-Approved-At: Tue, 23 Feb 2010 08:53:03 -0800 Cc: culler@eecs.berkeley.edu, roll@ietf.org, adrian.farrel@huawei.com, rcallon@juniper.net, ipr-announce@ietf.org Subject: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:18:15 -0000 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1270/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06." The IETF Secretariat From gnawali@cs.stanford.edu Tue Feb 23 08:59:11 2010 Return-Path: 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 6ADE928C563 for ; Tue, 23 Feb 2010 08:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.436 X-Spam-Level: X-Spam-Status: No, score=-5.436 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 q5M2NjQSjCOa for ; Tue, 23 Feb 2010 08:59:10 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B0AE228C553 for ; Tue, 23 Feb 2010 08:59:10 -0800 (PST) Received: from mail-vw0-f44.google.com ([209.85.212.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Njy8H-0003K1-7m for roll@ietf.org; Tue, 23 Feb 2010 09:01:14 -0800 Received: by vws19 with SMTP id 19so277612vws.31 for ; Tue, 23 Feb 2010 09:01:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.52.211 with SMTP id j19mr7019817qag.301.1266944472174; Tue, 23 Feb 2010 09:01:12 -0800 (PST) In-Reply-To: <201002231122.41069.henning.rogge@fkie.fraunhofer.de> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> From: Omprakash Gnawali Date: Tue, 23 Feb 2010 09:00:52 -0800 Message-ID: To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:59:11 -0000 On Tue, Feb 23, 2010 at 2:22 AM, Henning Rogge wrote: .... >> Does your bad experience related to metric representation from running >> OLSR network have to do with metric precision? > No, we discovered that we could not represent ethernet links (connecting > multiple devices) better than a "perfect" wireless link in our metric > encoding, so our routing agent prefers a single wireless link with some packet > loss over an ethernet-hop plus a perfect wireless link, which is BAD. > > It's a good idea to keep a little bit room for "better links". > > We use 1 byte for LQ with a factor of 255 to shift the floating point value > (0.0 - 1.0) into a pure integer one. It's very difficult to change the encoding > of the routing metric later without reinstalling the whole network at once. Thanks for sharing this insight. We need to be aware of similar scenarios also on LLNs. I think RPL's approach is to have different objective functions that maximize/minimize or constrain different metrics, and even apply a series of objective functions for path selection if desired. That seems like a better approach than overloading many meanings to ETX. Does OLSRv2 support different metrics such as data rates and energy? If it does, are there still advantages to overloading ETX? - om_p From pthubert@cisco.com Tue Feb 23 09:19:36 2010 Return-Path: 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 7C76F28C57A for ; Tue, 23 Feb 2010 09:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 r78E4jtIABkZ for ; Tue, 23 Feb 2010 09:19:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2062A28C572 for ; Tue, 23 Feb 2010 09:19:34 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAANOcg0uQ/uCWe2dsb2JhbACbDBUBARYkBhykc5hhhGwE X-IronPort-AV: E=Sophos;i="4.49,527,1262563200"; d="scan'208";a="57429428" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2010 17:21:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1NHLbYk006879; Tue, 23 Feb 2010 17:21:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 18:21:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 18:21:22 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Thread-Index: Acq0pCC+rD//0mgaRVGU9sCitaAlqAAAiO/A From: "Pascal Thubert (pthubert)" To: "Roger Alexander" , , , "Sung Lee" , "Emmanuel Baccelli" X-OriginalArrivalTime: 23 Feb 2010 17:21:37.0053 (UTC) FILETIME=[A7783CD0:01CAB4AC] Cc: roll@ietf.org, "Dan Lang \(dlang\)" Subject: [Roll] FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:19:36 -0000 Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco IPR debate: It is my understanding that this new declaration implements Roger's suggested compromise regarding Sung and Ruben's concerns, also relayed by Emmanuel. For reference: Roger suggested: http://www.ietf.org/mail-archive/web/roll/current/msg03045.html=20 Sung said: http://www.ietf.org/mail-archive/web/roll/current/msg03034.html Emmanuel said: http://www.ietf.org/mail-archive/web/roll/current/msg03063.html Ruben said: http://www.ietf.org/mail-archive/web/roll/current/msg03026.html=20 With this new IPR declaration, Cisco retains its defensive right in the context of RPL implementations *only*. By the new terms Cisco will not "walk freely anywhere" in someone else's "property". And the answer to Sung's question about "infringing patents NOT related to RPL" is now a NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does the exact same, which seems quite fair to me. For all I know, this is a major and somewhat exceptional step that should be recognized as such. And alternate terms based on RAND are still available to anyone who would prefer that way. Sadly, I'll still refrain from detailing which exact pieces RPL I personally think are covered by this IPR. I think it is pretty clear by now that this would not have a lot of value since 1) I'm not a lawyer, and 2) even less your own lawyer. Also the logic of claims somewhat escapes me, in particular when it comes to coverage. All I know is that the disclosures I was involved with detail ways to build trees and DAGs, propagate metrics and paint unicast and multicast routes along the DAGs, compress and expands routing headers, all things that are somewhat similar to RPL operations. I sincerely hope that this declaration will allow us to reach a positive consensus on the current poll about Cisco's IPR and move forward with RPL as soon as possible. Please let us know. Pascal -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 Sent: Tuesday, February 23, 2010 5:18 PM To: Pascal Thubert (pthubert); wintert@acm.org; rpl-authors@external.cisco.com Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1270/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06." The IETF Secretariat From ccrisan@gmail.com Tue Feb 23 09:56:24 2010 Return-Path: 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 A809B3A7102 for ; Tue, 23 Feb 2010 09:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Hu2rOsIzbO3l for ; Tue, 23 Feb 2010 09:56:23 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 1EF4F3A6B45 for ; Tue, 23 Feb 2010 09:56:22 -0800 (PST) Received: by bwz3 with SMTP id 3so2910564bwz.29 for ; Tue, 23 Feb 2010 09:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Tt6EeK7nhE5DGmrvgFUvAcR6RXLxKb+HjyVHsT/2cqI=; b=R88iVtyh5+iWWFq1bgkEm2dDSQUzTAAMMD3kg/eZ/NPeKlzRwkLG1dlCgn5sTTo5yn 6MztVhnyWSntUP+P0Ldk7bB0EdoqrGOb/K1lz4zK+w+RuCFXnvUHPRKH8AsTcUlS1SaC CX9lFMwxfD6x+1dwU3ppGOfaM2looGLkbF1Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=OjHEJC1/Sd15c/6jjuReUlLu/OQX9FR7XasM6NPfwbxuwg8zXOLRhkv2miA2yo5Nad Da+uS7/Afs0nE/DqxyVTvUDjVx/LX+a9pAyxJK2n1ZKe691qdywYfwJ3pqT7QujPkUeM FrJW6dP2b6Hxh21vkg2XKww+/cuJS4zxRD5LU= MIME-Version: 1.0 Received: by 10.204.141.69 with SMTP id l5mr3077030bku.64.1266947902367; Tue, 23 Feb 2010 09:58:22 -0800 (PST) In-Reply-To: <8538C767-9E3D-4E2B-901D-9F582E3DE4A8@cs.jhu.edu> References: <8538C767-9E3D-4E2B-901D-9F582E3DE4A8@cs.jhu.edu> From: Calin Crisan Date: Tue, 23 Feb 2010 18:58:02 +0100 Message-ID: To: "JeongGil Ko (John)" Content-Type: multipart/alternative; boundary=00151747927aab68c40480484be8 Cc: ROLL WG Subject: Re: [Roll] RPL question regarding the flow label's "Down" bit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:56:24 -0000 --00151747927aab68c40480484be8 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thank you for your quick answer. Yes, indeed a rank equal to 0 should not be considered as making part of the actual network's DODAG, aspect that I forgot about in my implementation. Cheers, Calin. On Tue, Feb 23, 2010 at 4:54 PM, JeongGil Ko (John) wrote: > Hi! > > Actually the first router will not detect inconsistency because the > SenderRank in the flow label is also set to zero when the message is > initiated at the source node (there will be no rank value for the first > router to compare with). So I think that the first router can receive the > message and then decide to modify the down bit before forwarding to the > second router, if any. > > Thanks. > > -John > > On Feb 23, 2010, at 6:09 AM, Calin Crisan wrote: > > > Hi, > > > > Supposing a simple scenario where a node wants to send a packet to > another node within its subdag, thus having a greater rank. The source node, > who acts as a host in this case, is supposed to set the flow label's bits to > 0, including the "Down" bit. The first router in the path will however have > a greater rank, and so it will detect a first forwarding inconsistency. Is > this OK? > > > > Thanks, > > > > Calin Crisan. > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > --00151747927aab68c40480484be8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0=A0 =A0Hi,

=A0=A0 =A0Thank you for your quick answer.= Yes, indeed a rank equal to 0 should not be considered as making part of t= he actual network's DODAG, aspect that I forgot about in my implementat= ion.

=A0=A0 =A0Cheers,

=A0=A0 =A0Ca= lin.

On Tue, Feb 23, 2010 at 4:54 PM, Jeo= ngGil Ko (John) <jg= ko@cs.jhu.edu> wrote:
Hi!

Actually the first router will not detect inconsistency because the SenderR= ank in the flow label is also set to zero when the message is initiated at = the source node (there will be no rank value for the first router to compar= e with). So I think that the first router can receive the message and then = decide to modify the down bit before forwarding to the second router, if an= y.

Thanks.

-John

On Feb 23, 2010, at 6:09 AM, Calin Crisan wrote:

> =A0 =A0 Hi,
>
> =A0 =A0 Supposing a simple scenario where a node wants to send a packe= t to another node within its subdag, thus having a greater rank. The source= node, who acts as a host in this case, is supposed to set the flow label&#= 39;s bits to 0, including the "Down" bit. The first router in the= path will however have a greater rank, and so it will detect a first forwa= rding inconsistency. Is this OK?
>
> =A0 =A0 Thanks,
>
> =A0 =A0 Calin Crisan.
>
> ________________________________________= _______
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu= .edu/~jgko


--00151747927aab68c40480484be8-- From alexandru.petrescu@gmail.com Tue Feb 23 10:08:29 2010 Return-Path: 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 67C293A848E for ; Tue, 23 Feb 2010 10:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 yh40wiXYXbNf for ; Tue, 23 Feb 2010 10:08:28 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 239AA3A8497 for ; Tue, 23 Feb 2010 10:08:26 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id F3188D480DE; Tue, 23 Feb 2010 19:10:25 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id BC877D481B7; Tue, 23 Feb 2010 19:10:22 +0100 (CET) Message-ID: <4B841A0C.302@gmail.com> Date: Tue, 23 Feb 2010 19:10:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: MiJeom Kim References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <4B7EFD56.9090408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100223-1, 23/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:08:29 -0000 Yes, I am interested in listening to more opinions me too. Le 23/02/2010 08:40, MiJeom Kim a écrit : > Hi, Alex, > > I still think that millisecond is better since micro-second is too > high precision for LLNs considering that most links are relatively > slow in LLNs. Even for the lower bound, difference of 1 millisecond > seems to be fine. Difference between 0 millisecond latency and 1 > millisecond latency seems good enough for LLN applications. > Micro-second is okay, but I am just considering the trade-off, > overhead to express that precision and accuracy. WEll I believe the upper bound 2^32 milliseconds may be way too large... maybe it's the time it takes light to travel the Universe or so. If the upper bound is too large and the lower bound not large enough maybe we could move the window to better accommodate both. Something like uint16_t (unsigned integer on 16 bit) micro-seconds. Just an idea floating around. > Regarding baud, you mean using it as throughput metric instead of > bytes per second? I prefer bytes per second since baud changes with > modulation methods. And the bytes-per-second don't change with the modulation method? I believe they do too (e.g. WCDMA gives 256kbit/s where TDMA offers only a quarter of it). Or maybe modulation method means the other typical serial links parameters like stop bits, data bits (7 or 8), etc.? I think these could indeed lead to a different byte-per-second were they applied to the same baud rate. In this case we could use them as additional parameters encoded in the metric. E.g. two links with same baudrate but different data bits (7 or 8) give two different preferences for the routing protocol. Listening, Alex > > How about listening to more opinions? > > Thanks, Mijeom. > > On Sat, Feb 20, 2010 at 6:06 AM, Alexandru Petrescu > wrote: >> I hope I get this straight... you're proposing to express latency >> in units of milliseconds, i.e. micro-second precision may get lost >> or so(?) >> >> Le 19/02/2010 09:49, MiJeom Kim a écrit : >>> >>> Hi, all, >>> >>> It's time to close on the #18. I think that throughput and >>> latency can be better presented by unsigned integers as the >>> below justification wrote. Latency can be expressed in units of >>> milliseconds and throughput can be expressed in bytes per second. >>> If you don't have any objection, let me close it. >> >> Sure I object to expressing latency as units of milliseconds, in a >> 32bit integer, because there commonly exist Round-Trip Times for >> 802.11g in the range of micro-seconds, i.e. fractions of >> milliseconds - are they lost? >> >>> Please send me your comments on the issue. >>> >>> Thanks, Mijeom. >>> >>> >>> >>> On Sun, Nov 15, 2009 at 7:30 PM, roll issue >>> tracker wrote: >>>> >>>> #18: Numeric Ranges in Routing Metric >>>> >>>> --------------------------------+------------------------------------------- >>>> >>>> >>>> >> >>>> >>>> >>>> Reporter: jpv@… | Owner: jpv@… >>>> >>>> Type: defect | Status: new Priority: minor >>>> | Milestone: Component: routing-metrics | Version: >>>> Severity: Active WG Document | Keywords: >>>> >>>> --------------------------------+------------------------------------------- >>>> >>>> >>>> >> >>>> >>>> >>>> This ticket is related to the Numeric Ranges in Routing Metric. >>>> >>>> Here is the original thread: >>>> >>>> I mentioned it during the roll meeting Tuesday, but I think >>>> it's probably worth documenting the thought in a little more >>>> technical detail. The routing metrics right now include 32-bit >>>> floating point numbers for latency and throughput. Since these >>>> numbers are much more likely to be added or compared rather >>>> than multiplied, fixed point rather than floating point is >>>> likely to be a better choice of representation. For example, >>>> for normalized positive 32-bit IEEE 754 numbers, the maximum >>>> number is about 3.4e38 and the minimum is about 1.2e-38. For >>>> reference, the age of universe in milliseconds (taking the high >>>> end of NASA's most recent estimate) is only 4.4e20 and the time >>>> it takes to travel the distance across an electron (Lorentz >>>> diameter for you physics heads) is about 1.9e-20 ms. A >>>> negative latency would seem to imply that packets appear before >>>> they're sent which is probably not practical. If instead, >>>> latency were a 32-bit unsigned integer in units of >>>> milliseconds,we'd still be able to go from 0 or 1 milliseconds >>>> up to almost 1200 hours if my math is right. That should be >>>> plenty for any practical network. >> >> YEs the upper bound of the latency seems to be set straight (max >> latency to be a huge number). A huge latency would correspond to a >> very slow link... >> >> But the lower bound, i.e. a very fast link? (micro-seconds RTT of >> 802.11g). >> >> Also, how about expressing something in _baud_ somewhere because it >> is very common on the slowest serial links (e.g. 150baud, 300baud, >> 600baud...) >> >> Whereas latency and throughput are typical metrics for high-speed >> links such as 1Mbps, 1GBps, etc. >> >> Alex >> >> >> I haven't done >>>> >>>> so but I suspect that we could do the same thing with >>>> throughput. >>>> >>>> -- Ticket >>>> URL: >>>> 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 mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From hrogge@googlemail.com Tue Feb 23 10:18:54 2010 Return-Path: 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 071D33A8497 for ; Tue, 23 Feb 2010 10:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] 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 Jhu+Fgeg9F+P for ; Tue, 23 Feb 2010 10:18:53 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A9A5C3A8182 for ; Tue, 23 Feb 2010 10:18:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so4406eyd.51 for ; Tue, 23 Feb 2010 10:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=teqej/Qud2rKVehjWxkduQsaJCm05/Y1hfxicsfmxzI=; b=dRGj/bS8bTNxoCKpKBN6wyngrzApfn0h7rGbzwAMVUgOlFJXEQ6KozUXPylRzAyaDU lAUBlJb9XnD+WlfXhK7q7FM/lDDj8dB9JebxOiwZkFgjyiyyrx2x7mwUJwmzzIEsPenq T2bPQArqRpRnHnRmXlGF5ya0vVtewfKlA23AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=WyfYpcDLgHSQ3KFjBC70RtozR5upv6jf4XFUjQqkwJA/xhwC2/ck95yrpgl4kGLsDn F5mwZ4xiuckQHy8GGYRvrvSdIy/ZrcKjvJGtwDn8sBucMWNNeeGNYsia5jXmT7PC+7m1 cN9x5/ipCqJ4+3qdyEo13Hu+UcLoixELvEGxE= Received: by 10.213.49.133 with SMTP id v5mr844668ebf.90.1266949250983; Tue, 23 Feb 2010 10:20:50 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm13452075eyh.16.2010.02.23.10.20.48 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 10:20:49 -0800 (PST) From: Henning Rogge To: roll@ietf.org Date: Tue, 23 Feb 2010 19:20:43 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.32-gentoo-r6; KDE/4.4.0; x86_64; ; ) References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <4B841A0C.302@gmail.com> In-Reply-To: <4B841A0C.302@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2187424.ddFroTSLfS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002231920.48118.hrogge@googlemail.com> Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:18:54 -0000 --nextPart2187424.ddFroTSLfS Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Am Dienstag 23 Februar 2010 19:10:20 schrieb Alexandru Petrescu: > Yes, I am interested in listening to more opinions me too. >=20 > Le 23/02/2010 08:40, MiJeom Kim a =E9crit : > > Hi, Alex, > >=20 > > I still think that millisecond is better since micro-second is too > > high precision for LLNs considering that most links are relatively > > slow in LLNs. Even for the lower bound, difference of 1 millisecond > > seems to be fine. Difference between 0 millisecond latency and 1 > > millisecond latency seems good enough for LLN applications. > > Micro-second is okay, but I am just considering the trade-off, > > overhead to express that precision and accuracy. >=20 > WEll I believe the upper bound 2^32 milliseconds may be way too large... > maybe it's the time it takes light to travel the Universe or so. >=20 > If the upper bound is too large and the lower bound not large enough > maybe we could move the window to better accommodate both. >=20 > Something like uint16_t (unsigned integer on 16 bit) micro-seconds. > Just an idea floating around. Why not using an exponential encoding for delay too ? You would only need a= =20 byte or two and can express both small and large values. Who cares about microseconds if the delay is three seconds ? But microsecon= ds=20 might be important if you can measure them and the total delay is just 1.2m= s. Henning Rogge --nextPart2187424.ddFroTSLfS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkuEHIAACgkQcenvcwAcHWedbQCePeZ3Joj+2NLbUwZHepwgCHmD BtYAn2cspc3yTYLPI2D8UKdiigdfaO+w =7iKU -----END PGP SIGNATURE----- --nextPart2187424.ddFroTSLfS-- From Ruben.Salazar@landisgyr.com Tue Feb 23 10:19:15 2010 Return-Path: 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 0B4283A8497 for ; Tue, 23 Feb 2010 10:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] 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 jSYojTpPscc3 for ; Tue, 23 Feb 2010 10:19:14 -0800 (PST) Received: from mta2.cellnet.com (cnsipm1.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id CC6443A8182 for ; Tue, 23 Feb 2010 10:19:13 -0800 (PST) X-ASG-Debug-ID: 1266949274-72a102f4000c-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 113493E60BE for ; Tue, 23 Feb 2010 13:21:16 -0500 (EST) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id z5StvCYZ1BHFIXOl for ; Tue, 23 Feb 2010 13:21:16 -0500 (EST) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 13:21:14 -0500 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Tue, 23 Feb 2010 13:21:14 -0500 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Date: Tue, 23 Feb 2010 13:21:12 -0500 Message-ID: <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 thread-index: Acq0pCC+rD//0mgaRVGU9sCitaAlqAAAiO/AAAOSwoA= References: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> From: "Salazar, Ruben" To: "Pascal Thubert \(pthubert\)" , "Roger Alexander" , , "Sung Lee" , "Emmanuel Baccelli" X-OriginalArrivalTime: 23 Feb 2010 18:21:14.0389 (UTC) FILETIME=[FBBA6450:01CAB4B4] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1266949276 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: roll@ietf.org, "Dan Lang \(dlang\)" Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:19:15 -0000 Pascal, et al. This is definitely a great move in the right direction. We feel much better with the new IPR statement from Cisco. Regards Ruben Salazar, PhD Director of Research and Technology Landys+Gyr EMS Office: 678 258 3165 Cellular: 678 438 0063 ruben.salazar@landysgyr.com www.landisgyr.com manage energy better Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Tuesday, February 23, 2010 12:21 PM To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; = Emmanuel Baccelli Cc: roll@ietf.org; Dan Lang (dlang) Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of = IPR relating to draft-ietf-roll-rpl-06 Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco IPR debate: It is my understanding that this new declaration implements Roger's suggested compromise regarding Sung and Ruben's concerns, also relayed by Emmanuel. For reference: Roger suggested: http://www.ietf.org/mail-archive/web/roll/current/msg03045.html=20 Sung said: http://www.ietf.org/mail-archive/web/roll/current/msg03034.html Emmanuel said: http://www.ietf.org/mail-archive/web/roll/current/msg03063.html Ruben said: http://www.ietf.org/mail-archive/web/roll/current/msg03026.html=20 With this new IPR declaration, Cisco retains its defensive right in the context of RPL implementations *only*. By the new terms Cisco will not "walk freely anywhere" in someone else's "property". And the answer to Sung's question about "infringing patents NOT related to RPL" is now a NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does the exact same, which seems quite fair to me. For all I know, this is a major and somewhat exceptional step that should be recognized as such. And alternate terms based on RAND are still available to anyone who would prefer that way. Sadly, I'll still refrain from detailing which exact pieces RPL I personally think are covered by this IPR. I think it is pretty clear by now that this would not have a lot of value since 1) I'm not a lawyer, and 2) even less your own lawyer. Also the logic of claims somewhat escapes me, in particular when it comes to coverage. All I know is that the disclosures I was involved with detail ways to build trees and DAGs, propagate metrics and paint unicast and multicast routes along the DAGs, compress and expands routing headers, all things that are somewhat similar to RPL operations. I sincerely hope that this declaration will allow us to reach a positive consensus on the current poll about Cisco's IPR and move forward with RPL as soon as possible. Please let us know. Pascal -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 Sent: Tuesday, February 23, 2010 5:18 PM To: Pascal Thubert (pthubert); wintert@acm.org; rpl-authors@external.cisco.com Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1270/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06." The IETF Secretariat From yoav@yitran.com Tue Feb 23 10:34:26 2010 Return-Path: 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 45DCF3A84BB for ; Tue, 23 Feb 2010 10:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 P28a74KHkFgf for ; Tue, 23 Feb 2010 10:34:25 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 923033A84D1 for ; Tue, 23 Feb 2010 10:34:24 -0800 (PST) Received: from source ([74.125.82.180]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS4QgK2NubtRSu+U7oUpSrd6dfvgHwdaj@postini.com; Tue, 23 Feb 2010 10:36:28 PST Received: by wyb42 with SMTP id 42so661432wyb.39 for ; Tue, 23 Feb 2010 10:36:27 -0800 (PST) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq0YC7jhblIDNvAR4alvkNT33U3tAAVX2kw Date: Tue, 23 Feb 2010 20:36:28 +0200 Received: by 10.216.86.200 with SMTP id w50mr1434642wee.173.1266950187142; Tue, 23 Feb 2010 10:36:27 -0800 (PST) Message-ID: <01f301cab4b7$1cecdb60$56c69220$@com> To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:34:26 -0000 Hi, Just a thought. How about assigning a few bits to the exponent of seconds (so for example, -9 would mean resolution of nanoseconds, and 0 would mean resolution of seconds), and the rest for the value itself. If the upper bound becomes too small, consider lowering the number of bits for the exponent such that each increase would represent a scale of 1,000 or so up or down instead of 10 (so for -1 resolution is for millisec, for -2 the scale is microsec, etc.). Thanks, Yoav Date: Tue, 23 Feb 2010 16:40:59 +0900 From: MiJeom Kim Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric To: Alexandru Petrescu Cc: roll@ietf.org Hi, Alex, I still think that millisecond is better since micro-second is too high precision for LLNs considering that most links are relatively slow in LLNs. Even for the lower bound, difference of 1 millisecond seems to be fine. Difference between 0 millisecond latency and 1 millisecond latency seems good enough for LLN applications. Micro-second is okay, but I am just considering the trade-off, overhead to express that precision and accuracy. Regarding baud, you mean using it as throughput metric instead of bytes per second? I prefer bytes per second since baud changes with modulation methods. How about listening to more opinions? Thanks, Mijeom. On Sat, Feb 20, 2010 at 6:06 AM, Alexandru Petrescu wrote: > I hope I get this straight... you're proposing to express latency in > units of milliseconds, i.e. micro-second precision may get lost or so(?) > > Le 19/02/2010 09:49, MiJeom Kim a ?crit : >> >> Hi, all, >> >> It's time to close on the #18. I think that throughput and latency >> can be better presented by unsigned integers as the below >> justification wrote. Latency can be expressed in units of >> milliseconds and throughput can be expressed in bytes per second. If >> you don't have any objection, let me close it. > > Sure I object to expressing latency as units of milliseconds, in a 32bit > integer, because there commonly exist Round-Trip Times for 802.11g in > the range of micro-seconds, i.e. fractions of milliseconds - are they lost? > >> Please send me your comments on the issue. >> >> Thanks, Mijeom. >> >> >> >> On Sun, Nov 15, 2009 at 7:30 PM, roll issue >> tracker ?wrote: >>> >>> #18: Numeric Ranges in Routing Metric >>> >>> --------------------------------+----------------------------------------- -- >>> >>> >>> > Reporter: ?jpv@? ? ? ? ? ? ? ? | ? ? ? Owner: ?jpv@? >>> >>> Type: ?defect ? ? ? ? ? ? ?| ? ? ?Status: ?new Priority: ?minor | >>> Milestone: Component: ?routing-metrics ? ? | ? ? Version: Severity: >>> Active WG Document ?| ? ?Keywords: >>> >>> --------------------------------+----------------------------------------- -- >>> >>> >>> > This ticket is related to the Numeric Ranges in Routing Metric. >>> >>> Here is the original thread: >>> >>> I mentioned it during the roll meeting Tuesday, but I think it's >>> probably worth documenting the thought in a little more technical >>> detail. ?The routing metrics right now include 32-bit floating >>> point numbers for latency and throughput. ?Since these numbers are >>> much more likely to be added or compared rather than multiplied, >>> fixed point rather than floating point is likely to be a better >>> choice of representation. ?For example, for normalized positive >>> 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and >>> the minimum is about 1.2e-38. ?For reference, the age of universe >>> in milliseconds (taking the high end of NASA's most recent >>> estimate) is only 4.4e20 and the time it takes to travel the >>> distance across an electron (Lorentz diameter for you physics >>> heads) is about 1.9e-20 ms. ?A negative latency would seem to imply >>> that packets appear before they're sent which is probably not >>> practical. ?If instead, latency were a 32-bit unsigned integer in >>> units of milliseconds,we'd still be able to go from 0 or 1 >>> milliseconds up to almost 1200 hours if my math is right. ?That >>> should be plenty for any practical network. > > YEs the upper bound of the latency seems to be set straight (max latency > to be a huge number). ?A huge latency would correspond to a very slow > link... > > But the lower bound, i.e. a very fast link? ?(micro-seconds RTT of 802.11g). > > Also, how about expressing something in _baud_ somewhere because it is > very common on the slowest serial links (e.g. 150baud, 300baud, > 600baud...) > > Whereas latency and throughput are typical metrics for high-speed links > such as 1Mbps, 1GBps, etc. > > Alex > > > ?I haven't done >>> >>> so but I suspect that we could do the same thing with throughput. >>> >>> -- Ticket URL: >>> 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 mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From tzeta.tsao@ekasystems.com Tue Feb 23 10:42:23 2010 Return-Path: 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 A950B3A84D4 for ; Tue, 23 Feb 2010 10:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iSpITZ0OMQ1D for ; Tue, 23 Feb 2010 10:42:23 -0800 (PST) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id DA1BA3A84D3 for ; Tue, 23 Feb 2010 10:42:22 -0800 (PST) Received: (qmail 29083 invoked from network); 23 Feb 2010 18:44:23 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 23 Feb 2010 10:44:22 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: 7LdfV5oVM1mSszZ3e5qShzQykB_Ys9ai9DOzpg6c0KPb2QVN0wY3Chia X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B842203.9090009@ekasystems.com> Date: Tue, 23 Feb 2010 13:44:19 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: roll@ietf.org References: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> In-Reply-To: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:42:23 -0000 WG, This is a short summary of the high-level proposals from the security DT for securing RPL: 1. Protect the DIO, DIS, and DAO control messages; 2. Allow options of the security services to be provided to those control messages; 3. Use the sub-option fields of those messages to indicate which services are provided; 4. Specify a instance-wide layer-3 key as the base requirement. We will put out a draft to describe the details and are interested in any input. Thanks, Tzeta From alexandru.petrescu@gmail.com Tue Feb 23 10:51:47 2010 Return-Path: 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 1A8C028C1CF for ; Tue, 23 Feb 2010 10:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 gZvmtjqepHDv for ; Tue, 23 Feb 2010 10:51:46 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 006B628C1D9 for ; Tue, 23 Feb 2010 10:51:44 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5B0AAD480CC; Tue, 23 Feb 2010 19:53:43 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 32FAAD4816E; Tue, 23 Feb 2010 19:53:41 +0100 (CET) Message-ID: <4B842432.3010908@gmail.com> Date: Tue, 23 Feb 2010 19:53:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Henning Rogge References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <4B841A0C.302@gmail.com> <201002231920.48118.hrogge@googlemail.com> In-Reply-To: <201002231920.48118.hrogge@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100223-1, 23/02/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:51:47 -0000 Hello Henning, Le 23/02/2010 19:20, Henning Rogge a écrit : > Am Dienstag 23 Februar 2010 19:10:20 schrieb Alexandru Petrescu: >> Yes, I am interested in listening to more opinions me too. >> >> Le 23/02/2010 08:40, MiJeom Kim a écrit : >>> Hi, Alex, >>> >>> I still think that millisecond is better since micro-second is >>> too high precision for LLNs considering that most links are >>> relatively slow in LLNs. Even for the lower bound, difference of >>> 1 millisecond seems to be fine. Difference between 0 millisecond >>> latency and 1 millisecond latency seems good enough for LLN >>> applications. Micro-second is okay, but I am just considering the >>> trade-off, overhead to express that precision and accuracy. >> >> WEll I believe the upper bound 2^32 milliseconds may be way too >> large... maybe it's the time it takes light to travel the Universe >> or so. >> >> If the upper bound is too large and the lower bound not large >> enough maybe we could move the window to better accommodate both. >> >> Something like uint16_t (unsigned integer on 16 bit) >> micro-seconds. Just an idea floating around. > Why not using an exponential encoding for delay too ? You would only > need a byte or two and can express both small and large values. > > Who cares about microseconds if the delay is three seconds ? In this precision sense yes, I agree, who cares about microseconds if the delay is 3 seconds. (I have yet to see a link having 3seconds delay - inter-planetary maybe). But it's not just lack of precision. If an RPL node is presented with two different directly connected 802.11g interfaces and has to chose based on a metric expressing latency then it must be able to choose between micro-second values, not rounded-up second values (they'd all be equal). Yes, if delay is 3 seconds then the link is obviously not 802.11g but something else much slower, should be accommodated too. > But microseconds might be important if you can measure them and the > total delay is just 1.2ms. YEs, one can measure them the microseconds. Microseconds is what is used in linux kernel to keep time, and to measure time. Alex > > Henning Rogge From adam@sics.se Tue Feb 23 10:56:00 2010 Return-Path: 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 363F83A84C4 for ; Tue, 23 Feb 2010 10:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 NkvPy+ooItfO for ; Tue, 23 Feb 2010 10:55:59 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 3CDC83A7D92 for ; Tue, 23 Feb 2010 10:55:59 -0800 (PST) Received: from [10.1.1.144] (unknown [10.1.1.144]) by letter.sics.se (Postfix) with ESMTPS id 1C5CC400E6; Tue, 23 Feb 2010 19:58:01 +0100 (CET) Message-ID: <4B842533.4010804@sics.se> Date: Tue, 23 Feb 2010 19:57:55 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <4B841A0C.302@gmail.com> <201002231920.48118.hrogge@googlemail.com> <4B842432.3010908@gmail.com> In-Reply-To: <4B842432.3010908@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:56:00 -0000 Alexandru Petrescu wrote: > In this precision sense yes, I agree, who cares about microseconds if > the delay is 3 seconds. (I have yet to see a link having 3seconds delay > - inter-planetary maybe). FWIW, some low-power 802.15.4 mechanisms that use radio duty cycling to reduce the power consumption can have a delay that approaches seconds. If the receiver wakes up only once per second, the worst-case delay would be one second. /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From pal@cs.stanford.edu Tue Feb 23 11:26:41 2010 Return-Path: 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 42B223A7EE4 for ; Tue, 23 Feb 2010 11:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3UJY9OWNevBA for ; Tue, 23 Feb 2010 11:26:40 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id CA5AD3A7D92 for ; Tue, 23 Feb 2010 11:26:39 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nk0R1-0003ou-4w; Tue, 23 Feb 2010 11:28:43 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <01f301cab4b7$1cecdb60$56c69220$@com> Date: Tue, 23 Feb 2010 11:28:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01f301cab4b7$1cecdb60$56c69220$@com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:26:41 -0000 On Feb 23, 2010, at 10:36 AM, Yoav Ben-Yehezkel wrote: > Hi, >=20 > Just a thought. >=20 > How about assigning a few bits to the exponent of seconds (so for = example, > -9 would mean resolution of nanoseconds, and 0 would mean resolution = of > seconds), and the rest for the value itself. >=20 > If the upper bound becomes too small, consider lowering the number of = bits > for the exponent such that each increase would represent a scale of = 1,000 > or so up or down instead of 10 (so for -1 resolution is for millisec, = for > -2 the scale is microsec, etc.). Floating point can cause problems with gradient calculations. If the = dynamic range of values is greater than the dynamic range of the = floating point, then it can be that A + B =3D A when B > 0. This can = cause problems when transforming routing metrics to Rank unless we are = careful. That is, the min rank increase requirement will have to operate = on the mantissa independently of the exponent. Phil= From Jerald.P.Martocci@jci.com Tue Feb 23 11:54:22 2010 Return-Path: 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 D09C328C13F for ; Tue, 23 Feb 2010 11:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_00=-2.599, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] 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 sXYFV6Y3VYO0 for ; Tue, 23 Feb 2010 11:54:22 -0800 (PST) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with ESMTP id 8FFC628C0FA for ; Tue, 23 Feb 2010 11:54:21 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKS4Qy6LfOKhY/gVue9gFcuzdVLL1f0ONz@postini.com; Tue, 23 Feb 2010 11:56:26 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010022313564009-1189031 ; Tue, 23 Feb 2010 13:56:40 -0600 To: JP Vasseur MIME-Version: 1.0 X-KeepSent: 59260181:BF1CBB5F-862576D3:006D14DD; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 23 Feb 2010 13:56:27 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 02/23/2010 01:56:21 PM, Serialize complete at 02/23/2010 01:56:21 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/23/2010 01:56:40 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 02/23/2010 01:56:42 PM, Serialize complete at 02/23/2010 01:56:42 PM Content-Type: multipart/related; boundary="=_related 006D8844862576D3_=" Cc: roll@ietf.org Subject: [Roll] Cisco ROLL IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:54:22 -0000 This is a multipart message in MIME format. --=_related 006D8844862576D3_= Content-Type: text/html; charset="US-ASCII"
JCI's Legal team has reviewed the new IPR language as proposed from Dan Lang.  We like it!!!.  It looks very fair.

Thanks all that helped make this happen; it saves us redoing a lot of hard RPL work.

JCI wishes to change its vote to 'yes' -  let's proceed.

Jerry

--=_related 006D8844862576D3_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_06D6D44C07891EC0006D8844862576D3> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 006D8844862576D3_=-- From emmanuel.baccelli@gmail.com Tue Feb 23 13:22:54 2010 Return-Path: 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 73A9728C1A8 for ; Tue, 23 Feb 2010 13:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 mNwyj4CcDbRt for ; Tue, 23 Feb 2010 13:22:52 -0800 (PST) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by core3.amsl.com (Postfix) with ESMTP id 185C528C0DF for ; Tue, 23 Feb 2010 13:22:51 -0800 (PST) Received: by ewy27 with SMTP id 27so449129ewy.14 for ; Tue, 23 Feb 2010 13:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=wpgLTJeyXom25FNilSW4iczQKlUQuCzP98vg2AeGIvM=; b=nR8njkMbKgC1vBKWBdgfm4mu74hm02EuUUJ6gWVcp6DarKH9XtSfgxUOAkLGGIr6Mg Btz5N7AgIDgm9OADS2gi+pHYL7g+D/nMwMF/W1IAsNc2msDOXXwJQV7HnFyJwpn6Qnu6 2Fdlv/AsdXwsUynArMj9uQM6Zz//sLYg2+0ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ALwfB2ZQpPiwKFYRcR1S7NOJrRsN++LSd3bLzhcbcqjFmtBhIA1uC5Gao0RxfKXREi zWpxdAo8OOzRFOEb5b5Hh1Ke6Dw/TH0iVfK43wpBXAedlE/KTcikbqWXxRwv9plBiCnz k4IYZAUhnDEBiWRobFfw8K5j7R1fRaQdUj7rg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.100.68 with SMTP id x4mr176378ebn.33.1266960292235; Tue, 23 Feb 2010 13:24:52 -0800 (PST) In-Reply-To: <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> References: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> From: Emmanuel Baccelli Date: Tue, 23 Feb 2010 22:24:32 +0100 X-Google-Sender-Auth: b89274e51ee98d02 Message-ID: To: "Salazar, Ruben" Content-Type: multipart/alternative; boundary=00504502c7ba29cc6904804b2ec5 Cc: roll@ietf.org, "Dan Lang \(dlang\)" , Sung Lee Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 21:22:54 -0000 --00504502c7ba29cc6904804b2ec5 Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal, Hi Dan, same for me. The new terms seem much more reasonable, as far as I can tell from my non-lawyer perspective! Regards, Emmanuel On Tue, Feb 23, 2010 at 7:21 PM, Salazar, Ruben wrote: > Pascal, et al. > This is definitely a great move in the right direction. > We feel much better with the new IPR statement from Cisco. > Regards > > Ruben Salazar, PhD > Director of Research and Technology > Landys+Gyr EMS > Office: 678 258 3165 > Cellular: 678 438 0063 > ruben.salazar@landysgyr.com > www.landisgyr.com > manage energy better > > > > > Ruben Salazar > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > manage energy better > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, February 23, 2010 12:21 PM > To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel > Baccelli > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco > IPR debate: > > It is my understanding that this new declaration implements Roger's > suggested compromise regarding Sung and Ruben's concerns, also relayed > by Emmanuel. > > For reference: > Roger suggested: > http://www.ietf.org/mail-archive/web/roll/current/msg03045.html > Sung said: > http://www.ietf.org/mail-archive/web/roll/current/msg03034.html > Emmanuel said: > http://www.ietf.org/mail-archive/web/roll/current/msg03063.html > Ruben said: > http://www.ietf.org/mail-archive/web/roll/current/msg03026.html > > With this new IPR declaration, Cisco retains its defensive right in the > context of RPL implementations *only*. By the new terms Cisco will not > "walk freely anywhere" in someone else's "property". And the answer to > Sung's question about "infringing patents NOT related to RPL" is now a > NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does > the exact same, which seems quite fair to me. For all I know, this is a > major and somewhat exceptional step that should be recognized as such. > And alternate terms based on RAND are still available to anyone who > would prefer that way. > > Sadly, I'll still refrain from detailing which exact pieces RPL I > personally think are covered by this IPR. I think it is pretty clear by > now that this would not have a lot of value since 1) I'm not a lawyer, > and 2) even less your own lawyer. Also the logic of claims somewhat > escapes me, in particular when it comes to coverage. All I know is that > the disclosures I was involved with detail ways to build trees and DAGs, > propagate metrics and paint unicast and multicast routes along the DAGs, > compress and expands routing headers, all things that are somewhat > similar to RPL operations. > > I sincerely hope that this declaration will allow us to reach a positive > consensus on the current poll about Cisco's IPR and move forward with > RPL as soon as possible. Please let us know. > > Pascal > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: Tuesday, February 23, 2010 5:18 PM > To: Pascal Thubert (pthubert); wintert@acm.org; > rpl-authors@external.cisco.com > Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; > jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org > Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-02-23 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1270/). The title of the IPR > disclosure is "Cisco's Statement of IPR relating to > draft-ietf-roll-rpl-06." > > The IETF Secretariat > > > > --00504502c7ba29cc6904804b2ec5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, Hi Dan,
same for me. The new terms seem much more reasonable,= as far as I can tell from my non-lawyer perspective!
Regards,
Emmanu= el

On Tue, Feb 23, 2010 at 7:21 PM, Salaz= ar, Ruben <Ruben.Salazar@landisgyr.com> wrote:
Pascal, et al. This is definitely a great move in the right direction.
We feel much better with the new IPR statement from Cisco.
Regards

Ruben Salazar, PhD
Director of Research =A0and Technology
Landys+Gyr EMS
Office: 678 258 3165
Cellular: 678 438 0063
ruben.salazar@landysgyr.com<= /a>
www.landisgyr.com
manage energy better




Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 1550
Rube= n.Salazar@landisgyr.com
www.landisgyr.com
manage energy better
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, February 23, 2010 12:21 PM
To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel Baccelli
Cc: roll@ietf.org; Dan Lang (dlang) Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of = IPR relating to draft-ietf-roll-rpl-06

Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco
IPR debate:

It is my understanding that this new declaration implements Roger's
suggested compromise regarding Sung and Ruben's concerns, also relayed<= br> by Emmanuel.

For reference:
Roger suggested:
http://www.ietf.org/mail-archive/web/roll/current/msg030= 45.html
Sung said:
http://www.ietf.org/mail-archive/web/roll/current/msg030= 34.html
Emmanuel said:
http://www.ietf.org/mail-archive/web/roll/current/msg030= 63.html
Ruben said:
http://www.ietf.org/mail-archive/web/roll/current/msg030= 26.html

With this new IPR declaration, Cisco retains its defensive right in the
context of RPL implementations *only*. By the new terms Cisco will not
"walk freely anywhere" in someone else's "property"= . And the answer to
Sung's question about "infringing patents NOT related to RPL"= is now a
NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does
the exact same, which seems quite fair to me. For all I know, this is a
major and somewhat exceptional step that should be recognized as such.
And alternate terms based on RAND are still available to anyone who
would prefer that way.

Sadly, I'll still refrain from detailing which exact pieces RPL I
personally think are covered by this IPR. I think it is pretty clear by
now that this would not have a lot of value since 1) I'm not a lawyer,<= br> and 2) even less your own lawyer. Also the logic of claims somewhat
escapes me, in particular when it comes to coverage. All I know is that
the disclosures I was involved with detail ways to build trees and DAGs, propagate metrics and paint unicast and multicast routes along the DAGs, compress and expands routing headers, all things that are somewhat
similar to RPL operations.

I sincerely hope that this declaration will allow us to reach a positive consensus on the current poll about Cisco's IPR and move forward with RPL as soon as possible. Please let us know.

Pascal


-----Original Message-----
From: IETF Secretariat [mailto:ietf-ip= r@ietf.org]
Sent: Tuesday, February 23, 2010 5:18 PM
To: Pascal Thubert (pthubert); wintert@a= cm.org;
rpl-authors@external.cisc= o.com
Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org;
jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org
Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR<= br> relating to draft-ietf-roll-rpl-06

Dear Pascal Thubert, Tim Winter, ROLL Team:

An IPR disclosure that pertains to your Internet-Draft entitled "RPL:<= br> IPv6 Routing Protocol for Low power and Lossy Networks"
(draft-ietf-roll-rpl) was submitted to the IETF Secretariat on
2010-02-23 and has been posted on the "IETF Page of Intellectual
Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/1270/). The title of the IPR
disclosure is "Cisco's Statement of IPR relating to
draft-ietf-roll-rpl-06."

The IETF Secretariat




--00504502c7ba29cc6904804b2ec5-- From tzeta.tsao@ekasystems.com Tue Feb 23 14:04:03 2010 Return-Path: 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 5213E3A8253 for ; Tue, 23 Feb 2010 14:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 B9VdLw2IFL8s for ; Tue, 23 Feb 2010 14:04:02 -0800 (PST) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 2872E28C235 for ; Tue, 23 Feb 2010 14:04:02 -0800 (PST) Received: (qmail 79579 invoked from network); 23 Feb 2010 22:06:03 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 23 Feb 2010 14:06:03 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: YWPhUSIVM1n9xrTn2OA67QLRiWi3pu3HTAYEQqGr38eP8CiZPYmtw8RkZyC3sqj9NAGJrUnnL8ghI0bQ3_OUtCHKwVN0egeW.1PPpBYn30h1gG9rpWeg9B8q8ZpnQ_.Zv40Om.20LObvpWTKyTHDoanYd4LD0q7WPAEjggaRWXBGTMTJPzuaECO8y1RCWtenTK26.0Pr03iaCpzcffxoPodKEe1Dj1rm61mrpuiSUHppsvKGESe6YE5QA.G_ncPV8CkIavtuqu_4FPAlYC9VW7xq2Ko.g7eQAcI0eTLlK9RvVEfh_lS7HtHO9d0_LVa3.5_vfoZW_7RG1bkwF7HldrffVVdQS6_NTRLAYF3Fiz7qTY7F2hzo.BDlK6aDmQJTMjcmcpOXWt0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B84514B.4010707@ekasystems.com> Date: Tue, 23 Feb 2010 17:06:03 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: ROLL WG References: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> <4B842203.9090009@ekasystems.com> <4B8440DB.6060006@gmail.com> In-Reply-To: <4B8440DB.6060006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 22:04:03 -0000 Hi Alex, The DT will certainly address message authentication/integrity protection, among other issues. Here is only my own thinking about using IPsec for RPL. Mainly, I have doubts on setting up security policy so that security association can be established autonomously. In fact, that problem is what RFC3971: SEND was meant to address. But SEND prescribed quite some heavy mechanisms; for example, RSA is mandated, making it unsuitable for RPL. Regards, Tzeta Alexandru Petrescu wrote: > Hello Tzeta, > > Thank you for the update. > > I was wondering whether AH of IPSec is going to be used to protect RPL > messages. > > Alex > > Le 23/02/2010 19:44, Tzeta Tsao a écrit : >> WG, >> >> This is a short summary of the high-level proposals from the security DT >> for securing RPL: >> >> 1. Protect the DIO, DIS, and DAO control messages; >> 2. Allow options of the security services to be provided to those >> control messages; >> 3. Use the sub-option fields of those messages to indicate which >> services are provided; >> 4. Specify a instance-wide layer-3 key as the base requirement. >> >> We will put out a draft to describe the details and are interested in >> any input. >> >> Thanks, >> Tzeta >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > From alexandru.petrescu@gmail.com Tue Feb 23 14:21:21 2010 Return-Path: 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 2AD9C28C1C5 for ; Tue, 23 Feb 2010 14:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 n2PB8Ys3gH4m for ; Tue, 23 Feb 2010 14:21:20 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 143873A8314 for ; Tue, 23 Feb 2010 14:21:18 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id F18A0D48130 for ; Tue, 23 Feb 2010 23:23:19 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id F1D46D48114 for ; Tue, 23 Feb 2010 23:23:16 +0100 (CET) Message-ID: <4B845551.10905@gmail.com> Date: Tue, 23 Feb 2010 23:23:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> <4B842203.9090009@ekasystems.com> <4B8440DB.6060006@gmail.com> <4B84514B.4010707@ekasystems.com> In-Reply-To: <4B84514B.4010707@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100223-2, 23/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 22:21:21 -0000 Le 23/02/2010 23:06, Tzeta Tsao a écrit : > Hi Alex, > > The DT will certainly address message authentication/integrity > protection, among other issues. > > Here is only my own thinking about using IPsec for RPL. Mainly, I > have doubts on setting up security policy so that security > association can be established autonomously. I guess a Security Policy Database and SA database could be left off. I guess using a shared short key (32bit?), an old and little secure signature algorithm (MD4?) could be relevant for constrained devices. These could work with an AH header, without requiring the use of a SAdb or of a SPdb, yet be compatible with IPsec speakers. This is in a context where the key could be pre-shared on all devices, which is typical in bluetooth-like setups using the much less secure 4 to 6 digit PIN codes keyed on each device. > In fact, that problem is what RFC3971: SEND was meant to address. > But SEND prescribed quite some heavy mechanisms; for example, RSA is > mandated, making it unsuitable for RPL. Well ok, RSA may be heavy. I guess the constrained environment choices could be: between dynamically setting keys or statically pre-sharing; between enc and auth methods; between resource-hungry and less hungry algorithms. I guess all could fit within typical IPsec headers, offering an adequate level of protection. Just some thoughts, Alex > > Regards, Tzeta > > Alexandru Petrescu wrote: >> Hello Tzeta, >> >> Thank you for the update. >> >> I was wondering whether AH of IPSec is going to be used to protect >> RPL messages. >> >> Alex >> >> Le 23/02/2010 19:44, Tzeta Tsao a écrit : >>> WG, >>> >>> This is a short summary of the high-level proposals from the >>> security DT for securing RPL: >>> >>> 1. Protect the DIO, DIS, and DAO control messages; 2. Allow >>> options of the security services to be provided to those control >>> messages; 3. Use the sub-option fields of those messages to >>> indicate which services are provided; 4. Specify a instance-wide >>> layer-3 key as the base requirement. >>> >>> We will put out a draft to describe the details and are >>> interested in any input. >>> >>> Thanks, Tzeta _______________________________________________ >>> 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 > From pister@eecs.berkeley.edu Tue Feb 23 15:29:03 2010 Return-Path: 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 1C53028C111 for ; Tue, 23 Feb 2010 15:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JSSR+sk4ZJQO for ; Tue, 23 Feb 2010 15:29:02 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id E80CE28C3B8 for ; Tue, 23 Feb 2010 15:29:01 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o1NNV1KA001314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Feb 2010 15:31:02 -0800 (PST) Message-ID: <4B846535.80908@eecs.berkeley.edu> Date: Tue, 23 Feb 2010 15:31:01 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <5AECB0B4-4B37-4576-97C8-55BDBF325884@cisco.com> <4B842203.9090009@ekasystems.com> <4B8440DB.6060006@gmail.com> <4B84514B.4010707@ekasystems.com> <4B845551.10905@gmail.com> In-Reply-To: <4B845551.10905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 23:29:03 -0000 The current proposal is use AES128 in CCM* mode. ksjp Alexandru Petrescu wrote: > Le 23/02/2010 23:06, Tzeta Tsao a écrit : >> Hi Alex, >> >> The DT will certainly address message authentication/integrity >> protection, among other issues. >> >> Here is only my own thinking about using IPsec for RPL. Mainly, I >> have doubts on setting up security policy so that security >> association can be established autonomously. > > I guess a Security Policy Database and SA database could be left off. > > I guess using a shared short key (32bit?), an old and little secure > signature algorithm (MD4?) could be relevant for constrained devices. > These could work with an AH header, without requiring the use of a SAdb > or of a SPdb, yet be compatible with IPsec speakers. > > This is in a context where the key could be pre-shared on all devices, > which is typical in bluetooth-like setups using the much less secure 4 > to 6 digit PIN codes keyed on each device. > >> In fact, that problem is what RFC3971: SEND was meant to address. >> But SEND prescribed quite some heavy mechanisms; for example, RSA is >> mandated, making it unsuitable for RPL. > > Well ok, RSA may be heavy. > > I guess the constrained environment choices could be: between > dynamically setting keys or statically pre-sharing; between enc and > auth methods; between resource-hungry and less hungry algorithms. > > I guess all could fit within typical IPsec headers, offering an adequate > level of protection. > > Just some thoughts, > > Alex > >> >> Regards, Tzeta >> >> Alexandru Petrescu wrote: >>> Hello Tzeta, >>> >>> Thank you for the update. >>> >>> I was wondering whether AH of IPSec is going to be used to protect >>> RPL messages. >>> >>> Alex >>> >>> Le 23/02/2010 19:44, Tzeta Tsao a écrit : >>>> WG, >>>> >>>> This is a short summary of the high-level proposals from the >>>> security DT for securing RPL: >>>> >>>> 1. Protect the DIO, DIS, and DAO control messages; 2. Allow >>>> options of the security services to be provided to those control >>>> messages; 3. Use the sub-option fields of those messages to >>>> indicate which services are provided; 4. Specify a instance-wide >>>> layer-3 key as the base requirement. >>>> >>>> We will put out a draft to describe the details and are >>>> interested in any input. >>>> >>>> Thanks, Tzeta _______________________________________________ >>>> 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 From jreddy@ti.com Tue Feb 23 16:11:39 2010 Return-Path: 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 C94463A7C68 for ; Tue, 23 Feb 2010 16:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] 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 ULK1KPn8OTdR for ; Tue, 23 Feb 2010 16:11:36 -0800 (PST) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by core3.amsl.com (Postfix) with ESMTP id 5030228C200 for ; Tue, 23 Feb 2010 16:11:36 -0800 (PST) Received: from dlep35.itg.ti.com ([157.170.170.118]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id o1O0De2c001412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Feb 2010 18:13:40 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id o1O0DdUN022165 for ; Tue, 23 Feb 2010 18:13:39 -0600 (CST) Received: from dlee74.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1O0DdWI005601 for ; Tue, 23 Feb 2010 18:13:39 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Tue, 23 Feb 2010 18:13:39 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Tue, 23 Feb 2010 18:13:38 -0600 Thread-Topic: Roll Digest, Vol 25, Issue 42 Thread-Index: Acq0uijcYLZbrVMrQNaLfITYMes4KAAK41DQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Roll Digest, Vol 25, Issue 42 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 00:11:39 -0000 =20 JP, Adrian, I too like the new IPR statement from Cisco much better and would favor con= tinuing work on the current draft. -Regards, Joseph ------------------------------ Message: 2 Date: Tue, 23 Feb 2010 13:21:12 -0500 From: "Salazar, Ruben" Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 To: "Pascal Thubert \(pthubert\)" , "Roger Alexander" , , "Sung Lee" , "Emmanuel Baccelli" Cc: roll@ietf.org, "Dan Lang \(dlang\)" Message-ID: <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> Content-Type: text/plain; charset=3D"iso-8859-1" Pascal, et al. This is definitely a great move in the right direction. We feel much better with the new IPR statement from Cisco. Regards Ruben Salazar, PhD Director of Research and Technology Landys+Gyr EMS Office: 678 258 3165 Cellular: 678 438 0063 ruben.salazar@landysgyr.com www.landisgyr.com manage energy better Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Tuesday, February 23, 2010 12:21 PM To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel B= accelli Cc: roll@ietf.org; Dan Lang (dlang) Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR = relating to draft-ietf-roll-rpl-06 Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco IPR = debate: It is my understanding that this new declaration implements Roger's suggest= ed compromise regarding Sung and Ruben's concerns, also relayed by Emmanuel= . For reference: Roger suggested: http://www.ietf.org/mail-archive/web/roll/current/msg03045.html Sung said: http://www.ietf.org/mail-archive/web/roll/current/msg03034.html Emmanuel said: http://www.ietf.org/mail-archive/web/roll/current/msg03063.html Ruben said: http://www.ietf.org/mail-archive/web/roll/current/msg03026.html=20 With this new IPR declaration, Cisco retains its defensive right in the con= text of RPL implementations *only*. By the new terms Cisco will not "walk f= reely anywhere" in someone else's "property". And the answer to Sung's ques= tion about "infringing patents NOT related to RPL" is now a NO. Simply, Cis= co opens its IPR on RPL to anyone that reciprocally does the exact same, wh= ich seems quite fair to me. For all I know, this is a major and somewhat ex= ceptional step that should be recognized as such. And alternate terms based on RAND are still available to anyone who would p= refer that way. Sadly, I'll still refrain from detailing which exact pieces RPL I personall= y think are covered by this IPR. I think it is pretty clear by now that thi= s would not have a lot of value since 1) I'm not a lawyer, and 2) even less= your own lawyer. Also the logic of claims somewhat escapes me, in particul= ar when it comes to coverage. All I know is that the disclosures I was invo= lved with detail ways to build trees and DAGs, propagate metrics and paint = unicast and multicast routes along the DAGs, compress and expands routing h= eaders, all things that are somewhat similar to RPL operations. I sincerely hope that this declaration will allow us to reach a positive co= nsensus on the current poll about Cisco's IPR and move forward with RPL as = soon as possible. Please let us know. Pascal From jreddy@ti.com Tue Feb 23 16:21:55 2010 Return-Path: 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 0EFC93A852A for ; Tue, 23 Feb 2010 16:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599] 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 VvOKqW-MSs2k for ; Tue, 23 Feb 2010 16:21:53 -0800 (PST) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by core3.amsl.com (Postfix) with ESMTP id 475303A8520 for ; Tue, 23 Feb 2010 16:21:53 -0800 (PST) Received: from dlep36.itg.ti.com ([157.170.170.91]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id o1O0Nv8H008539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Feb 2010 18:23:57 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1O0NvPY020086 for ; Tue, 23 Feb 2010 18:23:57 -0600 (CST) Received: from dlee75.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1O0Nu35008084 for ; Tue, 23 Feb 2010 18:23:56 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee75.ent.ti.com ([157.170.170.72]) with mapi; Tue, 23 Feb 2010 18:23:56 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Tue, 23 Feb 2010 18:23:56 -0600 Thread-Topic: [Roll] An Update from the Security Design Team Thread-Index: Acq0uijcYLZbrVMrQNaLfITYMes4KAALOA7w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 00:21:55 -0000 =20 Hi Tzeta, Assuming that there is link layer security already available in the network= , do you envision any additional benefit that will be provided by the propo= sed RPL security ? -Thanks, Joseph ------------------------------ Date: Tue, 23 Feb 2010 13:44:19 -0500 From: Tzeta Tsao Subject: [Roll] An Update from the Security Design Team To: roll@ietf.org Message-ID: <4B842203.9090009@ekasystems.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed WG, This is a short summary of the high-level proposals from the security DT fo= r securing RPL: 1. Protect the DIO, DIS, and DAO control messages; 2. Allow options of the = security services to be provided to those control messages; 3. Use the sub-= option fields of those messages to indicate which services are provided; 4.= Specify a instance-wide layer-3 key as the base requirement. We will put out a draft to describe the details and are interested in any i= nput. Thanks, Tzeta From jeonggil.ko@gmail.com Tue Feb 23 18:23:43 2010 Return-Path: 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 981E628C23E for ; Tue, 23 Feb 2010 18:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 MiTfWJd7Lsta for ; Tue, 23 Feb 2010 18:23:42 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 55E7528C17F for ; Tue, 23 Feb 2010 18:23:42 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so1251259fga.13 for ; Tue, 23 Feb 2010 18:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=8loIACdcUI5ZH+i09i/Hn9a1QbFnfT9O92guR3f+N2g=; b=nR+OtIEnLGzHbWDR5pMKljXvDuDv0kc1DgjDrMF+mVwbNoNbjnxZ1Iiu2cIin7VHHe SGaBF2zIBif7V9VdA4NCvillb5JkCgjva1bpNpy2wUQRGkR9tk6/P6dl7vy6LapCjCLv qcYLsqvtj2cSGsW8DS4CVQ97P4lPK7nGAU3UU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=vS50tq0WbqUQ1/bV0SOVYHh1rSxaSHwEf1tUwFlB+a9Rm0aHsDEaIaKSZBCDkkBi6n nNvsD3YyqEP6sQrGZZ3GCiWmdzELnAxGS86GG+IBalNFnCOWrYrPLjKWgIzp1JvNR76f Vg3/JkfoF6oM1MKgAPQE7H7lkK+zk662idGRQ= Received: by 10.103.81.20 with SMTP id i20mr4961797mul.21.1266978343878; Tue, 23 Feb 2010 18:25:43 -0800 (PST) Received: from dnab4046eb.stanford.edu (DNab4046eb.Stanford.EDU [171.64.70.235]) by mx.google.com with ESMTPS id j10sm6728702mue.56.2010.02.23.18.25.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 18:25:42 -0800 (PST) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 18:25:37 -0800 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 02:23:43 -0000 Hi! I was reading through the downwards route section in draft 6 (section 6) = and had a few questions in mind. 1. How is the DAO rank (in Figure 11) computed and what does this rank = value represent? By having this rank value, does it mean that all nodes = keep a rank for the DODAG (constructed using DIO exchanges) separately = and also maintain rank values for each 'downwards tree' that it = participates in (for example if I have two nodes that rely on me to = receive downwards packets, I would be maintaining one DODAG rank and two = separate rank values for each of the two nodes)? Is this to assure that = the downwards packets will make 'forward' progress? Why can't this be = achieved with the DODAG rank values? 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing = forwarding node will append, on the DAO packet, the address of the = 'child' to the RRstack. Why should we add the address of the child and = not the node that is forwarding the packet itself? Is there an intuition = behind this design? If there is a reason for this design, how would I = retrieve the IP address of the previous hop (for sure it is not included = in the IP address fields unless I am the first hop of the node)? Sorry for the massive amount of question marks in the message but this = downwards route part is really confusing me :) Thanks for all your help in advance! -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jhui@archrock.com Tue Feb 23 18:39:50 2010 Return-Path: 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 55C0C28C215 for ; Tue, 23 Feb 2010 18:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 BUv+xJrc9zyo for ; Tue, 23 Feb 2010 18:39:49 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 85EB928C23E for ; Tue, 23 Feb 2010 18:39:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7A59CAF92C; Tue, 23 Feb 2010 18:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnU+MuWw-vyC; Tue, 23 Feb 2010 18:41:48 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id C9479AF929; Tue, 23 Feb 2010 18:41:47 -0800 (PST) Message-Id: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> From: Jonathan Hui To: JeongGil Ko (John) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 18:41:46 -0800 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 02:39:50 -0000 Hi John, On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > I was reading through the downwards route section in draft 6 > (section 6) and had a few questions in mind. > > 1. How is the DAO rank (in Figure 11) computed and what does this > rank value represent? By having this rank value, does it mean that > all nodes keep a rank for the DODAG (constructed using DIO > exchanges) separately and also maintain rank values for each > 'downwards tree' that it participates in (for example if I have two > nodes that rely on me to receive downwards packets, I would be > maintaining one DODAG rank and two separate rank values for each of > the two nodes)? Is this to assure that the downwards packets will > make 'forward' progress? Why can't this be achieved with the DODAG > rank values? One of the main purposes of including ranks towards downwards destinations in a DAO is so that a node receiving two DAOs for the same downwards destination can use rank to make a more intelligent decision if the rank differs (i.e. preferring the one with lesser rank). > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing > forwarding node will append, on the DAO packet, the address of the > 'child' to the RRstack. Why should we add the address of the child > and not the node that is forwarding the packet itself? Is there an > intuition behind this design? If there is a reason for this design, > how would I retrieve the IP address of the previous hop (for sure it > is not included in the IP address fields unless I am the first hop > of the node)? The IP address of the forwarding node is included in the IP header - it would be redundant to include the forwarding node's address in the RRstack as well. -- Jonathan Hui From pal@cs.stanford.edu Tue Feb 23 18:52:34 2010 Return-Path: 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 251AD3A82B0 for ; Tue, 23 Feb 2010 18:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 dK3IlTnguVp4 for ; Tue, 23 Feb 2010 18:52:33 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6DC293A829F for ; Tue, 23 Feb 2010 18:52:33 -0800 (PST) Received: from m600f36d0.tmodns.net ([208.54.15.96] helo=232.15.224.10.in-addr.arpa) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nk7OX-0007HY-M6; Tue, 23 Feb 2010 18:54:37 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> Date: Tue, 23 Feb 2010 18:54:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 02:52:34 -0000 On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: >=20 > Hi John, >=20 > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >=20 >> I was reading through the downwards route section in draft 6 (section = 6) and had a few questions in mind. >>=20 >> 1. How is the DAO rank (in Figure 11) computed and what does this = rank value represent? By having this rank value, does it mean that all = nodes keep a rank for the DODAG (constructed using DIO exchanges) = separately and also maintain rank values for each 'downwards tree' that = it participates in (for example if I have two nodes that rely on me to = receive downwards packets, I would be maintaining one DODAG rank and two = separate rank values for each of the two nodes)? Is this to assure that = the downwards packets will make 'forward' progress? Why can't this be = achieved with the DODAG rank values? >=20 > One of the main purposes of including ranks towards downwards = destinations in a DAO is so that a node receiving two DAOs for the same = downwards destination can use rank to make a more intelligent decision = if the rank differs (i.e. preferring the one with lesser rank). Let's back up -- the purpose is clear but how it achieves that purpose = isn't. How is this value computed/filled in? Should -07 specify this? Is = it correct that DAO Rank is the rank advertised in DIOs? Does that mean = that a node sending DAOs to multiple DAO parents may specify different = DAO Rank values. How does this work for aggregated prefixes? Phil= From jhui@archrock.com Tue Feb 23 19:20:33 2010 Return-Path: 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 CF5AE28C415 for ; Tue, 23 Feb 2010 19:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 8pgtvqKFVqt4 for ; Tue, 23 Feb 2010 19:20:24 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5415E28C41E for ; Tue, 23 Feb 2010 19:20:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4C776AF990; Tue, 23 Feb 2010 19:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-kDp0llPfxe; Tue, 23 Feb 2010 19:22:02 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id 76D33AF938; Tue, 23 Feb 2010 19:22:02 -0800 (PST) Message-Id: <44516837-62BD-4D98-AF91-E31092CF2601@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: <00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Feb 2010 19:22:01 -0800 References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> <00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:20:33 -0000 On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: > >> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >> >> One of the main purposes of including ranks towards downwards >> destinations in a DAO is so that a node receiving two DAOs for the >> same downwards destination can use rank to make a more intelligent >> decision if the rank differs (i.e. preferring the one with lesser >> rank). > > Let's back up -- the purpose is clear but how it achieves that > purpose isn't. How is this value computed/filled in? Should -07 > specify this? Is it correct that DAO Rank is the rank advertised in > DIOs? Does that mean that a node sending DAOs to multiple DAO > parents may specify different DAO Rank values. How does this work > for aggregated prefixes? I think it's clear that the DAO mechanism is not nearly as fleshed out as the DIO mechanism. The text is intentionally vague (notice all the 'may' text around it) about what the DAO Rank field can contain - it is simply a place-holder acknowledging the fact that we may want to convey some notion of cost towards the destination. DAO aggregation is something we haven't even discussed yet. But even before that, we need to back up even further and analyze whether the basic DAO mechanism fits our needs. There is concern from the ROLL WG (including myself) on how DAOs are sent or triggered - specifically in cases where a network only caches a subset of the DAO information being sent around. The main challenge is that the WG would like to see a solution that allows both networks where all nodes maintain downward routes and networks where only the root maintains downward routes. Some would even like to see networks that where only some nodes maintain some subset of downward routes. Unfortunately, there's some added complexity in requiring an implementation to support these different modes (e.g. nodes always have to maintain state to know when to trigger DAOs from their children). There's certainly a number of dependencies that are not so obvious at first blush (e.g. a single DAG parent change could cause DAOs to be sent by every node in that sub-DAG). -- Jonathan Hui From tzeta.tsao@ekasystems.com Wed Feb 24 06:38:38 2010 Return-Path: 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 1F6C628C192 for ; Wed, 24 Feb 2010 06:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 weTdEz4DDBGO for ; Wed, 24 Feb 2010 06:38:37 -0800 (PST) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 4DF9F28C0D8 for ; Wed, 24 Feb 2010 06:38:37 -0800 (PST) Received: (qmail 5184 invoked from network); 24 Feb 2010 14:40:41 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 24 Feb 2010 06:40:41 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: pMUr_AUVM1k3lzQHLb8B.5fBwOmg.UeZBWoZiojULMF1OWVVQFwbWXHRN4KMOsNznVOEwPvwjEvYzrRBZdNNPBFCWJtGALBtfMDV.fRm9RdyYZMijEhX6bJ78uFBxpws7DXwAM28oblWm_wdN7nLjoKcJFL04bsoMzO_.EncaI_.ipmxgR8S_IFbTQAgVmY3eWNNhYv.B01zkmALid6dv8D9MeOcQlZLG14tSqeiWzaH2di5ukxpnJc9N0cBfwEdS6irGXfM1UF_JH3kgq.rirdh6R9i7shwub6.IZHzFV8zfLQPFUc_BniC9ufB9HAbH7PTPQ.6yYVPr.DAg.P38W57IaNGq4gUW19Izz3OEUn.6jsj6ovCVWnxWmJMPqAruwIxp1Eh1cKXVmhtSiQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B853A68.3080100@ekasystems.com> Date: Wed, 24 Feb 2010 09:40:40 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: "Reddy, Joseph" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] An Update from the Security Design Team X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 14:38:38 -0000 Hi Joseph, Indeed, there may or may not be link layer security, while there may be benefit to have layers of security. A design that leaves the decision to the user seems to be the best compromise. Regards, Tzeta Reddy, Joseph wrote: > > Hi Tzeta, > > Assuming that there is link layer security already available in the network, do you envision any additional benefit that will be provided by the proposed RPL security ? > > -Thanks, Joseph > > > ------------------------------ > > Date: Tue, 23 Feb 2010 13:44:19 -0500 > From: Tzeta Tsao > Subject: [Roll] An Update from the Security Design Team > To: roll@ietf.org > Message-ID: <4B842203.9090009@ekasystems.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > WG, > > This is a short summary of the high-level proposals from the security DT for securing RPL: > > 1. Protect the DIO, DIS, and DAO control messages; 2. Allow options of the security services to be provided to those control messages; 3. Use the sub-option fields of those messages to indicate which services are provided; 4. Specify a instance-wide layer-3 key as the base requirement. > > We will put out a draft to describe the details and are interested in any input. > > Thanks, > Tzeta > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Wed Feb 24 08:49:30 2010 Return-Path: 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 7101528C1DC for ; Wed, 24 Feb 2010 08:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.652 X-Spam-Level: X-Spam-Status: No, score=-9.652 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 cCNJVXXqfsKF for ; Wed, 24 Feb 2010 08:49:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B569E28C182 for ; Wed, 24 Feb 2010 08:49:27 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: DAO operations.pptx : 43830 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE/ohEtAZnwN/2dsb2JhbACbEXOkU5hGhHIEjjI X-IronPort-AV: E=Sophos;i="4.49,533,1262563200"; d="xml'?pptx'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="88672228" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2010 16:51:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1OGpXPJ010522; Wed, 24 Feb 2010 16:51:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 17:51:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAB571.9E2B91AA" Date: Wed, 24 Feb 2010 17:51:29 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151BB99@XMB-AMS-107.cisco.com> In-Reply-To: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Questions on DAO operations Thread-Index: Acq0+vTBYd++PjEdQWawKNkklJHAzwAan6hQ References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "JeongGil Ko (John)" X-OriginalArrivalTime: 24 Feb 2010 16:51:32.0827 (UTC) FILETIME=[9E7AF2B0:01CAB571] Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 16:49:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB571.9E2B91AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John and Jonathan. I think Question 2 deserves a few more words: the short answer=20 --------------------- The point is that the record route in the DAO is for the (sole) use of the recorder, when the RR stack has become a routing header in a packet on the way back to Destination. The packet will have to go between the recorder and loose Source Record Route next_hop in the DAO stack, and the question is whether the routing info to get there will have to be picked from the routing header in the packet, or can be found in the routing table of the recorder. The IP next-hop to get to the LSRR next-hop is definitively the source of the DAO, that's what the DAO is all about. So the question is whether the recorder has a route to the LSRR next-hop via the source of the packet or not.=20 If not, then the recorder needs to insert the next-hop information it will need as the new LSRR next-hop on top of the LSRR stack. The long answer ------------------- requires an example, illustrated in the slides attached.=20 Let us consider a DAO that is originated from Dest. No one below Parent decided to cache the specific source route A->B->C->Dest. Because nodes do not cache everything, it is acceptable, though, that DAO routing states are installed all the way between child and A. The result is that there's no need to additional source route to reach A from child inside .=20 We'll see how that works by forwarding the DAO up one more time, child to parent, and see what happens whether the parent has a DAO route to A via Child or not. Childs sends this to parent: =20 IP header: Source IP =3D Child Dest IP =3D Parent DAO: dest =3D Dest Stack =3D A, B, C Case 1: Parent does a route look up for A, and that does resolves via child. Either parent is missing a routing state, or its routing state is obsolete. Parent updates the Stack that is now Child, A, B, C. Case 1a) If parent decides to cache for Dest, then it stores Dest via Child, A, B, C.=20 Parent forwards the DAO to its ancestor as: IP header: Source IP =3D parent Dest IP =3D Ancestor DAO:=20 dest =3D Dest Stack =3D The result is that packets to Dest should come back without a routing header, with the IP header destination set to Dest. When Parent forwards a packet to Dest, it changes the destination to child, and inserts a RH A, B, C, Dest. and proceeds forwarding the packet. Child being connected, the lookup resolved immediately and the packet is passed to child. Case 1b) If parent decides not to cache for Dest, then it forwards to its own ancestor IP header: Source IP =3D parent Dest IP =3D Ancestor DAO:=20 dest =3D Dest Stack =3D child, A, B, C The result is that packets to Dest should come back with a routing header child, A, B, C, and with the IP header destination set to parent or child, depending on whether ancestor has a route to child via parent or not. If Parent is the destination of the packet, then it consumes the next entry in the RH, thus setting child as the destination in the IP header, and proceeds forwarding the packet.=20 In any case, child being connected, the lookup is resolved immediately and the packet is passed to child. Case 2: Parent does a route look up for A, and that resolves via child. Great, we have a routing state that's consistent. Case 2a) If parent decides to cache for Dest, then it stores Dest via A, B, C.=20 Parent forwards the DAO to its ancestor as: IP header: Source IP =3D parent Dest IP =3D Ancestor DAO:=20 dest =3D Dest Stack =3D The result is that packets to Dest should come back without a routing header, with the IP header destination set to Dest When Parent forwards a packet to Dest, it changes the destination to A , and inserts a RH B, C, Dest , and proceeds forwarding the packet now destined to A. A route lookup of A resolves in child (as verified above), so the packet can be passed to child. Case 2b) If parent decides not to cache for Dest, then it forwards to its own ancestor IP header: Source IP =3D parent Dest IP =3D Ancestor DAO:=20 dest =3D Dest Stack =3D A, B, C The result is that packets to Dest should come back with a routing header A, B, C, and with the IP header destination set to parent or child, depending on whether ancestor has a route to child via parent or not. Parent being the destination of the packet, to it consumes the next entry in the RH, iow sets A as the destination, and proceeds forwarding the packet now destined to A. A route lookup of A resolves in child (as verified above), so the packet can be passed to child. Note finally for the gory side of it that A, B, and C etc... are not link local addresses. They have to be global or ULA, because they can be used multihop. An implementation might decide to store the connected routes via the link locals, and the global of the children via the link local of the children. If that's so "Parent does a route look up for A, and that does resolves via child" must be understood as lookup for A and lookup for child both resolve in the same address, that is child's link local address. This looks a bit complex said that way. I hope the slideware attached helps. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, February 24, 2010 3:42 AM To: JeongGil Ko (John) Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations Hi John, On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > I was reading through the downwards route section in draft 6 (section=20 > 6) and had a few questions in mind. > > 1. How is the DAO rank (in Figure 11) computed and what does this rank > value represent? By having this rank value, does it mean that all=20 > nodes keep a rank for the DODAG (constructed using DIO > exchanges) separately and also maintain rank values for each=20 > 'downwards tree' that it participates in (for example if I have two=20 > nodes that rely on me to receive downwards packets, I would be=20 > maintaining one DODAG rank and two separate rank values for each of=20 > the two nodes)? Is this to assure that the downwards packets will make > 'forward' progress? Why can't this be achieved with the DODAG rank=20 > values? One of the main purposes of including ranks towards downwards destinations in a DAO is so that a node receiving two DAOs for the same downwards destination can use rank to make a more intelligent decision if the rank differs (i.e. preferring the one with lesser rank). > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing=20 > forwarding node will append, on the DAO packet, the address of the=20 > 'child' to the RRstack. Why should we add the address of the child and > not the node that is forwarding the packet itself? Is there an=20 > intuition behind this design? If there is a reason for this design,=20 > how would I retrieve the IP address of the previous hop (for sure it=20 > is not included in the IP address fields unless I am the first hop of=20 > the node)? The IP address of the forwarding node is included in the IP header - it would be redundant to include the forwarding node's address in the RRstack as well. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CAB571.9E2B91AA Content-Type: application/octet-stream; name="DAO operations.pptx" Content-Transfer-Encoding: base64 Content-Description: DAO operations.pptx Content-Disposition: attachment; filename="DAO operations.pptx" UEsDBBQABgAIAAAAIQBSFT0f+gEAAMwNAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE V9ty2jAQfe9M/sGj1wwWpGlCO5g8JM1TL8yEfIBqL6BWljTSQsPfd32BMQwNF9vjFzPC1tmjs7s+ 69HDW6qCFTgvjY7YIOyzAHRsEqnnEXudPveGLPAodCKU0RCxNXj2ML76MJquLfiAdmsfsQWi/cK5 jxeQCh8aC5ruzIxLBdLSzbkV8R8xB37T79/x2GgEjT3MMNh49JMIOJlAMBEOf4iU4nBrkXtFf34T a7NEX13ch4TOgscCJmMSMWGtkrFAOgdf6WSPQ8/MZjKGxMTLlCKH1oGn3/zxVIWVQNcZND+f07Br Tt+FR8pjoVOxGLTCqcA+SaeSzcdWeJzD4LYTBlmVTZyxvunoW+CTNDjQQe3oUQS6lNOnplVqoKvv uuZUdlA7nXxSpkoGN60ocYwBkqEAz6/1JchhjkWsFE158qKq2zl/vY5p5726y+kJZmKpMPj6RpZd TAm/Lcz33FemmbnnN8g7D+xxoPzeniOOXU4MIe3MbdovpPWb7B2I8P5IcMTVq/NA04W+g50KqTeH OHfsqd8BVSqnjz00NeUuxiljtcWBrI4SSHqWjBEcStgm9X96oPil4AXXCho30gr0xVnpKi3vTciD fu1EXVYrGamVhL+tjD1b4Etz9bkjVbYdFBsH53PYvAqz3Qf6huffYuN/AAAA//8DAFBLAwQUAAYA CAAAACEAaPh0oQUBAADiAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyS20oDMRCG7wXfIcx9N9sq ItJsb0Toncj6AGMyuxvdHEim0r69oeBhYS2CvZzTP1/yz3qzd6N4p5Rt8AqWVQ2CvA7G+l7Bc/uw uAWRGb3BMXhScKAMm+byYv1EI3IZyoONWRQVnxUMzPFOyqwHcpirEMmXSheSQy5h6mVE/YY9yVVd 38j0UwOaiabYGgVpa65AtIdYNv9HWzpiNMgodUi0iKmQJbblLaLF1BMrMEE/lnQ+dlSFGuQ80Oq8 QDzs3ItHO86gfNWq10j9b0DLvwOFrrOa7oPeOfI8Y4KcdnwzxcgyJspl7Gj7qR+6PicQ7Zm8IXPa NIzxk0hOLrP5AAAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUxLnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S 6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5 yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AM nYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEA S/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjf TqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1Kaq tirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZW X3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlMy54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHic HebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOO e6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848K xYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9 iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0Izugt DsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwx xdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA //8DAFBLAwQUAAYACAAAACEA3fONtisBAABfBQAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24u eG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lF9LwzAUxd8Fv0PJ u0vbzfmHpXsRYQ+C6PwAsb1tg2kScuO0397Q6rrJiC/Bp3JO6Lk/7oG7Wn92MtmBRaEVI9ksJQmo UldCNYy8bO8vrkmCjquKS62AkR6QrIvzs9UTSO78T9gKg4lPUchI65y5pRTLFjqOM21A+Zda2447 L21DDS/feAM0T9MltYcZpDjKTDYVI3ZT+fnb3vjJf2fruhYl3OnyvQPlToygznOBD+S2AcfIIEcz m3lQQk8zzGMyoBTVAcMgkQ6fPARxFRNiJ+Dj0WqD0zL2VggijwkR2ESwjiw6xANHB3baxUA2mt/V jCKItYyJZSzgr4L2Vqigy5gQgYIWIYjFP0HMQxA3MSEcf5Xw7Hrpz990PibzB4QencXiCwAA//8D AFBLAwQUAAYACAAAACEAGXTZxWECAAD5DAAAFAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JZdjpsw EMffK/UOyK9VlkD4CgpZqa0irZRKUZM9gBcmCVpjkO3QZE/fsXECTVRpD8AbZmb+M/PzYLx4PlfM aUHIsuYZ8Z6mxAGe10XJDxl53a0mCXGkorygrOaQkQtI8rz8+mXRpI0ACVxRhaEOynCZ0owclWpS 15X5ESoqn+oGONr2taiowqU4uIWgf1C+Yq4/nUZuRUtObLz4THy935c5/KzzU4XpOxEBzNQhj2Uj r2rNZ9SGXfxbkqQtbE9vEtSq5koiHbLEtiUrflGpQLwUa6nu3jhlkRHfC+IgmUUBshOpfoO+HnGX C/c/4UOpl6ITCaNBtK+jTfDNPBSfPZrng+jgwRzhPt9KC/vShoVsP5z8nJG5FwTTKfrnl4xESZiY hbo0OA0yFwA8ONv8vFYgbdjNU4ddNUwTBezpiakdnNVWXRgsFzTFd5uNsE+/N8JhVA8g8Mnr1lQ3 dGEt8xr0qahYZwQro+yAw8uIgzI7+rb9uGbEJhUzLkDX/Lt415uI2qrkdonRR0yF87g58Vx1m2yS 6SokKnnYMHHeQejvAycWh4CmsmZlsSoZMws96/CDCaelmE2du72+8zJZHc1tT3Nk963iE6Z0czQF emcA2hlyeWfIZY8DK8SRoqnloYXw0e/RBGGsCx75GCiWz6zn043lyKdlGorlE/R8vFnsReMA6a9K U7GAwgGgxE/M8TCeQJqKBRT1gHw/wQEajyCcIE3FAooHgOJgNp7R5selqVhASQ9I08H7x3hIt0xT sYDmA0BRGI+HtJkgTcVcsh+vmHjzHt70l38BAAD//wMAUEsDBBQABgAIAAAAIQBdwV0LGwsAAOph AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1s7F1Lc9tGEj4nVfsfpnjYmyPiSYCxlJIlOzkktkuS tyrHEQiK2IAAFoBe+fX79czgSZCURIiKLPhggcRgMI+ve3q+7h6+/+VuGbIbP82CODocaT+NR8yP vHgWRFeHo28Xn945I5blPJrxMI78w9G9n41+OfrXj++TaRbOGJ6Osik/HC3yPJkeHGTewl/y7Kc4 8SPcm8fpkuf4mF4dzFJ+i1qX4YE+HtsHSx5EI/V8+pDn4/k88PzT2Lte+lEuK0n9kOdoebYIkqyo LXlIbUnqZ6hGPN1o0hF65p2HM/qbJRep79NVdPNrmpwnX1Nx+/PN15QFM4zXiEV8iWEZHagbqpj4 GKEYLg5aj18VNfHp3TxdHr3nU/SN3R2OMPj39D8e4lP/Lmee/NKrvvUWXzrKeouPHaUPihegBeVL qVeyR6vd0YvuXAR56DOt7JUsyvHo77H3V8aiGP2k7svueZ9visqoz1R9smD5fYKRyakqVU7eFONR lM/EmBYNbY2E7lgT3WkOh6Prrj3GSNGgaJppjPGBmlHUgeplpck0v/sQz+5pMC/xlxrGpxEgeXyd x/MgZ/M4ys89HqKZLqop6qkKh1l+nt+HvpgQDBufijpSTH/ISULm6btPZyM2C9JczBHLlvlJ6HPI kprG/OgrT4E0Ri3MRTtlHaK29RX5KaQC+Oqo8MrPs0fW1lFLu0GXj+wauqMe2dKTrncz8e/0+Eu7 FdsasWFY5mm87H9YdmiQtwjCWatFfjQDHvhZOfF+9O7beQ1BEsrAGnBc4FdAmqRqveiaheie+R7U 9RXE1yCxgDKTwimu6xppiwRaE82cQCEA1tbEsU3LbMohlPhYt/FakkNXd2xXFCjFkE+TNMt/9eMl o4vDUYqGjQgq/Ob3LFfdVEVEbwupzUjiqGAYnflz6FkoQV08KVYX/yRM2Q0PD0fc8yBYmry14DNf fm3VRLl8QgieqJBqngdhWNatKqCVa7Vu2U5Vnh7153N0pHx4vKlh8uHyCfFmqJzy4WUAbdRVQYhe qTfL8nKA5MBUuCj0Gkvz8CTGiEAt8shbxFAdXp7KCVvVYVC5jIdX0FFloZTa9ji1dupn+Z7Aba2C W4CtD3AbALfmttbcAdxC6t4uuD/sCdn2KrKtvtS2CWQbuj6o7TertrGEkM15sicwT1bBbPcF5q6t wKCl37iWljurPaEbRIjc61cW9qQ3dENVj63WTneA9xuCt1LVx3sCs7sKZoG+PixqDboacB7sjjdr d3SRVid7JEM07IOlrr4Ai/ohvmNuQ1MzIlbAKiiC8xGsiA2iw9IkLaJrpr6ycbRdG5ylYiehwQ1d vPqptAjxlZ9AVhAZsJ7XZLcpBx2b/e8aVOOoxgYQArOE6M5PgaJceiY3icJb8Gza0FvorSBLn8qY nsfXqeezKfvhBwGbJkm4a+1EXASRYP7xhhUaY9fqVePT+Dr3WRDNY7zk+N9X+c/tPeUWzkWtCPRk Y3CfxEGzfe0BSDak6H0K41tvwdN8yk59LyAHE9OaLgV0kXwjlZdkCydpQOTsCQwxUI4mhE8z2rtb +AM0s3AOjCeaNSlI/cLV0mIl52jlCbWyaKOg4waKsiBeXzVFqTwvzOMgdzMGf0/KTlvC9FyEvGYU glDtFyAcAvJPpOQNLD6aBsqIOHm4xhy3BX/B+JgoQJw8+HvD2YL+gZOnFZLcgN8HJ3/u5yyTi2ce s8wP5z+z5uK5ffXY4GFL0jjhVzz3WzK0ZSXrMgcZGQ7XSaOixsrbj5PiD57+1eMA5Ave9nk8pe/K RDgTJkJjCHaanlveh1uYwiLYt6/tUXs2PVl6LjsNht2cmHWDQbPH8PMIQrIKroBBMRgMg09TchVl qAb7jWdCQZHB0J987jMeQCt9pp1itZv7tC5WBqxsBxtusV0pYpYGsRq4n9UIKCb2xBk7ZjcBf61y 1eHkgkm+i1lvubpLfloy67EYGbq5yRGgIbpF7XthL63Z1Q52/Su26zcY4MezdjzZU8zP513RXrZF fOHzPsYonhcbqYrIa4zbrpuVDbP8Ob5tvGr7pqAjxHLKBHVK9KFkH+lqbyxgh7NU29FbWtOSwjMK mq9pc9QDEhG9aI2HgMR2pCQGDLj9TgMSifx4pNxsEMIuY/1lVZsXR/MgXfpt9fZcO3O99KLVGMym I02YPY8g8OumjgmC0nGEjNb244MQU7jzGwm83CB+/Vg6RDKSC65HvRBEefxILdOxOkuXRKue3QTZ u4vO4XAlh9oJXbZzlWiHIT1zH8PL+JadxFGESHYwHHrllSufhN84xweZ5QSKToTiCDIOwhrNyltY 6MUtGa8uwkfKOpq+vdrXMtK/2r2o9CfLgE9Dk+49XTMmtitqrbSDWtVl6o/pGGP51qqilnPvElRm 2U1jRHsC4dmji6uZGg0++y/SbObLEFlsSCtg9fQBVZpsvTJTgfISqIKcB+HHaKbSnHiaxrdkkKAs 3a9567vyGR6Qc9CdrPAAzbDvZIX8rpgG5UiRvZfJChgHrwBmebEOoaXLbAWhleOshFEDoQUMC4dY DaEgwlQcGc3OExAK2gLpK5ZJaSVy+DvwCnNzrE1aqxlByVbuOOTKGLqknwGRNfv2AbD7yK7pDbDG WsDKwIQm2BqALVTqXgFrjp3J2IG2A9OkOxOCZHMPZbiOYaicLs1yBA81oLXIM5Pa/dWqV6NMNmmr V6PKOelWr4UOLeBSU6/gQ5/FADDs8cRyRcO6DQAYC9qW2LpBnb4udVpGJa8AtApO7gZogcIOdQqz 97nWf9M23Qlkg9Spa5u2VciHSsanpBUL76dwnGH9/8dk1/a2/ptrt1SmMIk3rP8FKjsAC6OiD8Bq NtGkdFLCPAyS3yjambYtynY1nbGpTfAqQNN0HX0yaUVGCPVaRFIaroHiansz2K4i6/yVWwNmGSDQ VrZmFRzQrWwL7BbarrIGiDJ8FmvAhHp1pQdhsAaqowu+ZzYAXvA1fJVZeZIUQCGLDyKb1m7lTfjd DXXchYkwW91qqcP6Uj7sjLr9Sv/YndH6Y1NwqokCWZEpJG04sXITh/r0VCELcRwuZSJhhdUcBwRR C1KGa9pIk1PWoWbLIKr12+3NQR2PyhSKcJZX73lC2d/oKMJTRuySjI3aoUgbeP4/P54/kAVfW71c iB99Yo5VLoDl1FcL325Tb8BXTem8wrhCfJwLQxGtrFauYepxLMELTn3JhJRTXzEgu029hcWD0i7E 1Hd5OIepf9mpL+P3yqlvRu89XeEbrqbDdhBTr4O6cpy2wp8YDlnIkg74nhV+h8fz85eX0vOlHVnO eGU/7ijshqlhaRczbhiONpEhRzU9P8x47cjDdf7t3lf2kkcsZ7ziD3eb8frKbpmWYa4YdcOMv8CM 2yURdxrfRuyYnPHMrjg4mvSVPSJ9SfvGTPyVPlnBlf2nxZUhzx/OMiXmlPMvTwqtxFzHgaTkCyTF /pDIwxkaKdpYhSQoI7aMMtgSPzCch0gD9HznIa5RVU/catiln7gOT7EnKDea/cCzOyt+gGeRzv4A wuw1RMf2DM+SBKnDU7C7PcPTgvakQ2MB9kF7ijHYh4N276fJ9gzPkqipw7PJ1fSjPekYY3lgyIDO AZ04OF5YYeqP/CkACiBUvw7ghekfPPlyAyOST/GjB7mf4mhqfJXgZw7IUkDRqghObQ5wmMoVWZx5 hBOw6SLhwgL1LlSgLUjTa5zdHEQzfx5EQU4kLU4rwvE0h6PIx880gK2OZ/6FPFl/eRbHuXDKqprw RlU1XanX4RK/1HD0fwAAAP//AwBQSwMEFAAGAAgAAAAhAIgGbbzFCAAA4jsAABUAAABwcHQvc2xp ZGVzL3NsaWRlMy54bWzsW1tv2zgWfl9g/wOh906sqy2j6aCTtN0F2qSI3QHmkZHpWDuyJFCKk+yv 3++Qulu+xHG67Ywf6iqSeEQenut3eN7++riM2ErILEzic8P8ZWAwEQfJLIzvzo1v049vRgbLch7P eJTE4tx4Epnx67t//uNtOs6iGcPoOBvzc2OR5+n47CwLFmLJs1+SVMR4Nk/kkuf4U96dzSR/ANVl dGYNBt7ZkoexUYyX+4xP5vMwEJdJcL8Uca6JSBHxHDPPFmGaldTSfailUmQgo0a3pvQOKwsm0Yz+ z9KpFIKu4tUnmU7Sr1I9vlp9lSycgV8Gi/kSbDHOigfFa+rPGK/h4qwz/K6kxMePc7l895aPsTb2 eG6A+U/0i0F8LB5zFuibQX03WFz3vBssPvS8fVZ+ADOoPkqr0itaX45VLmca5pFgZrUq/SrH0M9J 8GfG4gTrpOXr5QVXq5IYrZnIpwuWP6XgTE6kivf0Q8WP8v0MPFXMyh9/S2ZPtPBb/K9u8nGU5ZP8 KRKKIZg2H4M4fsD+iJOEzuWbjzcGm4UyVzxi2TK/iASHLBdszN9dvv/E3oIXObaiJLCDipAQSWxu DzWxgth0yIl49pVLflNNS8Rvvk0a0yI28TEWgLWXC8Wl3onN++GU+3EjAujgHfbEbu2J4lxTzJps pTV2BMxxh1A+LWamOzQ90yJ6tbCpm7ZnMBI53xp5vqP2rqaUyiz/JJIlo4tzQ2JmBlHgq89ZXqyz eEUtlzaYBCKjfaQXo/hGzKE9EG1LjVQ2Q1xEkq14dG7wIACHTf1owWdC33Yxb7WlYGQ1QrFVESTK 8zCKKtoFAbJH67T1PIv31frncyykGjzYNjE9WJQj1JeTuB68DONE9hGIsKriy/p9zSDNmFowSg1g Mo8uEnAE+8XjYJFAJoNc6g1b1wzwmfHoDpJfvSRpbluUZYuYf06yrCPlu6j1KAtL5oyzize3Yc4u 31+zlMvvpz3uuvYoYYZ91/YKe0GmuTbSO7RnaDq2A38I1Tgpz99eeXrE/UuyEixPWCwejuhxLq/h wY6gi88kscU4hLmQKnLqkHwtPwh/pMOs2g+6ZAYP1mQPftDy4F5Pqgx3elLl9aDx6rgqPJ1cdXTl EG/6TBJbNHguk+UzqfXYu+/v04frlsB7kSUwEVXin7IEjmP5pt2JiG3LdIYmXjhFxI3Aux2q/3Ui 4h4h/8Lln0f05vmCd9PHQ0zBJLmXgWA3yX0uWoqs80yVbOLn+TlBDweOuPoHfoys4up6ygi9Yd++ tuf2Cot/L5fKzOUyvLsTsv29Ek6oEv81PGKLDZ6GSyFbe7eb3B6781pBGBIfHYR9jJKHYMFlPmaX IggJOWTDFxlhB0CDVWRWFlAH31aJWg1LwAbbplMYYXMwRPpVYgElwtHBJeaY5AVNspyiQbnwCaQo oZe/BEgRJ7O28TtMgQIOlKhtl17BkPAo6hqP11JVCle6CZP/Ig1thkmu59jucET0ag1thUkjpFeu isvAxw0KegIOf2LgsMcNfUtnPBdwy9G8K+a74pstPvJyPXHaqTRd1P6lurxlehNM5vge/CX8+vd1 Zz472aWD9w21ieAxnhTlogu6XCuAVRWwD9Ft8sAukjgGkJ5IBhtUIjTVSCQQOf5QpTNgOkUNQNuR eFY+QaChnmgPrzCeikIbr23c1mUGbW2YTFCZcB2qGGgkv6iveQgjPKpuEOwDNNcZdayYCkTwfcr1 qFBCGJHmzwYrdosotFqzXccYpNt3s8II89l/wKb5MkKdFCUO1ixlqIhElTHKAIaGRjH95jyMPsSz opDGpUweitnQc1U/2lxb2aP+0V842aP28b0Bo/xxS+EEfAhKKa0u4lVDNgD3I0BX9dqqJrAmrnVp oBrZFFcM3CCugCSOIa6mRwJHSMQ8CtN/UfmRZKCQXHOAoNjHp0gwfRMhcCdCNhE2j6yicEfPEUWf RLdZT9R6/NOKrrXR0lo7LC1g7g2i+3qW1oWldQcaYLdgaSHcJI11vNi0tKar7fDmYPFkZstqc2lr iJdVGfxIaNzRzKxVHVzomlmrPr/Qa2ZLiVT2HtJSRwXHMrODUcPM/t4xs5YHw4rMhcys7XgAfjsB gukNR0PfLtBgz3FMtaA9JVefd+gFIU4+vyPNewvj5uMzlr+eBltqQw8uHEImbMeGlEJAdpcL9kKq Tokw2bL5z3mCpicRvrxfpkxBSq1M7JWzUJysbH3uMCTsmSS2ZMY47dNG1JQxf8EpuV2hvV1hXms+ p4a+tvqcsvBX+xwyIK8f27vuyPd9hHfkdIbeyMZSNsZKI9/yh+rww54+55SU4vzc/zVa2uygbAQS XZxW158PdlAWTnUOS4jjdMJTnwhVicf3iKB/uBOePf7pxz/Z8lJX2bPoS3UE9Xju7cc+P7PLVzrV Qf81X7kjPyuzsHVfSTWnY/jKHtjWQtTtDuGL4SBdgKfDQfn5ounBQsHJxZoItj2BCd2D9D858OVu BL7cHcAXudcNyFcpx4oCIchXTcC4eSa8ChmpXYPg9h01BmtgjgY+hJGiOaC2nj6pUCNfLaR2CHH2 T0Btq/HjB5fXzeGcW1UXpmje+i15ZG5dVaDaGaPeH/S9KHSrXcoqS2tNGSNZK/B/lyruAKMU7gAA i7DVVo5g+47nwQSrypWHxh4t2QeW3/k4Tj4idqKtKOW+p0HlQXJ0gcVoDDQazSoq2E7f3+cgUXQE 6ZYuerDet6JUaq1JJfsv2KQOZt4SvxodXluSzj8+TDouflP1cyN5LXwbqqFbth6YoY7kq61vn1A/ fOupjOn4BSYJ/NH2O+mhPbRHgNf/BlvfE9hd7VvvPmTHlezrFlDyEUVXaBDJLzy9XinBRbMrmiHQ vIZbKUAYrTGNV6A2IQ5b3VG3Qh6jR44u0AeluhemuhZO8n2P7q4wnol5GKO9Avok0HYrUceO0XEo IV046zTVHZXLmyTJVXGvoITJFaTpqvgcTR5trP8DAAD//wMAUEsDBBQABgAIAAAAIQCn5+DIsAcA AHAtAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTQueG1s7FrLcts2FF23M/0HDBfZJRIfetZ2JnHsbNLE YzmLLmESkthSIAeEZblf3wOA4EOiJNtV3SSVFzIlAhfAxX2cc4GTt6tFQpZM5HHKTx33TdchjIdp FPPZqfP15vL10CG5pDyiScrZqfPAcuft2S8/n2TjPIkIevN8TE+duZTZuNPJwzlb0PxNmjGOd9NU LKjEVzHrRILeQ+oi6Xjdbr+zoDF3iv7iMf3T6TQO2Yc0vFswLo0QwRIqMfN8Hme5lZY9RlomWA4x undjSmdYWThJIvU/z24EY+qJLz+KbJJdCf368/JKkDiCvhzC6QJqcTrFi6KZ/srRDA+dte4zK4mO V1OxODuhY6yNrE4dKP9BfaITHbOVJKH5Max+DedfWtqG84uW1h07AGZQDqpWZVa0uRzPLucmlgkj brkq05Si66c0/DMnPMU61fLN8sLPSytMrVmJz+ZEPmTQjFSiinbmpdaHbZ9Dp1pZcvU+jR7Uwm/x X/9Ix0kuJ/IhYVohmDYdQzg+oP6EKguditeX1w6JYiG1jki+kOcJo7DlQo3y7MO7L0SKeDZjgpxA JxJbYgXtkcYETBOb3CJVxgsmniiuRcwBZwRfyHK2NiXGoysq6HWpMcZff53UNKZ2kI6hW2yL3QM8 GiPZbiqBNZVrFiI8zGAufsNc9KbWPaC+40rta7bvjbzhyOtrD3AHbhAMh0pe5QfeYNjvDmGiyhv6 gTcKPG1WlaRM5PIjSxdEPZw6AjNzlAS6/JTLYp1FE71cZXvKVnNlYqphwq/ZFI4Nr/N0Tx3O2Hki yJImpw4NQ8QM17ya04iZn3td/BVzKXtotWqBSvI0TpJSdiFAhcpN2WaeRXu9/ukUCyk7d3dNzHRm toceOeVV50XMU9EmIMGqipFNe6Mgo5jKMKxzEiGT8xQaQcSiPJyncJNQCrNhm04LPROazOCUZSOh 5vYt+PHNN+rH+Qs5cs868mWS3odzKuSYfGBhrAABCdSOIh+a+K6fn+DSrjfsDXvwWDisdm9fy6u5 tBv4bgAbUi7tBt5w0Ld+ZKPDmk9PMclzNUk7RW3MRwe3Yeu7dvAJS6YkpIiLL2X8SDcGv1VZrPeP TD7oB37gAzMrk0cW63traM733GDgWpMf9ga+yXMlVkMuPqYxnTx/0DR2mapkmCDI5jLmmoCQmBu7 HzeCvsFlGpzhYzOHbmC7fWh4n8B9SXkHHJ5gMo3JW4RdAs99k1PAnACrN6Q0Zrxvei3wepLeiZCR MfnpJx1dDiq8toMYoPbtoKMUSxDpnWQwlGmKsV4l8tfGIPu1vWPv2CKTD08U16LrV7ONSW1Y6IHY x8DG7Ruw5PfpivQbUZsoIgMQXxDYJ0AWHyBkNDKQxfeH7qC7Bln8UdAHSNGIxeu7fYRyg5u3AJbd JISOeXoJaqBEKM5l+IilYSXavhcUbJujAOPUkLdC0Hn27k5CREFvDHVWLzZBeLv35H9BTS7oC7nV TLdi0jsM5veLyZq5bNvoreKN0rbQznDFJ0WR4lw9rpddkF9N2r5IbtN7cp5yDoqEuDoozaDsBx1J fNHlGmBdTe40UwUM5ZF9AyCg39QqGqUEVb6pCjm1n81+VfyzqOI0bAh4ABBXTauCvS4wQBBgSA17 e/sAwC04Z7lEvwK8SuQsKjRBoz9Qp5guEtTiwFVJnZNqeKxTqoUW2kK4+pQ0Ti54VBRrqBDpfWHQ Cd7XjLKNJD+CyLYz4EeQ2JdmwHK1gwFDD6G1ye01EbcMS21cym3GKFhE07CsmW+xqjqZCnoD1FDX 6yNHMqV8zNY+jD8/wtDKHsodpj9MtaSADdcKNjSCdQNStaDK9jxR5YWWzH/AIuY9Xed+z5mPKu2T r1fr89rIUvswqdEVvN+mZB0Qdc2wyE/Wa1EiAdJVZwJgfBuk0h2ViUl1eKrv11llAM5YlEmqjNJk lY8ppOzGJXvi/rE4qhT03xVHd0CzIw9TPG97wHtGNPn/ErAS8/BlDfbWQl15/rkOxE3ZS1eOy551 JK6g0hYoruLnv4LFe96wX1TbqsjZwOKoVw9QrzbcZAuhO6Lxl0BYj0bje03Ut9l4w0T1Rm83UUsW dTMYTEUWS+M13L8pognqS+O37N6wRSJSHFD2AnVwaCBqwR09r9f1+hga9WNQRCR7zUoqewV1VHzy SB2/ocPTwxlreR6xYazVsURpUvV4CovQMXPTWK0ZH95W/W4P1TD4lzq8Q1FsZGphla32Bm4P9TNj q6N+0Av0KgCqj7FV3yMwieY7rHR4IxtVbQHW09UIHQoVw3l+BdbFPZDBCFajIiAyttfTdZPKqnwc mSmMoIpnP3YFtoVpf24ej+i01Hq/53mF1+21Lb9kteWONznt83e8Xi9F9gsGg7XK1nHH63fWNooY xZnK83Z8H37ClY0ttXa/uu/VmpJsSX0zJZUI//A5Cecxg5HCZyp64Px9OFyrvRcQ/4ifvj/8pItS 5kIuHu0d3TARv9Hsy1ITe1w9lkzgvh5+ynDZWCVYNK2aoJIX447MTJXwJMe1QPWQUXRGsxtzSgRS G93hQlvMIzaNeSwZTt1wWI9bRziEY7gsDZdII3Zj7rcurtNUas5YSMKIhWj1VAyHR9yXPvsbAAD/ /wMAUEsDBBQABgAIAAAAIQDZjP6oRgIAAPEFAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTEueG1sxFTB btswDL0P2D8IuqdOM2AYjDjF1q7DgK4pkvQDGFmOhcmSIDFp8vejZCvtugzrIcAutiyRz3zvUZxe 7TvNdtIHZU3FLy/GnEkjbK3MpuKPq9vRJ84CgqlBWyMrfpCBX83ev5u6MuiaUbYJJVS8RXRlUQTR yg7ChXXS0FljfQdIn35T1B6eCLXTxWQ8/lh0oAwf8v1b8m3TKCFvrNh20mAP4qUGpMpDq1zIaO4t aM7LQDAp+7eSZsRMLHUd38GtvJRxZXbfvFu6B5+O73cPnqma9OLMQEey8GI4GMLSp6EwWhSv0jcZ Ccp947vZFErixvYVJ/EP8UlJUMo9MtFviudd0c5PxIr264noIv+AKjj+NLLqGf1JZ5LprBRqyS6P rPpQoNQ7K34GZizxjPR7euJ+l8Ei5wjvWoYHR8oI9AltCO3PkyQ5JZCsSS/cf7H1IXJf0zttQqkD LvGgZdKEKoeS8OlBDmiITdr40e2Cs1p5TDKx0OG1lkDtPCiJs5vPczYlOZDcyAD/QJGeupL8PYEG emO9wrZ7BSlN/QAeFsfSpBk9Ll+UFtWCkkgQ/0yWlr0hf7flQ7ZluV1jcmZyDmfCdt07Q61MfZbN /D8OfTcMWKPt0xl9Ei14PKNHyap+ItAyDwmh/Q9w811qS5p9KP112nI07Yb78RxCxquODuIdQXMX qCPpskA/V1YmT5V6S92nTC0bZRRKzmhcIbGpuJE0rakhbC1X6YJht7AWh+uVkGJ39dBxNfwuFk9T 7RcAAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9f cmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG 2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPm EuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L8392 6Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAA ACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAABw cHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBQH8PvB3kHO /WKStukHNb0Zg8KuRvcAEk8+WKKidixvPykMEiiOQsCbgIrn/Pgr5nj6GXryjcZ2SjLIkhQIykqJ TjYMPi9vLzsg1nEpeK8kMhjRwql8fjp+YM+d32TbTlviq0jLoHVOHyi1VYsDt4nSKP1KrczAnR+a hmpeffEGaZ6mBTXTGlDOapKzYGDOwve/jNp3/r+2quuuwldVXQeU7k4LavtO4Dsf1dX5stw06Bgk yXTeTge7xPOB3petYspWIdk2pmwbkmX5kjTnrxnODvI2Q2/fLORYlPHorcpDsmzJgB6VBTMrYsqK YGZxQwumtomZ2iaYmn/r4z2tWRqyrWPS1iHZPqZs/yejs99v+QsAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4 Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9osp TlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP// AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tj BcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZ w5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMi n39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDg RfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSw b5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtka xPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0Ni54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAMobsTVeAwAAGAsAACIAAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1srFbbctowEH3vTP9B4z4Tm3viCWSIgb7k whTSd8UWsSey5UqCQjudyW+1n5Mv6ZGMkiYlMyThxRh592j37O6Rjk9WOSdLJlUmip5XPwg8wopY JFlx0/OuZuPaoUeUpkVCuShYz1sz5Z30P344LkPFkzO6FgtNgFGokPa8VOsy9H0Vpyyn6kCUrMC3 uZA51fgrb/xE0u/AzrnfCIKOn9Os8Db+chd/MZ9nMRuKeJGzQlcgknGqEb9Ks1I5tHIXtFIyBRjr /TQkvS6RLYjRs5VHrJ1cYqXu9ZF6POUJKWiOhVmmOSMgiHyFcRZTTmZspa2ZKmeSMeNQLD/LclpO pPW+WE4kyRKDtkHx/M2HjZn9W8AML/4z9xuHRMPVXOb9YxqCFbLqeSje2jzhREMEQeJqMX5cjdPL LbZxOtpi7bsNEMHDpqh7WWX0fzoNl05FSv0hq8qUwvVMxLeKFAJ5mvSr9OKLpQMzORv4MiVVCbTh d2NXfbR8OHsFTi1ZenUqkrVJ/Bq/dpGGXOmpXnNmCUHYNAQ4HqCfU9PhrKhdTdHhuY44o5iADXm6 H/EsviVaEJZkmpxTpZkkNhjMAyCPwY5GcTaQrEgmVNIvz5BNfjTEzgjaRYjXisKXiWw6Ip/0FJlw GrNU8AShNPZBrqHKI0JmGIKq2z30JZrGVeY1jBsZAQqjJmgT3Tb+US7Cl/yB6HfWwzS5LYd6Uo+K c0s8Hm5Lm9QrWmDKYoG55mzJ+A7wtiKvgJ+lmdwdvVkxujNfY7GQOt05+NZr4bP5VnTozl4noeUm YUg1ezIAlhBIsdOON6lLojH8P3BUUD53rW8lwIqMkaJ3qc0cx4TR+Z+dIBgGh82o1h50xrVWG2+H 0WBYG9QH3VG32x6dRp1f3kbyEqSqs5yNs5uFZJcLc5jsJlp1v9HFmVgPHtsVIRjv/Val7aoyFsLo 4r/CZDvpvXWZa1kV5tuCSuzgavMWXXpBifbLSMcxMuVZwsjFIr9+xkt7H4KNOxegt1Jj5WfPbRsN onrQbZ3WRvXmqNYatdG23eFRbdAcN1qN4ChqHkYPbatM5gWi27Vb7+9+f7q/+7OHXrVHanXXwqu5 ndnrFJfntLxcWs3EfRR9FNmlEjdQczLD9NHEYLgbbf8vAAAA//8DAFBLAwQUAAYACAAAACEAoHrT g38EAACkEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbMxY3XLiNhS+70zf QeNes9jGYPCE7BAC7UU2ySzZB1BsETwr/1QWFNrpzL5W+zj7JP2ObPGTTac0yzC5ASMdHX3nO9+R jrl4v84kWwlVpUU+dLx3rsNEHhdJmj8NnU8P01bfYZXmecJlkYuhsxGV8/7yxx8uyqiSyQ3fFEvN 4COvIj50FlqXUbtdxQuR8epdUYocc/NCZVzjp3pqJ4r/Bt+ZbPuu22tnPM2dZr06Zn0xn6exuC7i ZSZyXTtRQnIN/NUiLSvrrTzGW6lEBTdm9SEkvSkRbSXiXwRPHGYM1QpDnnOJ2OOZTFjOMwzMREyb MzIUysxW5YMSguzy1c+qnJX3yiy6Xd0rlibkpFnstJuJxsz8zGGGh/az5U/WE4/Wc5VdXvAIbLD1 0EHSNvSJRTwSa83iejDejcaLuxds48XkBeu23QAItpsi32Ud0bfh+Dach1RLwbxtVLUpx9KbIv5c sbxAnBR+HV58u7LOKGZyXy5YTb0mV41dPWn4sPaV4dQC3TIR+n7H6xg6gsDtDdxnpIRh6AcYZESN 1+n5btg1m1hP2KR2XUZ6fVUkG6L0Ed/IHM/jRQGValrBI1npmd5I5BnPK+kBEePyCWUkoQIeJWL+ EUPV70MHW2LPR5P4mIMBLmWzbbMS6T70CLJ5BErwASeSUz2KvPVphnrM9FgKjo2a6PTlWKbxZ6YL JpJUsw+80kIxQyGqFxjJuzZ7GJciT+654gRv3zNlhUfYGSzY6A0hlJl/Tz/4rkvhgbR3L3ksFoVE MTCfgkS12Dy/SgnEvoOygaatcF4lCH/g9kKIwyTPVsmhILqu6/XDJjN1kR0jiMfa50uCyLi6MQWa 5glOGnqknD4ub3GcGiR7MsGRWE9XhUyTaSol2ZrTVIylYisuob41HUFIZ5rreiQEbKMEJG9rbFK5 5wdz9U5mYqs6I12fpFsjDbohUIDuI+B6/TPCJYwUNpB3dnAHHsr8WLi9M8IljA3cYAfX64QeoTiO XorMCOAMaiCQDd7uHt6+36ckvz28BLLB29vh9f0+6H2LeAlkgzfcwxsGnePL7Zx6IJAN3v4OL4E9 vt7OiZdANngHe3h73fBt1huBrE/ivS7C3PmEHofc9nI3Yb2+B6CLzrQA1UEP8Jp7PrD3/DXX4uCe N5fq997ziUZrg2ZpweXc3vf1tUaNsKGLHmaGubpNM92F7VRsn2ZuVXsXmx+G1zk6duq9/4Agrt1+ Z9zqjnrTVtDFU388um6NvFE4CcPu5Grc+9Np2tAEoeo0E9P0aanE3VI7pLJj0uG1/RDvJ5674x0Q aPVpu6+uzcq0KKjr2++/glP0X3Ot6sT8uuQKO9jc/Ecz9n9yc1pGepaRGboowW6X2eMzXkzP/716 xfsvXL9Ijel70TmeUrbj0dhzw+CqNfE6k1Yw6UK24fWgNepM/cB3B+NOf7yVbUWR50B3rFq/fvnr p69f/j6BVk3DXL//4pFelM0rgFQfeHm3MqcZ/huAjtDRYqjEvwGQCpnuTMiH/Xfh8h8AAAD//wMA UEsDBBQABgAIAAAAIQDjC6FYRgMAAOEKAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDIueG1srFZbctowFP3vTPegcb8d27zjATLEQH/yYApZgGLL2I0suZJwoZ3OZFvtcrKSXsk2aSid gcKPH/LV0b3nHh+pf7XOKCqIkClnA8u7cC1EWMijlC0H1sNiavcsJBVmEaackYG1IdK6Gr5/1899 SaMbvOErhQCDSR8PrESp3HccGSYkw/KC54TBt5iLDCt4FUsnEvgrYGfUabhux8lwyqxqvjhkPo/j NCRjHq4ywlQJIgjFCvKXSZrLGi0/BC0XRAKMmf02JbXJoVr++NlCJkgU8OpZQ6g7nNMIMZzBwCJV lCBgBwWcKUAyATJfCEJ0KCs+inyez4SZd1fMBEojjVPNt5zqQxVmXhmEwYOzM31ZI2F/HYts2Mc+ kIHWAwt6ttFXmIR9slYoLAfD19Ewud8TGyaTPdFOvQBksF0U2p2XFf1dTqMup6TD21ZVhmKYesPD J4kYhzp1+WV54V1Rg+maNXyeoJJ5pZmt4sqPho86XgKnhiy1vubRRhf+CHcziH0q1VxtKDGEQNrY B3C4AP0Ua2ETZj/MQdiZCijBIPyKPDUMaBo+IcURiVKFbrFURCCTDPwGANkHdhQ0p4IkLJphgT/t IOv6sA8rQ9J1hvBYUvhvIps1kZWa0IzikCScRpBE4zRa0whEUTN/BkahAYgWdEvdiQxr2RqC5RuG SxYNlXCplzRlHNHUOQk5/KOUFIQeAG+YPgJ+kaTicPSm7uMR6FO+Eio5OPnWsfBpvBcdnOSs2m7V 2h5jRd4I2xACtlq7wX/5RaTgd/4Gno9pbIHJarGbn9rYhjaXk/wjBsvXzv2947pjt9cM7PaoM7Vb bXjqBaOxPfJG3Um3255cB50fVmViEZSq0oxM0+VKkPuV3h6g8ztmsc+GPKfRhc3Nc1/lCino2eft SrvuypRz7XR/Go5R0ql9iZUoG/NlhQWsUPfmjE50XkY6NSNzmkYE3a2yxx1e2qcZcbm/weEJoPdS Y+znzLINRoHndlvX9sRrTuzWpA2y7Y4v7VFz2mg13Mug2Qu2spW6cgbZHarWl+efH16ef51Bq2aT LE9P8KhPWuaARMUtzu8Ls8fAwRJ0FJihHI6Seq+F0NcQjVEfTYe/AQAA//8DAFBLAwQUAAYACAAA ACEA21SIHjEEAABQEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMxY227j NhB9L7D/QGifvdZdihB74ch2X7JJUGc/gJFoW1jqUpJ27RYF9rfaz9kv6QwpWU7qosbCWPjFoajh 6PCcGXImtx93JSdbJmRRVyPL+WBbhFVZnRfVamR9fp4PYotIRauc8rpiI2vPpPVx/O6n2yaRPL+n +3qjCPioZEJH1lqpJhkOZbZmJZUf6oZV8G5Zi5IqeBSrYS7ob+C75EPXtsNhSYvKateLc9bXy2WR sWmdbUpWKeNEME4V4JfropGdt+Ycb41gEtzo1a8hqX0Du1WF4swi2kxsYcKxxrDzbMFzUtESJp7R gix4kTP9SjbPgjE0qrY/i2bRPAm94mH7JEiRo4d2pTVsX7Rm+rECMxgM3yxfdZ5osluKcnxLEyCC 7EYW6LXHX1hEE7ZTJDOTWT+brR9P2Gbr2QnrYfcBQHD4KEjdmB39eztutx1DhHPYlTGlsPS+zr5I UtWwT9y+2V72sO2c4Z7RfbMmhvVMCe2tNTXvNSXdEqlp7bAeyAjjILYNI67j2b4bvOYliiLXRwNk x/Ej2zYWx7s2rptE7e7qfI+svsBfrQpNuFQLtedMsw2c0ASQww9oyylmDKsGnxeQMaVKOaOQUa0y apzyIvtCVE1YXijyiUrFBFE6eiS6vAUQCpRvXbIqf6KC/vLGM5JHE/gy0NEhhKHR579V8jqVFpsX 8033EkLJzYsRCiIbwq7T9nzBHC9ywlYxL45DOBNeKxaCXFpSrVgUuGhtSDCJoDdv4qfj46RiKBPf cgcCh5RU3OvMKaocsl8PKV+BWhB5kMXgYPMAp51WOWdLEAEnZQ1ZPi841w94xLGUC7KlHA6KHZ4M oGBRKTMTBfYBqj4P0Vird+QHtOz8w7DFh35g6PZQ/SBCZsj14UWQLV6vx3vj+DrNrg8vgmzx+j3e QxheH2BE2QIOjgDHbqzT4voAI8oWcNgDdt0YMvcqQxhRtoCjI8CR711pziHKFnDcA0a0V5p0iLIF fHMEOAwiffZfXwwjSn1Ud/c9or/AdQ/35Y+68f3uxp9SxcgTpxlb1zyHmsO7xM2fKyhyfocSm/Il 3Ev69jcXM1aumj0cLDSRWJ/oAqqvWU7e0X1VtYT6GovlPyBApnbspYNgEs4HfgCjOJ1MBxNnEs2i KJjdpeGfVls35rBVVZRsXqw2gj1ulIW6nVOcOUM3gl7CsfsqDCDg6svWYUGnyryusf471sW/hC5L KGC0ML9uqIAvdNr8T2kGzJ+tzWUZCTtGdAtFHjblyxtedA0PPVfXMHxXSwG9Krg+SY2uhHV3cbmw TSepY0f+3WDmeLOBPwsgbKPpzWDizV3ftW9SL04PYSuxeawA3bnR+u3rX++/ff37ArGqq2fTsMIQ 21rdk3LxiTaPW31oQx8PcQS1K0w10Llj8Q2mvQn66P4TMP4HAAD//wMAUEsDBBQABgAIAAAAIQB3 QRCEkgcAACIvAAAhAAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FrdTuNGFL6v 1Hew3Msqm/gvTiJCBYG0K9EtWtgHmNgT4jKxXXtCYatK+w59g75F27s+yj5JvzMzdhxItkEECRAS SuyZ8fHM+c7Pdw7Z++56LqwrXpRJlg5t503HtngaZXGSXgztD+fjVs+2SsnSmIks5UP7hpf2d/tf f7WXD0oR/8hKyQsLMtJywIb2TMp80G6X0YzPWfkmy3mKuWlWzJnEbXHRjgv2K2TPRdvtdLrtOUtS 2zxfbPN8Np0mET/KosWcp1ILKbhgEvsvZ0leVtLybaTlBS8hRj29sqV9nC86EzF9Ty7053s+tZL4 GlrqdBx7f48N1Dn5SBTWFRNDe3Lh2O39vTY9gsXmih4u8/OCc7pKr74v8rP8tKCb6N3VaQGZEGlb KZtDvyRATZhl6jbFMi145fGLShIbXE+LOe0I6rGwQ6B4Q594iA34tbQiPRgtR6PZT2vWRrPjNavb 1QtwtPqldCp9orvHcavjnCdScOtUsIjPMhHDVpSK1An1Y9BifpJFl6WVZjgzqUIfFcqpBNP56VX5 zJI3ObQkSaxZpyexs7ReXyr9VpuuteIHIYxOqcYN/a7XW9VPz3X7XZonLTmO73VwQ3tZCsqLUn7P s7lFF0O74JFUhsCuTkqpl1ZLFPp6I/lAXh9m8Q2BMcE3MIfH4flZVny0LfE2LYd23/F9vFuqG7VT 2yqaM5OVGSlGGUwOT7A0gpyhHclC7SWFtx0sZDZNzI70K+nlopRn8kZwZRYAjw2gVnxgQ4KRw/O0 9eEMDj+XI8EZAoIxIbk/Ekl0acnM4nEiLeP3CgaEB4gkLUmlKyWSp/EpK9j7W5KNipRuKp0AOW1I m83Jq82JbLlpTS4B9FBrIgXZxrUfYlQOrIcMTKm38roVq/IDN+h3vadvVWQW9zIkeJwlrpRFquM/ 0LBIe8quyhXDgpEps9Uf1StVxLiHLZ/xKEtjS/ArLrYQr2zsHuLPZ0mxvXRlDPeQPs4WhZxtvXlf W+PWcIyT6VrpSCM7dWm/cukjJlcThFLIQ106lohiHxFhmZga11YwqjRByeSe+aLrBfi75dqu43l1 wvC6geMGT9+zV/KFctUqK6gMcSUccmUmLhD9hU1jMZ9SHCd1OhTeaKzMRBKPEyHUDdG9JQ2S15od ySSVmhiFwTKV1pxJJYuGHPi2fpOaQCyhjehrk7boXcrzpyJWrOk3aP+o0/NGreCgO275Aa56o4Oj 1oFzEB6HYXB8OOr+jqSqSEMMS5PJnI+Ti0XBf1ro1L1N8nPabgiq6XSW0QJboO3s1imCyinGWUa8 upnplCM/1C2m4AgKyF8WrMAbjGvohEQMalvX8BzXr7jUet/o9YMX7RsV3Xp63rFbm+xWNnkGj+fW u8V8cssyVdB7qGWimITodcapDP9ecbsbBN6XjfOlB25dCTw906wD9+hg5HRC/7B17HjHLf84QOAO j/qtA29MgaU/8nqjOnCXZHkprIMi7jbx+vOnv775/OnvHURrVZzo2h2XVUcgEsWPLLdQ7yNHStTu SHlDO77E1eTCpTEUwPIaV/ElrlgUocmAFeaiGsG8HqnXeNUIKh495VcjIEx6JKhGkC30SLcaga/O RJJegvfQl21NM/GDHqiuiKCg4BLxCbvJFvJtjML11ohKra7jh37P6/p9lKEDalEUb2NTuzeeXlkL frRcayqzjWuhq1quoXwb10I/9VqTBzeuhebqtSYybVwLndZru3c0s3o2aLteG/7PWuBQr1VNhhWN r8oNG2v7/yMXvbharqPI6BcErwBXNVUaqjDAy2vVEijJCFQ9r27J0wwFM1yQ8p2FiHLOJmdggqpd QXhL3YXg7CQ9LGB5wJW6cam5xZIZWgto+Z0u0gg9D9M5y6ND6pBR9yc6jQxPVEcCD8SYmZ0s3qHt qGhqI5qhUwK5l7ygluW2lBRCSHSTuKqNKnY4RYNqaH87/7klJIEAZsduTXCmJ6Ly1kRU0sQm+rqq VbQG0Wy4o+I5K06Gtue7fTpYkiLcQVWtaqBi44+tf6hSty9uYTDOwOSJRGs1HRQJE7aVJzKajdk8 EeiXefClaMaKkmPjpk6aLEYYUcND+/OnP7X+GjjqLP0YOKabcExbG3BMW1/EUbmDS6WRxioEVhTv aqzcXoAyByHZVE7PG6s/7mDl9h7L53aIFQFkQpe3xKrq5TbAcnuqOHkZYN11LPfRAuQOwSKEDFh+ AywAo8j70rNeFFhrPIuC7qNksx2CRQgZsIIlWG4nCJWpvUiw/v3nbhR8DlgRQAarbgOrwPFV0HuR WK2jF0RnnrxjEUIGrLABVj90VMJ9BetLbeatOP0OoyAhZMDqLcHSNH2FDL6olLWGXzwHzyKEDFj9 Bli9Xvcl84tnChYhhCJ6pT7OB5mc8aKullE5nmpITQ3Z/NFCXYKbJVX3Qpdrj1KYNSpZHayfZSVb /Spm97XQc9PP+uqx6nS96mdDweaF9MOXx+h8PDcDWl8kOT23p7jcqwVtqEwUW3q1IKSsDdVA6OtW 6asFbWDgYHSqD/GqoA2stxuEr0FaNfFrptkklyCey3+E0T99q9+27/8HAAD//wMAUEsDBBQABgAI AAAAIQAXW0S6DAQAALMRAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1s7Fjd cto4FL7fmX0HjfeaYhv/EE+gQwzsTZtkCn0AxRbBrSy5kiDQTmf6WruP0yfpkWwRQskCGy5zkwj5 0yed7/zo2JdvVyVFSyJkwVnP8d64DiIs43nB7nvOx+m41XWQVJjlmHJGes6aSOdt/88/LqtE0vwd XvOFQsDBZIJ7zlypKmm3ZTYnJZZveEUYPJtxUWIFP8V9Oxf4AbhL2vZdN2qXuGBOs14cs57PZkVG hjxblISpmkQQihWcX86LSlq26hi2ShAJNGb10yOpdQXWqgd+c/fJQQYnljDjOX0wPZvQHDFcwsT0 gaOUMwU05pGspoIQDWLLv0U1qW6FWXG9vBWoyDVDs9JpNw8amPnJAAaD9s7ye8uEk9VMlP1LnIAS aNVzwGFr/RcW4YSsFMrqyexxNpvf7MFm89EedNtuACfYbAq+rmqLfjfHt+ZMC0UJ8jZW1VAMS9/x 7LNEjIOd2vzavOx6acm0zZq+mqNGdk3V4OqHRg+Ll6CpEUutrni+1obfwX8ziRMq1UStKTGCwLFx AuTwB+SnWEc1Ya2PE4jqUqWUYIj6RjzVT2mRfUaKI5IXCr3HUhGBlLFLaspLUEeBcxpKwvJbLPCH HWZtH05gZzi0PSEMawmfF7JjhWyiCd1SnJE5pzkcwn+ZrPIrZAOmMwciEMLD+uAZbbVcO1EWhDHk qwk1L3JdPTb62oAL3E4X5h2kwy4I/fAi6hgHWiYjQO1mq8ler+m96ZJ6Jm1wkpOZllef3+/Wm4K2 WwAY+nuwwTbWAgDb2YN1t7EWANjgd6z35AwWANjwENYCABsdwloAYONDWAsAbPcQ1gIAe3EIWwO0 1k06aceYbIKVCBg2afPC7NIRZJJLPsmuOoN2tzSBe0JCT0jGWY4oWRJ6BL3JshPop/NCHM9uEuIE 9jFfCDU/+vBBnZFHu2NczPaywy1y1roW/FddM5rAfWovgxOvi526Zvxnrgpdacxg+87YV9eioPta 2OBGeC1syWth2zRCr4XtiIYttIVtiBV50q2ZUvz/q1rdBOcKetSdvs046PkCd0pTPIM3GP068g3a tqHb7aStcBCNW0EIo246GLYG3iAexXE4ukqj707TmedgqipKMi7uF4LcLPQ7D1xpOx3wvt7aa/sx vK557uM9DEfQq8973UTWK2POdfu+3UWHL+uia7/MlKgd82WBBexge+oDTfUpvjmvIrFVZEKLnKDr RXm3o0t0Dl3gcwBQ75XmwL18ijSbsE0HqefGwVVr5HVGrWAUQtjGw4vWoDP2A9+9SDvddBO2UlvO 4HTHRuvPH//89fPHv2eIVVNI6k8CMNQfDsxbPxXvcXWzNN0afCqBOErNVAUfR0APDX2EaA77saX/ CwAA//8DAFBLAwQUAAYACAAAACEAafz/VWgFAACCGwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQ1LnhtbOxZy5LaRhTdpyr/oFLWGPRCQA3jYjSQjT0zFfAHNFIzKNYrUsNAUqnybyWf 4y/JvbfVIF62hmHhqrABIY6O7vPoduvm/SqOtCXPizBN+rrxrqVrPPHTIEye+/qnyajR0bVCsCRg UZrwvr7mhf7+9uefbrJeEQUf2DpdCA04kqLH+vpciKzXbBb+nMeseJdmPIH/ZmkeMwE/8+dmkLMX 4I6jptlqtZsxCxO9vD6vc306m4U+v0/9RcwTIUlyHjEB9hfzMCsUW1aHLct5ATR09a5JYp2Bt+Il nawmL+nj9HddI3C+hNOGfgv+++Mo0BIWwwkvjTOWh0Wa0D9FNsk5R0yy/DXPxtlTThc8LJ9yLQyQ oLxQb5Z/lDD6mQAMDpp7lz8rJtZbzfL49ob1IBraqq9D0tb4CRexHl8JzZcn/e1Zf/54BOvPh0fQ TXUDsGBzU8h3Jj06dMdU7kxCEXHN2HgloQwu/ZD6nwstScFPdF+65z8sFRn6jPTZXCtDj1QlTv5J 8VD4AmJKwRKruzRYo+NT+KaTrBcVYizWEaQAjpeRQQlgvYDPfpOhrZwGb6twcJL1wBT4gGRFDPuA J41PY+iDWHgRZ9AnZajFrReF/mdNpBoPQqF9ZIXguSYoCgUacAPsAlJZUvIkeGI5AyN2mDEarAd3 BheVP3AoA3467NYm7Jjzp4j5fJ5GAVhgXiIDGE8dyhVqSSXsRCIwWnslaTsuNDjVpeFYjmFYaNK2 Ou2W3TI6IC5Yo22r67bJZgiDJCL3ZUmoiKgMayzx5ymoxVRSVrNXJluLWf6B+iJMAmhwPMS7TxcP oGJkiKwFrfizr5s2WjpVblZqgw5NqJ6SUHlVi7V1yIpUaAeYaW1Zu4ZNFtRhNTqHrEhVstpbVsNy jTaCa9EScjcEyFXSOhXajtkhG86lRa6Str2lNc0OmPAGa5GrpHUrtK5tUR2eay1ylbSdLS1y1k/Z kdgiV0nbrdC2HfdNKUMu0pJqT5Ci4U2g6jbSRXc/X+FQcEjgih2FO0fFbKViXpoI6NUdISPVgEet elC88lGC3T1n0ayUMSkx+FilMOFB9XmCCTktY6bh2h3X+YaMWV3HgOZARB0dIxmqJurgSbVVJ0lZ AcChEpOqkmELbbAKAFglERUsKckGqwCAVX1fxWJVbrAKAFjVzCexCgBY1aEnsQoAWNV2J7EKAFjV SyexCgBY2SBqEqD4kkhufPsxOoiGAfhQTUvP31eMJWPup0mgRXzJoyMNuk9PffEK+sk8zOuzl0/+ 2oozShe5mNc23pYdWZ8+nB1lh9nkotOZo3Rtsj+dkcXni5qcj+V0hgL3x4LlMHaWGkfRplG5tsa1 badlgrkwiZ2a1QwXlO86q/X166wG8/J1Vuvr1v9xVmsrTTs2q9FodL6sHUoZ6eTZUnZqXttK2XVe w5jvzj/Xee3Ens43Vzz7A9V1XsMtNLka3I/NjzqvuUrb7pngO4vQNk6Y5wubnNcCARuIu8tRQ66p Tq5H6a77u19wcrthST9ofT+DvWjcWf4LVmr3rY7lNZxBe9SwHTjqeIP7xsAYuEOY4oZ3Xvtvvdxk DcBVEcZ8FD4vcv64EDqy19kWMJqmC7vvRmu7vAAT8OrLTtGwQyi32Edpinur1V1O9xJ5mQmYnA+f PcZ3tjxfk5vLRqSrIjKOwoBrD4t4uhcX2oF4a73C2x2gPhqa72yjvCY0m7L1Bp7Rcu27xtCwhg17 6EDZuvfdxsAambbZ6npWx9uUbYGeJ2Bd3Wr9+uWfX75++fcCtUr70vLtDhziKyCShij/yLLHJS1C 4c0XVKpHpzJ41wXxQOgWghzq3dntfwAAAP//AwBQSwMEFAAGAAgAAAAhANfg2yHQAgAABAgAACEA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWysVe1umzAU/T9p72B5vymQ76IkVUqS /WmTaGkfwAUTUI3NbCcLnSb1tbbH6ZPs2kDbdZ0UafwBY997fM+5x3h8ccwZOlCpMsEn2D/zMKI8 EnHGdxN8e7N0RhgpTXhMmOB0gkuq8MX044dxESgWX5FS7DUCDK4CMsGp1kXguipKaU7UmSgoh7VE yJxo+JQ7N5bkG2DnzO143sDNScZxnS9PyRdJkkV0LqJ9TrmuQCRlREP9Ks0K1aAVp6AVkiqAsdl/ lqTLAtjqTDO65qzEyIbKA0z6eArsoy2LESc5TNyYKGTDzIoqbiSlZsQPn2WxLTbSJqwOG4my2ADU iditF+ow+8khDAbum/Rdg0SCYyLz6ZgEoAU6TjC0rDRPSCIBPWoUVZPRy2yUrt+JjdLFO9FuswFU 8LypYVUx+ptOp6FT6eA/s6pCCaReieheIS6Ap6Ff0YtWhwbMcDbwRYpeCV/HVYtWjyZegaZWLH28 FHFpiN/B206SgCm91SWjVhAomwQADg+QnxHja8qd2y34OtchowR8X4unpyHLonukBaJxptE1UZpK ZF0ApwAgx6COhubUkJTHGyLJlzfIhh8JYGcouqkQhpWE/xay2wg5J5qiDSMRTQWLoYJOG5rGGig/ wLEgLMFgRHCJb4lbaU0D/kvjBM6Dcff3gefNvVE3dPqzwdLp9WE0CmdzZ+bPhovhsL+4DAc/cN3o GKjqLKfLbLeXdL3X+NRW+W5nCOff9156AiWY7Ha70mu6shTCuOF1X7pt9CXRsmrM1z2RsEPTm+ac tOD/dhXpN4psWRZTtNrnd2906bWhC9wvAP2uNPY8tGzbcBb63rB36Sz87sLpLfpg2+H83Jl1l51e xzsPu6Pw2bbKMOdQ3alufXr8+enp8VcLXrU/kuqGgaG5huwlwuQ1KdYH+6eDuxd8FNqpAm7b+n/7 EmIwmtt7+hsAAP//AwBQSwMEFAAGAAgAAAAhALbl79yjAgAAsgYAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0Ny54bWysVVtu2zAQ/C/QOxDstyLJ7wi2A1u2+5MmRp0cYCNRlhCKVEna tVMUyLXa4+QkXVJW0ropEKD+sanV7nBnZkkNL3YlJ1umdCHFiIZnASVMJDItxHpEb28W3oASbUCk wKVgI7pnml6M378bVpHm6SXs5cYQxBA6ghHNjaki39dJzkrQZ7JiAt9lUpVg8FGt/VTBV8Quud8K gp5fQiHooV69pV5mWZGwmUw2JROmBlGMg8H+dV5UukGr3oJWKaYRxlX/2ZLZV8j2joO4p8SlqS0G QjpG5smKp0RAiYGpy7BBXd0oxuxKbD+qalUtlcu92i4VKVJbe6ih/uHFIc09CkzDhX9Uvm6QINpl qhwPIUIJyG5E0am9/cUiiNjOkKQOJi/RJL9+JTfJ569k+80G2MHzppZVzehvOq2GzgwMI0sOCcsl T5ki4TPBugoQ5VIm95oIiZStEjXT5Grb4Fr6dqcqJ7X0qcHBe0ATgWcU9UNyoSPrFLLJbtHUa5Tb 6Wh2U5nurSZ3+O+CEHFtVmbPmdMKGUGUoYPWlG+9IJgFg3bsdSe9hdfp4moQT2beJJz05/1+dz6N e99p0xRSNUXJFsV6o9j1xuA4QKTQYBwDPDBMeLcr7Ls0MWeAB+pgjxmHfquP0xoGQxTaYPOuBWed SJeg4PMRiFUIIuwVaTaccFn78W9X2o0rCykNevG7L61T+JIZVRvzZQMKd2i8aTytjfwvb9hJFek0 iqx4kTJytSnvjnRpn0IXvA0R+lVpnO5OkdONbTyJw6DfmXrzsD33OvMujm1/du5N2otWpxWcx+1B /Dy22jIX2N1bp/Xp8ceHp8efJ5hVN7L1xYhLe3G6u4+rT1Bdb/EUQ4RfCpyj2IUq/DYc7oaXFIvR fGvGvwAAAP//AwBQSwMEFAAGAAgAAAAhAHzUSJjnBAAADRIAACEAAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0OC54bWzMWMty4kYU3acq/9ClrBloPRBQxlNYhmw8tiswH9BIjVGm9YjUMJBU qua3ks+ZL8nplhoDwwzC9iIbLIvTR/d57kVX7zeJIGtelHGWDi36rmMRnoZZFKdPQ+vjbNLqWaSU LI2YyFI+tLa8tN5f//zTVT4oRXTHttlKEnCk5YANraWU+aDdLsMlT1j5Lst5iu8WWZEwiX+Lp3ZU sM/gTkTb7nS67YTFqVWfL5qczxaLOOS3WbhKeCorkoILJmF/uYzz0rDlTdjygpeg0acPTZLbHN5m 899nG4toWLHGDWpdw/NwKiKSsgQ3giyVYCCfY7kkAcuVHRpT5rOCc4VO178W+TR/LPTR+/VjQeJI UdUUVrv+oobpf1PAcNE+Ov5kmNhgsyiS6ys2QETIZmghcVv1iUNswDeShNXN8PluuHw4gQ2X4xPo tnkALNg9FDnPK4++dcc27sxiKTihO68qKMPRuyz8VJI0g5/K/cq98H5tyJTPij5fkir8UlHVuOpL HQ+DL3VMjaG7SLiej9rS4bB9p+MdxcTpdHoOdSyiIkNp164R+x5XzPlAbm6yaKsiOsdfJI6l4TJD oc6rOItSTuVWIM1sINaCwiDCxBM6SaAI2CDii99wq/xzaMEk2DQ3ju/wyDGu93gQYTZAHPCBo4Kp RuRp6+MUjZjIQHAG+toneR2IOPxEZEZ4FEvygZWSF0THDW0LyxS71M/QlDyNHlnBlFH7zCoVbIAn I77GZ1xW2f5+zhHEwy54FCzky0xEMMJ+XQXEEerXFEnz5Due76mEqmY4lX2PUgpElX2v5zkUpVC5 XzWUdruqQxMJk33dWvupqlN+lGlHVV9FuQfApV3X635V9PaxBgCscwLr7mMNAFj3BFZV284GAwDW O4c1AGC757AGAKx/DmsAwPbOYQ0A2P45bAU41UM4ScCwa5ZX9pTSVN1S5UFPVX2jmwcf5pG6cC9o 4ykPszQigq+5aECve+sC+tkyLpqz64a4gH2SrQpMv6bGu6owL6GPFyfZMebeVM1co2Yzlep9KdMB wdg3o+pFw0xNEEg4RsGSiYWFHQACpxOph5qSHH0x1RWvxFfd+tF0o67j0arPn0f+wXhzu33a6b5a 4EjCiju9YsRphG1HXSrT5qt7LIU6m3uaRg90Ss1EhUUnKnmrqcyMbsR3oKdHGlnz9amrnkoa8R1o 45GO1nzU8Wm3KWH/B1pr+Hp2T0l9IwMP+I70uOaz7R7MewnfkWYbPt/VY+ty+450veZTZI0TcuDv kfYbvq7nvywf/4/5gM4224ReMNSa+/29yjNKdMskP1AirZ2vVaJIfqNDtNoW1K+Nk0KEHn/24OQ+ pFVA764L/DhSP3D+QsJusWsHLW/UnbRcD1e9YHTbGtGRP/Z9b3wTdP+26l0/gqsyTvgkfloV/GEl tcI0WYFp2/bxQ5B2ngcnTFCa87bzoWuyMskytWXvTwhPzbTX5mUhiyoxf6xYgSfUM4Ke2YIvyc3b RsQ3EZmKOOLkfpXMj+LSfYu44EUDqE+G5sz8vCQ0u7INRgHt+O5Na0ydccsdeyhb/7bfGjkT27U7 /cDpBbuyLZXnKaxT9dakWr9++eeXr1/+fYNa1UJSvWTApXonoUtQFB9Y/rDWQxcvYVBHgb6V47UL 4qGgzxDFYV7jXP8HAAD//wMAUEsDBBQABgAIAAAAIQD8Px3nqAQAAHwRAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDkueG1srFjbctpIEH3fqv2HKe0zAV2QhMo4hTHeF8d2Lc4HjKXB qKLbSgOBbG1Vfmv3c/Ile3qkAeTgDSZ6ASF6zkx3nz7d0sX7TZqwtSirOM/GhvluYDCRhXkUZ89j 4+PjTc83WCV5FvEkz8TY2IrKeH/56y8XRVAl0S3f5ivJgJFVAR8bSymLoN+vwqVIefUuL0SG/xZ5 mXKJn+VzPyr5Z2CnSd8aDNx+yuPMaNaXp6zPF4s4FNd5uEpFJmuQUiRc4vzVMi4qjVacglaUogKM Wt0+ktwW8LaIw8eNwZRZucYN07iE5+E8iVjGU9x4iEO5KgX7HMslm/KCzqFsquKxFIKss/XvZTEv Hkq19G79ULI4IqgGwug3fzRm6mcGM1z0Xyx/1kg82CzK9PKCB4gI24wNJG5Ln1jEA7GRLKxvhvu7 4fL+iG24nB2x7usNcILdpsh5UXv0vTuWducxlolg5s6r2pRj6W0efqpYlsNPcr92L7xbazDymeCL JavDLwmqsav/VPHQ9pWKqT7oLhKmN7IsH7yF544Plg1eRGXo+K6Dm4xiM3Rdz/bVJhoJm9TQRSA3 V3m0pZA+4RuZ41m4zMHUJ1rBg6SSc7lNkGdcrxMTJ2I8eUYpJWABDyKx+AO3qi9jA3zHlk/a8509 ktzGQYh5gEDgA0sTTpUost7HOSoxldNEcMA3LsnLaRKHn5jMmYhiyT7wSoqSqcChbnEyQpdqDwUp suiBl5wOdYhMueABdobv2mcVBsrH60m3ddJ1GTwkPBTLPIlwCItChGLRCT6LAqhAA+UCLmvCnEcE 17Q8b1gnTVdHiweOaRJZTiXCq9lPeXmrqjHOIkgLXVIqn1Z30E+16oATNkjR7Niwh2xxaRGRaihn 6JEVOwXP2nvQgDR49h5vZDqK/CfhkWXNDeARSIPn7PFM2zOpxE47IBXBDpBQGsDhAaCP6j0PkFAa QHcPCDXAAc86IaE0gN4BoOeozJ3hMqE0gP4ekNBOT0orhoTSAI4OAN2hd2ZSCOW4JnWrHY7Wjkeq x0PhsIkhPyscpNcQTAjvkieLRkOUJKkeonyk5jpX7mrF1y3gaDMZ2mgVda/Yt9iWiPgDtJZ6E430 P81EqcGxDvImDTFbNUodqKHDmRpitjSJQBq8MzXEbNG1Aw0ZdSwhLbwOFKSF14GAtPA60I8WXgfy 0cJ7XT1AJIYmshtdFK3On3BINNSAU7UmnHOmmKFWomsuRUuJnC6UKJLf6ZBZN0HSn6NCpPRPz2F6 9mzJhfqhJsUFnkXoeeIv6P31wLenveHEvek5Q1z508l1b2JOvBmGn9nV1P3baEbrCK7KOBU38TMe X+5X0qAqPyUdZt/y8NxlDvZxxxFodbf9wdVZuclzmmkPO4Qa5H62QyxkWSfmzxUvsYOeM38waL4l N91GxNMRmSdxJNjdKn16ERe3C77iuR7QR0Pzg/75ltDsaDudTM2B51z1ZqY96zmzIWjrXY96E/vG cqzBaGr70x1tK/I8w+lOZeu3r//89u3rvx1wVTXy+pkel/QKQA0pSfmBF/drpWZ45wEeTdWtAm85 EA8y3ZsQhn5rcvkfAAAA//8DAFBLAwQUAAYACAAAACEA9tvBp6wDAAD4CwAAIgAAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0Vttu2zgQfS+w/0Bon11drIsjxC4c2d6XNglqt++s REdCKVJL0q7dYoH+1vZz+iUdUqLTOC6qbLwvsizOHM6cMzPk5atdTdGWCFlxNnb8l56DCMt5UbG7 sfNutRiMHCQVZgWmnJGxsyfSeTX548Vlk0pavMZ7vlEIMJhM8dgplWpS15V5SWosX/KGMFhbc1Fj BX/FnVsI/Amwa+oGnhe7Na6Y0/mLPv58va5yMuP5piZMtSCCUKwgfllWjbRoTR+0RhAJMMb7YUhq 30C2QIxaVYqSKStWOwcZe7GFFd+ZAAX5khaI4Ro+vAfTKscUGXsEjKEV2SljJpuVIEQ7sO1folk2 t8J4X29vBaoKjdahOG630JmZvwzM4MU9cr+zSDjdrUU9ucQpsIN2YwdE3OsnOOEUgkB5+zG//5qX Nyds83J+wtq1G0AEh01B/6bN6HE6gU3niBT/kF7rgwHjNc8/SsQ4JKx5aPPMr7cWVSev92lK1Gqi tB4O4qIC5VqJOq/W1NBkvaWh2sZ/ICiOg4vQa2kKkjAejh5yFXhRYtY1Y9Eo8qMgMptYJNikhW5S tbvixV4z/QF+QVBdNGOHYJ18C0ulWqo9JUYPYA2nkBI8wJhi3WiEDd4todFqlVGCoRE77dQko1X+ ESmOSFEp9AZLRQQyFEBbAuQliKOgNjpIwopbLPDbI2TNKk5hZ4jbxmtS0Mz+WsfhYx11Nd1SnJOS 0wJCCXSG0AhWsP8kqSbuSFFoC6hZWw/9lQ2jBAaLqf9TwsaefzHS6/+XsFBviG7pQcFnCq3pNjrL B0K3YhpF4WG3NGw9obaWJOcwpijZEtoD3kj9BPhVWYn+6MO2VXrzteAbocrewYdPha/WJ9Fhnp61 xULbYjOsyIPOMoQ8t7MKBVPlMxyFmK6drqfMbDFTUk9W8/LzuDT9bIeEHWpmcj0eY2s4/vT59SX2 vJk3GmaDaBovBmEEb6NsOhtM/WkyT5JofpXF/zjdBC8gVVXVZFHdbQS52ehDst809N0ggTPf9+7L FULQ3udVJbKqLDjXA/fniWcq6bm6rJVohfl7gwXsYLX5zcB7ijbnZSS2jCxpVRB0vak/HPFiDsjn 8gJ3SoA+SY0ZP2cu22ya+V4SXg3m/nA+COcRlG0yuxhMh4sgDLyLbDjKDmUrdeYMoutbrd+//vvn 96/fzlCr5qxu75Dwqm+d5tCl4g1ubrZmZsJ9G+ooM58auGFDqWjTexONYW/skx8AAAD//wMAUEsD BBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/Y dyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6 FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAz npC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq 6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4p DzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6 BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAs vrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLM E7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv 37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+v BkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidY c6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjN XEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphW mmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGV kIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ +4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhl SuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vl MWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzC Ic8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm5 1Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rG SXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWm h3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xl IcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb3 61AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyq mJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD /d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHrem/3UASh bqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3 WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx0 0MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNn FnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA //8DAFBLAwQKAAAAAAAAACEA7AJ+eAAcAAAAHAAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivzH8c/ti/tcal +0f+0z8B/wBmb9kb4J/GSz/Ze8KfCHxF4m1j4kftheKvgd4z8daj8XvB/iHxhpPhj4eeDdP/AGR/ i94Ol1KCHw3d6RBe+N/i34H0W61W805tQ1HRNMe91Gw6rU/+ChfhDWf2KfD37XPwl+HPifxd4i+I fiXRvhN8MvgB451Gz+HPjvUv2jde+K5+BUPwJ8e6rpdp8Q9O8Ba/4X+LcGq+F/iNr1naeMdG8H2P hzxJ4liOt6NpYnucnVh7GpXSqSjTrU8N7OFKrPFVcRWr1MNh6GFwUISxmMrYnE0/q+Ep4WhWniq9 TD0sOqtTFYaNWlG9SFPmprnjUl7WdSnDDU40aftq0sRi5yjhcLGjRVStWlia1JUaNDFVajjTwmKl R/Q6ivznvf8AgofoKfsd/s//ALSui/CTxX4o+J37TGo+Bvhp8K/2aNH8ReGrbxde/tH+L4dYtdb+ C+teNfEE2ieGdDtvhXr3hPx9H8VPHN3B9n8NeF/h54x8SWXh7Wb6wsvDeoXPAH7YPxs8P/tJ/Dv9 mD9sD9nn4e/BLxX8dvB/jbxR+z94/wDgh+0Jrn7Rfwo8e618LYbXU/iR8MPE2seN/wBn/wDZl8be BPibpXhbU9P8ceGNNHw+8T+EvGPhOy8Wz2vjTT9c8K3Og3fT7OTr4jDxdOc8Li8Tgas6dWlUw7xm DwdLH4jDUcXCcsLiatPBYjD4pQw9aq6lHE4adPnWJoe0xVSPsaFZqcY4jC0MbSpzp1IYj6picRVw tHE1MJOEcVRoyxGHxNGVStRpxpzwmMVRw+qYn2X6GUV4T8av2pP2ZP2bZfCcP7RX7RfwI+Ac3j25 1Gy8CxfGr4u/D/4WS+NLzSG01NWtPCcfjnxDoT+I7nS31nR11GDRxeS2Tarpq3KRG+tRL5dB+0V4 rb9vTX/2Ybiz8Jw/DTR/2PfDn7QyeIWt9Sj8VjxVq3xh8U+AL2zudWfW/wCwB4Uh0HQ7W9itx4fi 1GPUXubmXW5LJo7KHBVISq4WlzJfW6mZUqVRtKiqmU5PmGe46FSr8EJUcvyzFTkm7qp7KnJRdSLN ZxdOjWryTUaEMDUlGz9pOnmOcYLIsLOlT+KpCeY5hQoylFOMUqru3Skj7Hor5b+Dv7cf7FP7RHi6 6+H/AOz/APtgfst/HPx7Y6Re6/e+Cfg7+0D8Jvib4us9B025tLPUdbuvDfgrxbres2+kafeahYWt 7qUtklna3N7aQTzRy3MKPc+Hf7af7HPxeX4iv8J/2s/2Z/ignwf0i68QfFp/h38d/hb41X4XaDY/ 2h9u1v4it4a8VamPBOkWf9k6r9q1LxKdMsrf+zNQ86ZPsVz5dSagk5tRUsPVxUXJ8qeFoc/tsSm7 Xw9H2c/a1l+7p8k+eS5XYUZNyiotuNelhZJJtxxNdpUcPJbqvWckqVF2qVG0oRd0fTFFfFXir9tr 4ZXuqfDKx/Z98XfAT9oq21/9qDw7+zX8Ybzwt+1F8GtDk+COo6x4T8YeI7+e7sLnWNUuPG/xK0u7 8O6Rp1v8BtDNl8SdZsdeuvENjaDTPDmqE/GXxR/4LMfs6eI/g5+1Vrn7IvxX+CvxM+M/7L3xc8Af DbWPBGs+OvAvjKLxLoWu/FL4J+BvE/xS8M+Gvhl8UZ/Fes/C63j+LU3hnSPG91N4fs4fiNoeo6Lq FhMumtaakQftJ1KcE3UpOp7Sk1y1Y06MclqVcR7KfLUlhadPiHKajxUIyoSjianJUm8JjFQmq1Rj TnUlGMKroRhUTUqftMVWzbD0KE6kOaFLE1K2R5nBYapKFeP1eEp04wxOElX/AGior588E/tbfsp/ Evwr4q8dfDn9pv8AZ78f+CfAnirTvAvjfxj4J+M/w48VeFfBvjbV9Q07SdJ8HeKvEOheJL/SPD3i rVNV1fSdM07w9q95Z6ve6hqmnWVtZy3N7bRS8BJ/wUN/YBi8Mz+NZf25P2PY/Btr49X4VXPi2T9p n4LJ4Zt/ig2nzasvw3n15vGw0qLx62lW9xqa+D5LtfEJ0+Ca9GnG2ieRSLU5RhFqU5wo1IRj70pw xMqEMPOMVdyhXnisLCjJJqrLE0IwcnWpqVNOKm5JpU51aVRtWUKlCNedanNvSM6MMNiZ1YStKnHD 15TSVKo4/YVFIrK6q6MGVgGVlIZWVhkMpGQQQQQQSCDkUtMlNNJppppNNO6aeqaa0aa2YUUUUDCi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/IKST9qX9nj9uf9uH4p+Dv2Hfjd+0V4J/aI 8K/suw/C/wAa/DX4ofsieE/Btvr/AMJ/h74y8OeItN+IKfGX9pL4b/Ezw1psGt+INNSfV/DPwt8e Tf2VHqN/pWk61d29ppeoeJeFv+CdP7Us93+yL8Itd+LXiT4OeGPhf40/at/bu+N37QH7Ptz8F/Ec sn7anx/+JfifUPCnwf8Ahr4X/aJ+FvxO07W/hn8P/C3x0+OLp4z8bfAS0uNVXw/8NvEenSeEPG8l 9YaX+9VFRRgqU6dRudSdKtUrRlKcqcnzOtVoUpSwzoS9lg8e8BmmGSan9fyfLJ4ipXoRxlDGEm3S q0Iv2dGqnz0ko1KbnUpVsJiqjp11WhOWMy3G5rleIjUjOnHA5vj44enQxDwuIwv87i/sHftkfBC7 8UWvw0t9f/aOt/2X/wBvjw7/AMFCf2cvEfxZ8WfAjwF4g/aO0v43/Cz4i+D/ANrz9n8D4ZeHPhz4 C+HHxOtfFnj74lePPh/r2tfCL4afCbU/EHjzwVpt34ksLNPHfiLQPuTSvC3x/wD2rf2tP2a/jj8R /wBnDx7+yj8If2SbD4w+JNI8N/Gvxv8AAjxP8Xvir8ZPit4KX4YaNcaNo37Nvxc+PngHQPhX4I+H +s+OrnVdV8SfE7T/ABl4i8aa3oNjZ+A7TQfD9z4g1f8AT+itaUnSp06Ok6NH2bo0pRjCFF0Mky3I MOoKiqTUKGAyjL5UqTcqKxlCWMlTliMRiZ1liF9YqzrTclVqUpUatTmlUlWp1s0zLOcUqqrOrGcs ZmOc5rXxNWS9rOONnRjOFGjhaeH/AAx/4KZfA79uX4x/Eb4n+EPgb4T+JUvwh+L/AOyBrHwZs/EP 7P1l/wAE+tKuvEvxE16++Itlq/gv9tDxp+2n4W8efE23/Zy0/R/EmizeCNN/ZX8D+JfFdlceK/jD qOt2T6xP4QR/Dv2vP2fviZ8N/gX+018RviZpVn4E+Gdt/wAEFbP9kzxB451DW/7YsvDvxojuPGFl rPhy40H4ap40+IGrx6Pb+ItPvP7Q8O+EtX8O64XGl2usSiW6a3/o/rI8QeH9B8WaFrXhbxTomkeJ fDPiTSdR0HxF4c8QabZ6zoWv6Hq9pNp+raLrWkajDc6fquk6pYXFxZajp19bz2d7aTzW1zDLDK6N wvCQjhcRQinVnXjj051asoVZrG5VxzlPsJYinF1IUKGH4/zp4bljKWGnRy5wU6WHr0MX2wxcnj8J jJuVJYWrls4woRi4QeXZlwTmarU6NVzpvEVq/AeT/WHP3K8a2PUlGVbDzwn8y3wq+Gfxx+MsX7Vv 7KXx6Xx78Bv23/2mP+CXt58EfgDqGs/BX9nz4FfCu6+A/wAF213wNB4ovNJ/Zt/bm/4KC6wni/Rv iJ+0NpFt4s1XxX4p+G+mL4T1y00/4N/C2OXQfHM8vtXxZ/Z5/ah/a28PfD6Wy/YR1v8AZB1P9nH9 hT9q74KWGn+O/iP+zPq+pfFDxZ8df2d0+EnhH9n34I3HwK+NnxK0qz+CeieKdM0/xhrHij416h8J 47a98K/DAaT4CmnuvEmqeBf2V+Bv7Jn7K/7MDeJW/Zq/Zo/Z+/Z4bxoNJXxi3wN+DXw5+EreLF0A 6idCXxKfAPhvw+ddGinWNWOkjVDdDTjqmomz8n7bc+b9A115pTpZphMfhMTKc45tgMbhMwnThSwt 6uNrcUyeLwsaKc6WKp0eKsWq1StWxFDHY+nXx88Jh6GaY/LKnFl8qmArZfWgqcpZRi8vxWXuXtJu KweG4Rp1MPWTko1MJWrcIZfToUGnVwWXQoYWhivrGGpY1flD45/ZU+JKfAL/AIJUfDP4f/DTSdKP 7Lvx6/ZU8WfFDwpoWoeCdA0j4d+DPhp8HPGnhXxjdafbxatYaLqlvofiDV7GxXS/BraveX5uTd6R ZX1nHPcx/Ifxv/ZK/af8c/DP/gqp+zMf2X9c8Y+H/wBpr9rj4b/tF/Cv4kTeOP2f7r4PfE34c3N/ +yFa+Mfh/q+heJ/irpfxL0Txpolh8OfiNJr+j+MPhZY+A9Z0fQJItD8a69f63o+j6h/Q1RXRUryq 4/OMwqRhKrnePzfMMbSaboe1zmpwbXxFOlFy9pGjRr8C5JWw8ZVZ1FKWOhXqV6OIhSo4UsNCjhcp wsJVFHJcHk2EwFbntXgsklxL9VxE5RUYzxFWjxZm+GxDUI0nSlh50KNDE0I4h/gp/wAFBv2HPjx8 c/iX+19F8M/g5oniv4W/G39j79g34UWWlyav8MNJ0Xxv4x+Bv7anxK+IXjvwtrGh+JNe0uY2PhT4 K+LI7mOXxBY2/hvV9K1OXwzodzquqxTaND6v8R/2H/EviT9qH/gp78U7L4F+CdQ0b9of/gm98G/2 aPg74olt/hqt/wCL/FWmab+1Pp3xG+GwS7v49b8P6FdWviH4GWWsP4ot9E8HeILXT/C8CX2ow+C5 V0L9lKK87E4SGLyzFZXWqVnTxdDO8PVxamnjuXPXmixM1XlGS9phsPm+LwWClKnJUcEqeGqRrQ9p 7X0qWLnRxjxtOnSjN1uHa8KKi1h6M+Gv9WXgo0acZJ04YmXCmVzx6U71pvESpOg3h/q3gX7KXg/x h8Pf2XP2bPAPxCsptN8feB/gF8HfB/jjTrjUrHWLiw8YeGfh34d0XxNZT6vpl7qWm6rNa61ZXsEu pafqN/Y3zxtdWl7dQSxzye+0UV6mOxlTMMdjMfWjThWx2KxGMqxpKUaUamJrTrVI04zlOUacZTag pTnJRSTlJ3b8rAYOnl+BwWAoyqTo4HCYfB0p1XGVWVPDUYUacqsoRhGVSUYJzcYQi5NtRirJFFFF cp1hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8d3vx+8eeG9H1Ca 28HaZ49m0l/2j/F+uX2p+LYvBR03wN8HfitfeGYNK0i107wb4hTW/ET6Hd6fbaPb339iWV9Jpk0m ueI7Oe5N7L2vxt+Pd38I5/Cn9neEofGFtrEX9o6/bW9z49GuaBoI1LSNPbWVt/CXwr8eeG7W0Uaj cOLzx/4u+HGiTXFi9ra63cFb6bTfbH8H+EpI7mGTwt4ceG9tPEFheRPommNHd2Hiy+/tTxTZXKNa lZ7TxLqYGo+ILaUPDrN8Pteopc3H7ysvxV8Mvhv46udFvPG3w+8EeMbvw3I8vh268VeFNB8Q3OgS ySW0skuiz6vYXkulyPLZ2cjvYtAzSWts7EtBEUKen1VVPeUK05YtqylVoupiXTp07JRi6dOWEi3a M5ulWcql6kZxKt5OtKn7nPHEeyi9YwnP6u6Eno3aEli1NK8OWph1GnalKM/mj9pvx/8AGHwt4q8P ab8P9Zs/Dfh21+FHxe+Iut6lBfaJJrOoah4HbwhZWFhNo/iP4aeMrK50m1uPFNlN9l07XfDGo6s9 5dTTa3pcHh6HTfFXfan8cfE1r4wvNH07wDo2o+GV8dX3ws0zV5PHk1n4pvviFbeCp/GFtbXXg5PB l5ZaZ4UuhB/Z7eIJPFtxrUEUkeuDwjNoskV3J7tqvhrw5rsnm63oGiaxKNL1TRBLqulWOoSDRdbe xk1nSN93BM39l6vJpemPqlhn7Jfvp1i13FK1pbmPIT4d/D+PxjJ8RE8C+Dk+IE1r9hl8cp4Z0RfG MtkLZLMWcniYWI1p7UWkcdr9na+MP2aNINnlIqiVGXJTg5tWWKdSaUXUdSti1Uoyi5prlo4OP1WF NrkhWmsVKNeNOeGxLk170lFc/LSjCLcvZWhTrKTlGMoycp1qtOtUkpc1SnQeFg6HtoYjC/P/AIE/ ap034geJNC8N6V4OvLafxTJ4Rbw3Pe61Ao1Oy1DwndeKPiFcPbR6dJcWVx8LprT/AIRzXLO4UG78 Q3ulWLz6Z/aEbp6hqfj/AMWXHj7XfBvhfwx4futI8J6FpOqeMPEuteMbvR9Z05/EVrrs+kr4X8I2 ng3xDD4ljjGin7Zdaz4h8JWXnSyWthLqc9hqEVv3WneCfBmj3dlf6T4R8MaXfaaNfGnXunaBpVld 2A8V6nHrXigWVxbWkU1qPEmsRRatr4geP+2NTjjv9R+03SLKK2rfDzwBr/iTSfGWu+BvB2teL9Ag a10LxVq3hnRdR8SaLaubgvbaTrl5ZTapp0Dm7uy0NndQxsbq4yp86Tcq8XVoqEP3NWaq+1nCU+SE p03TiqEbqqqUHGFaMZVliFVqVU8XKlGlCJD3Kk5NudOKpxoxmoc8+SV3VryUfZ+2rJyVTkovDxjG nGGGUnUqT+XfC37RnxAtPhrDqPjLwT4fk8Zw/D34O+LtESDxT4s1hfHcHxLk1TTIftmlfDz4NeKf E2i+MftHh7VNUvPCfgzwP480i3gng+zeIP7OttSvdMz7z9qL4l6z8OvG/jTwV8KfC1o/gr4LTfEv WZPG/jnxLpradr3meP7P/hHrXwxF8N7bXNZh026+H+oXF2dcuvh7qVzDd2NhNZ6Lfvf/ANl/Vurf Db4da/pE3h/XfAPgrWtBudL0XQ7jRNW8K6FqWkXGi+G7iW78O6PNpt5YTWUul6Ddzz3Wi6e8LWml 3E0s9jDBLI7GzpPgLwNoGlTaFoXgzwnouh3GkQ+H7jRtJ8O6PpulT6DbnUDBok2nWdnDaS6RAdW1 Uw6a8LWUR1PUNkK/bbnzNq0lUlipwioOdec8NFcsIQoypTiqdRRi1GaqyjV5qceROMYRpxpRlSqF G1Orh3Nc9GCouvCV5TnKDwsqijOTd4VHTxNNe0TmqNZc05VlGrT0vDl1rd7oWk3niPT9L0rXbmwt 59V07RNWu9d0mzvJIw8sGn6xf6L4dvNQtkJHl3NzommSuPvWqYydqsvRND0TwzpOn6B4c0fS/D+h aTbR2WlaLomn2mlaTplnEMRWmn6bYQ29nZ20QJEcFtDHEg4VBWpSm4uc3BcsHKTjHVWi2+Vayk9F Zayk/wC893lRjOFKlCpPnqRpwjUn/POMUpT6fFJN7LcKKKKk0CiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooA/9kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEA WJuQwqoAAAAfAQAAEQAAAHBwdC9wcmVzUHJvcHMueG1sjI87DsIwDEB3JO4QZacpDAhV/SyImQEO EKVuGylxIjv8bk/ER4Kto2W95+e6u3snrkBsAzZyXZRSAJrQWxwbeT4dVjspOGnstQsIjXwAy65d LupYRQIGTDpl9Egii5Ar3cgppVgpxWYCr7kIETDvhkBepzzSqHrSt3zAO7Upy63y2qL88DSHD8Ng DeyDufgc8JYQuFcJTzby1xbn2H7/+EtS7RMAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAA ABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGij EuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQ pmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlI A1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEAo4oSaYUBAABJAwAAEQAAAHBw dC92aWV3UHJvcHMueG1sjFLBjsIgEL1vsv9AuGur7lZtrF42e/Kwie7eCdBK0gIBrNWv36FYW6MH TzAzzJv33rDaNFWJam6sUDLDk3GMEZdUMSGLDP/uv0cLjKwjkpFSSZ7hM7d4s35/W+m0Fvz0YxAA SJuSDB+c02kUWXrgFbFjpbmEWq5MRRyEpoiYIScArspoGsdJVBEh8bXfvNKv8lxQ/qXoseLSBRDD S+KAvD0IbTs0/QqaNtwCTNt9R2kN4qSnXf61En0Mb50ynG157pC9gFWfyTTG0bC2V7otLT+SpC1F jzi2FIz3sHRXskEUrqgmZkdJCXZPsB9gfbBekdQ2yG8phqUwf7ZTIH1+kobh1z6dKiMKIVGT4dFs CSs+wwVOYA+vaE+gOAK7rXV+aHtH0AkegZ3KXDDSymZ4OgnquichuVh0eD2IBx8I9Izu5UvluN3z xvUUBmweZAPzZ7Lv0n5IsGsoO2juGN5mwOMnFAoj2E4TCl8VUfBsPpvPYNmAQcG4WxTcq8MX+QcA AP//AwBQSwMEFAAGAAgAAAAhAI+4WideAQAAmgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySwU/DIBjF7yb+Dw33ltLNbZK2S9Ts5BKT zWi8IXzbiC0lwNbtv5e2W+2iB4/wHj/e+yCdH8siOICxslIZIlGMAlC8ElJtM/S6XoQzFFjHlGBF pSBDJ7Bont/epFxTXhl4MZUG4yTYwJOUpVxnaOecphhbvoOS2cg7lBc3lSmZ80uzxZrxL7YFnMTx BJfgmGCO4QYY6p6IzkjBe6Tem6IFCI6hgBKUs5hEBP94HZjS/nmgVQbOUrqT9p3OcYdswTuxdx+t 7I11XUf1qI3h8xP8vnxetVVDqZpZcUB5Kjh10hWQrwopICAp7ncajRtgrjK5drv9px9gK182m+EW zLqlf4eNBPFwGvh+a43dwEE2b5iPkxQP1/6ytnd3I4jAN6Fd74vyNnp8Wi9QnsQkDmMSJtN1PKXJ hMazjybX1fmmWbdRntP9k3hPCaF34wHxAsjbxNe/Kf8GAAD//wMAUEsDBBQABgAIAAAAIQCyv9Zs PQIAAOYEAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJxUS4/aMBC+V+p/sHJqD+CwC2iFjFcItOVQChLZ7dlNJolVx45sN7v013eSkACFVmp9 msfneXyeMXt8KxSpwDpp9DwYDcOAgI5NInU2D56jp8FDQJwXOhHKaJgHB3DBI3//ju2sKcF6CY5g CO3mQe59OaPUxTkUwg3RrdGTGlsIj6rNqElTGcPKxD8K0J7eheGUwpsHnUAyKPuAQRtxVvn/DZqY uK7PvUSHEgvmLDJeqEgWwEfhhNGTyr4amzg+mkwZbUW2KEslY+GREb6RsTXOpJ5sm9rJzryC3Rmp PaPnQOQDHDbVXHtqeuZbPXCxBdBkn5tX8mE8u//I6A0g2wkrMivK3PHpPUJOKtsrmYDjY0aPEvti PBpCRluBrWWSgD560Xyhs81mqWTZ4DuR7WOhYIkE8VQoBxi6N7A1iPrxd0Jax1nlZxXE3lji5E98 /nFAvgkHNa3zoBJWCu2R3hrWKo2sSuctj3AOMDb6Wr0Rz2HnshzzUQNA4a/ANlbTLYmkV+D+IQWy iOVcpaiNbZuY+5KANsU2xSfxN/iYnPPRlNay0VZ5nJkrInpKVostESozVvq8OO+jR2BenCqSgXek O/Wt1JqCxLlUyc1rq8UnAhXe/IN3S7yVWQaWeFwKS0CJsh6EPm8j9pz8xsLSFKXQB76ULjaMdir7 LPV391xGZiU8dLN1aWT7HDtK8A/o/CcDW+NYWVUHWeZCZ5B0mGtHvaUv7bfFR3fDEE+zkJ2t3rPu g+K/AAAA//8DAFBLAQItABQABgAIAAAAIQBSFT0f+gEAAMwNAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAA AAAAMwQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAA AAAAaQcAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAaAgAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAZQkAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAA AAAAAAAAAAAAYgoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAN3zjbYrAQAAXwUAAB8AAAAAAAAAAAAAAAAAXwsAAHBwdC9fcmVscy9wcmVzZW50YXRpb24u eG1sLnJlbHNQSwECLQAUAAYACAAAACEAGXTZxWECAAD5DAAAFAAAAAAAAAAAAAAAAADPDQAAcHB0 L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAXcFdCxsLAADqYQAAFQAAAAAAAAAAAAAA AABiEAAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhAIgGbbzFCAAA4jsAABUA AAAAAAAAAAAAAAAAsBsAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQCn5+DI sAcAAHAtAAAVAAAAAAAAAAAAAAAAAKgkAABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYA CAAAACEA2Yz+qEYCAADxBQAAFQAAAAAAAAAAAAAAAACLLAAAcHB0L3NsaWRlcy9zbGlkZTEueG1s UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAABC8AAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAtAAAAAAAAAAAAAAAAAA0wAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 MTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAAAAAAAAAAAAAAAWMQAA cHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAB+MgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAA AAAAAACGMwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACONAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAACWNQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACeNgAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8b4AAAA3AQAALAAAAAAAAAAAAAAAAACmNwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACu OAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAC2OQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAA AAAAAAAAAAC+OgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAyhuxNV4DAAAYCwAAIgAAAAAAAAAAAAAAAADGOwAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDEwLnhtbFBLAQItABQABgAIAAAAIQCgetODfwQAAKQQAAAhAAAAAAAA AAAAAAAAAGQ/AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAA ACEA4wuhWEYDAADhCgAAIQAAAAAAAAAAAAAAAAAiRAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDIueG1sUEsBAi0AFAAGAAgAAAAhANtUiB4xBAAAUBAAACEAAAAAAAAAAAAAAAAAp0cAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLAQItABQABgAIAAAAIQB3QRCEkgcAACIv AAAhAAAAAAAAAAAAAAAAABdMAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwEC LQAUAAYACAAAACEAF1tEugwEAACzEQAAIQAAAAAAAAAAAAAAAADoUwAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAGn8/1VoBQAAghsAACEAAAAAAAAAAAAA AAAAM1gAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQDX 4Nsh0AIAAAQIAAAhAAAAAAAAAAAAAAAAANpdAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 Ni54bWxQSwECLQAUAAYACAAAACEAtuXv3KMCAACyBgAAIQAAAAAAAAAAAAAAAADpYAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAHzUSJjnBAAADRIAACEA AAAAAAAAAAAAAAAAy2MAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQA BgAIAAAAIQD8Px3nqAQAAHwRAAAhAAAAAAAAAAAAAAAAAPFoAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAAACEA9tvBp6wDAAD4CwAAIgAAAAAAAAAAAAAAAADY bQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQItABQABgAIAAAAIQD5zwk5 gwYAAFwbAAAUAAAAAAAAAAAAAAAAAMRxAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItAAoAAAAA AAAAIQDsAn54ABwAAAAcAAAXAAAAAAAAAAAAAAAAAHl4AABkb2NQcm9wcy90aHVtYm5haWwuanBl Z1BLAQItABQABgAIAAAAIQBYm5DCqgAAAB8BAAARAAAAAAAAAAAAAAAAAK6UAABwcHQvcHJlc1By b3BzLnhtbFBLAQItABQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAAAAAAAAAAAAAAAIeVAABwcHQv dGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAKOKEmmFAQAASQMAABEAAAAAAAAAAAAAAAAA ZJYAAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhAI+4WideAQAAmgIAABEAAAAAAAAA AAAAAAAAGJgAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhALK/1mw9AgAA5gQAABAA AAAAAAAAAAAAAAAArZoAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAACsAKwAADQAAIJ4AAAAA ------_=_NextPart_001_01CAB571.9E2B91AA-- From sung.lee@us.fujitsu.com Wed Feb 24 18:32:09 2010 Return-Path: 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 53E3328C2B0 for ; Wed, 24 Feb 2010 18:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 3ph9DuU1CToR for ; Wed, 24 Feb 2010 18:32:08 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 1474228C10B for ; Wed, 24 Feb 2010 18:32:08 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o1P2ZPGM010444; Wed, 24 Feb 2010 18:35:25 -0800 (PST) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id o1P2ZP7S010441; Wed, 24 Feb 2010 18:35:25 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.8/8.13.8) with ESMTP id o1P2Y8pe029788; Wed, 24 Feb 2010 18:34:09 -0800 (PST) Received: from [10.157.253.32] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id o1P2Y6a28345; Wed, 24 Feb 2010 18:34:07 -0800 (PST) Message-ID: <4B85E199.6030908@us.fujitsu.com> Date: Wed, 24 Feb 2010 21:34:01 -0500 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Salazar, Ruben" References: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> In-Reply-To: <09D9C0631368C244941E610D99FEA71001BE78DD@usatlsv105.am.bm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, "Dan Lang \(dlang\)" Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 02:32:09 -0000 Pascal, I too agree with Ruben that this is a great move in the right direction. Following Dan's recommendation, I will forward this recent decision from Cisco to our legal. Best regards, Sung Salazar, Ruben wrote: > Pascal, et al. > This is definitely a great move in the right direction. > We feel much better with the new IPR statement from Cisco. > Regards > > Ruben Salazar, PhD > Director of Research and Technology > Landys+Gyr EMS > Office: 678 258 3165 > Cellular: 678 438 0063 > ruben.salazar@landysgyr.com > www.landisgyr.com > manage energy better > > > > > Ruben Salazar > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > manage energy better > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, February 23, 2010 12:21 PM > To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel Baccelli > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 > > Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco > IPR debate: > > It is my understanding that this new declaration implements Roger's > suggested compromise regarding Sung and Ruben's concerns, also relayed > by Emmanuel. > > For reference: > Roger suggested: > http://www.ietf.org/mail-archive/web/roll/current/msg03045.html > Sung said: > http://www.ietf.org/mail-archive/web/roll/current/msg03034.html > Emmanuel said: > http://www.ietf.org/mail-archive/web/roll/current/msg03063.html > Ruben said: > http://www.ietf.org/mail-archive/web/roll/current/msg03026.html > > With this new IPR declaration, Cisco retains its defensive right in the > context of RPL implementations *only*. By the new terms Cisco will not > "walk freely anywhere" in someone else's "property". And the answer to > Sung's question about "infringing patents NOT related to RPL" is now a > NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does > the exact same, which seems quite fair to me. For all I know, this is a > major and somewhat exceptional step that should be recognized as such. > And alternate terms based on RAND are still available to anyone who > would prefer that way. > > Sadly, I'll still refrain from detailing which exact pieces RPL I > personally think are covered by this IPR. I think it is pretty clear by > now that this would not have a lot of value since 1) I'm not a lawyer, > and 2) even less your own lawyer. Also the logic of claims somewhat > escapes me, in particular when it comes to coverage. All I know is that > the disclosures I was involved with detail ways to build trees and DAGs, > propagate metrics and paint unicast and multicast routes along the DAGs, > compress and expands routing headers, all things that are somewhat > similar to RPL operations. > > I sincerely hope that this declaration will allow us to reach a positive > consensus on the current poll about Cisco's IPR and move forward with > RPL as soon as possible. Please let us know. > > Pascal > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: Tuesday, February 23, 2010 5:18 PM > To: Pascal Thubert (pthubert); wintert@acm.org; > rpl-authors@external.cisco.com > Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; > jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org > Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-02-23 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1270/). The title of the IPR > disclosure is "Cisco's Statement of IPR relating to > draft-ietf-roll-rpl-06." > > The IETF Secretariat > > > > From pthubert@cisco.com Wed Feb 24 23:07:01 2010 Return-Path: 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 A7FEA28C142 for ; Wed, 24 Feb 2010 23:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.707 X-Spam-Level: X-Spam-Status: No, score=-9.707 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ThLNUd2cjaiF for ; Wed, 24 Feb 2010 23:07:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 607B428C12C for ; Wed, 24 Feb 2010 23:07:00 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABaxhUtAZnwN/2dsb2JhbACbFXOjPJhShHMEjjU X-IronPort-AV: E=Sophos;i="4.49,537,1262563200"; d="scan'208";a="488229233" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 25 Feb 2010 07:09:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1P798wg027766; Thu, 25 Feb 2010 07:09:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 08:09:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 08:08:43 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> In-Reply-To: <44516837-62BD-4D98-AF91-E31092CF2601@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Questions on DAO operations Thread-Index: Acq1AKRzRApvjdcURFGh/D86dX1YeAA529yg References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com><00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> <44516837-62BD-4D98-AF91-E31092CF2601@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Philip Levis" X-OriginalArrivalTime: 25 Feb 2010 07:09:08.0385 (UTC) FILETIME=[6C620110:01CAB5E9] Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 07:07:01 -0000 Hi Phil: I globally agree with you.=20 I think we are pretty ripe WRT to the case where source routing is not used. We have mechanisms that loads nodes send up their DAOs when then like, and gather DAOs from their subDAG when they like. What's missing there is more of a matter of recommending when those mechanisms are to be used. When it comes to source route, there are a lot more questions: - should the record route mechanism be part of the DAO as it is today or should it be part of the traffic as Richard suggested. There are pro/cons for both approaches and we really need to discuss that in this list. -(as you say) optimization for the case where only the root store states. Right now, we have an S bit mechanism that is not really spelled out in the spec. This mechanism has assumptions that are not obvious. We need to agree on it. - what routing header will be used? How to compress them? This question is holding 6LoWPAN HC at the moment. I think we should have a number of threads to examine all of these questions. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, February 24, 2010 4:22 AM To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: > >> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >> >> One of the main purposes of including ranks towards downwards=20 >> destinations in a DAO is so that a node receiving two DAOs for the=20 >> same downwards destination can use rank to make a more intelligent=20 >> decision if the rank differs (i.e. preferring the one with lesser=20 >> rank). > > Let's back up -- the purpose is clear but how it achieves that purpose > isn't. How is this value computed/filled in? Should -07 specify this?=20 > Is it correct that DAO Rank is the rank advertised in DIOs? Does that=20 > mean that a node sending DAOs to multiple DAO parents may specify=20 > different DAO Rank values. How does this work for aggregated prefixes? I think it's clear that the DAO mechanism is not nearly as fleshed out as the DIO mechanism. The text is intentionally vague (notice all the 'may' text around it) about what the DAO Rank field can contain - it is simply a place-holder acknowledging the fact that we may want to convey some notion of cost towards the destination. DAO aggregation is something we haven't even discussed yet. But even before that, we need to back up even further and analyze whether the basic DAO mechanism fits our needs. There is concern from the ROLL WG (including myself) on how DAOs are sent or triggered - specifically in cases where a network only caches a subset of the DAO information being sent around. The main challenge is that the WG would like to see a solution that allows both networks where all nodes maintain downward routes and networks where only the root maintains downward routes. Some would even like to see networks that where only some nodes maintain some subset of downward routes. Unfortunately, there's some added complexity in requiring an implementation to support these different modes (e.g. nodes always have to maintain state to know when to trigger DAOs from their children). There's certainly a number of dependencies that are not so obvious at first blush (e.g. a single DAG parent change could cause DAOs to be sent by every node in that sub-DAG). -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Wed Feb 24 23:15:19 2010 Return-Path: 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 120063A863F for ; Wed, 24 Feb 2010 23:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-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 CKGO+klr58wn for ; Wed, 24 Feb 2010 23:15:16 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4D78D3A862A for ; Wed, 24 Feb 2010 23:15:13 -0800 (PST) Received: from [10.240.234.141] (adsl-85-157-217-148.regionline.fi [85.157.217.148]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1P7H0F8019163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Feb 2010 09:17:16 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <2DE35018-4D70-4E63-8C24-879C73B3846F@cisco.com> Date: Wed, 24 Feb 2010 22:13:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <973A96A0-6F62-4C45-803C-4A6DB97D11FB@sensinode.com> References: <2DE35018-4D70-4E63-8C24-879C73B3846F@cisco.com> To: Dan Lang X-Mailer: Apple Mail (2.1077) Cc: roll@ietf.org Subject: Re: [Roll] Our revised IPR declaration on ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 07:15:19 -0000 Dan, Excellent! I'd like to thank Cisco for the excellent work listening to = feedback from all involved and finding a very good compromise!=20 Zach On Feb 23, 2010, at 17:50 , Dan Lang wrote: >=20 > Hi, I wanted to provide a little commentary on the revised licensing = commitment language that was just distributed on the mailer. We believe = that it will satisfy the concerns as we understand them and allow the WG = to move to the next step. Again, the proviso for the commentary is that = it is not intended as an interpretation or legal advice and you should = seek your own legal counsel. =20 >=20 > Essentially, our new statement, like the old, promises to not assert = our essential patents against functionality that implements ROLL, once = standardized. The difference is that whereas the old statement = suspended, at our option, this commitment in response to any patent = assertion against Cisco or Cisco products, the new statement only = potentially suspends our commitment as to those who assert their = essential patents against Cisco or CIsco products for implementing ROLL. >=20 > Dan Lang > Director, Intellectual Property > Cisco Systems, Inc. >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jhui@archrock.com Wed Feb 24 23:34:07 2010 Return-Path: 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 0FADF28C142 for ; Wed, 24 Feb 2010 23:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 xhgKWzSsQNBg for ; Wed, 24 Feb 2010 23:34:05 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C4CE03A8443 for ; Wed, 24 Feb 2010 23:34:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 516BEAF99B; Wed, 24 Feb 2010 23:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFZrmCXMAL68; Wed, 24 Feb 2010 23:36:11 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id DDAA5AF914; Wed, 24 Feb 2010 23:36:10 -0800 (PST) Message-Id: <0E2C7A75-1FFD-4E56-9A5F-DAA3BCAFD988@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Feb 2010 23:36:09 -0800 References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com><00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> <44516837-62BD-4D98-AF91-E31092CF2601@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 07:34:07 -0000 Hi Pascal, On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > I globally agree with you. > > I think we are pretty ripe WRT to the case where source routing is not > used. We have mechanisms that loads nodes send up their DAOs when then > like, and gather DAOs from their subDAG when they like. What's missing > there is more of a matter of recommending when those mechanisms are to > be used. I think there are still some concerns on the lack of compactness for the messages - that certainly is the case within the 6lowpan WG. Communicating and storing full IPv6 addresses is fine in the generic case, but there has to be a more efficient way. > When it comes to source route, there are a lot more questions: > > - should the record route mechanism be part of the DAO as it is > today or > should it be part of the traffic as Richard suggested. There are > pro/cons for both approaches and we really need to discuss that in > this > list. > -(as you say) optimization for the case where only the root store > states. Right now, we have an S bit mechanism that is not really > spelled > out in the spec. This mechanism has assumptions that are not > obvious. We > need to agree on it. > - what routing header will be used? How to compress them? This > question > is holding 6LoWPAN HC at the moment. > > I think we should have a number of threads to examine all of these > questions. Yes, I agree these are all issues. I think Richard actually suggested that record-routes are unnecessary if only the root caches downward routing information, though record-routes can be useful in some situations (e.g. on-demand route discovery). A topic that seems to come up every so often is when/where the use of labels show up. That could change our thinking and/or perception. What really worries me is the hidden complexities that result from needing to support both simultaneously. I agree that piece-wise source-routes and being able to operate networks where nodes have widely varying capabilities can take on different responsibilities, but we need to be careful that doing so does not grow beyond our state/ communication complexity goals. Looking forward to talking through these issues in depth. -- Jonathan Hui > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Wednesday, February 24, 2010 4:22 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > >> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: >> >>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >>> >>> One of the main purposes of including ranks towards downwards >>> destinations in a DAO is so that a node receiving two DAOs for the >>> same downwards destination can use rank to make a more intelligent >>> decision if the rank differs (i.e. preferring the one with lesser >>> rank). >> >> Let's back up -- the purpose is clear but how it achieves that >> purpose > >> isn't. How is this value computed/filled in? Should -07 specify this? >> Is it correct that DAO Rank is the rank advertised in DIOs? Does that >> mean that a node sending DAOs to multiple DAO parents may specify >> different DAO Rank values. How does this work for aggregated >> prefixes? > > I think it's clear that the DAO mechanism is not nearly as fleshed out > as the DIO mechanism. The text is intentionally vague (notice all the > 'may' text around it) about what the DAO Rank field can contain - it > is > simply a place-holder acknowledging the fact that we may want to > convey > some notion of cost towards the destination. DAO aggregation is > something we haven't even discussed yet. > > But even before that, we need to back up even further and analyze > whether the basic DAO mechanism fits our needs. There is concern from > the ROLL WG (including myself) on how DAOs are sent or triggered - > specifically in cases where a network only caches a subset of the DAO > information being sent around. The main challenge is that the WG > would > like to see a solution that allows both networks where all nodes > maintain downward routes and networks where only the root maintains > downward routes. Some would even like to see networks that where only > some nodes maintain some subset of downward routes. Unfortunately, > there's some added complexity in requiring an implementation to > support > these different modes (e.g. nodes always have to maintain state to > know > when to trigger DAOs from their children). There's certainly a number > of dependencies that are not so obvious at first blush (e.g. a single > DAG parent change could cause DAOs to be sent by every node in that > sub-DAG). > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Thu Feb 25 01:48:48 2010 Return-Path: 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 AA46C3A865A for ; Thu, 25 Feb 2010 01:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] 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 P6MkcjU2VNUY for ; Thu, 25 Feb 2010 01:48:47 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id D6A9B3A7B31 for ; Thu, 25 Feb 2010 01:48:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 10:50:56 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151BB99@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Questions on DAO operations Thread-Index: Acq0+vTBYd++PjEdQWawKNkklJHAzwAan6hQACYfxaA= References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D0151BB99@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 09:48:48 -0000 Hi Pascal Thanks for taking time to explain your thoughts on DAO. Unfortunately, I did not really get the idea of your slide deck! You have Dest sending a RR stack back to C>B>A - but is A then sending this to child which then sends it to Parent? Is the distinction that Parent and Child are stateful routers while A,B,C,Dest can only forward source routed packets? Maybe some different colors or shapes could help clarify this ;-) Finally another small clarification: > Note finally for the gory side of it that A, B, and C etc...=20 > are not link local addresses. They have to be global or ULA,=20 > because they can be used multihop. An implementation might=20 I agree in this but should RPL do an effort on definition and=20 compression of such source route stacks? My point is that you will need to do the same source routing for actually carrying real traffic along the same route. As far as I understand IPv6 deprecated source routing as it was originally defined, so how would you source route IPv6 packets across a 6lowPan/RPL network? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, February 24, 2010 17:51 > To: Jonathan Hui; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations >=20 > Hi John and Jonathan. >=20 > I think Question 2 deserves a few more words: >=20 > the short answer > --------------------- > The point is that the record route in the DAO is for the=20 > (sole) use of the recorder, when the RR stack has become a=20 > routing header in a packet on the way back to Destination. > The packet will have to go between the recorder and loose=20 > Source Record Route next_hop in the DAO stack, and the=20 > question is whether the routing info to get there will have=20 > to be picked from the routing header in the packet, or can be=20 > found in the routing table of the recorder. > The IP next-hop to get to the LSRR next-hop is definitively=20 > the source of the DAO, that's what the DAO is all about. So=20 > the question is whether the recorder has a route to the LSRR=20 > next-hop via the source of the packet or not.=20 > If not, then the recorder needs to insert the next-hop=20 > information it will need as the new LSRR next-hop on top of=20 > the LSRR stack. >=20 > The long answer > ------------------- > requires an example, illustrated in the slides attached.=20 >=20 > Let us consider a DAO that is originated from Dest. No one=20 > below Parent decided to cache the specific source route A->B->C->Dest. >=20 > Because nodes do not cache everything, it is acceptable,=20 > though, that DAO routing states are installed all the way=20 > between child and A. The result is that there's no need to=20 > additional source route to reach A from child inside .=20 >=20 > We'll see how that works by forwarding the DAO up one more=20 > time, child to parent, and see what happens whether the=20 > parent has a DAO route to A via Child or not. >=20 > Childs sends this to parent: =20 > IP header: > Source IP =3D Child > Dest IP =3D Parent > DAO: > dest =3D Dest > Stack =3D A, B, C >=20 >=20 > Case 1: Parent does a route look up for A, and that does=20 > resolves via child. Either parent is missing a routing state,=20 > or its routing state is obsolete. Parent updates the Stack=20 > that is now Child, A, B, C. > Case 1a) If parent decides to cache for Dest, then it stores=20 > Dest via Child, A, B, C.=20 > Parent forwards the DAO to its ancestor as: >=20 > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO:=20 > dest =3D Dest > Stack =3D >=20 > The result is that packets to Dest should come back=20 > without a routing header, with the IP header destination set to Dest. > When Parent forwards a packet to Dest, it=20 > changes the destination to child, and inserts a RH A, B, C,=20 > Dest. and proceeds forwarding the packet. > Child being connected, the lookup resolved immediately=20 > and the packet is passed to child. >=20 > Case 1b) If parent decides not to cache for Dest, then it=20 > forwards to its own ancestor > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO:=20 > dest =3D Dest > Stack =3D child, A, B, C >=20 > The result is that packets to Dest should come back=20 > with a routing header child, A, B, C, and with the IP header=20 > destination set to parent or child, depending on whether=20 > ancestor has a route to child via parent or not. > If Parent is the destination of the packet,=20 > then it consumes the next entry in the RH, thus setting child=20 > as the destination in the IP header, and proceeds forwarding=20 > the packet.=20 > In any case, child being connected, the lookup is=20 > resolved immediately and the packet is passed to child. >=20 >=20 > Case 2: Parent does a route look up for A, and that resolves=20 > via child. > Great, we have a routing state that's consistent. > Case 2a) If parent decides to cache for Dest, then it stores=20 > Dest via A, B, C.=20 > Parent forwards the DAO to its ancestor as: >=20 > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO:=20 > dest =3D Dest > Stack =3D >=20 > The result is that packets to Dest should come back=20 > without a routing header, with the IP header destination set to Dest > When Parent forwards a packet to Dest, it=20 > changes the destination to A , and inserts a RH B, C, Dest ,=20 > and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified=20 > above), so the packet can be passed to child. >=20 > Case 2b) If parent decides not to cache for Dest, then it=20 > forwards to its own ancestor > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO:=20 > dest =3D Dest > Stack =3D A, B, C >=20 > The result is that packets to Dest should come back=20 > with a routing header A, B, C, and with the IP header=20 > destination set to parent or child, depending on whether=20 > ancestor has a route to child via parent or not. > Parent being the destination of the packet,=20 > to it consumes the next entry in the RH, iow sets A as the=20 > destination, and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified=20 > above), so the packet can be passed to child. >=20 > Note finally for the gory side of it that A, B, and C etc...=20 > are not link local addresses. They have to be global or ULA,=20 > because they can be used multihop. An implementation might=20 > decide to store the connected routes via the link locals, and=20 > the global of the children via the link local of the children. > If that's so "Parent does a route look up for A, and that=20 > does resolves via child" must be understood as lookup for A=20 > and lookup for child both resolve in the same address, that=20 > is child's link local address. >=20 > This looks a bit complex said that way. I hope the slideware=20 > attached helps. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Jonathan Hui > Sent: Wednesday, February 24, 2010 3:42 AM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations >=20 >=20 > Hi John, >=20 > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >=20 > > I was reading through the downwards route section in draft=20 > 6 (section > > 6) and had a few questions in mind. > > > > 1. How is the DAO rank (in Figure 11) computed and what=20 > does this rank >=20 > > value represent? By having this rank value, does it mean that all=20 > > nodes keep a rank for the DODAG (constructed using DIO > > exchanges) separately and also maintain rank values for each=20 > > 'downwards tree' that it participates in (for example if I have two=20 > > nodes that rely on me to receive downwards packets, I would be=20 > > maintaining one DODAG rank and two separate rank values for each of=20 > > the two nodes)? Is this to assure that the downwards=20 > packets will make >=20 > > 'forward' progress? Why can't this be achieved with the DODAG rank=20 > > values? >=20 > One of the main purposes of including ranks towards downwards=20 > destinations in a DAO is so that a node receiving two DAOs=20 > for the same downwards destination can use rank to make a=20 > more intelligent decision if the rank differs (i.e.=20 > preferring the one with lesser rank). >=20 > > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing=20 > > forwarding node will append, on the DAO packet, the address of the=20 > > 'child' to the RRstack. Why should we add the address of=20 > the child and >=20 > > not the node that is forwarding the packet itself? Is there an=20 > > intuition behind this design? If there is a reason for this design,=20 > > how would I retrieve the IP address of the previous hop=20 > (for sure it=20 > > is not included in the IP address fields unless I am the=20 > first hop of=20 > > the node)? >=20 > The IP address of the forwarding node is included in the IP=20 > header - it would be redundant to include the forwarding=20 > node's address in the RRstack as well. >=20 > -- > Jonathan Hui >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Michael.Cowan@us.elster.com Thu Feb 25 05:41:34 2010 Return-Path: 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 2CFDB28C137; Thu, 25 Feb 2010 05:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] 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 gcSV7pQJ1FvR; Thu, 25 Feb 2010 05:41:31 -0800 (PST) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by core3.amsl.com (Postfix) with SMTP id F38ED28C0E6; Thu, 25 Feb 2010 05:41:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Michael.Cowan@us.elster.com X-Msg-Ref: server-10.tower-136.messagelabs.com!1267105388!53771298!8 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 27179 invoked from network); 25 Feb 2010 13:43:40 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-10.tower-136.messagelabs.com with SMTP; 25 Feb 2010 13:43:40 -0000 In-Reply-To: References: X-KeepSent: CC5D94E1:CBE0B2AC-852576D5:004B03DF; type=4; name=$KeepSent To: roll@ietf.org, roll-request@ietf.org X-Mailer: Lotus Notes Release 8.0.2 August 07, 2008 Message-ID: From: Michael.Cowan@us.elster.com Date: Thu, 25 Feb 2010 08:43:26 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 02/25/2010 08:40:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:41:34 -0000 Now that the IPR issues is being worked on and moving forward, when are we going to address the other two key technical issues with ROLL: 1) Point to point routing efficiency 2) Point to Multi-point Thanks, Michael Cowan Elster Solutions, LLC Principle Systems Engineer/ Demand Response Project Manager Email: michael.cowan@us.elster.com Phone: 919-250-5482 Cell: 919-901-9126 Fax: 919-250-5439 208 South Rogers Lane Raleigh, NC 27610 This email (and any attachments) is confidential and privilege information of Elster Solutions, LLC From: roll-request@ietf.org To: roll@ietf.org Date: 02/25/2010 04:51 AM Subject: Roll Digest, Vol 25, Issue 46 Sent by: roll-bounces@ietf.org If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 (Sung Lee) 2. Re: Questions on DAO operations (Pascal Thubert (pthubert)) 3. Re: Our revised IPR declaration on ROLL (Zach Shelby) 4. Re: Questions on DAO operations (Jonathan Hui) 5. Re: Questions on DAO operations (Anders Brandt) ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Feb 2010 21:34:01 -0500 From: Sung Lee Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 To: "Salazar, Ruben" Cc: roll@ietf.org, "Dan Lang \(dlang\)" Message-ID: <4B85E199.6030908@us.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Pascal, I too agree with Ruben that this is a great move in the right direction. Following Dan's recommendation, I will forward this recent decision from Cisco to our legal. Best regards, Sung Salazar, Ruben wrote: > Pascal, et al. > This is definitely a great move in the right direction. > We feel much better with the new IPR statement from Cisco. > Regards > > Ruben Salazar, PhD > Director of Research and Technology > Landys+Gyr EMS > Office: 678 258 3165 > Cellular: 678 438 0063 > ruben.salazar@landysgyr.com > www.landisgyr.com > manage energy better > > > > > Ruben Salazar > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > manage energy better > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, February 23, 2010 12:21 PM > To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel Baccelli > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 > > Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco > IPR debate: > > It is my understanding that this new declaration implements Roger's > suggested compromise regarding Sung and Ruben's concerns, also relayed > by Emmanuel. > > For reference: > Roger suggested: > http://www.ietf.org/mail-archive/web/roll/current/msg03045.html > Sung said: > http://www.ietf.org/mail-archive/web/roll/current/msg03034.html > Emmanuel said: > http://www.ietf.org/mail-archive/web/roll/current/msg03063.html > Ruben said: > http://www.ietf.org/mail-archive/web/roll/current/msg03026.html > > With this new IPR declaration, Cisco retains its defensive right in the > context of RPL implementations *only*. By the new terms Cisco will not > "walk freely anywhere" in someone else's "property". And the answer to > Sung's question about "infringing patents NOT related to RPL" is now a > NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does > the exact same, which seems quite fair to me. For all I know, this is a > major and somewhat exceptional step that should be recognized as such. > And alternate terms based on RAND are still available to anyone who > would prefer that way. > > Sadly, I'll still refrain from detailing which exact pieces RPL I > personally think are covered by this IPR. I think it is pretty clear by > now that this would not have a lot of value since 1) I'm not a lawyer, > and 2) even less your own lawyer. Also the logic of claims somewhat > escapes me, in particular when it comes to coverage. All I know is that > the disclosures I was involved with detail ways to build trees and DAGs, > propagate metrics and paint unicast and multicast routes along the DAGs, > compress and expands routing headers, all things that are somewhat > similar to RPL operations. > > I sincerely hope that this declaration will allow us to reach a positive > consensus on the current poll about Cisco's IPR and move forward with > RPL as soon as possible. Please let us know. > > Pascal > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: Tuesday, February 23, 2010 5:18 PM > To: Pascal Thubert (pthubert); wintert@acm.org; > rpl-authors@external.cisco.com > Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; > jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org > Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-02-23 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1270/). The title of the IPR > disclosure is "Cisco's Statement of IPR relating to > draft-ietf-roll-rpl-06." > > The IETF Secretariat > > > > ------------------------------ Message: 2 Date: Thu, 25 Feb 2010 08:08:43 +0100 From: "Pascal Thubert (pthubert)" Subject: Re: [Roll] Questions on DAO operations To: "Jonathan Hui" , "Philip Levis" Cc: ROLL WG Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="us-ascii" Hi Phil: I globally agree with you. I think we are pretty ripe WRT to the case where source routing is not used. We have mechanisms that loads nodes send up their DAOs when then like, and gather DAOs from their subDAG when they like. What's missing there is more of a matter of recommending when those mechanisms are to be used. When it comes to source route, there are a lot more questions: - should the record route mechanism be part of the DAO as it is today or should it be part of the traffic as Richard suggested. There are pro/cons for both approaches and we really need to discuss that in this list. -(as you say) optimization for the case where only the root store states. Right now, we have an S bit mechanism that is not really spelled out in the spec. This mechanism has assumptions that are not obvious. We need to agree on it. - what routing header will be used? How to compress them? This question is holding 6LoWPAN HC at the moment. I think we should have a number of threads to examine all of these questions. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, February 24, 2010 4:22 AM To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: > >> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >> >> One of the main purposes of including ranks towards downwards >> destinations in a DAO is so that a node receiving two DAOs for the >> same downwards destination can use rank to make a more intelligent >> decision if the rank differs (i.e. preferring the one with lesser >> rank). > > Let's back up -- the purpose is clear but how it achieves that purpose > isn't. How is this value computed/filled in? Should -07 specify this? > Is it correct that DAO Rank is the rank advertised in DIOs? Does that > mean that a node sending DAOs to multiple DAO parents may specify > different DAO Rank values. How does this work for aggregated prefixes? I think it's clear that the DAO mechanism is not nearly as fleshed out as the DIO mechanism. The text is intentionally vague (notice all the 'may' text around it) about what the DAO Rank field can contain - it is simply a place-holder acknowledging the fact that we may want to convey some notion of cost towards the destination. DAO aggregation is something we haven't even discussed yet. But even before that, we need to back up even further and analyze whether the basic DAO mechanism fits our needs. There is concern from the ROLL WG (including myself) on how DAOs are sent or triggered - specifically in cases where a network only caches a subset of the DAO information being sent around. The main challenge is that the WG would like to see a solution that allows both networks where all nodes maintain downward routes and networks where only the root maintains downward routes. Some would even like to see networks that where only some nodes maintain some subset of downward routes. Unfortunately, there's some added complexity in requiring an implementation to support these different modes (e.g. nodes always have to maintain state to know when to trigger DAOs from their children). There's certainly a number of dependencies that are not so obvious at first blush (e.g. a single DAG parent change could cause DAOs to be sent by every node in that sub-DAG). -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 3 Date: Wed, 24 Feb 2010 22:13:19 +0200 From: Zach Shelby Subject: Re: [Roll] Our revised IPR declaration on ROLL To: Dan Lang Cc: roll@ietf.org Message-ID: <973A96A0-6F62-4C45-803C-4A6DB97D11FB@sensinode.com> Content-Type: text/plain; charset=us-ascii Dan, Excellent! I'd like to thank Cisco for the excellent work listening to feedback from all involved and finding a very good compromise! Zach On Feb 23, 2010, at 17:50 , Dan Lang wrote: > > Hi, I wanted to provide a little commentary on the revised licensing commitment language that was just distributed on the mailer. We believe that it will satisfy the concerns as we understand them and allow the WG to move to the next step. Again, the proviso for the commentary is that it is not intended as an interpretation or legal advice and you should seek your own legal counsel. > > Essentially, our new statement, like the old, promises to not assert our essential patents against functionality that implements ROLL, once standardized. The difference is that whereas the old statement suspended, at our option, this commitment in response to any patent assertion against Cisco or Cisco products, the new statement only potentially suspends our commitment as to those who assert their essential patents against Cisco or CIsco products for implementing ROLL. > > Dan Lang > Director, Intellectual Property > Cisco Systems, Inc. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. ------------------------------ Message: 4 Date: Wed, 24 Feb 2010 23:36:09 -0800 From: Jonathan Hui Subject: Re: [Roll] Questions on DAO operations To: Pascal Thubert (pthubert) Cc: ROLL WG Message-ID: <0E2C7A75-1FFD-4E56-9A5F-DAA3BCAFD988@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi Pascal, On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > I globally agree with you. > > I think we are pretty ripe WRT to the case where source routing is not > used. We have mechanisms that loads nodes send up their DAOs when then > like, and gather DAOs from their subDAG when they like. What's missing > there is more of a matter of recommending when those mechanisms are to > be used. I think there are still some concerns on the lack of compactness for the messages - that certainly is the case within the 6lowpan WG. Communicating and storing full IPv6 addresses is fine in the generic case, but there has to be a more efficient way. > When it comes to source route, there are a lot more questions: > > - should the record route mechanism be part of the DAO as it is > today or > should it be part of the traffic as Richard suggested. There are > pro/cons for both approaches and we really need to discuss that in > this > list. > -(as you say) optimization for the case where only the root store > states. Right now, we have an S bit mechanism that is not really > spelled > out in the spec. This mechanism has assumptions that are not > obvious. We > need to agree on it. > - what routing header will be used? How to compress them? This > question > is holding 6LoWPAN HC at the moment. > > I think we should have a number of threads to examine all of these > questions. Yes, I agree these are all issues. I think Richard actually suggested that record-routes are unnecessary if only the root caches downward routing information, though record-routes can be useful in some situations (e.g. on-demand route discovery). A topic that seems to come up every so often is when/where the use of labels show up. That could change our thinking and/or perception. What really worries me is the hidden complexities that result from needing to support both simultaneously. I agree that piece-wise source-routes and being able to operate networks where nodes have widely varying capabilities can take on different responsibilities, but we need to be careful that doing so does not grow beyond our state/ communication complexity goals. Looking forward to talking through these issues in depth. -- Jonathan Hui > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Wednesday, February 24, 2010 4:22 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > >> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: >> >>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >>> >>> One of the main purposes of including ranks towards downwards >>> destinations in a DAO is so that a node receiving two DAOs for the >>> same downwards destination can use rank to make a more intelligent >>> decision if the rank differs (i.e. preferring the one with lesser >>> rank). >> >> Let's back up -- the purpose is clear but how it achieves that >> purpose > >> isn't. How is this value computed/filled in? Should -07 specify this? >> Is it correct that DAO Rank is the rank advertised in DIOs? Does that >> mean that a node sending DAOs to multiple DAO parents may specify >> different DAO Rank values. How does this work for aggregated >> prefixes? > > I think it's clear that the DAO mechanism is not nearly as fleshed out > as the DIO mechanism. The text is intentionally vague (notice all the > 'may' text around it) about what the DAO Rank field can contain - it > is > simply a place-holder acknowledging the fact that we may want to > convey > some notion of cost towards the destination. DAO aggregation is > something we haven't even discussed yet. > > But even before that, we need to back up even further and analyze > whether the basic DAO mechanism fits our needs. There is concern from > the ROLL WG (including myself) on how DAOs are sent or triggered - > specifically in cases where a network only caches a subset of the DAO > information being sent around. The main challenge is that the WG > would > like to see a solution that allows both networks where all nodes > maintain downward routes and networks where only the root maintains > downward routes. Some would even like to see networks that where only > some nodes maintain some subset of downward routes. Unfortunately, > there's some added complexity in requiring an implementation to > support > these different modes (e.g. nodes always have to maintain state to > know > when to trigger DAOs from their children). There's certainly a number > of dependencies that are not so obvious at first blush (e.g. a single > DAG parent change could cause DAOs to be sent by every node in that > sub-DAG). > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 5 Date: Thu, 25 Feb 2010 10:50:56 +0100 From: "Anders Brandt" Subject: Re: [Roll] Questions on DAO operations To: "Pascal Thubert (pthubert)" Cc: ROLL WG Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> Content-Type: text/plain; charset="us-ascii" Hi Pascal Thanks for taking time to explain your thoughts on DAO. Unfortunately, I did not really get the idea of your slide deck! You have Dest sending a RR stack back to C>B>A - but is A then sending this to child which then sends it to Parent? Is the distinction that Parent and Child are stateful routers while A,B,C,Dest can only forward source routed packets? Maybe some different colors or shapes could help clarify this ;-) Finally another small clarification: > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might I agree in this but should RPL do an effort on definition and compression of such source route stacks? My point is that you will need to do the same source routing for actually carrying real traffic along the same route. As far as I understand IPv6 deprecated source routing as it was originally defined, so how would you source route IPv6 packets across a 6lowPan/RPL network? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, February 24, 2010 17:51 > To: Jonathan Hui; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > Hi John and Jonathan. > > I think Question 2 deserves a few more words: > > the short answer > --------------------- > The point is that the record route in the DAO is for the > (sole) use of the recorder, when the RR stack has become a > routing header in a packet on the way back to Destination. > The packet will have to go between the recorder and loose > Source Record Route next_hop in the DAO stack, and the > question is whether the routing info to get there will have > to be picked from the routing header in the packet, or can be > found in the routing table of the recorder. > The IP next-hop to get to the LSRR next-hop is definitively > the source of the DAO, that's what the DAO is all about. So > the question is whether the recorder has a route to the LSRR > next-hop via the source of the packet or not. > If not, then the recorder needs to insert the next-hop > information it will need as the new LSRR next-hop on top of > the LSRR stack. > > The long answer > ------------------- > requires an example, illustrated in the slides attached. > > Let us consider a DAO that is originated from Dest. No one > below Parent decided to cache the specific source route A->B->C->Dest. > > Because nodes do not cache everything, it is acceptable, > though, that DAO routing states are installed all the way > between child and A. The result is that there's no need to > additional source route to reach A from child inside . > > We'll see how that works by forwarding the DAO up one more > time, child to parent, and see what happens whether the > parent has a DAO route to A via Child or not. > > Childs sends this to parent: > IP header: > Source IP = Child > Dest IP = Parent > DAO: > dest = Dest > Stack = A, B, C > > > Case 1: Parent does a route look up for A, and that does > resolves via child. Either parent is missing a routing state, > or its routing state is obsolete. Parent updates the Stack > that is now Child, A, B, C. > Case 1a) If parent decides to cache for Dest, then it stores > Dest via Child, A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest. > When Parent forwards a packet to Dest, it > changes the destination to child, and inserts a RH A, B, C, > Dest. and proceeds forwarding the packet. > Child being connected, the lookup resolved immediately > and the packet is passed to child. > > Case 1b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = child, A, B, C > > The result is that packets to Dest should come back > with a routing header child, A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > If Parent is the destination of the packet, > then it consumes the next entry in the RH, thus setting child > as the destination in the IP header, and proceeds forwarding > the packet. > In any case, child being connected, the lookup is > resolved immediately and the packet is passed to child. > > > Case 2: Parent does a route look up for A, and that resolves > via child. > Great, we have a routing state that's consistent. > Case 2a) If parent decides to cache for Dest, then it stores > Dest via A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest > When Parent forwards a packet to Dest, it > changes the destination to A , and inserts a RH B, C, Dest , > and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Case 2b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = A, B, C > > The result is that packets to Dest should come back > with a routing header A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > Parent being the destination of the packet, > to it consumes the next entry in the RH, iow sets A as the > destination, and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might > decide to store the connected routes via the link locals, and > the global of the children via the link local of the children. > If that's so "Parent does a route look up for A, and that > does resolves via child" must be understood as lookup for A > and lookup for child both resolve in the same address, that > is child's link local address. > > This looks a bit complex said that way. I hope the slideware > attached helps. > > Cheers, > > Pascal > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Wednesday, February 24, 2010 3:42 AM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > Hi John, > > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > > > I was reading through the downwards route section in draft > 6 (section > > 6) and had a few questions in mind. > > > > 1. How is the DAO rank (in Figure 11) computed and what > does this rank > > > value represent? By having this rank value, does it mean that all > > nodes keep a rank for the DODAG (constructed using DIO > > exchanges) separately and also maintain rank values for each > > 'downwards tree' that it participates in (for example if I have two > > nodes that rely on me to receive downwards packets, I would be > > maintaining one DODAG rank and two separate rank values for each of > > the two nodes)? Is this to assure that the downwards > packets will make > > > 'forward' progress? Why can't this be achieved with the DODAG rank > > values? > > One of the main purposes of including ranks towards downwards > destinations in a DAO is so that a node receiving two DAOs > for the same downwards destination can use rank to make a > more intelligent decision if the rank differs (i.e. > preferring the one with lesser rank). > > > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing > > forwarding node will append, on the DAO packet, the address of the > > 'child' to the RRstack. Why should we add the address of > the child and > > > not the node that is forwarding the packet itself? Is there an > > intuition behind this design? If there is a reason for this design, > > how would I retrieve the IP address of the previous hop > (for sure it > > is not included in the IP address fields unless I am the > first hop of > > the node)? > > The IP address of the forwarding node is included in the IP > header - it would be redundant to include the forwarding > node's address in the RRstack as well. > > -- > Jonathan Hui > > _______________________________________________ > 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 End of Roll Digest, Vol 25, Issue 46 ************************************ ______________________________________________________________________ This email has been spam and virus checked by Elster IT Services. From roger.alexander@ekasystems.com Thu Feb 25 06:33:53 2010 Return-Path: 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 DA2AB28C124 for ; Thu, 25 Feb 2010 06:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 N4ebxqNPZ0Sj for ; Thu, 25 Feb 2010 06:33:51 -0800 (PST) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id CF34E28C15E for ; Thu, 25 Feb 2010 06:33:50 -0800 (PST) Received: (qmail 98437 invoked from network); 25 Feb 2010 14:35:59 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp111.biz.mail.re2.yahoo.com with SMTP; 25 Feb 2010 06:35:59 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: xdt4xeYVM1mPKtkphmQOmFxh_OQ_rKSNYLFnvZMagPtYou8BLi_KLSjTUe3uKTM_LtybT7zxsg.EfoBLdtnit2Z9xIGeVZeqiF4rdIMx3Hgq2OEjzMjWspdN09Y7Q4TPcYMe1sszxdCLwuhVFCyXCAsnmGnuzcZE5cnx8qBEH4M4wUF2t_WoWtMNrqwmWsdi.IsykdHl6HDB4NHRAwdiDWuuJd_ObIp.Gnntj3JOXAgEPLcUy6JPUCl0ERAT5eJdFi3kwMqOSMIrID.XBThDrbghhass8IGqtki4MZDBonvkNECTuQK93jqavejmlgKb4n2s1gD_laB.Q9JCNp6THWE.GGgEAlDrP8ZLKNLWbqvNQ4Ji4Xr8zGNeq7l4O2SvZt9xrz8S37UzEsSAFZ5TiKk5Rlc5pVd.k7bqXg-- X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Pascal Thubert \(pthubert\)'" , , , "'Sung Lee'" , "'Emmanuel Baccelli'" References: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151B67D@XMB-AMS-107.cisco.com> Date: Thu, 25 Feb 2010 09:35:36 -0500 Message-ID: <005a01cab627$cb9f6080$62de2180$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq0pCC+rD//0mgaRVGU9sCitaAlqAAAiO/AAGAuzVA= Content-Language: en-us Cc: roll@ietf.org, "'Dan Lang \(dlang\)'" Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 14:33:53 -0000 Thanks Pascal and Dan for the great flexibility and accommodation shown on the part of Cisco and the willingness of its individuals to engage with the work group in an open and forthright way to continue to support the on-going standards development work. Thank you. Roger -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Tuesday, February 23, 2010 12:21 PM To: Roger Alexander; d.sturek@att.net; Ruben.Salazar@landisgyr.com; Sung Lee; Emmanuel Baccelli Cc: roll@ietf.org; Dan Lang (dlang) Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco IPR debate: It is my understanding that this new declaration implements Roger's suggested compromise regarding Sung and Ruben's concerns, also relayed by Emmanuel. For reference: Roger suggested: http://www.ietf.org/mail-archive/web/roll/current/msg03045.html Sung said: http://www.ietf.org/mail-archive/web/roll/current/msg03034.html Emmanuel said: http://www.ietf.org/mail-archive/web/roll/current/msg03063.html Ruben said: http://www.ietf.org/mail-archive/web/roll/current/msg03026.html With this new IPR declaration, Cisco retains its defensive right in the context of RPL implementations *only*. By the new terms Cisco will not "walk freely anywhere" in someone else's "property". And the answer to Sung's question about "infringing patents NOT related to RPL" is now a NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does the exact same, which seems quite fair to me. For all I know, this is a major and somewhat exceptional step that should be recognized as such. And alternate terms based on RAND are still available to anyone who would prefer that way. Sadly, I'll still refrain from detailing which exact pieces RPL I personally think are covered by this IPR. I think it is pretty clear by now that this would not have a lot of value since 1) I'm not a lawyer, and 2) even less your own lawyer. Also the logic of claims somewhat escapes me, in particular when it comes to coverage. All I know is that the disclosures I was involved with detail ways to build trees and DAGs, propagate metrics and paint unicast and multicast routes along the DAGs, compress and expands routing headers, all things that are somewhat similar to RPL operations. I sincerely hope that this declaration will allow us to reach a positive consensus on the current poll about Cisco's IPR and move forward with RPL as soon as possible. Please let us know. Pascal -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org] Sent: Tuesday, February 23, 2010 5:18 PM To: Pascal Thubert (pthubert); wintert@acm.org; rpl-authors@external.cisco.com Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1270/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06." The IETF Secretariat From anders.jagd@gmail.com Thu Feb 25 08:08:45 2010 Return-Path: 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 4C84828C1BB for ; Thu, 25 Feb 2010 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] 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 bKUiKt05x5nh for ; Thu, 25 Feb 2010 08:08:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1EAFD3A851B for ; Thu, 25 Feb 2010 08:08:44 -0800 (PST) Received: by pwi3 with SMTP id 3so6003889pwi.31 for ; Thu, 25 Feb 2010 08:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=jI5oed4FAratzNmqvc+LQVCmvsu7ViY3R1+MdqRIAtA=; b=PdYuFX3iCQKwxGAktZ23i96G6CmFHjS2wEwYkiAaJAiWQJkzemh+Kv7lcVptc6koLj Px194lZTFmoZ79P0DBSWZpsFM1BGucn98Z6rGuG9l0nbsQgOwKk/obwN+YwJY1BYaUFx K/GXFTOL47VFZCHtr/VRVtXh+q9gB2QYp2GT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eewSmSgYBpLxVX3f166nfEFKvCUXp8dKMNMi9gPczxoyL9bNJZfjrFzZgLRckCUozr hwx6Xx28QXSxw9B7LaiAuzAQGQBVDq5L2hX8nrK0lyzReRDkpMfFstqJ88kv80XJHDW2 xO9hzR3CRkDB26AkSKkdcbElNov5tvi4KqsZY= MIME-Version: 1.0 Received: by 10.142.247.2 with SMTP id u2mr677321wfh.198.1267114252522; Thu, 25 Feb 2010 08:10:52 -0800 (PST) Date: Thu, 25 Feb 2010 11:10:52 -0500 Message-ID: <77b524e41002250810n1b5242c2q264e855c9f9f5fc9@mail.gmail.com> From: Anders Jagd To: roll@ietf.org Content-Type: multipart/alternative; boundary=00504502c5d2e9567604806f06c4 Subject: [Roll] RPL Draft 06 - Misc comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:08:45 -0000 --00504502c5d2e9567604806f06c4 Content-Type: text/plain; charset=ISO-8859-1 I believe draft 06 in general strikes a good balance of requirements belonging to a base document. I hope and assume this now will be complemented by additional applicability documents. I would like to offer a few comments regarding draft 06. I apologize if some of my comments have already been discussed; I admit that I am not 100% up to speed with the mailing list. 1) The fundamental DAO mechanism appears to be quite solid; I am happy to see the introduction of the DTSN field in the DIO base. As for actual encoding of destinations, I was wondering if there have been any thoughts on compression of the (potentially large) amounts of (similar) data that may be propagated ? Several ways to approach this, mostly variations of "dictionary" schemes. 2) Page 26, first paragraph discusses padding. I suggest discouraging padding, since in my experience network bandwidth is often a more constrained resource than cpu cycles. This may of course depend on the application. 3) Page 27, section 5.1.3.5 describes the "DAG Destination Prefix" and how the "DODAG Root, or another node located upwards...needs to indicate that it offers connectivity". I understand the DODAG Root doing so, but am not sure how this would work for non Root nodes, since there wouldn't be any guarantee that downstream nodes would actually be able to target messages upstream for non Root nodes. 4) Page 37, section 5.3.5: Upon receiving a unicast DIS message, a node must respond, but should not reset the trickle timer. Does this mean the node must respond asap or should it wait until current trickle timer times out ? 5) Page 41, section 6.1 regarding DAO objects: Does DAO sequence need 16 bits ? Seems a bit excessive to me, but I may be missing something. 6) Page 46, section 6.2.4.1.1.2, bullet 1: I am a bit confused about the words "REACHABLE entry times out" ? Don't you mean "Retry counter reaches a maximum threshold" (as described in 6.2.4.1.1.2.2) ? A few minor editorial comments: Page 10, last bullet: Forward reference to DIO messages Page 13, section 3.4: "DODAG Information Object" should be "DAG Information Object" (see 3.4.1) Page 19, section 3.6.1.3: "...cleaned up the state" may need a little clarification Page 22, section 4: "This document defines three types", suggest "codes" instead of "types" Page 23, figure 4 (and text): Is Rank 16 bit or 8 bit ? Page 24, first paragraph: "other DODAG roots within the DODAG" (within the "DAG") Page 25, 5.1.2 bullet 3: A node "MAY" update Rank; don't you mean "MUST" ? Page 35, section 5.3.3.5, bullet 3: "if its revised rank would exceed..." should be "if its change in rank would exceed..." Page 39, section 5.4 "...when a node does not understand...", may consider replacing "understand" with "parse" or something similar. Page 48, section 6.2.5 "...from a child by a node who...", suggest replacing the word "who". Page 49, section 6.2.7 "Note: the DIO is modified", suggest to strike the word "modified". Page 52, section 7.2: Suggest to change the word "meltdown". Page 54, section 7.2.2.2, third paragraph: "RPLInstanceID" is not a "flag". /Anders Jagd --00504502c5d2e9567604806f06c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe draft 06 in general strikes a good balance of requirements b= elonging=A0to a base document. I hope and assume this now will be complemen= ted by=A0additional applicability documents.

I wou= ld like to offer a few comments regarding draft 06. I apologize if some of = my comments=A0have already been discussed; I admit that I am not 100% up to= speed with the mailing list.

1) The fundamental DAO mechanism appears to be quite so= lid; I am happy to see the introduction of=A0the DTSN field in the DIO base= . As for actual encoding of destinations, I was wondering if=A0there have b= een any thoughts on compression of the (potentially large) amounts of (simi= lar) data=A0that may be propagated ? Several ways to approach this, mostly = variations of "dictionary" schemes.

2) Page 26, first paragraph discusses padding. I sugges= t discouraging padding,=A0since in my experience network bandwidth is often= a more constrained resource than cpu cycles. This may=A0of course depend o= n the application.

3) Page 27, section 5.1.3.5 describes the "DAG Des= tination Prefix" and how the=A0"DODAG Root, or another node locat= ed upwards...needs to indicate that it offers connectivity".=A0I under= stand the DODAG Root doing so, but am not sure how this would work for non = Root nodes, since=A0there wouldn't be any guarantee that downstream nod= es would actually be able to target messages=A0upstream for non Root nodes.=

4) Page 37, section 5.3.5: Upon receiving a unicast DIS= message, a node must respond, but should=A0not reset the trickle timer. Do= es this mean the node must respond asap or should it wait until=A0current t= rickle timer times out ?

5) Page 41, section 6.1 regarding DAO objects: Does DAO= sequence need 16 bits ? Seems a bit=A0excessive to me, but I may be missin= g something.

6) Page 46, section 6.2.4.1.1.2, bull= et 1: I am a bit confused about the words=A0"REACHABLE entry times out= " ? Don't you mean "Retry counter reaches a maximum threshold= " (as described in=A06.2.4.1.1.2.2) ?

A few minor editorial comments:

Page 10, last bullet: Forward reference to DIO messages
Page 13= , section 3.4: "DODAG Information Object" should be "DAG Inf= ormation Object" (see 3.4.1)
Page 19, section 3.6.1.3: "...clea= ned up the state" may need a little clarification
Page 22, s= ection 4: "This document defines three types", suggest "code= s" instead of "types"
Page 23, figure 4 (and text): Is Rank 16 bit or 8 bit ?
Page= 24, first paragraph: "other DODAG roots within the DODAG" (withi= n the "DAG")
Page 25, 5.1.2 bullet 3: A node "MAY&= quot; update Rank; don't you mean "MUST" ?
Page 35, section 5.3.3.5, bullet 3: "if its revised rank would ex= ceed..." should be "if its=A0change in rank would exceed..."=
Page 39, section 5.4 "...when a node does not understand...= ", may consider replacing "understand" with=A0"parse&qu= ot; or something similar.
Page 48, section 6.2.5 "...from a child by a node who...", s= uggest replacing the word "who".
Page 49, section 6.2.7= "Note: the DIO is modified", suggest to strike the word "mo= dified".
Page 52, section 7.2: Suggest to change the word "meltdown".=
Page 54, section 7.2.2.2, third paragraph: "RPLInstanceID&q= uot; is not a "flag".

/Anders Jagd
--00504502c5d2e9567604806f06c4-- From pthubert@cisco.com Thu Feb 25 08:12:30 2010 Return-Path: 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 94A3228C1CF for ; Thu, 25 Feb 2010 08:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=-3.758, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6] 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 AyhCfd-cvxa1 for ; Thu, 25 Feb 2010 08:12:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0D3623A82FA for ; Thu, 25 Feb 2010 08:12:22 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAFswhkuQ/uCWe2dsb2JhbACbFxUBARYkBhykHIpwCY1jAoJSARSCDASOaA X-IronPort-AV: E=Sophos;i="4.49,540,1262563200"; d="scan'208";a="3783422" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 25 Feb 2010 15:42:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1PGEWiX004703; Thu, 25 Feb 2010 16:14:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 17:14:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 17:14:31 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Roll Digest, Vol 25, Issue 46 Thread-Index: Acq2IJG8tDgvffdiR5CxuifeLstcngAEwRgg References: From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 25 Feb 2010 16:14:32.0540 (UTC) FILETIME=[9D7FC9C0:01CAB635] Cc: roll@ietf.org Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:12:30 -0000 Hi Michael: Maybe it is unclear but Point to multipoint is already addressed. In short, the tree of preferred DAO parents is used as an internal mcast tree. Listeners registrations are propagated as DAOs. Upon a DAO with a mcast destination, the router installs a route in the mrib and forwards the DAO up. Upon a packet to a mcast destination, the router forwards to packet to its parent and all entries in the mrib, except the node that passed the packet in the first place. It is up to the root to advertise all the listeners to the external infrastructure by proxying the DAO for multicast groups into MLD. The long answer is here: http://tools.ietf.org/html/draft-ietf-roll-rpl-06#section-8 . Obviously help for improvements is welcome. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael.Cowan@us.elster.com Sent: Thursday, February 25, 2010 2:43 PM To: roll@ietf.org; roll-request@ietf.org Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 Now that the IPR issues is being worked on and moving forward, when are we going to address the other two key technical issues with ROLL: 1) Point to point routing efficiency 2) Point to Multi-point Thanks, Michael Cowan Elster Solutions, LLC Principle Systems Engineer/ Demand Response Project Manager Email: michael.cowan@us.elster.com Phone: 919-250-5482 Cell: 919-901-9126 Fax: 919-250-5439 208 South Rogers Lane Raleigh, NC 27610 This email (and any attachments) is confidential and privilege information of Elster Solutions, LLC =20 From: roll-request@ietf.org =20 To: roll@ietf.org =20 Date: 02/25/2010 04:51 AM =20 Subject: Roll Digest, Vol 25, Issue 46 =20 Sent by: roll-bounces@ietf.org =20 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 (Sung Lee) 2. Re: Questions on DAO operations (Pascal Thubert (pthubert)) 3. Re: Our revised IPR declaration on ROLL (Zach Shelby) 4. Re: Questions on DAO operations (Jonathan Hui) 5. Re: Questions on DAO operations (Anders Brandt) ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Feb 2010 21:34:01 -0500 From: Sung Lee Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 To: "Salazar, Ruben" Cc: roll@ietf.org, "Dan Lang \(dlang\)" Message-ID: <4B85E199.6030908@us.fujitsu.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Pascal, I too agree with Ruben that this is a great move in the right direction. Following Dan's recommendation, I will forward this recent decision from Cisco to our legal. Best regards, Sung Salazar, Ruben wrote: > Pascal, et al. > This is definitely a great move in the right direction. > We feel much better with the new IPR statement from Cisco. > Regards > > Ruben Salazar, PhD > Director of Research and Technology > Landys+Gyr EMS > Office: 678 258 3165 > Cellular: 678 438 0063 > ruben.salazar@landysgyr.com > www.landisgyr.com > manage energy better > > > > > Ruben Salazar > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > manage energy better > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, February 23, 2010 12:21 PM > To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel Baccelli > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 > > Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco > IPR debate: > > It is my understanding that this new declaration implements Roger's > suggested compromise regarding Sung and Ruben's concerns, also relayed > by Emmanuel. > > For reference: > Roger suggested: > http://www.ietf.org/mail-archive/web/roll/current/msg03045.html > Sung said: > http://www.ietf.org/mail-archive/web/roll/current/msg03034.html > Emmanuel said: > http://www.ietf.org/mail-archive/web/roll/current/msg03063.html > Ruben said: > http://www.ietf.org/mail-archive/web/roll/current/msg03026.html > > With this new IPR declaration, Cisco retains its defensive right in the > context of RPL implementations *only*. By the new terms Cisco will not > "walk freely anywhere" in someone else's "property". And the answer to > Sung's question about "infringing patents NOT related to RPL" is now a > NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does > the exact same, which seems quite fair to me. For all I know, this is a > major and somewhat exceptional step that should be recognized as such. > And alternate terms based on RAND are still available to anyone who > would prefer that way. > > Sadly, I'll still refrain from detailing which exact pieces RPL I > personally think are covered by this IPR. I think it is pretty clear by > now that this would not have a lot of value since 1) I'm not a lawyer, > and 2) even less your own lawyer. Also the logic of claims somewhat > escapes me, in particular when it comes to coverage. All I know is that > the disclosures I was involved with detail ways to build trees and DAGs, > propagate metrics and paint unicast and multicast routes along the DAGs, > compress and expands routing headers, all things that are somewhat > similar to RPL operations. > > I sincerely hope that this declaration will allow us to reach a positive > consensus on the current poll about Cisco's IPR and move forward with > RPL as soon as possible. Please let us know. > > Pascal > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: Tuesday, February 23, 2010 5:18 PM > To: Pascal Thubert (pthubert); wintert@acm.org; > rpl-authors@external.cisco.com > Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; > jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org > Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-02-23 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1270/). The title of the IPR > disclosure is "Cisco's Statement of IPR relating to > draft-ietf-roll-rpl-06." > > The IETF Secretariat > > > > ------------------------------ Message: 2 Date: Thu, 25 Feb 2010 08:08:43 +0100 From: "Pascal Thubert (pthubert)" Subject: Re: [Roll] Questions on DAO operations To: "Jonathan Hui" , "Philip Levis" Cc: ROLL WG Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" Hi Phil: I globally agree with you. I think we are pretty ripe WRT to the case where source routing is not used. We have mechanisms that loads nodes send up their DAOs when then like, and gather DAOs from their subDAG when they like. What's missing there is more of a matter of recommending when those mechanisms are to be used. When it comes to source route, there are a lot more questions: - should the record route mechanism be part of the DAO as it is today or should it be part of the traffic as Richard suggested. There are pro/cons for both approaches and we really need to discuss that in this list. -(as you say) optimization for the case where only the root store states. Right now, we have an S bit mechanism that is not really spelled out in the spec. This mechanism has assumptions that are not obvious. We need to agree on it. - what routing header will be used? How to compress them? This question is holding 6LoWPAN HC at the moment. I think we should have a number of threads to examine all of these questions. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, February 24, 2010 4:22 AM To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: > >> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >> >> One of the main purposes of including ranks towards downwards >> destinations in a DAO is so that a node receiving two DAOs for the >> same downwards destination can use rank to make a more intelligent >> decision if the rank differs (i.e. preferring the one with lesser >> rank). > > Let's back up -- the purpose is clear but how it achieves that purpose > isn't. How is this value computed/filled in? Should -07 specify this? > Is it correct that DAO Rank is the rank advertised in DIOs? Does that > mean that a node sending DAOs to multiple DAO parents may specify > different DAO Rank values. How does this work for aggregated prefixes? I think it's clear that the DAO mechanism is not nearly as fleshed out as the DIO mechanism. The text is intentionally vague (notice all the 'may' text around it) about what the DAO Rank field can contain - it is simply a place-holder acknowledging the fact that we may want to convey some notion of cost towards the destination. DAO aggregation is something we haven't even discussed yet. But even before that, we need to back up even further and analyze whether the basic DAO mechanism fits our needs. There is concern from the ROLL WG (including myself) on how DAOs are sent or triggered - specifically in cases where a network only caches a subset of the DAO information being sent around. The main challenge is that the WG would like to see a solution that allows both networks where all nodes maintain downward routes and networks where only the root maintains downward routes. Some would even like to see networks that where only some nodes maintain some subset of downward routes. Unfortunately, there's some added complexity in requiring an implementation to support these different modes (e.g. nodes always have to maintain state to know when to trigger DAOs from their children). There's certainly a number of dependencies that are not so obvious at first blush (e.g. a single DAG parent change could cause DAOs to be sent by every node in that sub-DAG). -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 3 Date: Wed, 24 Feb 2010 22:13:19 +0200 From: Zach Shelby Subject: Re: [Roll] Our revised IPR declaration on ROLL To: Dan Lang Cc: roll@ietf.org Message-ID: <973A96A0-6F62-4C45-803C-4A6DB97D11FB@sensinode.com> Content-Type: text/plain; charset=3Dus-ascii Dan, Excellent! I'd like to thank Cisco for the excellent work listening to feedback from all involved and finding a very good compromise! Zach On Feb 23, 2010, at 17:50 , Dan Lang wrote: > > Hi, I wanted to provide a little commentary on the revised licensing commitment language that was just distributed on the mailer. We believe that it will satisfy the concerns as we understand them and allow the WG to move to the next step. Again, the proviso for the commentary is that it is not intended as an interpretation or legal advice and you should seek your own legal counsel. > > Essentially, our new statement, like the old, promises to not assert our essential patents against functionality that implements ROLL, once standardized. The difference is that whereas the old statement suspended, at our option, this commitment in response to any patent assertion against Cisco or Cisco products, the new statement only potentially suspends our commitment as to those who assert their essential patents against Cisco or CIsco products for implementing ROLL. > > Dan Lang > Director, Intellectual Property > Cisco Systems, Inc. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. ------------------------------ Message: 4 Date: Wed, 24 Feb 2010 23:36:09 -0800 From: Jonathan Hui Subject: Re: [Roll] Questions on DAO operations To: Pascal Thubert (pthubert) Cc: ROLL WG Message-ID: <0E2C7A75-1FFD-4E56-9A5F-DAA3BCAFD988@archrock.com> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; = delsp=3Dyes Hi Pascal, On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > I globally agree with you. > > I think we are pretty ripe WRT to the case where source routing is not > used. We have mechanisms that loads nodes send up their DAOs when then > like, and gather DAOs from their subDAG when they like. What's missing > there is more of a matter of recommending when those mechanisms are to > be used. I think there are still some concerns on the lack of compactness for the messages - that certainly is the case within the 6lowpan WG. Communicating and storing full IPv6 addresses is fine in the generic case, but there has to be a more efficient way. > When it comes to source route, there are a lot more questions: > > - should the record route mechanism be part of the DAO as it is > today or > should it be part of the traffic as Richard suggested. There are > pro/cons for both approaches and we really need to discuss that in > this > list. > -(as you say) optimization for the case where only the root store > states. Right now, we have an S bit mechanism that is not really > spelled > out in the spec. This mechanism has assumptions that are not > obvious. We > need to agree on it. > - what routing header will be used? How to compress them? This > question > is holding 6LoWPAN HC at the moment. > > I think we should have a number of threads to examine all of these > questions. Yes, I agree these are all issues. I think Richard actually suggested that record-routes are unnecessary if only the root caches downward routing information, though record-routes can be useful in some situations (e.g. on-demand route discovery). A topic that seems to come up every so often is when/where the use of labels show up. That could change our thinking and/or perception. What really worries me is the hidden complexities that result from needing to support both simultaneously. I agree that piece-wise source-routes and being able to operate networks where nodes have widely varying capabilities can take on different responsibilities, but we need to be careful that doing so does not grow beyond our state/ communication complexity goals. Looking forward to talking through these issues in depth. -- Jonathan Hui > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Wednesday, February 24, 2010 4:22 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > >> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: >> >>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >>> >>> One of the main purposes of including ranks towards downwards >>> destinations in a DAO is so that a node receiving two DAOs for the >>> same downwards destination can use rank to make a more intelligent >>> decision if the rank differs (i.e. preferring the one with lesser >>> rank). >> >> Let's back up -- the purpose is clear but how it achieves that >> purpose > >> isn't. How is this value computed/filled in? Should -07 specify this? >> Is it correct that DAO Rank is the rank advertised in DIOs? Does that >> mean that a node sending DAOs to multiple DAO parents may specify >> different DAO Rank values. How does this work for aggregated >> prefixes? > > I think it's clear that the DAO mechanism is not nearly as fleshed out > as the DIO mechanism. The text is intentionally vague (notice all the > 'may' text around it) about what the DAO Rank field can contain - it > is > simply a place-holder acknowledging the fact that we may want to > convey > some notion of cost towards the destination. DAO aggregation is > something we haven't even discussed yet. > > But even before that, we need to back up even further and analyze > whether the basic DAO mechanism fits our needs. There is concern from > the ROLL WG (including myself) on how DAOs are sent or triggered - > specifically in cases where a network only caches a subset of the DAO > information being sent around. The main challenge is that the WG > would > like to see a solution that allows both networks where all nodes > maintain downward routes and networks where only the root maintains > downward routes. Some would even like to see networks that where only > some nodes maintain some subset of downward routes. Unfortunately, > there's some added complexity in requiring an implementation to > support > these different modes (e.g. nodes always have to maintain state to > know > when to trigger DAOs from their children). There's certainly a number > of dependencies that are not so obvious at first blush (e.g. a single > DAG parent change could cause DAOs to be sent by every node in that > sub-DAG). > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 5 Date: Thu, 25 Feb 2010 10:50:56 +0100 From: "Anders Brandt" Subject: Re: [Roll] Questions on DAO operations To: "Pascal Thubert (pthubert)" Cc: ROLL WG Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> Content-Type: text/plain; charset=3D"us-ascii" Hi Pascal Thanks for taking time to explain your thoughts on DAO. Unfortunately, I did not really get the idea of your slide deck! You have Dest sending a RR stack back to C>B>A - but is A then sending this to child which then sends it to Parent? Is the distinction that Parent and Child are stateful routers while A,B,C,Dest can only forward source routed packets? Maybe some different colors or shapes could help clarify this ;-) Finally another small clarification: > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might I agree in this but should RPL do an effort on definition and compression of such source route stacks? My point is that you will need to do the same source routing for actually carrying real traffic along the same route. As far as I understand IPv6 deprecated source routing as it was originally defined, so how would you source route IPv6 packets across a 6lowPan/RPL network? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, February 24, 2010 17:51 > To: Jonathan Hui; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > Hi John and Jonathan. > > I think Question 2 deserves a few more words: > > the short answer > --------------------- > The point is that the record route in the DAO is for the > (sole) use of the recorder, when the RR stack has become a > routing header in a packet on the way back to Destination. > The packet will have to go between the recorder and loose > Source Record Route next_hop in the DAO stack, and the > question is whether the routing info to get there will have > to be picked from the routing header in the packet, or can be > found in the routing table of the recorder. > The IP next-hop to get to the LSRR next-hop is definitively > the source of the DAO, that's what the DAO is all about. So > the question is whether the recorder has a route to the LSRR > next-hop via the source of the packet or not. > If not, then the recorder needs to insert the next-hop > information it will need as the new LSRR next-hop on top of > the LSRR stack. > > The long answer > ------------------- > requires an example, illustrated in the slides attached. > > Let us consider a DAO that is originated from Dest. No one > below Parent decided to cache the specific source route A->B->C->Dest. > > Because nodes do not cache everything, it is acceptable, > though, that DAO routing states are installed all the way > between child and A. The result is that there's no need to > additional source route to reach A from child inside . > > We'll see how that works by forwarding the DAO up one more > time, child to parent, and see what happens whether the > parent has a DAO route to A via Child or not. > > Childs sends this to parent: > IP header: > Source IP =3D Child > Dest IP =3D Parent > DAO: > dest =3D Dest > Stack =3D A, B, C > > > Case 1: Parent does a route look up for A, and that does > resolves via child. Either parent is missing a routing state, > or its routing state is obsolete. Parent updates the Stack > that is now Child, A, B, C. > Case 1a) If parent decides to cache for Dest, then it stores > Dest via Child, A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO: > dest =3D Dest > Stack =3D > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest. > When Parent forwards a packet to Dest, it > changes the destination to child, and inserts a RH A, B, C, > Dest. and proceeds forwarding the packet. > Child being connected, the lookup resolved immediately > and the packet is passed to child. > > Case 1b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO: > dest =3D Dest > Stack =3D child, A, B, C > > The result is that packets to Dest should come back > with a routing header child, A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > If Parent is the destination of the packet, > then it consumes the next entry in the RH, thus setting child > as the destination in the IP header, and proceeds forwarding > the packet. > In any case, child being connected, the lookup is > resolved immediately and the packet is passed to child. > > > Case 2: Parent does a route look up for A, and that resolves > via child. > Great, we have a routing state that's consistent. > Case 2a) If parent decides to cache for Dest, then it stores > Dest via A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO: > dest =3D Dest > Stack =3D > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest > When Parent forwards a packet to Dest, it > changes the destination to A , and inserts a RH B, C, Dest , > and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Case 2b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP =3D parent > Dest IP =3D Ancestor > DAO: > dest =3D Dest > Stack =3D A, B, C > > The result is that packets to Dest should come back > with a routing header A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > Parent being the destination of the packet, > to it consumes the next entry in the RH, iow sets A as the > destination, and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might > decide to store the connected routes via the link locals, and > the global of the children via the link local of the children. > If that's so "Parent does a route look up for A, and that > does resolves via child" must be understood as lookup for A > and lookup for child both resolve in the same address, that > is child's link local address. > > This looks a bit complex said that way. I hope the slideware > attached helps. > > Cheers, > > Pascal > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Wednesday, February 24, 2010 3:42 AM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > Hi John, > > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > > > I was reading through the downwards route section in draft > 6 (section > > 6) and had a few questions in mind. > > > > 1. How is the DAO rank (in Figure 11) computed and what > does this rank > > > value represent? By having this rank value, does it mean that all > > nodes keep a rank for the DODAG (constructed using DIO > > exchanges) separately and also maintain rank values for each > > 'downwards tree' that it participates in (for example if I have two > > nodes that rely on me to receive downwards packets, I would be > > maintaining one DODAG rank and two separate rank values for each of > > the two nodes)? Is this to assure that the downwards > packets will make > > > 'forward' progress? Why can't this be achieved with the DODAG rank > > values? > > One of the main purposes of including ranks towards downwards > destinations in a DAO is so that a node receiving two DAOs > for the same downwards destination can use rank to make a > more intelligent decision if the rank differs (i.e. > preferring the one with lesser rank). > > > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing > > forwarding node will append, on the DAO packet, the address of the > > 'child' to the RRstack. Why should we add the address of > the child and > > > not the node that is forwarding the packet itself? Is there an > > intuition behind this design? If there is a reason for this design, > > how would I retrieve the IP address of the previous hop > (for sure it > > is not included in the IP address fields unless I am the > first hop of > > the node)? > > The IP address of the forwarding node is included in the IP > header - it would be redundant to include the forwarding > node's address in the RRstack as well. > > -- > Jonathan Hui > > _______________________________________________ > 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 End of Roll Digest, Vol 25, Issue 46 ************************************ ______________________________________________________________________ This email has been spam and virus checked by Elster IT Services. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Feb 25 10:11:44 2010 Return-Path: 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 A16943A8707 for ; Thu, 25 Feb 2010 10:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 EoTFjxLDdFMB for ; Thu, 25 Feb 2010 10:11:41 -0800 (PST) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id D29F228C205 for ; Thu, 25 Feb 2010 10:11:37 -0800 (PST) Received: (qmail 91339 invoked from network); 25 Feb 2010 18:13:46 -0000 Received: from adsl-69-224-191-219.dsl.sndg02.pacbell.net (d.sturek@69.224.191.219 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 25 Feb 2010 10:13:46 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: QXO5IP8VM1k_DN1tWwxe7N9h7kSck01ezapk_0HVyHLH78wHN5NWAxzfIGbZrsGqIk7AUD4SbP.LJiPBOLOK6KMxFoNHMQQyZf0nRzsCoXFlfnRpy_iXx0UEjcw.FhW7aG2Y4zbioG8_2uxXf748ZH82kv4eI_PRnk0uuZ.HSO2megWb7KWftFhxbc84PD1V526.Je8p7TDawl8PwQhtKFUvptym69lARRtwAW3QtM7MhYK8m.IYbOwhGtIBlxcBQlpmfGnF58csmmPsAJ4VEYbJef8FwXnDsqbl1p.3l0RYLP2NyA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , References: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com> Date: Thu, 25 Feb 2010 10:13:40 -0800 Message-ID: <054001cab646$432d5210$c987f630$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq2IJG8tDgvffdiR5CxuifeLstcngAEwRggAASS1BA= Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 18:11:45 -0000 Hi Pascal, One additional question: If I am routing from outside the DAG to a device in the DAG at a rank that is not the DAG root, is source routing required? I had thought with the right selection of RA/RS and storage within the devices in the DAG it was possible to support this scenario without source routing. Could you or someone in the DT answer this? The issue is if source routing is required, we need to carefully review the header sizes to see if this will actually work for our application. Thanks, Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Thursday, February 25, 2010 8:15 AM To: Michael.Cowan@us.elster.com Cc: roll@ietf.org Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 Hi Michael: Maybe it is unclear but Point to multipoint is already addressed. In short, the tree of preferred DAO parents is used as an internal mcast tree. Listeners registrations are propagated as DAOs. Upon a DAO with a mcast destination, the router installs a route in the mrib and forwards the DAO up. Upon a packet to a mcast destination, the router forwards to packet to its parent and all entries in the mrib, except the node that passed the packet in the first place. It is up to the root to advertise all the listeners to the external infrastructure by proxying the DAO for multicast groups into MLD. The long answer is here: http://tools.ietf.org/html/draft-ietf-roll-rpl-06#section-8 . Obviously help for improvements is welcome. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael.Cowan@us.elster.com Sent: Thursday, February 25, 2010 2:43 PM To: roll@ietf.org; roll-request@ietf.org Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 Now that the IPR issues is being worked on and moving forward, when are we going to address the other two key technical issues with ROLL: 1) Point to point routing efficiency 2) Point to Multi-point Thanks, Michael Cowan Elster Solutions, LLC Principle Systems Engineer/ Demand Response Project Manager Email: michael.cowan@us.elster.com Phone: 919-250-5482 Cell: 919-901-9126 Fax: 919-250-5439 208 South Rogers Lane Raleigh, NC 27610 This email (and any attachments) is confidential and privilege information of Elster Solutions, LLC From: roll-request@ietf.org To: roll@ietf.org Date: 02/25/2010 04:51 AM Subject: Roll Digest, Vol 25, Issue 46 Sent by: roll-bounces@ietf.org If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 (Sung Lee) 2. Re: Questions on DAO operations (Pascal Thubert (pthubert)) 3. Re: Our revised IPR declaration on ROLL (Zach Shelby) 4. Re: Questions on DAO operations (Jonathan Hui) 5. Re: Questions on DAO operations (Anders Brandt) ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Feb 2010 21:34:01 -0500 From: Sung Lee Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 To: "Salazar, Ruben" Cc: roll@ietf.org, "Dan Lang \(dlang\)" Message-ID: <4B85E199.6030908@us.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Pascal, I too agree with Ruben that this is a great move in the right direction. Following Dan's recommendation, I will forward this recent decision from Cisco to our legal. Best regards, Sung Salazar, Ruben wrote: > Pascal, et al. > This is definitely a great move in the right direction. > We feel much better with the new IPR statement from Cisco. > Regards > > Ruben Salazar, PhD > Director of Research and Technology > Landys+Gyr EMS > Office: 678 258 3165 > Cellular: 678 438 0063 > ruben.salazar@landysgyr.com > www.landisgyr.com > manage energy better > > > > > Ruben Salazar > Director of Technology > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 3165 > Fax: +1 678 258 1550 > Ruben.Salazar@landisgyr.com > www.landisgyr.com > manage energy better > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, February 23, 2010 12:21 PM > To: Roger Alexander; d.sturek@att.net; Salazar, Ruben; Sung Lee; Emmanuel Baccelli > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06 > > Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco > IPR debate: > > It is my understanding that this new declaration implements Roger's > suggested compromise regarding Sung and Ruben's concerns, also relayed > by Emmanuel. > > For reference: > Roger suggested: > http://www.ietf.org/mail-archive/web/roll/current/msg03045.html > Sung said: > http://www.ietf.org/mail-archive/web/roll/current/msg03034.html > Emmanuel said: > http://www.ietf.org/mail-archive/web/roll/current/msg03063.html > Ruben said: > http://www.ietf.org/mail-archive/web/roll/current/msg03026.html > > With this new IPR declaration, Cisco retains its defensive right in the > context of RPL implementations *only*. By the new terms Cisco will not > "walk freely anywhere" in someone else's "property". And the answer to > Sung's question about "infringing patents NOT related to RPL" is now a > NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does > the exact same, which seems quite fair to me. For all I know, this is a > major and somewhat exceptional step that should be recognized as such. > And alternate terms based on RAND are still available to anyone who > would prefer that way. > > Sadly, I'll still refrain from detailing which exact pieces RPL I > personally think are covered by this IPR. I think it is pretty clear by > now that this would not have a lot of value since 1) I'm not a lawyer, > and 2) even less your own lawyer. Also the logic of claims somewhat > escapes me, in particular when it comes to coverage. All I know is that > the disclosures I was involved with detail ways to build trees and DAGs, > propagate metrics and paint unicast and multicast routes along the DAGs, > compress and expands routing headers, all things that are somewhat > similar to RPL operations. > > I sincerely hope that this declaration will allow us to reach a positive > consensus on the current poll about Cisco's IPR and move forward with > RPL as soon as possible. Please let us know. > > Pascal > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: Tuesday, February 23, 2010 5:18 PM > To: Pascal Thubert (pthubert); wintert@acm.org; > rpl-authors@external.cisco.com > Cc: rcallon@juniper.net; adrian.farrel@huawei.com; roll@ietf.org; > jpv@cisco.com; culler@eecs.berkeley.edu; ipr-announce@ietf.org > Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR > relating to draft-ietf-roll-rpl-06 > > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-02-23 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1270/). The title of the IPR > disclosure is "Cisco's Statement of IPR relating to > draft-ietf-roll-rpl-06." > > The IETF Secretariat > > > > ------------------------------ Message: 2 Date: Thu, 25 Feb 2010 08:08:43 +0100 From: "Pascal Thubert (pthubert)" Subject: Re: [Roll] Questions on DAO operations To: "Jonathan Hui" , "Philip Levis" Cc: ROLL WG Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="us-ascii" Hi Phil: I globally agree with you. I think we are pretty ripe WRT to the case where source routing is not used. We have mechanisms that loads nodes send up their DAOs when then like, and gather DAOs from their subDAG when they like. What's missing there is more of a matter of recommending when those mechanisms are to be used. When it comes to source route, there are a lot more questions: - should the record route mechanism be part of the DAO as it is today or should it be part of the traffic as Richard suggested. There are pro/cons for both approaches and we really need to discuss that in this list. -(as you say) optimization for the case where only the root store states. Right now, we have an S bit mechanism that is not really spelled out in the spec. This mechanism has assumptions that are not obvious. We need to agree on it. - what routing header will be used? How to compress them? This question is holding 6LoWPAN HC at the moment. I think we should have a number of threads to examine all of these questions. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, February 24, 2010 4:22 AM To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: > >> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >> >> One of the main purposes of including ranks towards downwards >> destinations in a DAO is so that a node receiving two DAOs for the >> same downwards destination can use rank to make a more intelligent >> decision if the rank differs (i.e. preferring the one with lesser >> rank). > > Let's back up -- the purpose is clear but how it achieves that purpose > isn't. How is this value computed/filled in? Should -07 specify this? > Is it correct that DAO Rank is the rank advertised in DIOs? Does that > mean that a node sending DAOs to multiple DAO parents may specify > different DAO Rank values. How does this work for aggregated prefixes? I think it's clear that the DAO mechanism is not nearly as fleshed out as the DIO mechanism. The text is intentionally vague (notice all the 'may' text around it) about what the DAO Rank field can contain - it is simply a place-holder acknowledging the fact that we may want to convey some notion of cost towards the destination. DAO aggregation is something we haven't even discussed yet. But even before that, we need to back up even further and analyze whether the basic DAO mechanism fits our needs. There is concern from the ROLL WG (including myself) on how DAOs are sent or triggered - specifically in cases where a network only caches a subset of the DAO information being sent around. The main challenge is that the WG would like to see a solution that allows both networks where all nodes maintain downward routes and networks where only the root maintains downward routes. Some would even like to see networks that where only some nodes maintain some subset of downward routes. Unfortunately, there's some added complexity in requiring an implementation to support these different modes (e.g. nodes always have to maintain state to know when to trigger DAOs from their children). There's certainly a number of dependencies that are not so obvious at first blush (e.g. a single DAG parent change could cause DAOs to be sent by every node in that sub-DAG). -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 3 Date: Wed, 24 Feb 2010 22:13:19 +0200 From: Zach Shelby Subject: Re: [Roll] Our revised IPR declaration on ROLL To: Dan Lang Cc: roll@ietf.org Message-ID: <973A96A0-6F62-4C45-803C-4A6DB97D11FB@sensinode.com> Content-Type: text/plain; charset=us-ascii Dan, Excellent! I'd like to thank Cisco for the excellent work listening to feedback from all involved and finding a very good compromise! Zach On Feb 23, 2010, at 17:50 , Dan Lang wrote: > > Hi, I wanted to provide a little commentary on the revised licensing commitment language that was just distributed on the mailer. We believe that it will satisfy the concerns as we understand them and allow the WG to move to the next step. Again, the proviso for the commentary is that it is not intended as an interpretation or legal advice and you should seek your own legal counsel. > > Essentially, our new statement, like the old, promises to not assert our essential patents against functionality that implements ROLL, once standardized. The difference is that whereas the old statement suspended, at our option, this commitment in response to any patent assertion against Cisco or Cisco products, the new statement only potentially suspends our commitment as to those who assert their essential patents against Cisco or CIsco products for implementing ROLL. > > Dan Lang > Director, Intellectual Property > Cisco Systems, Inc. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. ------------------------------ Message: 4 Date: Wed, 24 Feb 2010 23:36:09 -0800 From: Jonathan Hui Subject: Re: [Roll] Questions on DAO operations To: Pascal Thubert (pthubert) Cc: ROLL WG Message-ID: <0E2C7A75-1FFD-4E56-9A5F-DAA3BCAFD988@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi Pascal, On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > I globally agree with you. > > I think we are pretty ripe WRT to the case where source routing is not > used. We have mechanisms that loads nodes send up their DAOs when then > like, and gather DAOs from their subDAG when they like. What's missing > there is more of a matter of recommending when those mechanisms are to > be used. I think there are still some concerns on the lack of compactness for the messages - that certainly is the case within the 6lowpan WG. Communicating and storing full IPv6 addresses is fine in the generic case, but there has to be a more efficient way. > When it comes to source route, there are a lot more questions: > > - should the record route mechanism be part of the DAO as it is > today or > should it be part of the traffic as Richard suggested. There are > pro/cons for both approaches and we really need to discuss that in > this > list. > -(as you say) optimization for the case where only the root store > states. Right now, we have an S bit mechanism that is not really > spelled > out in the spec. This mechanism has assumptions that are not > obvious. We > need to agree on it. > - what routing header will be used? How to compress them? This > question > is holding 6LoWPAN HC at the moment. > > I think we should have a number of threads to examine all of these > questions. Yes, I agree these are all issues. I think Richard actually suggested that record-routes are unnecessary if only the root caches downward routing information, though record-routes can be useful in some situations (e.g. on-demand route discovery). A topic that seems to come up every so often is when/where the use of labels show up. That could change our thinking and/or perception. What really worries me is the hidden complexities that result from needing to support both simultaneously. I agree that piece-wise source-routes and being able to operate networks where nodes have widely varying capabilities can take on different responsibilities, but we need to be careful that doing so does not grow beyond our state/ communication complexity goals. Looking forward to talking through these issues in depth. -- Jonathan Hui > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Wednesday, February 24, 2010 4:22 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > On Feb 23, 2010, at 6:54 PM, Philip Levis wrote: > >> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote: >> >>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: >>> >>> One of the main purposes of including ranks towards downwards >>> destinations in a DAO is so that a node receiving two DAOs for the >>> same downwards destination can use rank to make a more intelligent >>> decision if the rank differs (i.e. preferring the one with lesser >>> rank). >> >> Let's back up -- the purpose is clear but how it achieves that >> purpose > >> isn't. How is this value computed/filled in? Should -07 specify this? >> Is it correct that DAO Rank is the rank advertised in DIOs? Does that >> mean that a node sending DAOs to multiple DAO parents may specify >> different DAO Rank values. How does this work for aggregated >> prefixes? > > I think it's clear that the DAO mechanism is not nearly as fleshed out > as the DIO mechanism. The text is intentionally vague (notice all the > 'may' text around it) about what the DAO Rank field can contain - it > is > simply a place-holder acknowledging the fact that we may want to > convey > some notion of cost towards the destination. DAO aggregation is > something we haven't even discussed yet. > > But even before that, we need to back up even further and analyze > whether the basic DAO mechanism fits our needs. There is concern from > the ROLL WG (including myself) on how DAOs are sent or triggered - > specifically in cases where a network only caches a subset of the DAO > information being sent around. The main challenge is that the WG > would > like to see a solution that allows both networks where all nodes > maintain downward routes and networks where only the root maintains > downward routes. Some would even like to see networks that where only > some nodes maintain some subset of downward routes. Unfortunately, > there's some added complexity in requiring an implementation to > support > these different modes (e.g. nodes always have to maintain state to > know > when to trigger DAOs from their children). There's certainly a number > of dependencies that are not so obvious at first blush (e.g. a single > DAG parent change could cause DAOs to be sent by every node in that > sub-DAG). > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------------------------------ Message: 5 Date: Thu, 25 Feb 2010 10:50:56 +0100 From: "Anders Brandt" Subject: Re: [Roll] Questions on DAO operations To: "Pascal Thubert (pthubert)" Cc: ROLL WG Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> Content-Type: text/plain; charset="us-ascii" Hi Pascal Thanks for taking time to explain your thoughts on DAO. Unfortunately, I did not really get the idea of your slide deck! You have Dest sending a RR stack back to C>B>A - but is A then sending this to child which then sends it to Parent? Is the distinction that Parent and Child are stateful routers while A,B,C,Dest can only forward source routed packets? Maybe some different colors or shapes could help clarify this ;-) Finally another small clarification: > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might I agree in this but should RPL do an effort on definition and compression of such source route stacks? My point is that you will need to do the same source routing for actually carrying real traffic along the same route. As far as I understand IPv6 deprecated source routing as it was originally defined, so how would you source route IPv6 packets across a 6lowPan/RPL network? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, February 24, 2010 17:51 > To: Jonathan Hui; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > Hi John and Jonathan. > > I think Question 2 deserves a few more words: > > the short answer > --------------------- > The point is that the record route in the DAO is for the > (sole) use of the recorder, when the RR stack has become a > routing header in a packet on the way back to Destination. > The packet will have to go between the recorder and loose > Source Record Route next_hop in the DAO stack, and the > question is whether the routing info to get there will have > to be picked from the routing header in the packet, or can be > found in the routing table of the recorder. > The IP next-hop to get to the LSRR next-hop is definitively > the source of the DAO, that's what the DAO is all about. So > the question is whether the recorder has a route to the LSRR > next-hop via the source of the packet or not. > If not, then the recorder needs to insert the next-hop > information it will need as the new LSRR next-hop on top of > the LSRR stack. > > The long answer > ------------------- > requires an example, illustrated in the slides attached. > > Let us consider a DAO that is originated from Dest. No one > below Parent decided to cache the specific source route A->B->C->Dest. > > Because nodes do not cache everything, it is acceptable, > though, that DAO routing states are installed all the way > between child and A. The result is that there's no need to > additional source route to reach A from child inside . > > We'll see how that works by forwarding the DAO up one more > time, child to parent, and see what happens whether the > parent has a DAO route to A via Child or not. > > Childs sends this to parent: > IP header: > Source IP = Child > Dest IP = Parent > DAO: > dest = Dest > Stack = A, B, C > > > Case 1: Parent does a route look up for A, and that does > resolves via child. Either parent is missing a routing state, > or its routing state is obsolete. Parent updates the Stack > that is now Child, A, B, C. > Case 1a) If parent decides to cache for Dest, then it stores > Dest via Child, A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest. > When Parent forwards a packet to Dest, it > changes the destination to child, and inserts a RH A, B, C, > Dest. and proceeds forwarding the packet. > Child being connected, the lookup resolved immediately > and the packet is passed to child. > > Case 1b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = child, A, B, C > > The result is that packets to Dest should come back > with a routing header child, A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > If Parent is the destination of the packet, > then it consumes the next entry in the RH, thus setting child > as the destination in the IP header, and proceeds forwarding > the packet. > In any case, child being connected, the lookup is > resolved immediately and the packet is passed to child. > > > Case 2: Parent does a route look up for A, and that resolves > via child. > Great, we have a routing state that's consistent. > Case 2a) If parent decides to cache for Dest, then it stores > Dest via A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest > When Parent forwards a packet to Dest, it > changes the destination to A , and inserts a RH B, C, Dest , > and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Case 2b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = A, B, C > > The result is that packets to Dest should come back > with a routing header A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > Parent being the destination of the packet, > to it consumes the next entry in the RH, iow sets A as the > destination, and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might > decide to store the connected routes via the link locals, and > the global of the children via the link local of the children. > If that's so "Parent does a route look up for A, and that > does resolves via child" must be understood as lookup for A > and lookup for child both resolve in the same address, that > is child's link local address. > > This looks a bit complex said that way. I hope the slideware > attached helps. > > Cheers, > > Pascal > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Wednesday, February 24, 2010 3:42 AM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > Hi John, > > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > > > I was reading through the downwards route section in draft > 6 (section > > 6) and had a few questions in mind. > > > > 1. How is the DAO rank (in Figure 11) computed and what > does this rank > > > value represent? By having this rank value, does it mean that all > > nodes keep a rank for the DODAG (constructed using DIO > > exchanges) separately and also maintain rank values for each > > 'downwards tree' that it participates in (for example if I have two > > nodes that rely on me to receive downwards packets, I would be > > maintaining one DODAG rank and two separate rank values for each of > > the two nodes)? Is this to assure that the downwards > packets will make > > > 'forward' progress? Why can't this be achieved with the DODAG rank > > values? > > One of the main purposes of including ranks towards downwards > destinations in a DAO is so that a node receiving two DAOs > for the same downwards destination can use rank to make a > more intelligent decision if the rank differs (i.e. > preferring the one with lesser rank). > > > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing > > forwarding node will append, on the DAO packet, the address of the > > 'child' to the RRstack. Why should we add the address of > the child and > > > not the node that is forwarding the packet itself? Is there an > > intuition behind this design? If there is a reason for this design, > > how would I retrieve the IP address of the previous hop > (for sure it > > is not included in the IP address fields unless I am the > first hop of > > the node)? > > The IP address of the forwarding node is included in the IP > header - it would be redundant to include the forwarding > node's address in the RRstack as well. > > -- > Jonathan Hui > > _______________________________________________ > 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 End of Roll Digest, Vol 25, Issue 46 ************************************ ______________________________________________________________________ This email has been spam and virus checked by Elster IT Services. _______________________________________________ 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 From Adrian.Farrel@huawei.com Thu Feb 25 13:44:09 2010 Return-Path: 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 22B7A3A848D for ; Thu, 25 Feb 2010 13:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 SaYXlkOoiwyq for ; Thu, 25 Feb 2010 13:44:08 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6482D3A8225 for ; Thu, 25 Feb 2010 13:44:08 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYF00FSZ358G8@usaga01-in.huawei.com> for roll@ietf.org; Thu, 25 Feb 2010 13:46:20 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYF004RD34WL2@usaga01-in.huawei.com> for roll@ietf.org; Thu, 25 Feb 2010 13:46:20 -0800 (PST) Date: Thu, 25 Feb 2010 21:45:38 +0000 From: Adrian Farrel To: roll@ietf.org Message-id: <8D33564714434CF49C9C4B6A44A95BA0@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: roll-ads@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Calling consensus on RPL and IPR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 21:44:09 -0000 Hi, I want to thank all of you who have discussed this issue on the list and in private email and voice conversations with me. I believe your constructive attitude helped to move the debate forward. In the light of the updated IPR disclosure and terms posted by Cisco, and the revised positions that have been announced on the list, I am now comfortable to judge that the working group has strong consensus to continue with the RPL specification building on the existing work and without any requirement to attempt to avoid the IPR. Particular thanks to Dan Lang at Cisco for engaging with the working group and listening to the concerns that were expressed. Now, get back to work! :-) Looking forward to watching you all continue with the remarkable progress that you have made over the last few months. Regards, Adrian From roger.alexander@ekasystems.com Thu Feb 25 14:45:55 2010 Return-Path: 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 DEBC928C444 for ; Thu, 25 Feb 2010 14:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 fczieFcLeLoN for ; Thu, 25 Feb 2010 14:45:54 -0800 (PST) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id 088E23A8579 for ; Thu, 25 Feb 2010 14:45:53 -0800 (PST) Received: (qmail 17234 invoked from network); 25 Feb 2010 22:48:03 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp113.biz.mail.re2.yahoo.com with SMTP; 25 Feb 2010 14:48:03 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: lxXP2ToVM1kBDvFvEEkivn2qOXVz5_sHTthbzWhmoWSptR_19U9CYBYHy00n1HF.vOuReKLFSyNafgZnJDrC6Bvoo5cJwd3G3O8En.4CJO.jt0BiB0IFHIL7_2W305ZobtTHk7z0XFiWUV2l3GzBk4E0O8vsh3A61OS04M7QXCCc614e4WDHaP_Lh1UHlQA48uolnsgpT0Ooj0q8.4N7gKsKqcA0EZqgIReqRyV9u2PdEUNARVl7wa2Tkx1BU.KFrfzgcJFZhOMnehjaJ1aHM52TLMMi8SEWRbg_2SFl522Fy._mJuVHJkbTt6I0dDQ0GMcUT6Kta183bjng_E4ngETp78i4avhEJsKd01GEJmPSkYtww1ZRBazFWkcGYBOasfvwr2y46xN2JEhnfirrHVyunUDdeB6uMTFtVx4- X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Anders Brandt'" , "'Pascal Thubert \(pthubert\)'" References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D0151BB99@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429F06@zensys17.zensys.local> Date: Thu, 25 Feb 2010 17:47:40 -0500 Message-ID: <009301cab66c$89643750$9c2ca5f0$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq0+vTBYd++PjEdQWawKNkklJHAzwAan6hQACYfxaAAGlMP4A== Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:45:56 -0000 Hi Pascal, WG, A point of clarification on the specified DAO operation. In Section 6.2.8. (page 51), the current text reads... 4. Note: it is NOT RECOMMENDED that a DAO Transmission (No-DAO) be scheduled when a DAO Parent is removed from the DAO Parent set. This text, as phrased, may be redundant as there is no value to sending a 'No-DAO' in the case of a removed DAO Parent as there is no relevant DAO Parent to whom the No-DAO would apply. However, there is potential value to an updated DAO transmission to the remaining DAO Parents. The DAO Parent set is intended to allow for some measure of downward routing path diversity (which may nonetheless only be local). However, in the event that a child removes a Parent from the DAO Parent Set, there can be value in the node sending updated DAOs to the remaining Parents of the DAO Parent Set. The response time benefit of updating the DAOs to the remaining DAO Parents is that it will allow for a more ready update of the downward paths from the common ancestor (which may be the root) to the affected node by eliminating the downward path through the removed DAO Parent. There is also the benefit of the potential reduction of network traffic that could otherwise result from failed packet deliveries and subsequent destination unreachable signaling that may occur along segments of the broken downward path. The penalty of the proactive update is of course the additional overhead that will be incurred in signaling to the existing DAO Parents and subsequent ancestor nodes. The tradeoff between proactive path correction and reactive traffic rerouting can be further tilted in the favor of proactive updates by enhancing the DAO message compactness. Currently suggested work on message address compression would be further beneficial as it would lower the overhead of proactive updates. Similarly, if Acknowledged DAO exchanges are supported in RPL there can be additional control options to indicate 'no' or 'incremental' DAO information changes that can be signaled in conjunction with an incremented DAO sequence number. As the draft is updated to include effective DAO message compression it will also assist implementation choice in the tradeoff between proactive and reactive downward path maintenance. Thus within Section 6.2.8, the following text amendment should be considered: 4. A Node MAY transmit a DAO message (with incremented DAO Sequence) to the remaining DAO Parents when a DAO Parent is removed from the DAO Parent set. Thanks. Roger -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Thursday, February 25, 2010 4:51 AM To: Pascal Thubert (pthubert) Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations Hi Pascal Thanks for taking time to explain your thoughts on DAO. Unfortunately, I did not really get the idea of your slide deck! You have Dest sending a RR stack back to C>B>A - but is A then sending this to child which then sends it to Parent? Is the distinction that Parent and Child are stateful routers while A,B,C,Dest can only forward source routed packets? Maybe some different colors or shapes could help clarify this ;-) Finally another small clarification: > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might I agree in this but should RPL do an effort on definition and compression of such source route stacks? My point is that you will need to do the same source routing for actually carrying real traffic along the same route. As far as I understand IPv6 deprecated source routing as it was originally defined, so how would you source route IPv6 packets across a 6lowPan/RPL network? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, February 24, 2010 17:51 > To: Jonathan Hui; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > Hi John and Jonathan. > > I think Question 2 deserves a few more words: > > the short answer > --------------------- > The point is that the record route in the DAO is for the > (sole) use of the recorder, when the RR stack has become a > routing header in a packet on the way back to Destination. > The packet will have to go between the recorder and loose > Source Record Route next_hop in the DAO stack, and the > question is whether the routing info to get there will have > to be picked from the routing header in the packet, or can be > found in the routing table of the recorder. > The IP next-hop to get to the LSRR next-hop is definitively > the source of the DAO, that's what the DAO is all about. So > the question is whether the recorder has a route to the LSRR > next-hop via the source of the packet or not. > If not, then the recorder needs to insert the next-hop > information it will need as the new LSRR next-hop on top of > the LSRR stack. > > The long answer > ------------------- > requires an example, illustrated in the slides attached. > > Let us consider a DAO that is originated from Dest. No one > below Parent decided to cache the specific source route A->B->C->Dest. > > Because nodes do not cache everything, it is acceptable, > though, that DAO routing states are installed all the way > between child and A. The result is that there's no need to > additional source route to reach A from child inside . > > We'll see how that works by forwarding the DAO up one more > time, child to parent, and see what happens whether the > parent has a DAO route to A via Child or not. > > Childs sends this to parent: > IP header: > Source IP = Child > Dest IP = Parent > DAO: > dest = Dest > Stack = A, B, C > > > Case 1: Parent does a route look up for A, and that does > resolves via child. Either parent is missing a routing state, > or its routing state is obsolete. Parent updates the Stack > that is now Child, A, B, C. > Case 1a) If parent decides to cache for Dest, then it stores > Dest via Child, A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest. > When Parent forwards a packet to Dest, it > changes the destination to child, and inserts a RH A, B, C, > Dest. and proceeds forwarding the packet. > Child being connected, the lookup resolved immediately > and the packet is passed to child. > > Case 1b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = child, A, B, C > > The result is that packets to Dest should come back > with a routing header child, A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > If Parent is the destination of the packet, > then it consumes the next entry in the RH, thus setting child > as the destination in the IP header, and proceeds forwarding > the packet. > In any case, child being connected, the lookup is > resolved immediately and the packet is passed to child. > > > Case 2: Parent does a route look up for A, and that resolves > via child. > Great, we have a routing state that's consistent. > Case 2a) If parent decides to cache for Dest, then it stores > Dest via A, B, C. > Parent forwards the DAO to its ancestor as: > > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = > > The result is that packets to Dest should come back > without a routing header, with the IP header destination set to Dest > When Parent forwards a packet to Dest, it > changes the destination to A , and inserts a RH B, C, Dest , > and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Case 2b) If parent decides not to cache for Dest, then it > forwards to its own ancestor > IP header: > Source IP = parent > Dest IP = Ancestor > DAO: > dest = Dest > Stack = A, B, C > > The result is that packets to Dest should come back > with a routing header A, B, C, and with the IP header > destination set to parent or child, depending on whether > ancestor has a route to child via parent or not. > Parent being the destination of the packet, > to it consumes the next entry in the RH, iow sets A as the > destination, and proceeds forwarding the packet now destined to A. > A route lookup of A resolves in child (as verified > above), so the packet can be passed to child. > > Note finally for the gory side of it that A, B, and C etc... > are not link local addresses. They have to be global or ULA, > because they can be used multihop. An implementation might > decide to store the connected routes via the link locals, and > the global of the children via the link local of the children. > If that's so "Parent does a route look up for A, and that > does resolves via child" must be understood as lookup for A > and lookup for child both resolve in the same address, that > is child's link local address. > > This looks a bit complex said that way. I hope the slideware > attached helps. > > Cheers, > > Pascal > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Wednesday, February 24, 2010 3:42 AM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations > > > Hi John, > > On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote: > > > I was reading through the downwards route section in draft > 6 (section > > 6) and had a few questions in mind. > > > > 1. How is the DAO rank (in Figure 11) computed and what > does this rank > > > value represent? By having this rank value, does it mean that all > > nodes keep a rank for the DODAG (constructed using DIO > > exchanges) separately and also maintain rank values for each > > 'downwards tree' that it participates in (for example if I have two > > nodes that rely on me to receive downwards packets, I would be > > maintaining one DODAG rank and two separate rank values for each of > > the two nodes)? Is this to assure that the downwards > packets will make > > > 'forward' progress? Why can't this be achieved with the DODAG rank > > values? > > One of the main purposes of including ranks towards downwards > destinations in a DAO is so that a node receiving two DAOs > for the same downwards destination can use rank to make a > more intelligent decision if the rank differs (i.e. > preferring the one with lesser rank). > > > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing > > forwarding node will append, on the DAO packet, the address of the > > 'child' to the RRstack. Why should we add the address of > the child and > > > not the node that is forwarding the packet itself? Is there an > > intuition behind this design? If there is a reason for this design, > > how would I retrieve the IP address of the previous hop > (for sure it > > is not included in the IP address fields unless I am the > first hop of > > the node)? > > The IP address of the forwarding node is included in the IP > header - it would be redundant to include the forwarding > node's address in the RRstack as well. > > -- > Jonathan Hui > > _______________________________________________ > 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 From pal@cs.stanford.edu Thu Feb 25 17:18:28 2010 Return-Path: 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 A91093A7B78 for ; Thu, 25 Feb 2010 17:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 MrHdm5S9GOul for ; Thu, 25 Feb 2010 17:18:27 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B4F2D3A6D3F for ; Thu, 25 Feb 2010 17:18:27 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nkosh-0003v6-VN for roll@ietf.org; Thu, 25 Feb 2010 17:20:40 -0800 From: Philip Levis Content-Type: multipart/alternative; boundary=Apple-Mail-7--1070253072 Date: Thu, 25 Feb 2010 17:20:39 -0800 References: <20100226011704.C9E4D28C140@core3.amsl.com> To: ROLL WG Message-Id: <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: e7339ca2e2d71873cd3c16053348112b Subject: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 01:18:28 -0000 --Apple-Mail-7--1070253072 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thomas and I thought it might make sense to separate Trickle out from = the RPL specification. Here's a first version of the draft: http://www.ietf.org/internet-drafts/draft-levis-roll-trickle-00.txt Phil Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 25, 2010 5:17:01 PM PST > To: pal@cs.stanford.edu > Cc: T.Clausen@computer.org > Subject: New Version Notification for draft-levis-roll-trickle-00=20 >=20 >=20 > A new version of I-D, draft-levis-roll-trickle-00.txt has been = successfuly submitted by P Levis and posted to the IETF repository. >=20 > Filename: draft-levis-roll-trickle > Revision: 00 > Title: The Trickle Algorithm > Creation_date: 2010-02-25 > WG ID: Independent Submission > Number_of_pages: 8 >=20 > Abstract: > The Trickle algorithm allows wireless nodes to exchange information > in a highly robust, energy efficient, simple, and scalable manner. > Dynamically adjusting transmission windows allows Trickle to spread > new information on the scale of link-layer transmission times while > sending only a few messages per hour when information does not > change. A simple suppression nechanism and transmission point > selection allows Trickle's communication rate to scale > logarithmically with density. This document describes Trickle and > considerations in its use. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-7--1070253072 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/internet-drafts/draft-levis-roll-trickle-00.txt=

Phil

Begin forwarded = message:

From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: February 25, 2010 5:17:01 PM PST
To: pal@cs.stanford.edu
Subject: New Version = Notification for draft-levis-roll-trickle-00 =


A new version of I-D, = draft-levis-roll-trickle-00.txt has been successfuly submitted by P = Levis and posted to the IETF repository.

Filename: = draft-levis-roll-trickle
Revision: 00
Title: The = Trickle Algorithm
Creation_date: 2010-02-25
WG ID: = Independent Submission
Number_of_pages: 8

Abstract:
The = Trickle algorithm allows wireless nodes to exchange information
in a = highly robust, energy efficient, simple, and scalable = manner.
Dynamically adjusting transmission windows allows Trickle to = spread
new information on the scale of link-layer transmission times = while
sending only a few messages per hour when information does = not
change.  A simple suppression nechanism and transmission = point
selection allows Trickle's communication rate to = scale
logarithmically with density.  This document describes = Trickle and
considerations in its use.



The IETF = Secretariat.



= --Apple-Mail-7--1070253072-- From pal@cs.stanford.edu Thu Feb 25 18:04:15 2010 Return-Path: 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 B7A6228C3D3 for ; Thu, 25 Feb 2010 18:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 xmyEnCCLrAWL for ; Thu, 25 Feb 2010 18:04:15 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 1CBF728C147 for ; Thu, 25 Feb 2010 18:04:15 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nkpb1-0006P5-Qs; Thu, 25 Feb 2010 18:06:28 -0800 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com><00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu> <44516837-62BD-4D98-AF91-E31092CF2601@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1468E781-0CDD-46B5-9959-CA460876059B@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 25 Feb 2010 18:04:35 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 02:04:15 -0000 On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > I globally agree with you. > > I think we are pretty ripe WRT to the case where source routing is not > used. We have mechanisms that loads nodes send up their DAOs when then > like, and gather DAOs from their subDAG when they like. What's missing > there is more of a matter of recommending when those mechanisms are to > be used. > I'm sorry -- what are you agreeing with? I had a bunch of concrete technical questions on how DAOs work. Can you answer them? Phil From mijeom@gmail.com Fri Feb 26 00:30:05 2010 Return-Path: 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 6145628C0F1 for ; Fri, 26 Feb 2010 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 AmVhxYao0fid for ; Fri, 26 Feb 2010 00:30:04 -0800 (PST) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by core3.amsl.com (Postfix) with ESMTP id 8921928C0DF for ; Fri, 26 Feb 2010 00:30:04 -0800 (PST) Received: by pxi30 with SMTP id 30so624826pxi.17 for ; Fri, 26 Feb 2010 00:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q+ofc8pJf016A5Sti9ioj7junckU2f/ttFsKimBkhJY=; b=JJ50fCHiDcT75pTu6U9aLMFWdf7xLFguyxzhcvsiyGowMWW4zRw3vnrRkQTvnsWqho YWSCFehJaxqgNkZIQnKglE4rF8q8zdepdXW0+uOapwUC8gqI2LsOX3cbGH2kAixgP9E4 lq2jAV7wNoy/oe9QZew4nqjPDHFbyQN10Cdj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=stEdPT4EE+op8/DfgsEZyFtC+d2cg20SvKqh98nhZTGsUvSo1b1f6eXv93Nkjb/eiL kqZFbgMvoY2KIKAUkvRjKtJqMND7HwNtbhqWocQdY9xy5KUksMU7jDQzFAwe6zYeI2Yi iNl7QMNAu6DxJDLE/NMuW9jBGVrt/jChrH7BE= MIME-Version: 1.0 Received: by 10.142.118.26 with SMTP id q26mr32845wfc.127.1267173135955; Fri, 26 Feb 2010 00:32:15 -0800 (PST) In-Reply-To: References: <01f301cab4b7$1cecdb60$56c69220$@com> Date: Fri, 26 Feb 2010 17:32:15 +0900 Message-ID: From: MiJeom Kim To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yoav Ben-Yehezkel , roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 08:30:05 -0000 Hi, To summarize up to now, for latency metric, 1. Better to express both in millisecond and microsecond 2. 2 bytes may be enough 3. Floating point needs to be avoided So how about using 2 bytes with the first bit to express the unit (millisecond or microsecond) and the rest 15 bits for the value (unsigned integer)? And for throughput, for simplicity, how about using bytes per second presented by unsigned integer using 32 bits? That is my first suggestion. Regarding baud, I meant that given the same bandwidth, changing modulation methods (e.g. BPSK or QPSK) changes baud rate, but not bytes per second. Mijeom On Wed, Feb 24, 2010 at 4:28 AM, Philip Levis wrote: > > On Feb 23, 2010, at 10:36 AM, Yoav Ben-Yehezkel wrote: > >> Hi, >> >> Just a thought. >> >> How about assigning a few bits to the exponent of seconds (so for exampl= e, >> -9 would mean resolution of nanoseconds, and 0 would mean resolution of >> seconds), and the rest for the value itself. >> >> If the upper bound becomes too small, consider lowering the number of bi= ts >> for the exponent such that each increase would represent a scale of 1,00= 0 >> or so up or down instead of 10 (so for -1 resolution is for millisec, fo= r >> -2 the scale is microsec, etc.). > > Floating point can cause problems with gradient calculations. If the dyna= mic range of values is greater than the dynamic range of the floating point= , then it can be that A + B =3D A when B > 0. This can cause problems when = transforming routing metrics to Rank unless we are careful. That is, the mi= n rank increase requirement will have to operate on the mantissa independen= tly of the exponent. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abr@sdesigns.dk Fri Feb 26 02:14:47 2010 Return-Path: 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 C15773A82B0 for ; Fri, 26 Feb 2010 02:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] 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 N1QgcQuafZZs for ; Fri, 26 Feb 2010 02:14:43 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 7A6823A8686 for ; Fri, 26 Feb 2010 02:14:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 11:16:54 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F0D@zensys17.zensys.local> In-Reply-To: <1468E781-0CDD-46B5-9959-CA460876059B@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Questions on DAO operations Thread-Index: Acq2iFJFyLHBd2pgTX+NPLEUf2MZrgAQ03sw References: <39F27BC7-C50D-40AA-A0F9-BADA31F326FD@archrock.com><00A9452C-1967-4D6A-A6FF-347C1B11AC00@cs.stanford.edu><44516837-62BD-4D98-AF91-E31092CF2601@archrock.com><6A2A459175DABE4BB11DE2026AA50A5D0151BCE3@XMB-AMS-107.cisco.com> <1468E781-0CDD-46B5-9959-CA460876059B@cs.stanford.edu> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" Cc: ROLL WG Subject: Re: [Roll] Questions on DAO operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:14:47 -0000 Same issue for me: I am still eager to see how the current RPL proposal can guarantee that I can - within a second or less (maybe a few) -=20 reach nodes somewhere in the tree if the current routes do not work? On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: > ... We have mechanisms that loads nodes send up their DAOs when then=20 > like, and gather DAOs from their subDAG when they like... The issue is that if a light module is not aware that routes are broken, "when they like" may be minutes into the future. It may be fine for data gathering and smart meters but it is a showstopper for home and building. Users will never appreaciate non-reactive light controls. Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Philip Levis > Sent: Friday, February 26, 2010 03:05 > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] Questions on DAO operations >=20 >=20 > On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > I globally agree with you. > > > > I think we are pretty ripe WRT to the case where source=20 > routing is not=20 > > used. We have mechanisms that loads nodes send up their=20 > DAOs when then=20 > > like, and gather DAOs from their subDAG when they like.=20 > What's missing=20 > > there is more of a matter of recommending when those=20 > mechanisms are to=20 > > be used. > > >=20 > I'm sorry -- what are you agreeing with? I had a bunch of=20 > concrete technical questions on how DAOs work. Can you answer them? >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From adam@sics.se Fri Feb 26 07:48:03 2010 Return-Path: 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 1983C3A8695; Fri, 26 Feb 2010 07:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 dNYdt1K0zhOv; Fri, 26 Feb 2010 07:48:02 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 621283A840C; Fri, 26 Feb 2010 07:48:01 -0800 (PST) Received: from [10.1.1.153] (unknown [10.1.1.153]) by letter.sics.se (Postfix) with ESMTPS id 27F8740356; Fri, 26 Feb 2010 16:50:15 +0100 (CET) Message-ID: <4B87EDB5.6070906@sics.se> Date: Fri, 26 Feb 2010 16:50:13 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Roll] ACM HotEmNets 2010 - only a few days left! X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:48:03 -0000 There are only a few days left to submit papers to ACM HotEmNets! Paper deadline is Monday, March 1 2010. Papers are 5 pages, double-column format. All submissions will be peer reviewed by the program committee. Accepted papers will be published in the ACM digital library. Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From gnawali@cs.stanford.edu Fri Feb 26 09:14:07 2010 Return-Path: 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 8B0CD28C245; Fri, 26 Feb 2010 09:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 PZXRPRrYifk5; Fri, 26 Feb 2010 09:14:04 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 02D1C28C25F; Fri, 26 Feb 2010 09:14:03 -0800 (PST) Received: from mail-qy0-f195.google.com ([209.85.221.195]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Nl3nW-00048Y-VP; Fri, 26 Feb 2010 09:16:19 -0800 Received: by qyk33 with SMTP id 33so313409qyk.17 for ; Fri, 26 Feb 2010 09:16:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.59.71 with SMTP id k7mr394650qah.245.1267204577890; Fri, 26 Feb 2010 09:16:17 -0800 (PST) In-Reply-To: <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> References: <20100223045634.C3F6328C44F@core3.amsl.com> <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> Date: Fri, 26 Feb 2010 09:16:17 -0800 Message-ID: From: Omprakash Gnawali To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 8ae29cfe0e7acab0c1a6d8f3d15a0178 Cc: "L. Aaron Kaplan" , ROLL WG , MANET IETF Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 17:14:08 -0000 We can definitely learn from the experience at Funkfeuer. Specifically, regarding ETX, it was interesting that there was a need to represent better than ETX=1 links. However, I wonder if it is better to use different metrics to differentiate these links rather than overloading the meaning of ETX. It is always good to get insights from practice on these issues... - om_p On 2/22/10, Thomas Heide Clausen wrote: > Just a FYI: in the [manet] WG, an ETx metrics specification was > published recently, based on the exhaustive operational experiences > from the FunkFeuer network: > > http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx > > I understand that the above I-D is being revised and an update is > expected shortly. > > I thought that it might be useful to cross-post this information -- it > would seem that there's both similarity and complementarity here. > > (and, for some reason, the only URL for draft-gnawali-roll-etxof that > I could make work is this: > https://datatracker.ietf.org/doc/draft-gnawali-roll-etxof/ > ) > > Sincerely, > > Thomas > > > On Feb 23, 2010, at 06:03 AM, Omprakash Gnawali wrote: > >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: Mon, Feb 22, 2010 at 8:56 PM >> Subject: New Version Notification for draft-gnawali-roll-etxof-00 >> To: gnawali@cs.stanford.edu >> Cc: pal@cs.stanford.edu >> >> >> >> A new version of I-D, draft-gnawali-roll-etxof-00.txt has been >> successfuly submitted by Omprakash Gnawali and posted to the IETF >> repository. >> >> Filename: draft-gnawali-roll-etxof >> Revision: 00 >> Title: The ETX Objective Function for RPL >> Creation_date: 2010-02-22 >> WG ID: Independent Submission >> Number_of_pages: 7 >> >> Abstract: >> The ETX metric of a wireless link is the expected number of >> transmissions required to successfully transmit and acknowledge a >> packet on the link. The Routing Protocol for Low Power and Lossy >> Networks (RPL) allows the use of objective functions to construct >> routes that optimize or constrain a routing metric on the paths. >> This specification describes ETXOF, an objective function that >> minimizes ETX. The RPL path computation using ETXOF results in >> minimum-ETX paths from the nodes to the DAG roots, i.e., paths that >> minimize the number of packet transmissions for packet delivery from >> nodes in the network to the DAG root. >> >> >> >> The IETF Secretariat. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From hrogge@googlemail.com Sun Feb 28 02:41:23 2010 Return-Path: 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 EFA963A8A72; Sun, 28 Feb 2010 02:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 T+BP1v8PKDGH; Sun, 28 Feb 2010 02:41:21 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 7D60C3A8A3B; Sun, 28 Feb 2010 02:41:21 -0800 (PST) Received: by ewy7 with SMTP id 7so331672ewy.29 for ; Sun, 28 Feb 2010 02:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=EOEhfr+sVQo1eID11CafBfDgpvIUyL7FUpVX3uRWBXY=; b=umsaUCsD6c9iqTBTKHMpdsYNap9mLCKXJP0kSoGQ4Exk30mTs93FxuEguhWh09Bn/2 XHpbE8FV8JLF8G8k83mJC12M9/OFAXnCXn2Fvm4o8nglVzihSkox0CzfidRKTY37nvmH IrWLwY728zivN+sYFbIgJCpvc2817lvej6MBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=l1V8yQNrccxa8emYlQWRQ5mGWiniXGHInB+VxrW5mSeyK0fABXJx0Cfh7CRA4XE3Xv KR378weKQi/ivWCocjfLBo3jKXRrI4j30z10BotD2+ZpTPFHasyjITjeyjLm9AtuzEzC hE/9XNUNy9GzW8Q4hxVjotFrDb4jdKi1AlPbE= Received: by 10.213.66.11 with SMTP id l11mr2089126ebi.7.1267353677715; Sun, 28 Feb 2010 02:41:17 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm7031991eyg.16.2010.02.28.02.41.16 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Feb 2010 02:41:16 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Sun, 28 Feb 2010 11:41:10 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.33-gentoo; KDE/4.4.0; x86_64; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> In-Reply-To: <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4144617.BCBNyWkg9d"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002281141.15423.hrogge@googlemail.com> Cc: ROLL WG , Marcello Caleffi , Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 10:41:23 -0000 --nextPart4144617.BCBNyWkg9d Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Sonntag 28 Februar 2010 11:19:50 schrieb Marcello Caleffi: > My two cents. > I think that ETX is a better metric than hop count (maybe every not stupid > metric works better then it), however I think that sometimes we miss the > point. The ETX estimates the expected transmission count basing on the > delivery ratios. A lot of works deal with improving the use of the > delivery ratios, but very few deal with improving the delivery ratio > estimation, which is the real key point (as it seems to me by my > simulations/experiments). So, with stupid delivery ratio estimators you > need to differentiate between links with the same ETX metric (in well > connected networks you have a lot of '1' links, while in high > dynamic/delay tolerant networks you have a lot of 'big value' links) just > because these estimators do not do their job. Just as example, generally > people use the moving average one (counting the hello packets received and > normalize to the number of hello sent), which assigns to the sequences > '0000011111' and '1111100000' the same directional delivery ratio (0.5). > However, maybe I am boring the list with uninteresting or out-of-topic > considerations , so I stop here. We did some experiments at Freifunk/Funkfeuer with an ETX metric based on=20 exponential aging to favor the recent data input, but discovered it dit not= =20 work well so we got back to a flat average of a certain time interval. This= =20 works well for our fixed networks, but could be better for mobile ones. It would be an interesting experiment to do the averaging with a slight bia= s=20 towards the new values, but this could have a negative side effect too. If = you=20 have an fluctuating link you get more fluctiation in the ETX result if you= =20 favor a small part of your input data. A better approach might be to calculate the standard deviation of the data= =20 points and use this as a penalty for the total link cost to favor stable li= nks=20 over unstable one. Without more statistics it's difficult too say that a=20 "0000011111" event is better than the "1111100000" event. Both could just b= e=20 the result of an instable and fluctuating link. Henning Rogge --nextPart4144617.BCBNyWkg9d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkuKSEsACgkQcenvcwAcHWemWQCeJgukgTFyRq6gIHmEqU/BdB9O CF0An3IH7mrl1qNmfvqqo2rYRqu/7Kjp =8A+a -----END PGP SIGNATURE----- --nextPart4144617.BCBNyWkg9d-- From hrogge@googlemail.com Sun Feb 28 03:13:03 2010 Return-Path: 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 6664A3A8A74; Sun, 28 Feb 2010 03:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 jPNG9CX8LN27; Sun, 28 Feb 2010 03:13:02 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id D3C683A8A76; Sun, 28 Feb 2010 03:13:00 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so121018eya.5 for ; Sun, 28 Feb 2010 03:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=FjSlNOVPjw9Z5bzAmdF5LqX3mAhSBUgRgadbmL2nDLA=; b=JwwYJOJCOhZyTKSuCBeUwH69Bp11tFN8IGHZXTt1k6NlIxnxvDlmViTqNT5QjrBbc6 eYlfuW1L/KmgTBmsTaODg1QXQa+Xz2DpGYFfX+uc+LElTcMiqDj9J0yRAQQUE5zTi3Uz JnRaME4fInwPML7AbN3JZ0XV56ozvuIQeXF3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=XOfTwTDqEDsBraSPbP002QRP3glNUFlgYNTq8nwnbFWaYBHG43EbMyWSEKGXN2MtC3 RnnW4m7I9xmTrOWhpp+Zx4441hqdx24ZqPAYEeZilRhRtj+sOydu1pmaBcwm9NqxPQJB yv7hibzBZt8Zwz7GI9Qb4ZDzegcuuto7hU5ro= Received: by 10.213.96.229 with SMTP id i37mr2130516ebn.56.1267355576626; Sun, 28 Feb 2010 03:12:56 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm6854490eyg.32.2010.02.28.03.12.55 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Feb 2010 03:12:55 -0800 (PST) From: Henning Rogge To: Marcello Caleffi Date: Sun, 28 Feb 2010 12:12:49 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.33-gentoo; KDE/4.4.0; x86_64; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <201002281141.15423.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4199480.Ekq5YJuLb2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002281212.54577.hrogge@googlemail.com> Cc: ROLL WG , manet@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 11:13:04 -0000 --nextPart4199480.Ekq5YJuLb2 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Sonntag 28 Februar 2010 11:54:06 schrieb Marcello Caleffi: > Dear Henning, > the exponential moving average is another common estimator for delivey > ratios. And I'm not surprised to read that it performed worse in a fixed > network (in absence of congestion, I suppose). The main issue with the > exponential aging is that the forgetting weight is fixed and it has to be > set by the user, i.e. is not adaptive. The same thing happens for a biased > estimator, until the estimator is not adaptive. Yes, there is no easy way to fix a metric for all cases. > You right saying that > without more statistics is hard to establish (from a statistically point > of view) which is better among "0000011111" and "1111100000", however > there are adaptive estimators (not too complex in terms of memory or > computational cycles) which can exploits the correlation among trials. If > my whole contact history is composed by 'ones', and I started to receives > '0's, is hard to think that nothing happened. Or maybe a bird just got into your transmission path. Better wait a few=20 moments before changing the metric output of the algorithm to see if it was= =20 just a glitch. > Maybe we could make some experiments in your network. That would be a little bit difficult because Freifunk/Funkfeuer networks ar= e=20 distributed over cities and used by their owners to get internet access. Bu= t=20 we have a limited test setup in Vienna that use a second IP range and port = to=20 run two OLSR instances on the same hardware. > However, the important thing for me is to discuss about it. One thing we were talking about in Funkfeuer was something we call "metric= =20 postprocessing". If we have a metric implementation that outputs a=20 dimensionless metric value, we could add another layer of algorithms to use= =20 statistics to stabilize and enhance the raw metric output, independant to t= he=20 metric itself. > Talking about how to use the delivery ratios (i.e. how > to compute and standardize the ETX metric) before to correctly (from an > operational, a statistical and a standardization point of view) compute > the delivery ratios is questionable in my mind. The draft I have sent to the MANET working group is a description of the=20 metric we have been using in the Freifunk/Funkfeuer networks for years. So = we=20 can say "yes, this does work" and "it works thousands times better than=20 hopcount". It's not meant as the "final and best approach to ETX", but it i= s a=20 working algorithm to compute a metric with few resources (most of our hardw= are=20 are embedded routers with 200-300 MHz CPUs and 16 MB ram). It's better to h= ave=20 a draft like this than to public a routing protocol without any documented= =20 alternative to hopcount (which does not work) which happened for OLSRv1. Ev= en=20 today I hear people on conferences talking about "OLSR does not work, see o= ur=20 little trick works better" and using hopcount. Why do they use hopcount ?=20 Because the RFC says so. Henning Rogge --nextPart4199480.Ekq5YJuLb2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkuKT7YACgkQcenvcwAcHWeqMgCffPOJQsiXpgXA5xxTmPyHNjXq sxwAn1+G+t9HpMjBO+E0K3u2TBa2RoZH =ezr2 -----END PGP SIGNATURE----- --nextPart4199480.Ekq5YJuLb2-- From hrogge@googlemail.com Sun Feb 28 12:58:52 2010 Return-Path: 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 44A2428C1D3; Sun, 28 Feb 2010 12:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 yGQjdB7Ig3jS; Sun, 28 Feb 2010 12:58:51 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id C29D428C1CF; Sun, 28 Feb 2010 12:58:50 -0800 (PST) Received: by ewy7 with SMTP id 7so495948ewy.29 for ; Sun, 28 Feb 2010 12:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=lJKHIQxLc9H5WUSww2+bi6tPxD+Lkr4b9i+2e2GLbAQ=; b=KCcZ3nz2yZtJI/rF/TktvCA6j5QwBV08ZIaCQBPRHadWDINjjeU2XDSdF3S08mr1+l 9RcZH+ybqaXjB9r0QzR8Enqk8xJKt80LK2VUr5dXRu6NYSmfahpA4wyfmsJ1LLGZqylK 7hlrWLPLGFLuk4F8/bCHXopY2tgp+zEyswI9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=HbTupE5gpWZk7IPy3c23LJ/epVn2EXMoYvD9I+BND2KfsWjbfhgvEpmmBpKzQ0WJo6 oVZKZl9aIDHUuiyhjok3SCBXvg/wFbCSXbgftddtnoq5hEl9XY3Tl6LAVnIv28B6QmHi GMlTOzpMbwF0s0pYkzxBCi1/dX/nyW37pBWfE= Received: by 10.213.68.138 with SMTP id v10mr2227480ebi.25.1267390727348; Sun, 28 Feb 2010 12:58:47 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm8276048eyf.19.2010.02.28.12.58.45 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Feb 2010 12:58:45 -0800 (PST) From: Henning Rogge To: Marcello Caleffi Date: Sun, 28 Feb 2010 21:58:27 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.33-gentoo; KDE/4.4.0; x86_64; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <201002281212.54577.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1475042.8YY0iGrVTE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002282158.35975.hrogge@googlemail.com> Cc: ROLL WG , manet@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 20:58:52 -0000 --nextPart1475042.8YY0iGrVTE Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Sonntag 28 Februar 2010 12:33:49 schrieb Marcello Caleffi: > We should discuss about it. Honestly, I don't know if the post-processing > can be independent from the metric dimension, but it will be a nice idea. I'm convinced it can be done, especially if the range of raw metric would be known (0 to 2^24-1 for example). Sliding-Window averaging, exponential agin= g,=20 even hysteresis could be considered postprocessing of the raw link value, n= ot=20 depending what data is represented by the link. It's similar to ripples objective function I think, just with a little bit= =20 more options. =20 > It was not my intention to discuss against your draft. Until we move > towards realistic hypothesis, I am in. Okay. > But since there are multiple > bi-directional connections among the topics: << I want a routing protocol > that works also in non-trivial networks <---> routing protocols forward > the packets according to routing metrics <---> I need a good routing > metric <---> routing metric usually estimates random processes like > delivery ratio or round trip time Packet loss/error rate, delay and bandwith... that are the most common thre= e=20 generic metric values I think. Signal strength might be a forth one. > <---> I need a good estimator >> here I > am just exploiting the opportunity provided by your draft to discuss some > issues outside from my research group. If you have a good idea how to "smooth/stabilize" the output of a packet lo= ss=20 measurement without sacrificing lot's of reaction time of the metric I woul= d=20 be very interested. The problem with many routing metrics is that they either fluctuate too muc= h=20 or need to much time to detect change. Henning Rogge --nextPart1475042.8YY0iGrVTE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkuK2PsACgkQcenvcwAcHWe6ZACgjlyfhV5ZtIhe94gbhfaJbkGm cu8AnRyUuhxHqCI0YIrZ2R6IsuvboLUf =iRP2 -----END PGP SIGNATURE----- --nextPart1475042.8YY0iGrVTE-- From wintert@acm.org Sun Feb 28 16:30:12 2010 Return-Path: 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 9D6DA3A8A14 for ; Sun, 28 Feb 2010 16:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 QcRRYM-xBNzG for ; Sun, 28 Feb 2010 16:30:11 -0800 (PST) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id 883683A8A07 for ; Sun, 28 Feb 2010 16:30:11 -0800 (PST) Received: (qmail 45384 invoked from network); 1 Mar 2010 00:30:08 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 28 Feb 2010 16:30:08 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: j8tx_2IVM1mNvUO16fop3JCMKeLQ2gQ.CzA8P3j46_jTckh4P4e1ixzO9LGbPzwLJYtu_tzQ1jYUB7yPxUkD7cLw4KbFtgGED2AT2HTrk6KP.b6_AYFi1BE9f1MJ2mFcl3nQ1FiNMxthoiv5I9_yczIvPbo2.ilkZTG3EfKRSMKH4U188OuO89qn63NwMq_MRSvCO3nYupXU.sVPZiv8Nn7SpYQVkL653lFopgnrtrZ2puGLScaDI57_sZDY_rs9x4G6HrfeRXB4hHc1OXs2Q0M4lw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B8B0A9B.3020005@acm.org> Date: Sun, 28 Feb 2010 19:30:19 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: d.sturek@att.net References: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com> <054001cab646$432d5210$c987f630$@sturek@att.net> In-Reply-To: <054001cab646$432d5210$c987f630$@sturek@att.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 00:30:12 -0000 Hi Don, Don Sturek wrote: > Hi Pascal, > > One additional question: If I am routing from outside the DAG to a device > in the DAG at a rank that is not the DAG root, is source routing required? > I had thought with the right selection of RA/RS and storage within the > devices in the DAG it was possible to support this scenario without source > routing. Could you or someone in the DT answer this? > > The issue is if source routing is required, we need to carefully review the > header sizes to see if this will actually work for our application. > > Thanks, > > Don Generally the idea is that traffic originating from outside the RPL domain and headed for a LLN destination inside the RPL domain would never need source routing on the outside of the RPL domain. When the traffic crosses into the RPL domain it may or may not need source routing as per the capabilities of the implementation. In the case where the nodes in the LLN store DAO state, as per the HW selection made by the implementation, then it may be possible that the traffic can traverse down the DODAG to the destination using only hop-by-hop routing state and without any additional modification to the traffic. In the case where not all of the nodes in the LLN are able to store DAO state, intermediate nodes will usually need to add source routing information to the traffic at the borders of the non-storing regions that the traffic must traverse. In the case where only the DAG root is capable of storing any DAO state, then the source routing information would be added at the DAG root as the traffic enters the RPL domain. The design decisions made in RPL thus far try to take into account the capabilities of both storing and non-storing nodes. The exact mechanism to bind source routing information on to the data traffic is still to be determined. Related mechanisms such as address compression and/or the use of tags/labels to mitigate the impact on header sizes have also been suggested by various members of the WG. Regards, -Tim From aaron@lo-res.org Fri Feb 26 09:45:19 2010 Return-Path: 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 57DA528C2AE; Fri, 26 Feb 2010 09:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Ro1aVXwwxDKo; Fri, 26 Feb 2010 09:45:18 -0800 (PST) Received: from mute.lo-res.org (mute.lo-res.org [193.238.157.69]) by core3.amsl.com (Postfix) with ESMTP id 2C71328C298; Fri, 26 Feb 2010 09:45:18 -0800 (PST) Received: from [192.168.100.101] (zhaus [62.178.168.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id 05ACFCE21AD; Fri, 26 Feb 2010 18:48:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "L. Aaron Kaplan" In-Reply-To: Date: Fri, 26 Feb 2010 18:47:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68FCEC5B-D9E7-4D5E-8BD5-1E2E094FDD58@lo-res.org> References: <20100223045634.C3F6328C44F@core3.amsl.com> <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Sun, 28 Feb 2010 17:46:19 -0800 Cc: MANET IETF , ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 17:45:19 -0000 On Feb 26, 2010, at 6:16 PM, Omprakash Gnawali wrote: > We can definitely learn from the experience at Funkfeuer. We will document it in a draft :) > Specifically, regarding ETX, it was interesting that there was a need > to represent better than ETX=3D1 links. However, I wonder if it is > better to use different metrics to differentiate these links rather > than overloading the meaning of ETX. It is always good to get insights > from practice on these issues... I agree... however , we have an operational issue here... the network is = quite distributed and community owned (so we can not reach every node with a = central=20 root account). Therefore updating is a pain in the neck.=20 Every update step has to be somewhat compatible. Well.. already discussed with Emmanuel, Thomas and Henning that we will = document the successes and learned lessons of Funkfeuer. :) Best regards, L. Aaron Kaplan (funkfeuer.at)= From marcello.caleffi@unina.it Sun Feb 28 02:20:09 2010 Return-Path: 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 D02E93A8A09; Sun, 28 Feb 2010 02:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 rHCEERMdIDxH; Sun, 28 Feb 2010 02:20:07 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id 72F5A3A8A03; Sun, 28 Feb 2010 02:20:01 -0800 (PST) Received: from [192.168.1.36] (host215-146-dynamic.3-87-r.retail.telecomitalia.it [87.3.146.215]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o1SAJodm012545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Feb 2010 11:19:51 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marcello Caleffi In-Reply-To: Date: Sun, 28 Feb 2010 11:19:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> References: <20100223045634.C3F6328C44F@core3.amsl.com> <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV 0.94.1/10465/Sun Feb 28 02:14:36 2010 on smtp2.unina.it X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 28 Feb 2010 17:46:19 -0800 Cc: MANET IETF , ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 10:20:09 -0000 My two cents. I think that ETX is a better metric than hop count (maybe every not = stupid metric works better then it), however I think that sometimes we = miss the point. The ETX estimates the expected transmission count basing on the delivery = ratios. A lot of works deal with improving the use of the delivery = ratios, but very few deal with improving the delivery ratio estimation, = which is the real key point (as it seems to me by my = simulations/experiments). So, with stupid delivery ratio estimators you = need to differentiate between links with the same ETX metric (in well = connected networks you have a lot of '1' links, while in high = dynamic/delay tolerant networks you have a lot of 'big value' links) = just because these estimators do not do their job. Just as example, generally people use the moving average one (counting = the hello packets received and normalize to the number of hello sent), = which assigns to the sequences '0000011111' and '1111100000' the same = directional delivery ratio (0.5). However, maybe I am boring the list with uninteresting or out-of-topic = considerations , so I stop here. Best, Marcello Il giorno 26/feb/2010, alle ore 18.16, Omprakash Gnawali ha scritto: > We can definitely learn from the experience at Funkfeuer. > Specifically, regarding ETX, it was interesting that there was a need > to represent better than ETX=3D1 links. However, I wonder if it is > better to use different metrics to differentiate these links rather > than overloading the meaning of ETX. It is always good to get insights > from practice on these issues... >=20 > - om_p >=20 >=20 > On 2/22/10, Thomas Heide Clausen wrote: >> Just a FYI: in the [manet] WG, an ETx metrics specification was >> published recently, based on the exhaustive operational experiences >> from the FunkFeuer network: >>=20 >> http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx >>=20 >> I understand that the above I-D is being revised and an update is >> expected shortly. >>=20 >> I thought that it might be useful to cross-post this information -- = it >> would seem that there's both similarity and complementarity here. >>=20 >> (and, for some reason, the only URL for draft-gnawali-roll-etxof that >> I could make work is this: >> https://datatracker.ietf.org/doc/draft-gnawali-roll-etxof/ >> ) >>=20 >> Sincerely, >>=20 >> Thomas >>=20 >>=20 >> On Feb 23, 2010, at 06:03 AM, Omprakash Gnawali wrote: >>=20 >>> ---------- Forwarded message ---------- >>> From: IETF I-D Submission Tool >>> Date: Mon, Feb 22, 2010 at 8:56 PM >>> Subject: New Version Notification for draft-gnawali-roll-etxof-00 >>> To: gnawali@cs.stanford.edu >>> Cc: pal@cs.stanford.edu >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-gnawali-roll-etxof-00.txt has been >>> successfuly submitted by Omprakash Gnawali and posted to the IETF >>> repository. >>>=20 >>> Filename: draft-gnawali-roll-etxof >>> Revision: 00 >>> Title: The ETX Objective Function for RPL >>> Creation_date: 2010-02-22 >>> WG ID: Independent Submission >>> Number_of_pages: 7 >>>=20 >>> Abstract: >>> The ETX metric of a wireless link is the expected number of >>> transmissions required to successfully transmit and acknowledge a >>> packet on the link. The Routing Protocol for Low Power and Lossy >>> Networks (RPL) allows the use of objective functions to construct >>> routes that optimize or constrain a routing metric on the paths. >>> This specification describes ETXOF, an objective function that >>> minimizes ETX. The RPL path computation using ETXOF results in >>> minimum-ETX paths from the nodes to the DAG roots, i.e., paths that >>> minimize the number of packet transmissions for packet delivery from >>> nodes in the network to the DAG root. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From marcello.caleffi@unina.it Sun Feb 28 02:54:17 2010 Return-Path: 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 139063A845C; Sun, 28 Feb 2010 02:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 iqaOJCXfl21B; Sun, 28 Feb 2010 02:54:16 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id EF2B23A7B31; Sun, 28 Feb 2010 02:54:15 -0800 (PST) Received: from [192.168.1.36] (host215-146-dynamic.3-87-r.retail.telecomitalia.it [87.3.146.215]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o1SAs6iE014291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Feb 2010 11:54:07 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marcello Caleffi In-Reply-To: <201002281141.15423.hrogge@googlemail.com> Date: Sun, 28 Feb 2010 11:54:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100223045634.C3F6328C44F@core3.amsl.com> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> <201002281141.15423.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV 0.94.1/10465/Sun Feb 28 02:14:36 2010 on smtp2.unina.it X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 28 Feb 2010 17:46:19 -0800 Cc: ROLL WG , manet@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 10:54:17 -0000 Dear Henning, the exponential moving average is another common estimator for delivey = ratios. And I'm not surprised to read that it performed worse in a fixed = network (in absence of congestion, I suppose). The main issue with the = exponential aging is that the forgetting weight is fixed and it has to = be set by the user, i.e. is not adaptive. The same thing happens for a = biased estimator, until the estimator is not adaptive. You right saying that without more statistics is hard to establish (from = a statistically point of view) which is better among "0000011111" and = "1111100000", however there are adaptive estimators (not too complex in = terms of memory or computational cycles) which can exploits the = correlation among trials. If my whole contact history is composed by = 'ones', and I started to receives '0's, is hard to think that nothing = happened. Maybe we could make some experiments in your network. However, the = important thing for me is to discuss about it. Talking about how to use the delivery ratios (i.e. how to compute and = standardize the ETX metric) before to correctly (from an operational, a = statistical and a standardization point of view) compute the delivery = ratios is questionable in my mind. Best, Marcello Il giorno 28/feb/2010, alle ore 11.41, Henning Rogge ha scritto: > Am Sonntag 28 Februar 2010 11:19:50 schrieb Marcello Caleffi: >> My two cents. >> I think that ETX is a better metric than hop count (maybe every not = stupid >> metric works better then it), however I think that sometimes we miss = the >> point. The ETX estimates the expected transmission count basing on = the >> delivery ratios. A lot of works deal with improving the use of the >> delivery ratios, but very few deal with improving the delivery ratio >> estimation, which is the real key point (as it seems to me by my >> simulations/experiments). So, with stupid delivery ratio estimators = you >> need to differentiate between links with the same ETX metric (in well >> connected networks you have a lot of '1' links, while in high >> dynamic/delay tolerant networks you have a lot of 'big value' links) = just >> because these estimators do not do their job. Just as example, = generally >> people use the moving average one (counting the hello packets = received and >> normalize to the number of hello sent), which assigns to the = sequences >> '0000011111' and '1111100000' the same directional delivery ratio = (0.5). >> However, maybe I am boring the list with uninteresting or = out-of-topic >> considerations , so I stop here. > We did some experiments at Freifunk/Funkfeuer with an ETX metric based = on=20 > exponential aging to favor the recent data input, but discovered it = dit not=20 > work well so we got back to a flat average of a certain time interval. = This=20 > works well for our fixed networks, but could be better for mobile = ones. >=20 > It would be an interesting experiment to do the averaging with a = slight bias=20 > towards the new values, but this could have a negative side effect = too. If you=20 > have an fluctuating link you get more fluctiation in the ETX result if = you=20 > favor a small part of your input data. >=20 > A better approach might be to calculate the standard deviation of the = data=20 > points and use this as a penalty for the total link cost to favor = stable links=20 > over unstable one. Without more statistics it's difficult too say that = a=20 > "0000011111" event is better than the "1111100000" event. Both could = just be=20 > the result of an instable and fluctuating link. >=20 > Henning Rogge From marcello.caleffi@unina.it Sun Feb 28 03:34:06 2010 Return-Path: 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 ED30E3A8693; Sun, 28 Feb 2010 03:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 BLd3pU2wBF8w; Sun, 28 Feb 2010 03:34:06 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id C41DB3A86BF; Sun, 28 Feb 2010 03:34:05 -0800 (PST) Received: from [192.168.1.36] (host215-146-dynamic.3-87-r.retail.telecomitalia.it [87.3.146.215]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o1SBUABh023289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Feb 2010 12:30:11 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marcello Caleffi In-Reply-To: <201002281212.54577.hrogge@googlemail.com> Date: Sun, 28 Feb 2010 12:33:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100223045634.C3F6328C44F@core3.amsl.com> <201002281141.15423.hrogge@googlemail.com> <201002281212.54577.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV 0.94/10465/Sun Feb 28 02:14:36 2010 on smtp1.unina.it X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 28 Feb 2010 17:46:19 -0800 Cc: ROLL WG , manet@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 11:34:07 -0000 Il giorno 28/feb/2010, alle ore 12.12, Henning Rogge ha scritto: > Am Sonntag 28 Februar 2010 11:54:06 schrieb Marcello Caleffi: >> Dear Henning, >> the exponential moving average is another common estimator for = delivey >> ratios. And I'm not surprised to read that it performed worse in a = fixed >> network (in absence of congestion, I suppose). The main issue with = the >> exponential aging is that the forgetting weight is fixed and it has = to be >> set by the user, i.e. is not adaptive. The same thing happens for a = biased >> estimator, until the estimator is not adaptive. > Yes, there is no easy way to fix a metric for all cases. >=20 >> You right saying that >> without more statistics is hard to establish (from a statistically = point >> of view) which is better among "0000011111" and "1111100000", however >> there are adaptive estimators (not too complex in terms of memory or >> computational cycles) which can exploits the correlation among = trials. If >> my whole contact history is composed by 'ones', and I started to = receives >> '0's, is hard to think that nothing happened. > Or maybe a bird just got into your transmission path. Better wait a = few=20 > moments before changing the metric output of the algorithm to see if = it was=20 > just a glitch. This is true :). >> Maybe we could make some experiments in your network. > That would be a little bit difficult because Freifunk/Funkfeuer = networks are=20 > distributed over cities and used by their owners to get internet = access. But=20 > we have a limited test setup in Vienna that use a second IP range and = port to=20 > run two OLSR instances on the same hardware. Maybe we can discuss it in private. >> However, the important thing for me is to discuss about it. > One thing we were talking about in Funkfeuer was something we call = "metric=20 > postprocessing". If we have a metric implementation that outputs a=20 > dimensionless metric value, we could add another layer of algorithms = to use=20 > statistics to stabilize and enhance the raw metric output, independant = to the=20 > metric itself. We should discuss about it. Honestly, I don't know if the = post-processing can be independent from the metric dimension, but it = will be a nice idea. >=20 >> Talking about how to use the delivery ratios (i.e. how >> to compute and standardize the ETX metric) before to correctly (from = an >> operational, a statistical and a standardization point of view) = compute >> the delivery ratios is questionable in my mind. > The draft I have sent to the MANET working group is a description of = the=20 > metric we have been using in the Freifunk/Funkfeuer networks for = years. So we=20 > can say "yes, this does work" and "it works thousands times better = than=20 > hopcount". It's not meant as the "final and best approach to ETX", but = it is a=20 > working algorithm to compute a metric with few resources (most of our = hardware=20 > are embedded routers with 200-300 MHz CPUs and 16 MB ram). It's better = to have=20 > a draft like this than to public a routing protocol without any = documented=20 > alternative to hopcount (which does not work) which happened for = OLSRv1. Even=20 > today I hear people on conferences talking about "OLSR does not work, = see our=20 > little trick works better" and using hopcount. Why do they use = hopcount ?=20 > Because the RFC says so. It was not my intention to discuss against your draft. Until we move = towards realistic hypothesis, I am in. But since there are multiple bi-directional connections among the = topics: << I want a routing protocol that works also in non-trivial networks = <---> routing protocols forward the packets according to routing metrics = <---> I need a good routing metric <---> routing metric usually = estimates random processes like delivery ratio or round trip time <---> = I need a good estimator >> here I am just exploiting the opportunity provided by your draft to = discuss some issues outside from my research group. By the way, thank you for your contribute. Marcello=