From 6lowpan-bounces@ietf.org Thu Apr 06 06:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRRg5-0003Qj-MG; Thu, 06 Apr 2006 06:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRRg4-0003Qe-Jp for 6lowpan@ietf.org; Thu, 06 Apr 2006 06:25:24 -0400 Received: from m5-141.126.com ([202.108.5.141] helo=126.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRRfz-000213-AX for 6lowpan@ietf.org; Thu, 06 Apr 2006 06:25:24 -0400 Received: from ecnulihai (unknown [211.144.102.60]) by smtp3 (Coremail) with SMTP id wKgAoE5Av2aK7DREp+KtCQ==.5171S2; Thu, 06 Apr 2006 18:25:15 +0800 (CST) Message-ID: <009901c65964$c2fe3880$78c0a8c0@netlab.cs.ecnu.edu.cn> From: "kevin" To: "6lowpan" <6lowpan@ietf.org> References: <007901c640b8$1403eec0$45706f0a@daniellaptop> Subject: Re: [6lowpan] LOAD Updated Date: Thu, 6 Apr 2006 18:27:46 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0867296415==" Errors-To: 6lowpan-bounces@ietf.org --===============0867296415== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQogICAgSSBoYXZlIGEgZG91YnQgcmVnYXJkaW5nIHRoZSBMT0FEIHNwZWMuIEFu ZCBoZXJlIGlzIHRoZSBkb3VidDoNCiAgICBJbiBTZWN0aW9uIDYuMiBQYWdlIDExLCB0aGUgbGFz dCBMT0FEIGRyYWZ0IHN0YXRlcyB0aGF0ICJVcG9uIHJlY2VpdmluZyBhIFJSRVEsIGFuIGludGVy bWVkaWF0ZSBGRkQgbm9kZSB0cmllcyB0byBmaW5kIHRoZSBlbnRyeQ0KICAgb2YgdGhlIHNhbWUg b3JpZ2luYXRvciBhZGRyZXNzIGFuZCBSUkVRIElEIHBhaXIgaW4gdGhlIHJvdXRlIHJlcXVlc3Qg IHRhYmxlLiAgSWYgdGhlIGVudHJ5IGlzIGZvdW5kLCB0aGUgbm9kZSBqdXN0IGRpc2NhcmRzIHRo ZSBSUkVRLi4iIEkgd29uZGVyIGlmIHRoZSBSUkVRIGNvbnRhaW5zIGEgYmV0dGVyIHJvdXRlIGNv c3QgdGhhbiB0aGUgZXhpc3Rpbmcgb25lIGluIHRoZSByb3V0ZSByZXF1ZXN0IHRhYmxlLCB3aHkg ZG8gd2UgdXNlIHRoZSBuZXcgcm91dGUgaW4gdGhlIFJSRVEgaW5zdGVhZD8gT3IgSSBtaXNzIHNv bWV0aGluZz8NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiU29vaG9uZyBE YW5pZWwgUGFyayIgPHNvb2hvbmdwQGdtYWlsLmNvbT4NClRvOiA8Nmxvd3BhbkBpZXRmLm9yZz4N ClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA3LCAyMDA2IDU6MjUgQU0NClN1YmplY3Q6IFJlOiBbNmxv d3Bhbl0gTE9BRCBVcGRhdGVkDQoNCg0KDQpIZXJlIGlzIGFuIG9mZmljaWFsIHJlbGVhc2U6DQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kYW5pZWwtNmxvd3Bhbi1s b2FkLWFkaG9jLXJvdXRpbmctMDIudHh0DQoNCg0KT24gMy82LzA2LCBTb29ob25nIERhbmllbCBQ YXJrIDxzb29ob25nLnBhcmtAc2Ftc3VuZy5jb20+IHdyb3RlOg0KPiBGb2xrcyAtIExPQUQgKDZM b1dQQU4gQWQgSG9jIE9uLURlbWFuZCBEaXN0YW5jZSBWZWN0b3IgUm91dGluZykNCj4gaGFzIGJl ZW4gdXBkYXRlZCBhbmQgeW91IGNhbiB1c2UgdGhlIGZvbGxvd2luZyBsaW5rcyBiZWZvcmUgaWV0 ZiByZXBvc2l0b3J5Lg0KPg0KPiBodHRwOi8vZGFuaWVsLnZzaXgubmV0L2lldGYvNmxvd3Bhbi9k cmFmdC1kYW5pZWwtNmxvd3Bhbi1sb2FkLWFkaG9jLXJvdXRpbmctMDIudHh0DQo+DQo+IERpZmYg ZnJvbSAwMSB2ZXJzaW9uOg0KPiBodHRwOi8vZGFuaWVsLnZzaXgubmV0L2lldGYvNmxvd3Bhbi9k cmFmdC1kYW5pZWwtNmxvd3Bhbi1sb2FkLWFkaG9jLXJvdXRpbmctMDJfZGlmZi5odG0NCj4NCj4g QW55IGNvbW1lbnRzIGFyZSBoaWdobHkgd2VsY29tZSwNCj4NCj4gU2VlIHlvdSBpbiBEYWxsYXMg c29vbi4NCj4NCj4gRGFuaWVsIChTb29ob25nIERhbmllbCBQYXJrKQ0KPiBNb2JpbGUgQ29udmVy Z2VuY2UgTGFib3JhdG9yeSwgU0FNU1VORyBFbGVjdHJvbmljcy4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNmxvd3BhbiBtYWlsaW5nIGxp c3QNCj4gNmxvd3BhbkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82bG93cGFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo2bG93cGFuIG1haWxpbmcgbGlzdA0KNmxvd3BhbkBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbg0K --===============0867296415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0867296415==-- From 6lowpan-bounces@ietf.org Thu Apr 06 20:33:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FReud-0006Tp-6I; Thu, 06 Apr 2006 20:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FReuc-0006Tk-ER for 6lowpan@ietf.org; Thu, 06 Apr 2006 20:33:18 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FReub-0005Y6-Tc for 6lowpan@ietf.org; Thu, 06 Apr 2006 20:33:18 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k370XH73037014 for <6lowpan@ietf.org>; Thu, 6 Apr 2006 19:33:17 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k370XGpf037013 for 6lowpan@ietf.org; Thu, 6 Apr 2006 19:33:16 -0500 (CDT) (envelope-from salo) Date: Thu, 6 Apr 2006 19:33:16 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604070033.k370XGpf037013@newbsd.saloits.com> To: 6lowpan@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [6lowpan] 6lowpan Thoughts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org A few comments motivated by the format draft, and to some extent the problem draft, follow. The format draft specifies packet formats for a protocol that presumably behaves something like IPv6, but is clearly not IPv6. I think the following diagram may provide a useful model: ----------- ---------- ---------- | 6lowpan | ------\ | Magic | ------\ | IPv6 | | packet | ------/ | Xform1 | ------/ | Packet | ----------- ---------- ---------- I assume that "Magic Xform1" [Magic Transformation 1] really exists. Of course, I think it is pretty easy to conclude that "Magic Xform2" does not exist such that IPv6 Packet1 is identical to IPv6 Packet2. ----------- ---------- ----------- ---------- ----------- | IPv6 | ---\ | Magic | ---\ | 6lowpan | ---\ | Magic | ---\ | IPv6 | | Packet1 | ---/ | Xform2 | ---/ | Packet | ---/ | Xform1 | ---/ | Packet2 | ----------- ---------- ----------- ---------- ----------- This may suggest that we want to be explicit about how Magic Xform1 actually works in detail, such as when an IPv6 packet is received that can't be transformed into a 6lowpan packet without loss of information. Presumably, this is the gateway specification document. ------ I assume that people want use the 6lowpan technologies to build real-world products. Assuming that these products are going to be introduced in this decade, (or, even in our lifetimes), a majority of these products will be connected to an IPv4 Internet. As far as I can tell, the implicit 6lowpan strategy for the real, (i.e., IPv4), world, is the following, (although I don't think this has been written down): ----------- ---------- ---------- --------- ---------- | 6lowpan | ---\ | Magic | ---\ | IPv6 | ---\ | v4/v6 | ---\ | IPv4 | | Packet | ---/ | Xform1 | ---/ | Packet | ---/ | Xform | ---/ | Packet | ----------- ---------- ---------- --------- ---------- I think we explicitly decided to ignore the following architecture: ----------- ---------- ---------- | 6lowpan | ------\ | Magic | ------\ | IPv4 | | packet | ------/ | Xform3 | ------/ | Packet | ----------- ---------- ---------- It seems to me that it would be useful to: o Convince ourselves that the first diagram will actually work, and o Determine whether the second diagram can work or can be made to work. These diagrams may also suggest that we really want to specify in detail how both 6lowpan/IPv6 and 6lowpan/IPv4 gateways ought to work. It is not obvious to me that 6lowpan gateways will all operate the same way, in the absence of a gateway specification. ------ As I have hinted, I think it may be useful to think of the 6lowpan network protocol as a protocol that acts a bit like IPv6 and that has a packet format that can be transformed to and from IPv6 without too much difficulty, (or state). Another advantage of thinking that 6lowpan is something other than IPv6 is that it would speed, (or would have sped), the thought process on the 6lowpan discovery document. Once we consider 6lowpan to be something other than a compressed IPv6, we can ask the question directly: what information, (e.g., provided by the IPv6 discovery processes), do 6lowpan nodes need? But, it is true that we may be arriving at the same answer by asking: how much of the IPv6 discovery processes do we really need? With our current approach, however, we may miss opportunities to reuse procedures that already exist in this environment, and instead simply simulate the IPv6 solution to the same problem. ------ In toto, these comments may suggest the need for a systems-level architecture document. Developing this document would, I believe, help increase the probability that our solution is complete. ------ By the way, I didn't seen any explicit congestion notification (ECN) bit in the format document. Did I miss it, or is it not there. It seems like this might be something we really want. (Again, a system architecture document might provide a forum for us to discuss why ECN is or isn't important.) ------ I would have to reread the problem draft, but I don't think that we were as emphatic as we might be that an important motivation for this work is to enable the interconnection of lowpan networks to the Internet. ------ I don't think we explicitly excluded 6lowpan networks as transit networks. ------ -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 12 02:37:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYxP-0008GS-Sx; Wed, 12 Apr 2006 02:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYxP-0008Ez-BH for 6lowpan@lists.ietf.org; Wed, 12 Apr 2006 02:36:03 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTYxM-0000X6-IS for 6lowpan@lists.ietf.org; Wed, 12 Apr 2006 02:36:03 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IXL00GKMJNV1D@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Wed, 12 Apr 2006 15:35:56 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IXL001JMJNVH4@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Wed, 12 Apr 2006 15:35:55 +0900 (KST) Date: Wed, 12 Apr 2006 15:36:09 +0900 From: Soohong Daniel Park To: 6lowpan <6lowpan@lists.ietf.org> Message-id: <024f01c65dfb$62650580$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [6lowpan] Couple of questions from packet format document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Gabriel - While going through our packet format document, a couple of questions happen in my side...Please clarify them. [1] In section 9.1, this document says " the packet length can be inferred from the layer two"... I am not sure how it can be inferred from the layer two. [2] In section 9.2, UDP source/destination port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 9.3.2). I am not sure what you mean by short_port. I can't see any relevant mention in Section 9.3.2. PS, just curious whether we should consider IPv6 extension from the Next Header perspective. Thanks, Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Apr 14 03:53:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJ6w-00086r-FV; Fri, 14 Apr 2006 03:52:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJ6v-00086m-TG for 6lowpan@lists.ietf.org; Fri, 14 Apr 2006 03:52:57 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUJ6s-0007vn-7L for 6lowpan@lists.ietf.org; Fri, 14 Apr 2006 03:52:57 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IXP007NKCIFXF@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Fri, 14 Apr 2006 16:51:51 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IXP00E19CIF8D@mmp1.samsung.com> for 6lowpan@lists.ietf.org; Fri, 14 Apr 2006 16:51:51 +0900 (KST) Date: Fri, 14 Apr 2006 16:51:54 +0900 From: Soohong Daniel Park To: Schumacher Christian Peter Pii , 6lowpan <6lowpan@lists.ietf.org> Message-id: <04ad01c65f98$4c22e1e0$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49A38D2FE2C53946A57916AD6A1F00D782ED70@DKDN01MX34.danfoss.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [6lowpan] poll for interim meeting locations - result ? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org poll for interim meeting locationsWhat's the result of the thread below ? Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: Schumacher Christian Peter Pii To: 6lowpan Sent: Tuesday, March 28, 2006 10:39 PM Subject: [6lowpan] poll for interim meeting locations Dear 6lowpanners There has been suggested the following locations for a 2-day interim meeting: - Europe: Danfoss A/S, Denmark TZI, Germany - Canada: In connection with WiMAX F2F meeting in Ottawa, May 23-25 - USA: In connection (possibly May 11-12) with IEEE 802 Interim in Jacksonville, May14-19 Please reply your preference to this mail and CC the mailing list, so we can determine the overall preference. Deadline for this poll is Friday 7th of April. Regards Christian Schumacher _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Apr 17 06:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVREt-00015e-EJ; Mon, 17 Apr 2006 06:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVREs-00015P-GG for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 06:45:50 -0400 Received: from mailx.danfoss.com ([193.162.34.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVREq-0006O6-12 for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 06:45:48 -0400 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by mailx.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 12:45:47 +0200 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Mon, 17 Apr 2006 12:45:46 +0200 Received: from dkdn01mx25.danfoss.net ([10.12.129.25]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 12:45:46 +0200 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx25.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 12:45:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Apr 2006 12:45:45 +0200 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D713930D@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll for interim meeting locations - result ? Thread-Index: AcZfmE2kaXExwW89QMyz9YwKZ5VUsgCcll8F References: <49A38D2FE2C53946A57916AD6A1F00D782ED70@DKDN01MX34.danfoss.net> <04ad01c65f98$4c22e1e0$6dc6dba8@daniellaptop> From: "Schumacher Christian Peter Pii" To: "Soohong Daniel Park" , "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 17 Apr 2006 10:45:46.0236 (UTC) FILETIME=[15412BC0:01C6620C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: cabo@tzi.org Subject: [6lowpan] SV: poll for interim meeting locations - result ? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0979975366==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0979975366== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6620C.14DF3B97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6620C.14DF3B97 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all. Sorry for the delay. The poll revealed a few in favor of jacksonville in connection with IEEE = meeting. However, there is a need for a clear agenda for the contents of such a = meeting or else people will have a hard time to justify the expenses = involved. I believe that such an agenda should be formulated by the = chairs of 6lowpan. Since we now are so close to May, it may be difficult to announce the = meeting in due time. Carsten, what are your 5-cents on this and a = possible agenda? Regards Christian -----Oprindelig meddelelse----- Fra: Soohong Daniel Park [mailto:soohong.park@samsung.com] Sendt: fr 4/14/2006 9:51 Til: Schumacher Christian Peter Pii; 6lowpan Emne: poll for interim meeting locations - result ? =20 poll for interim meeting locationsWhat's the result of the thread below = ? Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message -----=20 From: Schumacher Christian Peter Pii=20 To: 6lowpan=20 Sent: Tuesday, March 28, 2006 10:39 PM Subject: [6lowpan] poll for interim meeting locations Dear 6lowpanners=20 There has been suggested the following locations for a 2-day interim = meeting:=20 - Europe:=20 Danfoss A/S, Denmark=20 TZI, Germany=20 - Canada:=20 In connection with WiMAX F2F meeting in Ottawa, May 23-25=20 - USA:=20 In connection (possibly May 11-12) with IEEE 802 Interim in = Jacksonville, May14-19=20 Please reply your preference to this mail and CC the mailing list, so we = can determine the overall preference.=20 Deadline for this poll is Friday 7th of April.=20 Regards=20 Christian Schumacher=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C6620C.14DF3B97 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SV: poll for interim meeting locations - result ?

Dear all.

Sorry for the delay.

The poll revealed a few in favor of jacksonville in connection with IEEE = meeting.
However, there is a need for a clear agenda for the contents of such a = meeting or else people will have a hard time to justify the expenses = involved. I believe that such an agenda should be formulated by the = chairs of 6lowpan.

Since we now are so close to May, it may be difficult to announce the = meeting in due time. Carsten, what are your 5-cents on this and a = possible agenda?

Regards
Christian





-----Oprindelig meddelelse-----
Fra: Soohong Daniel Park [mailto:soohong.park@samsung.com<= /A>]
Sendt: fr 4/14/2006 9:51
Til: Schumacher Christian Peter Pii; 6lowpan
Emne: poll for interim meeting locations - result ?

poll for interim meeting locationsWhat's the result of the thread below = ?

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message -----
From: Schumacher Christian Peter Pii
To: 6lowpan
Sent: Tuesday, March 28, 2006 10:39 PM
Subject: [6lowpan] poll for interim meeting locations


Dear 6lowpanners
There has been suggested the following locations for a 2-day interim = meeting:
- Europe:
        Danfoss A/S, Denmark
        TZI, Germany
- Canada:
        In connection with WiMAX F2F = meeting in Ottawa, May 23-25
- USA:
        In connection (possibly May = 11-12) with IEEE 802 Interim in Jacksonville, May14-19
Please reply your preference to this mail and CC the mailing list, so we = can determine the overall preference.
Deadline for this poll is Friday 7th of April.
Regards
Christian Schumacher





_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf= .org/mailman/listinfo/6lowpan

------_=_NextPart_001_01C6620C.14DF3B97-- --===============0979975366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0979975366==-- From 6lowpan-bounces@ietf.org Mon Apr 17 06:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVRSM-0004U0-Iz; Mon, 17 Apr 2006 06:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVRSL-0004Q8-Py for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 06:59:45 -0400 Received: from mailx.danfoss.com ([193.162.34.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVRSJ-00071O-Px for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 06:59:45 -0400 Received: from DKDN04MX64.dkdn04.danfoss.net ([10.6.2.64]) by mailx.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 12:59:43 +0200 Received: from dkdn01mx22.danfoss.net ([10.12.129.22]) by DKDN04MX64.dkdn04.danfoss.net with InterScan Message Security Suite; Mon, 17 Apr 2006 12:59:43 +0200 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx22.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 12:59:42 +0200 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_01C6620E.07985090" Date: Mon, 17 Apr 2006 12:55:28 +0200 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D787EC08@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: minutes, updated Thread-Index: AcZZhMvG6uR8r4TNTcGOfBGsnyuNlAIh9sGQ From: "Schumacher Christian Peter Pii" To: "Carsten Bormann" , "Geoff Mulligan" X-OriginalArrivalTime: 17 Apr 2006 10:59:42.0393 (UTC) FILETIME=[07A49A90:01C6620E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] FW: minutes, updated X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6620E.07985090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <<6lowpan rev2.txt>> Dear Carsten and Geoff. The cutoff date 21st of April for submitting my revised minutes to "IETF65 Preliminary & Interim Materials" is drawing near.=20 I sent you these minutes on 6th of April, but you have yet to react on them :-(=20 Can I submit these minutes myself? Or how do we proceed? To 6lowpanners: This second version of minutes has not been posted on the mailing list until now, but here you go. Major change is the conversation sections, which are now a bit more narrative and easier to digest. Regards Christian -----Original Message----- From: Schumacher Christian Peter Pii=20 Sent: 6. april 2006 16:17 To: Carsten Bormann; 'Geoff Mulligan' Subject: minutes, updated Importance: High Hi Carsten and Geoff. Here are the new minutes, modified as suggested by Carsten.=20 Regards Christian ------_=_NextPart_001_01C6620E.07985090 Content-Type: text/plain; name="6lowpan rev2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6lowpan rev2.txt" Nmxvd3BhbiBhdCA2NXRoIElFVEYgbWVldGluZyBXRw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KU2xvdDogRnJpLiA5OjAwIC0gMTE6MzANClJvb206IE1vbmV0DQoNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIE5vdGVzIHRha2VuIGJ5Og0KICBDaHJpc3Rp YW4gUGV0ZXIgUGlpIFNjaHVtYWNoZXINCiAgUmFodWwgQy4gU2hhaA0KDQogTWludXRlcyBhc3Nl bWJsZWQgYnk6DQogIENocmlzdGlhbiBQZXRlciBQaWkgU2NodW1hY2hlcg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQoNCih2b2ljZSByZWNvcmRpbmdzIHdlcmUgbm90IHVzZWQg Zm9yIHRoZXNlIG1pbnV0ZXMsIA0KYnV0IHNob3VsZCBiZSBhdmFpbGFibGUgZnJvbSBodHRwOi8v d3d3LmlldGYub3JnKQ0KDQpBZ2VuZGE6IA0KDQogICAgU2VnbWVudHM6DQogICAgDQogICAgICAg IDEuIDA5OjAwIC0gSW50cm8gYW5kIGFnZW5kYSwgQm9ybWFubiAoMTApDQogICAgICAgIDIuIDA5 OjEwIC0gRm9ybWF0IFNwZWMsIE1vbnRlbmVncm8gKDQwKQ0KICAgICAgICAzLiAwOTo1MCAtIFJl Y2hhcnRlcmluZywgQ2hhaXJzICg2MCkNCiAgICAgICAgNC4gMTA6NTAgLSBOZXcgV29yaw0KICAg ICAgICAgICAgYS4gMTA6NTAgLSBORCwgQ2hha3JhYmFydGkvTm9yZG1hcmsgKDI1KQ0KICAgICAg ICAgICAgYi4gMTE6MTUgLSBSb3V0aW5nIHVwZGF0ZXMsIEtpbSAoMTUpDQogICAgICAgICAgICBj LiAxMTozMCAtIFNlcmlhbCBpbnRlcmZhY2luZywgU2FyaWtheWEgKDUpDQogICAgICAgICAgICAN ClNlZ21lbnQgWDoNCg0KICAgIERvY3VtZW50KHMpOg0KICAgICAgICBJLiBEb2N1bWVudCBwcmVz ZW50ZWQgZHVyaW5nIHNlZ21lbnQgWC4NCiAgICAgICAgSUkuIERvY3VtZW50IHByZXNlbnRlZCBk dXJpbmcgc2VnbWVudCBYLg0KICAgICAgICAuLi4NCiAgICANCiAgICBDb252ZXJzYXRpb246DQog ICAgICAgIENvbnZlcnNhdGlvbiBkdXJpbmcgZG9jdW1lbnQgSS4gcHJlc2VudGF0aW9uDQogICAg ICAgIENvbnZlcnNhdGlvbiBkdXJpbmcgZG9jdW1lbnQgSUkuIHByZXNlbnRhdGlvbg0KICAgICAg ICAuLi4NCiAgICAgICAgDQogICAgU3VtbWFyeSBub3RlczoNCiAgICAgICAgQ29uY2x1c2lvbnMg ZnJvbSBzZWdtZW50IFgNCg0KU2VnbWVudCAxLiAwOTowMCAtIEludHJvIGFuZCBhZ2VuZGEsIEJv cm1hbm4gKDEwKQ0KDQogICAgRG9jdW1lbnQocyk6DQoNCiAgICAgICAgSS4gIkNoYWlycycgc2xp ZGVzIiANCiAgICAgICAgaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDZtYXIvc2xp ZGVzLzZsb3dwYW4tNS5wZGYNCiAgICAgICAgDQogICAgQ29udmVyc2F0aW9uOg0KICAgIA0KICAg ICAgICBJLiBTbGlkZSAzIC0gNjV0aCBJRVRGOiA2bG93cGFuIFdHIEFnZW5kYQ0KICAgICAgICAg ICAgDQogICAgICAgICAgICBUaGUgV0cgd2FzIGluZm9ybWVkIHRoYXQgR2FicmllbCBNb250ZW5l Z3JvIHdpbGwgZmluaXNoIHRoZQ0KICAgICAgICAgICAgZm9ybWF0IGRvY3VtZW50Lg0KICAgICAg ICANCiAgICAgICAgSS4gU2xpZGUgNCAtIFdoYXQgaXMgNmxvd3Bhbj8NCiAgICAgICAgIA0KICAg ICAgICAgICAgVGhlIFdHIHdhcyBnaXZlbiBhIHNob3J0IGludHJvZHVjdGlvbiB0byA2bG93cGFu LCB3aGVyZSBpdCB3YXMNCiAgICAgICAgICAgIG1lbnRpb25lZCB0aGF0IHVubGlrZSBvdGhlciBJ UCBvdmVyIGZvbywgNmxvd3BhbiBoYXMgdG8gcmVhY2gNCiAgICAgICAgICAgIGFsbCB0aGUgbm9k ZXMgaW4gdGhlIG5ldHdvcmsuDQogICAgICAgIA0KICAgICAgICBJLiBTbGlkZSA1IC0gNmxvd3Bh biBXaWtpDQogICAgICAgICANCiAgICAgICAgICAgIFRoZSB3aWtpIGh0dHA6Ly82bG93cGFuLnR6 aS5vcmcgd2FzIHByb21vdGVkLg0KICAgICAgICANCiAgICAgICAgSS4gU2xpZGUgNiAtIFdHIHNl Y3JldGFyeQ0KICAgICAgICANCiAgICAgICAgICAgIENocmlzdGlhbiBQZXRlciBQaWkgU2NodW1h Y2hlciB3YXMgdW5vZmZpY2lhbGx5IHNlbGVjdGVkIGFzDQogICAgICAgICAgICBzZWNyZXRhcnkg Zm9yIDZsb3dwYW4uIEl0IGlzIHVub2ZmaWNpYWwgc2luY2UgdGhlIEFEIChNYXJrIFRvd25zbGV5 KQ0KICAgICAgICAgICAgd2Fzbid0IHByZXNlbnQuDQogICAgICAgIA0KICAgICAgICBJLiBTbGlk ZSA3IC0gT3BlbiBNaWxlc3RvbmVzIChmcm9tIFdHIGNoYXJ0ZXIgcGFnZSk6ICAgDQogICAgICAg IA0KICAgICAgICAgICAgVGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0IGlzIGFsbW9zdCBmaW5p c2hlZC4NCiAgICAgICAgDQogICAgU3VtbWFyeSBub3RlczoNCiAgICAgICAgDQogICAgICAgIE5v bmUNCg0KU2VnbWVudCAyLiAwOToxMCAtIEZvcm1hdCBTcGVjLCBNb250ZW5lZ3JvICg0MCk6DQoN CiAgICBEb2N1bWVudChzKToNCg0KICAgICAgICBJLiAiKFNlZ21lbnQgMik6IEZvcm1hdCBzcGVj IHVwZGF0ZSINCiAgICAgICAgaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDZtYXIv c2xpZGVzLzZsb3dwYW4tMi5wcHQNCiAgICAgICAgDQogICAgQ29udmVyc2F0aW9uOg0KICAgICAg ICANCiAgICAgICAgSS4gU2xpZGUgNCAtIFRvIERpc2N1c3MNCiAgICANCiAgICAgICAgICAgIFRo ZSBXRyB3YXMgYXNrZWQgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBzdXBwb3J0DQogICAgICAg ICAgICB1bmljYXN0IGZvciBib3RoIDE2IGFuZCA2NCBiaXQgYWRkcmVzc2VzLiBUaGUgcXVlc3Rp b24gd2FzIG5vdA0KICAgICAgICAgICAgYW5zd2VyZWQsIGFuZCB0aGUgZGlzY3Vzc2lvbiB0aGVu IGV2b2x2ZWQgYXJvdW5kIGhvdyB0aGUgbXVsdGljYXN0DQogICAgICAgICAgICBhZGRyZXNzIG1h cHBpbmcgd29ya3MuIFRoZSBhbnN3ZXIgd2FzIHRoYXQgdGhlIGlkZWEgaXMgc2ltaWxhciB0bw0K ICAgICAgICAgICAgd2hhdCBFdGhlcm5ldCBkb2VzLiBUaGUgbWFwcGluZyBiZXR3ZWVuIEwyL0wz IGFkZHJlc3MgaXMgdGhlIGxhc3QNCiAgICAgICAgICAgIG9jdGV0IG9mIHRoZSBhZGRyZXNzLg0K ICAgIA0KICAgICAgICAgICAgVGhlIHF1ZXN0aW9uIHdhcyByYWlzZWQgd2hldGhlciA2NCBiaXQg bXVsdGljYXN0IHNob3VsZCBiZQ0KICAgICAgICAgICAgc3VwcG9ydGVkLiBObyBjb25jbHVzaW9u Lg0KICAgICAgICAgICAgDQogICAgICAgICAgICBBbiBpZGVhIHdhcyByYWlzZWQgdG8gY2FydmUg dXAgc29tZSBhZGRyZXNzIHNwYWNlLCBkZXNpZ25hdGVkDQogICAgICAgICAgICBmb3IgbXVsdGlj YXN0LCB1bmljYXN0IGFuZCByZXNlcnZlZCAoYW55Y2FzdCAvIG11bWJsZWNhc3QgZXRjLikNCiAg ICAgICAgICAgIGFkZHJlc3Nlcy4gVGhlcmUgd2FzIHNvbWUgY29uY2VybiB3aGV0aGVyIGl0IG1h a2VzIHNlbnNlIHRvIA0KICAgICAgICAgICAgaGFyZHdpcmUgdGhpcyBzcGFjZSByaWdodCBub3cs IGFuZCBpdCB3YXMgcG9pbnRlZCBvdXQgdGhhdCBtYXliZQ0KICAgICAgICAgICAgYSBzZXBlcmF0 ZSBkb2N1bWVudCBjb3VsZCBkZWZpbmUgdGhpcyBhZGRyZXNzIHNwYWNlIHN0cnVjdHVyZS4gDQoN CiAgICBTdW1tYXJ5IG5vdGVzOg0KICAgIA0KICAgICAgICBMYXRlc3QgY2hhbmdlczoNCg0KICAg ICAgICAgICogSW50ZXJmYWNlIGlkZW50aWZpZXIgZGVyaXZhdGlvbiCWIDE2IHplcm8gYml0czog UEFOIElEOiAxNiBiaXQNCiAgICAgICAgICAgIHNob3J0IGFkZHJlc3MNCiAgICAgICAgICAgIA0K ICAgICAgICAgICogV29yayBvZiBjYXV0aW9uIG9uIHRoZSB0cmFuc2llbnQgbmF0dXJlIG9mIDE2 IGJpdCBzaG9ydCBhZGRyZXNzZXMNCiAgICAgICAgICAgIA0KICAgICAgICAgICogUmVhc3NlbWJs eSBub3cga2V5ZWQgb24gZGVzdGluYXRpb24gYW5kIGRhdGFncmFtIHNpemUgcGx1cyB0aGUNCiAg ICAgICAgICAgIHNvdXJjZSBpZCBhbmQgdGFnDQogICAgICAgICAgICANCiAgICAgICAgICAqIE1l c2ggZGVsaXZlcnkgaGVhZGVyIG5vdyBhbGxvd2luZyBhIG1peCBvZiAxNi82NCBiaXQgYWRkcmVz c2VzDQogICAgICAgICAgICAoMSBiaXQgdXNlZCBmb3IgdGhhdCkgbGVhdmluZyA2IGJpdHMgZm9y IGhvcHNfbGVmdC4NCiAgICAgICAgICAgIA0KICAgICAgICAgICogTXVsdGljYXN0IGFkZHJlc3Mg bWFwcGluZyBwYXR0ZXJuZWQgYWZ0ZXIgDQogICAgICAgICAgICBFdGhlcm5ldDogMCAwIDEgMSAw IDAgMSAxIHwgbGFzdF84X2JpdHNfb2ZfSVB2Nl9tY2FzdF9hZGRyDQogICAgICAgICAgICANCiAg ICAgICAgICAgICAgbyBKdXN0IDggYml0cyBmb3IgbXVsdGljYXN0IGFkZHJlc3MgbWF5IGJlIGxl c3MgKENhcnN0ZW4pDQogICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIG8gOCBiaXRzIGNo b3NlbiBmb3IgZWZmaWNpZW5jeSByZWFzb25zIChHYWJyaWVsKQ0KICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICBvIEhhdmUgYSBzZXBhcmF0ZSBhZGRyZXNzIGZvciB0aGUgUEFOIGNvb3Jk aW5hdG9yIChFcmlrKSBvcg0KICAgICAgICAgICAgICAgIGhhdmUgYSByZXNlcnZlZCBhZGRyZXNz IHNwYWNlIHRvIGFsbG93IGZvciBzcGVjaWFsIHRoaW5ncw0KICAgICAgICAgICAgICAgIGxhdGVy IHN1Y2ggYXMgYW55Y2FzdA0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICBvIE5lZWQg YSBzZXBhcmF0ZSBkb2MgdG8gZGVhbCB3aXRoIGFkZHJlc3MgYWxsb2NhdGlvbnMNCiAgICAgICAg ICAgICAgICAoQ2Fyc3RlbikuIEVyaWsgc2FpZCB0aGF0IHdlIHNob3VsZCBub3QgYWxsb2NhdGUg bW9yZSB0aGFuDQogICAgICAgICAgICAgICAgaGFsZiB0aGUgYWRkcmVzc2VzIGF0IHRoZSBiZWdp bm5pbmcgc2luY2UgYWRkaW5nIGxhdGVyIGlzDQogICAgICAgICAgICAgICAgbm90IGRpZmZpY3Vs dCwgYnV0IGdpdmVzIHVzIHJvb20gdG8gd29yay4NCiAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgbyBIYWxmIG9mIGFkZHJlc3Mgc3BhY2UgdG8gdW5pY2FzdC4gMS84dGggdG8gbXVsdGlj YXN0IGFuZA0KICAgICAgICAgICAgICAgIGtlZXAgMy84dGggZm9yIGZ1dHVyZSBhbGxvY2F0aW9u cy4gKENhcnN0ZW6ScyBzdWdnZXN0aW9uKQ0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICog TWVzaCBsYXllciBtY2FzdCBjb3VsZCBtYXAgdG8gdGhpbmdzIGxpa2UgZmxvb2RpbmcsIHVuaWNh c3RpbmcNCiAgICAgICAgICAgIHRvIFBBTiBjb29yZGluYXRvcg0KICAgICAgICAgICAgDQogICAg ICAgICAgKiBBbGwgemVybyBhZGRyZXNzIHNob3VsZCBub3QgYmUgdXNlZCAoMTYgb3IgNjQgYml0 KQ0KICAgICAgICAgICAgDQogICAgICAgIERpc2N1c3Npb24gb24gdW5pY2FzdCBhZGRyZXNzIG1h cHBpbmcgdG8gb3B0aW9uYWxseSBhbGxvdyBib3RoIDE2DQogICAgICAgIGFuZCA2NCBiaXQgYWRk cmVzc2VzOg0KICAgICAgICANCiAgICAgICAgICAqIEhvdyB0byBoYW5kbGUgdHdvIEwyIGFkZHJl c3NlcyB3aXRoIGRpZmZlcmVudCBzdGFiaWxpdHkNCiAgICAgICAgICAgIGNoYXJhY3RlcmlzdGlj cz8NCiAgICAgICAgICAgIA0KICAgICAgICAgICogTm90IHlldCBkaXNjdXNzZWQsIHNvIGxlZnQg b3V0IGZvciBub3cuDQogICAgICAgICAgICANCiAgICAgICAgICAqIENhbiBiZSBwdXQgaW4gZm9y IG5vdyBhbmQgY2FuIGJlIHJpcHBlZCBvdXQgbGF0ZXIgd2l0aG91dCBhDQogICAgICAgICAgICBw cm9ibGVtIGlmIHBlb3BsZSBkbyBub3Qgc2VlIGEgbmVlZCB0byBzdXBwb3J0IDE2IGJpdCBhZGRy ZXNzZXMNCiAgICAgICAgICAgIChFcmlrIGFuZCBDYXJzdGVuKS4NCiAgICAgICAgICAgIA0KU2Vn bWVudCAzLiAwOTo1MCAtIFJlY2hhcnRlcmluZywgQ2hhaXJzICg2MCk6DQoNCiAgICBEb2N1bWVu dChzKToNCg0KICAgICAgICBJLiAiQ2hhaXJzJyBzbGlkZXMiIA0KICAgICAgICBodHRwOi8vd3d3 My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wNm1hci9zbGlkZXMvNmxvd3Bhbi01LnBkZg0KICAgICAg ICANCiAgICAgICAgSUkuICJDaGFpcnMnIHNsaWRlcyBhcyBtb2RpZmllZCBkdXJpbmcgdGhlIG1l ZXRpbmciDQogICAgICAgIGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA2bWFyL3Ns aWRlcy82bG93cGFuLTYucGRmDQogICAgICAgIA0KICAgIENvbnZlcnNhdGlvbjoNCiAgICANCiAg ICAgICAgSS4gJiBJSS4gU2xpZGUgMTEgLSA2bG93cGFuOiBQcm9wb3NlZCBOZXcgQ2hhcnRlciBJ dGVtcw0KICAgICAgICANCiAgICAgICAgICAgIFRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlciBpdGVt cyB3ZXJlIGRlc2NyaWJlZC4NCiAgICAgICAgICAgIEl0IHdhcyBtZW50aW9uZWQgdGhhdCA2bG93 cGFuIG9ubHkgdXNlcyBzdGF0ZWxlc3MgaGVhZGVyDQogICAgICAgICAgICBjb21wcmVzc2lvbiwg YW5kIDZsb3dwYW4gc2hvdWxkIHRoZXJlZm9yZSBhbHNvIGxvb2sgaW50byB0aGUNCiAgICAgICAg ICAgIGV4aXN0aW5nIHdvcmsgb24gc3RhdGVmdWwgaGVhZGVyIGNvbXByZXNzaW9uLiBJdCB3YXMg YWxzbw0KICAgICAgICAgICAgbWVudGlvbmVkIHRoYXQgNmxvd3BhbiBzaG91bGQgZGVmaW5lIHJl Y29tbWVuZGF0aW9ucyBmb3IgcHJvdG9jb2wNCiAgICAgICAgICAgIHNlbGVjdGlvbiBmb3IgYXBw bGljYXRpb25zLCBhbmQgdGhhdCBtZXNoIHJvdXRpbmcgaXMgYSB2ZXJ5DQogICAgICAgICAgICBp bXBvcnRhbnQgdG9waWMgZm9yIDZsb3dwYW4uIEhlIHBvaW50ZWQgb3V0IDZsb3dwYW4gd2lsbCBk byBhbg0KICAgICAgICAgICAgaW5pdGlhbCBzZWN1cml0eSBhbmFseXNpcyAodGhyZWF0cyBhbmQg Z2FwIGFuYWx5c2lzKQ0KICAgICAgICAgICAgICAgIA0KICAgICAgICBJLiAmIElJLiBTbGlkZSAx MiAtIE5ldHdvcmsgU2V0dXAgYW5kIElQdjYgTkQgT3B0aW1pemF0aW9ucyAoUFMpDQogICAgICAg IA0KICAgICAgICAgICAgSXQgd2FzIGRldGVybWluZWQgdGhhdCB0aGUgTkQgb3B0aW1pemF0aW9u cyBkb2N1bWVudCBzaG91bGQgYWxzbw0KICAgICAgICAgICAgbG9vayBhdCBuZXR3b3JrIGJvb3Rz dHJhcHBpbmcuDQogICAgICAgIA0KICAgICAgICBJLiAmIElJLiBTbGlkZSAxMyAtIFByb2JsZW0g c3RhdGVtZW50IHN0YXRlZnVsIEhDIChJbmYpDQogICAgICAgIA0KICAgICAgICAgICAgVGhlIHF1 ZXN0aW9uIHdhcyByYWlzZWQgd2hldGhlciB3ZSBuZWVkIHN0YXRlZnVsIA0KICAgICAgICAgICAg aGVhZGVyIGNvbXByZXNzaW9uIGZvciA2bG93cGFuLiBJdCB3YXMgYW5zd2VyZWQgdGhhdCA2bG9w d2FuDQogICAgICAgICAgICBhc3N1bWUgc3RhdGVmdWwgaXMgdG9vIGNvbXBsZXggZm9yIDZsb3dw YW4sIGdpdmVuIGN1cnJlbnQgUkZDcywNCiAgICAgICAgICAgIGJ1dCB0aGF0IHdlIG5lZWQgdG8g d29yayBvbiB0aGlzIHRvcGljIHRvIGFzc2VydCB0aGF0IGFzc3VtcHRpb24uDQoNCiAgICAgICAg SS4gJiBJSS4gU2xpZGUgMTUgLSBNZXNoIFJvdXRpbmcgKFBTKQ0KDQogICAgICAgICAgICBJRVRG IGhhcyBjcmVhdGVkIGEgYmlnIGh1cmRsZSB3aGljaCBhaW1zIHRvIGRpc2NvdXJhZ2UgcGVvcGxl DQogICAgICAgICAgICBmcm9tIGJ1aWxkaW5nIHRoZWlyIG93biByb3V0aW5nIHByb3RvY29scyB3 aXRoaW4gdGhlIElFVEYuIEdpdmVuDQogICAgICAgICAgICB0aGlzLCA2bG93cGFuIHdpbGwgYXR0 ZW1wdCBub3QgdG8gYnVpbGQgcm91dGluZyBwcm90b2NvbHMgZnJvbQ0KICAgICAgICAgICAgc2Ny YXRjaCBhbmQgcHJlZmVyYWJseSByZWZlcmVuY2Ugd29yayBmcm9tIHRoZSBNQU5FVCBncm91cC4N CiAgICAgICAgICAgIA0KICAgICAgICAgICAgSXQgd2FzIGFza2VkIGlmIElFRUU4MDIuMTUuNCBk b2Vzbid0IHNwZWNpZnkgcm91dGluZyBwcm90b2NvbHMuDQogICAgICAgICAgICBUaGUgcmVwbHkg d2FzIHRoYXQgWmlnQmVlIGRvZXMgKHNvcnQgb2YgQU9EViksIGJ1dCBub3QNCiAgICAgICAgICAg IElFRUU4MDIuMTUuNC4gVGhlIHdvcmsgb2YgWmlnQmVlIGNhbm5vdCBiZSByZWZlcmVuY2VkIGR1 ZSB0bw0KICAgICAgICAgICAgcmVxdWlyZWQgbWVtYmVyc2hpcC4gNmxvd3BhbiBpcyBhbiBvcGVu IHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAgIEl0IHdhcyBhc2tlZCBpZiB0aGUgcm91dGlu ZyB3b3JrIG9mIElFRUU4MDIuMTFzIGNvdWxkIGJlIHVzZWQNCiAgICAgICAgICAgIGluIDZsb3dw YW4uIFRoZSByZXBseSB3YXMgdGhhdCB3ZSBhbHJlYWR5IGRvIHNvbWV0aGluZyANCiAgICAgICAg ICAgIHNpbWlsYXIuDQogICAgICAgICAgICANCiAgICAgICAgICAgIEEgbmV3IHF1ZXN0aW9uIHdh cyByYWlzZWQsIHdoYXQgdGhlIGFjdHVhbCBkaWZmZXJlbmNlDQogICAgICAgICAgICBiZXR3ZWVu IERZTU8vQU9EViBpcy4gVGhlIGFuc3dlciB3YXMgdGhhdCBEWU1PIGluIDZsb3dwYW4gY29udGV4 dA0KICAgICAgICAgICAgaXMgYSBkdW1iZWQgc2ltcGxpZmllZCB2ZXJzaW9uIG9mIEFPRFYsIHdo aWNoIG9wZXJhdGVzIHZlcnkgc2ltaWxhcg0KICAgICAgICAgICAgdG8gb3RoZXIgZHVtYmVkIGRv d24gQU9EVi4gTUFORVQgYnVpbHQgY29yZSBzcGVjIHVwb24gdGhpcyBmb3INCiAgICAgICAgICAg IERZTU8uIERZTU8gbWFpbnRhaW5zIGV4dGVuc2liaWxpdHkgYnV0IGRvZXMgbm90IHJlcXVpcmUg ZXZlcnlvbmUgdG8NCiAgICAgICAgICAgIGRvIHNvLiBUaGVyZWZvcmUgaXQgd2FzIGFsbW9zdCBi dWlsdCBwZXJmZWN0bHkgZm9yIDZsb3dwYW4uDQogICAgICAgICAgICANCiAgICAgICAgICAgIFRo ZSBxdWVzdGlvbiBvZiBEWU1PcyBjb21wYXRhYmlsaXR5IHdpdGggd29yayBvZiBJRUVFODAyLjEx cyB3YXMNCiAgICAgICAgICAgIGFza2VkLiBUaGUgcmVwbHkgd2FzIG1ham9yIGZlYXR1cmUgaXMg cGF0aCBhY2N1bXVsYXRpb24uIFNlY29uZA0KICAgICAgICAgICAgbWFqb3IgZmVhdHVyZSBzdXBw b3J0IG9mIG5vbi1zdXBwb3J0ZWQgb3B0aW9ucywgdHJhbnNtaXNzaW9uIG9mDQogICAgICAgICAg ICB0aGVzZSBhZGRpdGlvbmFsIG9wdGlvbnMuIDZsb3dwYW4gaXMgbm90IGdvaW5nIHRvIGhhdmUg dGhlc2UNCiAgICAgICAgICAgIGFkZGl0aW9uYWwgb3B0aW9ucy4NCg0KICAgICAgICBJLiAmIElJ LiBTbGlkZSAxNSAtIE1lc2ggUm91dGluZyAoUFMpIGNvbnRpbnVlZC4uLg0KICAgICAgICANCiAg ICAgICAgICAgIDZsb3dwYW4gd2lsbCBnaXZlIHJlcXVpcmVtZW50cyB0byBNQU5FVCBncm91cCAo aS5lLiBubyBtdWx0aXBsZQ0KICAgICAgICAgICAgaW50ZXJmYWNlcykuIFRoaXMgc2hvdWxkIGJl IGRvbmUgYmVmb3JlIERZTU8gaXMgc3VibWl0dGVkIGZvcg0KICAgICAgICAgICAgcmV2aWV3LCB3 aGljaCBzaG91bGQgYmUgZW5kIG9mIDIwMDYNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgRFlN TyBpcyBjb21wbGV0ZWx5IGFwcGxpY2FibGUgZm9yIDZsb3dwYW4gaWYgb25lIG1vZGlmaWVzIHRo ZQ0KICAgICAgICAgICAgYWRkcmVzcyBhbmQgdXNlIEwyIGluc3RlYWQgTDMuIEhvdyA2bG93cGFu IHJlZmVyZW5jZXMgaXQgDQogICAgICAgICAgICBub3JtYXRpdmVseSBpcyBhbiBhcmVhIHdoZXJl IHRoZSBXRyBtdXN0IHRhbGsgdG8gSUVTRywgdG8NCiAgICAgICAgICAgIGZyYW1lIGFyZ3VtZW50 IGluIGNvcnJlY3Qgd2F5Lg0KDQogICAgICAgICAgICBJdCB3YXMgbWVudGlvbmVkIHRoYXQgTUFO RVQgaGFzIGRvbmUgYSBsb3Qgb2Ygd29yayBvbiByZWR1Y2luZw0KICAgICAgICAgICAgZHVwbGlj YXRlIHBhY2tldCB0cmFuc21pc3Npb24gYW5kIG5vbi10cmVlIGJhc2VkIG11bHRpY2FzdA0KICAg ICAgICAgICAgc29sdXRpb25zLiBBIHJlZHVjZWQgcmVsYXktc2V0IGlzIHJlY29tbWVuZGVkIGZv ciA2bG93cGFuLA0KICAgICAgICAgICAgd2hpY2ggbWVhbnMgb25seSBjZXJ0YWluIG5vdGVzIHJl dHJhbnNtaXQgcGFja2V0cyBpbnN0ZWFkIG9mIA0KICAgICAgICAgICAgZXZlcnkgc2luZ2xlIG5v ZGUuIA0KDQogICAgICAgIEkuICYgSUkuIFNsaWRlIDE2IC0gU2VjdXJpdHkgQW5hbHlzaXMgKElu ZikNCiAgICAgICAgDQogICAgICAgICAgICA2bG93cGFuIHdpbGwgbG9vayBhdCBzZWN1cml0eSwg YmV5b25kIGJlaW5nIGdvb2QgSUVURiBjaXRpemVucywgDQogICAgICAgICAgICBhbmQgZXhwbGFp biBkaWZmZXJlbnQgYXBwcm9hY2hlcyB0byBlbnN1cmUgc3R1ZmYgd2lsbCBhY3R1YWxseQ0KICAg ICAgICAgICAgd29yay4NCiAgICAgICAgDQogICAgICAgIEkuICYgSUkuIFNsaWRlIDE3IC0gTWls ZXN0b25lcw0KDQogICAgICAgICAgICBNaWxlc3RvbmVzIGFyZSBleHBlY3RlZCB0byBiZSBmaW5p c2hlZCBieSBEZWNlbWViZXIgMjAwNi4NCiAgICAgICAgICAgIFRoZSBjaGFpcnMgYXNrZWQgaWYg cGVvcGxlIGFncmVlZCBvbiB0aGUgY3VycmVudCBjaGFydGVyDQogICAgICAgICAgICBzdWdnZXN0 aW9uLiBBIHF1ZXN0aW9uIHdhcyByYWlzZWQgd2hldGhlciB0aGUgd29yayBkb25lIGJ5IHRoZQ0K ICAgICAgICAgICAgYXV0b2NvbmZpZyBncm91cCByZWdhcmRpbmcgY29uZmlndXJhdGlvbiBvZiBN QU5FVHMgY291bGQgYmUNCiAgICAgICAgICAgIGFwcGxpY2FibGUsIGFuZCByZWR1Y2Ugb3VyIGNo YXJ0ZXIuIFRoZSByZXBseSB3YXMgdGhhdCB0aGUgd29yaw0KICAgICAgICAgICAgb2YgYXV0b2Nv bmYgaXMgYmVjYXVzZSBMMyBNQU5FVCBkZWZpbmVkIG5vdCB0byBoYXZlIGFuIElQLWxpbmsNCiAg ICAgICAgICAgIG1vZGVsIGNvbnNpc3RlbnQgd2l0aCBFdGhlcm5ldCByZWZlcmVuY2UgYW5kIHRo ZXJlZm9yZSA2bG93cGFuDQogICAgICAgICAgICBkb24ndCBuZWVkIHRvIGRvIGFueXRoaW5nIHNw ZWNpYWwuIEl0IHdhcyBwb2ludGVkIG91dCB0aGF0DQogICAgICAgICAgICA2bG93cGFuIG1pZ2h0 IGJlbmVmaXQgZnJvbSByZWZlcmluY2luZyBhIG11bHRpLWxpbmsgZHJhZnQNCiAgICAgICAgICAg IGJ5IFRheWxvci4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgVGhlIGNoYXJ0ZXIgdG9waWMg b24gcmVjb21tZW5kYXRpb25zIGZvciBhcHBsaWNhdGlvbnMgbWVudGlvbnMNCiAgICAgICAgICAg IFRDUC4gSXQgd2FzIG1lbnRpb25lZCB0aGF0IFRDUCBpcyByZWdhcmRlZCBhcyBhIGJhZCBzb2x1 dGlvbg0KICAgICAgICAgICAgaW4gNmxvd3Bhbi4gVGhlIHJlcGx5IHRvIHRoaXMgaXMgdGhhdCA2 bG93cGFuIHdpbGwgbm90IGRvIG5ldw0KICAgICAgICAgICAgdHJhbnNwb3J0IHByb3RvY29scy4g Nmxvd3BhbiBkZWZpbmUgcmVxdWlyZW1lbnRzLCBidXQgd2lsbCBub3QgDQogICAgICAgICAgICBk byB0aGUgYWN0dWFsIHR1bmluZyBvZiB0aGUgcHJvdG9jb2xzLg0KDQogICAgICAgICAgICBUaGUg aXNzdWUgb2Ygd2hldGhlciA2bG93cGFuIHNob3VsZCBhbHNvIGNvbnNpZGVyIGRvY3VtZW50aW5n DQogICAgICAgICAgICBob3cgdG8gbWVyZ2UgbXVsdGlwbGUgNmxvd3BhbnMgd2FzIHJhaXNlZC4g T25lIHJlcGx5IHdhcyB0aGF0DQogICAgICAgICAgICBpcyBhIGdlbmVyaWMgTkQgcHJvYmxlbSwg YW5kIHRoYXQgc3VjaCBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcw0KICAgICAgICAgICAgc2hvdWxk IGJlIHNvbHZlZCBwZW9wbGUgd2hvIG1ha2UgdGhlIHByb2R1Y3RzLg0KICAgICAgICAgICAgDQog ICAgICAgICAgICBJdCB3YXMgbWVudGlvbmVkIHRoYXQgdGhlIFBBTiBjb29yZGluYXRvciBpcyBh IHNpbmdsZS1wb2ludA0KICAgICAgICAgICAgb2YgZmFpbHVyZSBpZiBpdCBmYWlscyBhbmQgbG9z ZXMgdGhlIG1hcHBpbmcgdG8gc2hvcnQgYWRkcmVzc2VzLg0KICAgICAgICAgICAgVGhlIGNvbmNs dXNpb24gd2FzIHRoYXQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgZm9yIDZsb3dwYW4gdG8NCiAg ICAgICAgICAgIGxvb2sgaW50byB0aGlzIHByb2JsZW0sIG9yIDZsb3dwYW4gY291bGQgcmlzayB0 byBlbmQgdXAgd2l0aCBicm9rZW4NCiAgICAgICAgICAgIHNvbHV0aW9ucy4gVGhlIFdHIHdpbGwg YWRkIE5EIGJvb3RzdHJhcHBpbmcgdG8gdGhlIHRvcGljIG9mIE5EDQogICAgICAgICAgICBvcHRp bWl6YXRpb25zLCBpbiBvcmRlciB0byBkZWFsIHdpdGggdGhpcyBwcm9ibGVtIGluIGZ1dHVyZSB3 b3JrLg0KICAgICAgICAgICAgDQogICAgICAgICAgICBJdCB3YXMgc3VnZ2VzdGVkIHRoZSBjaGFy dGVyIHRvcGljcyBzaG91bGQgYmV0dGVyIHJlZmxlY3Qgd2hhdA0KICAgICAgICAgICAgZG9jdW1l bnRzIHdpbGwgYWN0dWFsbHkgYmUgcHJvZHVjZWQsIHNpbmNlIHNvbWUgdG9waWNzIHBvdGVudGlh bGx5DQogICAgICAgICAgICBjb3VsZCBjb3ZlciBtdWx0aXBsZSBkb2N1bWVudHMgKGkuZS4gbWVz aCByb3V0aW5nIG1heSBoYXZlIGJvdGgNCiAgICAgICAgICAgIERZTU8gYW5kIEFPRFYpDQogICAg ICAgICAgICANCiAgICAgICAgICAgIEdhYnJpZWwgTW9udGVuZWdybyB0ZW50YXRpdmVseSB2b2x1 bnRlZXJlZCB0byBsb29rIGF0IGJvb3RzdHJhcHBpbmcNCiAgICAgICAgICAgIGJ1dCBub3QgTkQg Ym9vdHN0cmFwcGluZy4gDQogICAgICAgICAgICANCiAgICAgICAgICAgIDZsb3dwYW5zIHBvdGVu dGlhbCBpbnRlcm9wZXJhYmlsaXR5IHdpdGggWmlnQmVlIHdhcyBkaXNjdXNzZWQuDQogICAgICAg ICAgICBBIHJlY29tbWVuZGF0aW9uIGZvciBhIGJlYWNvbiBleHRlbnNpb24gbWF5IGJlIG5lZWRl ZC4NCiAgICAgICAgICAgIFRoZSBjb25jbHVzaW9uIGlzIHRoYXQgNmxvd3BhbiBtYXkgbmVlZCBh IGRvY3VtZW50IGluIHRoaXMgYXJlYQ0KICAgICAgICAgICAgYW5kIG9uIFJGIGNvLWV4aXN0ZW5j ZS4gDQogICAgICAgICAgICANCiAgICAgICAgICAgIEFmdGVyIHRoZSBmZWVkYmFjayB0aGUgY2hh cnRlciByZWNlaXZlZCBlbm91Z2ggY29uc2Vuc3VzLg0KICAgICAgICAgICAgICAgIA0KICAgICAg ICBJLiAmIElJLiBTbGlkZSAxOCAtIEludGVyaW0/DQoNCiAgICAgICAgICAgIFRoZSBpbnRlcmlt IGluIEphbnVhcnkgd2FzIHByb2R1Y3RpdmUgYW5kIHRoZSBjaGFpcnMgcG9sbGVkIHRoZQ0KICAg ICAgICAgICAgaW50ZXJlc3QgZm9yIGhhdmluZyBhbm90aGVyIGludGVyaW0gaW4gZW5kIG9mIE1h eS4gVGhlcmUgd2FzIA0KICAgICAgICAgICAgZ3JlYXQgY29uc2Vuc3VzIGZvciBoYXZpbmcgYW4g aW50ZXJpbS4gSW4gdGVybXMgb2YgbG9jYXRpb24gDQogICAgICAgICAgICBFdXJvcGUgd2FzIGZh dm9yZWQgb3ZlciB0aGUgVVMuDQogICAgDQogICAgU3VtbWFyeSBub3RlczoNCiAgICANCiAgICAg ICAgUmVjaGFydGVyaW5nOg0KICAgICAgICANCiAgICAgICAgICAqIE5lZWQgdG8gc2VlIHdoYXQg b3RoZXIgcHJvdG9jb2xzIGFuZCBjb21wb25lbnRzIGFyZSBtaXNzaW5nIHRvIG1ha2UNCiAgICAg ICAgICAgIDZsb3dwYW4gYWN0dWFsbHkgd29yayBpbiByZWFsaXR5Lg0KICAgICAgICAgICAgDQog ICAgICAgICAgICAgIG8gTmVpZ2hib3IgZGlzY292ZXJ5IG9wdGltaXphdGlvbnMgKGRvYyBtb3N0 bHkgZXhpc3RzKQ0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgLiBJUHY2IE5E IGlzIHRvbyBleHBlbnNpdmUgYW5kIHJlcXVpcmVzIG11bHRpY2FzdA0KICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgIC4gUHJvcG9zZWQgc29sdXRpb24gdXNlcyAxNS40IG5l dHdvcmsgc3RydWN0dXJlIGFuZCBvYnZpYXRlDQogICAgICAgICAgICAgICAgICAgIG11bHRpY2Fz dCBieSB0YWxraW5nIHRvIGNvb3JkaW5hdG9yDQogICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgLiBDaGFuZ2VkIE5EIG11bHRpY2FzdCBzZW1hbnRpY3MNCiAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAuIERlZmluZSA2bG93cGFuIG5ldHdvcmsgc2V0 dXANCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIG8gU3RhdGVmdWwgaGVhZGVy IGNvbXByZXNzaW9uIChjYW4gd2UgdXNlIGV4aXN0aW5nIElFVEYgc3BlY3Mgb24NCiAgICAgICAg ICAgICAgICB0aGF0PykNCiAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIC4gU3Rh dGVsZXNzIHRvbyBzaW1wbGUgYW5kIHN0YXRlZnVsIG9uZXMgKFJGQyAyNTA3LCBST0hDKSB0b28N CiAgICAgICAgICAgICAgICAgICAgY29tcGxleA0KICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgIC4gRG9jdW1lbnQgcHJvYmxlbSBvZiB3aHkgdGhlIGV4aXN0aW5nIHN0YXRl ZnVsIGFwcHJvYWNoZXMgZG8gbm90DQogICAgICAgICAgICAgICAgICAgIG1ha2Ugc2Vuc2UgZm9y IDZsb3dwYW5zDQogICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICBvIFJlY29tbWVu ZGF0aW9ucyBmb3IgYXBwbGljYXRpb25zIJYgdHJhbnNwb3J0LCBhcHAsIGRpc2NvdmVyeS8NCiAg ICAgICAgICAgICAgICBjb25maWd1cmF0aW9uL2NvbW1pc3Npb25pbmcNCiAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgIC4gRG9jdW1lbnQgcmVsZXZhbnQgY2hvaWNlcw0KICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIC4gVHJhbnNwb3J0IG9wdGlvbnMgaW4g SUVURiCWIHRjcCwgdWRwLCBzY3RwIGFuZCBvbmUgbW9yZT8NCiAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgIG8gTWVzaCByb3V0aW5nDQogICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAuIFByb2JsZW0gaXMgdGhhdCBleGlzdGluZyByb3V0aW5nIHByb3RvY29scyBh cmUgYXQgTDMsIG5lZWQNCiAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nIGF0IEwyDQogICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgLiBXZSBwcm9iYWJseSBzaG91bGQg bm90IGRvIHJvdXRpbmcgcHJvdG9jb2xzIGl0c2VsZiwgYnV0IHVzZQ0KICAgICAgICAgICAgICAg ICAgICBzdHVmZiBmcm9tIE1BTkVUDQogICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgLiBOZWVkIHRvIGRlZmluZSBwYWNrZXQgZm9ybWF0cyBmb3IgYSByb3V0aW5nIHByb3Rv Y29sIHRvIHdvcmsNCiAgICAgICAgICAgICAgICAgICAgd2l0aCA2bG93cGFuDQogICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgLiBXZSBoYXZlIGFuIEFPRFYgYWRhcHRhdGlv biBpbiBkcmFmdCByaWdodCBub3cNCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAuIERZTU8gY291bGQgYmUgYW5vdGhlciBjaG9pY2UgliBoYXMgZmVhdHVyZXMgb2YgQU9E ViBhbmQgRFNSDQogICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgLiBQcm9m LiBLaW0gcHJlc2VudGVkIHNvbWUgcm91dGluZyBvcHRpbWl6YXRpb25zDQogICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDogVXNlIDY0IG9yIDE2IGJpdCBhZGRyZXNz ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDogVXNl IHByb3QtdHlwZSBmaWVsZCB0byBpbmRpY2F0ZSBBT0RWIGNvbnRyb2wgbWVzc2FnZXMNCiAgICAg ICAgICAgICAgICAgICAgICAgIHJhdGhlciB0aGFuIFVEUCBwb3J0cw0KICAgICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgOiBSb3V0ZSBjb3N0IGNhbiB1dGlsaXpl IHRoZSBMUUkgIG9mIHRoZSBQSFkgbGF5ZXINCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgIDogUmF0aGVyIHRoYW4gdXNpbmcgk0hlbGxvlCBtZXNzYWdlcyBv ZiBBT0RWLCAgdXNlIDE1LjQgbGluaw0KICAgICAgICAgICAgICAgICAgICAgICAgbGF5ZXIgbWVj aGFuaXNtcyBzdWNoIGFzIEFDS3MsIGJlYWNvbiByZXNwb25zZXMgZXRjLg0KICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgOiBNaW5pbWl6ZSBwb3dlciBjb25z dW1wdGlvbiBhbmQgY29tcGxleGl0eToNCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAtIERvIG5vdCB1c2UgZGVzdGluYXRpb24gc2VxdWVuY2UgbnVt YmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgIC0gT25seSBhbGxvdyBhIGRlc3RpbmF0aW9uIHRvIHJlcGx5IHRvIFJSRVEgKHRvIHByZXZl bnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICByb3V0aW5nIGxvb3BzKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAtIERvIG5vdCB1 c2UgbG9jYWwgcmVwYWlyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgIC0gUmVwb3J0IGJhY2sgdG8gdGhlIG9yaWdpbmF0b3IgYnkgUkVSUiB1 cG9uIGEgbGluaw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgIC0gRG8gbm90IG1h aW50YWluIHRoZSBwcmVjdXJzb3IgbGlzdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAtIFV0aWxpemUgZWZmaWNpZW50IFJFUlIgcmVwb3J0 aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg OiBSZXVzZSBleGlzdGluZyBzcGVjcyBzdWNoIGFzIEFPRFYgYW5kIERZTU8gYXMgbXVjaCBhcw0K ICAgICAgICAgICAgICAgICAgICAgICAgcG9zc2libGUNCiAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgLiBUcnlpbmcgdG8gdXNlIE1BTkVUIHNwZWNzIG1heSBub3Qg Zml0IHRpbWVsaW5lIChHZW9mZikNCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAuIFdlIGNhbiB1c2UgYSBNQU5FVCBwcm90b2NvbCBsaWtlIERZTU8gd2hpY2ggaXMgZGly ZWN0bHkNCiAgICAgICAgICAgICAgICAgICAgYXBwbGljYWJsZSwgZXhjZXB0IHRoYXQgdGhlIElQ IGFkZHJlc3NlcyBuZWVkIHRvIGJlIGNoYW5nZWQNCiAgICAgICAgICAgICAgICAgICAgdG8gSUVF RSBhZGRyZXNzZXMuIENhbiB3ZSByZWZlcmVuY2UgdGhlIERZTU8gc3BlYyBub3JtYXRpdmVseT8N CiAgICAgICAgICAgICAgICAgICAgVGhhdCBpcyBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBk aXNjdXNzZWQgd2l0aCBJRVNHLCBJQUINCiAgICAgICAgICAgICAgICAgICAgZXRjLg0KICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIC4gSWFuIG1lbnRpb25lZCB0aGF0IE1B TkVUIGlzIGFsc28gd29ya2luZyBvbiBhIHByb2FjdGl2ZQ0KICAgICAgICAgICAgICAgICAgICBw cm90b2NvbCwgYSBub24tdHJlZSBiYXNlZCBtdWx0aWNhc3QgcHJvdG9jb2wsIHdoaWNoIGFyZSBh bG1vc3QNCiAgICAgICAgICAgICAgICAgICAgZGlyZWN0bHkgYXBwbGljYWJsZSB0byA2bG93cGFu Lg0KICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgbyBTZWN1cml0eSBhbmFseXNp cw0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgLiBTZWN1cml0eSBpbiBsb3dw YW5zIGlzIGhhcmQNCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAuIERl ZmluZSB0aHJlYXQgbW9kZWwNCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAuIERvY3VtZW50IHN1aXRhYmlsaXR5IG9mIGV4aXN0aW5nIGtleSBtYW5hZ2VtZW50IHNjaGVt ZXMNCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAuIERpc2N1c3MgYm9v dHN0cmFwcGluZy9pbnN0YWxsYXRpb24vY29tbWlzc2lvbmluZy9zZXR1cCBpc3N1ZXMNCiAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAuIE5lZWQgdG8gbG9vayBhdCBEYXZl IFRheWxvcpJzIGRyYWZ0IChHYWJlKQ0KICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgbyBOZXcgc3VnZ2VzdGlvbiCWIEhvdyBzZXBhcmF0ZSA2bG93cGFucyBjYW4gam9pbiB0b2dl dGhlciAoR2VvZmYpPw0KICAgICAgICAgICAgICAgIEludGVyLVBBTiByb3V0aW5nLCBQQU4gbWVy Z2luZyBhbmQgcGFydGl0aW9uLg0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICogQ2FuIHdl IGRvIHRoZXNlIDUgaXRlbXMgYW5kIGZpbmlzaCB0aGlzIHJvdW5kIGluIERlYyAwNj8NCg0KICAg ICAgICBDaGFydGVyOg0KICAgIA0KICAgICAgICAgIFBTOiBwcm9wb3NlZCBzdGFuZGFyZA0KICAg ICAgICAgIEluZjogSW5mb3JtYXRpb25hbCBkb2N1bWVudA0KICAgICAgIA0KICAgICAgICAgICog Nmxvd3BhbiBCb290c3RyYXBwaW5nIChQUykgYW5kIDZsb3dwYW4gSVB2NiBORCBvcHRpbWl6YXRp b25zIChQUykNCiAgICAgICAgICAgIA0KICAgICAgICAgICogUHJvYmxlbSBzdGF0ZW1lbnQgc3Rh dGVmdWwgaGVhZGVyIGNvbXByZXNzaW9uIChJbmYpDQogICAgICAgICAgICANCiAgICAgICAgICAq IFJlY29tbWVuZGF0aW9ucyBmb3IgNmxvd3BhbiBhcHBsaWNhdGlvbnMgKEluZikNCiAgICAgICAg ICAgIA0KICAgICAgICAgICAgICBvIFRyYW5zcG9ydCwgYXBwLCBkaXNjb3ZlcnkvY29uZmlndXJh dGlvbi9jb21taXNzaW9uaW5nDQogICAgICAgICAgICAgICAgDQogICAgICAgICAgKiA2bG93cGFu IG1lc2ggcm91dGluZyAobiB4IFBTKQ0KICAgICAgICAgICAgDQogICAgICAgICAgKiA2bG93cGFu IHNlY3VyaXR5IGFuYWx5c2lzIChJbmYpDQogICAgICAgICAgICANCiAgICAgICAgRnV0dXJlIG1l ZXRpbmdzOg0KICAgICAgICANCiAgICAgICAgICAqIDIgbW9yZSBJRVRGIG1lZXRpbmdzIHRoaXMg eWVhciAoSnVseSBhbmQgTm92KQ0KICAgICAgICAgIA0KICAgICAgICAgICogSW50ZXJpbSBtZWV0 aW5nPyANCiAgICAgICAgICANCiAgICAgICAgICAgICAgbyBFbmQgb2YgTWF5DQogICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICBvIFR3byBkYXlzDQogICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICBvIEV1cm9wZQ0KDQoNClNlZ21lbnQgNC4gMTA6NTAgLSBOZXcgV29yazoNCg0KICAgIERv Y3VtZW50KHMpOg0KDQogICAgICAgIEkuLiAoU2VnbWVudCA0KTogSVB2NiBORCBvcHRpbWl6YXRp b24NCiAgICAgICAgaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDZtYXIvc2xpZGVz LzZsb3dwYW4tMS5wZGYNCiAgICAgICAgDQogICAgICAgIElJLiAoU2VnbWVudCA0KTogTE9BRCB1 cGRhdGUNCiAgICAgICAgaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDZtYXIvc2xp ZGVzLzZsb3dwYW4tNC5wcHQNCg0KICAgIENvbnZlcnNhdGlvbjoNCiAgICANCiAgICANCiAgICAg ICAgSS4uIChTZWdtZW50IDQpOiBJUHY2IE5EIG9wdGltaXphdGlvbg0KICAgICAgICA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQogICAgICAgIEkuLiBTbGlkZSA5IC0g TDIgTWVzaCBUb3BvbG9neSBTdXBwb3J0DQogICAgICAgIA0KICAgICAgICAgICAgVGhlIHRvcG9s b2d5IGhhcyBhIHNpbXBsZSBhc3N1bXB0aW9uOg0KICAgICAgICAgICAgUEFOIGNvb3JkaW5hdG9y IGlzIElQdjYgcm91dGVyLg0KDQogICAgICAgIEkuLiBTbGlkZSAxMyAtIEF2b2lkIG11bHRpY2Fz dCBEQUQNCiAgICAgICAgDQogICAgICAgICAgICBTZWN1cml0eSBpcyBpbXBvcnRhbnQsIGJ1dCB3 ZSB3aWxsIG5vdCByZWludmVudCB0aGUgZmxhdm9yIG9mIFNFTkQuDQoNCiAgICAgICAgSS4uIFNs aWRlIDE2IC0gTWluaW1pemUgdW5pY2FzdCBOVUQ/DQogICAgICAgIA0KICAgICAgICAgICAgQSBx dWVzdGlvbiB3YXMgcmFpc2VkIHdoZXRoZXIgdGhlIHNlbWFudGljcyBhcmUgY2hhbmdlZCANCiAg ICAgICAgICAgIHdpdGggcmVnYXJkcyB0byB0aGUgTmVpZ2hib3IgQ2FjaGUgZW50cnkuIEl0IHdh cyBjbGFyaWZpZWQNCiAgICAgICAgICAgIHRoZXJlIGlzIG5vIGNhY2hlIGJ1dCBhbiBhdXRob3Jp dGF0aXZlIGxpc3Qgb2YgbmVpZ2hib3JzLg0KDQogICAgICAgIEkuLiBTbGlkZSAxNyAtIEhvdyBk b2VzIHJvdXRlciBrbm93IGFsbCBob3N0cz8NCiAgICAgICAgDQogICAgICAgICAgICBJZiBhIGhv c3QgaGFzIG11bHRpcGxlIElQdjYgYWRkcmVzcywgaXQgbWlnaHQgbm90IGJlIHJlYWNoYWJsZSBi eSANCiAgICAgICAgICAgIHR3byBkaWZmZXJlbnQgYWRkcmVzc2VzLiBBIHNlbmRlciBjYW4gZG8g bm90aGluZyBhYm91dCB0aGF0LiBJZiBpdA0KICAgICAgICAgICAgaGFzIGEgVENQIGNvbm5lY3Rp b24gd2l0aCB1bmRlcmx5aW5nIE5VRCwgVENQIHdvdWxkIGhhcHBpbHkgcmVjYXN0DQogICAgICAg ICAgICB1bnRpbCBUQ1AgZ2l2ZXMgdXAuIElQIGxheWVyIGNhbiBkbyBub3RoaW5nIGFib3V0IGZh Y3QgdGhhdA0KICAgICAgICAgICAgcmVjaXBpZW50IGhhcyBvdGhlciBhZGRyZXNzLiANCg0KICAg ICAgICAgICAgQSBob3N0IG11c3QgYXNzdW1lIGl0IGlzIGRlYWQgdW50aWwgaXQgaGVhcnMgYSBy b3V0ZXIuIFRoZSBXRw0KICAgICAgICAgICAgc2hvdWxkIG1hbmRhdGUgZXZlcnkgbm9kZSBtYWtl cyBhbiBhZGRyZXNzIHJlZ2lzdHJhdGlvbiB0byBhdm9pZA0KICAgICAgICAgICAgYW55IG5vZGUg YXZvaWRzIGRvaW5nIHRoaXMuIFBhcnRpY3VsYXJseSBpbiB0aGUgY2FzZSBvZiAxNiBiaXRzDQog ICAgICAgICAgICBhZGRyZXNzLCByZWxpYWJsZSBhZGRyZXNzIHJlZ2lzdHJhdGlvbiBpcyBuZWVk ZWQuIA0KICAgICAgICANCiAgICAgICAgSUkuIChTZWdtZW50IDQpOiBMT0FEIHVwZGF0ZQ0KICAg ICAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgICAgIA0KICAgICAgICBJSS4g U2xpZGUgMiAtIENoYW5nZSBMb2cNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgSXQgd2FzIG1l bnRpb25lZCB0aGF0IHdoYXRldmVyIHZhbHVlIChMUUkpIHRoZSBXRyBkZWZpbmVzIHNob3VsZCBi ZQ0KICAgICAgICAgICAgbWFudWZhY3R1cmVyIGluZGVwZW5kZW50LiBJdCB3YXMgY29uY2x1ZGVk IHRoYXQgdGhlIGdvYWwgaXMgdG8NCiAgICAgICAgICAgIGRlZmluZSBhIHdlYWsgTFFJIHZhbHVl IHdoaWNoIGlzIG1hbnVmYWN0dXJlciBpbmRlcGVuZGVudC4gSW4gTE9BRA0KICAgICAgICAgICAg dGhlIG1lYXN1cmUgb2YgTFFJIGdpdmVzIHRoZSBvcHRpb24gb2YgYXQgbGVhc3QgYXZvaWRpbmcg dGhlIHdlYWsNCiAgICAgICAgICAgIExRSSwgd2hpY2ggaXMgYSBjb25zZXJ2YXRpdmUgYXBwcm9h Y2guDQogICAgICAgICAgICANCiAgICAgICAgSUkuIFNsaWRlIDMgLSBQcm90b3R5cGUgSW1wbGVt ZW50YXRpb24NCiAgICAgICAgDQogICAgICAgICAgICBIaS1sb3cgbm90IGNvbnNpZGVyZWQgaW4g Nmxvd3BhbiByaWdodCBub3cNCiAgICAgICANCiAgICBTdW1tYXJ5IG5vdGVzOg0KICAgIA0KICAg ICAgICA2bG93cGFuIEFPRFYgliBMT0FEIChQcm9mLiBLaW0pOg0KICAgICAgICANCiAgICAgICAg ICAqIERlZmluZSByb3V0ZSBjb3N0IGJ5IExRSSBhbmQgd2VhayBsaW5rcywgdXNlIGhvcCBjb3Vu dHMgd2hpbGUNCiAgICAgICAgICAqIGF2b2lkaW5nIHdlYWsgbGlua3MNCiAgICAgICAgICAgIA0K ICAgICAgICAgICogU2V2ZXJhbCBjb21tZW50czoNCiAgICAgICAgICAgIA0KICAgICAgICAgICAg ICBvIERlZmF1bHQgdmFsdWUgb2Ygd2VhayBMUUkNCiAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgbyBOZWVkIHNlcXVlbmNlIG51bWJlciB0byBwcmV2ZW50IHJvdXRpbmcgbG9vcHMNCiAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgbyBJbnRlcmFjdGlvbiBiZXR3ZWVuIFFvUyBt ZXRyaWMgYW5kIGRpc3RhbmNlIHZlY3RvciByb3V0aW5nDQogICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgIG8gTGlmZXRpbWUgZGVmaW5pdGlvbg0KICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICBvIExpbmsgbW9uaXRvcmluZyAocm91dGUgdGltZW91dCBieSB0aW1lcnM/KQ0KICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICBvIFdlYWsgbGluayBpbmRpY2F0b3IgYnkgTFFJ DQogICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIG8gVW5pZGlyZWN0aW9uYWwgbGlua3MN CiAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgbyBSRVJSIGZvciBsb3cgYmF0dGVyeSBh bmQgk3JvdXRlIGNvc3Qgbm90IHN1cHBvcnRlZJQgc2hvdWxkIGJ5DQogICAgICAgICAgICAgICAg YXZvaWRlZA0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICogUHJvdG90eXBlIGltcGxlbWVu dGF0aW9uDQogICAgICAgICAgICANCiAgICAgICAgICAgICAgbyBodHRwOi8vd3d3LjZsb3dwYW4u b3JnDQogICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIG8gVGVzdGJlZCBpbXBsZW1lbnRh dGlvbg0KDQoNCg0KDQo= ------_=_NextPart_001_01C6620E.07985090 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C6620E.07985090-- From 6lowpan-bounces@ietf.org Mon Apr 17 10:31:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUlF-00042T-St; Mon, 17 Apr 2006 10:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUlE-00042O-G4 for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 10:31:28 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUlD-0001AM-61 for 6lowpan@lists.ietf.org; Mon, 17 Apr 2006 10:31:28 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k3HEVLEG011187; Mon, 17 Apr 2006 08:31:21 -0600 (MDT) From: Geoff Mulligan To: Schumacher Christian Peter Pii In-Reply-To: <49A38D2FE2C53946A57916AD6A1F00D787EC08@DKDN01MX34.danfoss.net> References: <49A38D2FE2C53946A57916AD6A1F00D787EC08@DKDN01MX34.danfoss.net> Content-Type: text/plain Date: Mon, 17 Apr 2006 08:31:24 -0600 Message-Id: <1145284284.9167.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Carsten Bormann , 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Re: FW: minutes, updated X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I sent a reply saying i thought that they looked fine and asking how to "post" them - Carsten has done this in the past. geoff On Mon, 2006-04-17 at 12:55 +0200, Schumacher Christian Peter Pii wrote: > <<6lowpan rev2.txt>> Dear Carsten and Geoff. > > The cutoff date 21st of April for submitting my revised minutes to > "IETF65 Preliminary & Interim Materials" is drawing near. > > I sent you these minutes on 6th of April, but you have yet to react on > them :-( > Can I submit these minutes myself? Or how do we proceed? > > To 6lowpanners: > This second version of minutes has not been posted on the mailing list > until now, but here you go. > Major change is the conversation sections, which are now a bit more > narrative and easier to digest. > > Regards > Christian > > > -----Original Message----- > From: Schumacher Christian Peter Pii > Sent: 6. april 2006 16:17 > To: Carsten Bormann; 'Geoff Mulligan' > Subject: minutes, updated > Importance: High > > Hi Carsten and Geoff. > > Here are the new minutes, modified as suggested by Carsten. > > Regards > Christian _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 18 15:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvoM-0006zs-ID; Tue, 18 Apr 2006 15:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvoK-0006zn-JD for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 15:24:28 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvoJ-0001YQ-5M for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 15:24:28 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k3IJOOvS004312 for <6lowpan@lists.ietf.org>; Tue, 18 Apr 2006 14:24:24 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k3IJOOkR004311 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 14:24:24 -0500 (CDT) (envelope-from salo) Date: Tue, 18 Apr 2006 14:24:24 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604181924.k3IJOOkR004311@newbsd.saloits.com> To: 6lowpan@lists.ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [6lowpan] Working Group Productivity and Interim Meetings X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I recently reviewed the working group e-mail since the IETF meeting. I found: o 14 e-mails discussing an interim meeting o 3 e-mails discussing the minutes of the IETF meeting o No technical discussion (where a "discussion" requires at least two e-mails) This suggests a couple of things to me: o The working group is not using the e-mail list to make technical progress. o The working group is probably not adequately productive. I strongly urge that we explore how we can make the working group more productive _before_ we conclude that an interim meeting is the most appropriate solution. Let me recommend a couple of potential solutions in an effort to stimulate some thought and discussion: o We should seek to make more productive use of the e-mail list. This is, after all, the IETF. While there are almost 250 people on the mail list, there is a total absence of technical discussion. Why is this? - Do we have the right people on the e-mail list? That is, should there be additional technical personnel actively participating on the list? Presumably, the most likely source of these personnel is companies interested in the success of the working group. - Are most of the people on the e-mail list interested in merely tracking, rather than participating in, the activities [sic] of the working group? - Is there adequate interest within the IETF community to support this working group? If not, how do we generate the necessary interest and recruit the appropriate participants? Having said that, I am concerned about interim meetings becoming the dominant tool of the working group. This grates against the traditional IETF sensitivity to design-by-cabal. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 18 20:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW0gY-0008H6-Fi; Tue, 18 Apr 2006 20:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW0gW-0008Gt-QL for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 20:36:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVzGw-0004ON-AB for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 19:06:14 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVz5Z-0006El-VH for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 18:54:32 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k3IMsS0d005068 for <6lowpan@lists.ietf.org>; Tue, 18 Apr 2006 17:54:28 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k3IMsSqT005067 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 17:54:28 -0500 (CDT) (envelope-from salo) Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604182254.k3IMsSqT005067@newbsd.saloits.com> To: 6lowpan@lists.ietf.org X-Spam-Score: -2.6 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [6lowpan] Working Group Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I started to think about the working group charter, (a topic that appears to have drifted off into the ether since the IETF meeting). I suggest replacing the first three paragraphs of the current working group charter, (i.e., everything down to "The required work includes ...") with the following: - - - - - - The IP over IEEE 802.15.4 Working Group will develop an architecture, protocols, and other technologies that will interconnect IEEE 802.15.4 networks with IPv4 and IPv6 networks. The Working Group will demonstrate independent, interoperable implementations of these standards. IEEE 802.15.4 wireless personal-area networks, (wireless PANs), are dramatically different than the environments in which IP is traditionally deployed. o Many nodes in wireless PANs are severely resource-constrained. Often, these nodes will use eight-bit processors with only a few tens-of-kilobytes of program storage and a few kilobytes of temporary storage. o Many wireless PAN nodes are powered by batteries. As such, each node is able to transmit only a relatively fixed number of bits over its lifetime. The cost of unnecessary network overhead is much higher in battery-powered wireless PANs, because it directly reduces the lifetime of the network. - - - - - - - - A few comments about why I chose the language I did: o As a matter of personal style, I made the language more direct and eliminated a fair amount of verbiage that didn't seem to directly support our cause. o I more explicitly mentioned IEEE 802.15.4. It appears to me that our focus doesn't include any other wireless PAN technology. Yes, our solution should provide a good model for other technologies, but I haven't seen anyone thinking about anything other than 802.15.4. If I'm wrong, someone should say something. o I wanted to remind us that we are, in fact, developing an architecture for wireless PAN/IP interconnections. We are doing this because we largely don't have any models upon which to build. Our current approach is to distribute these architectural design decisions throughout a number of documents, so it is useful to remember that they should cumulatively create a complete, consistent architecture. (My thoughts on the need for an architecture document are left as an exercise for the reader...) o I described our objective as "interconnecting" wireless PANs and IP networks, rather than "running IP over" wireless PANs. I think that the former may provide a stronger motivation for why this work is important. o I believe that we really must develop a solution that gracefully interconnects with both IPv4 and IPv6 networks. Note that this language doesn't specify how this will be done, just that we have to ensure that it works. We may decide to use one or more existing IPv4/IPv6 transition strategies, but we shouldn't just assume that at least one will magically work and ensure interoperability without any thought on our part. o I wanted us to remember that we aren't done until we can demonstrate two independent, interoperable implementations. Of course, from my perspective, these implementations ought to be complete systems, not just bits and pieces, (e.g., a format implementation, a neighbor discovery implementation, etc.). Yes, we all agree that the rest of the charter needs to be revised, but I don't have any proposed language for the rest of the charter (yet). And finally, I don't claim that my suggested language is right, just that we ought to be thinking about this. More free advice from, -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 18 21:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW15d-0004Aa-W9; Tue, 18 Apr 2006 21:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW15d-0004AV-BK for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 21:02:41 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW15b-0002dP-Qa for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 21:02:41 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k3J12cv8005538 for <6lowpan@lists.ietf.org>; Tue, 18 Apr 2006 20:02:38 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k3J12cC4005537 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 20:02:38 -0500 (CDT) (envelope-from salo) Date: Tue, 18 Apr 2006 20:02:38 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604190102.k3J12cC4005537@newbsd.saloits.com> To: 6lowpan@lists.ietf.org Subject: Re: [6lowpan] Working Group Charter In-Reply-To: <200604182254.k3IMsSqT005067@newbsd.saloits.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT) > From: "Timothy J. Salo" > Subject: [6lowpan] Working Group Charter > > ... I suggest replacing the first three paragraphs ... Oops, I forgot a paragraph. > - - - - - - > > IEEE 802.15.4 wireless personal-area networks, (wireless PANs), are > dramatically different than the environments in which IP is > traditionally deployed. > [...] o In many markets, minimizing the cost of wireless PAN nodes is critical. For example, the difference in cost between 32 KB of ROM and 64 KB of ROM may make the difference between a product that is competitive and one that is not. Of course, this extra 32 KB of RAM will reduce the battery life of the node, as well. - - - - - - Sooner or later, someone will figure out that we have no intention of actually implementing IPv6 in wireless PANs, (e.g., mobile IP, IPsec, a bunch of MIBs, etc.). We should be prepared to explain why. [Speaking of MIBs, will wireless PAN/IP gateways have MIBs?] -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 18 22:18:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2HC-0005Uf-6W; Tue, 18 Apr 2006 22:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2HA-0005Pd-C4 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 22:18:40 -0400 Received: from web54710.mail.yahoo.com ([206.190.49.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FW2H8-0006EN-39 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 22:18:40 -0400 Received: (qmail 48579 invoked by uid 60001); 19 Apr 2006 02:18:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yCCbuBG+74Cy8cLpepxqkmUWJoGlU6ZD7XGM7S1x31FRMhP5bgoZEZDiHdbx/WTQO9C4v491PBkStTmaj46zUsebZ8aWFrm/TzveMvpZeE9RZ+uf/10V3xsrVUkuxMgQAzbjQlEG8LEEvHuL1RjEgQAw9j+2UDRpT1Bm6Uo6kxc= ; Message-ID: <20060419021834.48577.qmail@web54710.mail.yahoo.com> Received: from [70.53.126.162] by web54710.mail.yahoo.com via HTTP; Tue, 18 Apr 2006 19:18:34 PDT Date: Tue, 18 Apr 2006 19:18:34 -0700 (PDT) From: Peter Sherbin Subject: Re: [6lowpan] Working Group Charter To: "Timothy J. Salo" , 6lowpan@lists.ietf.org In-Reply-To: <200604190102.k3J12cC4005537@newbsd.saloits.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > Sooner or later, someone will figure out that we have no intention of > actually implementing IPv6 in wireless PANs If this is the case there is hardly any point in developing IPv4 PAN at all. It should be IPv6 only as it was from the start. Peter --- "Timothy J. Salo" wrote: > > Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT) > > From: "Timothy J. Salo" > > Subject: [6lowpan] Working Group Charter > > > > ... I suggest replacing the first three paragraphs ... > > Oops, I forgot a paragraph. > > > - - - - - - > > > > IEEE 802.15.4 wireless personal-area networks, (wireless PANs), are > > dramatically different than the environments in which IP is > > traditionally deployed. > > [...] > > o In many markets, minimizing the cost of wireless PAN nodes > is critical. For example, the difference in cost between > 32 KB of ROM and 64 KB of ROM may make the difference between > a product that is competitive and one that is not. Of course, > this extra 32 KB of RAM will reduce the battery life of the > node, as well. > > - - - - - - > > Sooner or later, someone will figure out that we have no intention of > actually implementing IPv6 in wireless PANs, (e.g., mobile IP, IPsec, > a bunch of MIBs, etc.). We should be prepared to explain why. > > [Speaking of MIBs, will wireless PAN/IP gateways have MIBs?] > > -tjs > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 00:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4Az-0000rj-64; Wed, 19 Apr 2006 00:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4Ax-0000re-HI for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:20:23 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW4Aw-0002TY-6T for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:20:23 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k3J4KLWc018232; Tue, 18 Apr 2006 22:20:21 -0600 (MDT) Subject: Re: [6lowpan] Working Group Charter From: Geoff Mulligan To: "Timothy J. Salo" In-Reply-To: <200604190102.k3J12cC4005537@newbsd.saloits.com> References: <200604190102.k3J12cC4005537@newbsd.saloits.com> Content-Type: text/plain Date: Tue, 18 Apr 2006 22:20:32 -0600 Message-Id: <1145420432.9167.157.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org What do you mean "that we have no intention of actually implementing IPv6 in wireless PANs". We have every intention of implementing IPv6 in wireless PANs! In fact WE (Invensys and some other companies) already have and WE (Invensys) have it deployed in a significant number of homes in pilots in the US right now. I do not agree with the wording for your suggested Charter changes, though I do truly appreciate that someone is starting some sort of exchange on the list. geoff On Tue, 2006-04-18 at 20:02 -0500, Timothy J. Salo wrote: > > Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT) > > From: "Timothy J. Salo" > > Subject: [6lowpan] Working Group Charter > > > > ... I suggest replacing the first three paragraphs ... > > Oops, I forgot a paragraph. > > > - - - - - - > > > > IEEE 802.15.4 wireless personal-area networks, (wireless PANs), are > > dramatically different than the environments in which IP is > > traditionally deployed. > > [...] > > o In many markets, minimizing the cost of wireless PAN nodes > is critical. For example, the difference in cost between > 32 KB of ROM and 64 KB of ROM may make the difference between > a product that is competitive and one that is not. Of course, > this extra 32 KB of RAM will reduce the battery life of the > node, as well. > > - - - - - - > > Sooner or later, someone will figure out that we have no intention of > actually implementing IPv6 in wireless PANs, (e.g., mobile IP, IPsec, > a bunch of MIBs, etc.). We should be prepared to explain why. > > [Speaking of MIBs, will wireless PAN/IP gateways have MIBs?] > > -tjs > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 00:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4Iu-0002Yu-S2; Wed, 19 Apr 2006 00:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4It-0002Yp-8Z for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:28:35 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW4Ir-0002fX-JR for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:28:35 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IXY0056HCFG9D@mailout2.samsung.com> for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:28:28 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IXY00IKWCFGJW@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:28:28 +0900 (KST) Date: Wed, 19 Apr 2006 13:28:42 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] Working Group Charter To: Geoff Mulligan , "Timothy J. Salo" Message-id: <013b01c66369$bd5c3350$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200604190102.k3J12cC4005537@newbsd.saloits.com> <1145420432.9167.157.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > What do you mean "that we have no intention of actually implementing > IPv6 in wireless PANs". We have every intention of implementing IPv6 in > wireless PANs! In fact WE (Invensys and some other companies) already > have and WE (Invensys) have it deployed in a significant number of homes > in pilots in the US right now. Count me as one of 6lowpan-implementor in Aais Pacific. It is about to be widely spreaded around IPv6 world... Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 00:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4NV-0003iT-7X; Wed, 19 Apr 2006 00:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW4NT-0003iO-KT for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:33:19 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW4NS-0002oS-82 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 00:33:19 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k3J4XE2I006199 for <6lowpan@lists.ietf.org>; Tue, 18 Apr 2006 23:33:14 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k3J4XEib006198 for 6lowpan@lists.ietf.org; Tue, 18 Apr 2006 23:33:14 -0500 (CDT) (envelope-from salo) Date: Tue, 18 Apr 2006 23:33:14 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604190433.k3J4XEib006198@newbsd.saloits.com> To: 6lowpan@lists.ietf.org Subject: Re: [6lowpan] Working Group Charter In-Reply-To: <1145420432.9167.157.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > Subject: Re: [6lowpan] Working Group Charter > From: Geoff Mulligan > Date: Tue, 18 Apr 2006 22:20:32 -0600 > > What do you mean "that we have no intention of actually implementing > IPv6 in wireless PANs". We have every intention of implementing IPv6 in > wireless PANs! The working group arguably isn't implementing IPv6 from two perspectives: o I don't think the IETF accepts the notion that implementing a subset of IPv6 is actually implementing IPv6. But, I could be wrong. I may ask this on question on the main IETF mail list. Having said that, the working group intends to implement only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). o The protocol described in the format specification is not IPv6. If you fed it into an IPv6 stack, nothing good would happen. It is, however, a protocol that can easily be transformed into [a subset of] IPv6. > In fact WE (Invensys and some other companies) already have and WE > (Invensys) have it deployed in a significant number of homes in pilots > in the US right now. See above. > I do not agree with the wording for your suggested Charter changes, > though I do truly appreciate that someone is starting some sort of > exchange on the list. Feel free to suggest alternative language and ideas. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 02:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6Ny-00070Q-IZ; Wed, 19 Apr 2006 02:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6Nx-00070L-1p for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 02:41:57 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW6Nv-00013p-MZ for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 02:41:57 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k3J6fs7D018622; Wed, 19 Apr 2006 00:41:54 -0600 (MDT) Subject: Re: [6lowpan] Working Group Charter From: Geoff Mulligan To: "Timothy J. Salo" In-Reply-To: <200604190433.k3J4XEib006198@newbsd.saloits.com> References: <200604190433.k3J4XEib006198@newbsd.saloits.com> Content-Type: text/plain Date: Wed, 19 Apr 2006 00:42:06 -0600 Message-Id: <1145428926.9167.164.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: > > Subject: Re: [6lowpan] Working Group Charter > > From: Geoff Mulligan > > Date: Tue, 18 Apr 2006 22:20:32 -0600 > > > > What do you mean "that we have no intention of actually implementing > > IPv6 in wireless PANs". We have every intention of implementing IPv6 in > > wireless PANs! > > The working group arguably isn't implementing IPv6 from two perspectives: > > o I don't think the IETF accepts the notion that implementing > a subset of IPv6 is actually implementing IPv6. But, I could > be wrong. I may ask this on question on the main IETF mail list. > Having said that, the working group intends to implement > only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). Too bad that we have to rehash this again because you are coming late to this discussion. We dealt with this issue already and the IESG said that an implementation that did not include IPsec and the like was still an implementation of IPv6. > > o The protocol described in the format specification is not > IPv6. If you fed it into an IPv6 stack, nothing good would > happen. It is, however, a protocol that can easily be > transformed into [a subset of] IPv6. If you do not use header compression then an IPv6 packet in the payload of the 6lowpan frame format will work perfectly fine and everything good will happen. The 6lowpan compressed headers are never intended to be passed uncompressed out of a 6lowpan. > > > In fact WE (Invensys and some other companies) already have and WE > > (Invensys) have it deployed in a significant number of homes in pilots > > in the US right now. > > See above. > > > I do not agree with the wording for your suggested Charter changes, > > though I do truly appreciate that someone is starting some sort of > > exchange on the list. > > Feel free to suggest alternative language and ideas. > > -tjs > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 03:35:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW7E9-0002Ii-82; Wed, 19 Apr 2006 03:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW7E7-0002IX-Jx for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 03:35:51 -0400 Received: from agp.stanford.edu ([171.67.73.10] helo=cs-smtp-1.Stanford.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW7E5-00047F-Vy for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 03:35:51 -0400 Received: from c-69-181-71-132.hsd1.ca.comcast.net ([69.181.71.132] helo=[192.168.2.210]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1FW7E3-0002EU-K0; Wed, 19 Apr 2006 00:35:49 -0700 In-Reply-To: <1145428926.9167.164.camel@localhost.localdomain> References: <200604190433.k3J4XEib006198@newbsd.saloits.com> <1145428926.9167.164.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B6DC1D8-D091-4AD6-9664-89AF92DA9704@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] Working Group Charter Date: Wed, 19 Apr 2006 00:37:19 -0700 To: Geoff Mulligan X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -8.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: ae7d61d5ad21aa0d569d6b6c8168eb46 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Apr 18, 2006, at 11:42 PM, Geoff Mulligan wrote: > On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: >>> Subject: Re: [6lowpan] Working Group Charter >>> From: Geoff Mulligan >>> Date: Tue, 18 Apr 2006 22:20:32 -0600 >>> >>> What do you mean "that we have no intention of actually implementing >>> IPv6 in wireless PANs". We have every intention of implementing >>> IPv6 in >>> wireless PANs! >> >> The working group arguably isn't implementing IPv6 from two >> perspectives: >> >> o I don't think the IETF accepts the notion that implementing >> a subset of IPv6 is actually implementing IPv6. But, I could >> be wrong. I may ask this on question on the main IETF mail list. >> Having said that, the working group intends to implement >> only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). > > Too bad that we have to rehash this again because you are coming > late to > this discussion. We dealt with this issue already and the IESG said > that an implementation that did not include IPsec and the like was > still > an implementation of IPv6. >> >> o The protocol described in the format specification is not >> IPv6. If you fed it into an IPv6 stack, nothing good would >> happen. It is, however, a protocol that can easily be >> transformed into [a subset of] IPv6. > > If you do not use header compression then an IPv6 packet in the > payload > of the 6lowpan frame format will work perfectly fine and everything > good > will happen. The 6lowpan compressed headers are never intended to be > passed uncompressed out of a 6lowpan. I might be, as Geoff puts it, merely rehashing old arguments, and if so, I apologize. I don't think there's any question as to whether you can implement IPv6 on 802.15.4. It's a link layer, after all. Sure, the headers might be big, but you can compress them, etc. Even IPSec is possible; without hardware support, it might be an energy nightmare and your crypto time might be the throughput bottleneck, but it's possible, and hardware support could make it not a big deal. If you take the IPv6 over 15.4 route (no pun intended), under the assumption of low-power embedded devices, I'd argue that it's not the data plane that changes, but rather the control plane. E.g., many existing IP routing approaches become problematic, predominantly due to the fact that the assume any-to-any connectivity as an end goal, while in PANs this is less commonly the case. I think this gets to the point raised earlier, of whether the group considers 802.15.4 networks being used as transmit networks, which is a very very important consideration. Coming from the world of TinyOS and sensor networks, I'd argue that it's pretty clear that a set of protocols and mechanisms enabling IP devices to directly communicate with PAN devices would be very useful (why I'm here). The most common case for this is management, as it's a situation where a user definitely wants to talk to a specific *node*, i.e., an address, rather than use some other naming scheme (e.g., "the lights in the living room"). The advantage that a direct IP-level protocol transcoder would provide is that it would preclude the need for application-level protocol stacks to even communicate with nodes within a network. Furthermore, you can begin to use all of the basic IP tricks and techniques when managing these networks (e.g., firewalls). That being said, if the plan is not to push IPv6 into the PAN, then this raises the simple question of what L3 protocols will run within the PAN. Phil http://csl.stanford.edu/~pal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 11:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWEdw-00026d-HM; Wed, 19 Apr 2006 11:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWEdu-00026Y-U8 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 11:30:58 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWEdt-0000RP-9E for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 11:30:58 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXZ00M9C72EQA@szxga01-in.huawei.com> for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 23:30:15 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXZ0070J72DHQ@szxga01-in.huawei.com> for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 23:30:14 +0800 (CST) Received: from [10.124.8.220] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXZ008AD7VAQD@szxml01-in.huawei.com>; Wed, 19 Apr 2006 23:47:42 +0800 (CST) Date: Wed, 19 Apr 2006 10:29:51 -0500 From: Behcet Sarikaya Subject: Re: [6lowpan] Working Group Charter In-reply-to: <1145428926.9167.164.camel@localhost.localdomain> To: Geoff Mulligan Message-id: <4446576F.2080106@yahoo.com> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <200604190433.k3J4XEib006198@newbsd.saloits.com> <1145428926.9167.164.camel@localhost.localdomain> X-Spam-Score: 2.7 (++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1818444663==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1818444663== Content-type: multipart/alternative; boundary="Boundary_(ID_AK4cSpakH0c965r5zsvG8w)" This is a multi-part message in MIME format. --Boundary_(ID_AK4cSpakH0c965r5zsvG8w) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I do not think it is the question of whether or not IPv6 can be implemented, the answer is of course it can be. Even IPsec/ MIPv6 can implemented as Phil said. From IP point of view this is another L2, and that's where I would like to comment. It seems that there is a fundamental problem in forming WGs on specific link layers, we have 6lowpan and 16ng as examples. In the past this was not followed, e.g. we did not have 3G related WGs although 3G has had much bigger impact. The question we should ask is what is the model to follow in 6lowpan? This seems to be not well defined so far and the discussions can help it clarify. However, as Timo said, the requirements should come from the industry, they should be real problems to be solved, so far we are not seeing this. As an example of the model, for example, for 16ng, we have WiMAX and to a lesser extent IEEE 802.16 that produce the requirements for any IETF standardization. WiMAX is taking the link spec from IEEE and defining a full-fledged cellular network using this link. We might probably need to define what a sensor network is and then derive the requirements for 6lowpan WG to do IETF-domain standardization. Hope this helps, --behcet Geoff Mulligan wrote: >On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: > > >>>Subject: Re: [6lowpan] Working Group Charter >>>From: Geoff Mulligan >>>Date: Tue, 18 Apr 2006 22:20:32 -0600 >>> >>>What do you mean "that we have no intention of actually implementing >>>IPv6 in wireless PANs". We have every intention of implementing IPv6 in >>>wireless PANs! >>> >>> >>The working group arguably isn't implementing IPv6 from two perspectives: >> >>o I don't think the IETF accepts the notion that implementing >> a subset of IPv6 is actually implementing IPv6. But, I could >> be wrong. I may ask this on question on the main IETF mail list. >> Having said that, the working group intends to implement >> only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). >> >> > >Too bad that we have to rehash this again because you are coming late to >this discussion. We dealt with this issue already and the IESG said >that an implementation that did not include IPsec and the like was still >an implementation of IPv6. > > >>o The protocol described in the format specification is not >> IPv6. If you fed it into an IPv6 stack, nothing good would >> happen. It is, however, a protocol that can easily be >> transformed into [a subset of] IPv6. >> >> > >If you do not use header compression then an IPv6 packet in the payload >of the 6lowpan frame format will work perfectly fine and everything good >will happen. The 6lowpan compressed headers are never intended to be >passed uncompressed out of a 6lowpan. > > > >>> In fact WE (Invensys and some other companies) already have and WE >>>(Invensys) have it deployed in a significant number of homes in pilots >>>in the US right now. >>> >>> >>See above. >> >> >> >>>I do not agree with the wording for your suggested Charter changes, >>>though I do truly appreciate that someone is starting some sort of >>>exchange on the list. >>> >>> >>Feel free to suggest alternative language and ideas. >> >>-tjs >> >>_______________________________________________ >>6lowpan mailing list >>6lowpan@ietf.org >>https://www1.ietf.org/mailman/listinfo/6lowpan >> >> > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www1.ietf.org/mailman/listinfo/6lowpan > > > --Boundary_(ID_AK4cSpakH0c965r5zsvG8w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT I do not think it is the question of whether or not IPv6 can be implemented, the answer is of course it can be. Even IPsec/ MIPv6 can implemented as Phil said. From IP point of view this is another L2, and that's where I would like to comment.
  It seems that there is a fundamental problem in forming WGs on specific link layers, we have 6lowpan and 16ng as examples. In the past this was not followed, e.g. we did not have 3G related WGs although 3G has had much bigger impact.
  The question we should ask is what is the model to follow in 6lowpan? This seems to be not well defined so far and the discussions can help it clarify. However, as Timo said, the requirements should come from the industry, they should be real problems to be solved, so far we are not seeing this.
  As an example of the model, for example, for 16ng, we have WiMAX and to a lesser extent IEEE 802.16 that produce the requirements for any IETF standardization. WiMAX is taking the link spec from IEEE and defining a full-fledged cellular network using this link.
  We might probably need to define what a sensor network is and then derive the requirements for 6lowpan WG to do IETF-domain standardization.
  Hope this helps,

--behcet
Geoff Mulligan wrote: 
On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote:
  
Subject: Re: [6lowpan] Working Group Charter
From: Geoff Mulligan <geoff@mulligan.com>
Date: Tue, 18 Apr 2006 22:20:32 -0600

What do you mean "that we have no intention of actually implementing
IPv6 in wireless PANs".  We have every intention of implementing IPv6 in
wireless PANs!
      
The working group arguably isn't implementing IPv6 from two perspectives:

o	I don't think the IETF accepts the notion that implementing
	a subset of IPv6 is actually implementing IPv6.  But, I could
	be wrong.  I may ask this on question on the main IETF mail list.
	Having said that, the working group intends to implement
	only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc).
    

Too bad that we have to rehash this again because you are coming late to
this discussion.  We dealt with this issue already and the IESG said
that an implementation that did not include IPsec and the like was still
an implementation of IPv6.
  
o	The protocol described in the format specification is not
	IPv6.  If you fed it into an IPv6 stack, nothing good would
	happen.  It is, however, a protocol that can easily be
	transformed into [a subset of] IPv6.
    

If you do not use header compression then an IPv6 packet in the payload
of the 6lowpan frame format will work perfectly fine and everything good
will happen.  The 6lowpan compressed headers are never intended to be
passed uncompressed out of a 6lowpan.

  
 In fact WE (Invensys and some other companies) already have and WE
(Invensys) have it deployed in a significant number of homes in pilots
in the US right now.
      
See above.

    
I do not agree with the wording for your suggested Charter changes,
though I do truly appreciate that someone is starting some sort of
exchange on the list.
      
Feel free to suggest alternative language and ideas.

-tjs

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
    


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--Boundary_(ID_AK4cSpakH0c965r5zsvG8w)-- --===============1818444663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1818444663==-- From 6lowpan-bounces@ietf.org Wed Apr 19 13:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWG2k-0000wF-2n; Wed, 19 Apr 2006 13:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWG2i-0000wA-KH for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:00:40 -0400 Received: from web54711.mail.yahoo.com ([206.190.49.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWG2i-0004UH-5h for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:00:40 -0400 Received: (qmail 9826 invoked by uid 60001); 19 Apr 2006 17:00:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JaryuXfziNWm2oTunmgkXVA5rLxMsUq0OHCUX5Y2TmM/VNiiwyTBFb2BFnAgp45greTWo5UxzMH/7BZmXB8RMMrGMdFdSxXIgOuYu9lLUNLi1rpeb8hMjcqLggOcodsrMBmf95+F2B0ua0+dFEpM1FtZfQtXwNp/7/XztzCCs7I= ; Message-ID: <20060419170039.9824.qmail@web54711.mail.yahoo.com> Received: from [65.95.103.250] by web54711.mail.yahoo.com via HTTP; Wed, 19 Apr 2006 10:00:39 PDT Date: Wed, 19 Apr 2006 10:00:39 -0700 (PDT) From: Peter Sherbin Subject: Re: [6lowpan] Working Group Charter To: Behcet Sarikaya , Geoff Mulligan In-Reply-To: <4446576F.2080106@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > clarify. However, as Timo said, the requirements should come from the > industry, they should be real problems to be solved, so far we are not > seeing this. Here is an industry input. I am working on a case where I need 10M - 100M mobile sensors size of 1/10 of a penny spread accross North America to provide updates every 10 min on their location / physical status for the duration of three - five years. All of them must have full length IPv6 addresses. When should I expect the solution from this WG? Peter --- Behcet Sarikaya wrote: > I do not think it is the question of whether or not IPv6 can be > implemented, the answer is of course it can be. Even IPsec/ MIPv6 can > implemented as Phil said. From IP point of view this is another L2, and > that's where I would like to comment. > It seems that there is a fundamental problem in forming WGs on > specific link layers, we have 6lowpan and 16ng as examples. In the past > this was not followed, e.g. we did not have 3G related WGs although 3G > has had much bigger impact. > The question we should ask is what is the model to follow in 6lowpan? > This seems to be not well defined so far and the discussions can help it > clarify. However, as Timo said, the requirements should come from the > industry, they should be real problems to be solved, so far we are not > seeing this. > As an example of the model, for example, for 16ng, we have WiMAX and > to a lesser extent IEEE 802.16 that produce the requirements for any > IETF standardization. WiMAX is taking the link spec from IEEE and > defining a full-fledged cellular network using this link. > We might probably need to define what a sensor network is and then > derive the requirements for 6lowpan WG to do IETF-domain standardization. > Hope this helps, > > --behcet > Geoff Mulligan wrote: > > >On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: > > > > > >>>Subject: Re: [6lowpan] Working Group Charter > >>>From: Geoff Mulligan > >>>Date: Tue, 18 Apr 2006 22:20:32 -0600 > >>> > >>>What do you mean "that we have no intention of actually implementing > >>>IPv6 in wireless PANs". We have every intention of implementing IPv6 in > >>>wireless PANs! > >>> > >>> > >>The working group arguably isn't implementing IPv6 from two perspectives: > >> > >>o I don't think the IETF accepts the notion that implementing > >> a subset of IPv6 is actually implementing IPv6. But, I could > >> be wrong. I may ask this on question on the main IETF mail list. > >> Having said that, the working group intends to implement > >> only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). > >> > >> > > > >Too bad that we have to rehash this again because you are coming late to > >this discussion. We dealt with this issue already and the IESG said > >that an implementation that did not include IPsec and the like was still > >an implementation of IPv6. > > > > > >>o The protocol described in the format specification is not > >> IPv6. If you fed it into an IPv6 stack, nothing good would > >> happen. It is, however, a protocol that can easily be > >> transformed into [a subset of] IPv6. > >> > >> > > > >If you do not use header compression then an IPv6 packet in the payload > >of the 6lowpan frame format will work perfectly fine and everything good > >will happen. The 6lowpan compressed headers are never intended to be > >passed uncompressed out of a 6lowpan. > > > > > > > >>> In fact WE (Invensys and some other companies) already have and WE > >>>(Invensys) have it deployed in a significant number of homes in pilots > >>>in the US right now. > >>> > >>> > >>See above. > >> > >> > >> > >>>I do not agree with the wording for your suggested Charter changes, > >>>though I do truly appreciate that someone is starting some sort of > >>>exchange on the list. > >>> > >>> > >>Feel free to suggest alternative language and ideas. > >> > >>-tjs > >> > >>_______________________________________________ > >>6lowpan mailing list > >>6lowpan@ietf.org > >>https://www1.ietf.org/mailman/listinfo/6lowpan > >> > >> > > > > > >_______________________________________________ > >6lowpan mailing list > >6lowpan@ietf.org > >https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 13:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGN7-00074l-Ku; Wed, 19 Apr 2006 13:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGN6-00071g-25 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:21:44 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWGN4-0005VW-LN for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 13:21:44 -0400 Received: from newbsd.saloits.com (localhost.saloits.com [127.0.0.1]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id k3JHLfi4008797 for <6lowpan@lists.ietf.org>; Wed, 19 Apr 2006 12:21:41 -0500 (CDT) (envelope-from salo@newbsd.saloits.com) Received: (from salo@localhost) by newbsd.saloits.com (8.13.1/8.13.1/Submit) id k3JHLfY2008796 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 12:21:41 -0500 (CDT) (envelope-from salo) Date: Wed, 19 Apr 2006 12:21:41 -0500 (CDT) From: "Timothy J. Salo" Message-Id: <200604191721.k3JHLfY2008796@newbsd.saloits.com> To: 6lowpan@lists.ietf.org Subject: Re: [6lowpan] Working Group Charter In-Reply-To: <1145428926.9167.164.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > Subject: Re: [6lowpan] Working Group Charter > From: Geoff Mulligan > Date: Wed, 19 Apr 2006 00:42:06 -0600 > [...] > Too bad that we have to rehash this again because you are coming late to > this discussion. We dealt with this issue already and the IESG said > that an implementation that did not include IPsec and the like was still > an implementation of IPv6. ... Could you provide a reference for this guidance? Here is what the chair of the IETF and the IESG said when I posed the question about subsetting IPv6 to the main IETF mail list: > Date: Wed, 19 Apr 2006 12:12:46 +0200 > From: Brian E Carpenter > Cc: "Timothy J. Salo" , ietf@ietf.org > Subject: Re: IPv6 Subsets? > > You might also want to look at RFC 4294 > (IPv6 Node Requirements). > > Brian And, here is what one of our Area Directors, (also a member of the IESG), said: > Date: Wed, 19 Apr 2006 11:14:20 +0300 > From: Jari Arkko > To: "Timothy J. Salo" > Cc: juha.wiljakka@ ietf@ietf.org > Subject: Re: IPv6 Subsets? > > RFC 4294 contains the most recent summary information > on what nodes should support from IPv6. The detailed > MUST/SHOULD/MAY requirements are in the IPv6 > specifications themselves. > > (RFC 3316 that Juha pointed to is a discussion of issues > related to running IPv6 over cellular interfaces. The > type of the interface that you are using does impact what > you need to support, at least in terms of what IPv6 over > Foo you need to support, what configuration options > make sense, etc.) > > --Jari Note that Jari is also a co-author of RFC 4294. Having said that, I believe that, at least from an engineering perspective, implementing a subset of IPv6, [a smaller subset than is permitted under RFC 4294], may make sense for wireless PANs. However, if we conclude that this is a good idea, we need to understand that implementing a subset of IPv6 conflicts with the prevailing view of many in the IETF. As such, if we want to implement less of IPv6 than is permitted under RFC 4294, we should start preparing our arguments about why wireless PANs are different from other environments. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 14:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHMl-0005Ky-Ni; Wed, 19 Apr 2006 14:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHMk-0005Ko-3q for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 14:25:26 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWHMe-000082-9M for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 14:25:26 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXZ00BXWFS8KY@szxga02-in.huawei.com> for 6lowpan@lists.ietf.org; Thu, 20 Apr 2006 02:38:32 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXZ006CZFS7RW@szxga02-in.huawei.com> for 6lowpan@lists.ietf.org; Thu, 20 Apr 2006 02:38:31 +0800 (CST) Received: from [10.124.8.220] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXZ00DQ5FY2WB@szxml01-in.huawei.com>; Thu, 20 Apr 2006 02:42:04 +0800 (CST) Date: Wed, 19 Apr 2006 13:24:19 -0500 From: Behcet Sarikaya Subject: Re: [6lowpan] Working Group Charter In-reply-to: <20060419170039.9824.qmail@web54711.mail.yahoo.com> To: Peter Sherbin Message-id: <44468053.8020004@yahoo.com> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <20060419170039.9824.qmail@web54711.mail.yahoo.com> X-Spam-Score: 2.3 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0788457885==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0788457885== Content-type: multipart/alternative; boundary="Boundary_(ID_spGcbicuk0iP5Y7X/pkw8Q)" This is a multi-part message in MIME format. --Boundary_(ID_spGcbicuk0iP5Y7X/pkw8Q) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Peter Sherbin wrote: >>clarify. However, as Timo said, the requirements should come from the >>industry, they should be real problems to be solved, so far we are not >>seeing this. >> >> > >Here is an industry input. I am working on a case where I need 10M - 100M mobile >sensors size of 1/10 of a penny spread accross North America to provide updates >every 10 min on their location / physical status for the duration of three - five >years. All of them must have full length IPv6 addresses. > >When should I expect the solution from this WG? > >Peter > > If you have 802.15.4 radio and MAC layer on them then use the format draft to implement an IP stack. Build your application including routing on top yourself. If you don't then nothing applies here maybe TinyOS might help you. Regards, --behcet --Boundary_(ID_spGcbicuk0iP5Y7X/pkw8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Peter Sherbin wrote:
clarify. However, as Timo said, the requirements should come from the 
industry, they should be real problems to be solved, so far we are not 
seeing this.
    

Here is an industry input. I am working on a case where I need 10M - 100M mobile
sensors size of 1/10 of a penny spread accross North America to provide updates
every 10 min on their location / physical status for the duration of three - five
years. All of them must have full length IPv6 addresses.

When should I expect the solution from this WG?

Peter
If you have 802.15.4 radio and MAC layer on them then use the format draft to implement an IP stack. Build your application including routing on top yourself.
If you don't then nothing applies here maybe TinyOS might help you.

Regards,
--behcet
--Boundary_(ID_spGcbicuk0iP5Y7X/pkw8Q)-- --===============0788457885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0788457885==-- From 6lowpan-bounces@ietf.org Wed Apr 19 14:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHox-0004lu-Rs; Wed, 19 Apr 2006 14:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHow-0004lp-Cf for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 14:54:34 -0400 Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWHov-00015L-C9 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 14:54:34 -0400 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k3JIrmIV013517; Wed, 19 Apr 2006 18:53:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k3JIrff9013516; Wed, 19 Apr 2006 18:53:41 GMT Date: Wed, 19 Apr 2006 18:53:41 +0000 From: bmanning@vacation.karoshi.com To: Peter Sherbin Subject: Re: [6lowpan] Working Group Charter Message-ID: <20060419185341.GB13461@vacation.karoshi.com.> References: <4446576F.2080106@yahoo.com> <20060419170039.9824.qmail@web54711.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060419170039.9824.qmail@web54711.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org yo... have you solved the power problem? small, (nearly) always on for three/five years is a tough nut to crack. tried it at least three different times in the past 10 years. kind of doable w/ active RFIDs but the life expectancy is much shorter. --bill On Wed, Apr 19, 2006 at 10:00:39AM -0700, Peter Sherbin wrote: > > clarify. However, as Timo said, the requirements should come from the > > industry, they should be real problems to be solved, so far we are not > > seeing this. > > Here is an industry input. I am working on a case where I need 10M - 100M mobile > sensors size of 1/10 of a penny spread accross North America to provide updates > every 10 min on their location / physical status for the duration of three - five > years. All of them must have full length IPv6 addresses. > > When should I expect the solution from this WG? > > Peter > > --- Behcet Sarikaya wrote: > > > I do not think it is the question of whether or not IPv6 can be > > implemented, the answer is of course it can be. Even IPsec/ MIPv6 can > > implemented as Phil said. From IP point of view this is another L2, and > > that's where I would like to comment. > > It seems that there is a fundamental problem in forming WGs on > > specific link layers, we have 6lowpan and 16ng as examples. In the past > > this was not followed, e.g. we did not have 3G related WGs although 3G > > has had much bigger impact. > > The question we should ask is what is the model to follow in 6lowpan? > > This seems to be not well defined so far and the discussions can help it > > clarify. However, as Timo said, the requirements should come from the > > industry, they should be real problems to be solved, so far we are not > > seeing this. > > As an example of the model, for example, for 16ng, we have WiMAX and > > to a lesser extent IEEE 802.16 that produce the requirements for any > > IETF standardization. WiMAX is taking the link spec from IEEE and > > defining a full-fledged cellular network using this link. > > We might probably need to define what a sensor network is and then > > derive the requirements for 6lowpan WG to do IETF-domain standardization. > > Hope this helps, > > > > --behcet > > Geoff Mulligan wrote: > > > > >On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: > > > > > > > > >>>Subject: Re: [6lowpan] Working Group Charter > > >>>From: Geoff Mulligan > > >>>Date: Tue, 18 Apr 2006 22:20:32 -0600 > > >>> > > >>>What do you mean "that we have no intention of actually implementing > > >>>IPv6 in wireless PANs". We have every intention of implementing IPv6 in > > >>>wireless PANs! > > >>> > > >>> > > >>The working group arguably isn't implementing IPv6 from two perspectives: > > >> > > >>o I don't think the IETF accepts the notion that implementing > > >> a subset of IPv6 is actually implementing IPv6. But, I could > > >> be wrong. I may ask this on question on the main IETF mail list. > > >> Having said that, the working group intends to implement > > >> only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). > > >> > > >> > > > > > >Too bad that we have to rehash this again because you are coming late to > > >this discussion. We dealt with this issue already and the IESG said > > >that an implementation that did not include IPsec and the like was still > > >an implementation of IPv6. > > > > > > > > >>o The protocol described in the format specification is not > > >> IPv6. If you fed it into an IPv6 stack, nothing good would > > >> happen. It is, however, a protocol that can easily be > > >> transformed into [a subset of] IPv6. > > >> > > >> > > > > > >If you do not use header compression then an IPv6 packet in the payload > > >of the 6lowpan frame format will work perfectly fine and everything good > > >will happen. The 6lowpan compressed headers are never intended to be > > >passed uncompressed out of a 6lowpan. > > > > > > > > > > > >>> In fact WE (Invensys and some other companies) already have and WE > > >>>(Invensys) have it deployed in a significant number of homes in pilots > > >>>in the US right now. > > >>> > > >>> > > >>See above. > > >> > > >> > > >> > > >>>I do not agree with the wording for your suggested Charter changes, > > >>>though I do truly appreciate that someone is starting some sort of > > >>>exchange on the list. > > >>> > > >>> > > >>Feel free to suggest alternative language and ideas. > > >> > > >>-tjs > > >> > > >>_______________________________________________ > > >>6lowpan mailing list > > >>6lowpan@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/6lowpan > > >> > > >> > > > > > > > > >_______________________________________________ > > >6lowpan mailing list > > >6lowpan@ietf.org > > >https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 19 15:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWImh-0008Mu-Ty; Wed, 19 Apr 2006 15:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWImg-0008Mp-IJ for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 15:56:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWIme-0003tr-G7 for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 15:56:16 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWIXL-0008IL-Sq for 6lowpan@lists.ietf.org; Wed, 19 Apr 2006 15:40:29 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k3JJe7m5021118; Wed, 19 Apr 2006 13:40:07 -0600 (MDT) Subject: Re: [6lowpan] Working Group Charter From: Geoff Mulligan To: bmanning@vacation.karoshi.com In-Reply-To: <20060419185341.GB13461@vacation.karoshi.com.> References: <4446576F.2080106@yahoo.com> <20060419170039.9824.qmail@web54711.mail.yahoo.com> <20060419185341.GB13461@vacation.karoshi.com.> Content-Type: text/plain Date: Wed, 19 Apr 2006 13:40:22 -0600 Message-Id: <1145475622.9167.188.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org we have not solved the power problem. We have found some techniques for building sensors that are not always on that look to have a 6-7 year battery life - 1) these devices are not considered part of the mesh routing and 2) they communicate with the core of mesh which is always on. power is going to be one of the hardest problems, but in our view of the application space, wireless does not equate to only battery operated. geoff On Wed, 2006-04-19 at 18:53 +0000, bmanning@vacation.karoshi.com wrote: > yo... have you solved the power problem? small, (nearly) always on > for three/five years is a tough nut to crack. tried it at least > three different times in the past 10 years. kind of doable w/ active RFIDs > but the life expectancy is much shorter. > > --bill > > > On Wed, Apr 19, 2006 at 10:00:39AM -0700, Peter Sherbin wrote: > > > clarify. However, as Timo said, the requirements should come from the > > > industry, they should be real problems to be solved, so far we are not > > > seeing this. > > > > Here is an industry input. I am working on a case where I need 10M - 100M mobile > > sensors size of 1/10 of a penny spread accross North America to provide updates > > every 10 min on their location / physical status for the duration of three - five > > years. All of them must have full length IPv6 addresses. > > > > When should I expect the solution from this WG? > > > > Peter > > > > --- Behcet Sarikaya wrote: > > > > > I do not think it is the question of whether or not IPv6 can be > > > implemented, the answer is of course it can be. Even IPsec/ MIPv6 can > > > implemented as Phil said. From IP point of view this is another L2, and > > > that's where I would like to comment. > > > It seems that there is a fundamental problem in forming WGs on > > > specific link layers, we have 6lowpan and 16ng as examples. In the past > > > this was not followed, e.g. we did not have 3G related WGs although 3G > > > has had much bigger impact. > > > The question we should ask is what is the model to follow in 6lowpan? > > > This seems to be not well defined so far and the discussions can help it > > > clarify. However, as Timo said, the requirements should come from the > > > industry, they should be real problems to be solved, so far we are not > > > seeing this. > > > As an example of the model, for example, for 16ng, we have WiMAX and > > > to a lesser extent IEEE 802.16 that produce the requirements for any > > > IETF standardization. WiMAX is taking the link spec from IEEE and > > > defining a full-fledged cellular network using this link. > > > We might probably need to define what a sensor network is and then > > > derive the requirements for 6lowpan WG to do IETF-domain standardization. > > > Hope this helps, > > > > > > --behcet > > > Geoff Mulligan wrote: > > > > > > >On Tue, 2006-04-18 at 23:33 -0500, Timothy J. Salo wrote: > > > > > > > > > > > >>>Subject: Re: [6lowpan] Working Group Charter > > > >>>From: Geoff Mulligan > > > >>>Date: Tue, 18 Apr 2006 22:20:32 -0600 > > > >>> > > > >>>What do you mean "that we have no intention of actually implementing > > > >>>IPv6 in wireless PANs". We have every intention of implementing IPv6 in > > > >>>wireless PANs! > > > >>> > > > >>> > > > >>The working group arguably isn't implementing IPv6 from two perspectives: > > > >> > > > >>o I don't think the IETF accepts the notion that implementing > > > >> a subset of IPv6 is actually implementing IPv6. But, I could > > > >> be wrong. I may ask this on question on the main IETF mail list. > > > >> Having said that, the working group intends to implement > > > >> only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc). > > > >> > > > >> > > > > > > > >Too bad that we have to rehash this again because you are coming late to > > > >this discussion. We dealt with this issue already and the IESG said > > > >that an implementation that did not include IPsec and the like was still > > > >an implementation of IPv6. > > > > > > > > > > > >>o The protocol described in the format specification is not > > > >> IPv6. If you fed it into an IPv6 stack, nothing good would > > > >> happen. It is, however, a protocol that can easily be > > > >> transformed into [a subset of] IPv6. > > > >> > > > >> > > > > > > > >If you do not use header compression then an IPv6 packet in the payload > > > >of the 6lowpan frame format will work perfectly fine and everything good > > > >will happen. The 6lowpan compressed headers are never intended to be > > > >passed uncompressed out of a 6lowpan. > > > > > > > > > > > > > > > >>> In fact WE (Invensys and some other companies) already have and WE > > > >>>(Invensys) have it deployed in a significant number of homes in pilots > > > >>>in the US right now. > > > >>> > > > >>> > > > >>See above. > > > >> > > > >> > > > >> > > > >>>I do not agree with the wording for your suggested Charter changes, > > > >>>though I do truly appreciate that someone is starting some sort of > > > >>>exchange on the list. > > > >>> > > > >>> > > > >>Feel free to suggest alternative language and ideas. > > > >> > > > >>-tjs > > > >> > > > >>_______________________________________________ > > > >>6lowpan mailing list > > > >>6lowpan@ietf.org > > > >>https://www1.ietf.org/mailman/listinfo/6lowpan > > > >> > > > >> > > > > > > > > > > > >_______________________________________________ > > > >6lowpan mailing list > > > >6lowpan@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Apr 20 04:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUhx-00065U-Cq; Thu, 20 Apr 2006 04:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUhw-00065P-A1 for 6lowpan@lists.ietf.org; Thu, 20 Apr 2006 04:40:12 -0400 Received: from mailx.danfoss.com ([193.162.34.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWUhv-0000kk-VG for 6lowpan@lists.ietf.org; Thu, 20 Apr 2006 04:40:12 -0400 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by mailx.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:40:10 +0200 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Thu, 20 Apr 2006 10:40:10 +0200 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:40:10 +0200 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 Subject: FW: [6lowpan] poll for interim meeting locations Date: Thu, 20 Apr 2006 10:40:08 +0200 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D787EDAC@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] poll for interim meeting locations Thread-Index: AcZUSXXFcPsLLGB3QSaVx+omqgJ/WwQC13Sw From: "Schumacher Christian Peter Pii" To: "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 20 Apr 2006 08:40:10.0255 (UTC) FILETIME=[08B2F9F0:01C66456] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear all. Gabriel pointed out in a previous mail, that it might be a good idea to give teleconferencing a shot. How many are interested in this? Please list preferred weekday and time (in GMT). Regards Christian -----Original Message----- From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]=20 Sent: 31. marts 2006 00:30 To: Geoff Mulligan; sarikaya@ieee.org Cc: 6lowpan Subject: Re: [6lowpan] poll for interim meeting locations Just to clarify: I think the interim we had was very productive and wish we had had more time. I'm one of the happy ones. And if it makes sense, I'm all for having another productive one (as per the subject line in this message). All I'm saying is that every interim/meeting is an expense in time and money, and it's good to have as much info in advance in order to weigh the priorities with other commitments. Things like teleconferences are used regularly in IEEE or other venues, and that's perhaps something to explore as well. -gabriel --- Geoff Mulligan wrote: > While a do agree that we should not meet if we do not have clear agenda > and take exception to your characterization that people were not happy > with the last interim. >=20 > Everyone that I have spoken with were pleased with the progress that we > made and the topics covered at the interim and felt that it was very > productive and useful. >=20 > If that is not the case, please speak up. >=20 > geoff >=20 > On Tue, 2006-03-28 at 10:06 -0800, Behcet Sarikaya wrote: > > I agree with Gabriel. We should not meet if there is not much to > > do/not enough attendance is expected, etc. I think that not many > > people were happy with the last interim. > >=20 > > Regards, > >=20 > > Behcet > >=20 > > gabriel montenegro wrote: > > > Why is an interim needed?=20 > > > What would be the agenda and desired outcome of this meeting? > > > What do we need to get done before we're ready for such a meeting? > > >=20 > > > I'd vote for Jacksonville, but really, without a clearer idea of the above I'd be > unable > > > to justify this expense in time and money. > > >=20 > > > -gabriel > > >=20 > > > --- Schumacher Christian Peter Pii wrote: > > >=20 > > > =20 > > > > Dear 6lowpanners > > > >=20 > > > > There has been suggested the following locations for a 2-day interim > > > > meeting: > > > >=20 > > > > - Europe: > > > > Danfoss A/S, Denmark > > > > TZI, Germany > > > > - Canada: > > > > In connection with WiMAX F2F meeting in Ottawa, May 23-25 > > > > - USA: > > > > In connection (possibly May 11-12) with IEEE 802 Interim in > > > > Jacksonville, May14-19 > > > >=20 > > > > Please reply your preference to this mail and CC the mailing list, so we > > > > can determine the overall preference. > > > >=20 > > > > Deadline for this poll is Friday 7th of April. > > > >=20 > > > > Regards > > > > Christian Schumacher > > > >=20 > > > >=20 > > > > =20 > > > > > _______________________________________________ > > > > > =20 > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > >=20 > > > > =20 > > >=20 > > >=20 > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > > http://mail.yahoo.com=20 > > >=20 > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > >=20 > > >=20 > > > =20 > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan >=20 >=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Apr 21 14:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0QH-0000H2-9G; Fri, 21 Apr 2006 14:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0QF-0000Gx-N4 for 6lowpan@ietf.org; Fri, 21 Apr 2006 14:32:03 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0QE-0008MW-9a for 6lowpan@ietf.org; Fri, 21 Apr 2006 14:32:03 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k3LIVtHs026734; Fri, 21 Apr 2006 20:31:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25B054F9-06B0-46A8-A401-05A84693B3FA@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Fri, 21 Apr 2006 21:31:52 +0300 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Carsten Bormann Subject: [6lowpan] Minutes from IETF 65 uploaded X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Lowpanners, I have just uploaded the minutes from our IETF65 meeting. Reminder: You can find the materials (Agenda, Minutes, Slides) at: https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=65#wg-6lowpan Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Apr 21 14:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0Yq-00036y-JX; Fri, 21 Apr 2006 14:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0Yp-00036t-Ad for 6lowpan@ietf.org; Fri, 21 Apr 2006 14:40:55 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0Yo-0000Bx-V8 for 6lowpan@ietf.org; Fri, 21 Apr 2006 14:40:55 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k3LIeq9p000530; Fri, 21 Apr 2006 20:40:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <622F0374-9E10-4822-ABFD-9E28FCBEC72C@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Fri, 21 Apr 2006 21:40:52 +0300 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Carsten Bormann Subject: [6lowpan] 6lowpan 16-bit address space map X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Lowpanners, here is a more detailed idea of how the addressing map for 16-bit addresses could look like. Comments welcome. 0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator 100xxxxxxxxxxxxx special unicast addresses, e.g. 1000000000000000 PAN coordinator 1000000000000001 backup PAN coordinator (just making this up now) allocation requires standards action 101xxxxxxxxxxxxx reserved (allocation requires standards action) 110xxxxxxxxxxxxx multicast addresses (mapping per format document) 111xxxxxxxxxxxxx special addresses, often multicast, e.g. 1111111111111110 (the 0xfffe thing from 802.15.4) 1111111111111111 radio-range-limited localcast to non-sleepers allocation requires standards action I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator things etc; maybe we should use 111xxxxxxxxxxxxx for all "special" addresses to have more contiguous space reserved for future use. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Apr 23 19:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXoFF-0001vY-VG; Sun, 23 Apr 2006 19:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXoFE-0001vT-VC for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 19:44:00 -0400 Received: from nz-out-0102.google.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXoFE-0000eF-IR for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 19:44:00 -0400 Received: by nz-out-0102.google.com with SMTP id x7so911989nzc for <6lowpan@lists.ietf.org>; Sun, 23 Apr 2006 16:44:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dpMw1vQOqmEOFYIMzHOqyei/VF+CDqvoRvvxp5fBDDPpZ0n5qQxW5/6ykky63usJ7NV4dvDT16ypAiB2I4GdM9/9BwvNnFKN/HCuFuaU8VPMkhvAvnfKIFysNctVLaLhFFe5GAM7FQlYU5QnpRZv7EcAuwv4hsN+n6zTtwVgmb8= Received: by 10.65.251.4 with SMTP id d4mr445272qbs; Sun, 23 Apr 2006 16:43:59 -0700 (PDT) Received: by 10.65.204.1 with HTTP; Sun, 23 Apr 2006 16:43:59 -0700 (PDT) Message-ID: <43b91d370604231643i37ced3a0j146942efc34e8867@mail.gmail.com> Date: Sun, 23 Apr 2006 16:43:59 -0700 From: "Samita Chakrabarti" To: "Timothy J. Salo" Subject: Re: [6lowpan] Working Group Charter In-Reply-To: <200604191721.k3JHLfY2008796@newbsd.saloits.com> MIME-Version: 1.0 References: <1145428926.9167.164.camel@localhost.localdomain> <200604191721.k3JHLfY2008796@newbsd.saloits.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1797089535==" Errors-To: 6lowpan-bounces@ietf.org --===============1797089535== Content-Type: multipart/alternative; boundary="----=_Part_1393_5810530.1145835839919" ------=_Part_1393_5810530.1145835839919 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Timothy, IESG had approved 6lowpan wg sometime ago and I am sure they were aware of some of the cases of IPv6 that are not directly or efficiently applicable for 802.15.4 networks. IPv6 is still useful for standardization of these devices. Sensors or 802.15.4 radio interface capable devices will be deployed large in numbers; the applications will expand from mere collection information from the end devices and they would often require to interoperate with regular devices on the Inernet. IPv6 is the sane and standard way to interoperate in that case without building numerous application gateways from different vendors. As one of the design-team members of RFC4294, I can say that IPv6 node requirements document is a guide line for generic IPv6 node builders. 6lowpan devices can implement generic IPv6 protocol, but due to the nature of power usage, device processing power, 802.15.4 network is quite different than regular fixed ethernet or wifi network for which IPv6 protocols are generally applicable. IPv6-over-foo needs to be developed and optimized for other type of interfaces and that's what 6lowpan is aiming for. The format document has consulted the IPv6-node-requirement document as well as far as I remember. It is the same reason, we are trying to optimize IPv6 Neighbor discovery protocol for this type of network. If you read the 6lowpan goals document and 6lowpan Neighbor discovery draft, you can see explanations how 6lowpan is different than regular Internet networks. -Samita > Date: Wed, 19 Apr 2006 11:14:20 +0300 > > From: Jari Arkko > > To: "Timothy J. Salo" > > Cc: juha.wiljakka@ ietf@ietf.org > > Subject: Re: IPv6 Subsets? > > > > RFC 4294 contains the most recent summary information > > on what nodes should support from IPv6. The detailed > > MUST/SHOULD/MAY requirements are in the IPv6 > > specifications themselves. > > > > (RFC 3316 that Juha pointed to is a discussion of issues > > related to running IPv6 over cellular interfaces. The > > type of the interface that you are using does impact what > > you need to support, at least in terms of what IPv6 over > > Foo you need to support, what configuration options > > make sense, etc.) > > > > --Jari > > Note that Jari is also a co-author of RFC 4294. > > Having said that, I believe that, at least from an engineering > perspective, > implementing a subset of IPv6, [a smaller subset than is permitted under > RFC 4294], may make sense for wireless PANs. However, if we conclude tha= t > this is a good idea, we need to understand that implementing a subset of > IPv6 conflicts with the prevailing view of many in the IETF. As such, if > we want to implement less of IPv6 than is permitted under RFC 4294, we > should start preparing our arguments about why wireless PANs are differen= t > from other environments. > > -tjs > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > ------=_Part_1393_5810530.1145835839919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 

Hello Timothy,
 
 
IESG had approved 6lowpan wg  sometime ago and I am sure they
were aware of some of the cases of IPv6 that are not directly
or efficiently applicable for 802.15.4 networks. IPv6 is still useful<= /div>
for standardization of these devices. Sensors or 802.15.4 radio interf= ace
capable devices will be deployed large in numbers; the applications
will expand from mere collection information from the end devices and<= /div>
they would often require to interoperate with regular devices on the
Inernet. IPv6 is the sane and standard way to interoperate in that cas= e
without building numerous application gateways  from different ve= ndors.
 
As one of the design-team members of RFC4294, I can say that IPv6
node requirements document is a guide line for generic IPv6 node build= ers.
6lowpan devices can implement generic IPv6 protocol, but due to the
nature of power usage, device processing power, 802.15.4 network is
quite different than regular fixed ethernet or wifi network for which = IPv6
protocols are generally applicable.  IPv6-over-foo needs to be de= veloped
and optimized for other type of interfaces and that's what 6lowpan is =
aiming for. The format document has consulted the IPv6-node-requiremen= t
document as well as far as I remember.
It is the same reason, we are trying to optimize IPv6 Neighbor discove= ry
protocol for this type of network.  If you read the 6lowpan goals= document
and 6lowpan Neighbor discovery draft, you can see explanations how
6lowpan is different than regular Internet networks.
 
-Samita

> Date: Wed, 19 Apr 2006 11:1= 4:20 +0300
> From: Jari Arkko <jari.arkko@>
> To: "T= imothy J. Salo" <salo@>
> Cc: juha.wiljakka@ ietf@ietf.org<= /a>
> Subject: Re: IPv6 Subsets?
>
> RFC 4294 contains th= e most recent summary information
> on what nodes should support from= IPv6. The detailed
> MUST/SHOULD/MAY requirements are in the IPv6
> specification= s themselves.
>
> (RFC 3316 that Juha pointed to is a discussio= n of issues
> related to running IPv6 over cellular interfaces. The
> type of the interface that you are using does impact what
> = you need to support, at least in terms of what IPv6 over
> Foo you ne= ed to support, what configuration options
> make sense, etc.)
>
> --Jari

Note that Jari is also a co-author of RFC 4294.<= br>
Having said that, I believe that, at least from an engineering persp= ective,
implementing a subset of IPv6, [a smaller subset than is permitt= ed under
RFC 4294], may make sense for wireless PANs.  However, if we = conclude that
this is a good idea, we need to understand that implementi= ng a subset of
IPv6 conflicts with the prevailing view of many in the IE= TF.  As such, if
we want to implement less of IPv6 than is permitted under RFC 4294, we<= br>should start preparing our arguments about why wireless PANs are differe= nt
from other environments.

-tjs

_________________________= ______________________
6lowpan mailing list
6lowpan@iet= f.org
htt= ps://www1.ietf.org/mailman/listinfo/6lowpan

------=_Part_1393_5810530.1145835839919-- --===============1797089535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1797089535==-- From 6lowpan-bounces@ietf.org Sun Apr 23 22:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXqqC-00036D-Pg; Sun, 23 Apr 2006 22:30:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXqqB-000368-HB for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 22:30:19 -0400 Received: from nz-out-0102.google.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXqqA-0007F9-2H for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 22:30:19 -0400 Received: by nz-out-0102.google.com with SMTP id x7so936778nzc for <6lowpan@lists.ietf.org>; Sun, 23 Apr 2006 19:30:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hg3GK9EJqssU7WZfyiLp7hfCwLkB2dFpfYcnII7QaTg3+HuvXP4LS5+1iC/6wxVFpe+72IkINn7gBqTTDSrF4axRsZkGwFPeassoKC6mLYhhDgauOpPYPtNOl19C0V/t9GLNhQLCdUr3w2p8K9P1tPGwI2d90b0tF6tbj3DacWM= Received: by 10.65.141.20 with SMTP id t20mr678462qbn; Sun, 23 Apr 2006 19:30:17 -0700 (PDT) Received: by 10.65.204.1 with HTTP; Sun, 23 Apr 2006 19:30:17 -0700 (PDT) Message-ID: <43b91d370604231930i63397fe5vd207682a58e2cdd4@mail.gmail.com> Date: Sun, 23 Apr 2006 19:30:17 -0700 From: "Samita Chakrabarti" To: "Philip Levis" Subject: Re: [6lowpan] Working Group Charter In-Reply-To: <5B6DC1D8-D091-4AD6-9664-89AF92DA9704@cs.stanford.edu> MIME-Version: 1.0 References: <200604190433.k3J4XEib006198@newbsd.saloits.com> <1145428926.9167.164.camel@localhost.localdomain> <5B6DC1D8-D091-4AD6-9664-89AF92DA9704@cs.stanford.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1256967690==" Errors-To: 6lowpan-bounces@ietf.org --===============1256967690== Content-Type: multipart/alternative; boundary="----=_Part_2986_32214716.1145845817186" ------=_Part_2986_32214716.1145845817186 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Phil, On 4/19/06, Philip Levis wrote: > > > If you take the IPv6 over 15.4 route (no pun intended), under the > assumption of low-power embedded devices, I'd argue that it's not the > data plane that changes, but rather the control plane. E.g., many > existing IP routing approaches become problematic, predominantly due > to the fact that the assume any-to-any connectivity as an end goal, Agree that IPv6 routing may be redundant in 802.15.4 network. The format document suggests alternative routing (Mesh) at L2. Thus, in practice, IPv6 would be useful for addressing, auto-configuration , device management and running applications while routing within the PAN takes place at the L2 layer. From IPv6 perspective, a PAN is a L3 subnet. However, the IPv6 router at the 6lowPAN junction is responsible for routing a packet to the Internet if the destination address suggests so= ; here the IPv6 6lowPan router acts as a default gateway. while in PANs this is less commonly the case. I think this gets to > the point raised earlier, of whether the group considers 802.15.4 > networks being used as transmit networks, which is a very very > important consideration. Good point. As mentioned earlier, 802.15.4 L2 layer can be used for data routing within the PAN. Coming from the world of TinyOS and sensor networks, I'd argue that > it's pretty clear that a set of protocols and mechanisms enabling IP > devices to directly communicate with PAN devices would be very useful > (why I'm here). The most common case for this is management, as it's > a situation where a user definitely wants to talk to a specific > *node*, i.e., an address, rather than use some other naming scheme > (e.g., "the lights in the living room"). The advantage that a direct > IP-level protocol transcoder would provide is that it would preclude > the need for application-level protocol stacks to even communicate > with nodes within a network. Furthermore, you can begin to use all of > the basic IP tricks and techniques when managing these networks > (e.g., firewalls). Agree. That being said, if the plan is not to push IPv6 into the PAN, then > this raises the simple question of what L3 protocols will run within > the PAN. By L3 protocols do you mean any routing protocols? Other than that, format doc already talks about running UDP, at the last interim folks brought up needs for running a simple TCP stack as well for running different existing apps. I'd think it really depends what sort of applications folks will run on top of 802.15.4 networks? There might be devices other than sensors, which will run 802.15.4 radio for a different type of applications where node-to-node communications might be necessary. Any ideas? Thanks, -Samita http://csl.stanford.edu/~pal > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > ------=_Part_2986_32214716.1145845817186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Phil,

On 4/19/06, = Philip Levis <pal@cs.stanford= .edu> wrote:

If you take the IPv6 over 15= .4 route (no pun intended), under the
assumption of low-power embedded d= evices, I'd argue that it's not the
data plane that changes, but rather the control plane. E.g., many
ex= isting IP routing approaches become problematic, predominantly due
to th= e fact that the assume any-to-any connectivity as an end goal,
 
Agree that IPv6 routing may be redundant in 802.15.4 network.
The format document suggests alternative routing (Mesh) at L2.
 
Thus, in practice, IPv6 would be useful for addressing, auto-configura= tion
, device management and running applications while routing within the<= /div>
PAN takes place at the L2 layer. From IPv6 perspective, a PAN is a
L3 subnet. However, the IPv6 router at the 6lowPAN junction is respons= ible
for routing a packet to the Internet if the destination address sugges= ts so;
here the IPv6 6lowPan router acts as a default gateway.

while in PANs this is less commo= nly the case. I think this gets to
the point raised earlier, of whether = the group considers=20 802.15.4
networks being used as transmit networks, which is a very very<= br>important consideration.
 
Good point. As mentioned earlier, 802.15.4 L2 layer can be used for
data routing within the PAN.

Coming from the world of TinyOS = and sensor networks, I'd argue that
it's pretty clear that a set of prot= ocols and mechanisms enabling IP
devices to directly communicate with PAN devices would be very useful(why I'm here). The most common case for this is management, as it's
a= situation where a user definitely wants to talk to a specific
*node*,= =20 i.e., an address, rather than use some other naming scheme
(e.g., "= the lights in the living room"). The advantage that a direct
IP-lev= el protocol transcoder would provide is that it would preclude
the need = for application-level protocol stacks to even communicate
with nodes within a network. Furthermore, you can begin to use all ofthe basic IP tricks and techniques when managing these networks
(e.g.,= firewalls).
 
Agree.

That being said, if the plan is = not to push IPv6 into the PAN, then
this raises the simple question of w= hat L3 protocols will run within
the PAN.
 
 
By L3 protocols do you mean any routing protocols?  Other than th= at,
format doc already talks about running UDP, at the last interim folks = brought up
needs for running a simple TCP stack as well for running different exi= sting
apps. I'd think it really depends what sort of applications folks will= run
on top of 802.15.4 networks?  There might be devices other than s= ensors, which
will run 802.15.4 radio for a different type of applications where nod= e-to-node
communications might be necessary. Any ideas?
 
Thanks,
-Samita

http://csl.stanford.edu/~pal



__________________= _____________________________
6lowpan mailing list
6lowpan@iet= f.org
htt= ps://www1.ietf.org/mailman/listinfo/6lowpan

------=_Part_2986_32214716.1145845817186-- --===============1256967690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1256967690==-- From 6lowpan-bounces@ietf.org Sun Apr 23 22:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXr2d-0005fG-50; Sun, 23 Apr 2006 22:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXr2c-0005f8-1w for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 22:43:10 -0400 Received: from nz-out-0102.google.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXr2b-0007Zy-FL for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 22:43:10 -0400 Received: by nz-out-0102.google.com with SMTP id x7so938930nzc for <6lowpan@lists.ietf.org>; Sun, 23 Apr 2006 19:43:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nMvzLumjgyNUWhawdFpAxDfqrONyI3R2KSduMYVXaYuFHvMMXHshjvLmFdUY1+F26do4AG331C0D8o2qNdV2WBXCkWE1+3oAMcsMGMgKk7QPrW+0urYjy1NcIP32C77RaErCKHoLeK8CRHDlybGSTFNyNM3UBWSNkn/fjBkBcrg= Received: by 10.65.95.6 with SMTP id x6mr107797qbl; Sun, 23 Apr 2006 19:43:08 -0700 (PDT) Received: by 10.65.204.1 with HTTP; Sun, 23 Apr 2006 19:43:08 -0700 (PDT) Message-ID: <43b91d370604231943s22458740n37a3e5ef572cf27a@mail.gmail.com> Date: Sun, 23 Apr 2006 19:43:08 -0700 From: "Samita Chakrabarti" To: "Schumacher Christian Peter Pii" Subject: Re: FW: [6lowpan] poll for interim meeting locations In-Reply-To: <49A38D2FE2C53946A57916AD6A1F00D787EDAC@DKDN01MX34.danfoss.net> MIME-Version: 1.0 References: <49A38D2FE2C53946A57916AD6A1F00D787EDAC@DKDN01MX34.danfoss.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1312316550==" Errors-To: 6lowpan-bounces@ietf.org --===============1312316550== Content-Type: multipart/alternative; boundary="----=_Part_3146_14058710.1145846588404" ------=_Part_3146_14058710.1145846588404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Christian, Please count me in. I am in pacific time zone. 10am -3pm and 9pm - 11pm (PDT) are good for me generally for teleconference. Thanks, -Samita On 4/20/06, Schumacher Christian Peter Pii wrote: > > Dear all. > > Gabriel pointed out in a previous mail, that it might be a good idea to > give teleconferencing a shot. How many are interested in this? Please > list preferred weekday and time (in GMT). > > Regards > Christian > > -----Original Message----- > From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com] > Sent: 31. marts 2006 00:30 > To: Geoff Mulligan; sarikaya@ieee.org > Cc: 6lowpan > Subject: Re: [6lowpan] poll for interim meeting locations > > Just to clarify: I think the interim we had was very productive and wish > we had had > more time. I'm one of the happy ones. And if it makes sense, I'm all for > having > another productive one (as per the subject line in this message). > > All I'm saying is that every interim/meeting is an expense in time and > money, and > it's good to have as much info in advance in order to weigh the > priorities with other > commitments. Things like teleconferences are used regularly in IEEE or > other venues, > and that's perhaps something to explore as well. > > -gabriel > > --- Geoff Mulligan wrote: > > > While a do agree that we should not meet if we do not have clear > agenda > > and take exception to your characterization that people were not happy > > with the last interim. > > > > Everyone that I have spoken with were pleased with the progress that > we > > made and the topics covered at the interim and felt that it was very > > productive and useful. > > > > If that is not the case, please speak up. > > > > geoff > > > > On Tue, 2006-03-28 at 10:06 -0800, Behcet Sarikaya wrote: > > > I agree with Gabriel. We should not meet if there is not much to > > > do/not enough attendance is expected, etc. I think that not many > > > people were happy with the last interim. > > > > > > Regards, > > > > > > Behcet > > > > > > gabriel montenegro wrote: > > > > Why is an interim needed? > > > > What would be the agenda and desired outcome of this meeting? > > > > What do we need to get done before we're ready for such a meeting? > > > > > > > > > I'd vote for Jacksonville, but really, without a clearer idea of > the above I'd be > > unable > > > > to justify this expense in time and money. > > > > > > > > -gabriel > > > > > > > > --- Schumacher Christian Peter Pii wrote: > > > > > > > > > > > > > Dear 6lowpanners > > > > > > > > > > There has been suggested the following locations for a 2-day > interim > > > > > meeting: > > > > > > > > > > - Europe: > > > > > Danfoss A/S, Denmark > > > > > TZI, Germany > > > > > - Canada: > > > > > In connection with WiMAX F2F meeting in Ottawa, May > 23-25 > > > > > - USA: > > > > > In connection (possibly May 11-12) with IEEE 802 Interim > in > > > > > Jacksonville, May14-19 > > > > > > > > > > Please reply your preference to this mail and CC the mailing > list, so we > > > > > can determine the overall preference. > > > > > > > > > > Deadline for this poll is Friday 7th of April. > > > > > > > > > > Regards > > > > > Christian Schumacher > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 6lowpan mailing list > > > > > 6lowpan@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > http://mail.yahoo.com > > > > > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > ------=_Part_3146_14058710.1145846588404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Christian,
Please count me in.  I am in pacific time zone. 10am -3pm and 9pm= - 11pm (PDT) are
good for me generally for teleconference.
 
Thanks,
-Samita


 
On 4/20/06, = Schumacher Christian Peter Pii <schumacher@danfoss.com> wrote:
Dear all.

Gabriel pointed= out in a previous mail, that it might be a good idea to
give teleconfer= encing a shot. How many are interested in this? Please
list preferred weekday and time (in GMT).

Regards
Christian
-----Original Message-----
From: gabriel montenegro [mailto:gabriel_montenegro_2000@yaho= o.com ]
Sent: 31. marts 2006 00:30
To: Geoff Mulligan; sarikaya@ieee.org
Cc: 6lowpan
Subject: Re: [= 6lowpan] poll for interim meeting locations

Just to clarify: I think= the interim we had was very productive and wish
we had had
more time. I'm one of the happy ones. And if it makes sen= se, I'm all for
having
another productive one (as per the subject lin= e in this message).

All I'm saying is that every interim/meeting is = an expense in time and
money, and
it's good to have as much info in advance in order to wei= gh the
priorities with other
commitments. Things like teleconferences= are used regularly in IEEE or
other venues,
and that's perhaps somet= hing to explore as well.

-gabriel

--- Geoff Mulligan <geoff@mulligan.com> wrote:

> While a do agree th= at we should not meet if we do not have clear
agenda
> and take ex= ception to your characterization that people were not happy
> with the last interim.
>
> Everyone that I have spoken= with were pleased with the progress that
we
> made and the topics= covered at the interim and felt that it was very
> productive and us= eful.
>
> If that is not the case, please speak up.
>
>&= nbsp;      geoff
>
> On Tue, 2006-03-2= 8 at 10:06 -0800, Behcet Sarikaya wrote:
> > I agree with Gabriel.= We should not meet if there is not much to
> > do/not enough attendance is expected, etc. I think that not m= any
> > people were happy with the last interim.
> >
&= gt; > Regards,
> >
> > Behcet
> >
> >= ; gabriel montenegro wrote:
> > > Why is an interim needed?
> > > What would b= e the agenda and desired outcome of this meeting?
> > > What do= we need to get done before we're ready for such a meeting?

> >= ; >
> > > I'd vote for Jacksonville, but really, without a clearer= idea of
the above I'd be
> unable
> > > to justify th= is expense in time and money.
> > >
> > > -gabriel
> > >
> > > --- Schumacher Christian Peter Pii <= ;schumacher@danfoss.com> w= rote:
> > >
> > >
> > > > Dear 6lowp= anners
> > > >
> > > > There has been suggested the= following locations for a 2-day
interim
> > > > meeting:=
> > > >
> > > > - Europe:
> > > = >         Danfoss A/S, Denmark
> > > >         TZI= , Germany
> > > > - Canada:
> > > > &nbs= p;       In connection with WiMAX F2F meeting= in Ottawa, May
23-25
> > > > - USA:
> > > &g= t;         In connection (possibly = May 11-12) with IEEE 802 Interim
in
> > > > Jacksonville, May14-19
> > > >=
> > > > Please reply your preference to this mail and CC th= e mailing
list, so we
> > > > can determine the overall p= reference.
> > > >
> > > > Deadline for this poll is Fr= iday 7th of April.
> > > >
> > > > Regards> > > > Christian Schumacher
> > > >
> &g= t; > >
> > > >
> > > > > _______________________= ________________________
> > > > >
> > > >= 6lowpan mailing list
> > > > 6lowpan@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/6lowpan<= /a>
> > > >
> > > >
> > >
>= > >
> > > __________________________________________________
&g= t; > > Do You Yahoo!?
> > > Tired of spam?  Yah= oo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > _____________= __________________________________
> > > 6lowpan mailing list> > > 6lowpan@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/6lowpan
> > >
= > > >
> > >
> > _____________________________= __________________
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan
>
>


_______________________________________________= ___
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best= spam protection around
http://mail.ya= hoo.com

_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www1.ietf.org/m= ailman/listinfo/6lowpan

_______________________________________________
6lowpan mail= ing list
6lowpan@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/6lowpan

------=_Part_3146_14058710.1145846588404-- --===============1312316550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1312316550==-- From 6lowpan-bounces@ietf.org Sun Apr 23 23:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXrdj-0004Ew-Nl; Sun, 23 Apr 2006 23:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXrdi-0004El-2m for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 23:21:30 -0400 Received: from xproxy.gmail.com ([66.249.82.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXrde-0000kJ-HG for 6lowpan@lists.ietf.org; Sun, 23 Apr 2006 23:21:30 -0400 Received: by xproxy.gmail.com with SMTP id s12so634189wxc for <6lowpan@lists.ietf.org>; Sun, 23 Apr 2006 20:21:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=idbZdb3nbgsyc4xCJG0L7XswZMYmOHwL2o2cDnzVuQiTI4eBo+2louCpMAp/KQuRrSzfBqXun4taB0361FMdkm8VUCNaDWJv1PuWsUepJKoK8T/HQK/3c5mGB/pLJExewQFdvqv0ZJcENs/fhO31OUH4spe+gELR0r+cEM4OxWU= Received: by 10.70.12.4 with SMTP id 4mr2981978wxl; Sun, 23 Apr 2006 20:21:25 -0700 (PDT) Received: from icom ( [202.30.3.197]) by mx.gmail.com with ESMTP id i37sm2531009wxd.2006.04.23.20.21.14; Sun, 23 Apr 2006 20:21:25 -0700 (PDT) From: "Ki-Hyung Kim" To: "'Schumacher Christian Peter Pii'" , "'6lowpan'" <6lowpan@lists.ietf.org> Subject: RE: [6lowpan] poll for interim meeting locations Date: Mon, 24 Apr 2006 12:21:09 +0900 Message-ID: <002701c6674e$296c47f0$c5031eca@icom> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZUSXXFcPsLLGB3QSaVx+omqgJ/WwQC13SwAL1nXFA= In-Reply-To: <49A38D2FE2C53946A57916AD6A1F00D787EDAC@DKDN01MX34.danfoss.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Christian, I also believe that we had a very productive interim meeting last time and we need another chance of communication (off-site or teleconference) before next IETF. I prefer to have an off-site interim, but teleconference is OK too if we don't have enough time to prepare it. My preferred time of teleconference is 17:00 ~ 20:00 PDT. (which is 9:00 ~ 12:00 in Korea local time). -- Ki-Hyung Kim Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://www.6lowpan.org http://ilab.ajou.ac.kr/kkim86/index.htm -----Original Message----- From: Schumacher Christian Peter Pii [mailto:schumacher@danfoss.com] Sent: Thursday, April 20, 2006 5:40 PM To: 6lowpan Subject: FW: [6lowpan] poll for interim meeting locations Dear all. Gabriel pointed out in a previous mail, that it might be a good idea to give teleconferencing a shot. How many are interested in this? Please list preferred weekday and time (in GMT). Regards Christian -----Original Message----- From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com] Sent: 31. marts 2006 00:30 To: Geoff Mulligan; sarikaya@ieee.org Cc: 6lowpan Subject: Re: [6lowpan] poll for interim meeting locations Just to clarify: I think the interim we had was very productive and wish we had had more time. I'm one of the happy ones. And if it makes sense, I'm all for having another productive one (as per the subject line in this message). All I'm saying is that every interim/meeting is an expense in time and money, and it's good to have as much info in advance in order to weigh the priorities with other commitments. Things like teleconferences are used regularly in IEEE or other venues, and that's perhaps something to explore as well. -gabriel --- Geoff Mulligan wrote: > While a do agree that we should not meet if we do not have clear agenda > and take exception to your characterization that people were not happy > with the last interim. > > Everyone that I have spoken with were pleased with the progress that we > made and the topics covered at the interim and felt that it was very > productive and useful. > > If that is not the case, please speak up. > > geoff > > On Tue, 2006-03-28 at 10:06 -0800, Behcet Sarikaya wrote: > > I agree with Gabriel. We should not meet if there is not much to > > do/not enough attendance is expected, etc. I think that not many > > people were happy with the last interim. > > > > Regards, > > > > Behcet > > > > gabriel montenegro wrote: > > > Why is an interim needed? > > > What would be the agenda and desired outcome of this meeting? > > > What do we need to get done before we're ready for such a meeting? > > > > > > I'd vote for Jacksonville, but really, without a clearer idea of the above I'd be > unable > > > to justify this expense in time and money. > > > > > > -gabriel > > > > > > --- Schumacher Christian Peter Pii wrote: > > > > > > > > > > Dear 6lowpanners > > > > > > > > There has been suggested the following locations for a 2-day interim > > > > meeting: > > > > > > > > - Europe: > > > > Danfoss A/S, Denmark > > > > TZI, Germany > > > > - Canada: > > > > In connection with WiMAX F2F meeting in Ottawa, May 23-25 > > > > - USA: > > > > In connection (possibly May 11-12) with IEEE 802 Interim in > > > > Jacksonville, May14-19 > > > > > > > > Please reply your preference to this mail and CC the mailing list, so we > > > > can determine the overall preference. > > > > > > > > Deadline for this poll is Friday 7th of April. > > > > > > > > Regards > > > > Christian Schumacher > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Apr 24 04:56:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXwrz-0004ph-R5; Mon, 24 Apr 2006 04:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXwry-0004pc-LS for 6lowpan@lists.ietf.org; Mon, 24 Apr 2006 04:56:34 -0400 Received: from violet.upc.es ([147.83.2.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXwrx-0008Kc-1q for 6lowpan@lists.ietf.org; Mon, 24 Apr 2006 04:56:34 -0400 Received: from violet.upc.es (localhost [127.0.0.1]) by violet.upc.es (8.13.6/8.13.6) with ESMTP id k3O8sb9G000888 for <6lowpan@lists.ietf.org>; Mon, 24 Apr 2006 10:56:31 +0200 Received: from localhost (wmail-mat.upc.es [147.83.39.70]) by violet.upc.es (8.13.6/8.13.6) with ESMTP id k3O8onGp032699 for <6lowpan@lists.ietf.org>; Mon, 24 Apr 2006 10:50:49 +0200 Received: from 147.83.39.92 ( [147.83.39.92]) as user peres@mat.upc.es by wmail-mat.upc.es with HTTP; Mon, 24 Apr 2006 10:27:21 +0200 Message-ID: <1145867241.444c8be92c078@wmail-mat.upc.es> Date: Mon, 24 Apr 2006 10:27:21 +0200 From: Pere Salvatella To: 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 147.83.39.92 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [6lowpan] routing protocol comments X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear all, I'm currently working on routing protocols at sensor networks following the guidelines marked by 6lowpan WG. I have continued with interest the evolutions of routing protocols indicated in both drafts LOAD and DYMO, and precisely I would like to denote the recent expiration of the draft describing the last one of these protocols. This initial draft DYMO-low-routing-00 expired last April 15, without no reference since its publication in this list. The only reference was some discussion on list stating the benefits offered by DYMO. The only reference in this list was a brief discussion to determine the advantages among the above mentioned protocol and the solution offered by LOAD, without any technical discussion that brings over of its functionality and specifications. Is there any interest on continuing ther work with Dymo-low ? Also I would like to give some comments related to the above mentioned protocol considering inaccuracies with the usage of sequence numbers. draft-montenegro-6lowpan-dymo-low-routing-00 (Section 4.7 ): This section states that the sequence numbers follow DYMO's directives, nevertheless in the definition of the Routing Table structure lacks on a specific field to store information relative to the above mentioned parameter. As well I think it should be most accurately described on the way they should be used. As well, is there any directive on how to add sequence numbers on LOAD specs? last comments point out that this functionality should be necessary to prevent routing loops if we want to use local repair functionality Sincerely ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 25 22:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZSw-0005ZE-Kd; Tue, 25 Apr 2006 22:09:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZSv-0005Z9-Bx for 6lowpan@lists.ietf.org; Tue, 25 Apr 2006 22:09:17 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYZSt-0000JB-Mz for 6lowpan@lists.ietf.org; Tue, 25 Apr 2006 22:09:17 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IYB0070X4MN6V@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Wed, 26 Apr 2006 11:08:47 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IYB006TU4MNRF@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Wed, 26 Apr 2006 11:08:47 +0900 (KST) Date: Wed, 26 Apr 2006 11:09:01 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] routing protocol comments To: Pere Salvatella , 6lowpan <6lowpan@lists.ietf.org> Message-id: <017301c668d6$62d3b710$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1145867241.444c8be92c078@wmail-mat.upc.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Pere - Please see my comments inline. > This initial draft DYMO-low-routing-00 expired last April 15, without no > reference since its publication in this list. The only reference was > some discussion on list stating the benefits offered by DYMO. The only > reference in this list was a brief discussion to determine the advantages > among the above mentioned protocol and the solution offered by LOAD, without > any technical discussion that brings over of its functionality and > specifications. Is there any interest on continuing ther work with Dymo-low ? This item is beyond a scope existing 6lowpan charter at this stage. That will be taken care of a rechartering. After then, we will begin a real work. Still, it is not mature status at all. So, please be patient at a moment. > Also I would like to give some comments related to the above mentioned > protocol considering inaccuracies with the usage of sequence numbers. > draft-montenegro-6lowpan-dymo-low-routing-00 (Section 4.7 ): > This section states that the sequence numbers follow DYMO's > directives, nevertheless in the definition of the Routing Table structure > lacks > on a specific field to store information relative to the above mentioned > parameter. As well I think it should be most accurately described on the way > they should be used. > > As well, is there any directive on how to add sequence numbers on LOAD specs? > last comments point out that this functionality should be necessary > to prevent routing loops if we want to use local repair functionality Same above. We also have several issues to be resolved by 6lowpan discussion from our evaluation led by Prof. Ki-Hyung Kim. I will catch up with your comments soon. Anyway, thanks your comment and interest. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Apr 28 20:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZdaG-0000PA-52; Fri, 28 Apr 2006 20:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZdaF-0000P5-N4 for 6lowpan@ietf.org; Fri, 28 Apr 2006 20:45:15 -0400 Received: from nz-out-0102.google.com ([64.233.162.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZdaD-0008S4-Du for 6lowpan@ietf.org; Fri, 28 Apr 2006 20:45:15 -0400 Received: by nz-out-0102.google.com with SMTP id s1so2038810nze for <6lowpan@ietf.org>; Fri, 28 Apr 2006 17:45:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WwPPeuqyU4H81LvFU+dJ3mDvg/7WqJAKaJoI03V45DRWFe6G2k+tFMYvgQbP8nnhYHLKider4v7ZVukgOavNvXzxWf9xcUDGxLlh/AAQbQvlELPKSXBJMDGVcZaCmPLEXnH6qAFyIsH2QKmrnkRsss3ScBJnoTm68H64Uzob6ho= Received: by 10.65.95.6 with SMTP id x6mr2955045qbl; Fri, 28 Apr 2006 17:45:12 -0700 (PDT) Received: by 10.64.148.8 with HTTP; Fri, 28 Apr 2006 17:45:12 -0700 (PDT) Message-ID: <43b91d370604281745j765a191bp22843d890af5eab9@mail.gmail.com> Date: Fri, 28 Apr 2006 17:45:12 -0700 From: "Samita Chakrabarti" To: "gabriel montenegro" , 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [6lowpan] Comments on the Format-02 document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128755000==" Errors-To: 6lowpan-bounces@ietf.org --===============2128755000== Content-Type: multipart/alternative; boundary="----=_Part_7549_13600562.1146271512679" ------=_Part_7549_13600562.1146271512679 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Gabriel: Here are some comments on the latest version of the format document. Hope they are not too late. Thanks, -Samita Nits: Typo in Introduction: Likewise, the provisions required for packet delivery in IEEE 802.15.4meshes defined. Section 2. "As usual, hosts learn IPv6 prefixes via router advertisements ([ I-D.ietf-ipv6-2461bis])." Does it make sense to mention about ND for lowpan work in this context as well ? Section 4 ( Reassembly): Each fragment contains "datagram_size" and datagram_tag and offset. Should "datagram_size" be replaced by "fragment_size" for the fragmented packets ? Is there anyway, during re-assembly one would know about the fragment payload size ? Note that the offset and datagram_size do not provide the info on the current fragment size. Section 7. Please have a subheading for defining the IPv6 SLLA, TLLA option formats. On the first look, it is a bit confusing as it seems IPv6 unicast address mapping from the 802.15.4 short and long addresses. Section 8. Please clarify that multicast 802.15.4 address is 16bit address. Q: Can IETF specify such L2 addressing and specification ? Is there any plan on IEEE to accomodate this feature? The rest looks ok to me. The header compression part is a bit tricky and complex. Should this draft suggest a default header compression scheme for a suggestion to the implementors? ------=_Part_7549_13600562.1146271512679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Gabriel:
 
Here are some comments on the latest version of the format document.
Hope they are not too late.
 
Thanks,
-Samita
 

Nits:

Typo in Introduction:

Likewise, the provisions required for packet delivery in IEEE 802.15.4 m= eshes  <is> defined.

Section 2.

"As usual, hosts learn IPv6 prefixes via router advertisements ([I-= D.ietf-ipv6-2461bis])."

Does it make sense to mention about ND for lowpan work in this context a= s well ?

 

Section 4 ( Reassembly):

Each fragment contains "datagram_size" and datagram_tag and of= fset.

Should "datagram_size" be replaced by "fragment_size"= ; for the fragmented

packets ? Is there anyway, during re-assembly one would know about the

fragment payload size ? Note that the offset and datagram_size do not

provide the info on the current fragment size.

 

Section 7.

Please have a subheading for defining the IPv6 SLLA, TLLA option formats= .

On the first look, it is a bit confusing as it seems IPv6 unicast addres= s

mapping from the 802.15.4 short and long addresses.

Section 8.

Please clarify that multicast 802.15.4 address is 16bit address.

Q: Can IETF specify such L2 addressing and specification ? Is there

any plan on IEEE to accomodate this feature?

 

The rest looks ok to me. The header compression part is a bit tricky

and complex. Should this draft suggest a default header compression

scheme for a suggestion to the implementors?

------=_Part_7549_13600562.1146271512679-- --===============2128755000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============2128755000==-- From 6lowpan-bounces@ietf.org Sun Apr 30 14:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGRf-0006GP-2i; Sun, 30 Apr 2006 14:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGRd-0006GK-JR for 6lowpan@lists.ietf.org; Sun, 30 Apr 2006 14:14:57 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaGRa-0005Nb-AJ for 6lowpan@lists.ietf.org; Sun, 30 Apr 2006 14:14:57 -0400 Received: by nz-out-0102.google.com with SMTP id o37so2417834nzf for <6lowpan@lists.ietf.org>; Sun, 30 Apr 2006 11:14:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=Wi2v8oP+M1Wr1cqPo0+UFMvW8FLuOfdu4oxyRprMhr2eZTzvas+XJXXQpqfjLs/9YG7DgiHanCmzTK4aiODH7JYaqKlgReHi8M76sae1i+DmJNQ3+Lzj/jEaW5u28r2du0Q1R5oL11HVDTAs3kQNHcsQKPIlXAv6bA26RNZIYbk= Received: by 10.64.153.2 with SMTP id a2mr168181qbe; Sun, 30 Apr 2006 11:14:52 -0700 (PDT) Received: by 10.64.199.6 with HTTP; Sun, 30 Apr 2006 11:14:52 -0700 (PDT) Message-ID: Date: Mon, 1 May 2006 03:14:52 +0900 From: "Ki-Hyung Kim" To: 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [6lowpan] Comment on the format document for IPv6-multicast support X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0960839647==" Errors-To: 6lowpan-bounces@ietf.org --===============0960839647== Content-Type: multipart/alternative; boundary="----=_Part_6983_12157353.1146420892212" ------=_Part_6983_12157353.1146420892212 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Gabriel and 6lowpaners, I want to raise an issue of supporting IPv6-multicast in 6lowpan. There are some cases which might require multicasting in 6lowpan such as packet transmission with multicast targets (0xFF~), Neighbor or Router advertisements. We can optimize some multicast by using an optimization technique, e.g. ND optimization, but not for all cases such as multicast targets(0xFF). Because the link layer of 6lowpan does not support multicast, multicast should be realized by broadcast (or flooding). My question is whether the current format document does support the broadcasting(or flooding) or not. It is clear that broadcast ID should exist on the adaptation layer for supporting broadcasting(or flooding) at the adaptation layer. ( in order to avoid duplicate handling of the same broadcast messages on a node) Is there a mechanism of broadcast ID in the current format document? If the adaptation layer does not have the mechanism, I believe that we should include it. What is your opinions? -- Ki-Hyung Kim Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://www.6lowpan.org ------=_Part_6983_12157353.1146420892212 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Gabriel and 6lowpaners,
 
I want to raise an issue of supporting IPv6-multicast in 6lowpan.=
 
There are some cases which might require multicasting in 6lowpan such = as packet transmission with multicast targets (0xFF~), Neighbor or Router a= dvertisements.
We can optimize some multicast by using an optimization technique, e.g= . ND optimization, but not for all cases such as multicast targets(0xFF).
Because the link layer of 6lowpan does not support multicast, multicas= t should be realized by broadcast (or flooding).
 
My question is whether the current format document does support t= he broadcasting(or flooding) or not.
It is clear that broadcast ID should exist on the adaptation layer for= supporting broadcasting(or flooding) at the adaptation layer. ( in order t= o avoid duplicate handling of the same broadcast messages on a no= de)
Is there a mechanism of broadcast ID in the current format document? I= f the adaptation layer does not have the mechanism, I believ= e that we should include it.
 
What is your opinions?
 

--
Ki-Hyung Kim
Associate Professor
Division of Information and Computer Eng., Ajou= University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-= 2551,  Fax: +82-31-219-2433 ht= tp://www.6lowpan.org
------=_Part_6983_12157353.1146420892212-- --===============0960839647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0960839647==-- From 6lowpan-bounces@ietf.org Sun Apr 30 19:30:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaLMj-0005NU-FF; Sun, 30 Apr 2006 19:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaLMi-0005Hh-AS for 6lowpan@lists.ietf.org; Sun, 30 Apr 2006 19:30:12 -0400 Received: from nz-out-0102.google.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaLMe-0001bo-2c for 6lowpan@lists.ietf.org; Sun, 30 Apr 2006 19:30:12 -0400 Received: by nz-out-0102.google.com with SMTP id n1so2653695nzf for <6lowpan@lists.ietf.org>; Sun, 30 Apr 2006 16:30:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a+G6tUrMqfAdpC0glJZdYoAn2sfM9WcZSAGRwHcjcl+It9eOyYUQc21PZTBNe2nZ5xrwC5aMN30SnLBvj3BP56I5plKn3CfEFe7zHV2lKw+V4gSIs+qb40h13xWZYMjKTY1otg9A9U1v+ZW8UrlRbUMwsd1WXM0I2xbihL3Detk= Received: by 10.36.39.9 with SMTP id m9mr1302257nzm; Sun, 30 Apr 2006 16:30:07 -0700 (PDT) Received: by 10.37.18.76 with HTTP; Sun, 30 Apr 2006 16:30:07 -0700 (PDT) Message-ID: <374005f30604301630l67d97e4t2f752d1e53da4e61@mail.gmail.com> Date: Sun, 30 Apr 2006 16:30:07 -0700 From: "Ian Chakeres" To: "Ki-Hyung Kim" Subject: Re: [6lowpan] Comment on the format document for IPv6-multicast support In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I think that the L2 shim should have a sequence number for emulated broadcast/multicast. This sequence number will be used for duplicate packet detection (DPD). For more information please see the SMF document, a MANET WG ID. Ian On 4/30/06, Ki-Hyung Kim wrote: > > Hi Gabriel and 6lowpaners, > > I want to raise an issue of supporting IPv6-multicast in 6lowpan. > > There are some cases which might require multicasting in 6lowpan such as > packet transmission with multicast targets (0xFF~), Neighbor or Router > advertisements. > We can optimize some multicast by using an optimization technique, e.g. N= D > optimization, but not for all cases such as multicast targets(0xFF). > Because the link layer of 6lowpan does not support multicast, multicast > should be realized by broadcast (or flooding). > > My question is whether the current format document does support the > broadcasting(or flooding) or not. > It is clear that broadcast ID should exist on the adaptation layer for > supporting broadcasting(or flooding) at the adaptation layer. ( in order = to > avoid duplicate handling of the same broadcast messages on a node) > Is there a mechanism of broadcast ID in the current format document? If t= he > adaptation layer does not have the mechanism, I believe that we should > include it. > > What is your opinions? > > > > -- > Ki-Hyung Kim > Associate Professor > Division of Information and Computer Eng., Ajou University, Suwon, Korea > 442-749 > Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 > http://www.6lowpan.org > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan