Re: Some additional obscure questions...

[Michael Kirkham <mikek@muonics.com>]

On Thu, 30 Jan 2003, Randy Presuhn wrote:

> Hi Mike -
>
> The value of the MODULE-IDENTITY macro is *not* the same
> thing as the object identifier that names an ASN.1 module.
> See RFC 2578 clause 5:
>
> |   Note that reference in an IMPORTS clause or in clauses of SMIv2
> |   macros to an information module is NOT through the use of the
> |   'descriptor' of a MODULE-IDENTITY macro; rather, an information
> |   module is referenced through specifying its module name.

Normally speaking, yes, it is obviously true that references to modules
are through the module's name.  However, saying "the value of the
MODULE-IDENTITY macro is *not* the same thing as the object identifier
that names an ASN.1 module", while literally true, may be a little
misleading:

   The value of an invocation of the MODULE-IDENTITY macro is an OBJECT
   IDENTIFIER.  As such, this value may be authoritatively used when
   specifying an OBJECT IDENTIFIER value to refer to the information
   module containing the invocation.  [RFC 2578 section 5.6]

Your statement mentions the MODULE-IDENTITY's value, but the paragraph you
quoted speaks of the MODULE-IDENTITY's descriptor.  Obviously this is
*illegal*:

IMPORTS a, b, c FROM someModuleIdentity;

But are you meaning to say that it is not the intent of the statement in
section 5.6 to allow the value of the MODULE-IDENTITY to be used in place
of a module's OID (which is forbidden in SMIv2) in 'SymbolsFromModule' to
disambiguate IMPORTS from modules with the same name?  e.g.

IMPORTS a, b, c FROM ABC-MIB { 1 2 3 4 ... };

...where { 1 2 3 4 ... } is the OID for the MODULE-IDENTITY contained in
the same module as assignments a, b and c, and ABC-MIB, which may or may
not be the actual name of the module, is the name it will be known as
locally for purpose of using "module.descriptor" form (if necessary
because the imported symbol is also otherwise ambiguous) within the
importing module?

I believe DP will agree with my that this is legal given several
discussions about exactly this over on comp.protocols.snmp recently.
Nothing in what I've been talking about was meant to imply that "FROM
someModuleIdentity" is legal in any way.  The discussion pertained to
accepted forms for the latter.  In ASN.1, the OID following "ABC-MIB"
would be that of the module its self, but as it is forbidden to assign an
OID to a module via the module header in SMIv2, the MODULE-IDENTITY's OID
takes its place.

Note that this is much more obvious in the MODULE-COMPLIANCE and
AGENT-CAPABILITIES macros:

    Module ::=
                  -- name of module --
                  "MODULE" ModuleName
                  MandatoryPart
                  CompliancePart

    ModuleName ::=
                  -- identifier must start with uppercase letter
                  identifier ModuleIdentifier
                  -- must not be empty unless contained
                  -- in MIB Module
                | empty
    ModuleIdentifier ::=
                  value(OBJECT IDENTIFIER)
                | empty

...and...

    Module ::=
                  -- name of module --
                  "SUPPORTS" ModuleName
                  "INCLUDES" "{" Groups "}"
                  VariationPart

    ModuleName ::=
                  -- identifier must start with uppercase letter
                  identifier ModuleIdentifier

Now, why would this be allowed for MODULE-COMPLIANCE and
AGENT-CAPABILITIES but not for IMPORTS, especially given recent
discussions regarding what can or must be included in a module's IMPORTS
in order to be used in the conformance statements?

--
Michael Kirkham
www.muonics.com