Subject: Re: [netmod] mib to yang conversion: imports

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Nov 2011 15:27:06 +0100

David,

I agree that your writeup how imports should be translated is much
better than what we had so far. As far as I can tell from reading the
text, the algorithm seems to produce the right behaviour. I have
merged your proposed text into the draft and I plan to update my
libsmi implementation accordingly, perhaps I manage during my trip to
Taipei.

/js

On Mon, Oct 10, 2011 at 05:23:42PM -0400, David Reid wrote:
> 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
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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