Re: Alternative procedure for updating MIB modules

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

Hi -

> 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.  We've also run into cases where
ranges were over-specified, causing problems with later technology.
(An imaginary example would be limiting the options for modem
speed as 75, 110, or 300 baud, ignoring the possibility that 1200
baud modems might someday be invented.)  Currently the antidote
to this kind of over-specification is extreme under-specification
(e.g., saying that baud rate is a positive integer) rather than permitting
the addition of discrete values to the value set.

I also agree with Mike that publishing the complete updated module
should be a MUST.  Piecing MIB modules together from deltas is a
bit too bewildering for non-experts.

Randy