Re: [core] COMI

[Alexander Pelov <[e-mail]>]

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


Le 15/09/2015 12:00, Hannes Tschofenig a écrit :
> Hi Juergen,
>
> thanks for the feedback.
>
>
> On 09/15/2015 11:37 AM, Juergen Schoenwaelder wrote:
>> On Tue, Sep 15, 2015 at 10:15:01AM +0200, Hannes Tschofenig wrote:
>>>> Why can't they use RESTCONF then?
>>>> The CORE WG should focus on CoAP.
>>>> The more options, the more complex it gets, not easier.
>>> 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.
>>>
>> 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. ;-)
>>
> 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.
>
>>>> Not yet.
>>>> Since YANG is modular the vendor has lots of freedom to deploy
>>>> 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.
>> 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.
> That's the reason why I look into it.
>
> Ciao
> Hannes
>> /js
>>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core