Re: [6lowapp] Proposed charter for 6LoWAPP BOF

[Jonathan Hui <[e-mail]>]

Hi Cullen,

This is a good start.  Generally, I think it covers the necessary work  
items.  But while its important to have a focused charter that  
constrains the work, I'd rather have the charter focus on one or more  
target applications rather than a particular solution.  Doing so will  
let the application requirements guide the solutions.  See below:

On Oct 28, 2009, at 11:42 PM, Cullen Jennings wrote:

> 1) A requirements and architecture document that documents the high  
> level boxes and arrows view of the protocol along with high level  
> description of how the security, particular for commissioning of new  
> devices into the network will work. The WG may also produce a  
> document that describes various uses cases that help motivate the  
> requirements.

Generating requirements is the most important first step.  Though, I  
would suggest generating a set of application-specific requirements  
documents for a small and carefully chosen set of applications.  The  
charter should indicate what applications we will work on first.  It  
is useful to call out different applications due to their diversity.   
We did this in ROLL and it allowed us identify a base set of common  
features and those outside the base.  It drives what we work on and  
the solutions.  Just as important, it helped to bring other WG members  
up to speed on the variety of application requirements.  Fortunately,  
we already have a number of individual submissions - but are there  
other not-yet-represented application areas that people want to work on?

I would drop the "and architecture" from "requirements and  
architecture document".  I'd prefer that the requirements docs drive  
the architecture, not specify it.

> 2) Specification of the framework for defining interface profiles  
> and the defining the CoAP. The CoAP will be able to set and query a  
> resource on a Device. It will allow a device to publish a value or  
> event to another Device. It will support a  non-reliable multicast  
> message to be sent to a group of devices to manipulate a resource on  
> all the devices simultaneously (roughly within 50 ms of each other).  
> The protocol will operate over UDP assuming a TBD byte payload and  
> assume an underlying network bandwidth of approximately TBD kbps.  
> The payload will be based on interface profile specific XML document  
> compressed with EXI.

I would drop all the "it will do X, Y, Z".  Let the requirements  
documents guide what the protocol/framework will support.

> 3) Specification on how to use the CoAP to discover Devices on the  
> LoPAN and to interrogate them to find out which interface profiles  
> they support.

Good.

> 4) Specification for the HTTP REST based API on the PEP to  
> communicate with Devices.
>
> 4a) Possibly specify a separate specifications with mappings to  
> SNMP. [[NOte: In the BOF it would be nice to figure out if this is  
> in the charter or not.]]

A REST/HTTP interface to the nodes is useful.  But based on my  
experience, such a device provides the most benefit as a full-blown  
gateway, not just a proxy.  In particular, just intercepting requests  
is not sufficient.  For example, the gateway may queue data/events  
sent periodically by a node which are slurped up by a REST/HTTP  
client.  The gateway may also provide additional metadata about the  
data (e.g. when it was received).  There's a number of additional non- 
proxy-like functions I can think of.  So I'd suggest changing the name  
to indicate gateway.

> 5) A small set of basic interface profiles to illustrate how this is  
> done. Interface profiles will be done for a power meter, a light and  
> light switch, and temperature sensor.

Again, let the set of application requirements drive the specific  
interface profiles we develop.

> 6) A document with operation and management advice about running a  
> network using these applications.

Good.

> Security, particularly keying of new Devices, is very challenging  
> for these applications. On one hand this needs to support models  
> where an end user can introduce a new device onto their network that  
> may have no display or not input capability's. On the other end this  
> may transport information about alarm systems or controlling door  
> locks to a building over a wireless network.

Important as well.  Though I wouldn't go so far as to say what is  
mandatory and what is not in the charter.

--
Jonathan Hui