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

> The original intention and Marshall's original belief was that....
>     .... it would be illegal in a MIB module for INTEGER to have
> a value outside of the (-2147483648..2147483647) range.

Thanks for the clarification.
That seems a reasonable position.

So just to check, the *only* situation in which a value greater
than 2147483647 would be valid, would be as a Counter64 value.  Yes?
 

> This thread has also quoted this text:
> 
>   -- indistinguishable from INTEGER, but never needs more than
>   -- 32-bits for a two's complement representation
>   Integer32 ::=
>       [UNIVERSAL 2]
>           IMPLICIT INTEGER (-2147483648..2147483647)

That was actually the comment that sent me off on the wrong track.
Since it states explicitly that an Integer32 would
	"never need more than 32-bits"

and seems to contrast this with INTEGER, I'd taken this to imply that
an (SMI) INTEGER value *could* potentially require more than 32-bits.
I.e. that values greater than 2147483647 were valid.


>   ..... it's good MIB design to be more explicit in specifying a range,
> either through always using Integer32 or always specifying a range with
> INTEGER.  What I would not recommend is trying to outlaw the use of
> INTEGER without an explicit range.

I'm not particularly bothered about whether an (apparently) unconstrained
INTEGER type is legal syntax or not.   But I'd suggest that it's worth
making the implicit 32-bit limitation rather clearer, wherever possible.

  The context that sparked off this discussion (the SMIv1->SMIv2
translation algorithm) would seem a reasonable place to mention this.

Dave