Re: Should a TC be allowed to remove the MAX-ACCESS restrictions of its base type?

[Andy Bierman <abierman@cisco.com>]

At 04:00 PM 9/2/2002 -0700, C. M. Heard wrote:
>[ With apologies for a 2nd follow-up to the same message,
>  but it occurs to me that the same type of pragmatic
>  argument that can be made against adding Unsigned64 to
>  the SMI can also be made against writeable Counter64 ... ]
>
>>>>>> On Wed, 28 Aug 2002, Andy Bierman wrote:
>> [ ... ] The specific changes to a toolset are not that
>> important -- the fact that any upgrade at all is required
>> is important.  The advantages to the upgrade have to be very
>> compelling for people to even consider taking the time and
>> risking any disruption. [ ... ]
>
>Suppose that we accept this as true (as in fact I do).  Then
>it would seem that the only prudent course in designing a
>standard MIB that is supposed to be deployable _in the short
>term_ would be to avoid, if at all possible, practices that
>(a) are forbidden by SMIv2 rules and (b) are disallowed by
>a significant population of existing toolsets.
>
>As was pointed out before, toolsets are known to exist that
>enforce the SMIv2 rule that no read-write or read-create
>objects may have a SYNTAX that resolves to Counter64.
>
>Unless there is good evidence that such tools constitute a small
>minority of the market, it seems to me that you'd be better off
>_from a pragmatic point of view_ to use a 32/32 pair or some
>equivalent for all your writeable 64-bit objects if you want
>your MIB to be deployable in the short-term.

What if we used a TC that had SYNTAX INTEGER (0..2^^64-1).
Since ASN.1 allows an integer to be this large, it should
be okay. (Not withstanding any CLRs in the SMI designed
to outlaw it.)  Why can't we use INTEGER? Why do we have
a CLR that makes us use Unsigned32 or nothing?


>Mike

Andy