[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: consensus call sect 4.4
So what do you say?
- Do not do section 4.4 as is
- Do not do it with my suggested change
- Do not do the doc at all in its current form
Dave, pls be clear instead of long enmails.
> -----Original Message-----
> From: David T. Perkins [mailto:firstname.lastname@example.org]
> Sent: woensdag 5 februari 2003 18:18
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: Re: consensus call sect 4.4
> 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
> 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
> > 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.
> /david t. perkins