[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ops-mib-review-guidelines-01.txt is now available
On Tue, 25 Feb 2003, Bob Natale wrote:
>>[Mike Kirkham wrote:]
>>> >2.) No consensus was reached on making it RECOMMENDED to put
>>> >external items used by MCs and ACs in the IMPORTS statement, so
>>> >(for now) Section 4.4 retains the neutral "MAY" language.
>>>
>>> It should be a MUST...or an explanation as to why
>>> *these* external references are exempt from the
>>> otherwise clear requirement (citation given earlier
>>> in this thread) that *all* external references MUST
>>> be included in the IMPORTs statement.
>>
>>Specifying it as a 'MUST' would be contrary to the rules of RFC 2580
>>(see below).
>
>If you are referring to this part of 2580:
>
>"5.4.3. Mapping of the OBJECT clause
>...
> By definition, each object specified in an OBJECT clause follows a
> MODULE clause which names the information module in which that object
> is defined. Therefore, the use of an IMPORTS statement, to specify
> from where such objects are imported, is redundant and is not
> required in an information module."
>
>That is fine...it says that the MODULE clause is effectively an
>IMPORTS statement. No problem at all with that and it does not
>at all obviate or diminish the more general and prior guidance
>of 2578:
>
>"3.2. IMPORTing Symbols
>To reference an external object, the IMPORTS statement must be used to
>identify both the descriptor and the module in which the descriptor is
>defined, where the module is identified by its ASN.1 module name."
I guess it's a matter of opinion whether RFC 2580 Section 5.4.3 (and
also 6.5.2) obviate or diminish the general requirement of RFC 2578
Section 3.2. Certainly, they exempt certain specific symbols from
the requirement to be listed in the IMPORTS statement, and the third
paragraph of Section 4.4 of the guidelines draft says exactly that:
Note that 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.
The symbols exempted by RFC 2580 do not, however, include
notifications or groups, although the same "... is redundant"
rationale clearly applie to them. This is almost certainly an
oversight: the exemptions were added in the transition from RFC
1444 to RFC 1904 as a result of a proposal from Dave Perkins to the
SNMPv2 WG in 1995 which made no such distinction (see attached), and
that proposal was accepted by the "Woods Team" without further
discussion (as far as I can tell from the archives). This oversight
is documented as issue #2 on the errata list at
http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. All of the MIB
compilers that I know of either don't check IMPORTS at all or act
as if that oversight was not there, so the guidelines go on to say
Some MIB compilers also grant exemptions to descriptors of
notifications appearing in a VARIATION clause and to descriptors of
object groups and notification groups referenced by a MANDATORY-GROUPS
clause, a GROUP clause, or an INCLUDES clause, although RFC 2580
(through apparent oversight) does not mention those cases.
Some of the MIB doctors (see http://ops.ietf.org/mib-doctors.html)
felt that making exceptions to the general rule (import everything
that's not predefined by ASN.1) was not especially helpful and
thought that MIB module authors should be advised to include the
symbols used by MCs and ACs in the IMPORTS statement (this is
clearly allowed, even if it's not required). There was some strong
opposition that felt that exactly the opposite advice would be
appropriate (the guidelines _do_ say that _unused_ symbols SHOULD
NOT be imported). What resulted was the following compromise:
The exemptions are sometimes seen as unhelpful because they make
IMPORTS rules more complicated and inter-module dependencies less
obvious than they otherwise would be. External symbols referenced
by compliance statements and capabilities statements MAY therefore
be listed in the IMPORTS statement; if this is done, it SHOULD be
done consistently.
The upshot of the last "SHOULD" is to admonish people not to import
some symbols used in MCs or ACs but not others. Otherwise this is
just a restatement of the rules in the SMIv2 documents, modulo
correction of the (apparent) editorial oversight.
>For the record, at least from my perspective, this has nothing to
>do with "limitations of specific products" (honestly, I could not
>care less from a business perspective)...it has to do with having
>clear rules and following them, and where we don't have clear rules
>then agreeing to implementing things in an interoperable way that
>is consistent with the rules that we do have.
The text in the draft is supposed to do just that.
//cmh
--- Begin Message ---
Date: Mon, 9 Jan 95 00:27:37 PST
From: Dave Perkins <dperkins@synoptics.com>
To: bstewart@cisco.com, dperkins@synoptics.com
Subject: Imports for Agent-caps & Mod-compls
pr15: 1/8/95 - dtp
Item: Imports for Agent-caps & Mod-compls
Area: SNMPv2 SMI
Level: Clarification
Problem:
To be strictly ASN.1 compliant, imports must be
specified for all objects or object-groups specified
in agent-capabilities or module-compliance macros.
This specification is redundant, however, because
the items are specified within a MODULE or INCLUDES
clause. Thus there is no ambiguity. These redundant
specifications can double the size of the module if
contains only agent-caps and mod-compls macros.
Solution:
Change the SMI to specify the following extension
from ASN.1 for SNMP MIB modules:
Items used only in AGENT-CAPABILITIES and
MODULE-COMPLIANCE macros must not be specified
in the IMPORTS clause of the MIB module.
Implementation Impact:
None to agents and application writers,
trivial to MIB compiler writers.
--- End Message ---