Re: Some additional obscure questions...

[Michael Kirkham <mikek@muonics.com>]

On Thu, 6 Feb 2003, Bob Natale wrote:

> I genuinely appreciate the time and effort you
> are putting into this discussion.  I hope that
> my persistence does not come across as anything
> other than a sincere effort to learn...that's

Not at all.  There are plenty of people on this list with much more
expertise than I, as probably evidenced by some of my recent topics and
the fact that my implementation is comparatively pretty new.  I'm sure
someone would be happy to put me in my place if I tried to claim I knew it
all. ;)

> >A parser won't generally know what it sees 'false' here whether that is a
> >reference to an OID value or whether it is an enumeration label.
>
> I cannot understand that assertion.
> The possible values of an object with TruthValue
> SYNTAX are specified unambiguously defined in
> RFC2579 in the TruthValue TC (which is IMPORTed
> in this example).  So, I don't think this is a
> "forward reference" of any type.  Do I have that
> wrong?

Not necessarily wrong or right but a matter of implementation (more
below).  Where I say "parser", what I'm talking about is the code that
deals solely with the grammar rules -- the contextual association of
tokens comprising the syntax of the language, but not necessarily the
semantic rules.  From below it I'm guessing that you're thinking in terms
of the parsing and the checking of semantics happening in the same phase.
Which they can as an implementation choice, but I believe it makes it
harder in some respects.

> >TruthValue' and go look up TruthValue and copied its information into the
> >OBJECT-TYPE's definition internally).  But that would seem to me to be way
> >more complicated.
>
> Again, I can't understand.  I parse all IMPORTs
> up-front.  Is there an argument for not doing so?

This is perhaps where we have a disconnect in our views of what is and
isn't a forward reference.

Whether or not you parse all of the IMPORTS up front is an implementation
choice.  Both methods have their pros and their cons that, for most
purposes, amount to a personal choice of balance between ease of
implementation and flexibility.  The complete merits of either probably
aren't important for the conversation at hand.

I don't do it this way, however, since, among other reasons, the nature of
my product is that it needs to be able to work with incomplete MIB
specifications.  The way I've handled things, everything can be
interpreted as a forward reference.  I make no effort to "connect the
dots", so to say, until I've completely parsed the file/modules being
read.  That is, the parser doesn't know anything about what 'TruthValue'
or 'false' are in terms of data type/value/etc. -- it just recognizes them
(contextually) to be a type reference and an identifier.

So, when you see '... SYNTAX TruthValue ... DEFVAL { false }' you
immediately postpone parsing the rest of the module until you have
verified that 'false' is an existing enum label in TruthValue?

This, I believe, is why we're stuck on terminology (ie., what is or isn't
a forward reference).  If an implementation analyses everything
immediately in context, then it can't support forward references.  I'm not
sure how you'd deal with other things (such as comparing a row's SEQUENCE
definition to the actual columns) using this method, but that's probably
not important for this discussion.

> Sorry, I just don't follow your thinking here.
> TruthValue should parsed at the IMPORTS statement;
> at that point, its permissible SYNTAX values are
> known.

This, again, is an implementation choice.  TruthValue "may" be parsed at
the IMPORTS statement.  Whether or not it "should" depends on the
appropriateness for the implementation/etc.  If my implementation did it
this way, given its specific purposes (in particular, creation/design of
MIBs, not just their use), it would be unusable for those purposes.  This
says nothing about another person's implementation where this might be
less appropriate.

> Maybe.  Maybe I'm just losing track of terminology
> here.  Or maybe I'm not understanding your examples.
> Clearly it's my view that the above TruthValue example
> is an example of what I *want* to see...and not a
> forward reference of any kind.

Does the above clarify a bit?

> Right.  I am fairly certain there are not any
> "normally-occurring situations" of this kind.
> I am also fairly certain that any "abnormal"
> examples that might exist could be better
> re-cast to avoid the forward reference as you
> define it (correctly, I believe) above.

They would be better re-cast to avoid forward references, definitely.  No
disagreement here.  But that makes one significant assumption: that
recasting it is an option.  As a person promoting good MIB designs and
compatibility, I would definitely promote organization/structure that
avoids forward references.  As an implementor, however, I try to go out of
my way to be as accomodating as possible with regards to both "uncommon
but legal" syntax as well as "broken but workable or correctable" issues.
This is largely why the implementation generates assignments in modules in
ascending order.

> >This isn't, IMHO, sufficient reason not to support them, however.
>
> *That* is where we disagree.

Disagree that implementations should support them, or disagree that the
SMI should support them?  I meant the former:  that being less common
usage is not a reason to not support them in an implementation.  I'm in
the same camp as the others who believe that they are already legal in the
SMI.  Uncommon, yes.  Bad idea to use given that there are a fair number
of compilers out there that don't support them, yes.  Illegal, no.

> design of the SMI.  It means that enforcing such
> consistency will likely aid them in avoiding even
> greater design carelessness in the future.  Furthermore,
> the effort to put 'a' before 'b' is not significant,
> assuming that one puts some effort into the up-front
> MIB design process.  We should always encourage that
> and discourage unnecessary looseness that permits
> people to skimp on up-front analysis and design.

I agree with you in terms of good/clean MIB design.  However, you might
say I'm playing "consumer's advocate" here.  If you're a consumer with a
device and an implemented MIB module (from a vendor or the IETF) and it
won't compile, they're not really responsible for the way the module was
laid out.  Who would you suppose is going to field the support call about
it?  The device vendor or the compiler/NMS vendor? :)

Avoiding support calls/costs is plenty of reason enough in my opinion to
support forward references in an implementation.  This is really still an
implementation choice, though.  The real issue is whether or not forward
references are legal.  Which, I believe, they are.

> So my argument is that *if* there is no requirement
> in the SMI to support the first construct which,
> in this example at least, clearly leads to more
> work and utilizes more resources (minuscule in
> this example, granted), *and* the superior approach
> is (1) totally consistent with the SMI and (2) requires
> less up-front design work (no need to define "mib"),
> then why promote the second practice at all?

I don't think anybody is promoting the practice, but rather promoting
implementation support for something that is allowed by the SMI.

Was that customer a MIB author, or a person trying to use someone else's
MIB?  Would it make a difference in your position?

--
Michael Kirkham
www.muonics.com