[6lowapp] CORE charter sent for IESG review

[Cullen Jennings <[e-mail]>]

Lisa sent the following charter to the IESG for review. That review will likely happen next thursday. The IESG may have some comments and/or changes then they will send it out for IETF Last Call. At that point, folks on this list and everyone else can suggest any final changes they think are critical to make. After that it will go back to the IESG and the IESG will make a decision about approving the WG or not. (I think this is highly likely to be approved, it's more an issue in what changes might be needed before it is approved).

Thanks everyone for all work on this charter. 

Cullen


Begin forwarded message:

> 
> 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.  Constrained networks can occur
> as 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
> resources. (Typically a single physical host on the network would have
> just one Device but a host might represent multiple logical Devices.
> The specific terminology to be used here is to be decided by the WG.)
> 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 proxies 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 proxy 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 proxy that has subscribed, when
> the proxy 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 in the
>   group.
> 
> 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 Web Application Description Language (WADL)
>   document) and an optional name or identifier.  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. There is a desire
> for discovery and configuration features, but the working group has not
> yet closed in on an specific approach. Thus, the WG may explore these
> topics and adopt drafts that define requirements or set problem
> statements, but will not adopt implementable specifications without a
> recharter.
> 
> 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


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html