Re: Guidelines Section 4.6.1.6 (BITS construct)

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

On Wed, 5 Feb 2003, Juergen Schoenwaelder wrote:
> The only way to allocate new bits safely is on new byte boundaries.

Not necessarily.  It all depends on what kind of object you have.
One common use of BITS is as a read-only "capabilities" vector
(cf. ifMauTypeListBits in the MAU-MIB), in which case allocating
the bits contiguously even across several revisions is just fine.
An old manager dealing with a new agent might, or might not, see
that extra bits exist.  It would if (a) any previously unused bits
in an existing byte were set or (b) the length increased (which would
happen if things crossed a byte boundary).  In any case, the only
sensible thing the manager can do is to ignore extra bits, as they
pertain to capabilities it does not know about.  Similar considerations
apply to read-only status objects of BITS types.

In cases where there is a read-write object, the only sensible design
(IMnsHO) is (a) clearly specify a convention in the DESCRIPTION clause 
for what value should be written to any bit to guarantee that no
unintended action takes place, and (b) on the manager side, always do
a read followed by write, so that you can adapt to the length expected
by the agent, and use neutral values for the bits you don't know about.
Wes Hardaker suggested this on the mibs@ops.ietf.org list a while ago.

> This was brought up during the SMIv2 to full standard revision. Since
> the previous SMIv2 language said bits must be contiguous (one of the
> few cases where I indeed agree this is a CLR) and some people found
> this particular rule important (or too late to change it), we ended up
> saying bits have to be contiguous and at the same time telling people
> that they won't be continuous if you update a MIB module correctly.

Sigh.  Compromises often fail to make sense.  It would have been
better just to repeal the rule that bits need to be contiguously
allocated.  But, as I said above, I'm not convinced that "the only
way to allocate new bits safely is on new byte boundaries."  It
depends on the nature of the object, and I think that it can always
be made safe with proper object design.  One thing that would be
helpful for me, since I don't remember the reasons for the "allocate
on byte boundaries" rule, would be to point me to the relevant mailing
list archive (or else recite from your memory).

> Sure, naming the unused bits as you have done above is a good way out
> of this strange dilemma and I like this very much - perhaps 'dontuse'
> is even better than 'unused'.

But, do we want to say this is RECOMMENDED, or would that be another
unwelcome CLR?

> I agree that compilers should not complain about non-contiguous named
> bits and I hope smilint does not...

It doesn't.  But it issues warnings for out-of-order enumerations.

//cmh