Re: [6lowpan] Rechartering consensus...

Geoff Mulligan wrote:
> 6LoWPAN group,
>   It would appear that we have consensus on the work items for the
> working group rechartering - the following 5 topics have been relatively
> unchanged for months.
>
> As I have been working with folks that are implementing 6LoWPAN and from
> some of the messages on the list I have realized that we should probably
> be focused on those topics that are necessary to resolve for
> interoperability between implementations.  Some of the 5 items here are
> targeted to this and some of the topics mentioned on the list, such as a
> standard/defined MIC could fall under one of the topics.
>
> - “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations”
> - “Problem Statement for Stateful Header Compression in 6lowpans”
> - “Recommendations for 6lowpan Applications”
> - “6lowpan Mesh Routing”
> - “6lowpan Security Analysis”
>
> I have attached a proposed new charter for the working group.
>
> 	geoff
>
>
>   
> ------------------------------------------------------------------------
>
> Background/Introduction:
>
> Well-established fields such as control networks, and burgeoning ones
> such as "sensor" (or transducer) networks, are increasingly being
> based on wireless technologies. Most (but certainly not all) of these
> nodes are amongst the most constrained that have ever been networked
> wirelessly. Extreme low power (such that they will run potentially for
> years on batteries) and extreme low cost (total device cost in single
> digit dollars, and riding Moore's law to continuously reduce that
> price point) are seen as essential enablers towards their deployment
> in networks with the following characteristics: 
>
> * Significantly more devices than current networks
>   
This statement seems a bit dubious to me. More devices than what 
"current" networks? And, what exactly is the limit of a "network" in 
this statement (the Internet is a network, for example, and I don't 
think you are building anything larger than the Internet itself).
> * Severely limited code and ram space (e.g., highly desirable to
> fit the required code--MAC, IP and anything else needed to
> execute the embedded application-- in, for example, 32K of flash
> memory, using 8-bit microprocessors)
>
> * Unobtrusive but very different user interface for configuration
> (e.g., using gestures or interactions involving the physical
> world)
>   
> * Robustness and simplicity in routing or network fabric
>   
This is a bit of a platitude, and why *or* here?
> A chief component of these devices is wireless communication
> technology. In particular, the IEEE 802.15.4 standard is very
> promising for the lower (physical and link) layers. As for higher
> layer functions, there is considerable interest from non-IETF groups
> in using IP technology. The working group is expected to coordinate
> and interact with such groups.
>
> The working group has completed a problem statement/requirements RFC
> and and adaptation layer (IPv6 over 802.15.4) RFC.  The working group
>   
Double "and"
> has as its main objective to complete those topics and areas necessary
> for successful implmentation interoperability.
>   
What do you mean by "complete those topics"? Continue to advance on the 
standards track?
> The required work includes items in the following (incomplete) list:
>   
> * Addressing schemes and address management
> * Network management
> * Routing in dynamically adaptive topologies
> * Security, including set-up and maintenance
> * Application programming interface
> * Discovery (of devices, of services, etc)
> * Implementation considerations
>
> Whereas at least some of the above items are within the purview of the
> IETF, at this point it is not clear that all of them are. Accordingly,
> the 6LoWPAN working group will address a reduced, more focused set of
> objectives.
>   
I think the above list raises more questions than it answers. When I 
read it, I immediately ask "who is doing all this work? Should we liaise 
with someone on it? is it possible to have interoperable implementations 
without addressing all of these items? What else is left? etc." Rather 
than try and capture the entire landscape in an incomplete list, let's 
focus the charter on two things (1) What the 6lowpan group is going to 
do, and (2) any *important* things that this WG is *not* going to do. 
For the latter, any pointers to other WGs, SDOs, etc. would be welcome.
> Scope of 6lowpan:
>
>   1. 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. 
Do we have consensus that ND is too expensive? If so, great, but I want 
to be sure.

Secondly, do we have consensus that ND is required? If 6lowpans have 
their own built-in address resolution due to the way addresses are 
managed, what aspects of ND are necessary?
> 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.
>   
This work item needs to be a little more crisp. Is this "Bootstrapping" 
or "ND" or both? If both, are we making the assumption that ND is the 
Bootstrapping method, but that it needs to be changed to work in a lowpan?
>   2. 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.
>   
For the last sentence "The WG will determine if the assumption is 
correct at this time and record the findings in this informational 
document."
>   3. 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.
>   
Can we be specific as to which protocols will be covered? This seems 
very open-ended.
>   4. 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.
>   
I think we need to be sure that the line between this and the "RSN" 
effort that is spinning up is clear. Also, nailing down which PS 
documents will be necessary would be a very nice thing to do.
>   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.
>   
And you will need a security area adviser appointed for this. When the 
time comes we will need to ask the secdir to appoint someone.

> The working group will reuse existing specifications whenever
> reasonable and possible.
>   
s/specifications/protocols and mechanisms
> The working group will also serve as a venue for ongoing discussions
> on other topics related to the more complete list outlined above.
> Additional related milestones may be added in the future via a
> rechartering operation.
>   
Not sure this is good advice. You already have a big chunk of work to 
chew on. If discussion naturally ends up on this list for other work, 
that's fine, but I don't see why it needs to be listed in the charter as 
specifically allowed.
> Note: As may be obvious from its official name above, this particular
> working group will not work on IPv4 over IEEE 802.15.4 specifications.
> Given the limitations of the target devices, dual-stack deployments
> are not practical. Because of its higher potential for header
> compression, its support for the huge number of devices expected and
> of cleanly built-in features such as address autoconfiguration, IPv6
> is the exclusive focus of the working group.
>   
I understand keeping IPv4 out of scope for within the lowpan, but I do 
think it is important to write a recommendation for the 6lowpan 
communicating on the Internet at large, in particular the IPv4 Internet. 
Thoughts on this?

Thanks,

- Mark
> ------------------------------------------------------------------------
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>   


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan