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

From: David Reid <[email-masked]>
Date: Thu, 13 Oct 2011 17:19:10 -0400

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?

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.

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.

   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.

-David Reid