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

[Arjun Roychowdhury <[e-mail]>]

My comments:

The charter seems to combine goals as well as architecture together in one
go. Probably can be simplified ? Specific comments below:


On Thu, Oct 29, 2009 at 2:42 AM, Cullen Jennings <[e-mail]> wrote:

>
>
> 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.
>

ARC> We are implicitly stating that devices in a lowpan will have simple
management requirements (kind of like set/get mostly). I'd like to see this
group also consider (in terms of usecases) what are the various control
functions that are desirable, given an internet connect ecosystem? I don't
think we should assume that just because most home control was mostly about
simple on/off/read  till date, that is what we should architect for. It is a
minimal requirement, but not complete by itself.



>
> 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.
>

ARC> I don't think HTTP to XX mapping should be assumed at this stage. HTTP
may be a popular protocol, but there could be others. So a general goal of
internet protocols to device control protocol mapping is more suitable


>
> 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.
>

ARC> Is this needed as a part of the charter?


>
> The initial work item of the WG are to define:
>
>
>
>
> 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.
>

<etc>

ARC> This seems to be a requirement specification of what a CoAP should be.
I think it should be left for a dedicated req doc, not as part of a charter.


>
> --
Arjun Roychowdhury