Re: [6lowapp] Revised Charter Proposal

[Zach Shelby <[e-mail]>]

More comments in-line: 

On Jan 25, 2010, at 1:25 , Cullen Jennings wrote:

> 
> I tired to incorporate the discussion on the list and the discussion from he BOF into a revised charter proposal. I'd like to see if there were any feedback early this week then, if things look like this charter is close, send this to Lisa (our AD) and see if this can make it on the next IESG call. 
> 
> Cullen
> 
> ----------------------
> 
> 
> CoRE
> 
> Applications are being developed for IP networks that have very limited
> packet sizes, exhibit a high degree of packet loss, and have substantial
> number of devices that may be powered off at any point in time but
> periodically "wake up" for brief periods of time.  These networks, and
> the nodes within them are characterized by severe limits on throughput,
> available power, and particularly on the complexity that can be
> supported with limited code size and limited RAM per node.  More
> generally, we speak of constrained applications whenever at least some
> of the nodes and networks involved exhibit these characteristics.
> 
> Low-Power Wireless Personal Area Networks (LoWPANs) are an example of
> this type of network. These networks are becoming increasing important
> for applications such as home and building automation, energy
> management, and the Internet of Things. This working group will define a
> framework for a limited class of applications that deal with the
> manipulation of simple resources on constrained devices. This includes
> applications to monitor simple sensors (e.g.  temperature sensors, light
> switches, and power meters) and control actuators (e.g. light switches,
> heating controllers, and door locks).
> 
> The general architecture consists of nodes on the constrained network,
> called Devices, that have one or more Resources that may represent
> sensors, actuators, or other values. Devices send messages to change and
> query resources on other Devices. Devices can send notifications about
> changed resource values to Devices that have subscribed to receive
> notification about changes. As part of the framework for building these
> applications, the WG will define a Constrained-node/network Application
> Protocol (CoAP) for the manipulation of Resources on a Device.


> The
> framework will also specify a way to define new interface profiles that
> vendors and other standards bodies can use to define the particular
> Resources on a Device and what manipulations are possible.

Remove the above sentence. 

> 
> CoAP will be designed to be used between Devices on the same constrained
> network, between Devices and general nodes on the internet, and between
> devices on different constrained networks both joined to the internet.
> 
> There also may be nodes called Constrained-to-General-Internet
> Intermediaries (CoGII) that interconnect between other protocols
> typically used by applications on the internet and the Devices using the
> CoAP protocol.  

Remove this sentence (see, no more CoGIIs).


> The WG will define a mapping on the CoGII from CoAP to
> an HTTP REST API; this mapping will not depend on a specific
> application.

Remove CoGII. Combine with some paragraph above. Add "It is worth noting that this mapping does not have to be deployed at the boundary of the constrained network and the more general network but can be deployed at various locations in the unconstrained network."


>  Each interface profile will define the Resources on the
> Device that applications can manipulate and what manipulations are
> possible.  This will determine, in a mechanical translation way, the
> HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to
> manipulate the Resources on the Device; it will also specify an XML MIME
> type for each class of Device that can be used to describe the Resource
> state in the body of HTTP REST messages. It is worth noting that the
> CoGII does not have to be deployed at the boundary of the constrained
> network and the more general network but can be deployed at various
> locations in the unconstrained network.

Remove all this stuff, this has to do with profiles etc. 

> 
> CoGIIs can provide various forms of "caching".  For example, if a
> temperature sensor is normally asleep but wakes up every five minutes
> and sends the current temperature to a CoGII that has subscribed, when
> the CoGII receives a request over HTTP for that temperature resource, it
> can respond with the last seen value instead of trying to query the
> Device which is currently asleep. The CoGIIs may also provide support
> for discovering Devices that may not be currently responding as they are
> temporarily asleep.

Replace with something like this:

CoAP can be cached in various ways. For example, if a temperature sensor 
is normally asleep but wakes up every five minutes and sends the current 
temperature to an intermediate subscriber, when the intermediate receives 
a request over HTTP for that temperature resource, it can respond with the 
last seen value instead of trying to query the Device which is currently asleep.

> 
> The initial work items of the WG is to define a protocol specification
> for CoAP that includes:
> 
> 1) A way to define the "interface profile" that specifies the Resources
>   for a Device and implies the REST API that can be used

Remove.

> 
> 2) The ability to set and query a resource on a Device.
> 
> 3) The ability to allow a Device to publish a value or event to another
>   Device that has subscribed to be notified of changes, as well as the
>   way for a Device to subscribe to receive publishes from another
>   Device.
> 
> 4) The ability to support a non-reliable multicast message to be sent to
>   a group of Devices to manipulate a resource on all the Devices
>   simultaneously.  The goals would be delivery of messages roughly
>   within 50 ms of each other for closely located Devices on suitable
>   networks to meet the use case of several lights appearing to turn on
>   at the same time to a human observer.

Update a la Lars

> 
> 5) Default operation of the protocol will be over UDP; it may optionally
>   use TCP or other reliable transports.
> 

Update a la Lars

> 6) A definition of how to use CoAP to discover Devices on the
>   constrained network, and to interrogate them to find out which
>   interface profiles they support.  The name taxonomy used for
>   discovery will be consistent with the approach defined in
>   draft-cheshire-dnsext-dns-sd.

Update to something like:

The ability for CoAP to be used for the discovery of Devices and resource on 
the constrained network. The details of discovery and profile formats are out of
scope. They may be defined by applications using CoAP or by the WG at a later time if 
necessary.


> 
> 7) An ability for Devices to provide a pointer to the general schema
>   information so that a CoGII does not need any code changes to support
>   new Device classes.

Remove.

> 
> 8) Specification for the HTTP REST based API and mapping on the CoGII to
>   communicate with Devices.

Remove CoGII.

> 
> The working group will not develop a reliable multicast solution.
> 
> Security, particularly keying of new Devices, is very challenging for
> these applications. On one hand this needs to support models in which an
> end user can introduce onto their network a new Device that may have no
> display or input capabilities. On the other hand, this protocol may
> transport information about alarm systems or controlling door locks over
> a wireless network.
> 
> The WG will work to support methods of security bootstrapping which are
> realistic given the constraints and requirements of the network. These
> methods are not specific to any communication layer. Instead the methods
> could run across any layer, including IP. Requirements considered
> include:
> 
> 1) The methods need to be suitable for use on resource constrained
>   nodes. These constraints include power, cost, size, and computational
>   capacity. [[ Note: the WG realizes the vagueness of this constraint
>   but does not currently have consensus on a more quantitative metric
>   of these constraints ]]
> 
> 2) The methods need to provide sufficient security for the application
>   space.
> 
> 3) The methods must guarantee that any two nodes can join together. This
>   includes nodes which are already on separate networks which a user
>   wishes to merge together.
> 
> 4) There may be additional requirements for each application space, such
>   as urban or commercial environments which deploy large networks,
>   compared to residential environments.
> 
> To ensure that any two nodes can join together, all nodes must implement
> at least one universal method. In additional several other methods will
> be specified which take advantage of the application space. In
> commercial applications, for instance, bootstrapping can take advantage
> of the fact that networks are typically managed from a central
> authority, and a method optimized for residential usage might take
> advantage of the fact that nodes are in close proximity.
> 
> Methods which will be considered include:
> 
> 1) Out of Band Key or Certificate: In this mode a key (either symmetric
>   or asymmetric) is distributed with the product, such as a 2D barcode
>   printed on the node. The user can scan this key with a computer to
>   give access to this node.
> 
> 2) Physical Button Protocol: In this mode two nodes only require
>   pushbuttons and LEDs, and the user simply pushes the button on each
>   node within a narrow time window to join them together.
> 
> 3) Out of Band Communication Link: This could include IrDA or NFC (Near
>   Field Communication) type technologies to allow a device to join
>   another device that is physically nearby.
> 
> 4) Out of Band Configuration: A simple example of this would be using
>   the programming interface which a node uses to download firmware.
> 

One comment is that it might not be necessary to descibe these in such detail in the charter, instead it might be enough to shortly list these. 

> This list should not be considered exhaustive, and methods may be
> removed or added as additional application spaces and requirements are
> found. The list gives examples of the types of methods to be
> investigated.

It should be explicitly said that the goal of the WG with regard to security bootstrapping is not to develop any new protocols. Instead these methods recommend how to use existing protocols in a constrained configuration.

> 
> Security can be achieved using other session security or object
> security.  For session security, the WG will work with the security area
> to select cipher suites most useful for constrained network.  For object
> security, CoAP will initially look at CMS (RFC 5652).

Mentioning TLS/DTLS would be a good idea.

> 
> The WG will coordinate on requirements from many organizations including
> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; other SDOs
> and organizations. The WG will closely coordinate with other IETF WGs
> including ROLL, 6LoWPAN, and appropriate groups in the IETF OPS and
> Security areas.
> 
> Milestones:
> 
> Mar 2010 - Select WG document for basis of CoAP protocol

I don't see this as a problem. There has been a lot of work going on already in December and January, the chartering process is going on in parallel. As SE 2.0 has a real need to be able to point at a document - this is a necessary milestone. 

> 
> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API
>           submitted to IESG as PS

Does this really need to be a separate RFC? From the BOF I had a feeling we should integrate this mapping with the main CoAP protocol document. Instead, I would find it much more valuable to have the security bootstrapping as its own RFC. 

Zach


> 
> Jan 2011 - Recharter to add things reduced out of initial scope
> 
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.