Re: Alternative procedure for updating MIB modules

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

On Wed, 2 Jun 2004, Randy Presuhn wrote:
> > > 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".

That's true.  One thing that could be done would be to put some text
in the DESCRIPTION clause of the TC or object definition indicating
whether or not future extension of the values is allowed.

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

I think we already allow that.  For an example see RFC 3592 ...
enumerations sts192cSTM64(6) and sts768cSTM256(7) were added to the
repertoire of sonetPathCurrentWidth in the transition from PS to DS.
(Based on this I'm not sure why the HC-RMON additions to RMON-1
weren't folded into RFC 2819/STD 59 ... I think they showed up at
more-or-less the same time).

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

I don't think that the problem is derailing the document from the
standards track, but rather the fact that republishing the whole
document is a hassle.  If we made that easier to do, then maybe the
motivation to do incremental updates would be removed.

Mike