Re: Guidelines Section 4.6.1.6 (BITS construct)

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

On Wed, 5 Feb 2003, Wijnen, Bert (Bert) wrote:
> [Michael Kirkham wrote:]
> > |   The BITS construct is described in RFC 2578 Section 7.1.4.  It
> > |   represents an enumeration of named bits.  The bit positions in a TC
> > |   or object definition whose SYNTAX is of this type MUST start at 0 and
> > |   MUST be contiguous.
> > 
> > This seems to be counter to the last part of paragraph 2, which suggests
> > adding new bits starting at the next octet during an update of a MIB
> > module.  Perhaps what you mean to say is that they MUST be contiguous in
> > newly defined (ie., first-publication) modules?
> > 
> I think 2578 allows for some unused bits when one extends the enumerations
> with a few more bits.

Hmm, maybe it does.  I'd always read that a little differently.

Here is the text of Section 7.1.4, with my annotations:

   The BITS construct represents an enumeration of named bits.  This
   collection is assigned non-negative, contiguous (but see below)
   values, starting at zero.  Only those named-bits so enumerated may be
   present in a value.  (Thus, enumerations must be assigned to
   consecutive bits; however, see Section 9 for refinements of an object
   with this syntax.)

So far, this is what the guidelines doc parroted.  Probably we
should ban parrots in this business because they have ugly voices
and distort what they repeat, but Bert asked me to say something.

   As part of updating an information module, for an object defined
   using the BITS construct, new enumerations can be added or existing
   enumerations can have new labels assigned to them.  After an
   enumeration is added, it might not be possible to distinguish between
   an implementation of the updated object for which the new enumeration
   is not asserted, and an implementation of the object prior to the
   addition.  Depending on the circumstances, such an ambiguity could
   either be desirable or could be undesirable.  The means to avoid such
   an ambiguity is dependent on the encoding of values on the wire;
   however, one possibility is to define new enumerations starting at
   the next multiple of eight bits.  (Of course, this can also result in
   the enumerations no longer being contiguous.)

The part about changing enum labels is flatly WRONG as it breaks
compilation compatibility, and the guidelines doc says "don't do
that" in Section 4.9.  As for the last two sentences, I had taken
them as informative text, since they are suggesting possibilities,
while the first paragraph is normative.  Thus, in rev 1 one might
have this:

   SYNTAX BITS { los(0), lof(1), ais(2), aisCI(3),
                 rai(4), raiCI(5) }

while rev 2 might look like this:

   SYNTAX BITS { los(0), lof(1), ais(2), aisCI(3),
                 rai(4), raiCI(5), unused1(6), unused2(7),
                 muxFault(8) }

i.e. names are given to the unused bit positions.

If this is not what it's supposed to mean, then the
restriction in the 1st paragraph is inoperative as far
as a MIB compiler is concerned, because it can't tell
if it's dealing with a new definition or a revised one.
And such a distinction is really arbitrary anyway.  So
in that case we ought to consider the rule in the first
paragraph to be another CLR, stop enforcing it in MIB
reviews, and fix MIB compilers to stop complaining
about it.  I never really understood the reason for
this rule anyway.

//cmh