[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some additional obscure questions...
HI,
On the below, it looks like you guys are tripping up on terminology and
ASN.1 vs MIB modules. The examples below should say it all.
In ASN.1 modules....
-- module 1
MyModule { 0 0 99999 1} DEFINITIONS ::=
BEGIN
...
a ... ::= { foo 1 }
END
-- module 2 (different from module 1)
MyModule { 0 0 99999 2 } DEFINITIONS ::=
BEGIN
...
a ... ::= { bar 1 }
END
AnotherModule { 0 0 99999 3 } DEFINITIONS ::=
BEGIN
IMPORTS
a FROM M1 { 0 0 99999 1 }
a FROM M2 { 0 0 99999 2 }
...
;
...
b1 ... ::= { M1.a 1 }
b2 ... ::= { M2.a 1 }
END
In MIB modules...
-- module 1
MyModule DEFINITIONS ::=
BEGIN
IMPORTS
...
;
myModule MODULE-IDENTITY
...
::= {0 0 99999 1}
...
a ... ::= { foo 1 }
g OBJECT-GROUP
...
::= { ... }
END
-- module 2 (different from module 1)
MyModule DEFINITIONS ::=
BEGIN
IMPORTS
...
;
myModule MODULE-IDENTITY
...
::= {0 0 99999 2}
...
a ... ::= { bar 1 }
g OBJECT-GROUP
...
::= { ... }
END
AnotherModule DEFINITIONS ::=
BEGIN
IMPORTS
a FROM M1 { 0 0 99999 1 }
a FROM M2 { 0 0 99999 2 }
...
;
anotherModule MODULE-IDENTITY
...
::= {0 0 99999 2}
...
b1 ... ::= { M1.a 1 }
b2 ... ::= { M2.a 1 }
ac AGENT-CAPABILITIES
...
SUPPORTS M1 { 0 0 99999 1 }
INCLUDES { g } -- note: no qualification with module ID
...
SUPPORTS M2 { 0 0 99999 2 }
INCLUDES { g } -- note: no qualification with module ID
...
::= { ... }
mc MODULE-COMPLIANCE
...
MODULE M1 { 0 0 99999 1 }
MANDATORY-GROUPS { g } -- note: no qualification with module ID
...
MODULE M2 { 0 0 99999 2 }
MANDATORY-GROUPS { g } -- note: no qualification with module ID
...
::= { ... }
END
If the above didn't clarify all the questions, ask again with a specific
question using the examples.
And note about the "macro defintions" for ACs and MCs in RFC 2580,
ASN.1-1988 does not allow module references to be specified in a
macro definition, so we had to fake it (and our fake is not valid)!
That is, ASN.1 macros only allow you to specify type references or
value references for macro variables, and not module references.
(Nobody ever said that the ASN.1 macros in the SMI were valid!)
At 06:47 PM 1/30/2003 -0800, Michael Kirkham wrote:
>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
Regards,
/david t. perkins