[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidelines Section 4.6.1.6 (BITS construct)



On Wed, 5 Feb 2003, C. M. Heard wrote:
> 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.  [Note, however, that it is not necessary for
> named bit positions to be non-contiguous even if one wishes to
> allocate newly-defined bits on an octet boundary;  one need only
> provide names for unused positions.]  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) }

On Wed, 5 Feb 2003, Juergen Schoenwaelder replied:
> The only way to allocate new bits safely is on new byte boundaries.
> 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.
> 
> 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'.

On Wed, 5 Feb 2003, C. M. Heard wrote:
> But, do we want to say this is RECOMMENDED, or would that be another
> unwelcome CLR?

Since I've not heard anything pro or con, I'll just propose the
following very minimal change to the existing text to bring it
into  compliance with RFC 2578:

   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
   SHOULD be contiguous.

i.e, s/MUST be contiguous/SHOULD be contiguous/

//cmh