Subject: [core] COMI

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Sep 2015 16:54:19 +0200

Hi COMI authors,

I started to read through the COMI specification and I have some basic
questions. More questions will follow.

What is the reason for tying COMI to CoAP/UDP? What would prevent me
from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over
MQTT?

While CoAP is a great protocol, not everyone is going to use CoAP and so
there has to be an easy way to use this specification on top of other
protocols as well.

> HTTP uses TCP which is not recommended for CoAP.

I am not sure that's entirely correct. RFC 7252 specified the usage of
CoAP over UDP but there has been work ongoing to run CoAP over TCP/TLS,
as you know. CoAP can also be used over other transports, such as SMS.

> A large amount of Management Information Base (MIB) [RFC3418]
   specifications already exists for monitoring purposes.

I would add a reference to the registry that lists those MIBs.

Have you guys looked at what data really makes sense in an IoT context?

> This data can be accessed in RESTCONF if the server converts the SMIv2
modules to YANG, using the mapping rules defined in [RFC6643].

Is it correct to say that this conversion happens once during the
development time rather than runtime? (Needless to say that this makes a
huge difference in terms of code complexity and runtime performance.)

> Stateless communication is encouraged to
   keep communications simple and the amount of state information small
   in line with the design objectives of 6lowpan [RFC4944] [RFC6775],
   RPL [RFC6650], and CoAP [RFC7252].

This is a strange sentence. With stateless communication you have no
state. Typically, you will have to create somewhere else in the protocol
stack and only a certain layer is stateless.

Additionally, I would remove the references to [RFC4944] [RFC6775], RPL
[RFC6650] since these specs are irrelevant for this work. It just creats
a longer reference list.

>    The end goal of CoMI is to provide information exchange over the CoAP
   transport protocol in a uniform manner as a first step to the full
   management functionality as specified in
   [I-D.ersue-constrained-mgmt].

I personally don't believe that the main value of this specification is
the ability to use CoAP. Instead, I believe the value is in re-using
existing management objects. The code for the different transport
protocols isn't that large after all...

> CoMI supports MIB modules which have been translated
   from SMIv2 to YANG, using [RFC6643]. This mapping is read-only so
   writable SMIv2 objects need to be converted to YANG using an
   implementation-specific mapping.

I am not sure I understand the implications of this design decision. It
sounds like a negative thing to me.

>    CoMI uses a simple URI to access the management object resources.
   Complexity introduced by instance selection, or multiple object
   specification is expressed with uri-query attributes.

This sentence is strange. You are saying that the URI is simple but then
in the next sentence you talk about complexity due to the query
attributes. Is the query attribute the same as a query parameter? When I
searched through the document for 'uri-query' then I found pretty much
nothing.

> Terminology

When I look at the terminology section and all the specifications a
reader needs to understand in order to be able to read this
specification then I don't feel very comfortable. Isn't there a way to
make it less complex. After all, you do very little.

>    o  The signature of the CoAP request in the server is standardized.

What does signature mean in this context? Are you talking about security
stuff here?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Sep 2015 16:57:57 +0200

> from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over

COMI works over REST, so it will work over all these except MQTT.

It is probably still a good idea to have a default expectation which
transport will be used with COMI, so calling out for CoAP over (DTLS
over) UDP is probably still a good plan.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Sep 2015 09:01:47 -0700

> there has to be an easy way to use this specification on top of other

Why can't they use RESTCONF then?
The CORE WG should focus on CoAP.
The more options, the more complex it gets, not easier.

> Have you guys looked at what data really makes sense in an IoT context?

Not yet.
Since YANG is modular the vendor has lots of freedom to deploy
functionality where it is needed.

IMO the most significant aspect of CoMI is that is uses modular data models
and the management content is decoupled from the protocol.
Really small devices with 2 or 3 leafs to export should not bother with
CoMI.
There is a cost to decoupling the content layer, and it is not worth the
cost if that layer is utterly trivial.

There are common modules like ietf-interfaces that should
be applicable even on IoT devices.

> huge difference in terms of code complexity and runtime performance.)
yes -- conversion is with RFC 6643.
This produces instance identifiers which are converted to YANG Hashes in
CoMI

> stack and only a certain layer is stateless.

NETCONF is very stateful.
It can take up to 10 roundtrips to complete a single editing transaction.
By contrast, RESTCONF or CoMI require 1 roundtrip instead.
We will clarify that the management operations are stateless.

> protocols isn't that large after all...

For those of us moving to YANG-based automation, that is the main
reason for using CoMI.  IMO why not just use SNMP if you
just want to poll some existing counters?  There is really no business case
at all to rip out SNMP and redo all the instrumentation in CoAP/YANG.
I don't buy the premise that all this R&D money will be better spent
redoing all the
instrumentation in CoAP, rather than just providing enough memory to run
both
SNMP and CoAP

> sounds like a negative thing to me.

The read-only restriction is to avoid putting RowStatus into YANG.
The edit model for SNMP is not compatible with anything else.
Supporting SMIv2 configuration objects is not a priority,

> What does signature mean in this context? Are you talking about security

Andy

>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 14 Sep 2015 09:52:32 +0200

Hi Hannes,

thanks for your interest. I will add to the answers by Andy.

Andy Bierman schreef op 2015-09-11 18:01:
> On Fri, Sep 11, 2015 at 7:54 AM, Hannes Tschofenig
> <[email-masked]> wrote:
> 
>> Hi COMI authors,
>> 
<pvds>
I agree with the answer of Andy.
As pointed out by Carsten, CoMI can be used on top of other protocols.
However, the design exercise was done for small low resource devices 
connected by LLN, where it is useful to reuse YANG and its accompanying 
experience and modules,
including the MIBs.
So, CoAP (DTLS) UDP is the favoured stack.
</pvds>
>> as you know. CoAP can also be used over other transports, such as
<pvds>
You're right, this might be better phrased.
Although the operative word is "recommend for" and not "used by".
</pvds>
>> I would add a reference to the registry that lists those MIBs.
<pvds>
Good suggestion
</pvds>
>> Have you guys looked at what data really makes sense in an IoT
<pvds>
This is a VERY open question. IoT represents a huge application domain 
and depends on the view of your interviewee.
Answer is NO, we did not.
Any suggestions?
</pvds>
> Really small devices with 2 or 3 leafs to export should not bother
> with CoMI.
<pvds>
May be not. Not sure about this.
</pvds>
>> huge difference in terms of code complexity and runtime
<pvds>
You mean: state this in the draft
</pvds>
> This produces instance identifiers which are converted to YANG Hashes
> in CoMI
> 
<pvds>
Well, it certainly paints a context
a single reference which paints the same context would be welcome 
(suggestion?)
</pvds>
> instrumentation in CoAP, rather than just providing enough memory to
> run both
> SNMP and CoAP
<pvds>
The point was also that snmpv3 including security is huge.
Using Coap and its accompanying security stack (that may evolve) reduces 
stack size and learning effort for coap using devices.
And as Andy points out we seem most added value for those that move to 
YANG.
</pvds>
>> searched through the document for 'uri-query' then I found pretty

<pvds>
Ok, will rephrase.
We can remove the whole sentence. It is a consequence of the grammar 
evolution CoMI lived through.
</pvds>
>> make it less complex. After all, you do very little.
<pvds>
but we reuse quite a lot.
I share your concern, and have been thinking about simplifications, with 
the result of often messing up by misrepresenting YANG concepts (but 
that may be me)
</pvds>
>> What does signature mean in this context? Are you talking about
<pvds>
signature in the sense of function name, type, and parameter name, type.
Ian Sommerville, software engineering.
</pvds>
> Andy

greetings,
Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Sep 2015 10:15:01 +0200

Hi Andy,

thanks for your quick response!

On 09/11/2015 06:01 PM, Andy Bierman wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi COMI authors,
>

It is of course a question about what the folks in the CORE working
group believe they will be using in their deployments. We hear a lot of
folks asking for protocols other than CoAP over UDP. It is hard to say
whether they are only interested to hear whether that's is possible or
whether they are really interested to deploy HTP2 or QUIC. Hard to say
at this point in time but I believe the COMI specification by its nature
does not need to be strongly tied to CoAP (which Carsten seems to
confirm in his email response).

Regarding RESTCONF: Based on your response below it appears that
RESTCONF by itself is very wasteful and not very useful for an IoT
deployment.

> functionality where it is needed.

I have to admit I don't fully understand YANG. I have read through OMA
LWM2M and compare it against that spec. OMA LWM2M is much easier to
understand since it has a simple object structure.

> This produces instance identifiers which are converted to YANG Hashes in

It might be useful to make this clear in the document.

> We will clarify that the management operations are stateless.

Thanks for clarifying this aspect in a future version of the draft.

> at all to rip out SNMP and redo all the instrumentation in CoAP/YANG.

I personally haven't heard anyone asking us to implement SNMP for IoT
device management. That's probably because other solutions have been
made available already.

> instrumentation in CoAP, rather than just providing enough memory to run

When you look at the classes of IoT devices described in RFC 7228 then
you may notice that this approach does not work too well. Of course, you
may question the class descriptions.

> Supporting SMIv2 configuration objects is not a priority,

I guess I will have to do a bit more reading to understand this response.

Ciao
Hannes

>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Sep 2015 11:37:51 +0200

> RESTCONF by itself is very wasteful and not very useful for an IoT

Most RESTCONF implementations likely use JSON encoding of the payload
but this is actually not hardwired and it should be possible to use
something more space efficient if needed (the IETF started to like
CBOR, I am not sure whether the industry will pick it up or whether
other binary encodings will be used). The only part where RESTCONF is
kind of verbose is the way objects are named, using relatively long
URLs. Finding ways to reduce the URL verbosity has been driving much
of the CoMI discussions as far as I can tell.

Whether CoAP is going to rule the IoT world or HTTP/2 or ... is
difficult to answer but I bet that the CORE working group has a
certain perhaps biased opinion here. ;-)

> understand since it has a simple object structure.

With YANG getting more widely adapted, we might see the same discussion
that we see on the protocol side - use something more mainstream that is
not optimal for IoT devices but perhaps good enough or use something
tailored for IoT devices but not used widely outside this specific context.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Sep 2015 12:00:39 +0200

Hi Juergen,

thanks for the feedback.

> certain perhaps biased opinion here. ;-)

I am new to this network management and so I have to trust what others
tell me. From your description it almost sounds like RESTCONF is not a
big problem either.

Did you or someone else did a performance analysis?

It is hard to see whether some of these design will positively impact
deployment but my feeling is that we should offer flexibility where it
does not cost much. In the area of the underlying protocol it looks like
we have a low-hanging fruit.

> tailored for IoT devices but not used widely outside this specific context.
That's the reason why I look into it.

Ciao
Hannes

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 17 Sep 2015 12:10:21 +0200

Dear Hannes,

I like the management interface being defined on a specific protocol - 
namely CoAP. Otherwise, we only add layers of interpretation and 
syntactic translations (as done in OneM2M), which could be:
1) straightforward (and thus useless - instead, write in CoAP directly)
2) not straightforward (which adds a burden to implementers. Instead - 
use CoAP as the base language, and add mapping to MQTT (for example).

I tend to agree with you that we should consider decoupling CoAP from 
the underlaying transport protocol (which I think comes for free). The 
rationale would be that we could have CoAP running on top of L2, TCP or 
other, e.g. in a 6TiSCH or LR-WAN / LPWA network:
https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00
https://tools.ietf.org/html/draft-pelov-core-cosol-00

So, I'd be in favor of keeping CoAP as the common language for 
expressing CoMI, but maybe keep explicit UDP bindings off the draft, and 
maybe provide them as examples (unless there are some specific needs). I 
have no strong opinion on this, however.

Best,
Alexander

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Sep 2015 16:16:22 +0200

> Did you or someone else did a performance analysis?

Well, we have implemented SNMP including SNMPv3 security on small
devices and bits and pieces of NETCONF and so we understand the issues
with that as a baseline. We once looked at CoAP implementations and we
were surprised that there was room for optimization. But the real
challenge here is to agree on the target device and the target link
layer and the security services provided.

On really small devices, in terms of code size, as long as you do
security in software, our experience is that the security code eats
the largest portion of memory. Data encoding surely matters as well,
SNMP's BER encoding is reasonably compact and fast to process,
NETCONF's XML encoding was a pain on our devices (since we had to go
through flash memory to handle larger message size). The question
question is also whether you have a link layer like 802.15.4 where you
like to avoid sending larger IPv6 packets or you happen to enjoy a
link layer that is not as picky about frame sizes. CoMI uses CBOR
(which is close to BER) so this should be good. The compression of
paths is important if we have to consider links such as 802.15.4 and
we need to be able do meaningful work with tiny frames. If that is
less an issue, RESTCONF with CBOR might be a reasonable choice as
well. But we have not implemented these.

So bottom line: For a real comparison, we need to agree on the
hardware capabilities, whether crypto has to be done in software,
whether it is important to optimize for constrained link layers like
good old 802.15.4 with 127 octet frames.

Some people may argue that devices that need (explicit) management
likely can afford links that are 'better' than 802.15.4 and
microcontroller that are 'better' than C0-C2 while others argue that
spending the engineering time to make something work well with very
constrained links and devices will eventually pay off due to the large
quantities in which IoT devices will appear. While I do have an
opinion, I surely do not have an answer. ;-)

/js