Folks,
I'd like the group to continue its work on rechartering. RSN is starting
to work on the routing piece, and this group needs to formulate its
charter in concert with this for the remaining items.
Starting with what we have from the last meeting, I'll offer the group my
thoughts on each as work items to start discussion. Please give your
feedback now, I'd like for the chairs to be able to get a proposed
charter together in time for Chicago.
I copied text from
http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf
Charter 1/5
Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND
Optimizations” to define the required optimizations to make
IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND
is too expensive for the devices of 6lowpan and requires
multicast. This document will define how to bootstrap a
6lowpan network and explore ND optimizations such as
reusing the 802.15.4 network structure (use the
coordinators), and obviate multicast by having devices talk
to coordinators without creating a single point-of-failure, and
changing the IPv6 ND multicast semantics. This document
will be a proposed standard.
Bootstrapping and ND would seem to be related, but separate, work items
(but feel free to convince me otherwise). I think this work item needs
better scoping with respect to what "bootstrapping" really means. Also,
it would be nice to get away from 802.15.4-specific jargon (e.g., you
shouldn't have to be intimately familiar with 802.15.4 to understand
what the work item is).
Charter 2/5
Produce “Problem Statement for Stateful Header
Compression in 6lowpans” to document the problem of
using stateful header compression (2507, ROHC) in
6lowpans. Currently 6lowpan only specifies the use of
stateless header compression given the assumption that
stateful header compression may be too complex. This
document will determine if the assumption is correct and will
be an informational document.
I see no problem documenting this informationally, I would hope that it
wouldn't slow down PS work though.
Charter 3/5
Produce “Recommendations for 6lowpan
Applications” to define a set of recommendations of
protocols to use for applications. The recommendations
will cover protocols for transport, application layer,
discovery, configuration and commissioning. This
document will be an informational document.
This sounds more like an overall framework document. I wonder why
Routing isn't listed here.
Charter 4/5
Produce “6lowpan Mesh Routing” to evaluate different
mesh routing protocols for use within 6lowpans. While most
routing protocols are defined above the IP layer, 6lowpan
requires a mesh routing protocol below the IP layer. “6lowpan
Mesh Routing” may be several proposed standard
documents.
Something to discuss with RSN so that we have a clear understanding of
the goals of MAC vs. IP routing, whether we need to do both or not, how
much of the mechanism could be shared if we do need both, etc.
Charter 5/5
Produce “6lowpan Security Analysis” to define the threat
model of 6lowpans and to document suitability of existing
key management schemes and to discuss
bootstrapping/installation/commissioning/setup issues. This
document will be an informational document.
Yes, and we will want to appoint a security adviser unless we already
have an expert in the group.
These Charter items, with some cleanup and tightening, seem like a
reasonable start to me. I'd like to know what others in the group
believe, and if we have editors and energy lined up for the tasks.
Thanks,
- Mark
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
