Re: coex draft last call -- review of Section 2

>>>>> Dave Shield writes:

>> .... there is nothing illegal about an INTEGER with no subrange or
>> enumerations; in fact it's completely equivalent to Integer32 with
>> no subrange.

Dave> Is there anything in either RFC 2578 or IS 8824 that defines the
Dave> range of acceptable values for an (unconstrained) INTEGER syntax
Dave> value?

In ASN.1, INTEGER has unlimited precision. In SMIv2, the situation is
not really that clear. RFC 2578 says:

   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.

This basically tells me that INTEGER used in SMIv2 modules is indeed
constrainted to a 32 bit value. But note that in the definition of
SMIv2, INTEGER is also used with the ASN.1 semantics:

   -- for counters that wrap in less than one hour with only 32 bits
   Counter64 ::=
       [APPLICATION 6]
           IMPLICIT INTEGER (0..18446744073709551615)

Yes, this has confused many people.

Dave> I was under the impression that trying to assign a value of
Dave> 4294967296 or above (i.e. 2^32) to an object of syntax INTEGER
Dave> would be theoretically valid - but one particular implementation
Dave> might easily choke on it, while another would be quite happy.

I do not think this is the case nor the intention. And in order to
reduce the confusion that people who happen to know ASN.1 can have, we
decided to let smilint warn about the usage of INTEGER where in fact
Integer32 should have been used. In other words: while it is legal to
use INTEGER in all places where you use Integer32, it does not have
any benefits and it has the potential to mislead people. So MIB
authors should just not do this.

Dave>   By insisting that all INTEGER-based objects have an explicit
Dave> range, such inconsistencies in behaviour could be avoided.

Using Integer32 instead of INTEGER does exactly this in a clear way.

Dave>   Or is there something I've missed that applies a 32-bit
Dave> limitation to apparently unconstrained INTEGER values?

Even if INTEGER would allow values bigger than 32 bit, you would not
be able to ship them due to the way SimpleSyntax is defined so in fact
INTEGER means Integer32 when used in SMIv2 modules.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>