Subject: [6lowapp] Revised Charter Proposal

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Jan 2010 16:25:05 -0700

I tired to incorporate the discussion on the list and the discussion from he BOF into a revised charter proposal. I'd like to see if there were any feedback early this week then, if things look like this charter is close, send this to Lisa (our AD) and see if this can make it on the next IESG call. 

Cullen

----------------------

CoRE

Applications are being developed for IP networks that have very limited
packet sizes, exhibit a high degree of packet loss, and have 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 applications 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. These networks are becoming increasing important
for applications such as home and building automation, energy
management, and the Internet of Things. This working group will define a
framework for a limited class of applications that deal with the
manipulation of simple resources on constrained devices. This includes
applications to monitor simple sensors (e.g.  temperature sensors, light
switches, and power meters) and control actuators (e.g. light switches,
heating controllers, and door locks).

The general architecture consists of nodes on the constrained network,
called Devices, that have one or more Resources that may represent
sensors, actuators, or other values. 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. As part of the framework for building these
applications, the WG will define a Constrained-node/network Application
Protocol (CoAP) for the manipulation of Resources on a Device. The
framework will also specify a way to define new interface profiles that
vendors and other standards bodies can use to define the particular
Resources on a Device and what manipulations are possible.

CoAP will be designed to be used between Devices on the same constrained
network, between Devices and general nodes on the internet, and between
devices on different constrained networks both joined to the internet.

There also may be nodes called Constrained-to-General-Internet
Intermediaries (CoGII) that interconnect between other protocols
typically used by applications on the internet and the Devices using the
CoAP protocol.  The WG will define a mapping on the CoGII from CoAP to
an HTTP REST API; this mapping will not depend on a specific
application.  Each interface profile will define the Resources on the
Device that applications can manipulate and what manipulations are
possible.  This will determine, in a mechanical translation way, the
HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to
manipulate the Resources on the Device; it will also specify an XML MIME
type for each class of Device that can be used to describe the Resource
state in the body of HTTP REST messages. It is worth noting that the
CoGII does not have to be deployed at the boundary of the constrained
network and the more general network but can be deployed at various
locations in the unconstrained network.

CoGIIs can provide 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 CoGII that has subscribed, when
the CoGII 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 CoGIIs may also provide support
for discovering Devices that may not be currently responding as they are
temporarily asleep.

The initial work items of the WG is to define a protocol specification
for CoAP that includes:

1) A way to define the "interface profile" that specifies the Resources
   for a Device and implies the REST API that can be used

2) The ability to set and query a resource on a Device.

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

4) 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
   simultaneously.  The goals would be delivery of messages roughly
   within 50 ms of each other for closely located Devices on suitable
   networks to meet the use case of several lights appearing to turn on
   at the same time to a human observer.

5) Default operation of the protocol will be over UDP; it may optionally
   use TCP or other reliable transports.
 
6) A definition of how to use CoAP to discover Devices on the
   constrained network, and to interrogate them to find out which
   interface profiles they support.  The name taxonomy used for
   discovery will be consistent with the approach defined in
   draft-cheshire-dnsext-dns-sd.

7) An ability for Devices to provide a pointer to the general schema
   information so that a CoGII does not need any code changes to support
   new Device classes.

8) Specification for the HTTP REST based API and mapping on the CoGII to
   communicate with Devices.

The working group will not develop a reliable multicast solution.

Security, particularly keying of new Devices, is very challenging for
these applications. On one hand this needs to support models in which an
end user can introduce onto their network a new Device that may have no
display or input capabilities. On the other hand, this protocol may
transport information about alarm systems or controlling door locks over
a wireless network.

The WG will work to support methods of security bootstrapping which are
realistic given the constraints and requirements of the network. These
methods are not specific to any communication layer. Instead the methods
could run across any layer, including IP. Requirements considered
include:

1) The methods need to be suitable for use on resource constrained
   nodes. These constraints include power, cost, size, and computational
   capacity. [[ Note: the WG realizes the vagueness of this constraint
   but does not currently have consensus on a more quantitative metric
   of these constraints ]]

2) The methods need to provide sufficient security for the application
   space.

3) The methods must guarantee that any two nodes can join together. This
   includes nodes which are already on separate networks which a user
   wishes to merge together.

4) There may be additional requirements for each application space, such
   as urban or commercial environments which deploy large networks,
   compared to residential environments.

To ensure that any two nodes can join together, all nodes must implement
at least one universal method. In additional several other methods will
be specified which take advantage of the application space. In
commercial applications, for instance, bootstrapping can take advantage
of the fact that networks are typically managed from a central
authority, and a method optimized for residential usage might take
advantage of the fact that nodes are in close proximity.

Methods which will be considered include:

1) Out of Band Key or Certificate: In this mode a key (either symmetric
   or asymmetric) is distributed with the product, such as a 2D barcode
   printed on the node. The user can scan this key with a computer to
   give access to this node.

2) Physical Button Protocol: In this mode two nodes only require
   pushbuttons and LEDs, and the user simply pushes the button on each
   node within a narrow time window to join them together.

3) Out of Band Communication Link: This could include IrDA or NFC (Near
   Field Communication) type technologies to allow a device to join
   another device that is physically nearby.

4) Out of Band Configuration: A simple example of this would be using
   the programming interface which a node uses to download firmware.

This list should not be considered exhaustive, and methods may be
removed or added as additional application spaces and requirements are
found. The list gives examples of the types of methods to be
investigated.

Security can be achieved using other session security or object
security.  For session security, the WG will work with the security area
to select cipher suites most useful for constrained network.  For object
security, CoAP will initially look at CMS (RFC 5652).

The WG will coordinate on requirements from many organizations including
OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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:

Mar 2010 - Select WG document for basis of CoAP protocol

Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API
           submitted to IESG as PS

Jan 2011 - Recharter to add things reduced out of initial scope

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 24 Jan 2010 19:13:49 -0500

For the configuration part, there is significant existing work, as part of the Wi-Fi Protected Setup™ ("Facilitates easy set-up of security features using a Personal Identification Number (PIN) or other defined methods within the Wi-Fi device"). Not sure this needs to be called out explicitly, but somebody may want to make sure we don't rule out reasonable mechanisms that seem to have widespread support in a similar scenario elsewhere.

Henning

On Jan 24, 2010, at 6:25 PM, Cullen Jennings wrote:

> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 25 Jan 2010 08:26:52 +0100

Hi,

looks pretty good. A few comments: 

In general, I'm missing a statement that this will use the 6LOWPAN and ROLL way of doing IPv6 over these links rather than some other way, or - even worse - IPv4. (The coordination text has some words about 6LOWPAN and ROLL, but nothing that I read as "6LOWPAN will use their stuff.)

>   at the same time to a human observer.

Doesn't apply this magic 50ms number also to unicast traffic? More importantly though, there is not much that CoAP can do in guaranteeing that delay; it seems to be almost entirely dependent on the underlying routing, radio and sensor technologies.

>   use TCP or other reliable transports.

I think we need to rephrase this bullet. I don't think you mean "optionally, TCP can be used in stead of UDP" when you say "it may optionally...", but it can be misread in this way.

Also, while folks have demonstrated that you can run TCP at acceptable performance in some deployments, I believe that these deployments have been very controlled in terms of their topology, radio configuration, routing setup, etc. *In such cases* CoAP could optionally partially use TCP for some operations, but in most deployments (esp. "unmanaged" home deployments) this will simply not work very well. All the essential functions of CoAP must IMO therefore run over UDP.

>   compared to residential environments.

Must CoAP support these application spaces from the beginning? If some of the yet-unstated requirements for these app spaces are conflicting, it's really easy for the WG to wedge itself, because the design space for the solution becomes the empty set.

Or is the paragraph above still about bootstrapping methods? Segway: I think you should explicitly say "bootstrapping method" in almost all places where you currently say "method" to make it clear whether that is what you mean. And if not, use a different word :-)

> security, CoAP will initially look at CMS (RFC 5652).

For session security, you not only need ciphers, you also need a protocol. Is the intent that you'd use TLS/DTLS? Then please say so.

Lars

---

From: "Oflynn, Colin" <[email-masked]>
Date: Mon, 25 Jan 2010 01:31:20 -0700

Hi Cullen,

Those methods are a good starting point, but I don't feel entirely suitable. I've put a number of thoughts in a document at http://www.newae.com/tiki-download_wiki_attachment.php?attId=5

There should shortly be an RFC with details on breaking down the exact requirements & solutions as well. Shorlty as in days....

Regards,

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Henning Schulzrinne
Sent: Mon 25/01/2010 00:13
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [6lowapp] Revised Charter Proposal
 
For the configuration part, there is significant existing work, as part of the Wi-Fi Protected SetupT ("Facilitates easy set-up of security features using a Personal Identification Number (PIN) or other defined methods within the Wi-Fi device"). Not sure this needs to be called out explicitly, but somebody may want to make sure we don't rule out reasonable mechanisms that seem to have widespread support in a similar scenario elsewhere.

Henning

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 Jan 2010 10:44:53 +0100

Cullen,

Good start, I have a few observations: 

- there is a lot of standardization activity in this area. Beyond what
is already mentioned in the charter I know about IEEE P802.3az doing
significant work in the  Energy-Efficient Ethernet Task Force, Henning
mentioned WiFi. We need to understand what 'The WG will coordinate on
requirements' means. If something is developped by another SDO do we
need to replicate the work in the IETF? Maybe yes in some cases, if the
work is for example layer 2 specific. 
- The milestone 'Mar 2010 - Select WG document for basis of CoAP
protocol' is completely unrealistic taking onto account that the charter
is not yet in IESG review
- The operational and manageability aspects are not mentioned, excepting
firmware updates. They are implied in some of the capabilities like
querying resources, but I think that observability of device presence
and operational status query should be mentioned explicitly. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Monday, January 25, 2010 1:25 AM
> To: [email-masked]
> Subject: [6lowapp] Revised Charter Proposal
> 
> 
> I tired to incorporate the discussion on the list and the 
> discussion from he BOF into a revised charter proposal. I'd 
> like to see if there were any feedback early this week then, 
> if things look like this charter is close, send this to Lisa 
> (our AD) and see if this can make it on the next IESG call. 
> 
> Cullen
> 
> ----------------------
> 
> 
> CoRE
> 
> Applications are being developed for IP networks that have 
> very limited packet sizes, exhibit a high degree of packet 
> loss, and have 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 applications 
> 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. These networks are becoming 
> increasing important for applications such as home and 
> building automation, energy management, and the Internet of 
> Things. This working group will define a framework for a 
> limited class of applications that deal with the manipulation 
> of simple resources on constrained devices. This includes 
> applications to monitor simple sensors (e.g.  temperature 
> sensors, light switches, and power meters) and control 
> actuators (e.g. light switches, heating controllers, and door locks).
> 
> The general architecture consists of nodes on the constrained 
> network, called Devices, that have one or more Resources that 
> may represent sensors, actuators, or other values. 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. As part of the framework for building these 
> applications, the WG will define a Constrained-node/network 
> Application Protocol (CoAP) for the manipulation of Resources 
> on a Device. The framework will also specify a way to define 
> new interface profiles that vendors and other standards 
> bodies can use to define the particular Resources on a Device 
> and what manipulations are possible.
> 
> CoAP will be designed to be used between Devices on the same 
> constrained network, between Devices and general nodes on the 
> internet, and between devices on different constrained 
> networks both joined to the internet.
> 
> There also may be nodes called 
> Constrained-to-General-Internet Intermediaries (CoGII) that 
> interconnect between other protocols typically used by 
> applications on the internet and the Devices using the CoAP 
> protocol.  The WG will define a mapping on the CoGII from 
> CoAP to an HTTP REST API; this mapping will not depend on a 
> specific application.  Each interface profile will define the 
> Resources on the Device that applications can manipulate and 
> what manipulations are possible.  This will determine, in a 
> mechanical translation way, the HTTP REST APIs on the CoGIIs 
> and the CoAP protocol encoding to manipulate the Resources on 
> the Device; it will also specify an XML MIME type for each 
> class of Device that can be used to describe the Resource 
> state in the body of HTTP REST messages. It is worth noting 
> that the CoGII does not have to be deployed at the boundary 
> of the constrained network and the more general network but 
> can be deployed at various locations in the unconstrained network.
> 
> CoGIIs can provide 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 CoGII 
> that has subscribed, when the CoGII 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 CoGIIs may also provide support for 
> discovering Devices that may not be currently responding as 
> they are temporarily asleep.
> 
> The initial work items of the WG is to define a protocol 
> specification for CoAP that includes:
> 
> Security, particularly keying of new Devices, is very 
> challenging for these applications. On one hand this needs to 
> support models in which an end user can introduce onto their 
> network a new Device that may have no display or input 
> capabilities. On the other hand, this protocol may transport 
> information about alarm systems or controlling door locks 
> over a wireless network.
> 
> The WG will work to support methods of security bootstrapping 
> which are realistic given the constraints and requirements of 
> the network. These methods are not specific to any 
> communication layer. Instead the methods could run across any 
> layer, including IP. Requirements considered
> include:
> 
> To ensure that any two nodes can join together, all nodes 
> must implement at least one universal method. In additional 
> several other methods will be specified which take advantage 
> of the application space. In commercial applications, for 
> instance, bootstrapping can take advantage of the fact that 
> networks are typically managed from a central authority, and 
> a method optimized for residential usage might take advantage 
> of the fact that nodes are in close proximity.
> 
> This list should not be considered exhaustive, and methods 
> may be removed or added as additional application spaces and 
> requirements are found. The list gives examples of the types 
> of methods to be investigated.
> 
> Security can be achieved using other session security or 
> object security.  For session security, the WG will work with 
> the security area to select cipher suites most useful for 
> constrained network.  For object security, CoAP will 
> initially look at CMS (RFC 5652).
> 
> The WG will coordinate on requirements from many 
> organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO 
> Alliance, OASIS, SENSEI; 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:
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 10:38:06 -0700

I think I made one (or at least one) big mistake in this charter update. At the end of the BOF, there was clear consensus to make the initial charter thorough out everything but the minimal approach. (Basically Ted Hardie's proposal). I thought I had done this but realize in going back and listening to the BOF recording that this included leaving the discovery stuff to a later time. I think I need to update the charter to move the discovery work to not be in the initial scope of work.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 10:39:38 -0700

Makes sense - do you want to propose another bullet point for this one or a modification of one of the existing bullet points to cover it ?

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 11:14:39 -0700

Some comments on Security section rewrite ideas inline ....

>   but does not currently have consensus on a more quantitative metric
thought this is true, hard to see how it constrains the WG or specifies what needs to happen. 

> 2) The methods need to provide sufficient security for the application

This does not really mean much - clearly true. 

>   wishes to merge together.

Could we just say it as there much be a security mandatory to implement way security mechanism. As far as I can tell, all we are saying is we will follow rules of BCP 61 here. 

>   compared to residential environments.

Not sure what this implies to work in the WG. Agree it is true, but what do we need to say in the charter.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 11:15:41 -0700

Thanks Lars, few comments inline ....

> In general, I'm missing a statement that this will use the 6LOWPAN and ROLL way of doing IPv6 over these links rather than some other way, or - even worse - IPv4. (The coordination text has some wo…

Everything I have heard in every so far about what people want to develop here is just it will run on an IP network. That would include IPv4, IPv6, and a 6LowPAN network and other networks where UDP, TCP, or whatever transport we use would work. I'm not sure how to phrase that in the charter but can you come up with some words that reflect that? 

> Doesn't apply this magic 50ms number also to unicast traffic? More importantly though, there is not much that CoAP can do in guaranteeing that delay; it seems to be almost entirely dependent on the…

Yep, I've received multiple comments that amount to IP guarantees nothing about making anything happened in 50 ms.  I think we should remove this but I'd like to figure out some way of saying it's a goal to be able to use this as part of an overall system that can get things to happen "simultaneously" from human point of view. Take RTP for example. Clearly RTP can be deployed on many IP networks and have a realtime experience that is "same time" from human point of view (i.e., audio with less than 150 ms of latency). I'm no sure how to phrase that type of goal. Ideas ?

> Also, while folks have demonstrated that you can run TCP at acceptable performance in some deployments, I believe that these deployments have been very controlled in terms of their topology, radio…

I think most people agree with what you are saying here. Help me get the text to be very clear about what we intended to do. How about something like 

5) The mandatory to implement transport for the protocol will be UDP. The WG may choose to specific additional transport protocols. 

Anyone else willing to write some replacement text here ?

> For session security, you not only need ciphers, you also need a protocol. Is the intent that you'd use TLS/DTLS? Then please say so.

So my two cents an individual contributor ... The WG is definitely not proposing to invent anything new. It would select something like TLS/DTLS and/or CMS and then also say a set of mandatory to implement ciphers. This would likely be a very minimal set.  The more I look at this, and the fact that it needs to gateway from CoAP to HTTP, the more I become convinced that the value of session based security is somewhat limited and we really need object based security here but I don't know that many folks agree with me on that. I had pushed the previous text a bit that was very constraining on what we would do for security as a way to speed things up. People proposed text on the list (which I paraphrased roughly into the current charter) that was much less constraining and more like exploitative of things that could be tried. My read of folks involved is that something like current text is what most people could live wish but clearly we need to tighten this up a bunch.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 11:31:56 -0700

> work is for example layer 2 specific. 

Yah, my experience with the words "coordinate" in charters has not exactly been good. Lets get specific about what you think this WG should do. It would definitely not be developing any layer 2 or 3. I'm not seeing how this has much to do with the P802.3az stuff (other than it very well may be running on a network using that). I think the WiFi comment was more about lets not reinvent a enrollment model if we can just use the technique developed by some people that put a huge amount of time into. I totally agree with Henning on that so I expect to update text a bit. 

One really good thing about coordination, I know that both Henning and Zack are going to closely follow this work and they are both on the Smart Grid Directorate that will help coordinate with other SDOs so I am confident things will not slip through the cracks. 

> is not yet in IESG review

I don't believe in dates in charters :-) but yes, agree. It seems that we might be abel to do this shortly after the March meeting depending on how that meeting goes. What date do people want to put in? makes no difference to me. 

> and operational status query should be mentioned explicitly. 

OK. Let me make an analogy of this work is a bit like we are defining a protocol like http here and not the protocol one would necessarily use to to manger a web server system. Agree we need to say more around ops and management but not sure what to say. Can you help me figure out what to say. Given the discussion in the BOF, we need to make sure what whatever we add it does not require Devices to be powered on at all times and we need to be sure that it does not require a way to enumerate all the Devices on the system as that is a discovery problem that is explicitly out of scope for now.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Jan 2010 11:37:32 -0700

Other request for ideas on charter improvement ....

Can someone come up with abetter name than CoGII. It's causing confusion and hard to pronounce or remember.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 25 Jan 2010 13:42:56 -0500

Cullen,

I, for one, am nervous about deferring a naming and discovery approach
and feel that this is important to interoperable implementations.  Not sure
I see the value of creating a framework for defining new profiles and
interface objects, if there's no consistent way to name and discover them.

Regards, -K-

---

From: Lars Eggert <[email-masked]>
Date: Mon, 25 Jan 2010 19:43:14 +0100

Hi,

> Everything I have heard in every so far about what people want to develop here is just it will run on an IP network. That would include IPv4, IPv6, and a 6LowPAN network and other networks where UD…

maybe the charter should simply say that 6LOWAPP targets a ROLL/6LOWPAN environment with all its additional constraints compared to normal IP networks, but that it is expected that the resulting CoAP protocol should also operate over traditional IP networks?

> Yep, I've received multiple comments that amount to IP guarantees nothing about making anything happened in 50 ms.  I think we should remove this but I'd like to figure out some way of saying it's…

You could say something like "non-reliable multicast delivery of CoAP messages should have a performance that is close to the IP multicast delivery performance achievable over the underlying IP topology?" (In other words, CoAP is not a significant source of additional latency.)

> 5) The mandatory to implement transport for the protocol will be UDP. The WG may choose to specific additional transport protocols.

I'm not sure that this captures all of it. If UDP is mandatory to implement and works well, there's really not a huge need to even use other transports. I thought the main motivation for TCP was that some operations (such as reliable delivery of a chunk of data larger than the MTU) are difficult and/or slow over UDP.

If that's the case, maybe we should say that the core CoAP functionality MUST be operate well over UDP and that it MUST be implemented over UDP, but that there are OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. And then point out that these functions are only expected to work under very specific deployment scenarios and that hence applications needing those OPTIONAL functions limit themselves to a narrow subset of deployment cases.

> Anyone else willing to write some replacement text here ?

Yes, please bash this text.

>> Or is the paragraph above still about bootstrapping methods? Segway: I think you should explicitly say "bootstrapping method" in almost all places where you currently say "method" to make it clear…

The comment above is separate from the next one below. You might have missed that and skipped over it - although minor, I want to make sure that this doesn't fall through the cracks :-)

> So my two cents an individual contributor ... The WG is definitely not proposing to invent anything new. It would select something like TLS/DTLS and/or CMS and then also say a set of mandatory to i…

All makes sense. My main point is that security for CoAP will need not only agreed on ciphers, but also a MUST-implement session- and/or object-security *protocol*.

Lars

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Jan 2010 22:20:19 +0200

> I think I made one (or at least one) big mistake in this charter update. At the end of the BOF, there was clear consensus to make the initial charter thorough out everything but the minimal approac…

Yep, the BOF message was definitely to keep the scope focused on CoAP and reduce the number of work items. I would say that CoAP needs to have a basic discovery mechanism which can then be used by others (SE 2.0, DPWS etc.) or later by us to define the details. Thus we could leave out the definition of profiles and how to use the discovery mechanism in my opinion.

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: Zach Shelby <[email-masked]>
Date: Mon, 25 Jan 2010 22:22:35 +0200

> Can someone come up with abetter name than CoGII. It's causing confusion and hard to pronounce or remember. 

Forget about CoGIIs all together. We are only defining an HTTP mapping, we don't have to define the entity where that is performed. 

Zach

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Jan 2010 22:31:47 +0200

> maybe the charter should simply say that 6LOWAPP targets a ROLL/6LOWPAN environment with all its additional constraints compared to normal IP networks, but that it is expected that the resulting Co…

This is good. 

> You could say something like "non-reliable multicast delivery of CoAP messages should have a performance that is close to the IP multicast delivery performance achievable over the underlying IP top…

This too, good text.

> I'm not sure that this captures all of it. If UDP is mandatory to implement and works well, there's really not a huge need to even use other transports. I thought the main motivation for TCP was th…

That is the main purpose. What about the use of CoAP over the larger Internet? 

> If that's the case, maybe we should say that the core CoAP functionality MUST be operate well over UDP and that it MUST be implemented over UDP, but that there are OPTIONAL functions in CoAP (e.g.…

I am OK with this, especially as it makes implementation more straightforward (having to listen on both UDP and TCP sockets for the same functionality would be a pain). 

> The comment above is separate from the next one below. You might have missed that and skipped over it - although minor, I want to make sure that this doesn't fall through the cracks :-)

The reference above is only regarding security bootstrapping. The target applications in smart energy and building automation both have urban and commercial environments, each with very different security requirements. That is the reason for bringing this up. It could also be mentioned that "urban and commercial" are not new application areas for the WG. 

Zach

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Jan 2010 22:50:44 +0200

More comments in-line: 

On Jan 25, 2010, at 1:25 , Cullen Jennings wrote:

> Protocol (CoAP) for the manipulation of Resources on a Device.

> The

Remove the above sentence. 

> CoAP protocol.  

Remove this sentence (see, no more CoGIIs).

> The WG will define a mapping on the CoGII from CoAP to
> application.

Remove CoGII. Combine with some paragraph above. Add "It is worth noting that this mapping does not have to be deployed at the boundary of the constrained network and the more general network but can be deployed at various locations in the unconstrained network."

>  Each interface profile will define the Resources on the

Remove all this stuff, this has to do with profiles etc. 

> for discovering Devices that may not be currently responding as they are

Replace with something like this:

CoAP can be cached in various ways. For example, if a temperature sensor 
is normally asleep but wakes up every five minutes and sends the current 
temperature to an intermediate subscriber, when the intermediate 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.

>   for a Device and implies the REST API that can be used

Remove.

>   at the same time to a human observer.

Update a la Lars

>   use TCP or other reliable transports.

Update a la Lars

>   draft-cheshire-dnsext-dns-sd.

Update to something like:

The ability for CoAP to be used for the discovery of Devices and resource on 
the constrained network. The details of discovery and profile formats are out of
scope. They may be defined by applications using CoAP or by the WG at a later time if 
necessary.

>   information so that a CoGII does not need any code changes to support

Remove.

>   communicate with Devices.

Remove CoGII.

>   the programming interface which a node uses to download firmware.

One comment is that it might not be necessary to descibe these in such detail in the charter, instead it might be enough to shortly list these. 

> found. The list gives examples of the types of methods to be

It should be explicitly said that the goal of the WG with regard to security bootstrapping is not to develop any new protocols. Instead these methods recommend how to use existing protocols in a constrained configuration.

> security, CoAP will initially look at CMS (RFC 5652).

Mentioning TLS/DTLS would be a good idea.

> Mar 2010 - Select WG document for basis of CoAP protocol

I don't see this as a problem. There has been a lot of work going on already in December and January, the chartering process is going on in parallel. As SE 2.0 has a real need to be able to point at a document - this is a necessary milestone. 

> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API

Does this really need to be a separate RFC? From the BOF I had a feeling we should integrate this mapping with the main CoAP protocol document. Instead, I would find it much more valuable to have the security bootstrapping as its own RFC. 

Zach

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

---

From: "Van Der Stok, Peter" <[email-masked]>
Date: Tue, 26 Jan 2010 12:08:20 +0100

Dear Zach,

I want to send some comments on the CoAP feature analysis draft from a building control point of view.

A picture emerges where a request on general Internet is generated and sent down to the low resources network, which necessitates a translation of HTTP commands to less resource demanding RESTful commands. I like to point out that for building control many (most?) communication originates inside the low resources network and will remain inside that network. However, some commands may remain within the building passing from one low resource network to another, and a smaller fraction will probably generate from outside the building in the general internet network. Efficiency inside the low resources network is more important than efficient translations. My remark does not very much influence the text in the document, but it may have impact on later implementation decisions.

In addition to REQ4 and in conjunction with REQ10, it will be necessary to interrogate on the state of the cached request. A simple statement like: the application is able to check the arrival of the cached request/command will be welcome. How to implement it is a second concern, but when the responsibility is delegated to the application, there remains the problem of waiting for the arrival of the status request by the application.

REQ5. The possibility to subscribe to published data can be made very complex with lots of additional conditions and time constraints within the request. I would suggest that a device can advertise the publication of a fixed set of data with a fixed set of repetition settings (probably a multiple of the sleep interval). Any other sophistication is optional.

REQ8. Although the cited 50ms would be fantastic, their guarantee depends on too many additional operational conditions. A possible phrase is: the multicast results should be delivered in a time comparable to the delivery of the broadcast service provided by the supporting link.
Another point is the scope. Sometimes multicast should be limited to the low resource network limited by the edge router, or should encompass a set of low resource networks (the whole building) possibly identified by a set of prefixes.

REQ10. I don't believe in limiting the reliability to given numbers. The same problem occurs as with response time. The reliability depends on too many other factors. I would be happy with the possibility that the arrival or non-arrival of a message can be tested.

Provision of TCP. When would I use TCP?
(1) reliability: it can tell me whether data arrived (it may say no, although it is yes, but when is says yes, it is yes)
(2) large messages (multiple packets): however the header overhead is such that UDP is preferred at the moment. Large messages can be interesting when descriptions are dumped into a low resource node.
(3) my application on a notebook attached to the building network uses TCP.

In section 2.6 I think to have a slight preference for cache description in the device description. The latter info can be used by the proxy. Difficult to see al consequences though.

I hope this helps a bit.

Peter

Peter van der Stok
Philips Research Laboratories Eindhoven,
High Tech Campus,               HTC 34 (WB) 6-051
5656 AA Eindhoven,              The Netherlands
Phone: +31 40 2749657 ,         Fax: +31 40 2746321
Mailto:  Peter.van.der.Stok@ philips.com

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Jan 2010 13:15:21 +0100

> From: Cullen Jennings [mailto:[email-masked]] 

> 
> > - The operational and manageability aspects are not mentioned, 
> > excepting firmware updates. They are implied in some of the 
> > capabilities like querying resources, but I think that 
> observability 
> > of device presence and operational status query should be 
> mentioned explicitly.
> 
> OK. Let me make an analogy of this work is a bit like we are 
> defining a protocol like http here and not the protocol one 
> would necessarily use to to manger a web server system. Agree 
> we need to say more around ops and management but not sure 
> what to say. Can you help me figure out what to say. Given 
> the discussion in the BOF, we need to make sure what whatever 
> we add it does not require Devices to be powered on at all 
> times and we need to be sure that it does not require a way 
> to enumerate all the Devices on the system as that is a 
> discovery problem that is explicitly out of scope for now. 
> 

At a minimum I think an operator would need to know which devices are at
a given moment in time powered and which are not. The IEEE actually
dealt with this problem by using linkDown / linkUp notifications on a
link - they operate at link level, and power down dormant links to save
energy. 

Dan

---

From: Robert Cragie <[email-masked]>
Date: Tue, 26 Jan 2010 12:36:38 +0000

Some comments below bracketed by <RCC></RCC>. I generally agree with 
Zach's comments unless stated.

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

> Remove CoGII. Combine with some paragraph above. Add "It is worth noting that this mapping does not have to be deployed at the boundary of the constrained network and the more general network but c…
<RCC>I don't think you need to say anything about deployment - it's a 
mapping.</RCC>
> Remove all this stuff, this has to do with profiles etc. 
<RCC>I agree, it's unnecessarily specific</RCC>
> last seen value instead of trying to query the Device which is currently asleep.
<RCC>I don't think you can get away with removing the concept of a 
CoGII. It's all gone a bit hand-wavy now going on about caching at 
'intermediate subscriber' (aka CoGII?) nodes. In my experience, managing 
data for sleeping nodes is one of the more complex and overlooked 
aspects of sensor networks and needs to be focused on not dissolved away 
like this.</RCC>
>>   at the same time to a human observer.
<RCC>I think the original statement is fine if you just remove "roughly 
within 50ms of each other"</RCC>
>>   use TCP or other reliable transports.
<RCC>I think the original statement is almost OK. I would perhaps reword 
as follows: "Default operation of the protocol will be over UDP, however 
it will not be precluded from operating over TCP or other reliable 
transports". This would address the 'wider internet' concern. I don't 
particularly see the point in having options only suitable for TCP, for 
example - this goes against the whole point of CoAP.</RCC>
>> transport information about alarm systems or controlling door locks over
<RCC>
Security is always 'very challenging' ;-). The 'on one hand/on the other 
hand' statement implies opposites but the statements are not logically 
related. I would perhaps rephrase something like the following:

"There are two main aspects of security which need special consideration 
in these applications. There must be support for introduction of Devices 
that may have no display or input capabilities onto the network. Also, 
support for high security is essential as this protocol may transport 
information about alarm systems or controlling door locks over a 
wireless network."
</RCC>
>> could run across any layer, including IP. Requirements considered
<RCC>Remove "Instead the methods could run across any layer, including 
IP"</RCC>
>>   but does not currently have consensus on a more quantitative metric
<RCC>I think we have already defined constrained node/network so I don't 
see the need to repeat it here. The only additional property 
specifically relevant for security called out above is computational 
capacity; maybe this could be incorporated in the original definition.</RCC>
>> 2) The methods need to provide sufficient security for the application
<RCC>I think the statement is rather vague. Perhaps something like "the 
methods need to support a wide range of security requirements coming 
from the application space"</RCC>
>>   wishes to merge together.
<RCC>
There are two things here:

1) It would always be a policy decision whether two nodes can join 
together, so I would rephrase as "the methods must support the joining 
of two nodes"
2) You have opened up a large can of worms when talking about merging 
networks. This has many implications beyond joining two nodes
</RCC>

>>   give access to this node.
<RCC>There are also polynomial-based key distribution methods which may 
be appropriate. Perhaps the statement above should be less specific.</RCC>
> Mentioning TLS/DTLS would be a good idea.
<RCC>..and EAP. Perhaps again this needs to be less specific and "the WG 
will work with the security area to select cipher suites and protocols 
most suitable for constrained networks" might be sufficient. I wouldn't 
call out CMS either at this stage.</RCC>

---

From: "Stuber, Michael" <[email-masked]>
Date: Wed, 27 Jan 2010 09:58:33 -0800

Absolutely agree.  +1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kerry Lynn
Sent: Monday, January 25, 2010 10:43 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [6lowapp] Revised Charter Proposal

Cullen,

I, for one, am nervous about deferring a naming and discovery approach
and feel that this is important to interoperable implementations.  Not
sure I see the value of creating a framework for defining new profiles
and interface objects, if there's no consistent way to name and discover
them.

Regards, -K-

On Mon, Jan 25, 2010 at 12:38 PM, Cullen Jennings <[email-masked]>
wrote:
>
> I think I made one (or at least one) big mistake in this charter
update. At the end of the BOF, there was clear consensus to make the
initial charter thorough out everything but the minimal approach.
(Basically Ted Hardie's proposal). I thought I had done this but realize
in going back and listening to the BOF recording that this included
leaving the discovery stuff to a later time. I think I need to update
the charter to move the discovery work to not be in the initial scope of
work.