Re: Alternative procedure for updating MIB modules

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

On Sat, 29 May 2004, Randy Presuhn wrote:
> > From: "Andy Bierman" <abierman@cisco.com>
> > To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > Cc: "Mreview (E-mail)" <mreview@ops.ietf.org>
> > Sent: Tuesday, May 25, 2004 8:32 AM
> > Subject: Re: Alternative procedure for updating MIB modules
> ...
> > IMO, the ability to add enumerations over time to an object or TC is
> > mandatory to support an evolving MIB base.  We need to adjust
> > the SMI, or the CLRs, or whatever, so the standards process
> > doesn't get in the way of this requirement.
> ...
> 
> Yes!  To avoid chaos, perhaps we could borrow from ASN.1 and
> provide an "extensibility marker" that indicates that additions to an
> enumeration are expected.

In effect, SMIv2 implicitly provides such a marker for _all_ enumerated
INTEGER and BITS objects, since it allows for enumerations or named
bits to be added.

The problem is not really an SMI problem;  it is that there is a
procedural hassle in opening up a document to add enum value or
named bits unless the data type definition was previously factored
out into an IANA-maintained TC.  The incremental update procedure
mitigates this hassle.

An alternative to the incremental update procedure would be to
allow an enum or BITS type that needed updating to be factored
out into an IANA-maintained module without prejudicing the
status of the document on the standards track.  Since we aready
allow enums to be added while a document is advancing (provided
that we don't change actual complicance requirements), I can see
no real reason not to allow this.

Mike