Re: contiguous BITS question

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

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