Re: [coman] Device Classes?

[Andy Bierman <[e-mail]>]

On Fri, Apr 4, 2014 at 9:01 PM, Thomas Watteyne
<[e-mail]>wrote:

> Andy, all,
>
> If CoAP is already in nodes for the applications running on, you have a
> monitoring/management solution almost for free. Want to monitoring the
> state of some attribute of your protocol? Use CoAP observe. Want to change
> a parameter of your protocol? CoAP PUT. On top of that, the work from
> CORE/DICE/DTLS/ACE, will ensure security, including authentication and
> authorization of management entities.
>
> For nodes where CoAP is present for the application, proposing an
> additional protocol will be a very hard sell.
>
>
It isn't another protocol.
It is a mapping of the RESTCONF data model framework onto CoAP.

A RESTCONF mapping would really just describe what the server was
expected to do wrt/ the content layer.


Andy



> Of course, as pointed out by Carsten, we need to agree on the resources.
> What is the URI, what methods are supported, what's the payload format,
> etc. YANG is a data modeling language which enables exactly that. RESTCONF
> has a RESTful approach to monitoring/management which is aligned with CoAP.
> What we would need is a constrained version of RESTCONF. This could be (and
> should be) very simple.
>
> At 6TiSCH, we have started this work, with YANG based data model [1] and a
> CoAP-based protocol built around that [2], any URI starting with "/6t" is
> to monitoring and manage the 6top sublayer. I believe there would be a huge
> benefit to having a more general solution, to which we all agree, i.e. a
> CoAPified version of RESTCONF. COMAN looks like the right place to do this.
>
> Thomas
>
> [1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-00
> [2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01
>
>
> On Fri, Apr 4, 2014 at 5:16 PM, Andy Bierman <[e-mail]> wrote:
>
>>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> coman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/coman
>>
>>
>