Re: [coman] Device Classes?

[Andy Bierman <[e-mail]>]

On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann <[e-mail]> wrote:

>
> 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).
>
>
RESTCONF addresses (1) and (2).
It replaces HATEOAS with YANG in order to be extensible,
modular, and predictable. The target use-case is programmatic
control.  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IMO YANG would be a better long-term decision than SMIv2.
It may seem that features like custom operations are too
heavy-weight and over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as
small as possible.




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

Andy