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

Re: Some additional obscure questions...

At 2/6/2003:03:04 PM, Randy Presuhn wrote:

Hi Randy,

> From a compiler / language design perspective, it
>is a forward reference since the value cannot be
>computed until more input is processed.

Granted...this is true for all such "circular"
examples that have been provided...i.e., where
somehow both "a" depends on "b" and "b" depends
on "a"...do we see that in real MIBs?

>the compiler won't even know whether such a DEFVAL
>is of the correct data type until that subsequent object
>definition has been processed.

I honestly can't follow that statement.  In your
example, the DEFVAL value *must* either devolve
to an OID or fail to devolve to anything.  The
only possible *type* for any DEFVAL is explicitly
defined by the SYNTAX clause of its OBJECT-TYPE
definition.  Isn't it?

>> In my view, the meaning of "forward reference"
>> that is central to this discussion refers to a
>> specification in the naming hierarchy of the MIB
>> that is not rooted in the predecessor  portion
>> of the MIB (modulo de jure standard starting
>> points).  (Note that the use of "the MIB",
>> rather than "a MIB" is deliberate there.)
>I think that definition is a bit too narrow.  For purposes
>of a MIB compiler, resolving references is not limited
>to the registration of a defintion, but also resolution
>of the contents of that definition (e.g. the OBJECTS
>mentioned in a NOTIFICATION-TYPE).

I am not aware of any MIB design constraints --
unless there are going to be more of these
"circular" examples -- in which the OBJECTS
used in a NOTIFICATION-TYPE definition could
not be defined prior to the NOTIFICATION-TYPE
using a "better" (i.e., more consistent with
the concept of "naming hierarchy").  Are there

>Since a
>compiler needs to be able to cope with forward
>references for the various cases already brought up
>in this thread,

As hard as I am trying -- and I truly am! -- I
have not yet seen an example that was not either
"circular" and/or otherwise "contrived" [by which
term I am referring simply to the details of the

I have not seen a concrete example from a
real MIB nor a citation of any part of the
SMI that requires support of "forward
references" to the naming hierarchy.  Indeed,
I think it's just the opposite:  Good examples
from real MIBs don't exist and the SMI, to
the extent it covers the topic at all, at
the very least suggests that object values
should be defined before referenced.  We
know that is true for external symbols (from
Sec. 3.2 of RFC2578) and, my point is, the
design guidance one can infer from the SMI
is that it is true of internal symbols too.

I grant that the "circular" examples
necessarily refute that last statement.
I'm not sure we encounter such examples
in real MIBs and, therefore, given the
rest, there is no need to support them
in MIB compilers.

>limiting the ability to have forward
>references in the MODULE-IDENTITY would, in my
>view, make things more complicated rather than
>simpler.  (I.e., one would need to implement two
>OID value resolution algorithms rather than one.)

Yep.  Two are harder than one.  I don't
think the facts suggest you need two...
you only need one...the simpler one...
objects should be either IMPORTed or
defined before used (in other objects).

Again, I thank all who are contributing
for their time and thought.  Perhaps we
are narrowing this down to the point where
I will be able to see what I have missed
or at least be able to phrase my position
in a more compelling way.

Sometimes previously unspecified features
emerge into practice accidentally, of sorts.
Sometimes those turn out to be necessary
and/or good; sometimes not.  In the former
case, they should then be specified.  In
the latter case, they should be discouraged
at the least.