Re: Some additional obscure questions...

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

Hi -

> From: "Michael Kirkham" <mikek@muonics.com>
> To: <mibs@ops.ietf.org>
> Sent: Wednesday, January 29, 2003 6:29 AM
> Subject: Some additional obscure questions...
...
> OBJECTS { { 1 2 3 4 1 } , { 1 2 3 4 2 } , { 1 2 3 4 3 } }
>
> ...that is, braces around each value corresponding to an 'Object' in the
> above productions.
>
> However, some apparently expect no braces, e.g.:
>
> OBJECTS { 1 2 3 4 1 , 1 2 3 4 2 , 1 2 3 4 3 }
>
> The former (with braces) is the correct form, and the latter is illegal,
> yes?

Agreed.

> 2. Disambiguating IMPORTS continued:  when specifying a MODULE-IDENTITY in
> the FROM module, so that elsewhere in the module you can use the
> ModuleReference.TypeReference or ModuleReference.ValueReference forms, is
> it legal for the MODULE-IDENTITY to be referenced by descriptor, rather
> than OID?  e.g.:
>
> 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 think this would not be supported by the SMIv2 notation.
RFC 2578 *seems* to limit IMPORTS where it says:

|3.2.  IMPORTing Symbols
|
|   To reference an external object, the IMPORTS statement must be used
|   to identify both the descriptor and the module in which the
|   descriptor is defined, where the module is identified by its ASN.1
|   module name.

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

> 4. So if that's not obscure enough for you, what if not only the two
> MODULE-IDENTITYs have the same descriptor, but the OIDs they are each
> subordinate to -also- have the same descriptor, but each of those are
> defined in other modules such that they can be resolved unambiguously
> using the ModuleReference.ValueReference form.  Is it legal to use this
> form in specifying the OID for the MODULE-IDENTITYs?  e.g.
>
> IMPORTS
>    xyzIdentityParent
>       FROM ONE-MIB oneMIBidentity
>    xyzIdentityParent
>       FROM TWO-MIB twoMIBidentity
>    someObjectIdentity
>       FROM XYZ-MIB { ONE-MIB.xyzIdentityParent 123 } -- xyzMIBidentity
>    someObjectIdentity
>       FROM ABC-MIB { TWO-MIB.xyzIdentityParent 456 } -- xyzMIBidentity
>    ;
>
> I assume so.  Though it's awefully obscure and probably neither I nor my
> users will ever run into it, I'd still like to be as strictly compliant as
> possible.
...

Though this might be a useful extension to the SMI, I think the language as
described in RFC 2578 doesn't support it.

Randy