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

["C. M. Heard" <heard@pobox.com>]

Since the discussion of this issue did not lead to consensus,
I've reworked the discussion of this matter to use the neutral
MAY instead of RECOMMENDED.  Here is the reworked Section 4.4:

   RFC 2578 Section 3.2 specifies which symbols must be imported and
   also lists certain pre-defined symbols that must not be imported.

   The general requirement 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.  The words "external
   object" in the first paragraph of this section may give the
   impression that such symbols are limited to those that refer to
   object definitions, but that is not the case, as subsequent
   paragraphs should make clear.

   Although exemptions to this general requirement are granted by RFC
   2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
   the OBJECT clause of a MODULE-COMPLIANCE statement or in the
   VARIATION clause of an AGENT-CAPABILITIES statement, these symbols
   MAY nonetheless be included in the module's IMPORTS statement.  MIB
   module authors and reviewers need to be aware that RFC 2580 does NOT
   exempt other external symbols referenced by MODULE-COMPLIANCE and
   AGENT-CAPABILITIES statements from appearing in the module's IMPORTS
   statement.  Thus, descriptors of externally-defined notifications
   referenced by a VARIATION clause and descriptors of externally-
   defined object groups and notification groups referenced by a
   MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause are
   technically required to be listed in the IMPORTS statement.
   Including the descriptors of objects makes the treatment consistent.

   Finally, even though it is not forbidden by the SMI, it is considered
   poor style to import symbols that are not used, and "standard" MIB
   modules SHOULD NOT do so.

OK, now poke sticks at it.

//cmh