[6lowapp] Next rev of CoRE Charter

[Cullen Jennings <[e-mail]>]

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

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.

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.

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.

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.

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.

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

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