Date: Wed, 10 Oct 2001 21:02:43 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
To: MIBS Mailing List <mibs@ops.ietf.org>,
        RMONMIB Mailing List <rmonmib@ietf.org>
Subject: Re: Last Call: Remote Network Monitoring Management Information Base
 for High Capacity Networks to Proposed Standard
In-Reply-To: <3BC4C204.D732AF63@nextbeacon.com>
Sender: owner-mibs@ops.ietf.org
Precedence: bulk

On Wed, 10 Oct 2001, Steve Waldbusser wrote:

> I agree that it's necessary to update the conformance statements for
> RMON and RMON2 and I agree that the OBJECT clause is the proper way to
> do it.
>
> But we need to do it a bit differently than suggested. Here's why:
>
> A vendor that has claimed conformance to (say) rmon2MIBCompliance in the
> past should continue to be able to claim conformance to
> rmon2MIBCompliance even after this event, as conformance requirements
> for RMON2 have not changed. It shouldn't become suddenly non-conformant
> to rmon2MIBCompliance.
>
> Therefore we should update the existing compliance statements with the
> OBJECT clause rather than add the modified compliance statements and
> deprecate the old ones.

I agree with this.  The addition of the OBJECT clause has the effect
of preserving the original semantics in the presence of the added enum
values.  Therefore the descriptor and OID for the MODULE-COMPLIANCE
invocation need not and should not change.  My suggestion to obsolete
the original compliance definition was incorrect.

This raises an issue with RFC 2580.  Specifically, Section 7.2,
Compliance Definitions, should -- but does not -- require that
appropriate OBJECT clauses be added (if not already present) to
a compliance definition when enumerated INTEGER objects or BITS
objects that are referenced by the compliance definition have new
enumerations added, because that is the only way to avoid changing
the requirements specified by that definition.  As matters now
stand, only revisions to the STATUS clause, addition or
revision of a REFERENCE clause, clarification of the DESCRIPTION
clause, and editorial changes are mentioned.  (Interestingly, this
same problem is recognized for capabilities definitions in Section
6.5.2.1 but is not mentioned in Section 7.2 or 7.3.)

Perhaps Frank Strauss or Juergen Schoenwaelder could add this
to the unofficial SMIv2 errata list at TU Braunschweig?

Thanks,

Mike