Overall, the charter looks good to me. Though I do think that some of the items must be more use case driven, as I think that we'll probably see different requirements based on the use cases. So maybe the wording on the charter items should change to reflect that? See comments below:
Geoff Mulligan wrote: [...]
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?)
While we'd all like to see 6LoWPAN move faster, I think the current timeline is realistic and achievable.
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.)
Yes. But I do believe that it should be specified case-by-case driven by the application, network architecture, or both. Maybe this should be a part of the use case documents?
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?
Manageability is important, but it's not clear whether SNMP or something SNMP-like is the right approach. Maybe we should have some work that surveys existing management mechanisms/methodology?
[...]
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?
I'm interested in specifying ND/autoconf for route-over. I know this overlaps with the AUTOCONF WG and I should probably start there. But I do believe that 802.15.4 places some more stringent requirements on the autoconf solution (e.g. 6LoWPAN's mapping of L3 to L2 addresses, extreme resource constraints, etc.) and that we can make 802.15.4 specific optimizations. Do the chairs have any thoughts on this?
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.
I'm interested in continuing my effort on HC1g and defining 6LoWPAN header compression for route-over configurations. I do believe this may be separate from the solution for mesh-under.
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?
I can help out on the overall doc if help is needed.
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.
Yes, it's unclear to me how the 6LoWPAN and ROLL documents are related and if they will be sufficiently different. I also believe that routing requirements must be use-case driven, so it's unclear to me whether this should be done in a single document, or as part of documents that describe use cases.
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.
Not sure if the intention here is to generate a single Use Case document. I'm seeing a pattern here where decisions may and probably will be largely driven by the use case. This applies to minimal node requirements, routing requirements, etc. Maybe we should generate separate docs for individual use cases that the WG is interested in that lay out each of the requirements?
-- Jonathan Hui
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.
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
