RE: Is unconstrained INTEGER illegal in SMIv2?

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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?

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
> 
>