[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2174.0. "Spider MIB information" by WOTVAX::PURNELLR ( Life, it's not what I thought it was !) Thu Jan 23 1992 12:40

    
    I have compiled the MIB for Spider RETIX bridges into a customer's
    DECmcc SNMP AM.
    
    Thankfully the process went through quite happily after one stumble.
    The MIB compiler did not like the following syntax
    
 	   	SYNTAX OCTET STRING (SIZE(13)
    
    On comparing the MIB ASN.1 file for the RETIX with the released MIB
    extensions, I modified the above string to;
    
    		SYNTAX OCTET STRING
    
    Following that modification the MIB loaded ok, although when the
    dictionary was updated an INVALID ID error registered.
    
    So, the customer can now pull a multitude of information from the
    Spider RETIX bridges......unfortunately there is no documentation to
    offer descritions as to what all of the returned field values mean in
    the RETIX MIB extensions.
    
    When a concise MIB is submitted, does the vendor have to submit a
    corresponding document which states what the parameters mean ? If so
    where could I find this on Internet, or alternatively does anyone have
    the information I need ?
    
    The customer is very happy at getting the MIB, but finds it rather
    strange that SPIDER are unable to supply a document that offers
    explanations of the propriatory values. I would love to see the SPIDER
    salemans face when asked by the customer for the Retix MIB information!
    
                                                                           
    
    :*)
    
    
    Rex
    
    
    
T.RTitleUserPersonal
Name
DateLines
2174.1Small 'soap-boxing'TOOK::MCPHERSONScientific progress goes 'Boink!'Thu Jan 23 1992 13:0138
>    When a concise MIB is submitted, does the vendor have to submit a
>    corresponding document which states what the parameters mean ? If so
>    where could I find this on Internet, or alternatively does anyone have
>    the information I need ?

One of the main ideas behind concise MIB format is that the devlopers include
meaningful descriptions *within* the MIB itself, using the DESCRIPTION clause,
hence the moniker "Concise MIB". This OBVIATES the need for developers to
maintain (and synchronize) separate description documents that must be changed
every time they make a change to the agent or a MIB variable.  And I quote from
RFC1212:

 |4.1.4.  Mapping of the DESCRIPTION clause
 |
 |   The DESCRIPTION clause, which need not be present, contains a textual
 |   definition of that object type which provides all semantic
 |   definitions necessary for implementation, and should embody any
 |   information which would otherwise be communicated in any ASN.1
 |   commentary annotations associated with the object.  Note that, in
 |   order to conform to the ASN.1 syntax, the entire value of this clause
 |   must be enclosed in double quotation marks, although the value may be
 |   multi-line.
 |                                                                  
 |   Further, note that if the MIB module does not contain a textual
 |   description of the object type elsewhere then the DESCRIPTION clause
 |   must be present.
                                                                    
I would beat up on the MIB writer to quit being so lazy and paste the text from
whatever separate documents they have into a single "concise" MIB description. 
Just because the RFC says it "needn't be there", doesn't mean it shouldn't.

Note that if more vendors did this, the SNMP MTU could then take vendors
DESCRIPTION fields from their MIB and use that data to create MCC HELP files
for the vendor's extensions.   Neat, huh?  (NTU doesn't do it now, but it's a
SMOP that's already been discussed...)

regards, 
doug
2174.2YAHEY::BOSEThu Jan 23 1992 17:3122
	RE .0

>>    Thankfully the process went through quite happily after one stumble.
>>    The MIB compiler did not like the following syntax
    
>> 	   	SYNTAX OCTET STRING (SIZE(13)
    
	The MIB translator did not like the above because of the unmatched
	brackets. The translator would indeed accept something like
   
 	   	SYNTAX OCTET STRING (SIZE(13))

>>    Following that modification the MIB loaded ok, although when the
>>    dictionary was updated an INVALID ID error registered.

	We have seen the INVALID ID CODE msg when the mib has enumerations
	with values > 2**20 -1. This will be fixed in V1.2 so that values
	upto 2**32 -1 are accepted.