Re: [6lowapp] Next rev of CoRE Charter

[Robert Cragie <[e-mail]>]

Just a couple of minor comments inline.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
[phone]
http://www.gridmerge.com <http://www.gridmerge.com/>



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.
> 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.
>   
<RCC>This seems to imply that only a 'translator' can be a cache? This 
does have implications for the way the protocol is designed, i.e. it 
could be simpler if this is the case. On the other hand, it would be 
more flexible to allow caching in intermediate nodes which are not 
necessarily 'translators'. What is the intention here?</RCC>
> 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.
>   
<RCC>Still not entirely happy with this language but can live with it - 
see earlier comments posted on January 26th.</RCC>
> 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
>
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>