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

RE: contiguous BITS question



I have also seen the other postings from Mike, Randy, Juergen and David.

David indeed raises a good question and that is, will in the future 
these reserved bits be used as bits or as maybe partly a octet or
a 16-bit unsigned or some such. That is a question that probably
only the WG can handle. 
Even if they do, then one could say that the abstract BITS is still fine,
but that in that case the reserved bits will no longer be mapped onto the
(currently) reserved bits in the TLV, but to other (possibly non-existent)
bits, i.e. no mapping which is fine too I think.

In any event, I would indeed do something like:

       SYNTAX  BITS {
                      delInProgress (0),
                      adminDown (1),
                      testing (2),
                      reserved3,       -- 0 on send, ignored on receive
                      reserved4,       -- 0 on send, ignored on receive
                      ..
                      reserved30,      -- 0 on send, ignored on receive
                      reflect (31)
                    }

Or some such. Just my personal (i.e. ad-hat off) 2-cents.

Bert


> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of jcucchiara@mindspring.com
> Sent: Friday, September 23, 2005 03:47
> To: mreview@ops.ietf.org
> Subject: contiguous BITS question
> 
> 
> 
> 
> HI Folks,
> 
> 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?)
> 
> Thanks,
>   -Joan
> 
> 
> 
> 
> 
> 
>