Re: consensus call sect 4.4

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

HI,

The consequence of this has not been fully explored and described. 
Until this has been done it is inappropriate to go forward with
the below recommendation.

There have been other recent attempts at "clarifications" of the
MIB module language, that appear to me to not consider the consequences,
and look at such clarifications in isolation instead of a wholistic
unified view. Is is a disturbing trend.
 
Please note that I do respect the tremendous amount of effort that has
been put into the guidelines documents by Mike Heard. And I'm sorry
that I do not have the time to further support his effort with detailed
comments on the consequences (including interactions) with the suggestions.
I've been quite disappointed with some examples that have been used
for clarifications.

I feel great sympathy with the clarification effort, since I too over
ten years ago worked on clarifying the SMI. My effort was to make sure
that the SMI was complete, self-consistent, in addition to being
comprehensible. In many cases, there were "rules" that were "oral
traditions", or were incorrect interpretations of ASN.1. Many of the
details and interpretations were never included in the SMI because
"everyone knew these". Now, there is a "new generation" that are
trying to use the SMI that didn't participate in the IETF and
don't understand the interpretations, and have only the text of
the SMI. And when reading the SMI text, are coming to different
interpretations. I'm troubled by the legalistic approach instead
of spending energy on addressing real limitations found in
the SMI such as the missing data types of Int64, Uint64, and
discriminated union. Adding support for some of the "clarifications"
may require more effort than adding support for new features
that address the limitations of the SMI.

That is, I believe that an SMI v2.1 is needed that incorporates
Mikes work and adds support that addresses current SMI limitations.

At 04:45 PM 2/5/2003 +0100, Wijnen, Bert (Bert) wrote:
>In the new guidelines doc by Mike Heard, we see
>
>   4.4.  IMPORTS Statement
>
>   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 that 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.
>
>   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.  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.  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.
>
>   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.
>
>I would prefer to change the MAY in the line prefixed with -> 
>in a RECOMMENDED (which is basically the same as a SHOULD, but 
>yet sounds more relaxed). I would like to see if we have (rough)
>conensus on this. Can all members of this mreview list pls make 
>their opinion known.
>
>Thanks,
>Bert 
Regards,
/david t. perkins