RE: consensus call sect 4.4

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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.


Thanks,
Bert 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: woensdag 5 februari 2003 18:18
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: Re: consensus call sect 4.4
> 
> 
> 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 
>