[core] Reponse to comments on CoMI

[Bert Greevenbosch <[e-mail]>]

Hi Juergen,

Thanks a lot for your comments. They are very helpful.

Peter and I have discussed them, and please find our response inline.

Best regards,
Bert


On Thu, Oct 17, 2013 at 11:53:28AM +0200, peter van der Stok wrote:
> >
> > Bert Greevenbosch and I have submitted a new draft on access to MIBs
> > via a CoAP interface.
> > We discuss a number of payload formats to investigate the
> > consequences of the choice.
> > A later version should concentrate on 1 (at most 2) formats.
> >
> 
> A couple of quick comments:
> 
> - Take a look at RFC 4088. In particular, you need to deal with
>   contexts to comply to the SNMP framework and you need to deal with
>   descriptors not necessarily being unique.

That is why we can specify the OID in the link format, and allow direct specification in JSON and CBOR of OID instead of descriptors too. The link format fixes the association between descriptor and OID.

Also we return (possibly multiple) information when multiple descriptors correspond with the specified descriptor.

> - The JSON type mapping is a bit too simplistic (e.g. what you render
>   as a string and what you ship as base64 encoded value in case of
>   JSON should likely depend on the type definition and not be
>   hardwired).

I think we could use information from the SMI type definition, similar as in regular SNMP. However in CoMI we have not mandated availability of the SMI definition to the managing entity.

Originally, we had a "tuple" JSON definition in our draft, which allowed specifying SMI type as well, however, for simplicity, we removed it. Consequently, it is hard to distinguish objects from the type e.g. between a counter, TimeTicks and an integer without secondary information from e.g. the SMI definition or hint in the name of the variable.

Indeed omitting the Base64 encoding may make sense in some cases, e.g. when the OCTET-STRING contains human-readable text.

But what counts is that the value is correctly transmitted, the type puts restrictions on the variable values, but these values are already guaranteed at the end points where the MIB and its type is known.

> - It might make sense to look what you get by taking a MIB module and
>   applying RFC 6643 to it. This gives you an XML serialization fully
>   defined today. And when you apply the JSON serialization of YANG,
>   currently defined in <draft-lhotka-netmod-yang-json-02>, you also
>   get a JSON serialization. The 6LoWPAN and RPL MIB modules have
>   examples of such serializations included I think.

We have thought about this aspect, but naively it seems complex to do this tandem coding
   
MIB -  YANG/XML -  JSON.

On the other hand, the examples in

   http://tools.ietf.org/id/draft-schoenw-6lowpan-mib-03.txt
   http://tools.ietf.org/id/draft-sehgal-roll-rpl-mib-06.txt

look quite nice, and are not that distant from our own solution. We will put some more time in investigating this.

> - Since counters are having discontinuity indicatores (defaulting to
>   sysUpTime), you need to provide primitives that allow you to
>   retrieve data from different branches of the OID number space.

We do have some problems understanding this remark.

Do you mean:
1)	going through oid space as specified for bulk transport and as suggested in RFC 4088 with the suffixes to the oid specification?
2)	specifying multiple MIB variables as specified with snmp (oid, value) pair, which permits the inclusion of sysUpTime in every request. The latter we support in section 3.2.2
3)	or something else?.

> - The SNMP framework has security and access control built into it.
>   It will be necessary at some point in time to explain how CoAP
>   access to MIB data relates to this - or if this is at least
>   conceptually a complete independent side channel to access the data
>   without access control at all. If its not a side channel, you need
>   to discuss how a securityName etc is provided for SNMP's access
>   control model to function.

This depends on CoRE authentication and authorisation. I think it is a bit too early to resolve now, but it needs to be resolved some day (as part of CoMI v1) for sure.

> Well, the security part is likely not yet that important. ;-)
> 
> I do not want to sound in any way negative. I appreciate that someone
> is working on this. I am actually trying to provide help. ;-)
> 
> /js