|
Just a couple of minor comments inline. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. Cullen Jennings wrote: <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>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>Still not entirely happy with this language but can live with it - see earlier comments posted on January 26th.</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.
|
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.