From 6lowpan-bounces@ietf.org Fri Sep 09 18:04:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EDqyW-0005vk-BT; Fri, 09 Sep 2005 18:04:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EDqyU-0005s7-Av
	for 6lowpan@megatron.ietf.org; Fri, 09 Sep 2005 18:03:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12304
	for <6lowpan@ietf.org>; Fri, 9 Sep 2005 18:03:53 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDr24-0002pS-EQ
	for 6lowpan@ietf.org; Fri, 09 Sep 2005 18:07:43 -0400
Received: from jurassic.eng.sun.com ([129.146.226.130])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j89M3m1L012711; 
	Fri, 9 Sep 2005 16:03:48 -0600 (MDT)
Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85])
	by jurassic.eng.sun.com (8.13.5.Beta1+Sun/8.13.5.Beta1) with SMTP id
	j89M3mEx341893; Fri, 9 Sep 2005 15:03:48 -0700 (PDT)
Message-Id: <200509092203.j89M3mEx341893@jurassic.eng.sun.com>
Date: Fri, 9 Sep 2005 15:02:05 -0700 (PDT)
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
To: nandakishore.kushalnagar@intel.com, itijibox-6lowpan@yahoo.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LcZkGGDEupi9Tys+2pl97Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: 6lowpan@ietf.org
Subject: [6lowpan] lowpan-aodv draft comments
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Sender: 6lowpan-bounces@ietf.org
Errors-To: 6lowpan-bounces@ietf.org

Hello Gabriel and Nandu:

I have recently reviewed draft-montenegro-lowpan-aodv-00.

Here are some questions and comments:

* DYMO would be replacing AODV in future. Are we working on
  AODV lowpan because of Zigbee compatibility or because
  availability of experimental RFC3561 ? 
  
* The draft refers to *aodvbis*, but the aodvbis draft has expired.
  Is there a plan for aodvbis draft to make progress for another RFC?
  If that is not the case, then I am happy to see that this draft defines
  the aodvbis format in this draft and go forward as 'lowpan-aodv' protocol.
   Otherwise, we should follow either RFC3561 format or DYMO format.
  
*  The lowpan-aodv draft requires only RREQ and RREP for control data.
    How about RERR for propagating error messages back to the sender ?
    AFAIK, the L2 ACK failure may detect a link failure in the intermediate
    node during a data transfer, should not it send an error message back
    to the sender(previous node) of the packet ? 
    Should the intermediate node do route repairing on behalf of the 
    sender node?
    
*   Also, aodvbis or dymo appends intermediate node information at each
    hop with the RREQ and RREP control packet. This increases the length
    of the control packet unnecessarily. In IEEE802.15.4 network, these
    additional bits are undesirable, as we know. It is a good idea that
    lowpan-aodv draft recommends not to use additional path node information
    on the RREQ and recommends APN-count to be zero in the RREP.
    
 *   The lowpan-aodv draft also needs to discuss Hostid size field values
     for lowpan. 
     
 When are you planning to publish the next revision of this draft?
 
 Thanks,
 -Samita


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



From 6lowpan-bounces@ietf.org Fri Sep 09 23:35:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EDw9W-000626-QB; Fri, 09 Sep 2005 23:35:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EDw9T-0005zs-4h
	for 6lowpan@megatron.ietf.org; Fri, 09 Sep 2005 23:35:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00694
	for <6lowpan@ietf.org>; Fri, 9 Sep 2005 23:35:35 -0400 (EDT)
Received: from mailout2.samsung.com ([203.254.224.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDwCq-000333-Rh
	for 6lowpan@ietf.org; Fri, 09 Sep 2005 23:39:28 -0400
Received: from ep_mmp1 (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 <0IML00AVX0MFWL@mailout2.samsung.com> for
	6lowpan@ietf.org; Sat, 10 Sep 2005 12:35:03 +0900 (KST)
Received: from natpt ([168.219.198.109])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IML001210MF20@mmp1.samsung.com> for 6lowpan@ietf.org;
	Sat, 10 Sep 2005 12:35:03 +0900 (KST)
Date: Sat, 10 Sep 2005 12:34:57 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: Re: [6lowpan] lowpan-aodv draft comments
To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>,
	nandakishore.kushalnagar@intel.com, itijibox-6lowpan@yahoo.com
Message-id: <005c01c5b5b8$9e014360$6dc6dba8@natpt>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200509092203.j89M3mEx341893@jurassic.eng.sun.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7BIT
Cc: 6lowpan@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: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Sender: 6lowpan-bounces@ietf.org
Errors-To: 6lowpan-bounces@ietf.org

Samita, 

>  When are you planning to publish the next revision of this draft?

Obviously, you have to refer a new version here;
http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt
which is updating what you are refering...


Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
----- Original Message ----- 
From: "Samita Chakrabarti" <Samita.Chakrabarti@eng.sun.com>
To: <nandakishore.kushalnagar@intel.com>; <itijibox-6lowpan@yahoo.com>
Cc: <6lowpan@ietf.org>
Sent: Saturday, September 10, 2005 7:02 AM
Subject: [6lowpan] lowpan-aodv draft comments


> Hello Gabriel and Nandu:
> 
> I have recently reviewed draft-montenegro-lowpan-aodv-00.
> 
> Here are some questions and comments:
> 
> * DYMO would be replacing AODV in future. Are we working on
>   AODV lowpan because of Zigbee compatibility or because
>   availability of experimental RFC3561 ? 
>   
> * The draft refers to *aodvbis*, but the aodvbis draft has expired.
>   Is there a plan for aodvbis draft to make progress for another RFC?
>   If that is not the case, then I am happy to see that this draft defines
>   the aodvbis format in this draft and go forward as 'lowpan-aodv' protocol.
>    Otherwise, we should follow either RFC3561 format or DYMO format.
>   
> *  The lowpan-aodv draft requires only RREQ and RREP for control data.
>     How about RERR for propagating error messages back to the sender ?
>     AFAIK, the L2 ACK failure may detect a link failure in the intermediate
>     node during a data transfer, should not it send an error message back
>     to the sender(previous node) of the packet ? 
>     Should the intermediate node do route repairing on behalf of the 
>     sender node?
>     
> *   Also, aodvbis or dymo appends intermediate node information at each
>     hop with the RREQ and RREP control packet. This increases the length
>     of the control packet unnecessarily. In IEEE802.15.4 network, these
>     additional bits are undesirable, as we know. It is a good idea that
>     lowpan-aodv draft recommends not to use additional path node information
>     on the RREQ and recommends APN-count to be zero in the RREP.
>     
>  *   The lowpan-aodv draft also needs to discuss Hostid size field values
>      for lowpan. 
>      

>  
>  Thanks,
>  -Samita
> 
> 
> _______________________________________________
> 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 Sat Sep 10 00:00:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EDwXp-0003VG-B2; Sat, 10 Sep 2005 00:00:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EDwXo-0003Ug-81
	for 6lowpan@megatron.ietf.org; Sat, 10 Sep 2005 00:00:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01533
	for <6lowpan@ietf.org>; Sat, 10 Sep 2005 00:00:44 -0400 (EDT)
Received: from mailout1.samsung.com ([203.254.224.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDwbU-0003fW-By
	for 6lowpan@ietf.org; Sat, 10 Sep 2005 00:04:38 -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 <0IML00DIN1SVU8@mailout1.samsung.com> for
	6lowpan@ietf.org; Sat, 10 Sep 2005 13:00:31 +0900 (KST)
Received: from natpt ([168.219.198.109])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IML00HK71SUOK@mmp1.samsung.com> for 6lowpan@ietf.org;
	Sat, 10 Sep 2005 13:00:31 +0900 (KST)
Date: Sat, 10 Sep 2005 13:00:25 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: Re: [6lowpan] Fwd:
	I-DACTION:draft-daniel-6lowpan-interoperability-01.txt
To: Tiago Camilo <tandre@dei.uc.pt>
Message-id: <00a701c5b5bc$2c9860b0$6dc6dba8@natpt>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <1122968823.42ef24f73a60f@mail.dei.uc.pt>
	<007f01c59742$e41bf3c0$d018ff56@samsung70c651a>
	<1122980048.42ef50d0baad0@mail.dei.uc.pt>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7BIT
Cc: 6lowpan@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: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Sender: 6lowpan-bounces@ietf.org
Errors-To: 6lowpan-bounces@ietf.org

> tc: I see one very important issue concerning authorization, because if no
> method is used, one can requesting infinity the lowpan network, which will
> reduce dramatic the energy levels..

I know this issue is also beyond scope of current charter of 6lowpan. However, I think we need some of light-weight security protocols for 6lowpan network though I don't have any idea this time...


Regards,

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

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



