Re: Is unconstrained INTEGER illegal in SMIv2?

[Andy Bierman <abierman@cisco.com>]

At 02:09 PM 1/7/2003 -0800, C. M. Heard wrote:
>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:

I agree with you that the coex document should not make this change.
I'm trying to avoid my usual rant mode here, but I find SMIv2 data
type rules to be mostly CLRs with little real benefit.  They most
serve to confuse MIB writers and give MIB reviewers more nits to
ding.  

Andy



>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