[core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-00

[Robert Quattlebaum <[e-mail]>]

Hello!

Here are my comments on draft-shelby-core-coap-00: (Separated by  
'-----')

What is the use case for the CREATE and DELETE methods? Wouldn't the  
resources exposed by a device be somewhat static? What sorts of  
resources would I be creating or deleting on a temperature sensor, a  
power meter, or an appliance module?

-----

I think that the UPDATE method and the NOTIFY method could be combined  
into one method. I believe that it would be relatively easy to design  
the protocol in such a way as to make this distinction unnecessary.  
(Elaborated on in my comments on draft-shelby-core-coap-req-00, below)

-----

I am assuming that, since URLs are being used, a physical device  
contains a hierarchy of nodes (Resources?) which can be read, updated,  
etc. If so, a explicit way to walk thru the hierarchy would be needed.  
I would recommend a walk-type mechanism (requiring multiple queries)  
as opposed to 'READ' returning all of the subnodes/resources---because  
the list of subnodes/resources may not fit into a single packet. It  
would also likely be easier to implement a walking system on highly  
constrained devices.

-----

Additional error codes worth considering:

401 Unauthorized
403 Forbidden
405 Method Not Allowed
409 Conflict
500 Internal Server Error
503 Service Unavailable
504 Gateway Timeout

-----

For the URI codes: 256 values may not be enough. Perhaps an adaptive  
encoding allowing for larger indices is warranted. A possible encoding  
scheme would be similar to the EXI Unsigned Integer encoding: <http://www.w3.org/TR/exi/#encodingUnsignedInteger 
 >. This integer encoding could also be used for the content-type  
encoding---which would reduce the size of that option by a byte for  
the 128 most common content types.

-----

I am unconvinced of the utility or practicality of a TCP interface for  
this protocol. In any case where TCP would be considered, I think a  
protocol such as HTTP would likely be better suited. My thinking is  
that any device powerful enough to do proper TCP would surely be  
powerful enough to do simple HTTP.

-----

Here are my comments on draft-shelby-core-coap-req-00:

Having a push model be a requirement is a good thing, but I do not  
think that a subscribe/notify mechanism is the ideal way to go. I  
think a more flexible approach is one where each device exposes  
"events" (resources which push) to "actions" (resources which do  
something when they receive a push). Events are then "paired" to  
actions, using some sort of administrative interface. This gives you a  
huge amount of flexibility.

This was the model I was using for "SCMP", which I document in  
considerably more detail here: <http://www.ietf.org/mail-archive/web/core/current/msg00119.html 
 >

For example, lets say that you have a light switch module and an  
appliance module. The module has a 'state' variable, that is either  
'on' or 'off'. The state variable would have three events associated  
with it: 'changed', 'turned-on', and 'turned-off'. The payload is the  
same for each event, but 'turned-on' only fires when the switch is  
turned on, and 'turned-off' only fires when the switch is turned off.  
The appliance module has a 'state' variable as well, and it has the  
following actions: 'set', 'turn-on', and 'turn-off'. The 'set' action  
would update the 'state' variable to match the payload of the event,  
assuming the content-type of the event matches the type of the 'state'  
variable. The 'turn-on' and 'turn-off' events would change the state  
variable to 'on' or 'off' respectively, ignoring the payload of the  
event. In general events and actions don't have to be associated with  
variables, but I'm doing so here for the sake of clarity.

You can pair the 'changed' event to the 'set' action, and then the  
light switch would control the appliance module. In this case, the  
'set' action is getting the value to set from the payload of the  
'changed' event. (This is why I suggest that the 'UPDATE' and 'NOTIFY'  
methods could perhaps be merged into a single method)

Alternatively, you could have an inverse relationship: You could pair  
the 'turned-off' event to the 'turn-on' action, and pair the 'turned- 
on' event to the 'turn-off' action. Now whenever the light switch is  
'on', the appliance module is 'off', and vise-versa. This works  
because the 'turn-on' and 'turn-off' actions don't care what the  
payload of the event they are receiving is---they perform a specific  
action whenever they are triggered.

I think this mechanism is superior to the subscribe/notify mechanism  
for the following reasons:

Additional metadata or actions can be associated with a pairing (such  
as reliability requirements).
Security credentials can be created per-pairing. This way, if a device  
is completely compromised the only actions an attacker can take are  
the ones already paired.
One-to-many pairings could be created that would use IPv6 multicasting  
for more efficient network utilization, while still maintaining the  
security credentials described above.
All pairings happen at setup, so if any resource constraints are  
exceeded (i.e. too many pairings) it is known at configuration time.  
If subscriptions happen at run-time, then device resources could be  
exhausted under certain circumstances causing some subscriptions to  
fail.

Pairings could be made in one of two ways:

Using a user interface on a computer.
Using a simple push-button pairing for simple, pre-defined device  
relationships. (e.g. light switch to lamp, volume knob to a stereo,  
temperature control panel to an HVAC system, etc.)

There are a lot of implementation details I'm skipping over for the  
sake of clarity. Please don't hesitate to ask if you want me to  
clarify or elaborate on any of the point I have made.

Thoughts?

__________________
Robert Quattlebaum
Jabber: [e-mail]
eMail:  [e-mail]
www:    http://www.deepdarc.com/