RE: Is unconstrained INTEGER illegal in SMIv2?

[Andy Bierman <abierman@cisco.com>]

At 11:46 PM 1/7/2003 +0100, Wijnen, Bert (Bert) wrote:
>Mmmm... Not sure why this was originally done.
>This has been so since the very first coex doc (RFC1452).
>
>How important is this? How many SMIv1 MIB Modules are 
>planned to be converted?

Keep in mind that these MIB writing guidelines are followed
very closely by vendors for their own MIBs.  I plan to force
Cisco MIB writers to follow these guidelines when the RFC is published.
SMIv1 conversions come up fairly often.  We generate more
Cisco MIB modules in a year than the entire IETF generates standard
MIB modules in a year.

Andy



>Anyway, I can live with changing it into a SHOULD or
>even a lowercase should. I think that is in sync with
>our guideline/rule:
>- For integer-valued objects, if the value range is
>  between -2147483648..2147483647 (inclusive) then:
>
>  - we prefer to use Integer32
>  - but use of INTEGER is acceptable
>
>Thanks,
>Bert 
>
>> -----Original Message-----
>> From: C. M. Heard [mailto:heard@pobox.com]
>> Sent: dinsdag 7 januari 2003 23: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
>> 
>>