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

[Andy Bierman <abierman@cisco.com>]

At 08:24 PM 9/2/2002 -0700, C. M. Heard wrote:
>On Mon, 2 Sep 2002, Andy Bierman wrote:
>> 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?
>
>Do toolsets typically accept SYNTAX INTEGER (0..18446744073709551615)
>in a TC or an object definition?  The MIB compilers that I have used
>either have rejected it as an error or have handled it incorrectly.
>
>If the objective is to get your MIB deployed without having to
>deploy new tools, then it seems to me that you need to avoid
>things that the SMI says are illegal, _unless_ you've got good
>evidence that the tools don't care about the rules you are
>breaking.  That's true even if the rules in question are CLRs.
>(Incidentally, I completely agree with you that the SMIv2 rule
>restricting INTEGER to the range -2^31..+2^31-1 is a CLR.)

I'm willing to give up on this issue.  I can only devote a
limited number of cycles to SNMP (wish that number was zero ;-) 
I'll change the draft to use an "Unsigned32 pair" for each of 
these parameters.

I still think it's the wrong thing to do, but SNMP is plagued
by so many CLRs, it's best to just limit what we try to use
it for.  The lamest part is that these CLRs are there to
benefit the 3 to 6 toolkit developers on the planet, at the expense
of all the MIB readers, MIB writers, and MIB developers.  

As for the value of tagging data types in detail, so code generators
can enforce CLRs in a generic manner, this is also broken by design.
These toolkits should not bother doing some limited number of
validation checks on the varbind list. It is much better design
to have the instrumentation code completely validate the varbind
list.  This is better for robustness and portability across
toolkits, since the instrumentation developer can't be sure
which checks will actually be performed across toolkits.
Since one cannot assume a check is made, and risk crashing
the router, these validation checks end up getting done twice,
which wastes CPU time and memory.  It is especially useless
to generically check that the data type for a Set PDU varbind
is not Counter32 or Counter64.  This is mindless enforcement
of a CLR taken to an extreme.


>Mike

Andy