Re: [core] Reponse to comments on CoMI

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Oct 28, 2013 at 12:17:23AM +0000, Bert Greevenbosch wrote:
> 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.

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

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.

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

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

> > - 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?.

Section 3.2.2 _might_ cover this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>