Subject: [netmod] mib to yang conversion: display-hint

From: David Reid <[email-masked]>
Date: Tue, 07 Feb 2012 17:01:22 -0500

I'm working on implementing the DISPLAY-HINT part of the MIB to YANG 
conversion. I'm wondering what to do in cases where the value does not
match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has
a DISPLAY-HINT of 255t and the description says "implementations must be 
prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I 
don't know how to display many of those code points that I must be prepared 
to encounter. In our SNMP code we just dump it in hex if we don't know how to
render it. But that is not really correct in this case.

-David Reid

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Feb 2012 14:58:09 -0800

Hi -

> From: "David Reid" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, February 07, 2012 2:01 PM
> Subject: [netmod] mib to yang conversion: display-hint
>

There is no single "right" answer.  Never mind that the failure to specify a
normalization form means there are lots of situations where different
byte sequences will be displayed exactly the same.  There are lots of
code points which are not (yet) assigned, and situations will arise where
a code point has been assigned, but your system doesn't have a font
that can display an appropriate glyph.  Depending on your application
needs, you might find these suggestions useful:
http://unicode.org/faq/unsup_char.html

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2012 08:24:32 +0100

> render it. But that is not really correct in this case.

I think this is not a mib to yang conversion issue (as indicated in
the subject line) and hence there is no action for the smiv2 to yang
mapping document.

/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: Wed, 8 Feb 2012 11:15:17 -0500 (EST)

Juergen,

I think David Reid was asking a follow-up question about the issue
from November, "smi2yang-04: string vs. binary".  The group came to
consensus on solution #04-01: "The mapping of the OCTET STRING depends
on the context.  If an OCTET STRING type has an associated DISPLAY-HINT,
then the corresponding YANG base type is the string type.  Otherwise,
the binary type is used."

As I understand the issue, the question is: What is the proper XML
rendering of the YANG string if the value in the OCTET STRING object
having DISPLAY-HINT "255t" does not map to a graphic character in the
current UTF-8 set?

-dss

On Tue, 22 Nov 2011, Juergen Schoenwaelder wrote:

> Subject: Re: [netmod] smi2yang-04: string vs. binary
>
> On Thu, Nov 17, 2011 at 12:21:29PM -0500, David Spakes wrote:
> > If the group concensus is solution #04-01, I'd go along.  However, I
> > favor solution #04-02.  The first character of the value would indicate
> > to the NETCONF protocol receiver which element of the union applies.
> >
> >   * If the first character is a double-quote, a string value follows,
> >     and the leading double-quote is not part of the value.
> >
> >   * If the first character is not a double-quote, the value is binary,
> >     and the leading character is part of the encoded value.
>
> A native NETCONF implementation will not do this and it is out of
> scope for us to change NETCONF behaviour. I am closing this now in
> favour of solution #04-01.
>
> /js

On Thu, 17 Nov 2011, David Spakes wrote:

> If the group concensus is solution #04-01, I'd go along
...
>
> ---------- Forwarded message ----------
> Date: Thu, 17 Nov 2011 11:44:08 -0500
> From: David Reid <[email-masked]>
> To: [email-masked]
> Subject: [netmod] smi2yang-04: string vs. binary
>
> I've never been entirely comfortable with solution #04-01, but I can't
> come up with anything better. Of the options on the table, I think #04-01
> is the best.
>
> -David Reid
>
>
> > * 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. Suggest that implementations provide options to cast an
> >    OCTET STRING into binary to handle situations where a DISPLAY-HINT
> >    got added when a module was revised.
> >
> > ** 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.

-------------------------------------------------------------
 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: David Reid <[email-masked]>
Date: Wed, 08 Feb 2012 12:27:18 -0500

Yes David, that is my question, how do I render it.

Just to be clear: I don't want to reopen issue #04-01 and I certainly don't
want to make the normal case harder by changing things to handle this corner
case. I'm just trying to figure out how to implement it.

-David Reid

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Feb 2012 12:30:16 -0800

Hi -

> From: "David Spakes" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, February 08, 2012 8:15 AM
> Subject: Re: [netmod] mib to yang conversion: display-hint
...
> having DISPLAY-HINT "255t" does not map to a graphic character in the

There are additional complications.  See
http://www.w3.org/TR/2007/NOTE-unicode-xml-20070516/
for an introduction to some of the issues.  It's made worse with
data from SNMP-land because we didn't mandate a normalization
form.

I think the bottom line is that NCRs are your friends.

Randy

---

From: David Reid <[email-masked]>
Date: Wed, 08 Feb 2012 16:58:07 -0500

> I think the bottom line is that NCRs are your friends.

That seems like a reasonable solution.

-David Reid