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

[Andy Bierman <abierman@cisco.com>]

At 02:02 PM 9/3/2002 -0700, Randy Presuhn wrote:
>Hi -
>
>> Message-Id: <4.3.2.7.2.20020903121332.0b315d20@fedex.cisco.com>
>> Date: Tue, 03 Sep 2002 12:32:01 -0700
>> To: "C. M. Heard" <heard@pobox.com>
>> From: Andy Bierman <abierman@cisco.com>
>> Subject: Re: Should a TC be allowed to remove the MAX-ACCESS 
>>   restrictions of its base type?
>> Cc: mibs@ops.ietf.org
>> In-Reply-To: <Pine.LNX.4.10.10209021934400.13880-100000@shell4.bayarea.n
>>  et>
>> References: <4.3.2.7.2.20020902170459.0b307938@fedex.cisco.com>
>...
>> 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.  
>
>Some of those CLRs (like not permitting TCs to be defined in
>terms of other TCs, limiting OID lengths, etc.) actually make
>things harder for toolkit developers, too.
>
>> 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.
>
>Tagging doesn't help the code generation process AT ALL.

Then why create different data type tags for Unsigned32 and
Counter32?  (Unless this was a misguided mistake in the SMI!)


>> 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 depends on how much of the "instrumentation" code is generated
>by the toolkit.  In my opinion, everything that is machine-readable
>should be fair game for code generation.
>
>>        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.
>
>If your developers are approaching the problem this way,
>then it's pretty obvious why SNMP is not more widely used
>for configuration: they're coding for the toolkits that do
>the least automatic code generation.  If this is true, then
>the SMIng effort is a waste of time, since much of its value
>comes from the ability to automate more code generation.

I think it's a bad idea for instrumentation developers to
tightly couple their code to a particular version of a 
particular toolset.  They would have to know exactly which
checks are being done automatically.  This would make it
much harder to ever change the toolkit.


>> 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.
>...
>
>The protocol library shouldn't be doing this, but just as
>a read-only object-type's "set" method will refuse to permit
>a set request to succeed, the same should apply for Counter
>types.  If your tools aren't making these basic checks, your
>developers are wasting their time.  Relying on humans to do
>automatable tasks invites error.

The auto-generated validation code is usually such a small
subset of the total instrumentation code, that it's not
wasting that much time to replicate the checks.  Why is testing
for a set on a counter important?  How are the bits transferred
in a Counter32 varbind different the bits transferred in an
Unsigned32 varbind?  How would the instrumentation code break if
it interpreted a varbind tagged as Counter32 as an Unsigned32?
The data type tagging isn't important in this case, and the
same instrumentation code could interpret a Counter64 as an
Unsigned64 without a problem.  As you and Juergen pointed out,
the real problem is that the SMI data types are kind of a mess.
The SMI should never have added Counter64 without also adding Unsigned64.


> ------------------------------------------------------
> Randy Presuhn          BMC Software, Inc.  SJC-1.3141
> randy_presuhn@bmc.com  2141 North First Street
> Tel: +1 408 546-1006   San Jose, California 95131  USA
> ------------------------------------------------------
> My opinions and BMC's are independent variables.
> ------------------------------------------------------

Andy