Re: [6lowapp] Next rev of CoRE Charter

Hi Cullen,

First comment is that I fully support the charter, and look forward to  
seeing an active WG, lots of
items that we need to work on :-)

Comments below,

On Jan 30, 2010, at 7:16 PM, Cullen Jennings wrote:

>
> Thanks to all the great comments form people and the work from Zach,  
> Carsten, and Lisa for this this version. This version clarified a  
> bunch of issues and also removed a bunch of text that did really  
> need to be in the charter. Documents tend to have words added over  
> time and every so often they need to go on a diet :-) I'm really  
> happy with this version and my view is that it is probably close  
> enough to send to the IESG. Just to let everyone on the list know  
> the process here, what happens next is:
>
> 1) See if there are any last minute screams on the email list about  
> this version of the charter
>
> 2) Send it to the AD (Lisa). She might have some changes before she  
> moves it forward to the IESG but Lisa's been very involved along the  
> way here so no expecting any huge surprises at that pint
>
> 3) Lisa puts in an schedule for IESG call and IAB and EISG look at  
> it. Some change might happen.
>
> 4) The IESG sends it out to the whole community for and IETF Last  
> Call. Anyone including folks on this list can send comment. LIkely  
> some changes.
>
> 5) It gets put back on an IESG call for formal approval as a WG
>
> There's variants of how things can happen but the above is roughly  
> what I expect to happen for this charter.
>
> I've attached the charter below. If you see something in it you  
> really can't live with, yell. If you see typos, things that need  
> better wording, or so on, send proposed text changes.
>
> One chug was we removed the word CoGII and instead just talked about  
> translators. Another word we could that was suggested was "proxy" or  
> just talk about things that provide a "mapping function". I really  
> don't much of an opinion about which of these words, or others,  
> would be best but if people have thoughts, Speak up.
>
> Thanks, Cullen
>
> ------------------------------------------------------------
>
>
> CoRE (Constrained RESTful Environments)
>
> CoRE is providing a framework for resource-oriented applications
> intended to run on constrained IP networks.  A constrained IP network
> has limited packet sizes, may exhibit a high degree of packet loss,  
> and
> may have a substantial number of devices that may be powered off at  
> any
> point in time but periodically "wake up" for brief periods of time.

JP>
1) I would suggest to first try to adopt a common "language" across  
Working
Groups. In ROLL, we use the term LLN to refer to Low power and Lossy  
Networks.
Using similar terminology could help.
2) I'd slightly reword to say that LLN are characterized by  
constrained environments
in terms of devices (CPU, Memory, power) interconnected by low speed  
lossy links.

> 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 networks 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. LoWPANs are part of home and
> building automation, energy management, and the Internet of Things.

JP> I would definitely suggest to remove that last sentence ... We've  
been struggling
with the term 6lowpan, trying to explain that "The Internet Of Things"  
refers to the
use of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE  
802.15.4 but
there are many other low power link layers, and this is one of the  
beauty of IP to
be able to support those. The Internet of things will (and is already)  
made of such
low power link layers. That looks like a cosmetic terminology comment  
but it will
avoid a ton of confusion.

>
> The CoRE working group will define a framework for a limited class of
> applications: those that deal with the manipulation of simple  
> resources
> on constrained networks. This includes applications to monitor simple
> sensors (e.g. temperature sensors, light switches, and power  
> meters), to
> control actuators (e.g. light switches, heating controllers, and door
> locks), and to manage devices.
>
> The general architecture consists of nodes on the constrained network,
> called Devices, that are responsible for one or more Resources that  
> may
> represent sensors, actuators, combinations of values or other
> information.  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. A Device can also publish or be queried about its
> description. Typically a single physical host on the network would  
> have
> just one Device but a host may represent multiple logical Devices. As
> part of the framework for building these applications, the WG will
> define a Constrained Application Protocol (CoAP) for the  
> manipulation of
> Resources on a Device.
>
> CoAP will be designed for use between Devices on the same constrained
> network, between Devices and general nodes on the Internet, and  
> between
> Devices on different constrained networks both joined by an
> internet. CoAP targets the type of operating environments defined in  
> the
> ROLL and 6LOWPAN working groups which have additional constraints
> compared to normal IP networks, but the CoAP protocol will also  
> operate
> over traditional IP networks.
>
> There also may be translators that interconnect between other Internet
> protocols and the Devices using the CoAP protocol.  The WG will  
> define a
> mapping from CoAP to an HTTP REST API; this mapping will not depend  
> on a
> specific application. It is worth noting that translation does not  
> have
> to occur at the boundary between the constrained network and the more
> general network, but can be deployed at various locations in the
> unconstrained network.

It might be worth clearly spelling out that such "Translators" are not  
protocol
translation gateways but sensor, devices, ... are IPv6 enabled devices.

>
> CoAP will support 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 translator that has subscribed,
> when the translator 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.

Completely in line with that architecture. Just note that nothing  
prevent an end
device with enough resource to natively support HTTP though.

>
> The initial work item of the WG is to define a protocol specification
> for CoAP that includes:
>
> 1) The ability to create, read, update and delete a Resource on a
>   Device.
>
> 2) 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.
>
> 3) 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.
>
> 4) The core CoAP functionality MUST operate well over UDP and UDP MUST
>   be implemented on CoAP Devices.  There may be OPTIONAL functions in
>   CoAP (e.g. delivery of larger chunks of data) which if implemented
>   are implemented over TCP. Applications which require the optional  
> TCP
>   features will limit themselves to a narrower subset of deployment
>   cases.

I would suggest to delete the last sentence though.

>
> 5) A definition of how to use CoAP to advertise about or query for a
>   Device's description. This description may include the device name
>   and a list of its Resources, each with a URL, an interface
>   description URI (pointing e.g. to a WADL document) and an optional
>   name. The name taxonomy used for this description will be consistent
>   with other IETF work, e.g. draft-cheshire-dnsext-dns-sd.

Does that cover the discovery aspects (of both the devices and the  
services)?
If so, great otherwise i would suggest to clearly spell it out since  
this is in my
opinion a core components.

>
> 6) Specification for the HTTP REST based API and translation to
>   communicate with Devices. Translation should make use of Device
>   description information and should not need code updates to deal  
> with
>   new Devices.
>
> 7) Consider operational and manageability aspects of the protocol  
> and at
>   a minimum provide a way to tell if a Device is powered on or not.

That is a really a "minimum" ... do we need to be so restrictive ?

>
> The working group will not develop a reliable multicast solution, and
> will not develop a general service discovery solution.

That is the part I was a bit worried about ... without service  
discovery, deployments will
certainly be extremely difficult. We should at least work on the  
selection of a discovery
protocols, many candidates exist ... and potentially re-charter,  
should protocol extension
will required.

>
> Security, particularly keying of new Devices, is very challenging for
> these applications. The WG will work to select approaches to security
> bootstrapping which are realistic given the constraints and  
> requirements
> of the network.  To ensure that any two nodes can join together, all
> nodes must implement at least one universal bootstrapping method.
>
> Security can be achieved using either session security or object
> security.  For both object and session security, the WG will work with
> the security area to select appropriate security framework and  
> protocol
> as well as selecting a minimal required to implement cipher suite.  
> CoAP
> will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.
>
> The WG will coordinate on requirements from many organizations  
> including
> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
> ASHRAE/BACnet; 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:
>
> Apr 2010 - Select WG document for basis of the CoAP protocol
>
> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API
>           submitted to IESG as PS
>
> Dec 2010 - Constrained security bootstrapping specification  
> submitted to
>           IESG as PS
>
> Jan 2011 - Recharter to add things reduced out of initial scope
>
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp