Subject: [6lowpan] WG rechartering

From: Geoff Mulligan <[email-masked]>
Date: Tue, 06 Feb 2007 08:14:45 -0700

Folks,
  We have reached a milestone.  We have submitted the Problem Statement
document and the Format Document to our AD for publication.  We have
completed the original charter of the WG.

Mark will review the documents and then submit them for IETF LC (2
weeks) and then IESG review and discussion, which will hopefully happen
on the IESG telechat on March 8th.

So now it is very important that we finalize our thoughts about
rechartering the Working Group for new work, should we want to take on
new work.

Some of the items that people have indicated interest in working on:
  Neighbor Discovery and Secure Neighbor Discovery (proposed standard)
  Stateful header compression (informational)
  6lowpan applications (informational)
  mesh routing (proposed standard)
  Security analysis (informational)

If there are other ideas as to work the WG should be looking at, please
send them to the list.  If you think that we are finished, please send
that to the list also.

We plan to have a call with our AD next Monday the 12th and I would like
to hear from the group before then.

	geoff

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 6 Feb 2007 10:53:49 -0800

Hi Geoff,

The list looks good.

Last time we also discussed a need for a document on boot-strapping.
Is it still on the agenda?  Personally I prefer bootstrapping should be a
separate document; we also have to figure out the requirements for
bootstrapping in this space.

The second point is on mobility analysis - recently with MANEMO (Network
mobility for MANET) discussion, some interesting points came out regarding
6lowpan mobility. Daniel Park, Jim Bound brought this up and
we are working on updating
my expired draft on 6lowpan mobility requirements.  So, may be we can keep
mobility item in the radar if not on the charter list for now.

Thanks,
-Samita

---

From: Daniel Park <[email-masked]>
Date: Wed, 07 Feb 2007 09:08:40 +0900

Bootstrapping is one of important issues around 6lowpan,
hence I agree with Samita's suggestion as well. 

Regarding 6lowpan mobility, MANEMO looks like a relevant
place within IETF as of today, but INT AD's decision does
not allow us to have a BOF in Prague at this stage.

Anyhow, I am suggesting 6lowpan mobility for further study
as one of rechartering items. As Samita pointed out, its 
problem statements are already available and we are in the
progress of ellaborating on that.

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

---

From: Myung-Ki Shin <[email-masked]>
Date: Wed, 07 Feb 2007 09:30:31 +0900

Hi folks,

I agree with Samita.
Specially, I'm interested in mobility item too.
I think it is time to take on this item in the WG.

Thanks,
Myung-Ki,

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Wed, 7 Feb 2007 11:28:39 +0900

Bootstrapping is one of the important issues. I think commissioning might be
more appropriate term which can include bootstrapping as a core protocol.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Wed, 7 Feb 2007 11:44:41 +0900

Geoff,
Congratulation. We are now eventually moving forward to the recharting
stage.
I remember that we have discussed a couple of additional rechartering items
in addition to the mentioned items from the beginning including the interrim
meeting.
I want to remind these some of the core rechartering items as follows:
1) Scalable routing protocol. While mesh routing could offer optimised
routing path, it consumes memory of sensor node for routing
table.   Together with Mesh routing protocol, Scalable routing protocol
provides a routing table-free routing mechanism which is essential for
memory constrained sensor nodes.

2) Service discovery protocol. It could offer lots of potential for wide
deployment of sensor network services.

3) 6LoWPAN management. It should be essential items.

4) Commissioning protocol which includes bootstrapping. It should be
essential items for interoperability of 6lowpan nodes.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Tue, 6 Feb 2007 22:11:08 -0800

>   Security analysis (informational)

Moving forward, I think that mesh routing is the most important  
problem. But neighbor discovery and bootstrapping are prerequisites  
for mesh routing, so I think that we need to tackle them first.

Phil

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 07 Feb 2007 10:31:41 -0700

We did discuss this at the interim.  I'm trying to make a full list, so
everyone keep sending in suggestions and then we will attempt to
prioritize them.

	geoff

On Wed, 2007-02-07 at 11:44 +0900, Ki-Hyung Kim wrote:
> I remember that we have discussed a couple of additional rechartering
> items in addition to the mentioned items from the beginning including
> the interrim meeting.
> table.   Together with Mesh routing protocol, Scalable routing
> protocol provides a routing table-free routing mechanism which is
> essential for memory constrained sensor nodes.
>  
> 2) Service discovery protocol. It could offer lots of potential for
> wide deployment of sensor network services.
>  
> Division of Information and Computer Eng., Ajou University, Suwon,
> Korea 442-749

---

From: "Myung J Lee" <[email-masked]>
Date: Thu, 8 Feb 2007 10:36:52 -0500

Hi Geoff,

Power saving algorithm could be an essential element for sensor
networks. 
Given 15.4, we could consider both beacon-enabled and non-beacon
enabled modes.

Thanks, 

Myung J. Lee

-----Original Message-----
From: Geoff Mulligan [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 12:32 PM
To: Ki-Hyung Kim
Cc: 6lowpan
Subject: Re: [6lowpan] WG rechartering

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 08 Feb 2007 09:13:24 -0700

I've added it to the list.

	geoff

---

From: Daniel Park <[email-masked]>
Date: Fri, 09 Feb 2007 08:33:31 +0900

Power saving is an essential part for 6lowpan, but 
I am so curious how to deal with this algorithm within
IETF. Is there any IP relevant issues ? It seems most
likely 802.15.4 technology itself...

----- Original Message ----- 
From: "Myung J Lee" <[email-masked]>
To: "'Geoff Mulligan'" <[email-masked]>
Cc: "'6lowpan'" <[email-masked]>
Sent: Friday, February 09, 2007 12:36 AM
Subject: RE: [6lowpan] WG rechartering

Hi Geoff,

Thanks, 

Myung J. Lee

-----Original Message-----
From: Geoff Mulligan [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 12:32 PM
To: Ki-Hyung Kim
Cc: 6lowpan
Subject: Re: [6lowpan] WG rechartering

geoff

---

From: "Myung Lee" <[email-masked]>
Date: Thu, 8 Feb 2007 19:36:14 -0500

Daniel,

Since we can't change any 15.4 MAC, we have to do it above MAC, which 
belongs to IP layer issue.
Thanks,

Myung J. Lee
CUNY

----- Original Message ----- 
From: "Daniel Park" <[email-masked]>
To: "Myung J Lee" <[email-masked]>; "'Geoff Mulligan'" 
<[email-masked]>
Cc: "'6lowpan'" <[email-masked]>
Sent: Thursday, February 08, 2007 6:33 PM
Subject: Re: [6lowpan] WG rechartering

---

From: Daniel Park <[email-masked]>
Date: Fri, 09 Feb 2007 09:54:45 +0900

Dear Prof. Myung, 

That sounds great. I second your suggestion.

Thanks,

---

From: Tiago Camilo <[email-masked]>
Date: Sat, 17 Feb 2007 18:09:31 +0000

Hi list,
Looking to the rechartering list I found out that this one does not 
contempt the later suggestion made by Ron Strich regarding a high level 
architecture document describing the overall 6LoWPAN architecture, as 
those that appear in v6ops WG.
I also agree with Phil regarding the main problems to be addressed, but 
I feel that Service Discovery can also represent an important role, in PANs.
Tiago Camilo

---

From: Geoff Mulligan <[email-masked]>
Date: Sun, 18 Feb 2007 12:05:40 -0700

Tiago,
  Thanks for remembering this!  I will add it to the list of possible
Working Group items.  I agree that just like in v6ops this is an
important topic for us.

	geoff