In article <7cab6615.0309231920.4ebb8d5e@posting.google.com>,
randy@alurtenaga.com.my says...
> Hi There,
> I'm using SNMPC6.0 to compile mibs. Currently i found some
> errors & warning when compling SNMPV2-SMI.MIB. The errors description
> are stated below.

The problem in this case is a common failing in many MIB compilers in
that they often are unable to parse things such as macro definitions that
are in the SMI base modules but are not permitted in MIB modules. This
is compounded by the fact that SNMPv2-SMI basically violates its own
rules in that it defines both information that a MIB compiler typically
needs to parse/load as well as trying to define the language its self.

SNMPv2-SMI really should have been written to only define the base data
types and macros and nothing else. Because it defines both macros and
needed branch definitions, one usually has to delete the macro
definitions from the module in order to successfully parse it with most
compilers. If deleting the macros from the file still leaves you with
errors, then you probably need to delete the tagged (base) data type
definitions as well (IpAddress etc.) which shouldn't be a problem
because they will generally be built-in to the compiler or NMS
application.

> My Question is
> 1. What is the coding using for mib file?

I'm not sure I understand the question. MIB files are written in either
the SMIv1 or SMIv2 language, of which SNMPv2-SMI partially defines SMIv2.
The problem here is that SNMPv2-SMI is special (or I might be inclined to
say "broken") in that it specifies both part of the language and uses its
self at the same time. A similar problem exists with SNMPv2-TC because
it defines both the TEXTUAL-CONVENTION macro (which is part of SMIv2) and
a common set of those TEXTUAL-CONVENTIONs. So to load/parse SNMPv2-TC
with most compilers you have to delete the macro definition.

> 2. How do I debug the errors from the compiler?

Well, that depends on the compiler and the quality of error messages it
gives you. The SMIv1, SMIv2 and ASN.1 specs need to be referenced if the
error messages aren't sufficiently clear, although the SMI specs are
unfortunately full of ambiguities. An alternate MIB compiler with better
error messages might be more helpful, but I'm not sure how much help it
would be with the macros: either it'll fail with a parse error because it
can't deal with the macro definitions or (as MIB Smithy does for example)
silently ignore them because it knows that they're supposed to be there
in those particular modules and knows how to parse them (only generating
errors if it finds macros in any non-base modules). In this case,
though, it's SNMPC's compiler that's lacking, yet if you're trying to use
some MIBs with SNMPC then you need to work within the limitations of
SNMPC and another MIB compiler won't help much. (Another MIB compiler
would only help with figuring out errors in the MIB modules, rather than
figuring out limitations of the first compiler.)

> 3. Is that all the mibs extacted from rfc should be errors free?

You'd think. They've gotten better in recent times since IETF MIBs
undergo a review process these days, but there are a lot of old MIBs in
RFCs that have errors in them too, just as there are a lot of old (and
new) vendor-specific MIBs with errors in them.

> 4. what is the recommended tools use to debug & correct the mibs
> errors?

That depends on who you talk to - different people have experience with
differen tools and make recommendations based on what they're experienced
with. I'd plug ours here but I try not to get too "sales-pitchy" on the
newsgroup. Your best bet is to try out several, see what's right for
you, and talk to the developers and people with experience using several
to learn about how the capabilities compare. A good place to start would
be www.snmplink.org for references to various commercial products and
some of the free online validator tools such as:

http://www.muonics.com/Tools/smicheck.php
http://www.simpleweb.org/ietf/mibs/validate/
http://agentpp.org:8080/mibtools/MIBTools.jsp

--
Michael Kirkham
Muonics
http://www.muonics.com/

randy@alurtenaga.com.my (Randy) wrote in message news:<7cab6615.0309231920.4ebb8d5e@posting.google.com>...
> Hi There,
> I'm using SNMPC6.0 to compile mibs. Currently i found some
> errors & warning when compling SNMPV2-SMI.MIB. The errors description
> are stated below.
>
> snmpv2-smi.mib(42): error: Got: 'MODULE-IDENTITY'; Expected: word OR
> quoted str
> snmpv2-smi.mib(67): error: Got: 'OBJECT-IDENTITY'; Expected: word OR
> ???
> snmpv2-smi.mib(90): warning: Got: '::='; Expected: DEFINITIONS
> snmpv2-smi.mib(91): warning: Got: 'OBJECT'; Expected: BEGIN
> snmpv2-smi.mib(91): error: Got: 'OBJECT'; Expected: word OR quoted
> string
> snmpv2-smi.mib(113): error: Got: '{'; Expected: word OR quoted string
> snmpv2-smi.mib(131): error: Got: '2'; Expected: word OR quoted string
> snmpv2-smi.mib(159): error: Got: 'IpAddress'; Expected: word OR quoted
> string
> snmpv2-smi.mib(272): error: Got: 'NOTIFICATION-TYPE'; Expected: word
> OR ???
> snmpv2-smi.mib(307): error: Got: 'zeroDotZero'; Expected: word OR ???
>
> My Question is
> 1. What is the coding using for mib file?
Based on the RFC 2578.(SMI)
> 2. How do I debug the errors from the compiler?
u should know the SMI.
> 3. Is that all the mibs extacted from rfc should be errors free?
I hope so...
> 4. what is the recommended tools use to debug & correct the mibs
> errors?
> on line mib compiler is avilable ..
u can use this link http://www.simpleweb.org/ietf/mibs/validate/

> Thanks.

-Kamaraj

Michael Kirkham wrote:
> randy@alurtenaga.com.my says...
> > Hi There,
> > I'm using SNMPC6.0 to compile mibs. Currently i found some
> > errors & warning when compling SNMPV2-SMI.MIB. The errors description
> > are stated below.
>
> The problem in this case is a common failing in many MIB compilers in
> that they often are unable to parse things such as macro definitions that
> are in the SMI base modules but are not permitted in MIB modules. This
> is compounded by the fact that SNMPv2-SMI basically violates its own
> rules in that it defines both information that a MIB compiler typically
> needs to parse/load as well as trying to define the language its self.

I disagree that it is a failing in a MIB compiler to be unable to parse
constructs that are not permitted in MIB modules, such as macro
definitions or definitions of the application-specific base data types.
It would be a failing, in fact, if a MIB compiler allowed a MIB module
containing such things to parse correctly!

About the only thing that a MIB compiler should need to load are the
OID-valued constants such as mgmt, mib-2, transmission, experimental,
enterprises, and so on. But these are sufficiently small in number
that they could be built-in (like iso, ccitt, and joint-ccitt-iso
are).

> SNMPv2-SMI really should have been written to only define the base data
> types and macros and nothing else. Because it defines both macros and
> needed branch definitions, one usually has to delete the macro
> definitions from the module in order to successfully parse it with most
> compilers. If deleting the macros from the file still leaves you with
> errors, then you probably need to delete the tagged (base) data type
> definitions as well (IpAddress etc.) which shouldn't be a problem
> because they will generally be built-in to the compiler or NMS
> application.

If I had my way, something like ABNF would have been used to define all
the gramamtical constructs and data types, and the only things in the
module would have been the predefined constants -- which would be legal
in an ordinary MIB module. In other words, everything associated with
a reserved word (which is part of the language) would have been defined
in a metalanguage (one more suitable than the "adapted subset" of
ASN.1-1987), and none of that stuff should need to be imported. The
rest could be treated as a standard library module (which might be
build into the compiler, but need not be).

Responding now to some of the OP's question:

> > My Question is
> > 1. What is the coding using for mib file?

SNMPv2-SMI is not a valid MIB module. It contains constructs
that are not allowed in MIB modules. It therefore should not
compile. Your MIB compiler should have the definitions built
in or in some standard library files included with it.

> > 2. How do I debug the errors from the compiler?

You don't. Just don't try to compile SNMPv2-SMI.

> > 3. Is that all the mibs extacted from rfc should be errors free?

The ones that are actually MIB modules should. But SNMPv2-SMI,
SNMPv2-TC, and SNMPv2-CONF are not, in fact, MIB modules (appearances
to the contrary notwithstanding).

> You'd think. They've gotten better in recent times since IETF MIBs
> undergo a review process these days, but there are a lot of old MIBs in
> RFCs that have errors in them too, just as there are a lot of old (and
> new) vendor-specific MIBs with errors in them.

Sad but true.

> > 4. what is the recommended tools use to debug & correct the mibs
> > errors?
>
> That depends on who you talk to - different people have experience with
> differen tools and make recommendations based on what they're experienced
> with. I'd plug ours here but I try not to get too "sales-pitchy" on the
> newsgroup. Your best bet is to try out several, see what's right for
> you, and talk to the developers and people with experience using several
> to learn about how the capabilities compare. A good place to start would
> be www.snmplink.org for references to various commercial products and
> some of the free online validator tools such as:
>
> http://www.muonics.com/Tools/smicheck.php
> http://www.simpleweb.org/ietf/mibs/validate/
> http://agentpp.org:8080/mibtools/MIBTools.jsp

There is a nifty e-mail robot to do checks with the libsmi family of
tools (smilint, smidiff, and kin). Send an e-mail message to
smilint@ibr.cs.tu-bs.de with the word help in the subject line (and
nothing else) and an empty message body.

nobody

In article , nobody@[127.0.0.1]
says...

> I disagree that it is a failing in a MIB compiler to be unable to parse
> constructs that are not permitted in MIB modules, such as macro
> definitions or definitions of the application-specific base data types.
> It would be a failing, in fact, if a MIB compiler allowed a MIB module
> containing such things to parse correctly!

Bull. It'd certainly be a failing of the compiler if it allowed it to
parse correctly and but didn't complain about it if such were used in
non-base modules. But not being able to parse the base modules
themselves? Big disagreement here. The SMI authors brought this on by
defining the main branches in the same modules as the language its self
and then further changing around where they're defined.

[MIB Smithy doesn't complain at the moment, but only because I removed
the complaint while extending its parser capabilities (for use with
generic ASN.1 (non-MIB) modules, for which the errors would/will be
generated at validation time rather than at parse time) but got side-
tracked to more urgent user needs before finishing. I could turn the
complaint back on, but the chances of it being an issue - an actual MIB
module trying to define its own macros - are pratically nil. I'd rather
leave it as-is for the moment, until I get a chance to finish those new
capabilities, since it won't affect anything. An interesting side
effect, though, is that MIB Smithy catches syntax errors in the macro
definitions from early versions of the SMI that went uncorrected for
years.]

> About the only thing that a MIB compiler should need to load are the
> OID-valued constants such as mgmt, mib-2, transmission, experimental,
> enterprises, and so on. But these are sufficiently small in number
> that they could be built-in (like iso, ccitt, and joint-ccitt-iso
> are).

Making them built-in is an option, but one that replaces one set of
problems for another, not the least of which is forward compatibility,
though I don't really feel like getting into them all right now.

But take mib-2, for example, which SMIv1 modules imported from RFC1213-
MIB (not an SMI base module) but was moved into SNMPv2-SMI (which is).
But not until RFC 1902! Certainly, RFC 1442 is obsolete, but that's a
small consolation for someone who might be stuck with a legacy compiler
written against RFC 1442, whose version of SNMPv2-SMI doesn't define
mib-2. And then there's VariablePointer, RowPointer, StorageType,
TDomain and TAddress defined in RFC 2579 (SNMPv2-TC) but not defined in
RFC 1443 (also SNMPv2-TC).

Now, I don't know about you but I'd much rather have a compiler that
could properly deal with such lack of foresight by the SMI authors,
working with what it's given and at most complaining about macros it
doesn't recognize by module name as being an SMI base module, rather than
complaining about not knowing something like mib-2 being in SNMPv2-SMI
(or, worse, conflicts being what's imported and what's predefined) and
being stuck.

If at a later date RFC 2578 and 2579 are replaced and some more OIDs or
TEXTUAL-CONVENTIONs are added without changing SNMPv2-SMI and SNMPv2-TC
to some other names, it's no problem for me. I don't have to do anything
at all - it just works. The same can't be said for the compiler that has
those things built-in and won't let you load those modules because
they're not pure MIB modules and it's too inflexible to realize what it
is and utilize it properly.

> If I had my way, something like ABNF would have been used to define all
> the gramamtical constructs and data types, and the only things in the
> module would have been the predefined constants -- which would be legal
> in an ordinary MIB module. In other words, everything associated with

I've been planning for quite a while (since about the time SMIng was
being closed down) to do that and submit it as an individual draft for
SMIv2.1. I've been too busy yet, however.

> a reserved word (which is part of the language) would have been defined
> in a metalanguage (one more suitable than the "adapted subset" of
> ASN.1-1987), and none of that stuff should need to be imported. The
> rest could be treated as a standard library module (which might be
> build into the compiler, but need not be).

What I had in mind for SMIv2.1 is for the ABNF and specification to
incorporate and/or clarify all of the bits that currently come from ASN.1
to the point that ASN.1 would no longer be in any way a necessary
reference for determining MIB parsing and authoring rules. It would be
pretty much the same as SMIv2, except it would be a self-contained
specification, clarify that a few things are permitted that are
completely unmentioned that need to be permitted, and close a couple
loopholes on things that nobody in their right mind would do and almost
nobody (no pun intended) supports anyway.

But as my plan for doing an SMIv2.1 draft is primarily for clarification
purposes and solidification, I do not plan to change the rules so
significantly as to say certain things need not be imported. Besides
being a compatibility issue (especially if the module names aren't
changed), without the imports there is no way to determine what the
intended SMI version is. And anyone who says you can based on things
like the presence of a MODULE-IDENTITY statement or use of MAX-ACCESS
instead of ACCESS is ignoring the possibility of an SMIv3 down the road
some day that (unless a totally new language like the IRTF SMIng
proposal) is still ASN.1-like but introduces new incompatibilities or
ambiguities. I'd rather a compiler issue a "I don't know that SMI
version" type error than just a "Your use of is invalid"
type error (e.g. if the STATUS values change as they did from SMIv1 to
SMIv2) because the compiler doesn't know about SMIv3.

> There is a nifty e-mail robot to do checks with the libsmi family of
> tools (smilint, smidiff, and kin). Send an e-mail message to
> smilint@ibr.cs.tu-bs.de with the word help in the subject line (and
> nothing else) and an empty message body.

www.simpleweb.org is also libsmi based. but it's got form options so you
don't need to remember various flags and such for the email reflector. I
don't know how current it is, though.

--
Michael Kirkham
Muonics
http://www.muonics.com/