[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some additional obscure questions...
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.)