Subject: [netmod] mib to yang conversion: imports

From: David Reid <[email-masked]>
Date: Mon, 10 Oct 2011 17:23:42 -0400

I modified our MIB to yang conversion tool to conform to
draft-ietf-netmod-smi-yang-01. Overall, I think the document
is in good shape, but I did run into a few issues for which I
will try to propose solutions.

To test, I converted all the current standard MIBs to yang and 
then ran the converted modules through pyang. I also compared my
output on a couple of the modules to the smidump output. pyang 
generated a number of warnings and a few errors. There are also
some differences between what I produce and what smidump produces.
I modified my tool to produce yang modules that compile with no 
warnings or errors under pyang and I'm going to try to propose some 
text that will address these issues. I have some questions
about some other issues and I need to study some of the issues more before
I can make an intelligent comment.

I'll address some issues with imports in this message and address other
issues in subsequent messages. I found 3 basic issues with imports:

1. Lots of modules produce the pyang warning "imported module FOO not used".
   That's not fatal, but I think we can re-write the imports section to 
   address this. Some examples include object identifier assignments and 
   objects referenced in conformance and compliance statements.

2. There were a couple of errors where we reference objects in 
   modules that were not imported. Here is an example: ADSL-LINE-EXT-MIB
   defines the notification adslAtucFailedFastRThreshTrap which includes the
   object adslAtucPerfCurr15MinFailedFastR. adslAtucPerfCurr15MinFailedFastR
   is defined in a table that augments adslAtucPerfDataEntry. 
   adslAtucPerfDataEntry is imported. adslAtucPerfDataEntry is indexed by
   ifIndex. ifIndex is not imported in the MIB module since it is not directly 
   referenced.  But in the yang notification, we have to include ifIndex, 
   therefore, ifIndex needs to be imported.

3. A few SMIv2 modules IMPORT from SMIv1 modules, but we don't define rules
   for converting SMIv1 modules. For example, RMON2-MIB is an SMIv2 module 
   which imports from TOKEN-RING-RMON-MIB which is an SMIv1 module. Lots of
   modules import RMON2-MIB to get ZeroBasedCounter32, so I think it is
   important that RMON2-MIB work (there's also the issue with the same object
   used multiple times in the index clause -- I'll address that in a subsequent
   message). I don't want to waste a lot of time on SMIv1, but if SMIv2 modules
   IMPORT from SMIv1 modules I think we need to address that. See my suggestion
   below.

Here is the text for my proposed solutions. 

In section 4, remove Table 3 and replace the text in the bullet 
points with the following:

    o Process each item in each SMIv2 IMPORT clause as follows:
       
       (1) If an import statement for this SMIv2 module has already been 
           generated, then ignore this item.

       (2) Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2-CONF, 
           then ignore this item. Note that these two modules can be 
           completely ignored since all definitions in these modules are 
           translated by translation rules.

       (3) Otherwise, if this item is a textual convention matching one 
           of the textual conventions in the SMIv2 types column of 
           Table 1 (MacAddress, PhysAddress, or TimeStamp) then ignore 
           this item. 

         [Note: We may want to add more TCs than just these 3. I'll address
          that in a separate e-mail]

       (4) Otherwise, if the item is used in a SYNTAX clause of an OBJECT-TYPE
           whose MAX-ACCESS is not accessible-for-notify, then generate an 
           import statement as described below.

       (5) Otherwise, if the item is used in an OBJECTS clause of a 
           NOTIFICATION-TYPE, then generate an import statement as described 
           below.

       (6) Otherwise, if the item is used in an INDEX or AUGMENTS clause, 
           then generate an import statement as described below.

       (7) Otherwise, ignore this item. Some examples of this case are
           OBJECT IDENTIFIER assignments and objects that are only referenced
           in MODULE-COMPLIANCE, OBJECT-GROUP, or NOTIFICATION-GROUP clauses.

    o Generate any additional imports statements as required by the type 
      translations according to the type mapping table (Table 1). This 
      requires the translator to consider all the types used in the 
      translation unit in order to produce the imports.

    o Generate an import statement for the yang module ietf-yang-smiv2 with 
      the prefix smiv2 if extensions from ietf-yang-smiv2 will be used in
      the translated yang module.

Add the following sentence somewhere, perhaps at the end of the first 
paragraph in section 1, to address the case where an SMIv2 module imports
from an SMIv1 module:

    SMIv1 modules may be converted to YANG by first following the rules in 
    RFC 3584 to convert the SMIv1 module to SMIv2, then following the rules 
    in this document to convert to YANG.

-David Reid