Re: Some additional obscure questions...

["David T. Perkins" <dperkins@dsperkins.com>]

HI Michael,

As an "old-timer" on the SMI, I appreciate your "searching for the truth".
But, on the other hand, it appears to me (and maybe to others), that in
your zeal to find the truth, you are being more concerned with legalistic
aspects of parsing small pieces of the SMI and ASN.1 definitions than
understanding the intent of the documents. Also, there is the balancing
of the "current practices" with the text in the definitions. After all,
the definitions are suppose to be the codification of existing
practices, and not the other way. Finally, it appears to me that
it would be more helpful if you were to describe the consequences
(the first, second, third, etc order affects) of alternative 
interpretations. 

The interpretation of the semantics of the IMPORTS clause is
difficult because there are dependences, and they affect the
strategy that would be taken in writing a MIB parser.

Please note, and I'm sorry if it sounds like a broken record,
that the MACRO definitions in the SMI are NOT valid ASN.1. Once
you understand this, then I believe that it makes understanding
the SMI easier. Also key in understanding the SMI, is that there
were some misunderstandings of ASN.1 by the original authors of
the SMI, and the editors of the current SMI tried to find the
proper balance between a "total rewrite" and just "typographical"
fixes. I believe that the current SMI is quite a bit more
1) complete, 2) unambiguous, and 3) self-consistent than earlier
versions. However, there are still problems with the text of the
current SMI. Where those problems are identified, it would
most benefit the community of users of the SMI to document
the problems and provide alternative fixes with the consequences
of those fixes. 
 
At 10:47 AM 1/29/2003 -0800, Michael Kirkham wrote:
>On Wed, 29 Jan 2003, Randy Presuhn wrote:
>
>> > IMPORTS
>> >     someObjectIdentity
>> >         FROM XYZ-MIB xyzMIBidentity
>> >     someObjectIdentity
>> >         FROM ABC-MIB abcMIBidentity
>> >     ;
>>
>> (I assume that by xyzMIBidentity you mean the object identifier value
>> for that module, and not just the valuereference.)
>
>I actually did mean just the valuereference.  In my poking around various
>discussions about ASN.1 a while back, looking to resolve various grey
>areas in the specs (both SMI and ASN.1 in general), I came across some
>notes from other folks who support this (though I believe it might have
>been an actual ASN.1 discussion, not an SMI discussion.  But where the SMI
>is silent, I tend to assume ASN.1 rules apply.)
>
>> > 3. What if you have a situation where both 'XYZ-MIB' and 'ABC-MIB' not
>> > only contain definitions called 'someObjectIdentity' that you are
>> > importing, but their MODULE-IDENTITY statements also happen to have the
>> > same descriptors?  Certainly, then, just specifying the MODULE-IDENTITY
>> > descriptors doesn't succeed in removing ambiguity, so you would need to
>> > specify a sufficient number of components to do so.
>>
>> Actually, I think the obnoxious case is the other way around: the two MIBs
>> have the same module name, so the only way to distinguish them would
>> be to reference them by object identifier value in ASN.1, but we've kinda
>> precluded that anyway.
>
>Right.  Sorry to not be clear: the XYZ-MIB and ABC-MIB I'm talking about
>here are what they are being called locally, in the above IMPORTS
>statement, instead of their actual module names.  So in reality what I'm
>talking about in 3. here is a situation where one module wants two import
>the same descriptor from two other, different modules that have the same
>name AND the same descriptor for their MODULE-IDENTITY statements.
>That's a *really* obnoxious case, though not a problem if only absolute
>OIDs are allowed instead of the MODULE-IDENTITYs' descriptors.
>
>> Though this might be a useful extension to the SMI, I think the language as
>> described in RFC 2578 doesn't support it.
>
>I think the language described in RFC 2578 doesn't really talk about it.
>I'm inclined to believe it's legal in ASN.1, but it's tough to choose
>between "SMI is silent, so follow ASN.1" or "SMI is silent, so ignore
>ASN.1 completely".  (These choices would all be much clearer if the SMI
>specs were fully self-contained.)
>
>--
>Michael Kirkham
>www.muonics.com


Regards,
/david t. perkins