Re: [coman] Device Classes?

[Thomas Watteyne <[e-mail]>]

Andy,
+1.
I'm meant "proposing an additional protocol *not using CoAP* will be a very
hard sell". I personally believe mapping RESTCONF onto CoAP is a good
approach, sorry if that wasn't clear.
Thomas


On Sat, Apr 5, 2014 at 10:08 AM, Andy Bierman <[e-mail]> wrote:

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