Subject: Re: [6lowapp] Next rev of CoRE Charter

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Feb 2010 12:26:44 -0800 (PST)

Hi Cullen,
  I have a few minor corrections on the charter:

----- Original Message ----
> From: Cullen Jennings <[email-masked]>
> To: [email-masked]
> Sent: Sat, January 30, 2010 12:16:14 PM
> Subject: [6lowapp] Next rev of CoRE Charter
> 
> 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. 

resources.

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

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

>WADL
Web Application Description Language (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.

This document expired years ago?

Regards,

Behcet

---

From: JP Vasseur <[email-masked]>
Date: Tue, 2 Feb 2010 08:57:54 +0100

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

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

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

> description. Typically a single physical host on the network would  
> have

It might be worth clearly spelling out that such "Translators" are not  
protocol
translation gateways but sensor, devices, ... are IPv6 enabled devices.

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

>   a group of Devices to manipulate a resource on all the Devices.
>

I would suggest to delete the last sentence though.

>   description URI (pointing e.g. to a WADL document) and an optional
>   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.

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

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

>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 2 Feb 2010 13:43:12 -0700

thank - I put theses in the next version...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 2 Feb 2010 14:50:52 -0700

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

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.

> 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

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

>> description. Typically a single physical host on the network would have
> It might be worth clearly spelling out that such "Translators" are not protocol

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. 

> Completely in line with that architecture. Just note that nothing prevent an end

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. 

> 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

> 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

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

>>  description information and should not need code updates to deal with
>>  new Devices.
>> 
>> 7) Consider operational and manageability aspects of the protocol and at

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. 

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

>> bootstrapping which are realistic given the constraints and requirements
>> the security area to select appropriate security framework and protocol
>> as well as selecting a minimal required to implement cipher suite. CoAP
>> The WG will coordinate on requirements from many organizations including
>> coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate
>> Dec 2010 - Constrained security bootstrapping specification submitted to
>>          IESG as PS
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Feb 2010 14:09:00 -0800 (PST)

Instead of removing LoWPAN how about 
Low-Power Wireless Personal Area Networks (LoWPANs) 

add here 
with IEEE 802.15.4 or many other low power link layers.

That would require less changes.

My 2 cents.

Behcet

----- Original Message ----
> To: JP Vasseur <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, February 2, 2010 3:50:52 PM
> Subject: 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
> 
> 
> >> 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 
> >> 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
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> 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
> >> 
> 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. 
> 
> 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." 
> 
> > 
> >> 
> 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. 
> 
> > 
> >> 
> 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. 
> 
> 
> > 
> >> 
> 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 enou
> gh to fix this email
> 
> > 
> >> 
> 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. 
> 
> > 
> >> 
> 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 c
> onsistent 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. 
> > 
> >>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Feb 2010 07:58:26 +0100

> Using similar terminology could help.

While LLN are one class of a constrained network, I believe the focus of CoRE should be a bit wider and narrower at the same time.  E.g., there may be little reason not to run CoAP on simple nodes connected by RS-485-style networks, even if we don't have a single standard way to map IP onto them right now.  On the other hand, some nodes on an LLN way be able to run HTTP with good results.

In other words:  I'm all for harmonization of terms, except where that muddies the waters.  Let's keep the three terms 6LoWPAN (a specific LLN where we do expect to have some highly constrained nodes), LLN, and constrained nodes/networks separate for now.  Yes, they all fit together in the region where they overlap, but, no, they aren't the same.

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Wed, 3 Feb 2010 08:41:38 +0100

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

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

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

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

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

> 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  

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

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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 3 Feb 2010 08:41:58 +0100

Hi Carsten,

On Feb 3, 2010, at 7:58 AM, Carsten Bormann wrote:

> While LLN are one class of a constrained network, I believe the  
> focus of CoRE should be a bit wider and narrower at the same time.   
> E.g., there may be little reason not to run CoAP on simple nodes  
> connected by RS-485-style networks, even if we don't have a single  
> standard way to map IP onto them right now.  On the other hand, some  
> nodes on an LLN way be able to run HTTP with good results.
>
> In other words:  I'm all for harmonization of terms, except where  
> that muddies the waters.  Let's keep the three terms 6LoWPAN (a  
> specific LLN where we do expect to have some highly constrained  
> nodes), LLN, and constrained nodes/networks separate for now.  Yes,  
> they all fit together in the region where they overlap, but, no,  
> they aren't the same.
>

We know that terminology can be discussed for years ;-) I am not  
particularly pushy for the use of one term or another but what I  
definitely noticed is that people and the industry can rightly be  
confused by all these terms. I cannot count the number of times I had  
this question ... what is the difference between 6lowpan, WSN, IP  
sensor networks, .... etc. I would personally prefer a slightly more  
generic term that cover them all and harmonized the terminology across  
all WGs. Just replied to Cullen about LLN. Does that make sense ?

---

From: Robert Cragie <[email-masked]>
Date: Wed, 03 Feb 2010 12:32:03 +0000

+1. The taxonomy of terms is not entirely clear nor defined so trying to 
classify at this stage is difficult. If you are going to pick a general 
term, I think constrained nodes/network works well, as I see LLN as a 
specialisation of a constrained nodes/network.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 03 Feb 2010 12:46:09 +0000

Just a couple of minor comments inline.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

> 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…
<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>
>    features will limit themselves to a narrower subset of deployment
<RCC>Still not entirely happy with this language but can live with it - 
see earlier comments posted on January 26th.</RCC>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Feb 2010 10:56:06 +0200

JP, Cullen,

Below are my comments regarding discovery, I agree it is an important feature. Summary: 

After the BOF consensus, what makes the most sense is to include a basic mechanism as part of CoAP which can be used for discovering devices running a CoAP service, and which CoAP resources that service has. This can surely be extended and used for wider purposes by others, here we should define the bare minimum that works and is interoperable.

For the first charter we do not want to define or modify a general service discovery protocol, such as SLP. That is, we don't want to discover printers running IPP. I do agree that there is a need for a constrained general service discovery protocol, and that might be something for re-chartering later or for another WG. 

Comments in-line:

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

Yes, this can be used for discovery of devices running CoAP and their resources.  Sure, some text making that clear is a good idea.

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

I think you described that nicely Cullen. 

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

Right, CoAP will support basic discovery of its own services, which is a good starting point. It is the best we can do for this charter. If we want to work on adapting or designing a new protocol for general service discovery (like SLP) then that will need re-chartering. Anyways, 6lowapp is a more general interest area, which may spawn several working groups. So this might be something for interested people to keep working on and then spin off a "Lightweight Service Discovery" LSD ;-) WG?

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 4 Feb 2010 09:48:54 -0500

Zach, JP, Cullen,

> For the first charter we do not want to define or modify a general service discovery protocol, such as SLP. That is, we don't want to discover printers running IPP. I do agree that there is a need…
KL> Your comments seem contradictory here - we want a basic mechanism
for discovering
devices running CoAP, but don't want to use a protocol that already
exists for that purpose?
> Yes, this can be used for discovery of devices running CoAP and their resources.  Sure, some text making that clear is a good idea.
KL> IMO, this is equivalent to the security discussion; we aren't
chartered to invent a new
constrained security protocol, but we do need to specify ONE baseline
selection that all
CoAP nodes will support, for interoperability.  Common device
naming/discovery/resolution
is an element necessary for interoperability.
>>> 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 bein
>  g 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.
>>>
KL>  As a thought experiment, remove DNS from the Internet and see
where that leaves
us.  Or, equivalently, deploy two or three similar mechanisms and let
people choose the
one they want.  That may work for a PC, but not for a constrained
device that will be up in
the ceiling for the next 30 years
> Right, CoAP will support basic discovery of its own services, which is a good starting point. It is the best we can do for this charter. If we want to work on adapting or designing a new protocol f…
I agree strongly with JP, as can be inferred from my comments above.
BACnet, for
example, models devices as collections of objects, objects as
collections of properties.
Viewed from a scoping perspective, BACnet device identifiers are
unique in network
scope, object IDs in device scope, property IDs in object scope.  So
yes, service
primitives for discovering the resources within a device are
absolutely within the charter.
But a separate protocol must be employed to discover those devices in
the first place.
If the choices for naming and discovery are left to each vendor or
industry then there
will be no interoperability.

A closely related topic is what we mean by "device".  There is wording
in the draft
that contradicts any assumption about a 1:1 correspondence between "device" and
"host";  "Typically a single physical host on the network would have
just one Device
but a host may represent multiple logical Devices."  As I interpret
this, a device is
really an instance of the CoAP service (protocol).  So the
naming/discovery choice
should be one that is lightweight and purpose-built for service discovery.
See draft-cheshire-dnsext-multicastdns-08.txt for an existence proof
and draft-cheshire-dnsext-dns-sd-05.txt, its complimentary extension.
To get a feeling for what these drafts mean by "service", see the list at
http://www.dns-sd.org/ServiceTypes.html

Regards, -K-

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Feb 2010 20:23:50 +0200

Kerry,

> devices running CoAP, but don't want to use a protocol that already

There is a misunderstanding with Device, as you noted below. What I am trying to say is that the bare minimum functionality we need is to be able to query a CoAP service about its resources. This is the equivalent of a standardized /index.html for CoAP. The naming of such resources should definitely be IETF consistent. This is what the charter says currently. Of course being able to make such a query multicast, using a standardized port, and to advertise it, is powerful already if done right.  

What we heard in Hiroshima (I think you were not present?) was that this WG needs to keep its scope very limited.  If there is a need for general discovery (what devices and services (using which protocols) exist in the first place?), sure you would use/modify an existing protocol like SLP or mDNS. Do we always need this for the kind of discovery in the energy and building automation applications that are the main focus here? As examples, HTTP web services for devices tend to use DPWS and BACnet has built-in naming and discovery. Can we even assume that constrained devices will implement many protocols in the first place?

> is an element necessary for interoperability.

Yep, and CoAP nodes run CoAP. The built-in mechanism should be enough. If it is specified well, then that gives you interoperability without the minimum complexity.

> the ceiling for the next 30 years

Exactly, this is why we included this basic mechanism in the protocol. 

> absolutely within the charter.

I have no problem with that. The charter already comes pretty close here.

> will be no interoperability.

Now we get to the point. A separate protocol should not be *required* to discovery CoAP services in the first place.

CoAP nodes run CoAP, and by simply doing a multicast CoAP READ on /resources using default CoAP UDP port 61626 (just a simplified example) there you go. Different industries will need to customize their interface definitions, and the idea is to allow that by including a URI to an interface description (e.g. WADL). 

> really an instance of the CoAP service (protocol).  

Good point, we should update the charter.

> So the

Sure, if you need general service discovery there is nothing stopping you from using these (this was discussed in the BOF). In fact the charter already mentions that any naming for resources should be compatible with e.g. mDNS naming. 

What would make you happy here (yet still get us a WG)? We could of course include text saying that we will recommend a service discovery protocol that should be used in addition to CoAP, if such a step is needed. Cullen, do you think that is still compatible with the BOF? 

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 4 Feb 2010 14:27:34 -0500

Hi Zach,

Comments inline...

> There is a misunderstanding with Device, as you noted below. What I am trying to say is that the bare minimum functionality we need is to be able to query a CoAP service about its resources. This i…
KL>Understood, but I'm saying you need to be able to locate the CoAP
service instance
before you can query it. Thus, I'm saying that both functions are
necessary (or minimal).

> What we heard in Hiroshima (I think you were not present?) was that this WG needs to keep its scope very limited.
KL> I attended remotely.

>If there is a need for general discovery (what devices and services (using which protocols) exist in the first place?), sure you would use/modify an existing protocol like SLP or mDNS. Do we always need this for the kind of discovery in the energy and building automation applications that are the main focus here? As examples, HTTP web services for devices tend to use DPWS and BACnet has built-in naming and discovery. Can we even assume that constrained devices will implement many protocols in the first place?
>
KL> I'm trying to avoid requiring constrained devices to implement
more than one service
discovery protocol, by requiring at least one.  In the case of BACnet,
its discovery
mechanism relies on broadcast and is not IT friendly.  In order to
discover devices off-
net, special devices called BBMDs (BACnet Broadcast Management Devices) are
required.  A new WG, BACnet IT, has just been chartered to facilitate
the convergence
of BAC and IT networks.  Device discovery is one area being discussed.
 Obviously,
the whole industry would need to adopt a common mechanism, as they have now, to
ensure interoperability.
> CoAP nodes run CoAP, and by simply doing a multicast CoAP READ on /resources using default CoAP UDP port 61626 (just a simplified example) there you go. Different industries will need to customize…
KL> It seems you're assuming a well-known port, which is OK, but it
means we need
some mechanism in the CoAP protocol (other than port) to demultiplex
multiple instances
running on the same host (as in the case of a proxy).  I am also
concerned about the
constraint implied by your comment that devices can only discover other CoAP
instances on the same link.  If CoAP nodes are to discover and communicate with
off-link devices, then I think this requires multicast support or a
name binding service.
If the latter, then let's not invent a new one.
> What would make you happy here (yet still get us a WG)? We could of course include text saying that we will recommend a service discovery protocol that should be used in addition to CoAP, if such a…
KL> That language would make me happy :)

Regards, -K-

---

From: JP Vasseur <[email-masked]>
Date: Thu, 4 Feb 2010 21:07:31 +0100

>> Sure, if you need general service discovery there is nothing  
>> stopping you from using these (this was discussed in the BOF). In  
>> fact the charter already mentions that any naming for resources  
>> should be compatible with e.g. mDNS naming.
>>
>> What would make you happy here (yet still get us a WG)? We could of  
>> course include text saying that we will recommend a service  
>> discovery protocol that should be used in addition to CoAP, if such  
>> a step is needed. Cullen, do you think that is still compatible  
>> with the BOF?
>>

Me too.

Cheers.

JP.

>>>> This e-mail and all attached material are confidential and may  
>>>> contain legally privileged information. If you are not the  
>>>> intended recipient, please contact the sender and delete the e- 
>>>> mail from your system without producing, distributing or  
>>>> retaining copies thereof.
>>>>
>>>>
>>>>
>>>>
>> This e-mail and all attached material are confidential and may  
>> contain legally privileged information. If you are not the intended  
>> recipient, please contact the sender and delete the e-mail from  
>> your system without producing, distributing or retaining copies  
>> thereof.
>>
>>
>>
>>
>>