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

[Mike Heard asked me to contribute my 2 cents to this discussion.]

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

The original intention and Marshall's original belief was that the
the SMI was defined (in RFC 1442) primarily by ASN.1, and that 1442's
ASN.1 definition resulted in INTEGER being constrained within MIB
modules.  That is, even though INTEGER in normal ASN.1 is
unconstrained, it would be illegal in a MIB module for INTEGER to have
a value outside of the (-2147483648..2147483647) range.

Recall that the SMI is *not* defined in the SMI language; rather, the
SMI is defined in ASN.1 using the full capability of ASN.1, e.g., the
SMI's definition uses "CHOICE" which is illegal in MIBs.
Thus, this:
	    SimpleSyntax ::=
	      CHOICE {
		  -- INTEGERs with a more restrictive range -- may also
		  be used integer-value
		      INTEGER (-2147483648..2147483647), string-value
		      OCTET STRING,
		  ...

was intended to specify that SimpleSyntax could be: an INTEGER with a
restricted range, or an OCTET STRING, or ...
That is, it was intended to mean:

   INTEGER may be used with a restricted range.

(After reading this statement, now re-read the ASN.1 comment in the above,
and the reason why "more" and "also" are used becomes clear:-).

(Also, to reinforce the notion that INTEGERs were constrained, the
conversion rules in section 11.1.1 of RFC 1442 said to convert all
(non-enumerated) INTEGERs to Integer32.)

However, as I recall, Marshall later learned from an ASN.1 expert that 
it was not valid ASN.1 for INTEGER to be restricted.  In those days, we
were still claiming to be a proper subset of ASN.1, and thus RFC 1402's
method of resticting the range of INTEGER was on shaky ground.
Under these conditions, I don't think it was possible for the
SMI's definition (in ASN.1) to require all uses of INTEGER to have ranges.
Since MIBs had already been written which used INTEGER without a range,
we could not (at this later time) change the SMI to ban the use of
(non-enumerated) INTEGERs.  Thus, we had to stick with using an implicit
restriction on the range of INTEGER despite it being on shaky ground.

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

It is not confusing if one recognizes that your quote is a part of the
definition of the SMI (using full ASN.1) which would be illegal in a MIB.

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)

it is my belief that "indistinguishable" in this context was intended
to mean from a transfer syntax viewpoint, i.e., it's impossible to
distinguish Integer32 from INTEGER by examining the ASN.1 sent over
"the wire" (by looking at a packet trace).  This is similar to what
is now called a Textual Convention, but that term had not yet been
invented in 1993.

Today, since we no longer claim that the SMI is a proper subset of ASN.1,
it's not a problem for the SMI to have an implicit restriction on the
range of INTEGER, i.e., we're no longer on shaky ground.  On the other
hand, 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.

Hope this helps,

Keith.