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

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Jun 2011 14:42:29 +0200

Hi,

I like to close this open issue. Please comment on the options
provided below.

* smi2yang-04: string vs. binary [open]

  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.

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

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

-- 
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: David Spakes <[email-masked]>
Date: Mon, 6 Jun 2011 10:40:37 -0400 (EDT)

Juergen,

I think solution 04-04 is best, but in my opinion the cost would be
less if every OCTET STRING object was treated the same way all the
time.  In other words, the choice should have a sysDescr-string leaf
even if there is no DISPLAY-HINT.

-dss

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

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2011 16:58:31 +0200

> even if there is no DISPLAY-HINT.

I assume sysDescr is not a good example since it has a DISPLAY-HINT.
If we take something that does not have a DISPLAY-HINT, then it is
rather unclear to me what the string representation is unless we
define one for strings that do not have a DISPLAY-HINT. But if we do
that and later a MIB module gets revised and a DISPLAY-HINT is added,
we are back to where we started since what is being added might
conflict with what was used before. So I am not convinced having a
-string version always is going to work well.

There are costs associated with solution 04-04, not on the server side
but on the client side. Perhaps some guidance should be given that
servers really should generate the stringified format if there is one
so as to encourage the usage of stringified representations.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 10 Jun 2011 09:20:49 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> conflict with what was used before.

This will be a problem in other cases as well, since SMIv2 allows the
DISPLAY-HINT to be updated in new revisions.

Besides, the DISPLAY-HINT is on the TEXTUAL-CONVENTION, and the choice
would be for the leafs that use the TEXTUAL-CONVENTION.  This means
that if the TEXTUAL-CONVENTION is updated, all modules importing the
TEXTUAL-CONVENTION would have to be re-translated.  So I don't think
this solution would work.

So I think solution #04-01 is best.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Jun 2011 17:35:41 +0200

> this solution would work.

Yes, we would essentially have to create a choice for at least every
OCTET STRING object. (I don't think the current translator every looks
at DISPLAY-HINTs for INTEGER types.)
 
> So I think solution #04-01 is best.

It is the one currenty implemented. ;-) Perhaps we could explain that
implementations may want to provie a mechanism to ignore DISPLAY-HINTs
for certain types/objects so that in cases where a DISPLAY-HINT is
added one can tweak the translation run via those mechanisms (e.g.
command line options). This is how one would likely address this
corner case in running code.

/js