[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Importing items used in MODULE-COMPLIANCE and AGENT-CAPABILITIES
- To: "Mreview (E-mail)" <mreview@ops.ietf.org>
- Subject: Importing items used in MODULE-COMPLIANCE and AGENT-CAPABILITIES
- From: "C. M. Heard" <heard@pobox.com>
- Date: Fri, 6 Dec 2002 15:58:09 -0800 (PST)
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