Subject: Re: [netmod] mib to yang conversion: type mapping table

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Nov 2011 17:04:24 +0100

On Thu, Oct 13, 2011 at 05:19:10PM -0400, David Reid wrote:
> I have a few questions about Table 1 which defines the maping of SMIv2
> types to YANG types.
> 
> 1. OBJECT IDENTIFIER maps to yang:object-identifier. Should it be
>    yang:object-identifier-128?

Makes sense (unfortunately ;-).
 
> 2. Table 1 maps all the built-in SMIv2 types to yang types or typedefs, which
>    is clearly necessary. It also maps 3 common textual conventions. I was
>    wondering why these 3 where chosen. I guess I would have expected either
>    that more TCs would be mapped (like ZeroBasedCounter32 for example) or none
>    of the TCs would be mapped. I'm not suggesting any changes, just trying
>    to understand the reasoning behind the way it is done.

I probably simply overlooked the ZeroBasedCounter* types. They are
listed as having an equivalent type in the YANG world in Table 1 of
RFC 6021.

> 3. This is related to #2 above. Would it make sense to map TruthValue to
>    boolean since the TruthValue labels (true/false) match the netconf 
>    encoding of booleans.

This might makes sense. The translation of the TruthValue TC results
in an enumeration defining the two enum values 'true' and 'false' and
hence the on the wire result in XML instance documents really is the
same. By using boolean, we would loose the assigned numeric values of
the enums, so a reader of the translated MIB module would have to know
that true is represented as 1 and false as 2 in the SNMP world (but
then for NETCONF payload and YANG/NETCONF aware applications, this
does not matter at all). I think I can go either direction on this.

> 4. I'm not entirely comfortable using DISPLAY-HINT to determine the type. If
>    we didn't use DISPLAY-HINT, we could consider creating mapping rules for
>    some of the well known string-type TCs like DisplayString, Utf8String,
>    SnmpAdminString, etc. Although I don't really like having a lot of
>    special case mapping rules, so I'm not sure this is a good idea.

Yes, trying to enumerate TCs that are to be treated as strings instead
of binary data is not going to work well here. The difficulty here is
that there is no way to extend the list of well known TCs without
causing different results when modules are translated at different
points in time, something we should avoid.

>    Side note: CHARACTER-MIB (rfc1658) uses DisplayString without importing it.
>    I've seen other MIBs do that with DisplayString. I added a hack to my tool
>    to handle that case. I don't think the document needs to account for broken
>    MIBs, but I thought I'd point this one out since it is in a standard MIB.

But at the end, these are broken SMIv2 modules. If you need to
translate them, simply fix the module before running the translator.
The IETF MIB modules that have such problems and are shipped with
smidump have been fixed manually.

/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, 9 Nov 2011 16:51:57 -0500 (EST)

On Wed, 9 Nov 2011, Juergen Schoenwaelder wrote:

> > 2. Table 1 maps all the built-in SMIv2 types to yang types or
>      typedefs, which is clearly necessary. It also maps 3 common
>      textual conventions. I was wondering why these 3 where chosen. I
>      guess I would have expected either that more TCs would be mapped
>      (like ZeroBasedCounter32 for example) or none of the TCs would
>      be mapped. I'm not suggesting any changes, just trying to
>      understand the reasoning behind the way it is done.
>
> > 3. This is related to #2 above. Would it make sense to map
>      TruthValue to boolean since the TruthValue labels (true/false)
>      match the netconf encoding of booleans.
>

The TruthValue TC and YANG boolean represent the same information,
even if the enumerated values are different.  The document should
map TruthValue to boolean.  A software entity that handles both
SNMP and NETCONF data should be prepared to transform between the
SNMP-centric [1,2] and NETCONF-centric [0,1] enumerations.  I believe
this same line of reasoning should prevail even when the semantic
equivalency is not as clear-cut.

When draft-ietf-netmod-yang-types-01.txt was current, I built this
list of SMIv2 types and textual conventions and their semantic
equivalents for YANG.  I found out later that yang:date-and-time
is a near superset of DateAndTime, since it can represent Zulu time
in addition to UTC time, so only partially equivalent.

  SMIv2                      YANG                       Reference
  -----                      ----                       ---------
  Integer32                  int32                      RFC 2578
  INTEGER                    int32                      RFC 1155
  Unsigned32                 uint32                     RFC 2578
  UInteger32                 uint32                     RFC 1442
  DisplayString              string                     RFC 1213
  OctetString                binary                     RFC 1155
  Null                       empty                      RFC 1155
  Opaque                     binary                     RFC 2578
  TruthValue                 boolean                    RFC 2579
  AutonomousType             identityref                RFC 2579
  Bits                       bits                       RFC 2579
  Counter32                  yang:counter32             RFC 2578
  Counter                    yang:counter32             RFC 1155
  ZeroBasedCounter32         yang:zero-based-counter32  RFC 4502
  Counter64                  yang:counter64             RFC 2578
  ZeroBasedCounter64         yang:zero-based-counter64  RFC 2856
  Gauge32                    yang:gauge32               RFC 2578
  Gauge                      yang:gauge32               RFC 1155
  CounterBasedGauge64        yang:gauge64               RFC 2856
  ObjectID                   yang:object-identifier-128 RFC 2578
  DateAndTime                yang:date-and-time         RFC 2579
  TimeTicks                  yang:timeticks             RFC 2578
  TimeStamp                  yang:timestamp             RFC 2579
  PhysAddress                yang:phys-address          RFC 2579
  InetVersion                inet:ip-version            RFC 4001
  Dscp                       inet:dscp                  RFC 3289
  IPv6FlowLabel              inet:flow-label            RFC 3595
  InetPortNumber             inet:port-number           RFC 4001
  InetAutonomousSystemNumber inet:as-number             RFC 4001
  InetAddressIPv4            inet:ipv4-address          RFC 4001
  InetAddressIPv4z           inet:ipv4-address          RFC 4001
  IpAddress                  inet:ipv4-address          RFC 2578
  InetAddressIPv6            inet:ipv6-address          RFC 4001
  InetAddressIPv6z           inet:ipv6-address          RFC 4001
  InetAddressDNS             inet:domain-name           RFC 4001
  InetAddress                inet:host                  RFC 4001
  Uri                        inet:uri                   RFC 5017
  MacAddress                 ieee:mac-address           RFC 2579
  BridgeId                   ieee:bridgeid              RFC 4188
  VlanId                     ieee:vlanid                RFC 4363

I tried to be thorough, but I too have probably overlooked some TCs
from standard MIBs.

If the document is going to map any of the standards-track TCs to YANG,
I believe it should map all of them (that have a YANG equivalent).  The
document should identify the transformations that are necessary to covert
data between formats.

> >    Side note: CHARACTER-MIB (rfc1658) uses DisplayString without
> >    importing it.  I've seen other MIBs do that with DisplayString.
> >    I added a hack to my tool to handle that case. I don't think the
> >    document needs to account for broken MIBs, but I thought I'd
> >    point this one out since it is in a standard MIB.
>

I observed that DisplayString existed before SMIv2.  It was defined
in RFC 1158 and later in RFC 1213.  RFC 1213 was a Full Standard at the
time RFC 1658 was published.

RFC 1443 (predecessor to the current SNMPv2-TC, RFC 2579) was published
as Proprosed Standard in April, 1993, a little more than a year before
RFC 1658 was published in July, 1994.  That suggests that RFC 1658 should
have been changed to import from RFC 1443 before it was published.
However, the author may have reasoned that the Full Standard definition
of DisplayString in RFC 1213 trumped the then-Proposed Standard TC.

-dss

-------------------------------------------------------------
 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: Fri, 11 Nov 2011 22:27:58 +0100

> equivalency is not as clear-cut.

YANG does not assign any numeric representation for true and false
as far as I can tell.
 
> of DisplayString in RFC 1213 trumped the then-Proposed Standard TC.

The issue is that RFC 1658 uses DisplayString without importing it and
hence RFC 1658 is broken. It does not matter whether other documents
had a DisplayString around that time or not.

/js