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

From: David Spakes <[email-masked]>
Date: Thu, 17 Nov 2011 12:21:29 -0500 (EST)

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.

-dss

---------- 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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Nov 2011 11:32:34 +0100

>     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

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