Some additional obscure questions...

[Michael Kirkham <mikek@muonics.com>]

1. Various macro productions that specify ObjectName (or similar) can
technically accept either a descriptor or an object identifier value,
although tools that only accept an identifier are not uncommon.  Of those
that accept object identifier values, there seems to be some disagreement
on the form.  Take, for example, the 'ObjectsPart' production of the
NOTIFICATION-TYPE macro:

    ObjectsPart ::=
                  "OBJECTS" "{" Objects "}"
                | empty
    Objects ::=
                  Object
                | Objects "," Object
    Object ::=
                  value(ObjectName)

I believe the proper form, if one were to specify object identifier values
instead of descriptors, would be (just for example):

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?


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
    ;

Currently I accept it (although it takes some creative restructuring of
the ASN.1 SymbolsFromModule productions to avoid shift/reduce conflicts).
Assuming this is legal, however (as I believe to be), it raises some
additional issues:

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.

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.

Appologies in advance if this makes anyone else's head hurt.  :)

--
Michael Kirkham
www.muonics.com