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

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

On Fri, 6 Dec 2002, David T. Perkins wrote:
> Take a step back. The reason for the recommendation from Mike was to
> accommodate MIB compilers. I was trying to point out that one accommodation
> could result in other problems.

That was one of two reasons.  The other reason was that including these
items helps to make dependencies on other modules obvious from looking at
the IMPORTS statement.

> If a MIB compiler is written correctly and completely (which to me
> seems sort of strange, since SMIv2 does not subset), then we have
> no issue.

It's certainly true that if one's MIB compiler correctly implements all
of the SMIv2 rules then there is no need to recommend anything to help
circumvent bugs in the MIB compiler.  However, the rules for importing
items used in MODULE-COMPLIANCE and  AGENT-CAPABILITIES statements are
a rather strange case, because RFC 2580 does not exempt names of
notifications referenced by a VARIATION clause or names of object groups
or notification groups referenced by a MANDATORY-GROUPS clause, a GROUP
clause, or a SUPPORTS clause from the general requirement that if an
external symbol other than a predefined ASN.1 type or the BITS construct
is used then it must be imported.  The only exemptions provided are for
names of objects appearing in the OBJECT clause of a MODULE-COMPLIANCE
macro invocation (Section 5.4.3) or in the VARIATION clause of an
AGENT-CAPABILITIES macro invocation (Section 6.5.2).

It's probably an inadvertent omission in RFC 2580 that _only_ object names
used in these two contexts are exempted from the requirement to be in the
IMPORTS statement (see http://www.ibr.cs.tu-bs.de/ietf/smi-errata/), but
on the other hand the predecessor document RFC 1904 says exactly the same
thing.  So by a strict reading of the SMI documents, the "foreign" object
groups in the example presented by David Perkins DO need to be imported!

To my way of thinking, it's a violation of the robustness principle to
rely on a literal reading of rules that defy the expectations even of
experts.  Certainly SMIv2 allows object names to be imported even when
mentioned only in OBJECT or VARIATION clauses, and requires other items
mentioned in comformance statements to be imported if used;  what I an
recommending is that MIB authors err on the side of conservatism and
just mention everything used in conformance statements in the IMPORTS
statement.

On Fri, 6 Dec 2002, Randy Presuhn wrote:
> [ ... ] I believe the value in the RECOMMENDation is for
> humans, not compilers, despite the stated rationale, which
> I've already characterized as a red herring.  Just try explaining
> to a human why no IMPORT is needed for items in a MODULE-COMPLIANCE
> or AGENT-CAPABILITIES construct, but is needed in the case of
> things like "modulename.typereference"  Taking our quirky
> notation as a given, the least we can do is help people write
> more-or-less human-readable specifications using it.

Do you still think so, given that the actual situation is that no
import is needed for some, but not all, items in a MODULE-COMPLIANCE
or AGENT-CAPABILITIES construct?  Or does the rationale I originally
gave make more sense to you now?

> (I'd also argue that any compiler that depends on or tries
> to enforce the recommendation has a bug.)

Actually, SMICng (at least in the now-obsolete book version) had an
optional switch that caused it to flag items in MODULE-COMPLIANCE
and AGENT-CAPABILITIES statements that were not imported.  I have
always used that switch and continue to recommend its use in
Appendix C of the draft guidelines.

Regards,

Mike