Hi Geoff: My answer is 2 fold: organizational and functional.
1) moving forward: What I see in the charter is a lot of good work ahead, and maybe not enough people for doing it! There's nothing I would drop from your long list. There's even some stuff I'd wish to add. But then we need to hire on this list! Long as we have enough people committed on contributing to a given task, go for it. Seems that a cross ref between prioritized work items and volunteers could help sort manning out. Are the tasks in the charter already ordered by priority? 2) items: I can commit to participate to the ND work, in particular WRT BrB. I agree with your image of an AP up to the point that with BrB, ND is done with recoverable unicast over a multihop mesh under, whereas in the WIFI AP case, we have direct sight and the AP actually rebroadcasts things that were passed unicast, with no recovery. So please count me in for the ND related work. I'm also interested on a work item that is not mentioned on the charter, fragment flow control and recovery. Considering that a 1500 bytes packet will be sliced in about 25 pieces, and that the loss of a single fragment causes the resending of the 25 of them, it might be appropriate to propose a minimalist fragment recovery to start with, wouldn't you think? Finally, I'm all for the 6LoWPAN profile and I know enough people who wish to contribute. The question is whether that one should be done at 6MAN or 6LoWPAN. Maybe we could get some wisdom from the ADs on this? I hope this helps Pascal >-----Original Message----- >From: Geoff Mulligan [mailto:[EMAIL PROTECTED] >Sent: lundi 10 décembre 2007 21:47 >To: 6lowpan >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. 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?) > >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.) > >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? > >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). > >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. > >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. 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? > >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. > >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. > >7 Interop guide: Zach Shelby and Jonathan Hui are interested. >What about the other folks that have built or are building >6LoWPAN implementations. > >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. > >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
