RE: Guidelines Section 4.6.1.6 (BITS construct)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

WFM (Works for me)

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zondag 16 februari 2003 0:22
> To: Mreview (E-mail)
> Cc: Michael Kirkham
> Subject: 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
> 
>