[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:
> >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
> Anything short of MUST simply points out our acceptance
> of lax approaches to following both the spirit and the
> letter of the SMI, IMHO...going as far as "MAY or MAY NOT"
> (which is what "MAY" means) is really stretching things.
Section 5.4.3 paragraph 2, and 6.5.2 paragraph 3, explicitly state that
the 'OBJECT' and 'VARIATION' references typically follow a MODULE or
SUPPORTS reference and thus state that importing the referenced
objects/notifications in IMPORTS is redundant (of course, only redundant
if the MODULE/SUPPORTS specifies a module other than the one that contains
the conformance statement).
My feeling is that it was likely oversight/accidental omission that only
these items need not be imported. If an implementation is capable of
dealing with OBJECT/VARIATION clauses that reference items that are not
explicitly imported at the beginning of the module (as it should), then
most likely it would be capable of dealing with group and type references
just as easily.
The reality is that many tools don't do anything with conformance
statements beyond parsing them for syntax errors. Of those that do, some
have problems. This issue seems to me to be one of whether or not IETF
MIBs should cater to the limitations of some implementations or not.
My opinion is that it should be left as a neutral 'MAY'. I would even go
as far as to say that requiring some to be imported but not others
qualifies as a CLR that should be relaxed, as I think that is much more in
the spirit (but not the letter) of RFC 2580, but that could be just me.
I already outlined my conceptual reasons for this to Mike Heard prior to
the -00 version, but I could summarize the discussion here if desired.