Is unconstrained INTEGER illegal in SMIv2?

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

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