Hi Geoff & Carsten, The current proposed rechartering items are well-shaped, but I feel that somehow we restart some old discussion in some part. My comments are inline.
On 12/12/07, Jonathan Hui <[EMAIL PROTECTED]> wrote: > > 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. [E] I agreed on it, but when I see the recharter discussion, it kinda push us back to the previous meeting. We had a long discussion on rechartering items until we see the current proposal. I think we have good base documents for current recharter item, so the way we can achieve the timeline is not to restart if we include something or not, but to gather opinion what's our expectation on each items. Then, the current authors and future contributors gather the idea to progress the work. > > > 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? > [E] Yes. We had an informal meeting in Vancouver, including JP, Jonathan, Mikko, Dominik and Eunsook to discuss this topic. We discussed how to approach this work by our experience to implement 6lowpan. What we discussed was it's necessary work for implementors, it will be an informational guide to 6lowpan implementors, and will be described case by case (based on configuration, networking, architecture) But, I think in somehow, we mix the current 'use case' in the charter with 'implementation guide'. It surely would be discribed case-by-case, but it's different from the current 'use case' approach, I think. In the current 'use case(scenario)', it shows applicability of 6lowpan with a bit more general view, and more scenario base, which could have similar configuration cases, different data gathering pattern, etc. I totally agree that the current document needs to be touched more implementation information, but I disagree to combine 'profiling cases for implemetation' with 'use case(scenario)' of 6lowpan. It will delay the current work, and we need to spend some time to match the different view on it. > > > [...] > > > 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? [E] I'm also interested in ND, and I also think we can look at autoconf wg work first. > > > 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. no arguement at all. :) > > > 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. > [E] If ROLL is in clear status, we can discuss how we will progress this work together. But, I don't think we should take out this work from our charter now. I clearly see we have both common and different parts together. It doesn't mean that we don't need to do the work due to the common part. We, 6lowpaners should make our requirements and give the input to ROLL. Actually, I partially agree that we need to describe the requirements in use-case driven. Due to 6lowpan node characteristics, we have very general 6lowpan requirements, and some part of requirements can be different by use-case (not scenario, but more likely networking case). We can enhance the current documents to specify more 6lowpan general req, and put chapter to point out req. for different neworking 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? > [E] In my view, here 'use case' is a guideline to show 6lowpan's applicability. Based on each application scenario, it should contain deployment cases, topology, high-level technical characteristics for each scenario, implementation perspective guide to deploy, etc. As I mentioned in the above, I think we need to enhace the current doc to collect more industries' input. But, again, this is not an specific profiling or so. It should be more general picture for 6lowpan applicatability, IMO. > > 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. > > [E] If you mention profiling here. I already said my opinion in the above that we, some 6lowpaners already volunteered, and I'm one of them. Although you say different thing, I think implementer's guide is always useful. > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > > the other folks that have built or are building 6LoWPAN implementations. > > [E] In the informal profiling meeting, we exchanged our thought on having an event of interoperability test. :) It would be good to have a doc for it. :) Thanks chairs for the new charter, and I hope we have discussion to progress the works in the new charter item now. - Eunsook > > 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 > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
