Hi Geoff, The proposed charter captures very well the discussions that we've been having for some time, thanks.
Minor comments in line, > From: Geoff Mulligan <[EMAIL PROTECTED]> > Date: Mon, 10 Dec 2007 13:46:56 -0700 > To: 6lowpan <[EMAIL PROTECTED]> > Subject: [6lowpan] Issue of the Week: Charter Finalization > > Lowpanners, > > We have had some recent discussion on issues related to network > structure, in particular the use of multicast and the issue of sleeping > nodes. > > Carsten and I don't want to interrupt this discussion, but we would like > to remind everyone that we also have one CRITICAL short term objective: > Getting rechartered. > > The *theme of the week* for the working group is the finalization of the > charter. OK so I won't comment on this aspect for the time being ;-) In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) > Are you planning to share the proposed Milestones? > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) Can't agree more ... We had an informational discussion on this topic last Thursday and this was also my input: if we want to work on a minimal 6lowpan/IPv6 profile (and I think that we should), it will have to be on a per-case basis. > > C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? I think so, at least to start with. Should there be a need to define a SSNMP (Super Simple ....), would it be done here ?? I'm not against this idea, but it is by itself a fairly heavy work item. > > D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). *If* a ROLL WG is formed that is certainly an area that we'll be working on. Hopefully the solution should be applicable to 6lowpan. > > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. I would certainly not add anything to what is already quite loaded. > > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. I second that. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? Count me in (for comments). > > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann might be contributing a bit of ROHC > background. > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? > > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. > If a ROLL WG is formed, the situation will be much clearer in a few months. I can see two options here: 1) Leave this out of the new charter for the moment, 2) Include the mesh-under routing requirement as the WG item, in which case it would be preferable to have one document with the mesh under routing requirements specifics being worked out in 6lowpan, feeding ROLL (if formed). The challenge here is that this document will most likely look quite similar to the first routing requirement David and I had started with before moving to a use case approach ... > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. > > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > might provide some input, but can't do this on their own.) > > 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. > What about the other folks that have built or are building 6LoWPAN > implementations. Could you shed some light on what you mean by "Implementers' guide" especially in an IETF context? > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > the other folks that have built or are building 6LoWPAN implementations. Certainly useful. > > In order to accelerate rechartering, we should have answers to these > questions/credible sets of contributors to these documents by the end > of this week, so please don't hesitate providing your input. Thanks. JP. > > Gruesse, Carsten and Geoff > > > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
