[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some additional obscure questions...

At 2/7/2003:01:46 AM, David T. Perkins wrote:

Hi Dave,

>It sort of seems like you have a MIB compiler that has limitations
>in its design,

Nope.  It has limitations in the set of requirements
that it aims to implement based on (1) the SMI specs
and (2) the purposes it serves for its users.

>and you want the MIB module language to be restricted
>so that your MIB compiler could be called compliant?

Nope.  I don't want the absence of every non-requirement
in the SMI to be taken as a carte blanche license to
implement whatever a MIB author wants...especially in
respects for which a more straight-forward solution
exists that is more in spirit (naming hierarchy) with
the overall thrust of the SMI specs.

>Explaining the
>allowed and unallowed forward references sort of seems to complicate

No, I don't think so.  Understanding the different
concepts that are sometimes conveyed by an overloaded
term is an essential step towards complexity reduction.
In the present context, both "forward reference" and
"MIB compiler" are two (of the possibly more) terms
that are overloaded.  The class of forward references
that subvert the naming hierarchy might constitute a
special case (in this context).

>Also, if you also have the limitation that OID values must
>be written in the form { <name> <number> },

I don't.

>then you cannot support
>the following valid MIB module that must use a forward reference:
>      x FROM ...
>     ;
>     ....
>     ::= { y 1 } -- this is { x 1 1 }
>  y OBJECT IDENTIFIER ::= { x 1 }

There is no *must* in that.  I gave a concrete example
in an earlier post showing the above from a bastardized
version of the Printer-MIB and then the correct form
that ended up in RFC1759 (if I recall the RFC number

>In general, I sympathize with Bob, in that the MIB module language has
>lots of extra stuff from ASN.1 in it that makes writing a MIB compiler
>harder than it needs to be.

I don't really have that complaint at all.  Indeed,
I am "complaining" about something that might be in
the full ASN.1 specs (as Randy has, I think, stated)
but is *not* specified as a requirement in the SMI
and that we are then taking the absence of a specific
requirement *not to do it* to support the claim that
it is allowed because it is not disallowed.  That's
weak, IMHO.

>And maybe if there was an opportunity to
>get rid of the extra stuff, like removing the IMPORTing all of the
>constructs such as OBJECT-TYPE, etc, I would support it. 

I have zero problems with IMPORTs...indeed they are
the solution to a large portion of the forward refs
that subvert the naming hierarchy (the solution to
the remaining portion is correct object ordering
within a MIB).  I don't consider the "circular"
examples as meaningful at all.

All of the above refers to what I think about how
MIBs *should* be written -- and I am very thankful
that all of the IETF standard MIBs that I have
examined recently (not a large number, true) conform
to that guidance.  I did not find one case that used
a forward reference in the naming hierarchy.  (I did
not look for any of the other types.)

In the course of the exchanges with Mike and Randy
in particular, I cam to realize that forgetting about
the overloaded nature of "forward reference" and
"MIB compiler" caused me to argue the case too
broadly.  Since it is conceivable that someone
can edit a perfectly good MIB module to introduce
a totally superfluous naming hierarchy forward
reference (as my earlier real-life concrete
example illustrated), then it is good that we
have some "MIB compiler" tools that either
report it to the user and require the MIB to
be corrected, report it to the user and accept
it, or silently accept it.  Depending upon the
purposes the "MIB compiler" user has in mind
(at the time) any one of the above can be seen
as the correct behavior.

Anyway, I do appreciate your taking the time to
comment on this thread.  I know the process is
helping me and I hope it has held some value
for some others as well.  I do plan to post a
brief bullet-list level summary soon (but that
might not be until the weekend).