| 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 |
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.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2174.1 | Small 'soap-boxing' | TOOK::MCPHERSON | Scientific progress goes 'Boink!' | Thu Jan 23 1992 10:01 | 38 |
> 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.2 | YAHEY::BOSE | Thu Jan 23 1992 14:31 | 22 | ||
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.
| |||||