Re: [6lowapp] Revised Charter Proposal

[Robert Cragie <[e-mail]>]

Some comments below bracketed by <RCC></RCC>. I generally agree with 
Zach's comments unless stated.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
[phone]
http://www.gridmerge.com <http://www.gridmerge.com/>



Zach Shelby wrote:
> 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."
>   
<RCC>I don't think you need to say anything about deployment - it's a 
mapping.</RCC>
>
>   
>>  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. 
>   
<RCC>I agree, it's unnecessarily specific</RCC>
>   
>> 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.
>   
<RCC>I don't think you can get away with removing the concept of a 
CoGII. It's all gone a bit hand-wavy now going on about caching at 
'intermediate subscriber' (aka CoGII?) nodes. In my experience, managing 
data for sleeping nodes is one of the more complex and overlooked 
aspects of sensor networks and needs to be focused on not dissolved away 
like this.</RCC>
>   
>> 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
>   
<RCC>I think the original statement is fine if you just remove "roughly 
within 50ms of each other"</RCC>
>   
>> 5) Default operation of the protocol will be over UDP; it may optionally
>>   use TCP or other reliable transports.
>>
>>     
>
> Update a la Lars
>   
<RCC>I think the original statement is almost OK. I would perhaps reword 
as follows: "Default operation of the protocol will be over UDP, however 
it will not be precluded from operating over TCP or other reliable 
transports". This would address the 'wider internet' concern. I don't 
particularly see the point in having options only suitable for TCP, for 
example - this goes against the whole point of CoAP.</RCC>
>   
>> 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.
>>     
<RCC>
Security is always 'very challenging' ;-). The 'on one hand/on the other 
hand' statement implies opposites but the statements are not logically 
related. I would perhaps rephrase something like the following:

"There are two main aspects of security which need special consideration 
in these applications. There must be support for introduction of Devices 
that may have no display or input capabilities onto the network. Also, 
support for high security is essential as this protocol may transport 
information about alarm systems or controlling door locks over a 
wireless network."
</RCC>
>> 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:
>>     
<RCC>Remove "Instead the methods could run across any layer, including 
IP"</RCC>
>> 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 ]]
>>     
<RCC>I think we have already defined constrained node/network so I don't 
see the need to repeat it here. The only additional property 
specifically relevant for security called out above is computational 
capacity; maybe this could be incorporated in the original definition.</RCC>
>> 2) The methods need to provide sufficient security for the application
>>   space.
>>     
<RCC>I think the statement is rather vague. Perhaps something like "the 
methods need to support a wide range of security requirements coming 
from the application space"</RCC>
>> 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.
>>     
<RCC>
There are two things here:

1) It would always be a policy decision whether two nodes can join 
together, so I would rephrase as "the methods must support the joining 
of two nodes"
2) You have opened up a large can of worms when talking about merging 
networks. This has many implications beyond joining two nodes
</RCC>

>> 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.
>>     
<RCC>There are also polynomial-based key distribution methods which may 
be appropriate. Perhaps the statement above should be less specific.</RCC>
>> 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.
>   
<RCC>..and EAP. Perhaps again this needs to be less specific and "the WG 
will work with the security area to select cipher suites and protocols 
most suitable for constrained networks" might be sufficient. I wouldn't 
call out CMS either at this stage.</RCC>
>   
>> 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
>>     
>
>