Re: [6lowapp] Next rev of CoRE Charter

Hi Cullen,

On Feb 2, 2010, at 10:50 PM, Cullen Jennings wrote:

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

It does apply to both (see below)

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

Sure. We had that discussion when we formed ROLL, trying to find a  
generic term that would apply to these envrionments. In http://www.ietf.org/id/draft-ietf-roll-terminology-02.txt 
, we define LLNs as:
LLN: Low power and Lossy networks (LLNs) are typically composed of
    many embedded devices with limited power, memory, and processing
    resources interconnected by a variety of links, such as IEEE  
802.15.4
    or Low Power WiFi.  There is a wide scope of application areas for
    LLNs, including industrial monitoring, building automation (HVAC,
    lighting, access control, fire), connected home, healthcare,
    environmental monitoring, urban sensor networks, energy management,
    assets tracking and refrigeration..
As you can see this quite generic and *OF COURSE* we can change/adapt  
this terminology to make it use by all WG working
on ... LLNs ...

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

OK great, thanks.

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

Totally agree. I was in fact trying to say two things here:
1) You have a point. Anything above layer 3, could be for v4 or v6.  
But still ... and up to the IESG of course but we need to remember  
that we had a similar discussion with 6lowpan and ROLL: the idea was  
to pass a clear message toward the use of v6 for these kind of  
environments for the number of reasons that we all know. For example  
RPL is v6 only, which is a decision made on purpose.
2) The first point is I think pretty important. As you know, the  
technology approaches were to say the least extremely fragmented not  
so long ago. After tons of effort, we managed to get a momentum toward  
the use of IP, explaining that protocol translation gateways is not  
the best approach compared to a true IP end-to-end architecture (no  
need to enumerate the number of reason here) ... so I was just a bit  
cautious on introducing a term that would make people think that this  
is what we are proposing here ... "translator" may be a dangerous term  
to use.

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

Just something like ... "For the constrained device not supporting  
HTTP natively, ...."

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

Clear explanation, thanks, I now see where it is coming from. The  
sentence does not hurt too much, I just found it weird and with little  
"sense". And we do not want to re-open the can worms indeed. The  
proposal to delete was just to not limit ourselves. But no big deal  
here.

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

I guess that we could slightly reword:

Delete "a minimum .... " since the bar is so low that it does make  
little sense. You would not do anything with that sole information  
anyway. There might be a way to make it a bit more generic:

7) Consider operational and manageability aspects of the protocol  
(e.g. tell if a Device is powered on or not, retrieve management  
information related to errors, traffic, ....).

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

The objective is clearly not to delay anything on my side, I do  
believe as many people that the sooner this WG is operational, the  
better !!!
But discovery is IMO a central issue. In most use cases, and this was  
discussed in length in several other WGs and even other SDOs, the lack  
of discovery is almost a show stopper. Most proprietary solutions have  
their own discovery solutions, we do have IP protocols that could make  
the work here with potential adaptation, I do not see how we could  
leave it out. In most environments (smart cities, smart grid, ..) this  
is listed as one of the key item. Would it make sense to poll the list  
on that particular aspect restating what it means not to have a  
discovery solution for these kind of networks (without re-BOFFING for  
course) ? Again the idea would not be to redefine a complete solution  
but to evaluate existing solutions and select one; if extensions are  
needed this could be done in concert with the WG owning that protocol.

Thanks!

JP.

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