Re: Importing items used in MODULE-COMPLIANCE and AGENT-CAPABILITIES

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Importing may help some MIB compilers, and may cause other problems.

Consider the following...
A DEFINITIONS ::= BEGIN
...
 g1 OBJECT-GROUP
 ...
END

B DEFINITION ::= BEGIN
...
 g1 OBJECT-GROUP
END

C DEFINITIONS ::= BEGIN
IMPORTS
  g1 ... FROM A  -- is these two together going to mess up MIB compilers?
  g1 ... FROM B
 ...

  g1 OBJECT-GROUP
   ...


m1 MODULE-COMPLIANCE
 ...
 MODULE MANDATORY-GROUPS { g1 }
   ...
 MODULE A MANDATORY-GROUPS { g1 }
   ...
 MODULE B MANDATORY-GROUPS { g1 }
   ...
END

Check the above out and see what happens.

For MIB compilers that simply skip over the MODULE-COMPLIANCE and
AGENT-CAPABILITIES, leaving out the IMPORTS is a big win!

At 03:58 PM 12/6/2002 -0800, C. M. Heard wrote:
>Howdy,
>
>Thanks to all who have responded, both on and off list, to the draft
>MIB review guidelines that I posted before the IETF meeting.  I'm still
>travelling but I shall start working on a new version of the draft
>when I get back home next week to address the comments.
>
>In the meantime there is one comment that I received from Dave Perkins
>that I'd like to get other opinions on:
>
>On Mon, 18 Nov 2002, David T. Perkins wrote:
>> [ ... ] there is that little item about importing
>> items used in MODULE-COMPLIANCE and AGENT-CAPABILITIES
>> that I very much disagree with.
>
>The item in question is this:
>
>   Although exemptions to this general requirement are granted by RFC
>   2580 Sections 5.4.3 and 6.5.2 for names of objects appearing in the
>   OBJECT clause of a MODULE-COMPLIANCE macro invocation or in the
>   VARIATION clause of an AGENT-CAPABILITIES macro invocation, it is
>   nonetheless RECOMMENDED by these guidelines that such symbols be
>   included in the module's IMPORTS statement.  There are two reasons
>   for this.  One is that these special rules are somewhat obscure and
>   may not be implemented by all MIB compilers, especially since RFC
>   2580 has no analogous rules for names of notifications referenced
>   by a VARIATION clause nor for names of object groups or notification
>   groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or a
>   SUPPORTS clause.  The other reason is that including these items
>   helps to make dependencies on other modules obvious from looking at
>   the IMPORTS statement.
>
>The "general requirement" in questions is that if an external symbol
>other than a predefined ASN.1 type or the BITS construct is used,
>then it MUST be mentioned in the module's IMPORTS statement.
>
>I'd like to hear other opinions about this.  I don't know of any
>precedents in published MIBs, but there is currently a Hubmib draft
>(http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-04.txt)
>where this issue will arise.  The nearest thing that I know of in a
>published MIB is in the inverted stack table MIB in RFC 2864, which
>imports a group from the IF-MIB but does not have any OBJECT clauses
>relevant to members of that group.
>
>Mike
Regards,
/david t. perkins