Re: [coman] Device Classes?

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.

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 <andy@yumaworks.com> wrote:

>
>
>
> On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>>
>> On 04 Apr 2014, at 13:45, Hannes Tschofenig <hannes.tschofenig@gmx.net>
>> wrote:
>>
>> > Hi Carsten.
>> >
>> >
>> > On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> >> On 04 Apr 2014, at 13:32, Hannes Tschofenig <hannes.tschofenig@gmx.net>
>> 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
> coman@ietf.org
> https://www.ietf.org/mailman/listinfo/coman
>
>