Re: Alternative procedure for updating MIB modules

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Wednesday, June 02, 2004 11:43 PM
> Subject: Re: Alternative procedure for updating MIB modules
>

> 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.

But it doesn't provide a way to say where they're planned / expected.
"TruthValue" is a very different beast from, say, "ModulationScheme".

> 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.
...

I'm just saying that having an explicit marker to identify where extensions
are expected would make it even easier, allowing the addition to be
made in a revision of the document, without causing slippage along
the standards track, and without requiring an IANA-maintained module.

There are cases (e.g. IfType) where the IANA-maintained registry is
the right thing to do.  There are others, e.g, "ModulationScheme",
where it would be serious overkill, and it would make more sense
to be able to do the update "in-line" without derailing it from the
standards track.

Randy