Error Compiling MIB

MIB Explorer
1

[Pls pardon me in advance if this is the wrong forum.]

I am by no ways an expert in MIB-ASN.1 notation, MIB explorer gives me an error messatge when I try to compile some ISO MIBs into MIB Explorer Light (prev. version):

Here is the relavant excerpt from that MIB:

FdLogSnapshotFactoryEntry ::= SEQUENCE {
               fdLogSnapshotFactoryIndex         ITSPositive8,
               fdLogSnapshotFactoryDescription   SnmpAdminString,
               fdLogSnapshotFactoryObjectContext SnmpAdminString,
               fdLogSnapshotFactoryObjectID      VariablePointer,
               fdLogSnapshotFactoryLogClass      ITSRelativeRowPointer,
               fdLogSnapshotFactorySecurityModel SnmpSecurityModel,
               fdLogSnapshotFactorySecurityLevel SnmpSecurityLevel,
               fdLogSnapshotFactorySecurityName  SnmpAdminString,
               fdLogSnapshotFactoryStorageType   StorageType,
               fdLogSnapshotFactoryRowStatus     RowStatus }

When trying to compile this MIB, MIB Explorer complains about 3 lines:

“The sequence clause of the table entry definition fdLogSnapshotFactoryEntry at line xx, column xx does not match the order or number of objects registered for that table at entry fdLogSnapshotFactorySecurityModel”

for these three OIDs

  1. fdLogSnapshotFactorySecurityModel
  2. fdLogSnapshotFactorySecurityLevel
  3. fdLogSnapshotFactorySecurityName

These are the definitions of those 3 objects:

fdLogSnapshotFactorySecurityModel OBJECT-TYPE
  SYNTAX     SnmpSecurityModel
  MAX-ACCESS not-accessible
  STATUS     current
  DESCRIPTION
    "The security model used to activate this row of the 
     fdLogSnapshotFactoryTable and that shall be used when accessing the object
     referenced by fdLogSnapshotFactoryObjectID."
  ::= {fdLogSnapshotFactoryEntry 6}
  
  fdLogSnapshotFactorySecurityLevel OBJECT-TYPE
  SYNTAX     SnmpSecurityLevel
  MAX-ACCESS not-accessible
  STATUS     current
  DESCRIPTION
    "The security level used to activate this row of the 
     fdLogSnapshotFactoryTable and that shall be used when accessing the object
     referenced by fdLogSnapshotFactoryObjectID."
  ::= {fdLogSnapshotFactoryEntry 7}

fdLogSnapshotFactorySecurityName OBJECT-TYPE
  SYNTAX     SnmpAdminString
  MAX-ACCESS not-accessible
  STATUS     current
  DESCRIPTION
    "The security name used to activate this row of the 
     fdLogSnapshotFactoryTable and that shall be used when accessing the object
     referenced by fdLogSnapshotFactoryObjectID."
  ::= {fdLogSnapshotFactoryEntry 8}

All other objects in this table (except the index) have MAX-ACCESS read-create, only those 3 have MAX-ACCESS not-accessible. If I change their MAX-ACCESS to e.g. read-only (and add them necessarily to an object group), MIB explorer compiles the MIB, but I cannot find no reason why the MIB is rejected in the first place.

Has anyone ever experienced such error before? Is there an explanation here that I didn’t get?

2

Maybe the error message is a bit unclear and there was a discussion with one authors of the RFCs (and me) more than 20 years ago, whether the SEQUENCE logic from ASN.1 which defines an order must or should be applied to SMIv2 as well. No clarification or errata resulted from that discussion though.
In any case, on the wire, an SNMP agent must return objects in lexicographic order of their OID. Thus, if you define a table where column with OID x.2 is defined in the SEQUENCE before the column with OID x.1, then the agent will return the columns in order x.1|x.2. However, for INDEX columns this is only true if they are read-only. For not-accessible columns, the INDEX clause defines the order.

Because are often misunderstandings and incompatibilities caused by inconsistent order of objects in SEQUENCE clause vs. column OID order, The strict mode of the MIB Explorer SMI compiler is reporting this error.

In your case, the root cause seems to be the following:

The not-accessible MAX-ACCESS is used in SMIv2 (SNMP) tables for INDEX columns only as “auxiliary-objects” (see §7.3 of RFC 2578 - Structure of Management Information Version 2 (SMIv2)).
I assume from the error, that you did not include all these three not-accessible objects to the INDEX clause of the corresponding table?

Does that help?

3

First of all, thanks for your quick and detailed answer, and excuse me for my ignorance about SMIv2, I seem to lack several extra brain cells to get it.

I didn’t design this MIB, this is how the table entry is defined:

fdLogSnapshotFactoryEntry OBJECT-TYPE
  SYNTAX     FdLogSnapshotFactoryEntry
  MAX-ACCESS not-accessible
  STATUS     current
  DESCRIPTION
    "An entry in the fdLogSnapshotFactoryTable. An entry of this table can be 
    called by external logic (e.g., the Action table defined in ISO/TS 20684-3) 
    to create an entry in the fdLogTable."

  INDEX      {fdOwnerIndex, fdLogSnapshotFactoryIndex}
  ::= {fdLogSnapshotFactoryTable 1}

Those three fields ‘fdLogSnapshotFactorySecurityModel’, ‘fdLogSnapshotFactorySecurityLevel’, and ‘fdLogSnapshotFactorySecurityName’ aren’t part of the INDEX, because they aren’t part of the key to table row: I assumed they only hold some not-to-be-shared security-information (that’s why they aren’t accessible from outside).

If I change the INDEX to include those 3 objects, the MIB successfully compiles, too.

Though the part I don’t understand is why should a field be part of the index if it doesn’t identify a row at all? I didn’t gather that from the RFC2578.

4

Ok, understood. In this case please choose one of the following fixes:

  1. remove the columns from the MIB specification and add their description in proper way to the table’s Entry description.
  2. Change them to read-only and provide a AGENT-CAPABILITIES statement where these three columns are listed as “not-implemented” (see 6.5.2.1)

Moving them into the INDEX will break semantics and interoperability!
But because SMIv2 requires all not-accessible columnar objects to be part of the INDEX, there is no other way to fix this bug in the original MIB specification.

1 Like