Re: [6lowapp] Next rev of CoRE Charter

Hi JP, 

Thanks for comments. Some questions inline before I figure out how to integrate these.  If this email makes no sense, drop me a note and I'll give you a phone call and figure out to sort it out. 

Cullen

On Feb 2, 2010, at 12:57 AM, JP Vasseur wrote:

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

Agree with common language in general but in some earlier but in earlier discussion I understood from people and LLN was a description about the network and not so much the constraints of the hosts that ran on it. (I may have totally misunderstood what they were saying) It seemed like what people were trying to say here was a related to but not the same as LLN. Can you point at the best definition of LLN over in ROLL and perhaps I can try and sort this out. 

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

I think that was my mistake - Thanks for catching. What I was trying to do is motivate they type of places that might be able to use the output of the CoRE WG. What I was trying to say is "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
>> 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.

I might not be understanding what point you are getting at here. Uh, I think we have had pretty clear input the CoRE application level could be running over v4 or v6. The charters tried to be pretty explicit that it is not v6 specific. I'm trying to reflect the consensus here and the actually consensus call would be up to Lisa as the AD but I did get a fair amount of input on topic and it all seemed to go towards the direction of, yes this definitely has to work on v6, but to make something that is above layer 3 be only for v6 would encourage layer violations of the worst kind and there was no need for that. I think the general approach for IETF application layer protocols is to work on both v4 and v6 unless there is some really good reason they can't. 

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

Yep - agree. But do we need to say anything about that here? I'm just not sure what words to put in. Clearly we can do HTTP/Rest API over IP today without any new standardization. Nothing here would be saying don't do that. 

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

There as a lot of discussion leading to this sentence and I'm cautions to open the can worms. The issues of taking it out is the following. Clearly some people think that TCP won't meet all the needs or we would probably not bother to do UDP at all. But given you are doing UDP, why would you bother with TCP, and the answer is there are probably good reasons to use it in some cases. Then the questions comes up, so OK what about when you don't have it. We end of with this circular argument about the everything that works over UDP must work over TCP and visa versa so why have both. This sentence in the charter tries to break that argument by pointing out the obvious which is some stuff is just not going to be work as well, if at all, over UDP and also TCP is not going to be available 100% of the time. I realize this paragraph makes almost no sense but I hope you can figure out what I am getting at if not, glad to give you a call and get to the point where I can explain well enough to fix this email

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

It covers the naming aspects of device and services. (More or discover bellow)

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

It's definitely a pretty minimal minimum. The question is what do we add beyond that and do we need to do it in the charter. Note this bullet does not stop the WG from doing more, just sets a minimum bar. Honestly, this bar is so low but every time I tried to raise the bar, I failed. Ideas welcome. I pretty much expect that folks would have a way of finding out things like firmware version and such but do to the privacy aspects of some of that, people have argued that would be one of the "Resources" defined which you can access via the CoRE protocol and not part of the CoRE protocol itself. I'm working with Dan Romascanu (Ops AD) has been following this charter and I know he is has sent me some emails that I have not got to yet so I expect to be able to improve this point  a bit but doubt we can figure out any really significant changes that can get widespread agreement. 

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

So I share your concern and was very skeptical of how this could be useful without a Discovery protocol. However, at the BOF, there was a surprisingly strong HUM at the end to throw Discovery under the bus. This sort of freaked me out at first but as I came to talk to more people about it, I realized that people had widely varying views of what Discovery meant. Here's my current understanding of what sort of "Discover" in the scope of this charter and what is out of scope. 

First, a discovery protocol can be decoupled from a data transfer protocol. For example, a printer can be discovered with UPnP, Bonjour, SLP, etc even though one might use IPP to print to it. What we are trying to do here is more the IPP like protocol. Second, the charter has the word " A Device can also publish or be queried about its description." I'll update this a bit but the intention was, if you know the IP address of a Device, you can ask it what resources it supports - basically what's it profile. A device should also decide to publish out to other devices what resources it supports. It could publish them to a multicast group. A device could also sent out to multicast group what resources do you support and get back answers from many devices. Some people think this is discover and many do not. They think it is just a device saying what characteristics it has and consider Discover much more complicated.  The other part in the proposed charter around discover is being consistent with existing naming constraints. The goal here is to make sure that whatever this WG selects around name devices and services, it's got to make sure that this is not impossible for an application to use in some multicast DNS discover protocol. 

That my rough, and perhaps somewhat confused, interpretation of the state of the current charter and given the strong HUMs at the end of the BOF, I don't see how we have this WG take on a full blown discovery effort without re-charting (or re-boffing) which is something I am perfectly happy to delay to do later.

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