Re: MODULE COMPLIANCE

["C. M. Heard" <heard@pobox.com>]

On Tue, 7 Jan 2003, David T. Perkins wrote:

> On the below, the object would be in an included group. And while
> "legal", it is incompatible with standard track documents.
> In standards tract documents there MUST NOT be any "completely
> optional" portions.

I don't think that's true.  The requirement (in general) is that
prior to advancement on the standards track any optional features
must either be present in two interoperable, genetically unrelated
implementations or else removed from the spec.

I think the way that this requirement would be applied in the
following case is that if two implementations did not include
ihfLastChanged (with a correct value) in some view that could
be seen in a MIB dump (cf. Basic Object Comparison test in
BCP 27 / RFC 2438) then the object would have to be deprecated
or obsoleted before the MIB module could advance.

> At 09:03 PM 1/7/2003 +0100, Wijnen, Bert (Bert) wrote:
> >In document draft-ietf-ipsp-ipsec-conf-mib-05.txt
> >
> >I see in the MODULE-COMPLIACNE things like:
> >
> >          OBJECT      ihfLastChanged
> >          MIN-ACCESS  not-accessible
> >          DESCRIPTION
> >               "This object not required for compliance."
> >
> >I don't think I have seen this ever before
> >
> >Do we believe that that is the proper way do this?

The usual practice is to put the object into an unconditionally
optional group, but as Dave says above, this is legal.  It may
be unusual, but I can't see any problem with it.

Mike