Subject: [core] Reponse to comments on CoMI

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 28 Oct 2013 00:17:23 +0000

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Oct 2013 17:51:02 +0100

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

I likely do not understand. An example might help me, in particular
when it comes to non default SNMP contexts.
 
> 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 i…

You need to have clear rules. Right now, you use string notation for
some OCTET STRINGS (e.g. udpEndpointLocalAddress) while the table says
Base64 encoded string.

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

There is no 'tandem coding' (or more precisely I do not know what this
phrase means).

> 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

Section 3.2.2 _might_ cover this.

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