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

Re: Some additional obscure questions...



At 2/6/2003:05:07 PM, Michael Kirkham wrote:

Hi Mike,

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
all it is...my personal history shows that I'm
probably not a bad student...but maybe I'm faltering
in my senior years here! :-)  Anyway...on to the
discussion:

>On Thu, 6 Feb 2003, Bob Natale wrote:
>
>> >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?
>
>With regards specifically this this statement/question:
>
>DEFVAL-EXAMPLE-MIB DEFINITIONS ::= BEGIN
>IMPORTS
>   OBJECT-TYPE
>      FROM SNMPv2-SMI
>   TruthValue
>      FROM SNMPv2-TC
>   ...
>   ;
>   ...
>   trueOrFalse OBJECT-TYPE
>      SYNTAX TruthValue
>      ...
>      DEFVAL { false }
>      ::= { ... }
>END
>
>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?

>In
>theory it *could* if you did all your parsing manually instead of using a
>parser generator with, say, only 1 lookahead token, and you went through
>and resolved every possible thing as you parsed it (e.g., you see "SYNTAX
>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?

>And, not only that, but then you'd definitely have to
>consider type references to be forward referencing too (and there I would
>point back to the table-based example I gave with the order of the
>sequence type/table/row/columns being at issue).

I don't consider type references to be "forward
references" of consequence...only those that
"violate" (my opinion) naming hierarchy consistency
rules.

>Whether or not this falls into the common definition of a forward
>reference is probably debatable.  Depending on the implementation, the
>definition of 'TruthValue' may or may not be known at the time this object
>is parsed.  But I doubt many compiler implementations are going to try to
>figure out what 'false' means immediately upon parsing it.  They're going
>to save it off somewhere in internal data structures to deal with once
>everything is parsed, at which point it can do post-processing stuff that
>includes verifying that 'false' is an okay DEFVAL for this object.  In
>order to do that, the compiler is going to have to retain some of the
>symbolic nature of the parsed data and resolve 'false' later through
>implementation-specific algorithms.

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.

>Resolving things after the parsing phase, as opposed to during, qualifies
>as forward-referencing in my book.  Perhaps not yours and that's why we've
>got some disagreement on some of the issues.

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.

>> 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
>> any?
>
>To be honest, I haven't been able to think of any normally-occuring
>situations where it is impossible to define a MIB module without forward
>references for OID assignments (::= etc. -- that is, excluding all of the
>other references to OID values except those that assign values to
>descriptors as in macro invocations).

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.

>This isn't, IMHO, sufficient reason not to support them, however.

*That* is where we disagree.

>Not supporting them just means that someone, somewhere, will get to deal
>with the headache when their MIB doesn't work with a particular compiler
>because they put 'b' before 'a'.

No, it means they should have put 'a' before 'b'
because it is consistent with the naming hierarchy
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.

And, no, I'm not a total dinosaur...I do believe
in rapid prototyping, iterative methodologies, and
running code...but only in the context of basic
engineering values as well.  And, yes, I do believe
in the "be generous in what you accept" dictum...
but not to the point where senders believe it is
acceptable to be careless in what they send.

I recently had this customer support issue:

   IMPORTS mgmt from SNMPv2-SMI;
   Some-MIB MODULE-IDENTITY ::= { mib xx }
   mib OBJECT IDENTIFIER ::= { mgmt 1 }

Where "mib" used in the MODULE-IDENTITY
macro requires a forward reference to
"mib" as defined (later) as "mgmt 1".

The right way to do that, of course, is:

   IMPORTS mib-2 from SNMPv2-SMI;
   Some-MIB MODULE-IDENTITY ::= { mib-2 xx }

And both the forward reference and a superfluous
duplicate definition of "mib-2" ("mgmt 1") from
the perspective of the overall MIB namespace.

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? 

>It's also possible to write modules such that they're impossible to deal
>with without handling forward references; but those are exactly the
>"circular" examples, which may be contrived to varying degrees.  If
>there's no circular nature to it, then it must be linear and can be
>reordered, right? :)

Exactly.  The question is:  Do we see a real
need for such "circular" relationships (that
have impacts on the naming hierarchy) in real
MIBs?  If so, I'll have to change my position.
IF not, then I consider support for such forward
references in MIB compilers as a gratuitous
feature with (modestly) less than benign value.

>If it makes you feel any better, my implementation generates SMI modules
>with assignments in order of increasing OID for compatibility with those
>that don't support forward references.  That helps with the 'b' before 'a'
>issue, but doesn't get you anywhere with circular references.

It does make me feel much better.
I don't think we need or want to get anywhere
with circular references unless there is a
real need for them in real MIBs.

>As a postscript, and likely another contrived example, I'll mention a that
>not too long ago there was some discussion about whether or not it was
>legal to, for example, have an OBJECT-TYPE defined under the OBJECT-GROUP
>in which it is contained.  Consensus was that it is legal, but not a
>particularly good idea for several reasons.

In "technologies" like SNMP and the SMI in
which the protocol and grammar rules might
not be fully specified, the best approach to
"conventioneering" -- i.e., implementation
agreement type conventions -- is to adopt
the most conservative approach wrt things
which are "not a particularly good idea".

>Now, I don't know of any
>modules offhand that do this, so you can consider it a contrived example
>if you wish, but that would tend toward forward references (and, of
>course, a "circular" example, because I believe "circular" is a
>requirement to meet your definition of a forward reference).

"Circular" is a requirement to meet my definition
of the case in which a forward reference may be
unavoidable.  All other forward references (which
impact naming hierarchy) can be avoided through
better MIB design (where better means consistent
with naming hierarchy).  I doubt that any circular
forward references are required for real MIBs.

Cheers,

BobN