Subject: Re: [netmod] smi2yang-04: string vs. binary

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 May 2011 10:42:55 +0200

On Sat, Apr 09, 2011 at 01:15:00PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Juergen Schoenwaelder <[email-masked]> wrote:
> > * smi2yang-04: string vs. binary
> > 
> >   It would be nice to have a reliable mechanism to determine whether
> >   an OCTET STRING can be represented as a human readable string or is
> >   a binary string. The current ID suggests to use the presence of a
> >   DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a
> >   DISPLAY-HINT when a MIB module is revised, which can lead to
> >   different translations of different versions of a MIB module.
> > 
> > ** Solution #04-01
> > 
> >    Declare this a non-problem since additions of DISPLAY-HINTs are
> >    rare.
> 
> I prefer this solution.  We should clearly specify what effect this
> legal SMIv2 change (and #02) have on YANG revisioning.
> 
> > ** Solution #04-02
> > 
> >    Translate strings into unions that allows both a human readable
> >    string representation and a binary representation. However, this
> >    requires to have some mechanism in place to decide whether a value
> >    is a human readable string or a binary string, which means we
> >    likely have to mess around with values.
> > 
> > ** Solution #04-03
> > 
> >    Always translate OCTET STRING types into the YANG binary types. We
> >    could list some well-known types as exceptions, like DisplayString,
> >    SnmpAdminString, DateAndTime but such a list will always be
> >    incomplete and hence some human readable data will be encoded into
> >    base64.

Any other opinions? If I do not see more discussion on the list, I
(as editor) will assume solution #04-01 has been adopted by the WG.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 21 May 2011 01:11:03 +0200

>    incomplete and hence some human readable data will be encoded into

** Solution #04-04

   Always translate OCTET STRINGS into a choice which contains a
   binary leaf. Add a second string leaf if there is a DISPLAY-HINT.
   This would also apply to objects using an OCTET STRING TC, that is
   in the extreme case (no special rules for well known string types),
   we get for sysDescr:

   choice sysDescr-leaf {
     leaf sysDescr-string {
       type string;
     }
     leaf sysDescr-binary {
       type binary;
     }
   }

   While this solution is robust wrt. module revisions that add a
   DISPLAY-HINT, the cost of having to support two formats are
   significant.

/js

---

From: David Reid <[email-masked]>
Date: Tue, 24 May 2011 17:05:05 -0400

>    DISPLAY-HINT, the cost of having to support two formats are

I like this solution. I need to think more about the implementation cost.
But at first look, I think it is a quite clever solution. I have one
suggestion: always include both string and binary in the choice whether it
has a DISPLAY-HINT or not and let the server decide which one to use. The
server knows best what the best encoding should be. And if someone did not 
want to incur the extra cost, they could use binary in every case.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 May 2011 02:37:05 +0200

> want to incur the extra cost, they could use binary in every case.

The costs of this solution are on the client side and not on the
server side. For every OCTET STRING MIB object, a client now needs to
be prepared to handle both a binary (=base64) encoded XML element and
a separate string encoded XML element. So yes, for a server, this is
kind of attractive. For a client, this is going to be more of a pain
(and I fear we will see lots of programs/scripts not handling this
correctly).

/js