2012/9/26 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
Here is an excerpt from the smilint manual page:
All generated error and warning messages have an associated severity level. The actual severity levels are: 0 Internal error, no recovery possible. Examples are memory allocation failures. Errors of this level usually cause the application to abort. 1 Major SMI/SPPI error, recovery somehow possible but may lead to severe problems. Examples are lexically unexpected characters or unknown keywords. Errors of this kind usually lead to follow-on errors. 2 SMI/SPPI error which is probably tolerated by some implementations. Examples are MIB/PIB modules which mix constructs from different SMI/SPPI versions. 3 SMI/SPPI error which is likely tolerated by many implementations. Examples are misplaced SMIv2 MODULE-IDENTITY invocations or SMIv2 textual conventions derived from other textual conventions. 4 Something which is not strictly an error but which is recommended to be changed. Warnings of this level are usually considered during MIB reviews. 5 Something that is basically correct but might be problematic in certain environments or usage scenarios. Examples are warnings that identifiers only differ in case or that type definitions are not used within the defining module. 6 Messages of this level are auxiliary notices. Examples are messages that point to a previous definition in case of a redefinition. Higher levels are currently not used and lead to the same effects as level 6 does. Note that errors up to level 3 are errors violating the specifications and must be fixed by the responsible author. The warnings generated with level 4 should be considered during normal MIB/PIB reviews.
Yes, I understand that those errors is not critical, but have an idea to make how much correctly. For example, in DISMAN-PING-MIB which has similar structure I have not observed those errors. May be is any secret here ? Please show any links how to check normal MIB/PIB reviews
This means only
[2] {parent-scalar} scalar's parent node must be simple node
really needs to be fixed. 1) and 2) relate to conformance definitions, which is important for standardized MIB modules but less so for proprietary MIB modules. 5) is a deviation from common naming conventions, does not really hurt but I personally would probably fix it an rename MetersTableEntry to MetersEntry (but then it must start with a lowercase letter - perhaps you removed some prefix before sending this to the list?).
/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/
Oh sorry, you are right in original I have following error message:
5warning: row identifier `aidMetersTableEntry' should have the same prefix as table identifier `aidMyMib-MetersTable' where aidMyMib is defined in follow record aidMyMib OBJECT IDENTIFIER ::= { MyMib 3 }
and all table is defined is follow way
-- Table of Meter's Characteristics
aidMyMib-MetersTable OBJECT-TYPE SYNTAX SEQUENCE OF AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table with management data " ::= { aidMyMib 11 }
aidMetersTableEntry OBJECT-TYPE SYNTAX AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Record describing the attributes of one meter. It is indexed by aidMeterIndex." INDEX { aidMeterIndex } ::= { aidMyMib-MetersTable 1 }
AidMetersTableEntry ::= SEQUENCE { aidMeterIndex MeterIndex, aidMeterST SystemTitle, aidMeterInfo OCTET STRING, aidMeterStatus OCTET STRING, aidMeterAlarms OCTET STRING, aidMeterLastResponse DateTime, aidMeterCommRate OCTET STRING }
aidMeterIndex OBJECT-TYPE SYNTAX MeterIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { aidMetersTableEntry 1 }
Unfortunately your advice has not helped to fix this issue.
Any suggestion ?
WBR, Evgheni