Re: contiguous BITS question

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

This is an interesting question about should the realization
influence an abstraction. To make it more interesting,
consider a 16 bit unsigned integer value that is used
to encode a few bit values and a few unsigned int values.

For example, consider the following defines in C:

  uint16  my_status;
#define MYS_a 0x0001         /* field a - a single bit */
#define MYS_b_shf 1          /* field b - shift to put at low end */
#define MYS_b_msk 0x001f     /* field b - mask to isolate 5 bits */
#define MYS_c 0x0040         /* field c - a single bit */
#define MYS_d 0x0080         /* field d - a single bit */
#define MYS_e_shf 8          /* field e - shift to put at low end */
#define MYS_e_msk 0x003f     /* field e - mask to isolate 6 bits */
#define MYS_f_shf 14         /* field f - shift to put at low end */
#define MYS_f_msk 0x0003     /* field f - mask to isolate 2 bits */

So given the above realization, how would you define MIB objects?
Would it be 
 1) one, with SYNTAX value of UNSIGNED(0..'ffff'h)
 2) four, one to hold all the single bits with SYNTAX
     value of of BITS { a(0), c(1), d(2) }
     then UNSIGNED(0..'1f'h) - holds b
          UNSIGNED(0..'3f'h) - holds e
          UNSIGNED(0..'3'h) - holds f
 3) some other variant.


Back to the original question...
I'd either have "SYNTAX Unsigned32" or
BITS {delInProgress (0), adminDown (1), testing (2),
      res3(3), res4(4), res5(5), res(6), res(7), res(8),
      res(9), res(10) ... res(3), reflect(31) }

Note, the reason for the "interesting question",
is that in the future, the reserved portion of the below
may be carved up into fields that are not just one bit
wide. And when this happens, what should be done.

Note that one the question of "aren't the bit numbered
incorrectly?", it really depends if you look at the
original value as a fixed sized integer or an
array or bits. 

On Thu, 22 Sep 2005, C. M. Heard wrote:
> On Thu, 22 Sep 2005 jcucchiara@mindspring.com wrote:
> > One of the MIB modules that is being reviewed for GMPLS
> > gives the following error because the BITS are not contiguous.
> > I have requested that the authors change this, but they are
> > hesitant because the enum reflects the actual TLV object 
> > that this managed object represents:
> > 
> > >
> > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS
> > > must be in contiguous positions
> > >
> > >       SYNTAX  BITS {
> > >                      delInProgress (0),
> > >                      adminDown (1),
> > >                      testing (2),
> > >                      reflect (31)
> > >                    }
> > >
> > >
> > > RFC2578 specifies that BITS should be contiguous
> > > (although there are exceptions to this, but this
> > > object does not seem to be an exception).
> > 
> > 
> > Here is the TLV that the object represents:
> > 
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |R|                        Reserved                       |T|A|D|
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >       Reflect (R): 1 bit
> >       Reserved: 28 bits
> >       Testing (T): 1 bit
> >       Administratively down (A): 1 bit
> >       Deletion in progress (D): 1 bit
> > 
> > 
> > I would like to be sure before pursuing this issue with the
> > MIB authors, that the enum as written does violate the SMI and
> > is not an exception per RFC2578. (My interpretation of RFC2578 
> > indicates that if there is a refinement of an enum that
> > the BITS may no longer be contiguous and that would be allowable,
> > but this is the original definition so should be contigous, correct?)
> 
> It is true that RFC 2578 has a rule requiring that the initial
> definition of a BITS object have named bits in contiguous positions
> but allows subsequent revisions not to.  Other MIB Doctors may
> disagree, but as far as I am concerned, this is simply another CLR
> that we should not enforce.  Why restrict the original definition
> more severely than a revision?  What harm could result if this rule
> is not enforced?
> 
> In my considered opinion, the authors should get their way on this
> one, although I would ask them why they reversed the bit numbers.
> 
> For what it's worth, section 4.6.1.6 of the the just-published MIB
> review document (ftp://ftp.isi.edu/in-notes/rfc4181.txt) says this:
> 
>    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.
> 
> The "SHOULD" means "make it contiguous unless there is a good reason
> not to".  I think that the reason given by the authors is a good
> one;  that's why I would be happy to let them have their way.
> 
> Mike
> 
> 


Regards,
/david t. perkins