RE: Is unconstrained INTEGER illegal in SMIv2?

["Presuhn, Randy" <Randy_Presuhn@bmc.com>]

Hi -

As far as I know, unconstrained INTEGER is legal,
but Integer32 is preferred because it brings
additional redundancy.

Randy

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Tuesday, January 07, 2003 14:09
> To: Mreview (E-mail)
> Subject: Is unconstrained INTEGER illegal in SMIv2?
> 
> 
> Hello,
> 
> Apologies to those of you who also monitor the snmpv3 list. 
> The question
> came up ober there whether the following requirement of the 
> coexistence
> document (currently <draft-ietf-snmpv3-coex-v2-02.txt>) is actually
> justified by the language in RFC 2576:
> 
> (3)  For any object with an integer-valued SYNTAX clause, in which the
>      corresponding INTEGER does not have a range restriction 
> (i.e., the
>      INTEGER has neither a defined set of named-number 
> enumerations nor
>      an assignment of lower- and upper-bounds on its value), 
> the object
>      MUST have the value of its SYNTAX clause changed to Integer32, or
>      have an appropriate range specified.
> 
> I made the assertion that the MUSTs in that paragraph are unjustified
> because as far as I could tell the words that are actually written in
> RFC 2578 do not, in fact, ban the unconstrained INTEGER 
> syntac.  Here's
> my reasoning:
> 
> On Tue, 7 Jan 2003, C. M. Heard wrote:
> > On Tue, 7 Jan 2003, David T. Perkins wrote:
> > > Mike, did you make this claim....
> > > >>                                   .... there is nothing illegal
> > > >> about an INTEGER with no subrange or enumerations;  in 
> fact it's
> > > >> completely equivalent to Integer32 with no subrange.
> > > 
> > > Would you show me where the INTEGER without a sub-range 
> (or enumerations)
> > > is legal?
> > 
> > Well, here is the relevant text from RFC 2578, Section 7.1.1:
> > 
> >    The Integer32 type represents integer-valued information between
> >    -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 
> decimal).  This
> >    type is indistinguishable from the INTEGER type.  Both 
> the INTEGER
> >    and Integer32 types may be sub-typed to be more 
> constrained than the
> >    Integer32 type.
> > 
> >    The INTEGER type (but not the Integer32 type) may also be used to
> >    represent integer-valued information as named-number 
> enumerations.
> >    In this case, only those named-numbers so enumerated may 
> be present
> >    as a value.  Note that although it is recommended that enumerated
> >    values start at 1 and be numbered contiguously, any 
> valid value for
> >    Integer32 is allowed for an enumerated value and, 
> further, enumerated
> >    values needn't be contiguously assigned.
> > 
> > The first paragraph says that the Integer32 and INTEGER types are
> > indistinguishable, so I would expect that INTEGER could be used
> > wherever Integer32 could be used, unless a subsequent provision of
> > the specification said otherwise.  The second paragraph indeed makes
> > such an exception, which is that one is allowed to use enumerations
> > with INTEGER but not Integer32.  But I could find is no language in
> > RFC 2578 that prohibits using an unconstrained INTEGER.  On 
> that basis
> > I concluded that it's legal.
> > 
> > Now, can you explain to me why that reading is wrong?
> 
> I'd like to hear the opinions of the MIB Doctors and the 
> reasons for them.
> 
> I'll note in passing that the language in RFC 1442 did seem 
> to disallow
> unconstrained INTEGER, but in going to RFC 1902 the language 
> was changed
> to substantally the form it has above (RFC 2578 added the language
> clarifying that Integer32 is not allowed for enumerated integers).
> 
> If indeed unconstrained INTEGER is banned in SMIv2 then the 
> fact should
> be spelled out the MIB review guidelines doc, because it's not clear
> from reading RFC 2578.
> 
> //cmh
> 
>