Re: [coman] Device Classes?

[Carsten Bormann <[e-mail]>]

On 04 Apr 2014, at 13:45, Hannes Tschofenig <[e-mail]> wrote:

> Hi Carsten.
> 
> 
> On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> On 04 Apr 2014, at 13:32, Hannes Tschofenig <[e-mail]> wrote:
>> 
>>> For me the software update mechanism is extremely important since it is
>>> not just a way to replace the entire firmware but also to provision
>>> certain protocol parameters.
>> 
>> Provisioning protocol parameters is one CoAP PUT to the right resource.  Cf. OMA LWM2M.
>> (They also do define a firmware update mechanism, but that seems to presume the device has space for a complete firmware image.)
> 
> That is exactly the question I raised when it comes to network management.
> 
> I don't understand what network management protocol add beyond what is
> already there with CoAP.

Assuming we continue to use the client-server model of network management, to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the client learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling method).

3) What is the security model.

There has been a strong argument that we should not start from scratch with (2) (and probably not entirely with (1) either), even if we are not using the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03
http://www.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll have to make sure the lessons learned from management security go into ACE.)

> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in certain environments.

>> If you want to do this the SEP2.0 way, you need EAP/PANA.
>> (SEP2.0 is targeting class-2+, not class-1.)
> 
> With devices that are in direct connection with each other you could
> argue that there is no need for DTLS and alike since you will have to
> deal with the pairing procedure at the lower layer. Many devices fall
> into that category.

(Defining single-hop security only is not very useful for the Internet of Things.)

> If that's not the case I believe you cannot assume that no network
> access authentication will be needed.

Indeed, most wireless networks will need network access control.  
Maybe there are ways to authorize (!) access to a network that are more appropriate for the Internet of Things.
But this is outside the scope of COMAN.

Grüße, Carsten