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

[Jukka Manner <[e-mail]>]

Hi,

I'm somewhat struggling with understanding the charter, but at least two 
items pop out:

1. This seems to indicate that 6lowapp will not be tied to any existing 
work, it will work on its own goals, but in collaboration with others 
(which is somewhat open as what it means). I would have expected that 
6lowapp would specifically look at existing work in related WGs and see 
how build on top of that.

2. The charter goes quite far in the design of the solution and it's 
details. To me this seems a bit too far into the future, but also 
somewhat limited and very specific and narrow(?). Maybe this is fine for 
a BOF charter, but way too detailed for a WG charter.

I'll comment more when I understand the goals more (if that happens 
anytime soon).

regards,
Jukka

Cullen Jennings wrote:
> 
> I've been talking to various folks about the how quickly they would like 
> to get initial standards on this topic complete. To move quickly, I 
> think we need an initial charter that is extremely focused and makes it 
> clear what we are going to go do. After we meat the initial goals of the 
> WG, we could expand the WG to explore into more area and extend the 
> protocols to do more. I bounced some ideas around with Zack, Carsten, 
> and Don and have put an initial draft of what I think of as a focused 
> charter might look like below.
> 
> It's just a straw man and it has some problems in it. I've been trying 
> to merge all the various things different people have told me and 
> organize them. I'm not promoting that I think this is the best plan - it 
> just a plan that we can use as a baseline to talk about what we really 
> want to do as group and if this charter reflects that or not.
> 
> Please, read it. Think about, if the WG did this, could you live with 
> that. If No, why and what requirements do you have this does not meet. 
> If you could live with it but some changes would make it better, what 
> are they.
> 
> Thanks, Cullen
> 
> ----------------------------------------
> 
> 
> 
> Applications are being developed for networks that have very limed 
> packets sizes, have high degree of packet loss, and where a substantial 
> number of devices that may be powered of at any point in time but 
> periodically "wake up" for beef periods of time. These Networks are 
> referred to as Constrained Networks (CNEets). 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 automation, energy management, and the Internet of Things. This 
> working group will define a framework a limited class of applications 
> that deal with manipulation of simple resources on devices on a CNet. 
> This includes applications to monitor simple sensors such as a 
> temperature gauge, light switch, or power meter and control an actuator 
> such as a light switch, heating system, or door lock. Typical uses 
> include power management and reporting, and home automation.
> 
> The general architecture consists of nodes on the CNet, called Devices, 
> that have one or more Resources that represent sensors and actuators. 
> Devices send message to change and query resources on other devices. 
> Devices can send notifications about changed resource values to 
> subscribed Devices. In other words, the architecture requires push, pull 
> and and a notify approach to manipulating resources. As part of the 
> framework for building these applications, the WG will define a CNet 
> Application Protocol (CoAP) for manipulation or Resources on Devices. 
> The framework will also specify a way to define new interface profiles 
> that can be defined by vendors and other standards bodies to define the 
> particular Resources on a Device and what manipulation are possible.
> 
> There are also nodes called PEPs (Performance Enhancing Proxy) that 
> gateway between the protocols typically used by the applications on the 
> Internet and the protocol used on the CNet. An application on the 
> general network can use HTTP REST to communicate with the PEP which will 
> use CoAP to manipulate the Resource on the Device. The WG will define a 
> mapping on the PEP from the CoAP to the a HTTP  REST API. Each interface 
> profile will define the Resources on the device that application can 
> manipulate and what manipulations are possible.  This will determine the 
> HTTP REST APIs on the PEPs and the CoAP protocol encoding to manipulate 
> the Resources on the Device it will also specify an XML MINE type for 
> each class of Device that can be used to described the Resource state in 
> the the body of HTTP REST messages. The WG may also work on a mapping to 
> SNMP on the PEP. It is worth noting that the PEP does not have to be 
> deployed at the boundary of the CNet and the more general network but 
> can be deployed at various location in the network.
> 
> The PEP boxes 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 the a PEP that subscribed, when the 
> PEP 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 PEPs may also provide support for 
> discovering devices that may not be currently responding as they are 
> temporarily asleep.
> 
> The initial work item of the WG are to define:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.]]
> 
> 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.
> 
> 6) A document with operation and management advice about running a 
> network using these applications.
> 
> 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.
> 
> The CoAP protocol will support three commissioning methodologies.
> 
> 1) Duckling mode. One device is put in a "mother duck" mode where it 
> listens for broadcasts of Devices trying to imprint. Other Devices are 
> put in a "duckling" mode where they broad cast to the "mother duck" 
> Device then "imprint" by forming a new shared secret between the two 
> Devices. Once this is complete the devices are taken out of this mode 
> and can be use in a secure fashion.
> 
> 2) Out of Band Key mode. Each device in manufactured with an initial 
> symmetric key physically printed on the side in numeric and barcode 
> form. Alternatively the device could have a barcode that forms a URL 
> which when dereferenced with appropriate authorization provides a secure 
> access to the key. A human can enter or scan this into a computer that 
> can then be used form a secure connection with the Device. Once a secure 
> connection is formed, the symmetric key can be changed.
> 
> 3) Certificate mode. Each device is manufactured with a certificate with 
> an asymmetric key. The fingerprint of the certificate is printed on a 
> barcode. During commissioning, a computer can scan the barcode, the 
> connect to the device and replace the certificate with a locally 
> generated certificate that can be used for forming secure connections.
> 
> Modes 1 and 2 are mandatory to implement but mode 3 is option. In all 
> modes, once Device A and Device B have formed a secure connection with 
> Device C, Device C can be used to transitively introduce A and B so now 
> A and B have a secure connection with  C. This transitive trust 
> introduction can be used during commissioning even if A and B do not yet 
> have network connectivity to each other.
> 
> The CoAP will use CMS for object security. The WG will request the 
> security area define a subset of CMS along with an EXI encoding instead 
> of ASN.1 that is appropriate for a CNet network and for theses types of 
> devices. It will have one mandatory to implement crytpo profile with no 
> public key cryptograph to support modes 1 and 2 and additional crypto 
> profile with public key cryptograph for support of mode 3. In mode 3, it 
> will (or will not TBD) require support for Elliptical Curve Cryptograph 
> (ECC).
> 
> The WG will coordinate on requirements from TBD (other SDO and 
> organizations). The WG will closing coordinate with other IETF WGs 
> including ROLL 6LowPAN and appropriate groups in OAM and Security.
> 
> Milestone:
> 
> Jan 2010 - Select WG document for basis of CoAP protocol
> 
> Jun 2010 - Requirements and Architecture to IESG as Info
> 
> Dec 2010 - Core protocol specification to IESG as PS
> 
> Dec 2010 - HTTP Rest API mapping to IESG as PS
> 
> Mar 2011 - Discovery specification to IESG as PS
> 
> Mar 2011 - Specifications of basic interface profiles to IESG as PS
> 
> Mar 2012 - Ops & Management advice to IESG as Info
> 
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [e-mail]
Finland                           WWW:    www.comnet.tkk.fi