Hi Geoff, Carsten, all, Some comments in line:
> 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"? (I 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.) We believe there could be a minimal 6lowpan/Ipv6 profile derived from the analysis of the different uses cases. If the profile is not reduced we can define a set of profiles, suitable for different uses cases. A profile-based solution could address the diversity of requirements that arise from different use cases. > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm 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? Yes, we believe management should be considered in the architecture > 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). We believe some multicast solution should be supported, but it should be considered possibly by RL2N, where unicast and multicast routing protocols can be matched if necessary. > 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. Transport protocols should be considered. See our comment below (regarding the architecture topic). > [...] 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. According to our vision, mobility is not a strict requirement at this stage. In most cases, it can be solved through a quick network reconfiguration. > 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 (that would be me) 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? We believe transport protocols should be considered. In a reduced resource network, crosslayer issues should be considered. Architecture should consider this fact providing mechanisms to exchange relevant information (reliability, link quality,..) through layers > 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. We believe, at least at this time, it might not be necessary having two different routing requirements documents (one from RL2N and one from 6LoWPAN). Since LoWPAN scenarios are a subset of those considered by RL2N, at least there should be an RL2N requirements document, which should address the requirements for 6LoWPAN. If RL2N requirements were too broad for 6LoWPAN, then a routing requirements document for 6LoWPAN would make sense. > 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. We can contribute. We have developed applications for home automation, healthcare and city management environments. > 5 "6LoWPAN Security Analysis". Nobody? (I might provide some input, > but can't do this on my own.) > > 6 Implementers' guide: Zach Shelby is interested We may contribute. > 7 Interop guide: Zach Shelby is interested > Best regards, Carles Gomez Technical University of Catalonia _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
