Re: Some additional obscure questions...

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Bob Natale" <Bob.Natale@AppliedSNMP.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <mibs@ops.ietf.org>
> Sent: Thursday, February 06, 2003 1:15 PM
> Subject: Re: Some additional obscure questions...


...
> >Indeed,
> >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?

A compiler needs to be able to figure out what's wrong
in order to generate a reasonable error message.  For
example, consider:

a OBJECT-TYPE ... SYNTAX OBJECT INDETIFIER ... DEFVAL { b } ...

b INTEGER ::= -1

If one treats the DEFVAL { b} as a forward reference, then one can
correctly generate an error message pointing to the DEFVAL saying
"wrong type" or something like that.  If one treats the DEFVAL as
an implicit declaration of b's type (rather than merely a value reference)
then things get really ugly if one encounters another reference to the
value with a different implicit type or contradictory value constraints, e.g.,

c OBJECT-TYPE ... SYNTAX  Unsigned32 ... DEFVAL { b } ...

...
> I am not aware of any MIB design constraints --

I think that's precisely the point: RFC 2578 has given MIB authors
no reason whatsoever to think that forward references were somehow
undesirable.

> 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
> any?

I view the fact that RFC 2578 does not impose ordering
constraints (other than the placement of the MODULE-IDENTITY,
which is presumably as much a human factors consideration as
anything else) as a rather strong clue that compiler writers need
to be prepared for forward references.

...
> 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
...

Defined or declared?   When something shows up
in an IMPORTS, the module it references hasn't necessarily
been processed from the input stream, so even this case may,
from the compiler's perspective, be a forward reference.
Even calling it a "declaration" is a bit strong, since in these cases
it's nothing more than a value reference, and the type information
isn't known (although potential conflicts can be inferred from the
context in which some references appear) until the actual definition
shows up in the input stream.

Randy